Swift moved the date. It did not move the work.

What the SR2026 structured address extension means for banks and what to do with the time you just got back.

What happened 

Swift has agreed to extend the migration from unstructured to structured postal addresses in ISO 20022 payment messages. The requirement was due to land on 14 November 2026 as part of Standards Release 2026. After several communities formally asked for more time, Swift confirmed a controlled extension: all payments changes in SR2026 are deferred, while securities and trade changes proceed as planned. A revised timetable will follow consultation with banks, central banks, payment market infrastructures, market practice groups and corporates.

The reason is readiness, not doubt about the direction. Swift's own position is that progress remains uneven, with large parts of the industry across every region still unable to meet the requirement. Swift data from April showed roughly 61% of payments still carrying unstructured debtor address data and a similar share on the creditor side - this, after more than 98% of payment instructions had already moved to ISO 20022 following the end of MT coexistence in 2025.

That gap is the whole story. Format migration is done. Data migration has barely started.

What has not changed

Three things are worth being blunt about.

1.The requirement itself stands:

When the new date is set, fully unstructured addresses will still be rejected. Only structured or hybrid formats will be accepted, with town and country in their own designated fields rather than buried in free text.

2.Structured addresses already work today:

They have been supported since SR2025 and flow across the network without friction. Banks that finished the work early lose nothing - they are already collecting the benefit in screening quality and straight-through processing. Swift has been explicit in encouraging institutions and domestic market infrastructures to keep going.

3.Domestic deadlines are not automatically aligned:

Market infrastructures set their own timelines. An extension on the cross-border leg does not mean your domestic scheme, your regulator or your correspondent has moved with it. Confirm each one separately.

The real risk of this extension is organisational, not technical: a deferred deadline is the fastest way for a data remediation programme to lose its budget line and its steering committee slot.

The part most banks under-scoped

Almost every structured address programme we see is scoped as a messaging project. It is a customer data project wearing a messaging project's clothes.

The address in a pacs.008 is not created in the payments engine. It is created years earlier, at account opening, in a CRM screen, an onboarding form, a branch data entry field, a migrated legacy record or a corporate's ERP master. By the time it reaches the payment message, the damage is already done, and all the payments layer can do is fail or repair.

That is why readiness stalled. Mapping a field is a sprint. Cleaning twenty years of customer static data and closing the intake gaps that keep producing more of it is a programme.

Concretely, the scope runs across:

• Static data - customer and counterparty address records in the core banking system, with no reliable town/country decomposition and inconsistent country coding

• Origination - onboarding, KYC and account maintenance screens that still accept a free-text address block.

• Corporate channels - MT101 users needing field 59 option F, host-to-host and ERP-initiated flows and the move to pain.001 for payment initiation.

• Payment engine and gateway - mapping, validation, hybrid-versus-structured logic, truncation rules and rejection handling.

• Screening - sanctions and AML engines tuned on unstructured strings, whose hit and false-positive profile shifts once addresses arrive properly decomposed.

• Operations - repair queues, exception handling and the STP metrics nobody is currently measuring at address level.

How Wtilth helps

Wtilth works at the intersection of banking technology and payments standards - Temenos T24/Transact, ISO 20022, CBPR+ and the surrounding integration and quality estate. On structured addresses, our engagement usually takes one of four shapes.

1. Readiness assessment and data profiling

A short, evidence-based diagnostic rather than a questionnaire. We profile live address data across the core, CRM and payment repositories to establish what percentage of records can be structured automatically, what needs enrichment and what has to be re-collected from the customer. Output: a remediation volume, a cost and a defensible plan - the artefacts you need to keep the programme funded through an extension.

2. Data remediation and address structuring

Rules-based parsing plus machine learning to decompose free-text addresses into town, country subdivision and ISO 3166 country codes, with confidence scoring so that only genuinely ambiguous records reach a human. We build the exception queue, the reviewer workflow and the golden-record write-back, so remediation is a controlled pipeline rather than a spreadsheet exercise. Swift's own AI address structuring model sits in this space; we integrate to it or to an equivalent and wrap it in the governance a bank actually needs.

3. Functional and technical implementation

Temenos T24/Transact configuration and customisation for structured address capture and mapping, payment engine and gateway changes, CBPR+ message mapping for debtor, creditor and agent fields and the corporate channel uplift - MT101 field 59F, pain.001 adoption, host-to-host and ERP-side payment initiation. On the functional side, we redesign the origination and maintenance screens so the bank stops generating unstructured addresses at source. Without that, remediation is a one-off clean-up that decays from day one.

4. Quality engineering and assurance

This is where extensions are usually lost. We build CBPR+ regression packs covering structured, hybrid and negative cases, validate against Swift MyStandards, run screening impact analysis before go-live and put STP and repair-rate dashboards in place so improvement is measurable rather than asserted. Our quality engineering practice runs this as a standing capability, not a one-time test phase.

What to do in the next quarter

Whatever your new date turns out to be, four moves are safe:

• Profile your data now: You cannot plan a remediation you have not sized.

• Fix intake before backlog: Every week the origination screens stay unstructured, the backlog grows.

• Confirm domestic and correspondent timelines separately: Do not inherit the cross-border extension by assumption.

• Keep the programme visible: Convert the deadline - driven mandate into a data-quality business case: screening false positives, repair costs, STP rate. Those benefits are collectable before any deadline arrives.

Swift gave the industry breathing room. The institutions that use it to finish the data work will spend the next migration cycle collecting benefits. The ones that treat it as a reprieve will be in the same conversation again, with less time.

Wtilth Technologies Pvt. Ltd

Banking IT, Digital Engineering and Quality Engineering, with delivery presence across India, the UK, GCC and Africa. If you are scoping structured address readiness or an ISO 20022 remediation programme, we are happy to walk through what the assessment involves.

www.wtilth.com