ISO 20022 structured addresses: what becomes mandatory in November 2026

Less than it did a month ago. On 27 August 2026 Swift accepted a community request to extend the structured address migration for ISO 20022 payment messages and deferred every payments change in Standards Release 2026, including the network validation that was to reject fully unstructured postal addresses from 14 November 2026. The European Payments Council followed on 9 September, postponing the same end date under all five of its scheme rulebooks. The target format is unchanged, the hybrid option has been live since November 2025, and the address data sitting in your core banking system is in exactly the state it was in July. This is what still binds, and what to do with the months.

The three address formats, and the one being withdrawn

ISO 20022 has carried a structured postal address for far longer than any of these deadlines. The schema was never the hard part. Most banks hold the last mile of a customer address as one free-text line, because that is what a delivery label and an MT field both wanted, and splitting that line is a data project rather than a message-format project.

The PostalAddress component offers 14 structured attributes plus a free-text AddressLine. Interbank payment messages allow three combinations of them:

• fully structured: the structured elements only, with no AddressLine
• fully unstructured: AddressLine only, which is what most traffic still carries
• hybrid: structured elements together with AddressLine, available in CBPR+ and the leading market infrastructures since the November 2025 Standards Release

The hybrid option is the compromise that made the migration tractable, and it carries three rules worth knowing before anyone writes a mapper. Town Name and Country are mandatory inside PostalAddress, exactly as they are in a fully structured address. AddressLine is capped at two occurrences of 70 characters. Structured information must not be repeated in AddressLine, so a message that puts Brussels in both TwnNm and an address line is malformed and a receiving engine may read the town twice.

None of this makes an address mandatory. Under the EPC schemes an address is required where Regulation (EU) 2023/1113 requires it, which is where a payment service provider in the chain sits outside the EEA, and it stays optional inside the EEA. For agents, a BIC on its own remains a valid alternative to name and address. Swift's scope also leaves out the cash reporting messages camt.052, camt.053 and camt.054. What is being withdrawn is one format of address. Whether an address has to be there at all is a question for the funds transfer regulation.

Which rule belongs to whom

Coverage of this deadline tends to run four separate rulebooks together. They have different owners, different scopes and, as of this month, different dates.

1. Swift CBPR+ is a network rule. Fully unstructured addresses were to be NAK'ed at network level from 14 November 2026, with no contingency measure. That validation is now deferred along with the rest of the payments release.
2. Market infrastructures set their own dates. The Eurosystem moved the November 2026 releases of T2, T2S, TIPS and ECMS from 14 to 28 November 2026, and raised a fast-track change request, T2-0188-SYS, to keep accepting fully unstructured addresses in RTGS messages sent over A2A. The Bank of England deferred its own November 2026 RTGS standards release, which carries the CHAPS message standards, on the day Swift announced.
3. Scheme rulebooks are third. The EPC had set 15 November 2026, and 03h30 CET for the instant schemes, replacing an earlier 22 November. Its Payment Scheme Management Board delayed that on 9 September 2026 and will set a new date in October.
4. Regulation is the layer that has not moved. FATF published its revised Recommendation 16 on 18 June 2025, to come into effect by the end of 2030.

The T2 change request repays reading in full. It reopens fully unstructured addresses on the A2A channel for pacs.004, pacs.008, pacs.009, pacs.010, camt.029 and camt.056, and leaves the RTGS user interface accepting structured or hybrid only. It also records that the business validation rules deleted by the earlier change will not be restored, so a postal address that would have been flagged as an error before now passes. One system, two answers, depending on the channel a message arrives through.

Recommendation 16 is the reason none of this goes away. Above USD/EUR 1,000 it asks for the originator's name and address and the beneficiary's name, town name and country, and it tells countries to use structured data where possible. The CPMI's harmonised ISO 20022 data requirements, published in October 2023, ask for the same minimum: country and town name in explicit structured elements.

What to build while the date is open

The months bought back are build time. Swift's own readiness figures say where it should go: in August 2026, 54.8% of debtor addresses and 56.2% of creditor addresses observed in CBPR+ traffic were still fully unstructured. Those are the records that have to be split, and the splitting is the slow part.

The design question is where in the flow an address becomes structured. There are three placements, in rising order of what they cost to retrofit:

1. At capture. The channel, the core banking party record and the corporate's own ERP hold the address in structured fields from the start, so the payment message is correct before it reaches the gateway.
2. In one mapping service. A single component between the originating systems and the payment gateway owns parsing, lookup and the mapping into PostalAddress, and every channel goes through it.
3. Per system, in an adapter. Each legacy source translates its own address format at its own boundary.

Most banks end up with all three: capture for new onboarding, a mapping service for the flows that come out of systems nobody will replace this decade, and adapters where a core cannot be touched at all. The placement matters less than the rule that there is exactly one implementation of the mapping. Two systems that both believe they own the address will keep overwriting each other, and that costs more than any parser.

The part most plans underweight is that the mapping runs in both directions and to more than one target. The PMPG guidance sets out three schemes for it. Hybrid to MT uses option F, with the name in subfield 1, the address lines in subfield 2, and country, town and post code in subfield 3. Hybrid to a market infrastructure that does not yet support hybrid folds everything back into up to three address lines of 35 characters, comma separated. The third scheme covers returns and warehoused payments that straddle a cutover, where a pacs.004 generated after go-live has to carry a structured address derived from a message that never had one. For that case the guidance allows the literal value CUTOVER2026 in Town Name, for three months only, with Country derived from the creditor agent's BIC as a last resort and the institution carrying the risk of that being wrong. All of it belongs in the same payment orchestration layer as the rest of the routing, because it is routing: the format depends on where the message is going next.

What breaks first, and the order to check it

Address data is rarely one field in one system, which is why “structure the addresses” arrives as a single ticket and leaves as a programme. In a bank of any age the same customer address exists in the core banking party record, in the channel's stored beneficiary templates, in the screening engine's own copy, in the CRM and in the archive that regulatory reporting reads. Those copies already disagree. Splitting them multiplies the disagreement by the number of copies.

The order that keeps it contained:

1. Measure before parsing. Count how many records already yield a reliable town and country, by country and by channel. That number decides whether this is a lookup problem or a customer outreach problem, and it is usually worse for corporate creditors than for retail debtors.
2. Name the master. Decide which system owns the structured address and make every other copy derived from it.
3. Fix the stored templates. Repeat payments run from beneficiary preformats saved on the e-banking platform, and those are the records nobody re-enters. A migration that cleans the customer master and leaves the templates alone will pass testing and fail in production.
4. Build the mapping matrix per counterparty. One outbound format is not enough while some infrastructures take hybrid and some do not, and the same is true for instant payment schemes with their own rulebooks and their own dates.
5. Re-tune screening last, and expect it to move. Splitting a free-text blob changes the strings the sanctions engine sees, so the hit rate moves in both directions, and it moves on the day the mapper changes.

Two small rules save a surprising amount of rework. Do not repeat a structured element inside an address line, because that is what makes a hybrid address malformed. And do not fill Town Name with NOTPROVIDED: the PMPG expects the industry to move away from that value for compliance reasons and warns that it may become a red-flag issue.

The records no lookup service will fix

Every enrichment provider handles the well-documented postal systems. The residue is where the engineering goes, and the market practice guidance is more specific about it than most teams expect.

• Town names longer than the 35 characters TwnNm allows. The PMPG suggests truncating to something identifiable, the way Welwyn Garden City becomes Welwyn Gdn Cty.
• Addresses with no town at all. The country subdivision takes its place as the next smallest identifying entity, and the same value goes into both Town Name and Country Subdivision deliberately, so that the repetition reads as intentional.
• Post box addresses. PstBx is its own element, capped at 16 characters, and the Wolfsberg Group's payment transparency standards say a post office box alone should be avoided as an address except where market practice leaves no alternative.
• Records that hold a country and nothing else. These need a customer conversation and a date in a plan, and no API answers them.

The extra months are worth what a team does with them. Measurement, the master data decision and the template clean-up can all start before anyone knows the new date, and none of them get cheaper by waiting for it. The same holds for the schemes that set their own calendars, including instant payments across the EU.