ISO 20022

32.0 What this chapter gives you#

1. You will be able to explain why ISO 20022 is not a format but a method for producing formats, a dictionary of business concepts and a committee structure for deciding what goes into it.
2. You will be able to say what actually retired on 22 November 2025, and why the authorisation message leaving a shop terminal was untouched by it.
3. You will be able to read a message identifier such as pacs.008.001.08, name each of its four parts, and say why a version increment is a release rather than a configuration change.
4. You will be able to distinguish a pain message from a pacs message and say which party sends which.
5. You will be able to explain why “richer data” describes a capacity rather than a delivery, given that the unstructured remittance field is the same one hundred and forty characters in both the old message and the new one.
6. You will be able to say what a structured postal address changes for sanctions screening, and why the address mandate slipped repeatedly for reasons that were about stored data rather than software.
7. You will be able to explain why translating a rich message into a legacy format is lossy by construction, and why a round-trip diff is a more useful document than any readiness report.
8. You will be able to say why validating a message against its schema does not validate its codes, and how often the external code sets have to be refreshed.
9. You will be able to explain why a domestic real-time gross settlement system can cut over in a weekend while a correspondent network of eleven thousand institutions needed two and a half years of coexistence.
10. You will be able to state the single design rule the chapter turns on: keep the ISO 20022 message as the system of record, and translate only at the last mile.

The name is a trap. Everything else in this volume has been a format: ISO 8583 is a format, EMV tag-length-value is a format, a Bacs Standard 18 record is a format. ISO 20022 is not a format. It is a method for producing formats, plus a dictionary of business concepts that those formats draw on, plus a committee structure for deciding what goes into the dictionary. When somebody says “we’ve gone ISO 20022”, they have not adopted a message. They have adopted a family of several hundred messages, of which they probably use four.

The second trap is the word “replaces”. ISO 20022 did not replace ISO 8583 in the way that HTTP/2 replaced HTTP/1.1. As of August 2026, when you tap a card in a shop, the authorisation that leaves the terminal is still an ISO 8583 0100 and the reply is still an 0110, and there is no serious industry programme to change that. What ISO 20022 has actually replaced, and replaced almost completely, is the other legacy format: the SWIFT MT messages that carried cross-border and high-value payments between banks. That migration finished its main phase on 22 November 2025. This chapter is about what changed, what it bought, what it cost, and why a change that everybody agreed on in 2004 was still being argued about in 2027.

The plain version#

In the ISO 8583 chapter you learned the numbered form: everybody memorises the code book, box 4 is always the amount, and the message is short because nothing in it says what anything is. That works beautifully until the day you need to put something in the message that the code book never anticipated.

So think about a freight depot instead.

Harkness Joinery in Leeds sends pallets of timber all over Europe. For forty years every pallet went out with a docket: a small card with numbered boxes on it, printed in the depot’s own house style. Box 3 is the weight. Box 8 is the destination depot code. Box 14 is notes, and box 14 is one hundred and forty characters long, no more, because that is how wide the card is.

The docket works. It is small, it is cheap, it goes through the sorting machine at speed, and every depot from Leeds to Lisbon has the code book pinned to the wall. The trouble is box 14.

Because what actually needs to travel with the pallet is not a note. It is a list. This pallet covers three orders — order 4471 for £7,200, order 4488 for £6,150 and order 4502 for £5,100 — and the customer’s warehouse clerk needs to know which planks belong to which order, or she cannot sign anything off. One hundred and forty characters is not enough for three orders with their dates and amounts, so the Leeds despatcher does what despatchers everywhere do. He writes:

ORD 4471 4488 4502 PART DEL SEE EMAIL

and the pallet leaves. At the other end a human being reads that, opens a spreadsheet, and spends twenty minutes working out what arrived. Multiply by four hundred pallets a day.

There is a second problem, and it is quieter. Box 9 on the docket is the consignee: four lines of text, thirty-five characters each. The Leeds despatcher types:

VAN DOORN HOUT BV
KANAALDIJK 14
5613 EA EINDHOVEN
NETHERLANDS

That is perfectly clear to you. It is completely opaque to a machine. Nothing on the docket says which of those four lines is the town. A computer at a border checkpoint that has been told to stop every consignment going to one particular address in one particular city has to guess, by pattern-matching lumps of text against a list, and it will guess wrong in both directions: it will stop pallets it should let through, and let through pallets it should stop.

Now the new sheet.

The new sheet is A4, not a card. Every line on it says what it is. Instead of box 9 there is a block that reads:

STREET NAME: Kanaaldijk
BUILDING NUMBER: 14
POST CODE: 5613 EA
TOWN NAME: Eindhoven
COUNTRY: NL

and instead of box 14 there is a whole labelled section headed what this pallet settles, which repeats as many times as it needs to:

ORDER NUMBER: 4471   DATED: 2026-06-02   AMOUNT: 7,200.00
ORDER NUMBER: 4488   DATED: 2026-06-09   AMOUNT: 6,150.00
ORDER NUMBER: 4502   DATED: 2026-06-15   AMOUNT: 5,100.00

Three things follow from that, and they are the whole point of the standard.

The sheet is fatter. It is several times the size of the docket, because every value now drags a label along behind it. In 1985 that would have been disqualifying. In 2026, when the depot’s network cost is not measured in characters, it is a rounding error.

The sheet is self-describing. A depot that has lost the code book can still read it. More usefully, a piece of software written by someone who has never met the Leeds despatcher can read it, because “TOWN NAME” means town name everywhere the sheet is used, in every kind of sheet the depot prints — deliveries, returns, invoices, insurance claims. That consistency is not a happy accident; it is the actual product. Somebody sat down and wrote a dictionary that says what a town name is and what a consignee is, and then every form gets built out of the dictionary rather than being invented from scratch.

The clerk at the far end stops doing twenty minutes of work. This is what “richer data” means, stripped of the brochure language. It does not mean more characters. It means the same facts arrive already separated into their component parts, so that a machine can act on each part without guessing.

Now translate the whole thing back into money, with real numbers.

Harkness Joinery pays Van Doorn Hout BV €18,450.00, settling those three invoices. Under the old system that payment travelled as an MT 103, and the MT 103 has a field for remittance information called field 70, and field 70 is four lines of thirty-five characters — one hundred and forty characters — and that is all there is. The beneficiary’s name and address travel in field 59, four lines of thirty-five characters, undifferentiated. Van Doorn’s finance team gets a bank statement showing €18,450.00 from a name they half recognise and a reference that reads INV 4471 4488 4502. Somebody matches it by hand.

Under the new system the same payment travels as a message called pacs.008. The three invoices go in as three separate structured entries, each with its own number, its own date and its own amount. The address goes in with the town in the box marked town and the country in the box marked country. Van Doorn’s ledger software reads the message, matches all three invoices automatically, closes them, and nobody touches it.

That is the promise. Here is why it took twenty-two years to deliver.

The new sheet is worthless unless the depot at the other end can read it. If Leeds prints the A4 sheet and Eindhoven only has a slot for the small card, the sheet has to be cut down to fit — and cutting it down means throwing away exactly the three invoice lines that made it worth printing. So for years every depot has to be able to handle both, and the network only moves at the speed of its worst reader. Nobody can go first, because going first costs money and buys nothing. Everybody has to go at once, and “everybody” is eleven thousand institutions in two hundred countries, each with thirty years of software behind the counter that was written on the assumption that a reference is never longer than thirty-five characters.

The way that gets solved, in the end, is not persuasion. It is a date. On 22 November 2025 the old dockets stopped being accepted for cross-border payment instructions on the SWIFT network, and everybody who had been putting it off found out what their real deadline had been all along.

Where the plain version stops being true#

ISO 20022 is not a message format, and calling it “the replacement for ISO 8583” is wrong in two directions at once. It is a modelling standard: a metamodel, a repository of business concepts, and a set of rules for generating machine-readable schemas from that repository. The catalogue currently holds around eight hundred registered message definitions spanning payments, securities, foreign exchange, trade finance, collateral and cards. What was retired on 22 November 2025 was not ISO 8583 but SWIFT MT — the FIN messages of the ISO 15022 era — for cross-border payment instructions and reporting. Card authorisation traffic is untouched. ISO 20022 does contain card message sets (the business areas caaa, cain, catp and casp cover acceptor-to-acquirer, acquirer-to-issuer, ATM and sale-to-POI messaging, and the nexo standards build on them), and they have made almost no impression on global acquiring volume. The 0100 you met earlier in this volume will outlive everyone reading this.

“Richer data” describes a capacity, not a delivery. The unstructured remittance field in pacs.008 is still one hundred and forty characters, exactly the same as MT 103 field 70; the CBPR+ market practice for cross-border payments permits one occurrence of it. The gain is structure, not length, and structure only pays when the sender populates it and the receiver consumes it. The clearest evidence that this is harder than it sounds is the Bank of England: having proposed to mandate structured remittance data in CHAPS from November 2027, it announced in July 2026 that it would not, and would instead work on international alignment first. A field that exists, is schema-valid and is uniformly empty has bought nobody anything.

XML versus packed binary is the least interesting difference between the two standards, and ISO 20022 is not intrinsically XML. ISO 20022-4:2013 specifies XML Schema generation; ISO 20022-8:2013 specifies ASN.1 generation; the Registration Management Group approved a JSON Schema generation recommendation on 10 June 2025 targeting JSON Schema Draft 2020-12; and ISO 20022-9, published in April 2026, generalises syntax generation rules so that the model is not bound to any one encoding. Card messages under nexo are routinely carried as ASN.1, not XML. The substantive difference is not angle brackets versus bitmaps. It is that ISO 8583 defines a message and leaves the meaning of its contents to bilateral agreement, whereas ISO 20022 defines the meaning centrally and derives the message from it. That is why two ISO 8583 implementations can both be “compliant” and unable to talk to each other, and why the same concept has the same name in an ISO 20022 payment, statement and investigation.

Coexistence and translation preserve delivery, not meaning, and the loss is arithmetic rather than sloppiness. During coexistence a rich pacs.008 bound for a bank that could only receive MT was translated in flight. MT 103 field 70 holds 140 characters and field 59 holds four lines of thirty-five; a RemittanceInformation block with three structured invoice entries and a fifteen-element postal address does not fit, so it is truncated or dropped. The translation is not reversible: converting back the other way produces a schema-valid message containing less than the original. This matters legally as well as operationally, because the originator and beneficiary information that must accompany a wire transfer under FATF Recommendation 16 is precisely the information that translation squeezes. An institution that keeps a translated MT as its record of the payment has quietly destroyed the evidence the standard existed to carry.

The technical version#

What the standard actually is#

ISO 20022 is maintained under ISO Technical Committee 68, Subcommittee 9. The core standard was published in eight parts in May 2013 and extended in 2026:

The architecture has three layers and confusing them is the source of most arguments about the standard. At the top is the business model: business processes, business roles and business concepts, expressed in UML and independent of any message. In the middle is the logical message: a message definition assembled from components in the Data Dictionary. At the bottom is the physical syntax: an XML Schema, an ASN.1 module or a JSON Schema, generated mechanically from the logical message by the rules in Parts 4, 8 or 9. The generated XSDs carry a comment recording the Standards Editor build and the ISO 20022 version they were generated from, which tells you they are outputs, not hand-written artefacts.

Governance is a registry, not a standards body in the usual sense. SWIFT acts as Registration Authority, maintaining the repository and checking that submissions comply with the technical specifications. The Registration Management Group oversees registration and reports to TC 68/SC 9. Standards Evaluation Groups — for Payments, Securities, Cards and Related Retail Financial Services, Foreign Exchange, Trade Finance and API Resources — validate new message definitions from a business perspective and approve changes to existing ones. A Cross-SEG Harmonisation Group resolves conflicts where the same concept appears in more than one domain, and a Technical Support Group handles the syntax mechanics. A new message begins with a business justification accepted by the RMG, is developed by a submitting organisation, is validated by the relevant SEG, and is then published by the RA into the repository.

Message definitions are grouped into four-letter business areas. The payments and cards ones matter here:

The distinction between pain and pacs is the one that catches newcomers. A pain message is customer to bank: a corporate instructing its bank to make payments. A pacs message is bank to bank: the interbank leg. A corporate never sends a pacs.008 and a clearing system never receives a pain.001.

The message identifier and the namespace#

A message definition identifier has four parts:

pacs . 008 . 001 . 08
 |      |     |     |
 |      |     |     +-- version (two digits)
 |      |     +-------- variant (three digits; 001 is the base variant)
 |      +-------------- message functionality (three digits)
 +--------------------- business area (four letters)

pacs.008.001.08 is version 8 of the base variant of message 008 in the payments clearing and settlement area — FIToFICustomerCreditTransferV08. The XML target namespace embeds the whole identifier:

urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08

That last point has an operational consequence that is regularly underestimated. A version increment changes the namespace, which changes every schema binding, every XPath expression and every generated class in every application that touches the message. Upgrading from pacs.008.001.08 to pacs.008.001.13 is not a configuration change. It is a release. This is why market infrastructures pin versions and hold them for years: the SEPA 2025 scheme implementation guidelines use the 2019 message versions throughout — pacs.008.001.08, pacs.004.001.09, pacs.002.001.10, pacs.028.001.03, camt.056.001.08, camt.029.001.09, camt.027.001.07, camt.087.001.06 — and CBPR+ pinned the same generation for cross-border.

The MT messages that were retired map across roughly as follows. “Roughly” is load-bearing: the mappings are many-to-one in places and none of them is lossless.

MT 199 and MT 299 were not retired in November 2025; they remain in use for transaction tracking, with their exceptions-and-investigations and payment-initiation use cases scheduled to migrate later.

Anatomy of a pacs.008#

A CBPR+ payment on the wire is two documents in one envelope. The first is the Business Application Header, head.001.001.02, which carries routing and identification: Fr and To (the sending and receiving BICs), BizMsgIdr (the business message identifier, which CBPR+ requires to equal the group header’s MsgId), MsgDefIdr (pacs.008.001.08), BizSvc (the business service, for example swift.cbprplus.02, or swift.cbprplus.stp.02 for the straight-through-processing variant) and CreDt.

The second is the message document itself, rooted at FIToFICstmrCdtTrf, with a GrpHdr and one or more CdtTrfTxInf. Under CBPR+, NbOfTxs is fixed at 1 — one payment per message — which is a market practice restriction, not a schema restriction, and is the single most common cause of a schema-valid message being rejected by the network.

The datatypes are worth stating exactly, because they are where the contrast with ISO 8583 becomes concrete. Taking the definitions from the pacs.008.001.09 XML Schema:

• PmtId/EndToEndId is Max35Text, mandatory, and must be passed unchanged along the whole chain.
• PmtId/UETR is UUIDv4Identifier, constrained by the pattern [a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89ab][a-f0-9]{3}-[a-f0-9]{12} — thirty-six characters, a version-4 UUID, unique for the life of the payment.
• IntrBkSttlmAmt is ActiveCurrencyAndAmount: an xs:decimal restricted to totalDigits 18, fractionDigits 5 and minInclusive 0, carrying a mandatory Ccy attribute matching [A-Z]{3,3} — the ISO 4217 alphabetic code.
• ChrgBr is ChargeBearerType1Code, an enumeration of exactly DEBT, CRED, SHAR and SLEV.
• SttlmInf/SttlmMtd is SettlementMethod1Code: INDA, INGA, COVE, CLRG, TDSO, TDSA.
• Agent identification uses BICFI, typed BICFIDec2014Identifier with the pattern [A-Z0-9]{4,4}[A-Z]{2,2}[A-Z0-9]{2,2}([A-Z0-9]{3,3}){0,1} — the ISO 9362 BIC, eight or eleven characters.
• Accounts use IBAN, typed IBAN2007Identifier, pattern [A-Z]{2,2}[0-9]{2,2}[a-zA-Z0-9]{1,30} — ISO 13616.
• Legal entities use LEI, typed LEIIdentifier, pattern [A-Z0-9]{18,18}[0-9]{2,2} — twenty characters, ISO 17442.
• Ctry is CountryCode, pattern [A-Z]{2,2} — ISO 3166-1 alpha-2.
• CreDtTm is ISODateTime, which is xs:dateTime; CBPR+ requires the UTC offset to be present.

The same facts in both formats#

This is the table to keep. It is the honest comparison between what the terminal sends and what the interbank leg sends, for the concepts that appear in both.

Two rows in that table are worth dwelling on.

The amount row explains a class of migration bug. DE4 is a fixed-width integer whose decimal point is implied by the currency in DE49; 18450.00 in euros is the twelve characters 000001845000. IntrBkSttlmAmt is a decimal with the currency as an attribute: <IntrBkSttlmAmt Ccy="EUR">18450.00</IntrBkSttlmAmt>. Anything that parses the second into a binary floating-point type has introduced a defect that will surface as a one-penny break in a reconciliation six months later. Five fractional digits also means the schema will happily accept 18450.00001, which is a valid decimal and not a valid euro amount; the constraint that the value must respect the currency’s minor units lives in the usage guideline, not in the XSD.

The outcome row explains why anyone bothered. In ISO 8583, everything the issuer wants to say about a decline is compressed into DE39, two characters, of which the most commonly used means “do not honour” and is deliberately uninformative. In ISO 20022 the outcome is split: a pacs.002 carries TxSts from a four-character external code set — RCVD, ACTC, ACCP, ACSP, ACWC, ACSC, PDNG, RJCT — and where the status is RJCT a separate StsRsnInf/Rsn/Cd is mandatory, itself from a further external code set, with AddtlInf available for free text. Status and reason are different facts and get different fields. Whether the reason is any more candid than “do not honour” is a policy question, not a format question, and in the sanctions cases it usually is not.

The address problem, exactly#

Structured addresses are the least glamorous part of this migration and by a distance the most expensive. Here is the actual structure, from the pacs.008.001.09 schema (the complex type is PostalAddress24):

Three population patterns are possible and the industry has given them names. Unstructured uses AdrLine only. Fully structured uses the named elements and no AdrLine at all. Hybrid uses AdrLine for the street part but populates TwnNm and Ctry as discrete elements. CBPR+ narrows AdrLine to three occurrences; the Fedwire Funds Service hybrid profile requires at least country code and town name plus up to two free-format lines of seventy characters.

The deadline is firm and dated. Swift is removing the unstructured option with Standards Release 2026: from November 2026, a CBPR+ payment instruction carrying a purely unstructured postal address is rejected at the network, and only hybrid or fully structured addresses are accepted, with TwnNm and Ctry mandatory.

Compare what this replaced. MT 103 field 59 is [/34x] 4*35x: an optional account line followed by four lines of thirty-five characters holding name and address together, with no separator between the name and the address and no indication of which line is which. Field 50a option K is the same shape for the ordering customer. Every sanctions screening engine in the world has spent thirty years fuzzy-matching those blobs, and the false positive rate that follows is the reason a bank’s payment investigations team is the size it is. Moving the town and the country into their own elements does not make screening perfect; it changes it from a text-similarity problem into a lookup, which is a different order of problem.

The reason this deadline slipped, repeatedly, has nothing to do with software. Banks cannot populate TwnNm for a customer whose stored address is four lines of free text typed into a branch terminal in 1998. Address remediation across tens of millions of customer records, with no reliable way to distinguish a street from a district in a language nobody in the remediation team reads, is a multi-year data project. Swift’s own response has been to offer a machine learning service that infers structure from legacy address strings, which tells you how tractable the manual approach was judged to be.

Remittance information, exactly#

RmtInf is typed RemittanceInformation16 and has exactly two children:

• Ustrd, Max140Text, unbounded in the base schema.
• Strd, StructuredRemittanceInformation16, unbounded in the base schema.

StructuredRemittanceInformation16 contains, in order: RfrdDocInf (referred document information, unbounded, each with Tp, Nb as Max35Text, RltdDt as ISODate and LineDtls for line-item detail), RfrdDocAmt, CdtrRefInf (with Tp and Ref as Max35Text), Invcr, Invcee, TaxRmt, GrnshmtRmt, and up to three occurrences of AddtlRmtInf as Max140Text.

That is where the three invoices in the worked example live: three Strd occurrences, or one Strd with three RfrdDocInf occurrences, each carrying its own number, date and amount. There is also RltdRmtInf, typed RemittanceLocation7, up to ten occurrences, which does not carry the remittance data at all but a pointer to it: a Mtd from {FAXI, EDIC, URID, EMAL, POST, SMSM} and an ElctrncAdr of up to 2,048 characters. That is the escape valve for genuinely large remittance sets, alongside the standalone remt.001 remittance advice message.

Now the honest part, which vendor material tends to omit. CBPR+ restricts Ustrd to a single occurrence of 140 characters. MT 103 field 70 is 4*35x — also 140 characters. For an institution that migrated by mapping field 70 into Ustrd and declaring victory, the cross-border remittance capacity did not increase by one byte. Every gain in this area comes from Strd, and Strd requires the originating corporate to supply invoice-level data, the originating bank to carry it, every intermediary to pass it unchanged, and the beneficiary’s bank to present it on the statement. That is four consenting parties, and the Bank of England’s decision in July 2026 to abandon its November 2027 structured remittance mandate for CHAPS is the clearest available evidence of how many of them were ready.

Codes that live outside the schema#

A detail with disproportionate operational weight: many of the code sets are not in the schema. ExternalPurpose1Code is declared in the XSD merely as a string of one to four characters. ExternalCategoryPurpose1Code and ExternalServiceLevel1Code are the same; ExternalLocalInstrument1Code allows up to thirty-five. The permitted values live in the External Code Sets, published by the Registration Authority on a quarterly cycle at the end of February, May, August and November, in XLSX, XSD and JSON. The point of externalising them is that a new code can be added without incrementing a message version.

The consequence for an implementer is that validating a message against the XSD does not validate its codes, and that any implementation which compiles the code list into an enumeration in source will be wrong within three months. Treat the external code sets as reference data with a refresh job, exactly as you would treat a BIN table.

Purpose codes are the clearest example of what this buys. The Bank of England’s recommended UK purpose code list includes, among others:

Since May 2025 the Bank has mandated purpose codes on all CHAPS payments between financial institutions and on property transactions, and Legal Entity Identifiers on all CHAPS payments between financial institutions. From November 2027 purpose codes extend to all CHAPS payments, and LEIs to pacs.004 returns and pacs.009 COV payments between financial institutions. A four-character code declaring that a given £340,000 movement is a property completion rather than an unexplained transfer is worth more to a financial crime team than any amount of free text, and it costs eleven bytes.

Migration state, as of August 2026#

The pattern is not accidental. A domestic real-time gross settlement system has a closed participant list, a single operator, a mandate and a testing regime, so it can cut over in a weekend. T2 settled around 400,000 transactions on its first day, in line with the pre-migration average for a system that had been handling roughly €2.2 trillion a day. CHIPS processed 555,345 payments worth $1.81 trillion on its first day, 8 April 2024, figures its operator described as in line with a typical day. Fedwire, which averages more than $4.7 trillion a day, went in a single cutover on 14 July 2025. An open correspondent network with eleven thousand institutions cannot do that, which is why Swift ran two and a half years of coexistence and still needed contingency arrangements at the end.

Adoption figures track the deadline rather than the benefit. In June 2025 Swift reported that over 40% of daily traffic was in ISO 20022, more than 1.8 million payment messages a day across 180-plus sending and 220-plus receiving countries, and over 75% of its payments market infrastructure traffic. By September 2025 average daily ISO 20022 payment instructions had passed 60%; by October 2025 thirty-two RTGS market infrastructures had adopted the standard, representing 84.6% of Swift’s global PMI traffic volume, and Lynx reported that over 98% of its messages were MX a month before the deadline. Read that curve honestly: the industry moved when the date got close, not when the business case was explained.

The forward calendar, again as of August 2026:

• 1 January 2026. Swift’s contingency conversion of MT messages sent by institutions that had not migrated, and its in-flow translation of inbound ISO 20022 into MT for receivers, both became chargeable.
• November 2026, Standards Release 2026. The unstructured postal address option is removed and rejected when used. MT 101 (single) moves to pain.001 with contingency conversion available; MT 101 (multiple) reaches end of life. Receipt of camt.110 via Case Management becomes mandatory.
• November 2027. Mandatory send and receive of camt.110 and camt.111 for exceptions and investigations, replacing in-flow translation. Payment cancellation moves exclusively to Case Management over FINplus. MT 199 and MT 299 for exceptions, investigations and payment initiation migrate. CHAPS extends purpose codes to all payments and LEIs to pacs.004 and pacs.009 COV.
• November 2028. Target for direct debits, charges and statement messages, with enforcement dependent on community adoption. Cheque messages continue indefinitely.

Bacs, and what a 100-character record cannot hold#

The United Kingdom’s bulk clearing has not migrated and is a useful antidote to the idea that ISO 20022 is universal. Bacs Standard 18 remains a fixed-length record:

One hundred characters, or one hundred and six for a multi-processing-day file. Bacs publishes an ISO 20022 to Standard 18 translation guide mapping pain.001 to Direct Credits, pain.008 to Direct Debits, pacs.008 to cleared credits, pacs.003 to cleared debits, pacs.004 to returns, pacs.007 to reversals, pain.009 to AUDDIS, pain.010 and pain.011 to ADDACS, and acmt.022 to AWACS, with dates converted from YYYY-MM-DD to the Bacs Julian form bYYDDD and lowercase folded to uppercase.

Look at the arithmetic and the limits of translation become obvious. The service user’s reference is eighteen characters. A UETR is thirty-six. An EndToEndId is up to thirty-five. A RemittanceInformation block with three structured invoices is several hundred bytes. None of them fits, and no amount of implementation quality changes that. Translating a pain.001 into Standard 18 is lossy by construction, and anyone building a translation layer should be able to enumerate, in writing, exactly which elements are dropped and hand that list to whoever signs off the migration.

Why a migration of this kind takes a decade#

It is worth setting out the reasons as engineering rather than as complaint, because they generalise to every large format migration.

The value is bilateral but the cost is unilateral. Structured remittance data only pays when the sender populates it and the receiver consumes it. The first mover pays full cost for zero benefit. In that situation nothing happens until somebody imposes a date, which is why every milestone in the table above is a regulatory or operator mandate rather than a market outcome.

The message is the smallest part of the change. Behind a pacs.008 sit sanctions screening, fraud scoring, liquidity and intraday position management, statement generation, reconciliation, archive, regulatory reporting and dispute handling — most of it written against thirty-five-character references and four-line addresses, some of it in COBOL, and much of it maintained by people who have retired. Changing the format at the edge is a quarter’s work. Changing what the institution can do with the data is a decade’s.

You cannot populate a field with data you have never collected. The address mandate slipped twice for this reason and no other.

Coexistence is not a bridge, it is a tax. For the duration, every institution runs two message stacks, two test suites, two sets of operational runbooks and two support rotas, and reconciles between them. That cost is why coexistence must have an end date, and why the end date must eventually stop moving. Swift’s decision to make contingency conversion and in-flow translation chargeable from 1 January 2026 is the same lever, applied with a price rather than a prohibition.

The target moves during the project. Standards Releases are annual. A programme that began against pacs.008.001.08 and runs for four years will finish inside a repository that has moved several versions on, which is why market infrastructures pin versions and why the pinned version becomes the real standard.

The forcing function is legal, not technical. The reason structured party data is mandatory is that FATF Recommendation 16 and its national implementations require identifiable originator and beneficiary information to travel with a transfer. Format follows obligation.

Coexistence, translation, and what to build#

The mechanics of coexistence deserve stating precisely, because “we translate at the boundary” hides an important design decision. Swift’s approach centred on Transaction Manager, which holds a central copy of the transaction so that the rich data survives even when an individual leg is delivered in a reduced format, plus in-flow translation from ISO 20022 to MT for receivers who had not migrated and, after November 2025, contingency conversion in the other direction for senders who had not. The important property is that the central copy, not the delivered message, is the record.

That generalises into the single rule worth taking away from this chapter. Keep the ISO 20022 message as the system of record and translate only at the last mile, never in the middle. A translated message can be revalidated; it cannot be reconstituted. Once a fifteen-element postal address has been flattened into four lines of thirty-five characters, the information required to rebuild it does not exist anywhere in the message, and an institution that stores the flattened version has destroyed the very thing the migration was for.

Four other things follow, for anyone building against this.

Model, do not map. Store the message structure natively — nested parties, typed amounts, repeating remittance — and derive legacy formats on the way out. Every implementation that flattens ISO 20022 into an existing internal record on receipt has to be rebuilt later at greater cost, and the rebuild always arrives attached to a regulatory deadline.

Never treat the XSD as the specification. The schema permits far more than any network will accept. CBPR+ fixes NbOfTxs to 1; the schema does not. The schema allows seven address lines; CBPR+ allows three and Fedwire’s hybrid profile allows two. The usage guideline published on MyStandards is the contract, and the schema is only the outer bound of it. A message that passes xmllint and fails the network is the normal case, not an anomaly.

Refresh the external code sets on a schedule. Quarterly, at the end of February, May, August and November. If a purpose code or a status reason code is an enumeration in your source tree, you have a defect with a known expiry date.

And test the round trip. Take a fully populated pacs.008 with three structured invoices and a fully structured address, translate it to MT, translate it back, and diff the two. The diff is the true measure of what your coexistence arrangement costs, expressed in the only units that matter: the fields that arrive empty at the other end. Print it. Show it to whoever is signing the migration off. It is a more useful document than any readiness report, and it is the one nobody produces.

32.98 Common wrong ideas#

Wrong: ISO 20022 is a message format that replaces ISO 8583. Right: It is a modelling standard with a repository and a registry behind it, and what it replaced was SWIFT MT for cross-border payment instructions and reporting, not card authorisation traffic.

Wrong: Card messages are about to move across too. Right: The caaa, cain, catp and casp business areas exist and have made almost no impression on global acquiring volume; the 0100 will outlive everyone reading this.

Wrong: ISO 20022 means XML. Right: Part 4 generates XML Schema, Part 8 generates ASN.1, a JSON Schema generation recommendation was approved in June 2025 and Part 9 generalises syntax generation altogether, and nexo card messages are routinely carried as ASN.1.

Wrong: Migrating gives you longer remittance fields. Right: The cross-border market practice permits one occurrence of the unstructured field at one hundred and forty characters, exactly the size of the field it replaced, and every real gain comes from the structured block, which needs four consenting parties to populate, carry, pass and present it.

Wrong: A message that validates against the schema will be accepted by the network. Right: The schema is only the outer bound; the market practice fixes the number of transactions at one and narrows the permitted address lines, and the usage guideline is the contract.

Wrong: The schema defines the permitted code values. Right: Purpose, category purpose, service level and local instrument codes are declared as plain strings whose values live in the External Code Sets, republished quarterly, so a code list compiled into source is a defect with a known expiry date.

Wrong: Translating at the boundary is a safe way to coexist. Right: Translation preserves delivery and not meaning, it is not reversible, and an institution that keeps the flattened message as its record has destroyed exactly the originator and beneficiary information the standard existed to carry.

Wrong: A settlement amount can be parsed into a floating-point type like any other number. Right: It is a decimal with up to eighteen total digits and five fractional digits, and parsing it as binary floating point produces a one-penny reconciliation break six months later.

Wrong: Five fractional digits mean the schema will catch an impossible currency amount. Right: A value with five decimal places is a valid decimal and an invalid euro amount, because the constraint that the value must respect the currency’s minor units lives in the usage guideline and not in the schema.

Wrong: The industry migrated because the business case was compelling. Right: Adoption tracked the deadline rather than the benefit, because the value of structured data is bilateral while the cost of producing it is unilateral, so every milestone was a regulatory or operator mandate.

32.99 Chapter summary in 20 lines#

1. ISO 20022 is not a format but a method for producing formats, plus a dictionary of business concepts and a committee structure for deciding what goes into the dictionary.
2. What retired on 22 November 2025 was SWIFT MT for cross-border payment instructions and reporting, not ISO 8583, and the card authorisation message is untouched.
3. The old numbered form is small and fast precisely because nothing in it says what anything is, which works until the day a message must carry something the code book never anticipated.
4. The new form labels every value, which makes it fatter, makes it self-describing, and makes the same concept mean the same thing in every kind of message the standard produces.
5. That consistency is the actual product: every form is built out of a central dictionary rather than invented from scratch.
6. Translated into money, three invoices that once travelled as a one-hundred-and-forty-character note now travel as three structured entries that a ledger can match and close without a human.
7. The architecture has three layers — a business model in UML, a logical message assembled from the Data Dictionary, and a physical syntax generated mechanically — and confusing them is the source of most arguments about the standard.
8. Governance is a registry rather than a standards body in the usual sense, with a Registration Authority maintaining the repository, a Registration Management Group overseeing it and Standards Evaluation Groups validating new definitions.
9. A message identifier carries business area, functionality, variant and version, and because the version is embedded in the namespace, upgrading is a release rather than a configuration change.
10. Market infrastructures therefore pin versions and hold them for years, and the pinned version becomes the real standard.
11. Set beside ISO 8583 the differences become concrete: a six-digit trace number that wraps within the day becomes a UUID unique end to end, and a two-character outcome becomes a status plus a separate mandatory reason.
12. Structured addresses are the least glamorous part of the migration and by a distance the most expensive, because they turn sanctions screening from a text-similarity problem into a lookup.
13. That deadline slipped for a reason that has nothing to do with software: a bank cannot populate a town name for a customer whose stored address is four lines of free text typed into a branch terminal in 1998.
14. Richer data is a capacity rather than a delivery, and the Bank of England’s decision in July 2026 to abandon its structured remittance mandate for CHAPS is the clearest available evidence of how few parties were ready.
15. Many code sets live outside the schema and are republished quarterly, so schema validation does not validate codes and compiled enumerations rot within three months.
16. Purpose codes show what the structure actually buys: four characters declaring that a movement is a property completion rather than an unexplained transfer are worth more to a financial crime team than any amount of free text.
17. Domestic real-time gross settlement systems cut over in a single weekend because they have a closed participant list, one operator and a mandate; an open correspondent network of eleven thousand institutions cannot.
18. Adoption curves therefore track deadlines and not benefits, because the value is bilateral while the cost is unilateral and nobody can afford to go first.
19. Coexistence is not a bridge but a tax — two message stacks, two test suites, two runbooks, two support rotas — which is why it must have an end date and why the end date eventually had a price attached to it.
20. Keep the ISO 20022 message as the system of record, translate only at the last mile, never treat the schema as the specification, and test the round trip, because the fields that arrive empty at the other end are the only honest measure of what the arrangement costs.

Sources: ISO 20022 Registration Authority — ISO 20022 standard parts 1 to 8 (2013) and ISO 20022-9:2026; message definition catalogue; business area code list (RA, June 2025); external code sets publication policy; RMG governance pages; ISO 20022 Technical Support Group, Generation of JSON Schema Draft 2020-12 for ISO 20022 (v2.0, approved 10 June 2025). Message schemas: pacs.008.001.09 and pacs.008.001.07 XML Schemas as generated by the ISO 20022 Standards Editor. Swift: ISO 20022 implementation FAQs; ISO 20022 for financial institutions; ISO 20022 in bytes, “One month to go”; “Momentum builds as industry advances ISO 20022 adoption” (23 June 2025); CBPR+ roadmap beyond November 2025 (v5, June 2026); Swift AI address structuring model FAQ; CBPR+ pacs.008.001.08 usage guideline. Bank of England: Mandating ISO 20022 enhanced data in CHAPS (policy statement, 2024) and Expanding mandatory ISO 20022 enhanced data in CHAPS from 2027 (policy statement, 2025, including the July 2026 structured remittance decision); UK recommended purpose code list. European Central Bank: “Successful launch of new T2 wholesale payment system” (21 March 2023). EBA Clearing: EURO1 ISO 20022 migration. The Clearing House: CHIPS network migrates to ISO 20022 (10 April 2024). Federal Reserve Financial Services: Fedwire Funds Service ISO 20022 migration announcement (15 July 2025), ISO 20022 format FAQs, and Fedwire Funds Service ISO 20022 Quick Reference Guide. Payments Canada: Lynx ISO 20022 adoption and RTR pacs.002.001.10 usage guideline. European Payments Council: SEPA Credit Transfer Inter-PSP Implementation Guidelines 2025 v1.0. Bacs: ISO 20022 to Standard 18 Translation Guide and the Standard 18 message implementation guide. Swift Standards MT November 2021 Message Reference Guide for MT 103 field formats.