The ISO 20022 message model
How ISO 20022 separates a shared business dictionary from message syntax, and what the Business Application Header envelope does.
L0 Explain simply
Analogy: think of ISO 20022 as a dictionary plus a grammar, not a pile of ready-made sentences. The dictionary defines reusable parts — "debtor", "amount", "account" — once, each with a precise meaning. Every message type is a sentence pattern assembled from those shared parts, which is why the same concept looks identical wherever it appears. And like a letter, each message travels inside an envelope: the Business Application Header is the address label on the outside, saying who sent it, who should receive it, and what kind of document is inside — so the postal system can route and sort the letter without having to open and read it.
L1 Core concepts
The standard has layers. At the top sits the business model: definitions of parties, accounts, amounts, and the relationships between them, held in a central repository. Message definitions are assembled from those shared components, which is why a debtor block looks the same in a customer initiation message as in an interbank transfer. The wire format is XML, validated against a published schema. Names follow area.number.variant.version: in pacs.008.001.xx, pacs is the business area, 008 the message number, 001 the variant, and the final part a version that changes as the standard evolves. Networks and schemes pin the specific versions they accept, so version numbers matter operationally, not just editorially.
L2 Practitioner view
The Business Application Header — message definition head.001 — is a separate small document that travels with the payload rather than inside it. It identifies the sender and receiver at business level, names the message definition of the payload, and can carry a business service identifier telling the receiver which usage guideline the message claims to follow. Practically, validation happens in layers: schema validation checks the XML against the base definition; guideline validation applies the tighter rules of the specific scheme or service; business validation — does the account exist, is a party sanctioned — happens in the bank's own systems. A message can pass the first layer and still fail the others, and institutions differ in where each layer runs.
L3 Technical details
Details worth knowing. Many code lists are external code sets, maintained outside the message schemas so new codes can be added without reissuing a message version. New versions add or restructure elements, which is why version coexistence is normal: an infrastructure declares which version of pacs.008.001 it accepts and when it will move. In the header, elements such as Fr (from), To, BizMsgIdr (business message identifier), and MsgDefIdr (message definition identifier) drive routing and duplicate detection. Where guideline validation is enforced varies by institution — at the network gateway, in the payment engine, or both — so an identical message can be rejected at different points in different banks, a genuine source of cross-institution confusion during investigations.
L4 Standards & sources
The governing publications sit with the ISO 20022 Registration Authority. The catalogue of messages, published on iso20022.org alongside the underlying e-repository, is the normative record of every registered message definition: for each one it fixes the elements, their multiplicities and data types, and the shared business components they draw on. The Business Application Header is itself a registered definition — head.001, root element AppHdr — defined as a header that can be combined with any other ISO 20022 message definition to form a complete business message; it formally specifies the business-level sender and receiver, the message's own identity, and the MsgDefIdr naming the payload definition. Neither tells you how a network uses a message: the catalogue defines what a message can carry; each community's usage guideline decides what it must and may carry on a rail.
Sources & standards2
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · catalogue of messages and e-repository
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Official requirement
Business application header (BAH) ↗ — ISO 20022 Registration Authority · head.001 (AppHdr) message definition
Several BAH versions exist (head.001.001.01 through .03); each usage community, such as CBPR+, specifies which version applies.
Sources for this topic3
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · message definitions and shared component repository
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Official requirement
Business application header (BAH) ↗ — ISO 20022 Registration Authority · head.001 Business Application Header definition
Several BAH versions exist (head.001.001.01 through .03); each usage community, such as CBPR+, specifies which version applies.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: The three-layer validation model (schema, guideline, business) is our teaching device; real validation pipelines split these steps differently per institution and network.
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.
Deepest material on this page: L4 — Standards & sources. Where a topic stops short of implementation depth, that is a deliberate coverage decision, not an oversight — see coverage.