MT101 to Pain.001: What the November 2026 SWIFT Deadline Means for Your Payment Files

The short version

Two related but separate deadlines are landing in mid-November 2026:

• November 14, 2026 — SWIFT retires the MT101 "Request for Transfer" message for interbank use. Financial institutions sending MT101 over FIN must migrate to pain.001 version 9 (the CBPR+-compliant XML format) delivered via FINplus.
• Mid-November 2026 (SWIFT: Nov 14; SEPA/EPC-aligned schemes: Nov 15) — unstructured postal addresses are banned from cross-border and SEPA payment messages. Every payment initiation file needs, at minimum, a structured Town Name and Country Code — free-text address blocks alone won't be accepted.

If your payment files still rely on flat MT101 text or free-text address lines, both of these changes affect you — whether you're a bank, a corporate treasury team, or a business generating your own payment files from Excel.

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 are not directly bound by the November 14 interbank deadline, but they still need to update their message content to meet the same hybrid address requirements — otherwise their instructions 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 need before November 2026 — not fully structured, but Town Name and Country Code do need to be broken out.

What happens if you don't prepare

Nothing dramatic on November 13, and then a real problem on November 14. Payments carrying unstructured addresses or legacy MT101 formatting after the cutover 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.