ISO 20022 specialist
This path takes you from why ISO 20022 exists to full working depth on the pain, pacs, and camt families, grounded in a real scheme lifecycle so the messages stay connected to actual money movement. It finishes with the cross-border usage guidelines and the translation and truncation problems that dominate real migration work. Expect to go to standards-level depth on the interbank messages.
FOR: Analysts and engineers who design, map, or validate ISO 20022 messages and need authoritative depth on the model and its message families.
AFTER THIS PATH YOU CAN
- You can explain the ISO 20022 message model — components, elements, and external code sets — and how a message definition becomes an XML instance.
- You can place pain, pacs, and camt messages correctly in an end-to-end flow and say which party sends each one.
- You can read a pacs.008 and account for its key party, agent, and settlement fields.
- You can describe how cross-border usage guidelines constrain the base standard and why that matters for interoperability.
- You can identify where MT-to-MX translation loses data and design around truncation risk.
THE LINE
- 01GO TO L3 — TECHNICAL DETAILSClearing versus settlementClearing works out who owes what; settlement actually pays it. Two words that sound alike and describe completely different risks.The pacs family is organized around clearing and settlement events, so the distinction is baked into the message design. Without it, interbank message fields look arbitrary.
- 02GO TO L2 — PRACTITIONER VIEW · OPTIONALMT message structureHow an MT message is put together: five blocks, numbered field tags, and the references that let banks track one payment across many systems.Much of your work will involve systems and colleagues still thinking in MT terms. Knowing the block-and-tag structure makes coexistence and translation topics later in the path concrete.
- 03GO TO L2 — PRACTITIONER VIEWWhy ISO 20022 existsWhy the industry replaced terse, position-coded MT telegrams with a structured, shared data standard for payment messages.Understanding what problem the standard solves — structured, richer, reusable data — tells you why the model makes the choices it does. That context turns memorization into reasoning.
- 04GO TO L3 — TECHNICAL DETAILSThe ISO 20022 message modelHow ISO 20022 separates a shared business dictionary from message syntax, and what the Business Application Header envelope does.The layered model of business components, message definitions, and XML syntax is the grammar of everything you will build. Specialists who skip this end up pattern-matching instead of understanding.
- 05GO TO L3 — TECHNICAL DETAILSThe pain family: payment initiationpain messages carry a customer's payment instructions to their own bank — pain.001 to initiate, pain.002 to report what happened.Payment initiation is where customer data enters the chain, and its quality determines everything downstream. Knowing pain messages lets you trace a bad interbank field back to its source.
- 06GO TO L4 — STANDARDS & SOURCESThe pacs family: interbank messagesThe interbank workhorses: pacs.008 and pacs.009 move value, pacs.002 reports status, and pacs.004 brings money back.The pacs family is the core of your specialty: credit transfers, cover payments, status reports, and returns between banks. This is the depth interviewers and integration partners will test.
- 07GO TO L3 — TECHNICAL DETAILSThe SCT lifecycleHow one SEPA credit transfer travels from the debtor's instruction through clearing and settlement to the creditor's account — and what each hop does.The SEPA credit transfer is the cleanest live example of pain and pacs messages doing real work end to end. Anchoring the families to one concrete scheme keeps your knowledge practical.
- 08GO TO L3 — TECHNICAL DETAILSThe camt family: cash management & investigationscamt messages handle cash reporting and the awkward questions — camt.056 asks for a payment back, camt.029 carries the answer.Cancellations, investigations, and cash management reporting all ride on camt messages. Exception and reconciliation flows are unreadable without them.
- 09GO TO L4 — STANDARDS & SOURCESCBPR+: ISO 20022 for cross-border paymentsCBPR+ profiles ISO 20022 for correspondent banking over SWIFT; HVPS+ does the same for high-value payment systems.Cross-border usage guidelines are where the open standard meets binding constraints on fields and practice. Real interoperability questions are answered here, not in the base catalogue.
- 10GO TO L4 — STANDARDS & SOURCESMT-to-MX translation and truncationWhat happens when rich ISO 20022 data must fit MT fields and back — truncation, address handling, and one-to-many mappings.Translation between MT and ISO 20022 formats is where migration projects succeed or fail, because richer data must survive a round trip through a narrower format. Truncation handling is a specialty skill in genuine demand.
- 11GO TO L3 — TECHNICAL DETAILSThe annual Standards Release (MSR)SWIFT updates its message standards once a year, and every connected institution moves to the new version on the same November weekend — the annual Standards Release.ISO 20022 base standards are maintained on the same annual Standards Release cycle as MT, so knowing when versions change — and how to read a Standards Release Guide — is part of keeping a migration on the rails.