📐 ISO 20022 and the global migration

A data standard, not a file format

ISO 20022 is an international standard for financial messaging. It combines a modeling method with a dictionary in which every business concept has a single, reusable definition. The XML schemas published under the ISO 20022 name are generated from that dictionary, just like the ASN.1 and JSON representations. The standard governs the data model, and the file format is only one way of expressing it. A migration therefore changes the data model, and with it what an institution must know about its own counterparties. A project run as a simple parser swap leaves that part of the work out of scope.

ISO appointed Swift as registration authority, and Swift maintains the repository of published messages. Three bodies oversee that repository: the Registration Management Group rules on requests, the Standards Evaluation Groups review messages domain by domain, and a technical group keeps the dictionary consistent. Every new message starts with a Business Justification submitted to the RMG. A change takes effect only once each of these bodies has approved it in turn, which stretches the time between a request and publication. The same process protects live implementations, since no participant can change a message on its own.

Reading a message identifier

A message identifier breaks down into four parts, as pacs.008.001.08 shows. The four letters give the business area, the first three digits the message function, the next three the variant, and the last two the version. The variant is almost always 001, while the version keeps moving. Two banks that both say they support pacs.008 may therefore expect different message trees. The mismatch surfaces during testing when the interface agreement does not state which version each side uses.

Three families, three layers

The three most common prefixes sort payment messages by the part of the chain they travel on. pain covers the relationship between a company and its bank. pacs covers the interbank leg: what travels over Swift or through a real-time gross settlement (RTGS) system. camt covers reporting and exception handling. The sender and receiver change from one layer to the next: first a company talks to its bank, then banks deal with each other. A company never receives a pacs.008, and a bank does not accept a pain.001 into its RTGS. A specification that asks for a message outside its layer describes an exchange no participant can carry out.

Exception traffic covers the messages sent after a payment to cancel it, claim the funds back, or answer such a request. A recall used to travel as an MT 192, answered by an MT 196. The useful content of both messages sat in a free-text field that an operator had to read. The camt.056 and camt.029 pair carries a reason code, a reference to the original payment, and a machine-readable answer. Processing no longer waits for someone to read the message, so turnaround is faster. Recovery rates still depend on the receiving bank.

The migration timeline, system by system

The world's four largest high-value payment systems moved to ISO 20022 within three years. Each operator chose its own timing, method, and scope, and integrators working across several currencies absorbed all of those choices. A bank active in euros, US dollars, sterling, and Canadian dollars went through five separate go-lives between March 2023 and November 2025.

How structured data changes processing

A structured data element sits in its own field, and the standard fixes the field's name and allowed content. A value that used to be buried in a line of text gets a set place and a set format. A country becomes an ISO 3166-1 alpha-2 code, and a payment purpose becomes a code from a closed list. A paid invoice becomes an identified element, with its number, date, and amount. The receiving application reads these values directly, instead of extracting them from free text with regular expressions. The values also carry weight in an audit or a regulatory review. What the standard brings is this organization of content, whether the message is serialized as XML or in another format.

<CdtTrfTxInf>
  <PmtId>
    <InstrId>INST-4417</InstrId>
    <EndToEndId>INV-2026-000871</EndToEndId>
    <!-- UETR: assigned once, kept unchanged all the way to the beneficiary -->
    <UETR>b2c3d4e5-6f70-4a81-9b2c-3d4e5f607182</UETR>
  </PmtId>
  <IntrBkSttlmAmt Ccy="USD">184500.00</IntrBkSttlmAmt>
  <ChrgBr>SHAR</ChrgBr>
  <Dbtr>
    <Nm>NORDIC MARINE SUPPLY AS</Nm>
    <PstlAdr>
      <StrtNm>Strandgaten</StrtNm>
      <BldgNb>18</BldgNb>
      <PstCd>5013</PstCd>
      <TwnNm>Bergen</TwnNm>
      <!-- country as ISO 3166-1 alpha-2, never spelled out -->
      <Ctry>NO</Ctry>
    </PstlAdr>
    <Id>
      <OrgId>
        <!-- LEI: 20 characters, ISO 17442 standard (sample value) -->
        <LEI>969500XXXXXXXXXXXX42</LEI>
      </OrgId>
    </Id>
  </Dbtr>
  <!-- payment purpose: closed ExternalPurpose1Code list -->
  <Purp><Cd>GDDS</Cd></Purp>
  <RmtInf>
    <Strd>
      <RfrdDocInf>
        <Tp><CdOrPrtry><Cd>CINV</Cd></CdOrPrtry></Tp>
        <Nb>2026-000871</Nb>
      </RfrdDocInf>
      <RfrdDocAmt><DuePyblAmt Ccy="USD">184500.00</DuePyblAmt></RfrdDocAmt>
    </Strd>
  </RmtInf>
</CdtTrfTxInf>

Sanctions screening compares the parties to a payment against lists of people and entities subject to restrictive measures. An engine reading four free-text lines had to guess where the street ended and the country began. It raised alerts on cities that happened to share a name, and missed others. A Ctry field and an LEI make the match exact, because every element checked against the lists is identified for what it is. Banks that measured their alert volumes before and after migration report fewer false positives. How much fewer depends entirely on the quality of their counterparty master data.

Coexistence with MT, and the weak link

The end of CBPR+ coexistence took categories 1, 2, and 9 out of Swift's cross-border scope: the MT 103, the MT 202, and interbank statements. The rest of the MT catalog is still in use. A bank that says it has migrated may mean that cross-border scope only, not all of its services. Its other flows then stay bilingual, sometimes for years, and an integration project that built its schedule on the announcement loses weeks redoing it.

• Category 3: treasury, foreign exchange, and derivatives. No retirement date has been announced.
• Category 4: documentary collections and cash letters.
• Category 5: securities markets, which migrate on their own timetable.
• Category 7: documentary credits and guarantees, the backbone of trade finance.
• Category 9 in bank-to-corporate: the MT 940 delivered to a treasurer as a file is not affected by the interbank cutoff, and no end date has been published.

A like-for-like migration puts a translation layer in front of an unchanged core banking system that still thinks in MT. An enhanced migration, by contrast, has the core banking system carry the structured data itself. A like-for-like message still validates against the schema, because its structured fields are either empty or filled by copying a line of text. The data the standard is meant to make usable then exists nowhere in the sending system. The promised gains in compliance and reconciliation never show up.

Like-for-like does answer a real constraint. It lets a bank meet a regulatory deadline on a tight budget and push the systems overhaul to later. The deferral shows as soon as requirements target the content of fields rather than their mere presence. The party address deadline, planned for November 2026 and postponed by Swift on August 27, 2026, is the first large-scale example, because meeting it means completing counterparty master data, not changing an XML schema.

Migration is not just a Western story

Dozens of central banks have rebuilt their RTGS on ISO 20022, often while moving to round-the-clock operation. These projects happened outside the Euro-Atlantic world, and several came before the big Western systems. The National Bank of Ukraine launched its SEP-4.0 generation on April 1, 2023, with ISO 20022 messaging and 24/7/365 operation, in the middle of a war.

The same shift is visible in other markets. PRISM+ in Pakistan, PhilPaSS+ in the Philippines, BAHTNET in Thailand, NISS in Namibia, and RIPPS in Rwanda have all aligned their messaging with the standard. These programs paired a technical rebuild with longer operating hours. The Reserve Bank of India's RTGS has run around the clock since December 2020. These markets closed the gap between their old system and the standard in a single step, because they were replacing older, less tangled infrastructure.

Usage guidelines, where the real work happens

A usage guideline narrows an ISO 20022 message for a given rail, setting its mandatory fields, allowed values, and reject rules. It comes from the network, the system operator, or the scheme owner. ISO publishes none. The XSD schema that ISO publishes is deliberately permissive by comparison. Almost everything in it is optional, because the same message has to handle a salary transfer in Brazil and a market settlement in London. A developer who codes against the schema alone produces messages that pass XML validation. The rail then rejects them, because it also enforces its own guideline.

These guidelines stack up on a single payment. A corporate credit transfer starts out under CGI-MP, enters the interbank space under HVPS+ or the EPC rulebook, then crosses a border under CBPR+. Each layer adds its own requirements to those of the one before, so a field that was good enough at the first level falls short at the third. The reject then comes midway, hours after the payment was sent, from an institution further down the chain than the originator's bank.

The allowed character set shows how this layering works. The schema accepts very broad strings, and the real restriction sits in the usage guideline of whichever rail the payment takes, which differs from rail to rail. A beneficiary name with an umlaut goes through on a domestic rail, then gets rejected elsewhere or silently transliterated. Character checks belong in the sending system, where the exact name is still known, not in the transport layer, which can only reject or transliterate.

What a file sender has to change

A company that sends payment files to its bank does not produce the interbank messages itself: the bank that receives the file does the conversion. The company's file format can therefore stay the same while the rail changes. That setup works as long as requirements concern the form of the messages. It stops working once requirements concern their content, because no translation layer can produce data the sender never had.

What the migration does not fix

How fast a payment moves depends on system operating hours, the number of correspondents it passes through, and the time spent in compliance checks. What it costs depends on competition in the corridor and the number of intermediaries taking a fee. A richer message format affects none of these factors. ISO 20022 makes them measurable without removing them.

• Cutoffs stack up. Each correspondent sets its own cutoff time, and the chain is only as fast as the link that closes earliest.
• Alerts still need human review. Structured data cuts false positives, but someone still has to review the cases that remain.
• FX is handled elsewhere. Currency conversion and its cost have nothing to do with messaging.
• Underbanked corridors stay closed. A better-formed message creates no correspondent relationship where none is left.

The next deadline is regulatory. The revised FATF Recommendation 16 sets new requirements for originator and beneficiary data, structured along ISO 20022 lines. Full implementation is expected by the end of 2030. FATF put its draft guidance out for public consultation in June 2026, and the comment period closed on August 21, 2026. An institution that migrated like-for-like will have to rework its counterparty master data before that deadline.