ISO 20022 for Payment Engineers

What ISO 20022 is (and is not)

ISO 20022 is a methodology and a catalogue: a shared data dictionary (business components such as Debtor, Creditor Agent or Interbank Settlement Amount) from which message definitions are built and published as XML schemas. It is not a single format — the same pacs.008 is used by Swift, Fedwire, CHAPS, TARGET and SEPA, each with its own rules on top.

• Message identifiers read pacs.008.001.08: business area (pacs = payments clearing and settlement), message number, variant and version. Systems pin a version; a pacs.008.001.08 and .001.10 are different schemas.
• MX vs MT — "MX" is Swift's name for ISO 20022 messages on its network; "MT" are the legacy FIN messages (MT103, MT202, MT940) they replace.
• Usage guidelines narrow the schema per community: CBPR+ for cross-border on Swift, HVPS+ for high-value RTGS systems, the EPC implementation guidelines for SEPA, plus national guidelines. Valid against the XSD is not enough — a message must also meet its guideline.
• The Business Application Header (head.001) travels with each message and carries sender, receiver, message type and business service — the part routing and duplicate checks key off.

MT103 vs pacs.008, field by field

The customer credit transfer shows what changes. Every MT103 field has a home in pacs.008, but most pacs.008 elements are richer than the field they replace — which is why mapping MX back to MT for a legacy system loses data.

Check a real message in the ISO 20022 Validator (pacs.008 CBPR+ example) and the legacy side in the SWIFT MT validator.

The messages you will meet

The same handful of messages covers most payment flows. Each links to its structure and key elements in the ISO 20022 reference.

A payment's life in messages

1. pain.001 — the corporate sends a credit transfer initiation to its bank (often a batch of payments).
2. pain.002 — the bank reports acceptance or rejection of the file or individual payments.
3. pacs.008 (with its BAH) — the debtor's bank sends the payment to the next bank, each hop carrying the same UETR; a pacs.009 moves bank-to-bank cover or liquidity.
4. pacs.002 — a bank rejects (RJCT, with a reason code) or confirms the payment before settlement.
5. pacs.004 — after settlement, a bank that cannot credit the beneficiary (closed account, AC04) returns the funds with a return reason.
6. camt.054 / camt.053 — the account holders get a notification of each credit or debit and an end-of-day statement to reconcile against.
7. Exceptions — camt.056 asks to recall a payment, camt.029 answers the investigation, and camt.110/111 carry exceptions and investigations on Swift.

Where each rail stands

Most large systems already run on ISO 20022: SEPA since its launch in 2008, TARGET since the T2 consolidation in March 2023, CHAPS since June 2023, CHIPS since April 2024, Fedwire since 14 July 2025, and Swift ended MT/MX coexistence for cross-border payments on 22 November 2025. What is still moving is the next step — the end of fully unstructured postal addresses:

Last checked against the Swift, Federal Reserve and EPC notices on 2026-09-24. The same table, with calendar dates, is on the ISO 20022 reference and the events calendar.

Structured addresses

MT messages carried names and addresses as up to four free-text lines. ISO 20022 has separate elements for street, building number, post code, town and country, so sanctions screening and routing can read them without guessing. Three forms exist:

• Structured — only the dedicated elements, at least TwnNm and Ctry.
• Hybrid — TwnNm and Ctry plus at most two AdrLine for the rest; accepted as the transition form.
• Unstructured — AdrLine only. This is what Swift, Fedwire and the EPC are retiring; the dates are in the table above.

Unstructured<PstlAdr>
  <AdrLine>Hauptstrasse 1</AdrLine>
  <AdrLine>10115 Berlin</AdrLine>
</PstlAdr>

Structured<PstlAdr>
  <StrtNm>Hauptstrasse</StrtNm>
  <BldgNb>1</BldgNb>
  <PstCd>10115</PstCd>
  <TwnNm>Berlin</TwnNm>
  <Ctry>DE</Ctry>
</PstlAdr>

The work is upstream: customer master data, onboarding forms and corporate ERP exports have to capture town and country separately before payment messages can. Test files today with the validator's post-migration option, which treats unstructured addresses as errors.

Engineering checklist

• Pin versions per counterparty and rail — and route on the BAH's MsgDefIdr, not by sniffing the payload.
• Validate in two layers — the XSD, then the usage guideline (CBPR+, HVPS+, EPC). Most rejects come from the second.
• Carry the UETR end to end — generate a UUID v4 once, keep it on every hop, status, return and statement entry; it is how gpi tracking and investigations find the payment.
• Don't truncate silently — when an internal system still speaks MT, store the full MX and flag what the mapping dropped (long names, structured remittance, ultimate parties, LEIs).
• Amounts and codes — currency minor units, 18 total digits, charge bearer codes (DEBT/CRED/SHAR) and external code lists (reason, purpose, status) are where hand-built messages break.
• Reconcile on camt — match camt.054 notifications and camt.053 statement entries back to EndToEndId and UETR, and handle pacs.004 returns as their own state, not as a failed payment.