MT101 to Pain.001: The SWIFT and EPC Structured-Address Deadlines Have Been Deferred

The short version

Update: both dates originally cited in this article have been pushed back. On 27 August 2026, SWIFT deferred its planned MT101 retirement. On 9 September 2026, the EPC's Payment Scheme Management Board voted to extend support for unstructured addresses beyond the previously announced 15 November 2026 cutoff, with a new date expected in October 2026. Neither body has published a replacement date yet — this is a deferral, not a cancellation.

• SWIFT MT101 retirement — SWIFT will retire the MT101 "Request for Transfer" message for interbank use, requiring financial institutions sending MT101 over FIN to migrate to pain.001 version 9 (the CBPR+-compliant XML format) delivered via FINplus. The date originally announced for November 2026 no longer applies.
• Structured address mandate — unstructured postal addresses will eventually be banned from cross-border and SEPA payment messages. Every payment initiation file will need, at minimum, a structured Town Name and Country Code — free-text address blocks alone won't be accepted once the mandate takes effect.

If your payment files still rely on flat MT101 text or free-text address lines, both of these changes will eventually affect you — whether you're a bank, a corporate treasury team, or a business generating your own payment files from Excel. There's just no fixed date to work against right now, so treat this as "prepare when convenient," not "scramble before a cutover."

Why this isn't just "a bank problem"

It's tempting to read this as backend infrastructure — something SWIFT and banks sort out between themselves. Two details make that assumption risky:

The address requirement flows upstream. A bank can't construct a compliant outbound message from an inbound file that doesn't have the data. If your company submits bulk payment files — whether through a corporate banking portal or your own pain.001 generation — the creditor address in that file needs structured fields, not a two-line free-text block. Banks are already signaling that non-compliant submissions will be rejected at the point of initiation, not silently patched.

Corporate MT101 users aren't automatically exempt. Corporates using SCORE or MA-CUG access to SWIFT were never directly bound by the interbank retirement deadline, but they'll still need to update their message content to meet the same hybrid address requirements once a new date is confirmed — otherwise their instructions could get stuck at the first bank that has already migrated.

MT101 vs. pain.001: what actually changes

The practical upshot: pain.001 carries more data per payment, in a format that's actually machine-parseable — which is exactly why the address requirement exists. A free-text address line was never something downstream systems (sanctions screening, in particular) could reliably parse. Structured fields fix that at the source.

What "structured" and "hybrid" actually mean

There are three tiers in play:

1. Unstructured — the old way. One or two free-text lines: 123 Main Street, London EC2V 8BQ, United Kingdom. Machine-unreadable as discrete fields. Being phased out entirely.
2. Hybrid — the practical minimum going forward. Town Name and Country Code go in their own dedicated XML fields; the rest of the address can still be free text.
3. Fully structured — every component (street name, building number, town, postcode, country) in its own field. This is the direction SWIFT and the EPC both want the industry to move, though hybrid meets the near-term bar.

If you're generating payment files today with a single "Address" column mapped straight into a free-text field, hybrid structuring is the minimum change you'll eventually need — not fully structured, but Town Name and Country Code do need to be broken out. There's no fixed deadline right now, so preparing early just avoids a scramble once new dates are confirmed.

What happens if you don't prepare

There's no cutover date on the calendar right now, so nothing changes overnight. But whenever SWIFT and the EPC confirm their new dates, payments carrying unstructured addresses or legacy MT101 formatting risk:

• Rejection at the first bank in the chain that has completed its own migration
• Delays while the payment gets manually repaired or bounced back for resubmission
• Downstream reconciliation problems if a "successful" file quietly fails structured-data checks

SWIFT's own data suggests a meaningful share of payment traffic industry-wide still carries unstructured addresses well into 2026 — this is not a hypothetical edge case, it's a live gap.

How to check where you stand

• Audit your address data. Do your Excel exports or ERP records have Town/City and Country as separate columns, or are they buried inside one free-text address field?
• Check your payment file format. If you're still producing MT101, plan the move to pain.001 v9 now rather than waiting for a bank notice.
• Confirm your BIC handling. pain.001 v9 uses BICFI in place of the older BIC tag — a small but real schema difference if you're hand-rolling XML.
• Don't default to placeholder text. Using something like "NOTPROVIDED" in a required address field doesn't satisfy the requirement and won't reliably pass validation.

Where a converter fits in

This is exactly the kind of structural change that's easy to get right once and then never think about again — if the tool generating your XML enforces it by default. A converter that maps your spreadsheet's city and country columns into dedicated TwnNm and Ctry fields (rather than concatenating everything into a free-text address line) clears this bar automatically, without you needing to track SWIFT release notes.