Banks that came through the end of Swift’s coexistence period in November 2025 might reasonably feel the hardest part is behind them, and the news that the structured address requirement has been deferred may well have taken some of the urgency out of the conversation. Swift is still consulting on timing and has said it will confirm the approach before the end of 2026, but the requirement itself has not changed, and the translation tools that many institutions have leaned on so far were never built to meet the standard that this next phase demands.
The readiness gap
To bridge legacy systems and ISO 20022, a large share of banks turned to translation tools as a sensible short term fix, and 65% of the banking IT leaders we surveyed are still relying on them today. The difficulty is that these tools change the format of a message without improving the data inside it, so address information that sits in legacy systems as free text, with fields missing or inconsistently entered, carries that same weakness straight into the ISO 20022 message.
What the deferral actually changes
Swift has deferred all payments changes and is consulting with banks, central banks, payment market infrastructures and market practice groups to define the optimal timing and approach for the address requirement, with an update expected by the end of this year. What has not changed is the destination, because once the requirement takes effect, payments carrying fully unstructured addresses will be rejected at the validation stage rather than repaired further down the line, and Swift has been clear that the decommissioning of unstructured addresses is being rescheduled rather than abandoned.
Nothing is stopping you starting now
Structured and hybrid addresses are already supported across the Swift network today, so any remediation work a bank completes can be deployed immediately rather than held back waiting for a date to be published. That matters because the work involved is data remediation across customer and counterparty records rather than a messaging change, and it is the kind of programme that takes quarters rather than weeks once the scale of the legacy estate becomes clear.
The bigger picture
The move to structured addresses is not an isolated rule change, and it reflects a wider industry shift towards higher quality, standardised payment data that aligns with initiatives such as the G20 Cross Border Payments Roadmap and FATF Recommendation 16. By enforcing defined fields for the core components of an address, Swift is building a more consistent foundation for payments, one that supports greater straight through processing, more accurate sanctions and AML screening, clearer transparency for every party in the chain, and a higher level of automation across operations.
How Aquila solves it
Aquila treats address data as something to be validated and enriched before a message is ever created, through its native ISO 20022, rather than something to be reformatted on the way out, which is the difference between a message that passes validation and one that merely looks like it should. It integrates with core systems through APIs, sits alongside whatever core banking platform a bank already runs without replacing it, and brings payments, treasury, securities, reconciliations, matching and reporting together so that the same quality controls apply across the whole flow.
Stat callouts
65% of the banking IT leaders we surveyed still rely on translation tools
72% say richer data requirements have exposed structural gaps in their data
Deadline deferred, approach to be confirmed by Swift before the end of 2026
If you would like to talk through where your address data actually sits today, and what a remediation programme looks like before the new timeline is published, we would be glad to have that conversation.
