What Is ISO 20022? Understanding the Common Language of Next-Generation Payment Infrastructure

ISO 20022 is frequently mentioned in discussions of fintech and cross-border payments. Some describe it as a new cross-border payment system; others reduce it to an XML message format, or assume that it is a new protocol introduced by the Society for Worldwide Interbank Financial Telecommunication (Swift) to replace legacy telegraph-style messaging.

Those explanations blur the boundary between transmitting information and settling funds.

ISO 20022 is not a clearing network. It does not move money by itself, nor is it a single transport protocol. It is a financial-industry methodology for information modelling and a business data dictionary. The important question is what infrastructure problem it seeks to solve: how financial institutions, payment and clearing systems, and market infrastructures that do not otherwise interoperate can exchange data in a shared language with explicit syntax and machine-readable meaning.

Standardising message formats is only the first step in modernising infrastructure. Even when institutions use the same standard at the messaging layer, cross-border payment friction and fragmentation do not disappear automatically.

I. What Is ISO 20022?

At the most basic level, a payment requires a payer's bank to tell a payee's bank: credit a specified amount to a specified customer.

When that instruction moves between institutions, it carries much more information: the legal names of the payer and payee, account numbers or identifiers, the ultimate originator and beneficiary, the correspondent-bank clearing route, the party responsible for fees, the underlying contract or invoice number, and the address and Legal Entity Identifier (LEI) needed for compliance screening. Processing can stop when institutions interpret those data differently or lack a common vehicle for transmitting them.

Modern payment systems operate on two parallel tracks. One is the funds flow, which changes ledger balances. The other is the information flow, which records the meaning of a transaction and the parties involved. ISO 20022 primarily addresses the latter by giving financial institutions common definitions for the data they exchange.

1. A Four-Layer Architecture

ISO 20022 is developed under the International Organization for Standardization Technical Committee 68 (ISO/TC 68). ISO describes it as a standardisation methodology^[1]. It is not a fixed data table, but a layered framework with four components:

1. Business Concepts: abstraction of real financial processes and roles into common concepts, including the debtor, creditor, instructing agent, instructed agent, and clearing channel.
2. Logical Data Elements: the Business Data Dictionary defines the meaning, attributes, validation rules, and permitted values of each element.
3. Message Definitions: data elements are assembled into specifications for particular use cases, such as customer credit transfers, financial-institution transfers, and account balance reports.
4. Syntax Solutions: logical models are converted into concrete physical formats.

ISO 20022 is therefore not synonymous with Extensible Markup Language (XML). While most current implementations define message schemas in XML, ISO 20022 technical specifications also include rules such as Abstract Syntax Notation One (ASN.1). In future, its model may be mapped to JSON, data-exchange specifications, or even distributed-ledger state dictionaries^[2]. Syntax is the physical wrapper; the essential elements are the data model and business semantics.

2. Coverage Across Financial Services

ISO 20022 is not limited to retail payments or interbank clearing. Under its governance framework, it spans five principal financial-service domains:

• Payments: corporate and consumer payment initiation, interbank clearing and settlement, liquidity management, payment tracking, and exception handling.
• Securities: securities trading, clearing and settlement, corporate actions, custody, and depository reconciliation.
• Trade Finance: letters of credit, commercial invoice transmission, and supply-chain financing instructions.
• Cards and Related Services: point-of-sale terminal communications, ATM transaction exchange, merchant-acquiring authorisation, and clearing.
• Foreign Exchange (FX): FX trade confirmations, hedge reporting, and FX clearing instructions.

ISO 20022 is a common information-modelling framework across financial asset classes. It can give post-trade securities settlement and invoice matching in cross-border trade access to the same data dictionary and account semantics, reducing the cost of bridging information across financial markets.

3. Governance and Standard Maintenance

ISO 20022 has remained an international standard because it is supported by an open governance framework with checks and balances. Four bodies play central roles:

• ISO/TC 68: sets the top-level governance framework and metamodel specifications.
• Registration Management Group (RMG): represents the global financial community, monitors the standard's evolution, approves requests to develop new business domains, and oversees the maintenance process.
• Standards Evaluation Groups (SEGs): industry experts in individual domains, such as the Payments SEG and Securities SEG, who assess market change requests and approve changes to message specifications.
• Registration Authority (RA): operates the data dictionary and message catalogue, maintains the official website, and publishes technical documentation. Swift currently provides this operational service.

To accommodate market developments, ISO 20022 follows a formal Annual Maintenance Cycle^[3]. Financial institutions, payment systems, and industry organisations submit Change Requests (CRs) by the second quarter. The relevant SEG tests their business rationale, after which the RA prepares the new version for global publication in the following year.

Three layers must be distinguished in practice:

ISO 20022 Standard

⬇

ISO 20022 Message Definitions, maintained annually

⬇

Market Practice Usage Guidelines, such as CBPR+ and HVPS+

Official ISO message definitions often contain thousands of optional elements to accommodate complex requirements worldwide. A payment system implementing them must publish its own market-practice guidelines, specifying which fields are mandatory and which code values are permitted. The Swift upgrades discussed in the industry usually concern upgrades to such usage guidelines, not a replacement of ISO 20022's underlying modelling framework.

II. Why Is the World Migrating? Payment Systems First Had to Address Data Fragmentation

Before ISO 20022 migration began, global financial-payment infrastructure ran in a dispersed, proprietary, and highly fragmented messaging environment.

Domestic interbank clearing systems typically used local specifications designed by regulators or clearing organisations. Cross-border clearing relied heavily on Swift's legacy MT messages. Securities custodians and exchanges used proprietary protocols, while banks'core systems accumulated their own historical code and internal data dictionaries.

The Committee on Payments and Market Infrastructures (CPMI) at the Bank for International Settlements (BIS) observed in its 2026 study of financial-messaging evolution that legacy back-office environments faced structural constraints from parallel standards, repeated data conversion, and information truncation across systems^[4].

1. The Limitations of Legacy Messages: Constrained Capacity and Unstandardised Meaning

Take legacy MT messages, used for decades in interbank communication, such as MT 103 for customer transfers and MT 202 for financial-institution funds transfers. Their original design imposed strict character limits to economise on storage and transmission, and it relied heavily on unstructured free-text fields.

In an MT 103, a payer's or payee's address and remittance information may be restricted to a few free-text lines of 35 characters each. Senders commonly compress country, province, street, building number, and contact details into a single continuous string.

This makes processing difficult for computer systems. An automated screening engine cannot reliably determine which characters identify a city, which describe a street, and which are abbreviated narrative text. When a payment moves from a domestic clearing system to a cross-border correspondent network and then to a local payment system in another country, differences in field length and structure can truncate data. Once essential clearing information is lost in transit, the payment must move to manual handling. Different languages and spelling conventions also lead to inconsistent interpretations of the same transaction and require substantial manual communication, one reason why cross-border payments can be inefficient.

2. Structured, Semantic, and Extensible Data

Compared with traditional formats, ISO 20022 provides structured, semantic, and extensible data.

[Traditional free-text format]
:70: INV 98765 ABC TRADING Lize Road No.18 Beijing CN TAX ID 12345

[ISO 20022 structured-data format]
<RmtInf>
  <Strd>
    <RfrdDocInf>
      <Nb>INV-98765</Nb>
    </RfrdDocInf>
  </Strd>
</RmtInf>
<Cdtr>
  <Nm>ABC TRADING</Nm>
  <PstlAdr>
    <StrtNm>Lize Road</StrtNm>
    <BldgNb>No.18</BldgNb>
    <TwnNm>Beijing</TwnNm>
    <Ctry>CN</Ctry>
  </PstlAdr>
</Cdtr>

When a system can accurately identify the business attribute of every byte, a payment instruction can trigger Straight-Through Processing (STP). Bank compliance systems no longer need to infer a payer's risk profile from incomplete strings, and automated reconciliation can match purchase invoices with incoming bank transactions. Better payment data is a major driver of infrastructure modernisation.

III. What Does ISO 20022 Contain? The Payment Information Lifecycle from pain to pacs to camt

ISO 20022 message names follow a clear functional convention. Each standard message name has four components, for example:

• Business Domain: the first four letters identify the business domain. For example, pacs denotes payments clearing and settlement, pain denotes payment initiation, and camt denotes cash management.
• Message Functionality: the three-digit number identifies a function within that domain. For example, 008 denotes a customer credit transfer and 009 a financial-institution transfer.
• Flavor / Variant: the three-digit number identifies a particular industry or sub-market variant; the baseline version is generally 001.
• Version Number: the final two digits identify the release version.

Following the full lifecycle of an interbank customer payment shows how these messages work together.

[Layered information transmission over a payment lifecycle]

  Debtor Enterprise A                  Creditor Enterprise B
       │                                     ▲
       │ pain.001 (payment initiation)       │ internal credit notification
       ▼                                     │
   Debtor Bank A ───── pacs.008 (interbank clearing) ───── Creditor / Account-Holding Bank B
       │                                     │
       ├─ camt.054 (debit notification)      ├─ camt.054 (credit notification)
       └─ camt.053 (end-of-day statement)    └─ camt.053 (end-of-day statement)

1. Payment initiation: pain (Payment Initiation)

A corporate payer sends a batch-transfer request to its bank through online banking or an internal ERP system. The messages at this stage belong to the pain domain. The corporate customer sends pain.001, a customer payment-initiation message, requesting the bank to debit its account. Once validated, the bank may return pain.002, a payment-status report, showing that the instruction was accepted or rejected.

1. Clearing and settlement: pacs (Payments Clearing and Settlement)

After accepting the customer's instruction, the payer's bank must send clearing and settlement instructions to the payee's bank through an interbank payment system. Messages at this stage belong to the pacs domain.

• For an ordinary transfer initiated by an individual or corporate customer, the debtor bank sends a pacs.008, a financial-institution customer credit fund transfer message, to the creditor bank or payment system. It carries structured information about both parties and the clearing channel.
• For interbank borrowing, or settlement of FX trading positions, institutions use pacs.009, a financial-institution credit fund transfer message. It does not contain ordinary retail-customer data.
• If an account is frozen or payment information is incorrect, the receiving party sends pacs.004, a payment-return message, to begin the return process.

1. Cash and account management: camt (Cash Management)

As funds move and after settlement, banks reconcile accounts with customers and payment systems. These messages belong to the camt domain.

• When an account balance changes, a bank uses camt.054, a debit and credit notification, to send a real-time debit or credit alert to the customer.
• At the end of each business day, participant banks send camt.053, a bank-to-customer statement, to large corporate clients with end-of-day balances and transaction details.
• When an exception occurs, institutions use camt.056, a payment-cancellation request, and camt.029, a cancellation-investigation resolution, to track it automatically.

Message Flows and Funds Flows Are Not the Same Thing

One frequent misunderstanding is to treat a pacs.008 message containing clearing and settlement fields as the funds flow itself. A message is only a payment instruction with highly structured semantics; the actual funds flow is a separate process.

No matter how complex the data elements contained in a pacs.008 message, it only instructs the central bank to debit Bank A's reserve account by CNY 1 million and credit Bank B's reserve account by the same amount. Final clearing and settlement still depend on a Real-Time Gross Settlement (RTGS) system debiting and crediting commercial banks'reserve-deposit accounts. The message is a means of communication, not the final settlement asset. Our earlier article, "After the "Transfer Was Successful": Payment Instruction, Account Posting, and Funds Transfer Are Actually Three Different Things", explains the accounting of an interbank transfer in more detail.

IV. Why Is the World Migrating? From National RTGS Systems to Swift's Cross-Border Transition

From national large-value payment systems to international messaging networks, core financial infrastructure around the world has been migrating its messages to ISO 20022 in recent years. This is also an important technical prerequisite for the Group of Twenty (G20) roadmap to improve cross-border payments.

1. The Migration of Global RTGS Systems

RTGS systems are hubs of national financial market infrastructure. Because they carry systemically important transactions, major jurisdictions have spent years on consultations, sandbox testing, and live trials before upgrading their messaging standards.

According to the CPMI's overview of global infrastructure migrations^[4], large-value settlement systems in major economies have switched in stages:

[ISO 20022 migration timeline for major large-value payment systems]

2015 ── Bank of Japan's BOJ-NET completed its system renewal and adopted ISO 20022 early
 │
2020 ── The People's Bank of China's large-value RTGS system applied and continued to refine ISO 20022 alongside the second-generation domestic payment-system upgrade
 │
2022 ── The Monetary Authority of Singapore's MEPS+ entered live operation under its new messaging standard
 │
2023 ── The Eurosystem's T2 replaced TARGET2 with a major system upgrade
 │    ── The Bank of England's CHAPS converted its core clearing messages to ISO 20022
 │    ── Canada's Lynx large-value system completed its first migration phase
 │
2024 ── Hong Kong Monetary Authority's HKD CHATS completed ISO 20022 migration
 │
2025 ── The Federal Reserve's Fedwire Funds Service switched in July 2025
 │    ── Swift ended the coexistence period for cross-border payments and reporting messages on 22 November 2025
 │
2026 ── CPMI issued updated harmonised ISO 20022 data requirements for cross-border payments

• Japan: The Bank of Japan Financial Network System (BOJ-NET) began a comprehensive upgrade based on ISO 20022 messaging as early as 2015. It was among the earlier infrastructures in a major reserve-currency jurisdiction to build practical experience.
• The euro area and the United Kingdom: In March 2023, the European Central Bank launched T2, replacing TARGET2's legacy messaging architecture with ISO 20022. In June of the same year, the Bank of England's Clearing House Automated Payment System (CHAPS) completed its transition.
• The United States: The Federal Reserve migrated the Fedwire Funds Service to ISO 20022 and completed the transition in July 2025^[5]. The upgrade of the USD large-value clearing message layer marked the broad completion of standards migration among the core wholesale settlement systems for major reserve currencies.

2. The Actual Relationship Between Swift and ISO 20022: Standard and Network

Many newcomers conflate Swift with ISO 20022. In financial operations, they have distinct roles:

• ISO 20022 is an international standard framework: it is managed by ISO, and can be adopted by financial systems, private networks, and non-bank fintech platforms. It is not owned by a single commercial organisation.
• Swift is a financial-telecommunications cooperative and network operator: it provides secure, encrypted messaging rails for more than 11,000 financial institutions worldwide and implements relevant message specifications within that network.

Swift serves as the ISO 20022 Registration Authority (RA). To establish consistent usage among international banks on its network, Swift also worked with global commercial banks and clearing experts to develop the Cross-Border Payments and Reporting Plus (CBPR+) market-practice guidelines.

CBPR+ is not a separate standard outside ISO 20022. It is a market-practice usage guideline for cross-border payment scenarios on the Swift network.

During the transition launched in March 2023, Swift permitted legacy MT messages and ISO 20022 messages to coexist and provided in-flow translation. As institutions completed their upgrades, the transition ended on 22 November 2025. Swift's cross-border payment channel ended MT/ISO 20022 coexistence and moved fully to ISO 20022 processing^[6].

3. The G20 Roadmap and CPMI's Role

The traditional cross-border payment system has long faced four problems: high cost, slow settlement, limited transparency, and difficult access. In 2020, G20 finance ministers and central-bank governors endorsed the G20 Roadmap for Enhancing Cross-Border Payments, prepared by the Financial Stability Board (FSB) and CPMI. The roadmap identifies fragmented message formats as one reason for inefficient Straight-Through Processing.

To address information barriers across systems, CPMI and the Payments Market Practice Group (PMPG) published the Harmonised ISO 20022 Data Requirements for cross-border payments in 2023^[7]. The document establishes a minimum baseline for data exchanged across systems and calls for economies to achieve complete, lossless end-to-end business-data transmission by the end of 2027. In February 2026, CPMI issued an updated version that further clarified the field structure for correspondent-banking and cross-border fast-payment linkages.

V. If Everyone Uses ISO 20022, Why Does Cross-Border Payment Fragmentation Remain?

Once major financial centres and Swift have adopted ISO 20022, it is natural to ask whether a common communications protocol can remove long-standing fragmentation in cross-border payments.

The reality is more complicated. Using the same technical standard does not mean applying the same business logic.

1. Seven Structural Layers of Fragmentation That Remain in Cross-Border Payments

In a multilateral payments and clearing ecosystem, friction remains even when every system claims ISO 20022 compatibility:

1. Message-version fragmentation: ISO 20022 continues to evolve, and a message such as pacs.008 has multiple historical versions. If a European system remains on one annual maintenance release while a system in the Americas adopts a newer release, intermediary layers still need message-conversion rules, preventing fully seamless connectivity.
2. Market-practice fragmentation: Swift uses CBPR+, national large-value systems follow their own HVPS+ guidelines, and Fast Payment Systems (FPS) often use independent lightweight rules. These may all belong to the ISO 20022 family, but the rules applied to the same message can differ considerably.
3. Field-rule divergence: a beneficiary's legal identifier, such as an LEI, may be mandatory in System A, where an omitted value fails validation, but optional in System B. When a transaction is routed from System B to System A, a missing mandatory field can interrupt processing.
4. Regulatory and compliance-data fragmentation: Anti-Money Laundering (AML), Countering the Financing of Terrorism (CFT), sanctions-screening rules, and the Travel Rule are independently determined under domestic law. Jurisdictions have incompatible requirements for the granularity of beneficial-owner identification. A standard can carry the relevant data; it cannot eliminate differences in sovereign compliance requirements.
5. Fragmented exception and return workflows: clearing operating hours, end-of-day batch processing, payment-cancellation mechanisms, definitions of recourse, and return-fee rules follow local practices. A common format does not remove the timing gap between business customs and clearing rules.
6. Infrastructure interlinking deficit: two payment systems may both use ISO 20022 without having a direct interface or dedicated connection between them. Commercial banks still rely heavily on chains of correspondent banks worldwide to route payments.
7. Settlement-asset fragmentation: this is the deepest boundary in the monetary system. USD payments ultimately settle on Federal Reserve reserve ledgers, EUR payments on European Central Bank reserve ledgers, and CNY payments in the People's Bank of China's large-value payment system. Cross-currency transactions necessarily involve FX liquidity, exchange-rate risk management, and FX settlement risk. See "# What Is the Most Dangerous Moment in FX? Why PvP Is the Market's "Payment-versus-Payment"".

2. What Else Is Needed for Genuine Interoperability?

ISO 20022 reduces the communication loss that occurs when institutions use different data languages. Reducing overall friction in cross-border payments requires further coordination across financial infrastructure:

• Moving from format harmonisation to data harmonisation: payment participants cannot simply wrap their messages in XML. They need to follow CPMI's harmonised data requirements so that structured names, addresses, and entity identifiers can pass losslessly from the first pain message through to the recipient, without being compressed or truncated.
• More consistent market-practice guidelines: national HVPS+ rules and CBPR+ should remove unnecessary differences and converge on more common practices.
• Payment-system interlinking and real-time pre-validation: before a message is sent, application programming interfaces (APIs) can verify in real time that the beneficiary name and account match. Cross-border fast-payment systems can also connect through gateways, reducing dependence on long correspondent-banking chains.
• Stronger Payment versus Payment (PvP) settlement mechanisms: financial market infrastructures such as Continuous Linked Settlement (CLS) can ensure that both currency legs of a cross-border transaction settle synchronously and irrevocably on their respective central-bank ledgers, isolating cross-time-zone settlement risk.

ISO 20022 standardises the basic vocabulary of global financial messaging. Cross-border payments still face a multi-dimensional governance challenge involving data, rules, communications networks, regulatory law, and central-bank money settlement arrangements.

VI. Conclusion

After years of preparation, large-value settlement systems and cross-border messaging networks in major economies have moved to the new standard, and the MT-message coexistence period for cross-border payments has ended.

One stage has closed, but a more consequential phase of governance has begun: can the global financial system use this common language through consistent rules, consistent data standards, and uninterrupted business processes?

ISO 20022 matters because it provides financial services with an end-to-end data model, from customer initiation and interbank routing to central-bank clearing and settlement and end-of-day account reconciliation.

To understand the evolution of next-generation financial market infrastructure, attention needs to shift from an individual message format to the broader information ecosystem. Three questions are worth following:

1. Can business data move end to end in a structured, lossless form?
2. Are frictions between national market-practice guidelines and regulatory rules shrinking?
3. Can shared data standards deliver genuine interoperability between infrastructures?

References

[1]: ISO 20022 Registration Management Group. About ISO 20022. Available at: https://www.iso20022.org/about-iso-20022 ↩

[2]: International Organization for Standardization. ISO 20022: Financial services — Universal financial industry message scheme. Available at: https://www.iso20022.org/iso-20022-standard ↩

[3]: ISO 20022 Standards Evaluation Groups. ISO 20022 Standard Maintenance Process. Available at: https://www.iso20022.org/iso-20022-standard-maintenance-process ↩

[4]: Bank for International Settlements, Committee on Payments and Market Infrastructures. The future of financial messaging: navigating the ISO 20022 migration journey, CPMI Brief 11, February 2026. Available at: https://www.bis.org/cpmi/publ/brief11.pdf ↩

[5]: Federal Reserve Bank Financial Services. Fedwire Funds Service ISO 20022 Implementation Final Phase. Available at: https://www.frbservices.org/news/fed360/issues/071625/wires-iso-20022-implementation-complete-fedwire-funds-service ↩

[6]: Swift. ISO 20022: A new era in global payments. Available at: https://www.swift.com/news-events/news/iso-20022-new-era-global-payments ↩

[7]: Bank for International Settlements, Committee on Payments and Market Infrastructures & Payments Market Practice Group. Harmonised ISO 20022 data requirements for enhancing cross-border payments, CPMI Updated Report, February 2026. Available at: https://www.bis.org/publications/harmonised-iso-20022-data-requirements-enhancing-cross-border-payments-updated-report ↩

Originally published by Luminale Fintech Observer: https://luminale.cn/articles/what-is-iso-20022-common-language-payment-infrastructure-en