In plain words
Think of an old paper form with one big box that says “details”. Everyone fills it in differently, and the person reading it has to guess what each line means. ISO 20022 replaces that box with a proper form: separate fields for the name, the street, the town, the country, the reason for the payment and the invoice number, each with a fixed meaning.
ISO 20022 is an international standard for financial messages, published by the International Organization for Standardization. 1 It does not move money. It defines the language that banks and payment systems use to tell each other what to move, to whom and why. Because so many systems now speak this same language, a payment can carry the same structured information from the customer’s app all the way to the recipient’s bank.
For a founder, this matters less as a technical format and more as a data promise. Your partners now expect clean, structured details with every payment, and they can give you richer information back.
How it works
How ISO 20022 messages follow a payment
Different message types cover each stage, and they share the same data and references.
-
1
The customer asks to pay: pain.001
A business or provider sends its bank a payment initiation message with the payer, payee, amount and remittance details.
-
2
Bank pays bank: pacs.008
The bank sends a pacs.008 to the next bank, carrying the same structured details and a unique reference such as the UETR.
-
3
Status comes back: pacs.002
Banks report whether the payment was accepted or rejected, with a coded reason. Returns use pacs.004.
-
4
The account is reported: camt.053 and camt.054
Statements and credit or debit notifications tell the account holder what moved, with the original references, ready for reconciliation.
The message families you will meet
Message names follow a pattern: a four-letter family, then a number. You do not need to learn them all, but these come up in almost every payments project.
| Family | What it covers | Common examples |
|---|---|---|
| pain | Payment initiation, between a customer and its bank | pain.001 to send a payment, pain.008 to collect a direct debit |
| pacs | Payments clearing and settlement, between banks | pacs.008 customer payment, pacs.009 bank-to-bank payment, pacs.002 status, pacs.004 return |
| camt | Cash management, reporting and exceptions | camt.053 statement, camt.054 notification, camt.056 request to cancel |
The older MT103 did the job of pacs.008 on SWIFT, but with a handful of short text fields. ISO 20022 messages are usually written in XML and have far more room, which is why people describe them as carrying “richer” data.
Why richer data matters
With structured data
- Sanctions screening compares a real name and country, so fewer false alarms stop payments
- Invoice numbers and references arrive intact, so payments match to invoices automatically
- Rejections come with coded reasons your product can show the customer
- Purpose codes help banks and regulators understand what a payment is for
With messy data
- Payments are held while a person checks a name that was cut short
- Remittance details are truncated, and finance teams match payments by hand
- Banks in the chain send questions back, adding days
- Payments are returned for missing or unstructured addresses
The standard only helps if the data going in is good. If your onboarding stores a customer’s address as one free-text line, no message format can split it into street, town and country later. Collect data in the structure your partners need from the first version.
The same applies to what comes back. A rejection code or a statement entry is only useful if your ledger keeps the original references and links them to the right customer and transaction. Teams that store only an amount and a date end up matching payments by hand, however good the incoming data is.
For a deeper look at what this changes in cross-border products, read SWIFT, ISO 20022 and the future of cross-border fintech products.
Where ISO 20022 is used: UK, EU and the Gulf
Adoption has happened system by system over almost two decades.
| System | Region | Status |
|---|---|---|
| SEPA schemes | EU and wider Europe | Built on ISO 20022 from the start |
| T2 | Euro area | Moved to ISO 20022 in March 2023 |
| CHAPS | United Kingdom | Moved to ISO 20022 in June 2023, with richer data requirements phased in since 3 |
| Faster Payments and Bacs | United Kingdom | Still use older formats; Pay.UK plans to move them as it modernises its systems |
| SWIFT cross-border payments | Global | Standard since November 2025, when coexistence with MT messages ended 2 |
| Gulf payment systems | UAE, Saudi Arabia, GCC | Several national and regional systems, including newer platforms such as Buna, use or are moving to ISO 20022. Versions and timelines differ, so confirm with your partner bank. |
Example: a payroll payment that matches itself
Karim runs operations at a payroll startup that pays contractors in the UK and Europe through a payment provider’s API.
- Collecting data. When a contractor signs up, the app asks for their address in separate fields and checks the IBAN format before saving.
- Sending. The provider turns each payout into a pain.001, then a pacs.008, with the contractor’s structured address and an invoice reference.
- A rejection. One payment comes back with a pacs.002 reason code for a closed account. The app shows the contractor a clear message and asks for new details.
- Reconciling. Next morning, the camt.053 statement lists every payout with its reference. The back office matches them automatically and flags the one return.
Common misconceptions
“ISO 20022 is a new payment network.”
It is a message standard. Existing networks such as SWIFT, SEPA and CHAPS use it to carry their messages.
“It is only a problem for banks.”
Banks build the messages, but the data comes from your product. Missing or messy data causes delays and returns for your customers.
“Every system uses the same version.”
Each system publishes its own usage rules and versions, so a message valid in one system may need changes for another.
FAQ
What is ISO 20022 in simple terms?
It is a common language for financial messages. It defines what each piece of payment information is called, where it goes and what format it takes, so that different banks and systems can read each other's messages without guesswork.
Is ISO 20022 a payment system?
No. It is a message standard. Payment systems such as SEPA, CHAPS, T2 and SWIFT use it to carry their instructions, but the standard itself does not move money.
What is the difference between MT and ISO 20022 messages?
MT messages are the older SWIFT formats, with short, mostly free-text fields. ISO 20022 messages, sometimes called MX, have many more fields and structure the data, for example splitting an address into street, town and country.
What is pacs.008?
pacs.008 is the ISO 20022 message one bank sends another to pay a customer's money to a customer at the other bank. It replaced the MT103 for cross-border customer payments on SWIFT.
Why does ISO 20022 matter for fintechs?
Your partners now expect structured, accurate data with each payment. If your product collects names, addresses and payment purposes properly, payments are screened faster, rejected less often and reconciled automatically.
Do I need to build ISO 20022 messages myself?
Usually not. Most fintechs send payments through a bank or payment provider's API, which builds the messages. You still need to collect the data those messages require.
Sources
-
1
I
ISO 20022 ISO 20022: universal financial industry message scheme
https://www.iso20022.org/ -
2
S
Swift ISO 20022 at Swift
https://www.swift.com/standards/iso-20022 -
3
BO
Bank of England Payment and settlement
https://www.bankofengland.co.uk/payment-and-settlement
