ISO 20022
Published on
01/09/2026
Updated on
01/09/2026
Reading time
4 min
Definition
ISO 20022 is the international standard for financial messaging. Contrary to the common belief that “ISO 20022 is an XML format,” ISO 20022 is syntax-independent.
The standard is not a single format, but rather a process from which formats are derived. By its own definition, it describes “a unified standardization approach (methodology, process, repository) that can be used by all standardization initiatives in the financial sector.”
The three components
The standard consists of three parts:
- Modeling methodology – a method for describing business transactions independently of syntax
- Data dictionary – a central repository of business terms and their definitions
- Business process catalogue – the business processes and messages derived from this
The Data Dictionary and the Business Process Catalogue together form the Financial Repository, which is publicly available on iso20022.org.
The technical schemas are then created from the model according to fixed rules (in practice XML, according to the standard also ASN.1). A field is defined not because it is in the XML schema, but because it has a definition in the data dictionary.
The message name
Each message bears a four-part name. The example pacs.008.001.08:
| Element | Meaning | Example |
|---|---|---|
pacs | Business Unit | Payments Clearing and Settlement |
008 | Message definition | FI to FI Customer Credit Transfer |
001 | Variant | Basic variant |
08 | Version | eighth version |
Two systems can both “speak pacs.008” and yet fail to interoperate because they expect different versions. “pacs.008” is not a sufficient specification.
The Business Units
The first four letters assign each message to a business unit. The following are particularly relevant for payment transactions:
| Abbreviation | Business Unit | Example in Glossary |
|---|---|---|
pain | Payments Initiation | pain.001(opens in new tab), pain.002(opens in new tab), pain.008(opens in new tab), pain.013/14(opens in new tab) |
pacs | Payments Clearing and Settlement | pacs.002(opens in new tab), pacs.003(opens in new tab), pacs.004(opens in new tab), pacs.007(opens in new tab), pacs.008(opens in new tab), pacs.028(opens in new tab) |
camt | Cash Management | camt.029(opens in new tab), camt.052(opens in new tab), camt.053(opens in new tab), camt.054(opens in new tab), camt.056(opens in new tab), camt.110(opens in new tab) |
acmt | Account Management | acmt.023(opens in new tab), acmt.024(opens in new tab) |
head | Business Application Header | see payment transaction headerHeader im Zahlungsverkehr(opens in new tab) |
remt | Payments Remittance Advice | Payment advices |
reda | Reference Data | Master data, directories |
admi | Administration | technical control messages |
auth | Authorities | Notifications to authorities |
Alongside these are the families for securities (sese, setr, seev), collateral (colr), foreign exchange (fxtr), and card operations ((caaa, catm, cainand others).
Rule for payment transactions: pain flows between customer and bank, pacs between banks, and camt reports on accounts.
The messages typically follow a sequence within the context of the business transaction for the scheme being used. Here is an example of a SEPA credit transfer:
Those who uphold the standard
ISO committee TC 68/SC 9 is responsible. Three bodies operate under it:
- The Registration Authority (RA) acts as the “custodian of the ISO 20022 Financial Repository.” SWIFT performs this role—a point often overlooked: SWIFT operates the repository on behalf of ISO but does not own the standard.
- The Registration Management Group (RMG) oversees the registration process and reports to TC 68/SC 9.
- The Standards Evaluation Groups (SEGs) review new messages from a business perspective and approve changes. They are organized into six domains: Payments, Securities, Cards and Retail Financial Services, Foreign Exchange, Trade Finance, and API Resources.
This is complemented by the Technical Support Group (TSG) for technical support.
From Standard to Specification: Usage Guidelines
The repository is too broadly defined for practical use. Almost every field is optional, and almost every structure allows for multiple entries. Consequently, each user community establishes its own usage guidelines, restricting which fields are used, which are mandatory, and how they should be populated.
| Rulebooks | Publisher | Scope |
|---|---|---|
| SEPA-Rulebooks | EPC(opens in new tab) | SCT(opens in new tab), SCT Inst(opens in new tab), SDD(opens in new tab), SRTP(opens in new tab) |
| CBPR+ | Payments Market Practice Group | Cross-border payment transactions via SWIFT |
| HVPS+ | High Value Payments Systems Plus | Large-value systems such as T2(opens in new tab) |
| National and institutional requirements | among others: Bundesbank, Berlin Group | SEPA Clearer(opens in new tab), APIs |