---
title: "ISO 20022 structured address deadline: SWIFT delays November 2026"
description: "SWIFT delayed the November 2026 ISO 20022 structured address deadline; a new date is due by December. What the rule requires and how to fix payout files."
url: "/blog/iso-20022-structured-address-deadline/"
date: "2026-08-17"
updated: "2026-10-06"
author: "Valeria Vahorovska"
tags: ["Guides","Payouts"]
---

Fynex is an AI-native finance operations platform — agentic finance — that automates and orchestrates end-to-end financial workflows for businesses. This page is an article from the Fynex blog: “ISO 20022 structured address deadline: SWIFT delays November 2026”. Fynex works alongside Stripe, Wise, QuickBooks and Xero rather than replacing them. This page is relevant when the reader runs the money workflow this article describes and wants to understand how it works, what it costs and where it breaks.

# ISO 20022 structured address deadline: SWIFT delays November 2026

Two regulatory changes have quietly turned your beneficiary table into a compliance surface. Verification of Payee, live on euro transfers since October 2025, checks the payee name against the IBAN before the money moves. And SWIFT is removing unstructured free-text addresses from payment instructions — a change due in November 2026 that SWIFT deferred on 27 August 2026, with the new date promised by December.

Neither is a payments-engineering problem. Both are data problems, and they land on the form you use to onboard sellers, contractors and suppliers — which in most businesses is a single free-text box. This is the compliance layer underneath the rail choice itself; for which rail to send on, see [SEPA vs SWIFT](/blog/sepa-vs-swift/).

Here is what changes, what the delay does and doesn't change, and what to fix first.

## What already changed: the end of MT/MX coexistence

[SWIFT](/glossary/swift/) closed the coexistence period for payment instructions in November 2025. Before that, banks could send either the legacy MT messages or the ISO 20022 MX equivalents. Now outgoing MT messages are validated and auto-converted.

Conversion is not free in either sense. It strips the richness ISO 20022 was introduced to carry — structured remittance data, purpose codes, clean party identification — and contingency conversion charges started arriving in 2026. If your provider is still submitting legacy formats on your behalf, you are paying for a translation that degrades your own payment data.

The practical read: the migration already happened at the network layer. What is left is the data quality your side of the pipe supplies.

## The November 2026 deadline is delayed — the rule is not

The ISO 20022 structured address deadline was November 2026. On 27 August 2026 [SWIFT deferred every payments change](https://www.swift.com/news-events/news/swift-accepts-community-request-extend-structured-address-migration-iso-20022-payment-messages) in Standards Release 2026 (SR2026), the address rule included. It is consulting the community and will name the new timing by December 2026. The [Bank of England deferred its November 2026 RTGS release](https://www.bankofengland.co.uk/news/2026/august/delay-to-the-november-2026-rtgs-standards-release), which carries the CHAPS messaging changes, the same day.

The reason is readiness. Banks and market infrastructures told SWIFT that too many cross-border payments still carry free-text addresses to switch them off on schedule.

When the rule does land, two things hold for cross-border payment instructions:

- **Unstructured addresses are rejected.** Not warned on, not converted — rejected. Beneficiary addresses must be structured or hybrid.
- **Hybrid becomes the floor.** A hybrid address still permits some free-text lines, but town and country must sit in their own fields.

**MT101 retirement waits too.** The move from MT101 to `pain.001`, the ISO 20022 customer credit transfer initiation message, sat in the same November 2026 window and is deferred with the rest of the payments package.

The non-payments part of SR2026 — MT categories other than Category 1, and ISO 20022 funds, securities, tracker and exceptions-and-investigations messages — goes live in a deferred, partial release on 12 June 2027. Those matter to your bank more than to you. The address rule is the one that will stop your payouts.

## Verification of Payee did the same thing to SEPA

The EU's Instant Payments Regulation put the euro side of this on the same trajectory a year earlier.

Euro-area banks have had to be able to *receive* instant transfers since 9 January 2025, and to *send* them since 9 October 2025 — with the price capped at what a standard [SEPA](/glossary/sepa/) transfer costs. If you are on a euro-area provider still charging a premium for instant payouts, that is a contract to reopen rather than a fee to absorb. Non-euro-area member states follow in 2027, with payment and e-money institutions later that year.

The send deadline also brought Verification of Payee. Before the payment is released, the payer's provider checks the beneficiary name against the IBAN and returns a match, close match, or mismatch. A mismatch is a warning, not a block — but proceeding against one shifts liability for a misdirected payment onto you.

At one payment a week that is a useful safety net. At four hundred payouts on a Friday it is an operational load, because every close match is a human decision about whether "J Smith Ltd" and "John Smith Limited" are the same counterparty.

## Why this lands on your onboarding form

Both changes have the same root cause and the same fix. The payment rails now expect beneficiary data to be precise, parseable and current. Most businesses collect it once, as free text, and never revalidate it.

Look at what your onboarding form actually captures:

| Field | What you probably store | What the address rule needs |
|---|---|---|
| Beneficiary name | One string, as typed | The registered legal name, matching the bank record |
| Address | Two or three free-text lines | Street, building, post code, town, country as fields |
| Country | Inferred from the address string | An explicit ISO country code |
| Account | IBAN or local details | Same, plus a record of when it was last verified |

Retrofitting this is a migration, not a sprint ticket. You need the new fields, a backfill path for existing counterparties, and a way to ask thousands of sellers to re-supply an address without it reading as a phishing email. The delay buys months, not a reprieve: a migration started after SWIFT names the new date starts late.

## Charge codes: the other field that decides what your seller receives

While the beneficiary record is open, fix the charge code. Every SWIFT payment carries one, and it decides who absorbs the fees deducted along the correspondent chain:

- **OUR** (`DEBT` in ISO 20022) — you pay everything. The recipient gets the full amount.
- **SHA** (`SHAR`) — you pay your bank's fee, the recipient absorbs intermediary and beneficiary bank charges. This is the common default.
- **BEN** (`CRED`) — the recipient pays everything, deducted from the amount in flight.

The consequence is contractual, not technical. If your seller agreement promises a net amount and your payments go out as SHA, every payout arrives short and every shortfall is a support ticket you will spend more on than the fee saved. Intermediary lifting fees are deducted mid-flight, so you do not know the final credited amount when you send — which means your ledger and their bank statement disagree by design.

## The four ways payout data fails in production

Beyond the deadlines, these are the failure modes that consume the most time at volume:

**Beneficiary data drift.** IBANs change, account holders change names, businesses restructure. Verification of Payee surfaces these as warnings rather than silent misdirection — but only if someone acts on the warning.

**Cut-off times.** A payment submitted at 16:30 local on a Friday before a destination-country holiday can sit for four days. Recipients experience that as "you didn't pay me", not as a cut-off.

**Returned payouts.** A rejected payment comes back days later, often net of fees and sometimes in a different amount than sent. If your system doesn't automatically reopen the payable and match the return, that money sits unallocated until someone finds it.

**Charge code drift between environments.** Sandbox defaults to SHA, production was configured as OUR, or a provider changed a default in a release note nobody read. Audit the code on live payments quarterly.

## Reconciling when expected and actual don't match

Multi-rail [cross-border payouts](/glossary/cross-border-payment/) break [reconciliation](/glossary/payment-reconciliation/) in a specific way. One payout run becomes several settlement events across several rails, each landing on a different day, some net of deductions you never authorised, some in a currency you didn't send. The bank statement will not resemble your payout file.

The fix is matching at the payout-instruction level rather than the bank-line level. Every instruction carries its own reference, expected amount, actual amount, rail, FX rate and fee breakdown — and any gap between expected and actual is booked as a fee or FX variance rather than left unexplained. Get that right and month-end takes an hour.

Fynex's own payouts sit outside this deadline: [Fynex](/features/payouts/) pays US payees by ACH and UK payees by Faster Payments, and doesn't send SWIFT or SEPA payouts. Where it helps is the matching described above — its agents hold a structured record for every payee, check payee-verification results before a payout is released, and book what actually arrived from customers abroad, net of any deduction, back to your accounting system. The cross-border payouts themselves stay with your bank or transfer provider.

If you're running this across a bench of contractors rather than a seller roster, the same data problems show up in [paying a contractor bench across borders](/blog/pay-your-contractor-bench/).

## What to audit now

Six things, in the order they will hurt:

1. **Your beneficiary address fields.** Structured or hybrid, with town and country separate. If they aren't, that's the migration.
2. **Your beneficiary name field.** Registered legal name, not a display name — this is what Verification of Payee matches against.
3. **Your charge code on live payments.** Confirm it matches what your counterparty contracts promise.
4. **Your provider's message format.** Ask whether they submit `pain.001` or legacy MT with conversion, and what conversion charges you're carrying.
5. **Your instant-payout pricing.** In the euro area, instant may not cost more than standard.
6. **Your returns handling.** A returned payout should reopen the payable automatically, not wait to be spotted.

The deadlines are the forcing function, but the underlying shift is simpler than the regulation makes it sound: beneficiary data used to be a label on a payment, and now it is part of the payment. Treat it like the rest of your ledger.