Infrastructure11 min read

The ISO 20022 messaging standard and the future of real-time payments in Europe

The migration to ISO 20022, rich-data message structures and how SEPA and global clearing systems use standardised data flows.

What is ISO 20022?

ISO 20022 is an international messaging standard for the financial industry. It is not merely a file format but a complete methodology for defining financial messages. The standard consists of three layers: a methodology for describing messages, a business model that defines concepts such as parties, accounts and payments, and message definitions derived from that shared model.

In principle, message definitions are independent of their technical representation, meaning the same model can be expressed in XML or ASN.1, for example. In practice, payments use XML almost exclusively, and each message has a corresponding XML schema against which its structure can be validated automatically.

The central idea of the standard is a common vocabulary. When different systems, banks and countries use the same business model, information can be passed along the chain without its meaning changing or part of it being lost. This is the decisive difference from older message formats, in which fields were often short, free-form and interpreted differently by different systems.

Message families: pain, pacs and camt

ISO 20022 messages are grouped by business area. For payments, three message families are central, and their names indicate the role each message plays in the payment chain.

Message familyScopeKey messages
pain (Payments Initiation)Payment initiation between customer and bankpain.001 credit transfer initiation, pain.002 status report
pacs (Payments Clearing and Settlement)Interbank clearing and settlementpacs.008 customer credit transfer, pacs.002 status report, pacs.004 return
camt (Cash Management)Cash management, reporting and investigationscamt.052 account report, camt.053 statement, camt.054 debit/credit notification, camt.056 cancellation or recall request, camt.029 resolution of investigation

A typical payment travels as a chain of these messages. A company sends its payment file to its bank as a pain.001 message and receives a pain.002 report on the processing status. The bank forwards the payment to the payee’s bank as a pacs.008 message, and the receiving party acknowledges it with a pacs.002 message. If the payment cannot be credited, it is returned with a pacs.004 message. The payee sees the incoming payment in a camt.054 notification or on a camt.053 statement, and the cancellation of an erroneous payment is requested with a camt.056 message, which is answered with a camt.029 message.

Because all messages are based on the same business model, payment identifiers and reference data can travel through the entire chain, from the original file to the account statement. This is the basic prerequisite for automated reconciliation.

Rich data and its benefits

ISO 20022 messages are often described as rich-data messages. Richness refers to both the amount of information and its structure: data is split into unambiguous fields rather than packed into a single free-text line. Key structured data elements include:

  • Structured remittance reference. For example, the international RF creditor reference under ISO 11649 identifies an invoice in a machine-readable way.
  • Structured party data. Name, address and identifiers in separate fields, so that country, town and postcode, for instance, can be read individually.
  • Purpose codes. Standardised codes indicating the nature of the payment, such as salary or tax.
  • Organisation identifiers. Messages include fields for, among others, the LEI (Legal Entity Identifier), which uniquely identifies a legal entity.

Several processes benefit from structured data. Reconciliation becomes more efficient when an incoming payment can be matched to an open invoice by its reference without manual work. Sanctions screening becomes more precise when name and address data sit in separate fields, reducing false positives. Fraud prevention gains access to more signals with which unusual payments can be identified before execution.

SEPA and European payment systems

In Europe, ISO 20022 is nothing new. The SEPA schemes of the European Payments Council (EPC), namely the SEPA Credit Transfer (SCT), SEPA Instant Credit Transfer (SCT Inst) and SEPA Direct Debit (SDD), have been based on ISO 20022 XML messages from the outset. Finnish companies, for example, have therefore long used pain and camt messages, even if the name of the messaging standard was not familiar to them.

Large-value payment systems have also moved to the same standard. The Eurosystem’s T2 service, which replaced TARGET2, migrated to ISO 20022 messages in March 2023. In the United Kingdom, the Bank of England’s CHAPS system migrated to ISO 20022 messages in June 2023. Retail payments and large interbank payments in Europe are thus increasingly speaking the same language.

A common standard also facilitates interoperability between systems. When instant payment systems, large-value payment systems and international correspondent banks use the same business model, payment data can flow from one system to another without conversions in which information is lost.

The global migration and address data

For cross-border payments, correspondent banking traffic on the Swift network has migrated to ISO 20022 messages in accordance with the CBPR+ (Cross-Border Payments and Reporting Plus) usage guidelines. The period of coexistence between legacy MT messages and ISO 20022 messages for payment instructions ended in November 2025.

The next phase of the migration concerns address data. The aim is for party addresses to be transmitted in structured form or at least as so-called hybrid addresses, in which at least the town and country are in separate fields. Swift had planned to reject payment messages containing only unstructured addresses from November 2026. However, on 27 August 2026 Swift accepted an industry request to extend the transition period, and at the time of writing no new date had been confirmed. According to Swift, an update is due by December 2026.

A similar change applies to the SEPA schemes. Under the EPC’s original timetable, the use of unstructured addresses would have ended in all EPC payment schemes on 15 November 2026. On 10 September 2026 the EPC announced that unstructured addresses will continue to be supported beyond that date and that a new end date will be set later.

Check the current status

The migration timetables for address data changed during 2026 for both Swift and the EPC. Always check the applicable dates in the official announcements of Swift and the EPC, and with your own bank, before scheduling system changes.

The risk of data truncation

Rich data is only useful if it survives the entire payment chain. The single biggest risk during the migration is truncation: when an ISO 20022 message is converted into an older, narrower format at some point in the chain, part of the information does not fit into the target fields and is lost.

Truncation can occur, for example, when a bank’s internal core system, a company’s financial management software or an intermediary’s system still processes payments according to the old data model. The result may be that the payment reference does not reach the account statement, party address data is shortened or the purpose code disappears. This weakens reconciliation and can trigger unnecessary investigations in sanctions screening.

The risk is managed by mapping the entire data flow from message creation to archiving and ensuring that every system in the chain can process and store ISO 20022 data in full. Where a conversion cannot be avoided, its rules must be documented and any lost data identified.

ISO 20022 and real-time payments

Real-time payments highlight the importance of standardised data. Under the EU Instant Payments Regulation, the funds of an instant transfer must be made available to the payee within ten seconds. There is no room for manual investigations within that time; the message must be correctly formatted and machine-processable from the start.

The same applies to verification of payee, in which the payer’s bank checks, before the payment is authorised, whether the payee’s name matches the account number. Structured, consistent name data improves the reliability of the comparison. More information on the obligations of the Instant Payments Regulation can be found in our guide Instant transfers: SEPA Instant and the EU Instant Payments Regulation.

Real-time processing also changes reporting. As payments move around the clock, companies are shifting from daily account statements towards transaction-level notifications, such as camt.054 messages, and continuous reconciliation. Structured data is a prerequisite for this development, because only machine-readable information can be processed automatically as it arrives. A broader description of clearing and settlement systems is available in the technology area Transaction infrastructure.

Practical implementation guidance

The following principles help to adopt the ISO 20022 standard in a controlled manner. They do not replace the message implementation guidelines of banks and payment systems, which specify the versions to be used and field-level rules.

  1. Schema validation. Validate every outgoing message against the XML schema and the rules of the relevant system before sending. Correcting a rejected message after the fact is costly in a real-time environment.
  2. Field mapping. Document how data from internal systems corresponds to ISO 20022 fields, and use the same mapping across all channels.
  3. Data quality. Store party addresses in structured form in customer and supplier master data from the outset. Regardless of changes to migration timetables, structured data is a sustainable foundation.
  4. Version management. Monitor updates to the message versions in use and set aside time to test the annual rule changes.
  5. End-to-end testing. Test the entire chain from payment creation to the account statement and ensure that no data is truncated at any stage.
  6. Monitoring. Monitor rejections, returns and status reports centrally so that recurring message errors are detected quickly.
The real benefit of the ISO 20022 migration does not come from changing the message format, but from preserving rich data and putting it to use throughout the payment chain.

Sources and further reading

  1. ISO 20022 – official website
  2. European Payments Council (EPC)
  3. EPC: postponement of the address format migration timeline (10 September 2026)
  4. Swift: extension of the structured address migration for ISO 20022 payment messages
  5. European Central Bank: T2
Disclaimer

This guide has been prepared carefully from public sources, but regulation and service features change. Always check current information from official sources and the providers' own documentation. Corrections: support@brevixoo.com.