Unstructured addresses stop being accepted

By Sebastien Rousseau, maintainer of AskISO and the ISO 20022 MCP servers. Last reviewed 27 August 2026.

Where the timing stands

Swift deferred every payments change in Standards Release 2026 on 27 August 2026, the structured address requirement among them. There is no replacement date yet. Swift is consulting banks, central banks, payment market infrastructures, market practice groups and corporates, and has promised to confirm the timing by December at the latest.

The requirement itself was not withdrawn. The community agreed it in 2023 and it still stands, so what follows is what it asks for.

What changes

CBPR+ stands for Cross-Border Payments and Reporting Plus. It is the set of usage guidelines for ISO 20022 payment messages exchanged over Swift, and it sits above the standard itself.

The rule applies to everyone sending cross-border payments. That covers banks and corporates using SWIFT CBPR+, and the main payment market infrastructures. Wherever an address appears, it must be hybrid or fully structured. Non-compliant messages are rejected outright.

A structured address places each component in its own element: town, post code, country, street and building number. It replaces the free-text AdrLine lines that MT carried, and that early ISO 20022 messages permitted. A hybrid address keeps some address lines but requires town name and country to be structured.

This is not the whole of ISO 20022's 2026 change, and the address rule is the one with a hard rejection behind it.

Where the industry actually is

Nearly one institution in ten reports that more than half of its address data is still non-compliant. The gap is rarely in the payment engine itself. It lies in the customer data feeding that engine, which is why it takes longer to close than expected.

The 65% is Swift's own count, published in its March 2026 milestone notice. The other three figures come from RedCompass Labs research, which surveyed 308 senior payments professionals across Europe and North America and was reported in March 2026. All four were measured while the cutover was still November 2026, so read them as the readiness that prompted the deferral rather than as the position today.

Which messages the rule does not reach

Swift names six message identifiers as outside the requirement: admi.024, camt.025, camt.052, camt.053, camt.054 and camt.060. Everything else carrying an agent or a party is in scope, across payments, securities, trade, FX and funds.

For an agent specifically, giving the BIC alone remains valid. The requirement bites where a name and address are used in place of one.

What comes after

Swift's deferral covers the payments changes in Standards Release 2026 only. The later phases stand as published, and the timeline above follows the CBPR+ roadmap as RedCompass Labs summarises it.

Treating 2026 as a one-off project is the expensive path. The same data quality work — structured parties, verifiable identifiers, coded reasons instead of prose — is what 2027 and 2028 also require.

Check your own messages

AskISO checks the address rules without needing a schema installed, so this takes about a minute:

go install github.com/sebastienrousseau/askiso/cmd/askiso@latest

Then point it at a message. This is a real session, replayed — the output below is what the binary writes, checked against it on every commit:

$ askiso lint payment.xml --profile cbpr-2026
  LINTER   Semantic Business Rule Linter: payment.xml

  ✅ All 2 semantic checks passed with zero issues!
     • IBAN Modulo-97 Checksums : Verified
     • BIC / SWIFT Structure   : Verified
     • ISO 4217 Decimals       : Verified
     • RFC 4122 UUIDv4 UETR    : Verified

    PROFILE   cbpr-2026 — CBPR+ structured address requirements: postal addresses must be hybrid or fully structured. Swift deferred the 14 November 2026 cutover on 27 August 2026 and confirms new timing by December.

  ❌ [CBPR-ADDR-002] the address is fully unstructured (2 address line(s), no structured element)
     at       /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Cdtr/PstlAdr
     expected hybrid or structured
     fix      Move the town into <TwnNm> and the country into <Ctry>; keep the remainder in at most two <AdrLine> elements.

  ❌ [CBPR-ADDR-001] the address has no country
     at       /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Cdtr/PstlAdr/Ctry
     expected a <Ctry> element
     fix      Populate <TwnNm> and <Ctry> inside <PstlAdr>.

  ❌ [CBPR-ADDR-001] the address has no town name
     at       /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Cdtr/PstlAdr/TwnNm
     expected a <TwnNm> element
     fix      Populate <TwnNm> and <Ctry> inside <PstlAdr>.

Error: profile cbpr-2026 found 3 error(s)

Run it across a directory to get a count rather than a verdict on one file:

$ askiso batch ./messages --profile cbpr-2026
  BATCH   4 file(s)

  ✅ clean.xml
  ❌ pay-1.xml  pacs.008.001.10
      [CBPR-ADDR-002] the address is fully unstructured (2 address line(s), no structured element)
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Cdtr/PstlAdr
      [CBPR-ADDR-001] the address has no country
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Cdtr/PstlAdr/Ctry
      [CBPR-ADDR-001] the address has no town name
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Cdtr/PstlAdr/TwnNm
      [CBPR-ADDR-002] the address is fully unstructured (3 address line(s), no structured element)
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Dbtr/PstlAdr
      [CBPR-ADDR-004] 3 address lines; CBPR+ permits at most 2
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Dbtr/PstlAdr/AdrLine
      [CBPR-ADDR-001] the address has no country
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Dbtr/PstlAdr/Ctry
      [CBPR-ADDR-001] the address has no town name
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Dbtr/PstlAdr/TwnNm

  ❌ pay-2.xml  pacs.008.001.10
      [CBPR-ADDR-002] the address is fully unstructured (2 address line(s), no structured element)
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Cdtr/PstlAdr
      [CBPR-ADDR-001] the address has no country
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Cdtr/PstlAdr/Ctry
      [CBPR-ADDR-001] the address has no town name
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Cdtr/PstlAdr/TwnNm
      [CBPR-ADDR-002] the address is fully unstructured (3 address line(s), no structured element)
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Dbtr/PstlAdr
      [CBPR-ADDR-004] 3 address lines; CBPR+ permits at most 2
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Dbtr/PstlAdr/AdrLine
      [CBPR-ADDR-001] the address has no country
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Dbtr/PstlAdr/Ctry
      [CBPR-ADDR-001] the address has no town name
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Dbtr/PstlAdr/TwnNm

  ❌ pay-3.xml  pacs.008.001.10
      [CBPR-ADDR-002] the address is fully unstructured (2 address line(s), no structured element)
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Cdtr/PstlAdr
      [CBPR-ADDR-001] the address has no country
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Cdtr/PstlAdr/Ctry
      [CBPR-ADDR-001] the address has no town name
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Cdtr/PstlAdr/TwnNm
      [CBPR-ADDR-002] the address is fully unstructured (3 address line(s), no structured element)
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Dbtr/PstlAdr
      [CBPR-ADDR-004] 3 address lines; CBPR+ permits at most 2
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Dbtr/PstlAdr/AdrLine
      [CBPR-ADDR-001] the address has no country
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Dbtr/PstlAdr/Ctry
      [CBPR-ADDR-001] the address has no town name
         at /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Dbtr/PstlAdr/TwnNm

  1 passed, 3 failed, 21 error(s) total
$ askiso batch ./messages --profile cbpr-2026 --format sarif > findings.sarif

The SARIF output feeds GitHub code scanning, or any other tool that reads the format. Your check can therefore sit in a pipeline rather than in somebody's terminal.

Nothing is uploaded. AskISO runs locally, which matters when the input is a real payment instruction.

The rules behind it

The cbpr-2026 profile carries five address rules, CBPR-ADDR-001 through CBPR-ADDR-005. Every diagnostic names the rule, the path and what was expected. It also states what to do about it, so you can hand it straight to whoever owns the data instead of interpreting it first.

--profile cbpr-2027 checks the enhanced-data expectations CBPR+ is moving towards: purpose codes, legal entity identifiers and structured remittance. --profile all runs everything.

If you are converting from MT

MT addresses are unstructured by nature — that is what fields 50K and 59 carry. A message converted from MT will therefore not satisfy the mandate until the addresses are enriched from another source. AskISO says so rather than handing you a message that looks compliant:

$ askiso translate payment.mt103 --report
  TRANSLATE    MT103 → pacs.008.001.10

  source   payment.mt103
  fields   5 mapped, 3 derived, 2 truncated, 1 unmapped

  ⚠️  :121:  derived
       → /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtId/UETR
       the source carried no UETR; a new one was generated
  ✅ :20:  mapped
       → /Document/FIToFICstmrCdtTrf/GrpHdr/MsgId
  ❌ :23B:  unmapped
       bank operation code has no direct equivalent; carry it as a local
       instrument if the rail defines one
  ✅ :32A:  mapped
       → /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/IntrBkSttlmAmt
  ✅ :50K:  mapped
       → /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Dbtr
  ⚠️  :50K (address):  truncated
       → /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Dbtr/PstlAdr/AdrLine
       MT addresses are unstructured; CBPR+ rejects those once the
       deferred structured address requirement takes effect. Populate
       TwnNm and Ctry.
  ⚠️  :52:  derived
       → /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/DbtrAgt
       taken from the message header
  ⚠️  :57:  derived
       → /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/CdtrAgt
       taken from the message header
  ✅ :59:  mapped
       → /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Cdtr
  ⚠️  :59 (address):  truncated
       → /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Cdtr/PstlAdr/AdrLine
       MT addresses are unstructured; CBPR+ rejects those once the
       deferred structured address requirement takes effect. Populate
       TwnNm and Ctry.
  ✅ :71A:  mapped
       → /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/ChrgBr

  ⚠️  this conversion is lossy — review the entries above before relying on it
  → check the CBPR+ address rules:      askiso lint <file> --profile cbpr-2026

The fidelity report names every field in the source and what became of it — mapped, derived, truncated or unmapped. Nothing is dropped silently, which matters most in precisely this case. The conversion succeeds and the XML is schema-valid. It would still be rejected in November.

Remediating at scale

For bulk address remediation there is a separate tool, structured-address-fix, which analyses and proposes structured forms for existing records. Remediation is a data problem rather than a message problem, and it is worth separating the two: validating tells you the size of the gap, remediation closes it.

---

AskISO is a developer tool, not regulatory advice. A clean result is not an assurance that a scheme or correspondent will accept a message. The authoritative sources are iso20022.org, your scheme operator, and Swift's own CBPR+ documentation.

Figures above are drawn from published industry readiness reporting in mid-2026; they describe the industry, not any individual institution.