58% Unstructured: Swift Delays ISO 20022

In July 2026, four months before the deadline, 58.3% of debtor addresses and 59.3% of creditor addresses crossing the Swift network were still fully unstructured free text. On 27 August, Swift gave up on the date. The mandate to retire unstructured postal addresses in ISO 20022 payment messages, due to bite on 14 November 2026, has been deferred with no replacement date attached.

That is the rare industry deadline that slipped not because the technology was late, but because the data was never collected in the first place. More than 98% of payment instructions already travel as ISO 20022 after the end of MT coexistence. The rails are done. The addresses inside them are not.

What Swift Actually Changed

Swift is applying what it calls a controlled extension to Standards Release 2026. Every payments change in that release is deferred, structured addresses included. The non-payments elements, which carry work tied to the T+1 settlement moves in several markets, have been decoupled so they can ship on their own timetable. Those are now targeted at Q1 2027, with an exact date promised by mid-September after stakeholder consultation. On the payments side, Swift will consult banks, central banks, market infrastructures and corporates, and publish an update by December 2026 at the latest.

The knock-on effects arrived within days. The Federal Reserve moved its planned November 2026 Fedwire Funds Service release to November 2027, with scope to be confirmed this autumn. U.S. Bank told customers it will not start rejecting wires on address formatting in November, and pointed ERP users at their software vendors. Domestic market infrastructures with dates aligned to the Swift one now each have their own decision to make.

So the correct mental model for anyone building payment initiation is not "the deadline moved." It is "the deadline fragmented." Swift's date is unknown, Fedwire's is November 2027, and individual correspondent banks are setting their own leniency in the meantime. Whatever you build to enforce address structure needs to be configurable per corridor and per counterparty, not a single global feature flag flipped on a date.

The Technical Detail the Announcements Skip

Most coverage describes this as "moving to structured addresses," which makes it sound like a serialisation choice. It isn't. The CBPR+ rules are specific enough that a naive implementation produces messages that are worse than the free text they replaced.

A fully structured PstlAdr block breaks the address into dedicated elements: StrtNm, BldgNb, BldgNm, Flr, PstBx, Room, PstCd, TwnNm, TwnLctnNm, DstrctNm, CtrySubDvsn, Ctry. Fully unstructured means the whole thing sits in repeating AdrLine elements. The compromise that most banks will actually ship is hybrid: TwnNm and Ctry are mandatory in their own fields, with Ctry carrying an ISO 3166-1 alpha-2 code, plus up to two AdrLine occurrences of 70 characters for anything that doesn't decompose cleanly.

Here is the constraint that catches teams out. If a component has a dedicated structured field, it must go there and must not also appear in an AdrLine. Putting "London" in TwnNm and again in a free-text line is not a slightly redundant hybrid address. It is malformed, and it can be rejected. The obvious implementation, parse what you can into fields and dump the original string into AdrLine as a safety net, is exactly the one that fails validation.

That single rule is why address migration is harder than it sounds. You cannot hedge. Every token you extract has to be removed from the free-text remainder, which means your parser needs to be confident enough about what it extracted to delete the source. Two 70-character lines is not much room for the leftovers of a badly captured Japanese or Brazilian address either.

Why the Data Isn't There

The industry decided on this migration in 2023. Three years is not a short runway for a schema change. The reason readiness stalled is that the missing data does not live in the payments stack at all.

TwnNm and Ctry have to be populated from somewhere upstream: an ERP vendor master, a treasury system, a customer onboarding record, a supplier form filled in by a human a decade ago. In most of those systems the address is one or more free-text lines, because nothing ever asked for more. PYMNTS Intelligence puts better ERP, treasury and accounting integration as the top payments priority for 29% of businesses turning over more than $25 million, which is a polite way of saying that the data model in the system of record and the data model on the wire have drifted apart.

I've watched this pattern play out in reconciliation work more than once. A field is captured as a display string, then years later somebody needs it as a queryable attribute, and the only honest fix is to go back to the point of capture. Retrofitting a parser in the middle of the flow buys you a plausible-looking output and a long tail of edge cases nobody owns.

My Read: This Is the Last Extension That Matters

Swift will not cancel this. The compliance case is too strong. Structured town and country are what let sanctions screening compare an address to a list without fuzzy matching an entire free-text blob, and that is the difference between a payment clearing straight through and landing in a manual investigation queue.

But I think the December update lands on a date in late 2027 or 2028, aligned closer to Fedwire's November 2027 slot than to a rushed 2027 alternative, and I think the fully structured format quietly stops being the target. Hybrid becomes the permanent destination, not a transitional concession. Once two-thirds of the network has built hybrid output and validated it in production, the incremental compliance value of splitting StrtNm from BldgNb will not justify another coordinated migration. The screening benefit is already captured by town and country.

If that read is right, the engineering decision for the next 18 months is straightforward: build hybrid properly, with the no-duplication rule enforced at validation time, and stop waiting for a date before starting.

What This Means for Payment Developers

Concretely, if you own payment initiation:

Treat address as a schema decision, not a formatting one. Add town, country (alpha-2) and optional structured components as first-class columns wherever you persist counterparty details. In PostgreSQL that is a cheap migration today and an expensive backfill in two years. Validate at capture, not at send. Every onboarding form, supplier import and API contract that accepts an address should require town and country separately from the moment it goes live. New data arriving already structured is the only thing that shrinks the backlog. Make the outbound rule per-corridor. A configuration table keyed on scheme and destination, holding the address policy in force, beats a hardcoded cutover. You will need it, because the dates are now diverging by scheme. Reject early and loudly. If your hybrid builder can produce a message that duplicates TwnNm into an AdrLine, that is a bug you want failing in CI rather than surfacing as a correspondent's rejection three hops downstream. A schema-level assertion is a few lines of code and saves an operations ticket. Keep the original string. Store the raw captured address alongside the parsed components. When the parser is wrong, and it will be, you need the source to re-derive from.

As a fintech developer and payment developer who spends most of his time in settlement and reconciliation systems, I find this the most instructive story in payments this year, precisely because it is not glamorous. The message standard shipped. The network migrated. The thing that stopped it was three years of address fields nobody modelled properly. That is where most payment infrastructure work actually lives, and it is why UK fintech teams keep hiring engineers who are comfortable with data migration rather than just API design. If you want to see the kind of infrastructure work I do, start at Tom Wang.

The deadline moved. The schema didn't.