Part 1: How native ISO 20022 orchestration solves the structured address mandate
When Swift agreed to community requests to extend the structured address deadline, originally set for November 2026, many financial institutions slowed or paused their plans.¹ A new date has yet to be confirmed.
The extension gives legacy core systems some breathing room. But pausing comes at a cost. As of July 2026, more than half of payment messages on the Swift network still contain unstructured, free-text addresses.² Each one is a potential manual repair, sanctions false positive or downstream rejection.
Institutions that use this time to fix the underlying problem, rather than maintaining temporary translation layers, will lift straight-through processing (STP) rates, cut manual repair work and build a real edge in cross-border payments. Those that wait will keep treating rich payment data as an operational burden instead of a strategic asset.
What's actually changing?
The ISO 20022 envelope is already in place. Following the end of MT and ISO 20022 coexistence in November 2025, 97% of cross-border payment instructions are now sent as ISO 20022 messages, with the remaining 3% relying on Swift's translation services, according to figures shared at EBA Day 2026.³ But sending a message in the right envelope isn't the same as using what's inside it.
Addresses are the clearest example. Historically, a full customer address was squeezed into three or four lines of free text. Under the new rules, that free text gives way to dedicated fields:
- Unstructured (being retired): everything sits in raw text lines, for example "32 Main Street, Suite 400, London, EC1A 1BB, UK".
- Structured (new way): each element has its own field, such as building number, street name, postcode, town and country.
- Hybrid (also permitted): town and country must sit in dedicated fields, with up to two lines of free text for the rest. This is intentional, as not every address in the world fits neatly into a fixed structure.
Why ‘ISO shims’ create technical debt
To meet the deadline, many institutions placed an ISO 20022 translation layer, or "shim", over their existing architecture. It secured day-one compliance, but left the underlying data model unchanged.⁴ That creates three problems:
- Data truncation: legacy cores typically store addresses as flat text lines. When a detailed ISO 20022 message arrives, anything that doesn't fit gets cut off. When that payment is forwarded, the missing data can trigger a rejection further down the chain.
- Sanctions screening noise: screening engines that parse blocks of free text often flag street names or postcodes that happen to resemble sanctioned entities. Structured fields let screening tools check the right attribute in the right place, reducing false positives.⁵
- Dependence on vendor release cycles: changing hard-coded schema mappings in legacy middleware means custom code, so your roadmap can only move as fast as your vendor's next release.
This matters beyond compliance. Swift reports that around 80% of markets now process cross-border payments faster than they did two years ago. But it stresses that technology alone won't meet the G20 targets for faster, cheaper and more transparent payments: "last mile" processing inside banks has to change too.⁶
The solution: flexible payment orchestration
Solving the structured address mandate permanently requires decoupling orchestration logic from legacy core banking databases.
Vault Payments natively supports the full ISO 20022 data set, including structured and hybrid addresses, across every payment rail. More importantly, it lets you put that data to work:
- Python-based workflow logic: build, change and deploy payment flows on demand via API using standard Python, so your team owns orchestration instead of waiting for vendor releases.
- Configurable integrations: run sanctions screening, risk checks and data lookups as configurable steps within each flow, for example fetching and populating missing address details before a message fails validation.
- Compliance once, across rails: support Swift CBPR+, FedNow, T2 and regional instant payment schemes on a single platform. When other schemes adopt structured addresses, you won't have to start again.
Don't wait for the next mandate
Structured addresses won't be the last change. Swift has already confirmed the next one: from November 2027, cross-border Exceptions & Investigations (E&I) messages must move to dedicated ISO 20022 formats and be routed through its new Case Management service.
Banks that replace temporary fixes now will cut operating costs and give corporate clients faster cross-border payments. Banks that delay will keep paying for workarounds, and face the same problem again with every new mandate.
In Part 2, we look at what the E&I migration means in practice, and how to get ahead of it.
Ready to turn ISO 20022 compliance into a competitive advantage?
Reach out to our team.
References
- https://www.Swift.com/news-events/news/Swift-accepts-community-request-extend-structured-address-migration-iso-20022-payment-messages
- https://www.Swift.com/standards/iso-20022/removal-unstructuredaddress#wherearewetoday
- https://www.finextra.com/newsarticle/47943/ebaday-2026-iso-20022-and-the-evolving-global-payments-ecosystem
- https://www.thoughtmachine.net/blog/to-be-iso-20022-ready-is-not-good-enough
- https://www.Swift.com/standards/iso-20022/iso-20022-faqs/Swift-ai-address-structuring-model
- https://www.Swift.com/payments/g20-goals-enhancing-cross-border-payments
