Structured Addresses in SWIFT and SEPA Payments: The Deadline Moved, the Work Didn't
2026-11-05
The Date That Quietly Disappeared
For most of the past year, November 2026 was circled in the payments industry's calendar. From that month, cross-border payment messages on the Swift network were due to stop accepting postal addresses written as free text, and SEPA payments in Europe were set to follow from 15 November. Banks spent months rebuilding forms and files around it.
Then, at the end of the summer, both dates came off the calendar. On 27 August 2026 Swift announced it was deferring the payment changes in its 2026 standards release, including the removal of unstructured addresses, and said it would consult the industry before setting a new timeline, with an update expected by December. On 9 September the European Payments Council's scheme management board did the same for all five SEPA rulebooks: the 15 November end date was dropped, and a new one will be set later.
If your business sends or receives international payments, it's tempting to read that as "nothing to do". It isn't quite that.
Free Text, Structured, Hybrid: What the Change Is About
Modern payment messages, built on the ISO 20022 standard, have a separate field for each part of an address: street, building number, postcode, town, country. Older formats had a few lines of free text, and many payments still squeeze the whole address into those lines, in whatever order the person typing chose.
The industry works with three formats:
- Unstructured: the whole address as free text. This is the one being phased out.
- Fully structured: every element in its own field, with town and country as the minimum.
- Hybrid: town and country in their own fields, plus up to two free-text lines of up to 70 characters each for the rest. It exists as a bridge for organisations that can't yet split every address cleanly.
For the banks along the route, a BIC remains an accepted way to identify the bank itself. The change is mostly about the people and companies at either end of the payment: you, your customers, your suppliers.
Why Anyone Cares Where the Street Name Goes
A free-text address is easy for a person to read and awkward for a machine. "Unit 4, 12 Harbour Road, Limassol 3035, CY" and "Cyprus, Limassol, Harbour Rd 12/4" are the same place, but an automated check has to guess which part is the town and which is the country. Sanctions screening and anti-money-laundering monitoring at every bank in the chain run on that data. When it can't be read with confidence, the payment stops for a manual look, and somebody writes back asking for clarification.
Structured fields remove most of the guessing. A country in its own field can be checked instantly, and a town in the right place doesn't get mistaken for part of a company name. The payoff is fewer payments held for questions and fewer sent back. That's why the change is still coming, even with the date gone.
Why the Delay Happened
The short version: the industry wasn't ready. Readiness figures quoted at the time put the share of payments still carrying unstructured addresses at around 61% in April 2026, and large banks and domestic payment systems asked for more time. Moving the deadline acknowledged how much data still needs cleaning. It wasn't a change of direction. J.P. Morgan, for one, has described the decision as rescheduled, not abandoned.
The Part That Sits With You
Banks can rebuild their message formats. What they can't easily do is repair an address that was captured badly in the first place. Swift has been explicit that address data has to be right at the source, and for a business the source is usually its own records: supplier lists, customer files, invoice templates, the payees saved in online banking.
That's what the extra time is good for:
- Split addresses into parts. For every regular counterparty, store street, building number, postcode, town and country separately, not as one block of text.
- Use consistent country codes. "Germany", "DE" and "Deutschland" should become one value, ideally the two-letter ISO code.
- Ask when you onboard someone. When a supplier sends bank details, ask for the registered address in parts at the same time. Most will answer once and never think about it again.
- Match the paperwork. The beneficiary's name and address on the payment should match the invoice and the contract. Mismatches are a common reason for questions, and sometimes for a returned transfer.
- Check your own details. The address your customers see when they pay you should be your registered one, written the same way everywhere.
- Use the fields you're given. If a payment form or upload file has separate fields for town and postcode, fill them in instead of packing everything into the first line.
None of this is hard. It's tedious, and it touches finance, procurement and whoever looks after the accounting system, which is exactly why it slips when there's no deadline.
What This Means for Your Payments Today
Nothing about your payments has to change overnight. Unstructured, hybrid and structured addresses are all still valid under the current Swift standard, and the SEPA rulebooks keep allowing the unstructured format until the EPC sets a new end date. Swift's update on the timeline is due by the end of this year. Whenever the new dates land, it's easier to already have clean data than to start the clean-up then.
Meanwhile, messy data has a cost of its own. A payment held while a bank along the route asks who the beneficiary is, or one returned because the details don't line up, costs time and often fees. SWIFT payments can pass through correspondent banks, and each runs its own checks. Our guide to returned transfers covers what happens when details go wrong, and our SEPA vs SWIFT overview explains when each route applies.
How Polydirection Fits In
Polydirection provides international accounts and payments for businesses with complex cases: SEPA, SWIFT, multi-currency IBANs and Mastercard, routed through one account and reviewed individually. Crypto, gambling, forex and dating businesses get a dedicated manager, not a form-letter decline.
If you pay suppliers and partners in many countries, that means there's a person to ask when a payment is held or a counterparty's details look unclear. If you're tidying up how your payment data is set up, or want to check what an outgoing payment needs before you send it, contact us.
