Skip to content
Insights

Swift deferred the deadline and kept the requirement.

Everything planned for Standards Release 2026 came off the calendar on August 27, and the replacement date is a consultation.

  • Andrii Triasun
  • Industry
  • Aug 28, 2026

The coexistence period for cross-border payments closed on November 22 and 23, 2025. MT103 and MT202 went with it, replaced by pacs.008 and pacs.009, and Swift reports more than 98 percent of payment instructions are now sent in ISO 20022. The next hard date was November 14, 2026, when a CBPR+ message carrying a fully unstructured postal address was to be rejected at the network.

On August 27, 2026 that date was deferred. Swift put off every payments change planned for Standards Release 2026 and has not said what replaces them.

What was deferred

Swift's stated reason is that readiness across the industry was uneven and that several communities had formally asked for more time, and it consulted the payment market infrastructures before deciding. It will now consult banks, central banks, market infrastructures, market practice groups and corporates on new timing and a new approach, and publish an update by December 2026 at the latest.

The interbank MT101 relay sat on the same November 14 date. Multi-instruction MT101 messages were to be rejected outright, and single-instruction messages converted to pain.001 for a fee. That is on hold as well: Swift will not enforce the end of MT101 coexistence in November, and no automatic conversion will apply. The target format is still pain.001.

What did not move

The decision to go to structured addresses was taken by the community in 2023 and has not been reversed. Nothing about the obligation itself changed on August 27. What changed is when it bites. That date does not currently exist.

Domestic payment market infrastructures set their own deadlines and do not necessarily follow the CBPR+ timeline. The Swift announcement says nothing about any of them, so a locally cleared scheme may still be holding a date of its own. Those have to be checked one at a time.

The requirement, in full

Where a CBPR+ payment message carries a postal address, that address has to be fully structured or hybrid. The floor is low: town and country in their own elements, TwnNm and Ctry, for every agent and party in the message. In the hybrid form the rest can stay as free text, in up to two AdrLine elements of 70 characters each.

<PstlAdr>
  <PstCd>60311</PstCd>
  <TwnNm>Frankfurt am Main</TwnNm>
  <Ctry>DE</Ctry>
  <AdrLine>Musterstraße 12</AdrLine>
</PstlAdr>

A low floor is the useful part, because a core that holds one long address string can reach it. Reaching a fully structured address is a different project. Splitting the remainder into a street name and a building number by heuristic produces messages that validate and are wrong, which is worse than leaving the address unstructured.

Withdrawn is harder than late

November 14 was something a program could be scheduled against. It named the day the work had to be finished by, and it let everything else queue behind it. What sits there now is a consultation and a promise of an update by December, which is harder to plan around than a deadline.

The remediation is the same size it was on August 26. Getting town and country out of a free-text blob and into their own elements takes as long as it takes, and the teams that finish before the new date is announced are the ones that never have to find out what it is.