If ISO 20022 were a person, it would be old enough to drink*. Introduced in 2004, the transition to improve international payment messaging has been so long and complex that it feels never-ending.
But the shift is reaching a critical point. By 22 November 2025, the coexistence period for MT (Message Type) and MX (Message Exchange) messages will end**. From then on, banks need to be able to process MX messages, which contain much richer data. Non-compliance may result in failed payments, operational inefficiencies, regulatory scrutiny, and reputational damage.
Now, many banks have already transitioned. But many more have yet to make the switch.
And unfortunately, more work is ahead for everyone.
A change of address
After November 2025, banks will need to prepare for yet another major shift: structured addresses.
Starting November 2026, unstructured postal addresses will no longer be supported in CBPR+ messages. From this point on, swift, and payment schemes, such as SEPA and CHAPS, will begin rejecting transactions with unstructured data. Banks need to adopt either a fully structured or hybrid address format to become compliant. Neglecting this may lead to payment failures, processing delays, higher costs, false compliance hits, and increased scrutiny from regulators and correspondent banks.
The benefits are far-reaching. Structure will bring clarity and precision to payments, improving financial crime compliance, sanctions screening, and processing speed.
But there are big, expensive hurdles to overcome first. Namely, updating libraries of messy customer data.
Common language, local dialects
To illustrate, let’s start with the problem: unstructured addresses. Free-text fields in MT messages have no predefined structure. The entire message is lumped into one box, without a clear or specific space for street name, city or postcode. They look something like this:
:59:/123456789 JOHN DOE 123 MAIN STREET, APT 4B SPRINGFIELD, NY 10001 USA
Hard to read and automate, unstructured addresses lead to inconsistencies, errors, and difficulty processing payments.
Now consider the ISO 20022 Structured Address element, which includes fields for specific address data. Unlike unstructured addresses, these are clear, quick and machine-readable:
- Street Name ()
- Building Number ()
- Floor ()
- Postcode ()
- Town Name ()
- Country ()
Now, it looks good on paper. But address formats differ across regions. In the West, for example, we prefer a bottom-up approach, which starts with a house number or name and ends with a postcode (House>Street > City > State > Country). In the East, a top-down approach is the norm (Country > State > City > House>Street). In some countries, such as Hong Kong and Somalia, there are no postcodes. And in others, like India and Kenya, addresses often include landmarks to help identify a location (e.g., “near City Mall, opposite the bus stop”). Unstructured, free-text fields could accommodate these differences. Structured Addresses cannot.
So, this is where hybrid addresses come in. A hybrid address combines both structured and unstructured elements, to allow for differences in address formats. This makes them more flexible than structured addresses.
- Address Line (Unstructured free-text field)
- Town/City Name (Structured)
- Country Code (Structured)
Lost in translation
The trouble is that many corporate Enterprise Resource Planning (ERP) and Treasury Management Systems (TMS) use free-text or semi-structured fields for address information. That means corporates and their payment service providers have big databases filled with customer and counterparty addresses in an unstructured format. All of which need updating to meet compliance.
But updating these legacy systems and databases is a huge task. One that’s particularly painful for banks and large multinationals with extensive payment networks. Converting years of historical data to a structured or hybrid format could cost millions in IT infrastructure upgrades and operational costs. What’s more, banks will need to invest in training staff to ensure the migration is handled efficiently. Most of the heavy lifting needs to be done in 2025 and 2026. The cost of in-action will be a far bigger burden.
Addressing the future
So, what should banks do? As with all regulations, start early. Plan carefully.
First, review and migrate your existing address data to a more structured format. This will involve mapping unstructured fields (e.g., street names, landmarks) into the defined fields in the structured address element. You can use AI-based address normalization tools or address validation software to help automate the conversion process.To futureproof this work, transition to fully structured addresses where possible. Hybrid addresses will continue to be permitted beyond 2026. But that could change in the future. As the migration progresses and systems become fully compliant with ISO 20022, the preference may shift toward fully structured addresses in years to come. You don’t want to do this work twice.
Then, upgrade your ERP and TMS systems to support ISO 20022. This is essential. For many, this will involve updating databases to accommodate both structured and hybrid address formats. Consider optimizing related processes like KYC and customer onboarding. By capturing address data in a structured format from the start, you increase your chances of seamlessly integrating with modern ERP systems, improving data accuracy and compliance while streamlining operations. Some vendors may offer specialized solutions to ease the transition.
If you’re stuck, do some reading. The payments community, led by swift, is helping banks with resources and guidelines. You can access test environments to check compliance and get updates on regulatory frameworks that will govern the transition.
Finally, speak to RedCompass Labs. We’ve been supporting banks with the ISO 20022 transition for years. Our FastStart accelerator can help you meet the 2025 deadlines in as little as six weeks. And our deep payments, technology and AI expertise can help you from then and beyond.
*In most countries.
**Categories 1, 2 and 9
Share this post
Written by

Pratiksha Pathak
Head of Payments, RedCompass Labs

Praveen Bhosale
Consulting Manager, RedCompass Labs
Resources