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:

ElementMeaningExample
pacsBusiness UnitPayments Clearing and Settlement
008Message definitionFI to FI Customer Credit Transfer
001VariantBasic variant
08Versioneighth 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:

AbbreviationBusiness UnitExample in Glossary
painPayments Initiationpain.001(opens in new tab)pain.002(opens in new tab)pain.008(opens in new tab)pain.013/14(opens in new tab)
pacsPayments Clearing and Settlementpacs.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)
camtCash Managementcamt.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)
acmtAccount Managementacmt.023(opens in new tab)acmt.024(opens in new tab)
headBusiness Application Headersee payment transaction headerHeader im Zahlungsverkehr(opens in new tab)
remtPayments Remittance AdvicePayment advices
redaReference DataMaster data, directories
admiAdministrationtechnical control messages
authAuthoritiesNotifications to authorities

Alongside these are the families for securities (sesesetrseev), collateral (colr), foreign exchange (fxtr), and card operations ((caaacatmcainand 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:

The account holder instructs the debtor bank with a pain.001 and receives a pain.002 in return. The debtor bank sends a pacs.008 through the SEPA Clearer to the creditor bank. Only if the payment cannot be processed does a pacs.002 reject come back. After settlement the beneficiary is notified by a camt.054 and both customers see the payment on their camt.053 account statement. If the money has to come back, the account holder asks with a camt.055 and the debtor bank sends a camt.056 recall. The creditor bank then answers in one of two ways: variant A, a pacs.004 returns the funds and a camt.054 credits them back; variant B, a camt.029 rejects the recall with a reason code and the money stays with the beneficiary.Debtorthe account holderDebtor’s bankoriginator’s PSPSEPA Clearerthe CSM in betweenCreditor’s bankbeneficiary’s PSPCreditorthe beneficiary1 · the order2 · the paymentonly if something is wrongsettlement — the payment is final3 · the customers are informed4 · the recallpain.001 · the customer’s orderpain.002 · acceptedpacs.008 · customer credit transferpacs.008 · on to the creditor’s PSPpacs.002 · rejectpacs.002 · passed backcamt.054 · credit notificationcamt.053 · account statementcamt.053 · account statementcamt.055 · the customer’s recall requestcamt.056 · recall requestcamt.056 · on to the creditor’s PSPpacs.004 · accepted — funds returnedpacs.004 · the return arrivescamt.054 · credited backcamt.029 · rejectedcamt.029 · reason code says whyrecall window: 10 business days for a bank recall, up to 13 months for a customer request — answer due within 15 business days5 · one of two answersvariant A · the recall is acceptedvariant B · the recall is rejectedno return — the money stays with the beneficiaryIn the SEPA Clearer the pacs.002 is the reject. In SCT Inst the same message is the positive confirmation.An ISO 20022 message rarely travels alone — it is part of a sequence1 · The order: the account holder sends a pain.001 and gets a pain.002 back2 · The payment: a pacs.008 runs through the SEPA Clearer to the beneficiary’s PSPOnly if something is wrong: a pacs.002 rejects the payment — then it never settles3 · After settlement: a camt.054 notifies the beneficiary, a camt.053 reports to both4 · The recall: the account holder asks with a camt.055, the bank sends a camt.0565a · Recall accepted — a pacs.004 returns the funds, a camt.054 credits them back5b · Recall rejected — a camt.029 comes back with a reason code, and the money staysOne payment, up to ten message types — that is why ISO 20022 is a conversation, not a form
pacs.008 in the SEPA Clearer — from the account holder to the beneficiary, and every message in between

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.

RulebooksPublisherScope
SEPA-RulebooksEPC(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 GroupCross-border payment transactions via SWIFT
HVPS+High Value Payments Systems PlusLarge-value systems such as T2(opens in new tab)
National and institutional requirementsamong others: Bundesbank, Berlin GroupSEPA Clearer(opens in new tab), APIs

Sources