Swift Moved the Structured Address Deadline. Your Vendor Master Clean-Up Shouldn’t Wait
October 12, 2026
When Swift announced on 27 August 2026 that it would defer the payments changes in Standards Release 2026, including the removal of unstructured postal addresses, a fair number of treasury teams breathed out. The European Payments Council followed on 9 September, postponing the 15 November 2026 end date for unstructured addresses across all five SEPA scheme rulebooks. For anyone who had spent the summer chasing ERP consultants about address fields, it looked like the pressure had come off.
It has, but only on the calendar. The work itself has not changed, and the part of that work that sits with corporates, rather than with banks, is the part that takes longest. Swift has been explicit that address information has to be sourced at origin, which means no bank, network or clever piece of middleware can fix a vendor record that was badly captured in the first place. The extension gives treasury and finance teams time to do this properly. It does not make the problem smaller.
This article sets out what actually moved, why the deferral is a reason to keep going rather than pause, and where address data tends to break inside a multinational’s payment chain. It builds on our earlier piece on ISO 20022 and the SWIFT MX migration, which introduced the structured address requirement at a high level.
What changed, and what did not
The original plan was straightforward. From November 2026, cross-border payment messages on the Swift network would only accept postal addresses in a fully structured or hybrid format, and SEPA scheme payments would follow the same rule a day later. Both of those dates have now been withdrawn. What replaces them is still being settled.
| Item | Original position | Position at October 2026 |
|---|---|---|
| Swift CBPR+ structured address requirement | Unstructured addresses rejected from November 2026 | Deferred. Swift is consulting banks, market infrastructures and corporates, with an update expected by December 2026 |
| SEPA scheme rulebooks (EPC) | Unstructured format no longer permitted from 15 November 2026 | Postponed by the EPC board on 9 September 2026. A new end date is expected to be discussed in October 2026 |
| Deferred SR 2026 release (non-payments changes) | November 2026 | 12 June 2027. This date does not cover the payments changes, so it should not be read as the new address deadline |
| Structured and hybrid formats | Supported | Still supported and usable today across the Swift network |
Two points in that table deserve attention. The first is that the June 2027 date has already been misquoted in some internal project updates we have seen as the “new deadline” for addresses. It is not. The second is that nothing has been cancelled. The end state is unchanged, and both Swift and the EPC have encouraged institutions that are already prepared to keep using structured data. The EPC has gone further and recommended that payment users move directly to fully structured addresses where they can, rather than stopping at the hybrid format.
It is also worth remembering that your banks have their own timelines. Several had already rebuilt their online banking screens and file specifications around structured fields ahead of November. Some will keep those changes in place regardless of the network deferral, and their validation rules for corporate files may tighten before the interbank deadline does. The only reliable way to know is to ask each bank, in writing, what it will accept on each channel and from when.
Why this is a treasury problem, not a bank problem
In most groups, nobody in treasury owns the vendor master. Accounts payable maintains it, procurement onboards new suppliers into it, and IT manages the interface that turns it into payment files. Treasury owns the bank connectivity and, very often, the payment factory or in-house bank that sends the money out. That split is exactly why address remediation stalls. Each function can reasonably argue that the problem starts somewhere else.
The practical consequence is that treasury ends up holding the risk without holding the data. When a cross-border payment is rejected or held for a sanctions query because the beneficiary’s town and country cannot be read cleanly, the call comes to treasury, usually on the afternoon the supplier was promised its funds. Poor address quality is already causing friction today, under the current rules, in the form of screening hits and repair queues at intermediary banks. A future deadline simply converts that friction into outright rejection.
There is also a control dimension that tends to be overlooked. A large-scale address clean-up is, by definition, a mass change to vendor master data. In our article on treasury fraud in 2026 we described how attackers exploit periods of legitimate change. An email to suppliers asking them to “confirm their details for our new payment standards” is a perfectly normal communication, and it is also an ideal template for a fraudster. Any remediation project needs the same segregation of duties and dual authorisation over vendor changes that applies to bank account updates, and suppliers should be told clearly that their bank details will never be requested as part of the exercise.
Where address data actually breaks
When we review payment data with clients, the issues rarely sit in one place. They are spread across systems that were configured at different times, by different people, for different purposes. The most common sources are these.
- The ERP vendor master. Many records hold the address in a handful of free-text lines, with town and postal code typed together in a single field, or the country code defaulted to the paying entity’s own country when a record was created through a legacy interface.
- Saved beneficiaries in bank portals. Templates created years ago for urgent or one-off payments are often the worst records in the estate, and they sit outside the ERP clean-up entirely.
- TMS static data. Counterparty and payee records in platforms such as Kyriba or SAP Treasury may have been loaded once from the ERP and never resynchronised.
- In-house bank flows. In payment-on-behalf-of structures the message carries both the in-house bank as debtor and the subsidiary as ultimate debtor. Both addresses need to be correct, and the subsidiary’s address is frequently the one nobody has checked.
- MT101 users. Groups still sending MT101 requests will need to move beneficiary details to field 59 option F to carry structured town and country information.
- Manual payments. Anything keyed by hand under time pressure, typically the payments that matter most on the day.
Underneath the systems question is a simpler one. Real addresses do not fit neatly into fields designed around a single country’s conventions. An Irish supplier may give “Naas, Co. Kildare” with an Eircode, and a Dublin address may include a postal district that a parser reads as part of the town name. Hong Kong has no postal code system at all. Many businesses in the United Arab Emirates use a P.O. Box rather than a street address. Japanese addresses run from the largest unit to the smallest, the reverse of the Western order. Mexican addresses usually include a colonia that has no direct equivalent in a US format. A US address needs its state captured as a country subdivision, not appended to the city. None of this is exotic for a multinational with a global supplier base, and all of it defeats the assumption that address structuring is a simple find-and-replace job.
From the field
A US-headquartered industrial group running its in-house bank out of Ireland asked us to review its readiness in early 2026. Treasury had been told by IT that the SAP vendor master was “already structured”, because street, city, postal code and country each had their own field. On paper, that was true.
In practice, around a fifth of the European records had the postal code and town typed together in the city field. A block of Latin American vendors created through an old procurement interface carried the US country code. When a test payment to a long-standing supplier in Monterrey was run through the bank’s validation service, it failed on the first attempt.
The group did not try to fix everything. It deactivated vendors that had not been paid in two years, which removed a significant part of the file and closed off an obvious fraud exposure at the same time. It then remediated the remaining records in order of cross-border payment value, starting with the top corridors, and changed the supplier onboarding form so that new records could only be created in structured form. The clean-up of the long tail is still running. The payments that matter are no longer at risk.
Hybrid or fully structured?
The hybrid format was introduced as a bridge. It requires town and country to be held as structured elements and allows the remaining detail to stay in free text, in no more than two address lines of 70 characters each. For many groups it is the realistic target for the long tail of low-volume vendors. For high-value and high-volume beneficiaries, and for anything that passes through a payment factory or in-house bank, fully structured data is the better investment. It is what the EPC is recommending, it reduces screening noise, and it avoids a second remediation exercise later if hybrid support is eventually withdrawn.
| Format | What it contains | Practical use |
|---|---|---|
| Unstructured | Free-text address lines, with country as the only reliable structured element | Still accepted for now, but on its way out on both Swift and SEPA |
| Hybrid | Town and country as structured elements, plus up to two free-text lines of 70 characters | Reasonable minimum for low-volume vendors and occasional payees |
| Fully structured | Each component, such as street, building number, postal code, town, subdivision and country, in its own element | Target for key suppliers, high-value corridors and in-house bank flows |
Take a supplier recorded in the ERP as “Unit 4, 18 Harbour Road, Cork T12 X7KP, Ireland”. This is how the same record looks in each format.
| Format | How the address is carried |
|---|---|
| Unstructured | Address line 1: Unit 4, 18 Harbour Road Address line 2: Cork T12 X7KP Ireland |
| Hybrid | Town: Cork. Country: IE Address line 1: Unit 4, 18 Harbour Road, T12 X7KP |
| Fully structured | Room: Unit 4. Building number: 18. Street: Harbour Road. Postal code: T12 X7KP. Town: Cork. Country: IE |
A practical sequence for the next six months
The extension is most useful to teams that treat it as a project window rather than a reprieve. The sequence below is the one we would recommend to most mid-market and large multinationals.
- Segment the vendor and beneficiary base. Rank records by cross-border payment value and volume over the last twelve months, then adjust for frequency, operational dependency and repair history. A logistics provider paid every week deserves attention before an equipment supplier paid once a year, even if its annual spend is lower.
- Retire what you do not use. Block or deactivate vendors with no payments in an agreed period. This shrinks the remediation scope and removes dormant records that fraudsters like to reactivate.
- Parse, then review. Use tooling to split addresses into components. Swift has released an open-source address structuring model that can help, but automated output still needs human review for the countries and formats where parsers struggle.
- Fix the front door. Change onboarding forms and vendor portals so that new records can only be created in structured form. Otherwise the problem rebuilds itself while you clean it.
- Control the change. Run mass updates through the same approval and logging controls as any other vendor master change, with independent sample checks before release. Keep a copy of the original data and record the source of every correction. Where the town or country is unclear, ask the supplier. The country of the beneficiary’s bank is not evidence of the country of the supplier’s address, and parsers that assume it will produce confident, wrong results.
- Confirm bank by bank and test. Obtain each bank’s channel requirements and timeline in writing, then test structured files end to end, including in-house bank and payment-on-behalf-of flows. Trace a sample of real payments from the vendor record to the message the bank receives, across each ERP and portal in use, and include one deliberately incomplete record so you know who receives the exception and how the corrected payment is resubmitted.
Progress needs measuring in the same way. A database completion percentage looks reassuring but says little about whether payments will go through. More useful measures are the share of active suppliers with verified town and country data, the number of payment interfaces tested successfully, and the volume of address-related repairs and screening holds, which should fall month by month.
Diagnostic checklist
If you cannot answer yes to most of the following, the deferral has bought you time you will need.
☐ We know which function owns address quality in the vendor master, and that ownership is written down.
☐ We have ranked our beneficiaries by cross-border payment value and know the address status of the top tier.
☐ Dormant vendors have been identified and blocked or deactivated.
☐ New vendor records cannot be created without town and country as separate structured fields.
☐ Each of our banks has confirmed in writing what address formats it accepts on each channel, and from when.
☐ We have tested structured payment files end to end, including in-house bank and payment-on-behalf-of flows.
☐ We know what happens to an incomplete address before release: who sees the exception and how the payment is corrected.
Frequently asked questions
Has Swift cancelled the structured address requirement?
No. Swift has deferred the payments changes in Standards Release 2026, including the removal of unstructured addresses, and is consulting the industry on new timing. The requirement itself remains, and structured and hybrid addresses can already be used across the network.
Is 12 June 2027 the new deadline for structured addresses?
No. 12 June 2027 is the implementation date for the deferred, non-payments parts of Standards Release 2026. The new timing for the structured address requirement is being set separately, with an update expected by December 2026.
Does the SEPA deadline still apply on 15 November 2026?
No. The European Payments Council postponed the 15 November 2026 end date for unstructured addresses across all five SEPA scheme rulebooks in September 2026. Individual banks may still apply their own requirements on corporate channels, so confirm directly with each one.
Should corporates aim for hybrid or fully structured addresses?
Hybrid is an acceptable minimum for low-volume vendors. Fully structured is the better target for key suppliers, high-value corridors and in-house bank flows, and it is the format the EPC recommends wherever possible.
FTI Treasury supports multinational corporations with payment operations, bank connectivity and in-house banking across 40 countries and 30 currencies. To discuss how structured address requirements affect your payment flows, explore our Back Office Services, Treasury Operations & Transformation, Technology and In-House Banking solutions, or contact our team.