Every bank transfer is, underneath, a structured message passed between institutions: who is paying, who is being paid, how much, in what currency, and why. For decades, cross-border payments used Swift's MT messages, compact formats with short, loosely structured text fields. ISO 20022 replaces them with a much richer, structured standard, and it has now become the norm: Swift's coexistence period for cross-border payment instructions ended on 22 November 2025, and India's RTGS system has been built on ISO 20022 since 2013.
Most businesses never see an ISO 20022 message directly; their bank or payment provider does. But the standard shapes what data travels with a payment, what can go wrong with it, and how easily it can be reconciled. This guide explains the standard for finance, treasury and engineering teams.
What ISO 20022 is
ISO 20022 is an international standard for financial messaging. It isn't a single message format but a methodology and a shared repository: business processes and data elements are modelled once, and message definitions are generated from that model, most commonly in XML. The same dictionary of elements, such as a debtor, a creditor, an amount or a remittance reference, is reused across messages, so data means the same thing everywhere it appears.
Payments are only one of its business domains; it also covers securities, trade services, foreign exchange and cards. In payments, it's used for customer-to-bank instructions, bank-to-bank clearing and settlement, and bank-to-customer reporting.
Reading a message name
ISO 20022 message names follow a fixed pattern. Take pacs.008.001.08:
| Part | Example | Meaning |
|---|---|---|
| Business area | pacs | Payments clearing and settlement (bank to bank) |
| Message functionality | 008 | Which message within the area: here, a customer credit transfer |
| Variant | 001 | The variant of that message (001 for the base message) |
| Version | 08 | The version, which changes as the message evolves |
The business areas payments teams meet most are pain (payment initiation, customer to bank), pacs (clearing and settlement, bank to bank), camt (cash management: statements, notifications, investigations) and acmt (account management). Different market practices, such as Swift's cross-border usage guidelines or a domestic scheme's rules, use particular versions and restrict how fields are used.
The messages you're most likely to meet
A short field guide, with the MT messages they replaced where there was a direct equivalent:
| Message | What it does | Typical sender → receiver | Replaces (cross-border) |
|---|---|---|---|
| pain.001 | Customer credit transfer initiation: instruct the bank to pay | Business → its bank | MT101 (in part) |
| pain.002 | Status report on an initiation | Bank → business | — |
| pain.008 | Direct debit initiation | Business (creditor) → its bank | — |
| pacs.008 | Customer credit transfer between banks | Bank → bank | MT103 |
| pacs.009 | Financial institution credit transfer | Bank → bank | MT202 / MT202 COV |
| pacs.002 | Payment status report | Bank → bank | — |
| pacs.004 | Payment return | Bank → bank | MT103 return usage |
| camt.053 | Bank-to-customer account statement | Bank → business | MT940 / MT950 |
| camt.054 | Debit or credit notification | Bank → business | MT900 / MT910 |
| camt.052 | Intraday account report | Bank → business | MT942 |
| camt.056 | Request to cancel a payment | Bank → bank | MT192 / MT292 |
What changed from MT103
The headline is richer, structured data. An MT103 carried the payer, payee and purpose in a handful of short text fields, often truncated and free-format. A pacs.008 carries the same information in dedicated, structured elements:
| Data | MT103 | ISO 20022 |
|---|---|---|
| Names and addresses | Free text in a few short lines | Structured elements: street, building, post code, town, country |
| Remittance information | Four lines of 35 characters | Unstructured text or structured references to invoices and documents |
| References | Sender's reference | Instruction ID, end-to-end ID passed unchanged to the payee, transaction ID and UETR |
| Parties | Ordering and beneficiary customer | Also ultimate debtor and ultimate creditor, and legal entity identifiers |
| Purpose | Free text if any | Purpose and category purpose codes |
Two of these matter most for businesses. The end-to-end ID you set when you initiate a payment travels with it to the payee's bank and statement, so both sides can match it automatically. And structured remittance information means the invoice numbers a payment settles can arrive intact rather than truncated.
What a message looks like
Here's one transaction from a customer credit transfer initiation, abridged. Real messages carry a group header and payment information around it, and each bank publishes an implementation guide saying exactly which elements it requires.
<CdtTrfTxInf>
<PmtId>
<EndToEndId>INV-2026-0042</EndToEndId>
</PmtId>
<Amt>
<InstdAmt Ccy="EUR">1250.00</InstdAmt>
</Amt>
<CdtrAgt>
<FinInstnId>
<BICFI>BANKDEFFXXX</BICFI>
</FinInstnId>
</CdtrAgt>
<Cdtr>
<Nm>Example Supplies GmbH</Nm>
<PstlAdr>
<StrtNm>Hauptstrasse</StrtNm>
<BldgNb>12</BldgNb>
<PstCd>60311</PstCd>
<TwnNm>Frankfurt am Main</TwnNm>
<Ctry>DE</Ctry>
</PstlAdr>
</Cdtr>
<CdtrAcct>
<Id>
<IBAN>DE89370400440532013000</IBAN>
</Id>
</CdtrAcct>
<RmtInf>
<Ustrd>Invoice INV-2026-0042</Ustrd>
</RmtInf>
</CdtTrfTxInf>Note that amounts in ISO 20022 messages are decimal values with a currency attribute, not integers in minor units as most payment APIs use. Conversions between the two belong in one well-tested place; our guide to storing money in code explains why.
Key dates
ISO 20022 has been adopted system by system rather than all at once:
- 19 Oct 2013RBI launches India's new RTGS system, built on ISO 20022 messaging standards.
- 20 Mar 2023Swift begins the coexistence period for cross-border payments and reporting (CBPR+): MT and ISO 20022 both supported.
- 22 Nov 2025Coexistence ends for cross-border payment instructions on Swift; remaining MT instructions are converted under chargeable contingency processing or rejected, depending on the message type.
Other systems run their own schedules, and some domestic rails use other formats entirely, so check the specification of each rail you connect to rather than assuming ISO 20022.
What it means for businesses
You don't need to write XML to benefit from ISO 20022, but you should act on it:
- Send better data. Structured names and addresses, and accurate payee details, reduce rejections and compliance holds on cross-border payments. Ask your bank which elements it now requires.
- Set a meaningful end-to-end ID on every payment you initiate, such as your invoice or payout reference, and keep it in your own records. It's what comes back on the payee's side and on your statements.
- Use structured remittance where you can, so customers paying you, and suppliers you pay, can match payments to invoices automatically.
- Move statement processing to camt.053 and camt.054 if your bank offers them; they carry more detail than MT940 and plain-text statements.
- Feed the richer references into reconciliation. Our payment reconciliation guide explains why references are everything.
What it means for payment platforms
For anyone building payment systems, ISO 20022 is mostly a mapping problem done well once. Map your internal payment model to the messages your banks and providers use, preserve end-to-end IDs and UETRs on your records so payments can be traced across institutions, validate data against the relevant usage guidelines before submission rather than after a rejection, and keep the mapping inside a connector so scheme updates don't ripple through your system. Our guide to payment orchestration architecture shows where that boundary sits, and our cross-border payments guide covers international B2B payments more broadly.
Frequently asked questions
What is ISO 20022 in simple terms?
A global standard for the messages banks and payment systems exchange, such as payment instructions, statements and status reports. It defines a shared dictionary of financial data, so messages carry richer, structured information than older formats.
Is MT103 still used?
Not for cross-border payment instructions between financial institutions on Swift: the MT and ISO 20022 coexistence period ended on 22 November 2025, and the ISO 20022 equivalent of MT103 is pacs.008. Some MT messages sent after that date are converted under chargeable contingency processing and others are rejected.
What is the difference between MT and MX messages?
MT messages are Swift's older, compact formats with short text fields. MX is the common name for Swift's ISO 20022 messages, which are XML-based and carry structured, richer data such as full addresses, end-to-end references and structured remittance information.
What is camt.053?
The ISO 20022 bank-to-customer account statement, typically sent at the end of each day. It replaces MT940 and carries detailed transaction information, including the references payers set, which makes automatic reconciliation easier.
Does India use ISO 20022?
India's RTGS system has used ISO 20022 messaging since RBI launched the new RTGS in October 2013. Other Indian payment systems have their own specifications, so check the rail you're connecting to.
Official sources
- Swift — ISO 20022 for financial institutions: focus on payments instructionsEnd of MT/ISO 20022 coexistence for cross-border payment instructions on 22 November 2025; treatment of MT messages after that date.
- Swift — ISO 20022 coexistence begins, opening new possibilities for cross-border paymentsCoexistence for CBPR+ began on 20 March 2023.
- Swift — Global financial community completes switch to ISO 20022 (press release)
- RBI — RBI Governor launches new ISO 20022 compliant RTGS System (press release, 19 Oct 2013)
- ISO 20022 — Message definitions catalogue
Last reviewed . Examples, amounts and screens marked illustrative are not LILPE figures.
