On 27 August 2026, Swift confirmed what many payment operations teams had been quietly hoping for: the November 2026 cutover that would have ended fully unstructured postal addresses in cross-border payment messages was deferred, with timing to be confirmed by December 2026. The Federal Reserve moved its Fedwire Funds Service release from November 2026 to November 2027 on the same day. For banks, payment service providers and corporate treasuries, the obvious reaction is relief. The better reaction is to recognize what the delay actually exposed: the hard part of ISO 20022 was never the message format. It is the reference data that fills it.
Structured addresses, Legal Entity Identifiers (LEIs), purpose codes, country and currency codes, and the external code sets that ISO 20022 relies on are all reference data. They change on their own schedules, they are owned by different authorities, and they are copied into dozens of systems. This article explains what is changing, why the reference data layer is where most migrations stall, and how to build a governed reference data capability that turns the extra time into an advantage.
What Actually Changed in 2025 and 2026
A short recap helps, because the timeline has moved several times. In November 2025 the coexistence period for cross-border payment instructions on Swift ended, and payment instructions are now exchanged in ISO 20022 (MX) format, with Swift converting legacy MT instructions where needed. At the same time, Swift introduced the hybrid postal address, which lets senders combine structured elements with a limited amount of free text. Under the hybrid format, as J.P. Morgan’s migration guidance summarizes, Town Name and Country are mandatory, separate structured components, up to two address lines of 70 characters each are allowed, and structured data must not be repeated in the free-text lines.
The next step was supposed to be the removal of fully unstructured addresses in November 2026. Swift’s announcement explained that many firms across regions were still not ready and that several communities asked for more time; Swift also moved a deferred portion of its 2026 standards release for securities and trade to 12 June 2027 to avoid colliding with the European T+1 transition. J.P. Morgan’s guidance indicates that fully unstructured addresses may continue until at least November 2027, while the bank itself is keeping its own hybrid and structured address implementation on the original November 2026 date.
- Already live: ISO 20022 for cross-border payment instructions, hybrid addresses, and structured addresses flowing across the network for institutions that have upgraded.
- Deferred: the hard rejection of fully unstructured addresses, with Swift to confirm timing and approach by the end of 2026, and the Fedwire address change now planned for November 2027.
- Unchanged in direction: regulators and market infrastructures still expect richer, structured party data to support sanctions screening, anti-money-laundering controls and straight-through processing.
- Local rules still bite: some jurisdictions already demand complete addresses. J.P. Morgan notes, for example, that it will reject Canadian wires with incomplete remitter or beneficiary information under FINTRAC expectations.
Why Reference Data Is the Real Bottleneck
Most ISO 20022 programs were organized around messages: mapping MT fields to MX elements, upgrading payment hubs, testing with counterparties. That work is largely done. What remains is data that the message cannot invent. A pacs.008 can only carry a structured town name if the customer master holds one. It can only carry an LEI if someone captured, validated and renewed it. It can only carry a valid purpose code if the code list in the originating channel matches the version the receiving bank expects.
In most institutions, that data lives in several places at once: the core banking customer file, the KYC platform, the corporate onboarding portal, treasury management systems, beneficiary templates saved by customers years ago, and spreadsheets maintained by operations. Each copy drifts. Addresses are stored as three free-text lines because that was what MT103 field 50K allowed. Country names appear in local spelling rather than ISO 3166 alpha-2 codes. LEIs are captured once and never checked again, even though the registration may have lapsed.
The deferral did not remove the work; it moved the critical path from message mapping to reference data quality. Firms that treat addresses, LEIs and code lists as governed reference data will be ready whenever the cutover lands, and will get cleaner screening and fewer repairs in the meantime.
Structured Addresses: From Free Text to Governed Data
Address structuring is the most visible part of the problem, and it is harder than it looks. Customer addresses are full of edge cases: buildings without street numbers, rural locations described by landmarks, post office boxes, non-Latin scripts, and countries where the postal code precedes the town. A pure parsing approach will fail on a meaningful share of records, so the goal should be a repeatable pipeline rather than a one-off cleansing project.
A practical structuring pipeline
- Profile the population. Count addresses by channel, country and format. Identify how many already carry a clean town and ISO country code, how many are three-line free text, and how many are incomplete. This defines the size of the remediation effort.
- Extract town and country first. These are the mandatory elements in the hybrid format, so they unlock compliance even when the rest of the address stays in address lines. Swift has published a free, open-source AI address structuring model that infers town and country from unstructured text in debtor and creditor fields, returns confidence scores, runs offline inside your environment and, according to Swift, was trained on synthetic data rather than personal data.
- Validate against authoritative references. Check country codes against ISO 3166, and where possible check towns and postal codes against national postal or geographic reference files. Treat a low-confidence result as a task for a human, not as an answer.
- Write back to the golden record. The structured result must update the customer or beneficiary master, not just the outgoing message. Otherwise every future payment repeats the same inference.
- Close the front door. Change onboarding screens, APIs and file formats so new addresses are captured in structured fields from day one. Remediation without capture changes is a treadmill.
- Monitor continuously. Track the share of outgoing payments with fully structured, hybrid and unstructured addresses by channel, and track repairs and rejections from correspondents.
Swift itself notes that its model does not extract full postal addresses or handle agent fields, and that results may be unreliable for non-Latin scripts. That is a useful reminder that tooling accelerates the work but does not replace data ownership and stewardship.
The LEI and vLEI: Identity as Reference Data
Addresses describe where a party is. The LEI says who it is. The 20-character identifier, issued under ISO 17442 and overseen by the Global LEI Foundation (GLEIF) and the Regulatory Oversight Committee, gives each legal entity a single, public, standardized identity with reference data about its legal name, registered address and, where reported, its parent relationships.
In payments, the LEI has been steadily moving from optional to expected. In its response to the CPMI consultation on harmonized ISO 20022 requirements for cross-border payments, GLEIF argued that the LEI should be able to substitute for name and postal address in the same way a BIC can, and pointed to concrete precedents: the Reserve Bank of India has required LEIs for large-value RTGS and NEFT payments since April 2021, and the Bank of England uses the LEI to identify financial institutions in CHAPS with plans to broaden the requirement. GLEIF also highlighted why the BIC alone is not enough: a BIC routes messages, but one legal entity can have several BICs and one BIC can relate to more than one entity.
From LEI to verifiable LEI
The verifiable LEI (vLEI) extends the identifier into the world of digital credentials. An organization that already holds an LEI can obtain a Legal Entity vLEI credential from a Qualified vLEI Issuer, and then official organizational role credentials for people who act on its behalf. GLEIF lists nine qualified issuers on its site, and in March 2026 it published version 4.0 of the vLEI Ecosystem Governance Framework documents. For payments and treasury, the interesting use cases are cryptographically verifiable authorization of payment instructions, onboarding without repeated document checks, and signing of regulatory filings.
For reference data teams, the practical implications are straightforward:
- Capture the LEI as a first-class attribute for every legal entity customer, counterparty and beneficiary where one exists, with source, capture date and validation status.
- Validate against the GLEIF golden copy rather than trusting what customers type. GLEIF publishes the full data set and an API, so names, registration status and next renewal dates can be checked automatically.
- Monitor lapses. An LEI that has not been renewed still identifies the entity but signals stale reference data. Lapse status should feed onboarding and periodic KYC reviews.
- Use relationship data. Parent and ultimate parent records help with exposure aggregation and sanctions screening, and they make corporate hierarchies in the customer master auditable.
- Plan for credentials. Even if vLEI adoption is early, design identity data models so a verified credential can be linked to the entity and role records later without rework.
Code Lists: The Reference Data Nobody Owns
ISO 20022 messages are full of coded values: external purpose codes, category purpose codes, status reason codes, return reason codes, charge bearer types, and country and currency codes from ISO 3166 and ISO 4217. Many of these are published as external code sets that are maintained outside the message schema precisely so they can change without a new message version. That flexibility is useful for the standard and painful for implementers, because it means code lists change on a different cadence from the software that consumes them.
A simple example shows the risk. Bulgaria adopted the euro on 1 January 2026. Any system that hard-coded a mapping from country BG to currency BGN, or validated customer accounts against a static currency table, needed an update with an effective date and a transition rule for historical transactions. Changes like this are well publicized and still cause breaks, because nobody owns the code table and it exists in five places.
What good code-list management looks like
- One authoritative register for every external code set, holding the code, description, source authority, version, effective-from and effective-to dates.
- Subscription to sources. Someone is accountable for tracking ISO 20022 external code set releases, ISO maintenance agency updates, market infrastructure usage guidelines and correspondent requirements.
- Distribution by API or event, not by email attachment, so payment hubs, screening engines, channels and reporting systems consume the same version.
- Crosswalks with lineage. Internal product codes, legacy MT codewords and local scheme codes should map to ISO values in a maintained crosswalk, with history, so a regulator or auditor can see which mapping applied on which date.
- Impact analysis before release. A code change should trigger a check of which systems and reports consume it, and regression tests where the code drives validation or routing.
Operating Model: Who Owns Payments Reference Data
Technology is rarely the blocker. Ownership is. A workable operating model for ISO 20022 reference data usually has four layers. Business data owners in payments, KYC and treasury decide what the data must mean and how complete it must be. Data stewards in operations handle exceptions, low-confidence matches and customer outreach. A reference data platform team runs the hub that ingests external sources, maintains crosswalks and publishes data to consumers. And a data governance function sets policies, quality thresholds and change control across all of them.
The key decision is where the golden record for each domain lives. For parties, it is usually a customer or entity master with LEI, structured address and relationships. For codes, it is a reference data hub. Payment engines should consume from these masters rather than maintaining their own copies, and the masters should expose quality scores so channels can block or flag payments built on incomplete data before they reach a correspondent.
A Worked Example: A Mid-Sized Bank Uses the Extra Year
Consider a hypothetical regional bank that processes cross-border payments for corporate clients across Europe and Asia. Before the deferral, its plan was to rely on the hybrid format and a last-minute parsing exercise. With roughly a year of additional time, it restructures the program around reference data.
In the first quarter, the team profiles its customer and beneficiary records and finds that a large share of corporate customer addresses still sit in three free-text lines inherited from MT-era systems, while beneficiary templates saved in online banking are even less structured. It deploys an address structuring service, starting with town and country extraction, and routes low-confidence results to an operations queue. Corrected values are written back to the customer master and to saved templates.
In parallel, it adds LEI capture to corporate onboarding and runs a one-time match of existing corporate customers against the GLEIF golden copy using name, registered address and national registry identifiers. Matches above a confidence threshold are accepted automatically; the rest go to relationship managers. A nightly job checks LEI status and flags lapsed registrations for KYC review.
In the second half of the year, it consolidates purpose codes, return reasons and currency tables into a reference data hub with effective dating and publishes them to the payment hub, the screening engine and the online banking channel through an API. Dashboards show the share of fully structured, hybrid and unstructured addresses per channel, LEI coverage among corporate payers, and repair rates from correspondents. When Swift confirms the new cutover date, the bank is not starting a project. It is adjusting a threshold.
Pitfalls to Avoid
- Fixing messages instead of masters. Structuring addresses in the payment hub at send time creates invisible, unaudited inference that has to be repeated forever.
- Treating the hybrid format as the finish line. It reduces risk now, but the industry direction, including the Federal Reserve’s stated intention to remove fully unstructured addresses, points toward structured data.
- Ignoring saved beneficiaries and corporate files. Customer-maintained templates and bulk payment files are where unstructured data hides longest.
- Collecting LEIs without validating them. An unchecked identifier gives false comfort to screening and reporting teams.
- Letting each system keep its own code table. The next code change will break whichever copy was forgotten.
- Underestimating non-Latin scripts and local formats. Address tools and matching logic must be tested on the real distribution of countries in your book, not on a sample of easy cases.
Outlook: Reference Data as Payments Infrastructure
Over the next two years, several forces will push in the same direction. Swift will confirm a new date for retiring unstructured addresses. Market infrastructures such as Fedwire will align their own changes. The G20 cross-border payments agenda continues to emphasize harmonized data and better identifiers. And verifiable organizational credentials such as the vLEI are maturing from pilots toward production use cases in onboarding and authorization.
All of these depend on the same foundation: reference data that is authoritative, versioned, validated against external sources and distributed consistently. AI will help, especially for parsing addresses and matching entities, but it works best when it feeds a governed master rather than patching messages on the fly.
Conclusion
Swift’s deferral is a rare gift in a regulatory calendar that usually moves the other way. Institutions can spend it waiting for the next deadline, or they can use it to build a reference data capability for parties, identifiers and code lists that will outlast this migration. The second option costs about the same and pays back in fewer repairs, cleaner screening and faster onboarding. Start with a profile of your addresses and LEI coverage, appoint owners for every code list, and make the masters, not the messages, the place where payments data gets fixed.
How Hanoi Technology Can Help
Hanoi Technology designs and runs reference data hubs, address structuring pipelines and LEI validation services that help payments teams turn ISO 20022 requirements into governed, reusable data.
Further Reading
- Swift accepts community request to extend structured address migration – Swift
- Fedwire Funds Service November 2026 release rescheduled to November 2027 – Federal Reserve Financial Services
- ISO 20022 migration and November 2026 CBPR+ mandate – J.P. Morgan
- ISO 20022: The Swift AI address structuring model – Swift
- GLEIF response to CPMI consultation on ISO 20022 harmonisation – BIS
- Get a vLEI – GLEIF