ISO 20022 migration
ISO 20022 is an international standard for the financial messages that organizations exchange when handling payments and other financial transactions. The standard gives information such as payer identity and payment references a defined structure. Migration means adapting systems and working processes to send, receive and use those structured messages.
Banks use ISO 20022 to exchange payment data in a format that their systems can process consistently. Structured fields can improve sanctions screening and help accounting systems match incoming money to an invoice. Those benefits depend on the data supplied and how the bank's systems validate and use it.
What a pacs message carries that an MT did not
A customer credit transfer used to travel as an MT103, a message with numbered fields and a lot of free text inside them. Field 50 held the ordering customer: name, address and account, in up to four lines, written however the sending bank chose. The ISO 20022 equivalent is a pacs.008, and there the debtor has a name element, a postal address with street, building number, ZIP code, town and country, and an account identification of its own.
Two more differences count in daily operations. The remittance information can be structured, with references a creditor system can read directly, and the message carries more of it. The end-to-end reference travels unchanged through the chain, which makes it possible to track the payment.
CBPR+ and the end of MT for cross-border payments
CBPR+ is the set of market practice guidelines that says how banks use ISO 20022 for cross-border payments and reporting. Without such guidelines the standard is too flexible: two banks could both be compliant and still be unable to process each other's messages. CBPR+ narrows that down to one usage.
The MT messages for cross-border payments have been retired on the Swift network, which ended the period in which a bank could receive either format and translate. A bank that still runs translation in the middle of its own stack has not completed its migration because the data a translator drops is exactly the data the structured fields were added for.
The structured address requirement and what it breaks
The Swift community decided to move from unstructured to structured postal addresses for payment messages, and set November 2026 for the switch. In August 2026 Swift extended that deadline after communities and market infrastructures asked for more time. The Swift notice on the extension states that progress across the industry was uneven, and the new date banks are now planning against is November 2027, as the migration resource center at J.P. Morgan sets out for its clients.
What the rule actually requires is a hybrid address at minimum, not a fully structured one: town name and country have to sit in their own elements, and up to two address lines of 70 characters may carry the rest, as long as they do not repeat what the structured elements already hold. A fully unstructured address stops being accepted. That distinction decides how much data work a bank has to do.
The delay reflects the need to clean up customer address data. A bank's customer master holds addresses as free text that was never parsed into a street, a number and a postcode, and in many cases the components cannot be recovered without asking the customer. The work is a data cleanup in the core banking system, which is why it takes longer than the message mapping. Read about the systems involved in this work under core banking in Germany.
Which message families go when
The migration runs as a set of separate retirements, and a bank tracks them per message family. Payment initiation moves from MT101 to pain.001 by November 2027, the same horizon as the address rule. Account reporting is a later step: the MT 9xx statements and notifications, which means MT940, MT941, MT942, MT900 and MT910, are set for decommissioning in November 2028, with camt.052 for the intraday report, camt.053 for the statement and camt.054 for the debit and credit notification taking their place.
Inquiry messages also change: an unstructured MT199 inquiry about a missing payment gives way to camt.110 and camt.111, structured inquiry and investigation messages, with camt.056 for a cancellation and camt.029 for the resolution. A bank that keeps answering investigations in free text keeps the manual effort the structured flow was meant to remove.
What the richer data gives screening and reconciliation
A sanctions filter working on free text produces false positives, because a town name in a street field matches a name on a list. With a country element and a structured town, the filter compares like with like, and the number of alerts a compliance team has to clear by hand falls. Read about the controls for financial crime in payments and the requirements for sanctions compliance in Germany.
For corporate reconciliation, a payment that arrives with a structured creditor reference can be matched to an open invoice automatically, and the accounts receivable team only looks at the exceptions. That is the main argument for a treasury department to push its banks on the migration.
Where a European bank stands
European banks had a head start, because the euro high-value and instant systems moved to ISO 20022 before the cross-border migration. T2 settles in ISO 20022 messages, TIPS always did, and the SEPA schemes have used the standard since they started. A German bank therefore has the message formats in production and the question is the quality of the data it puts in the fields.
The remaining gaps sit in three places: addresses in the customer master, purpose and category codes that nobody fills, and reporting that still comes from an MT-shaped data model. The payment infrastructure used by these banks includes TARGET2 and TIPS.
What a corporate sending payment files has to change
A company that sends payment files to its banks is on the pain.001 side of the standard, and the same address requirement reaches it there. Three pieces of work follow: the supplier master needs structured addresses, the ERP has to produce them in the file, and the bank's validation rules have to be tested against real files before the deadline.
On the account statement, a camt.053 with structured remittance data closes the loop on reconciliation, and a treasury that asked for structured references on its outgoing payments gets matched returns on the incoming ones. These reconciliation tasks form part of the work of corporate treasury.
What is the ISO 20022 deadline?
Deadlines differ by payment system, and the MT retirement for cross-border payments on Swift has passed. The address requirement and the MT101 retirement move to November 2027 after the August 2026 extension, and the MT 9xx reporting messages follow in November 2028. National systems have their own calendars: the Federal Reserve migrated in July 2025, and the Bank of England made the richer data fields in CHAPS mandatory from May 2025. A bank tracks the deadline per system it connects to.
Is ISO 20022 the same as SWIFT?
ISO 20022 is an international standard for financial messages, published by ISO and used by payment systems that have nothing to do with Swift, including the SEPA schemes and T2. Swift is a network and a cooperative that carries messages between banks, and it has adopted ISO 20022 for cross-border payments in place of its own MT formats.
ISO 20022 and Finance Loop
Finance Loop is the meeting place for payment operations in Germany, and the migration is a data project in every bank that runs one. Finance Loop brings together the payment engineers mapping the messages, the compliance teams that gain from the structured fields, and the treasurers who have to change their own files.
Finance Loop is a professional network supporting the institutional use of emerging technologies in finance, such as AI, tokenization, stablecoins, and DeFi. Finance Loop helps its members build skills and personal networks in these fields: Investment & Digital Assets, Payments & Digital Money, Digital Infrastructure & Sovereignty, and Risk & Compliance.