What ISO 20022 is
ISO 20022 is an international standard for the messages financial institutions exchange: payment orders, confirmations, returns, statements and notifications. Unlike earlier formats based on fixed-length fields or free text, ISO 20022 defines a common data model and usually expresses it in XML (and, increasingly, in JSON for APIs).
The practical difference is the richness and structure of the information. An ISO 20022 message can carry the name and structured address of the debtor and creditor, entity identifiers, the purpose of the payment and references to the invoice being paid. That information travels intact end to end and makes it possible to automate reconciliation, compliance and customer service.
Why it is worth acting now
The world's major payment infrastructures have been adopting ISO 20022. In cross-border messaging, SWIFT set November 2025 as the end of the coexistence period for the old MT messages for interbank payment instructions, so correspondents now expect data in the new format. Many domestic and instant payment systems also use it or have announced it.
For a mid-sized bank or a credit union, the reason is not only to satisfy a correspondent. It is the ability to integrate with fintechs, wallets and Open Finance ecosystems without building a different connector for each one. An institution that speaks ISO 20022 at its edges lowers the cost of every new integration.
Note: Domestic payment systems have their own formats and timelines. Before planning, confirm with the operator of each system (in Venezuela, the BCV; in Mexico, Banxico for SPEI) which format it requires today and what changes are planned.
The messages worth knowing
ISO 20022 has hundreds of messages grouped by business domain. For payments and cash management, a handful carries most of the traffic:
| Message | What it is for |
|---|---|
| pain.001 | Credit transfer order sent by a customer (company) to its bank. |
| pain.002 | Status of that order: accepted, rejected or pending. |
| pacs.008 | Credit transfer between financial institutions. |
| pacs.002 | Status of a payment between institutions. |
| pacs.004 | Return of a payment that has already settled. |
| camt.053 | End-of-day account statement. |
| camt.054 | Debit or credit notification on the account. |
| camt.056 | Request to cancel a payment. |
Families are identified by their prefix: pain (payment initiation), pacs (clearing and settlement between institutions) and camt (cash management and reporting). Knowing which ones each flow in your institution uses is the first step of the inventory.
What changes in your data
The hard part of ISO 20022 is not the XML but the data. The new messages expect information that many legacy cores store incompletely or as free text:
- Structured addresses. Street, city, postal code and country in separate fields instead of free lines.
- Party identifiers. Entity identifiers such as the LEI, BIC codes and personal identification numbers.
- Remittance information. References to the invoice or document being paid, in structured fields.
- Payment purpose and category. Codes that explain why money moves, useful for compliance.
- Lengths and character sets. Longer names and characters that older formats truncated.
If the core truncates or mixes that data, the message will be incomplete even if the format is correct. That is why the migration must include data quality work on the customer master file, not just an interface change.
Two strategies: translate at the edge or adopt in the core
Translation at the edge
An integration layer receives ISO 20022 messages and translates them into the format the current core understands (ISO 8583, SOAP, flat files) and back. It is the fastest route: it does not require changing the core and lets you connect new rails in weeks or months, depending on scope. Its limit is that data the core does not store will not appear by magic; the layer can enrich it from other sources, but not invent it.
Adoption in the core
The core stores and processes data using the ISO 20022 model from the source. It is the ideal destination because it removes translations and information loss, but it requires a modern core or a migration. In practice, most institutions combine both: they translate at the edge today and adopt in the core as they modernize each product.
In the Alodiga platform, AloConnect plays the role of edge translator, with configurable mappings between ISO 20022, ISO 8583, SOAP and other protocols, and AloCore exposes its APIs with models aligned with the standard. The guide Modernizing the core without shutting down the bank explains how both pieces fit together.
A phased migration plan
- Inventory. List payment flows, the systems involved, current formats and counterparties (correspondents, domestic systems, fintechs).
- Prioritization. Start with the flow under the most external pressure or with the most value: usually cross-border payments or the integration with a new partner.
- Data mapping. For each message, document where each field comes from, what is missing and how it will be completed.
- Data quality. Fix the customer master file: addresses, identifiers and names. This is business work, not just IT work.
- Translation and testing. Configure the integration layer and test with real anonymized messages, including rejections and returns.
- Parallel run. For a period, compare results between the old and the new flow before retiring the former.
- Progressive adoption. As you modernize products, move the data model into the core so you no longer need to translate.
Who should take part and how to measure progress
An ISO 20022 migration is not an IT-only project. At a minimum it needs payment operations (who know the flows and exceptions), compliance (who will use the new data for screening and monitoring), customer service (who receives complaints about held payments) and the data or customer master file team. Appoint a business owner for each flow and a technical owner for each integration.
Useful indicators
- Percentage of outgoing messages with a structured address and complete identifiers.
- Rate of rejections and returns caused by incomplete data, before and after each phase.
- Percentage of incoming payments reconciled automatically.
- Number of integrations already using the common layer versus point-to-point connectors.
Measure from the start, even if the starting numbers are poor: the baseline is what will let you show management the value of each phase.
What the institution gains
- Automatic reconciliation. Structured references make it possible to match payments and invoices without manual work.
- Better compliance. More party data makes screening against lists and AML/CFT monitoring easier. See AloCompliance.
- Cheaper integrations. A single language for correspondents, fintechs and Open Finance APIs.
- Better service. Fewer payments held for incomplete data and faster responses to complaints.
Common mistakes
- Treating the migration as a format project and forgetting the quality of source data.
- Silently truncating long fields when translating to the core format, losing information.
- Testing only the happy path and not rejections, returns and cancellations.
- Building point-to-point connectors for each counterparty instead of a common layer.
Alodiga · Alodiga Team · October 2026 · Source: https://alodiga.com/en/recursos/migrar-iso-20022