ISO 20022 structured address requirements
For the team that owns a company master and has to defend it.
A stewardship queue, a CRM after a migration or a merger, a supplier file before a payment run, counterparty onboarding that has to survive an audit. Read the argument here, take the takeaways at the foot into your next vendor conversation, and send us a file when you want the same measurement on your own rows.
Regulatory deadlines · 1,842 words · every figure carries the population it was measured over
11 min read, last revised . 6 questions answered at the foot.
all 19guides →how every figure here was measured →On this page
What changes, and on what date
The date was 14 November 2026, and the requirement is published by Swift as part of the CBPR+ migration. On 27 August 2026 Swift delayed the November 2026 Swift Standards Release that carried it, at the industry's request for more time to prepare, and the Bank of England deferred its own CHAPS messaging release to match. The Bank's notice names no replacement date. Once the change takes effect, a cross-border payment message carrying a fully unstructured postal address for a payment party is not accepted.
The requirement is narrower than "fully structured", which is the detail most summaries drop. A hybrid address remains acceptable: the town name and the country are carried in their own structured elements, and the remainder of the address may stay as address lines. What the change stops accepting is the fully unstructured form, where the entire address sits in free-text lines with nothing separately identified.
That narrowing is why this is achievable and also why it is under-scoped. Extracting a town and a country from a free-text block sounds like a parsing exercise that a library solves. The reason it is not is that the fields are only correct if the address belongs to the party the message names, and a payment file's address column is the least maintained column in most systems.
Why a parser is not the deliverable
Swift itself publishes a free open-source address structuring model, so the generic parsing capability is available at no cost and is not something worth buying. Anybody selling you address parsing for this deadline is selling you the part that has already been given away.
The work that is left is verification, and it is a different shape. A structured address that parses cleanly and belongs to a different company is worse than an unstructured one, because it passes the network's validation and fails silently. The unstructured address at least announces its problem on the day of the change.
So the deliverable a payments team actually needs is a decision per party: this structured address is consistent with this named counterparty, this BIC, and this identifier, and here is the register page it rests on — or, this one cannot be repaired safely and here is the specific reason.
The identity work the change forces
Four consistency questions sit underneath every repaired address, and only the first is about formatting.
- Is the address structurable at all, and does the structured form preserve the original meaning rather than inventing a town that the free text implied but did not state.
- Does the named counterparty resolve to a registered legal entity, and is the structured address consistent with the address that entity's register publishes. A mismatch here is a finding, not a formatting failure.
- Do the identifiers agree. A BIC, an LEI and a company number attached to the same payment party should describe one entity, and where they do not, the disagreement is the most valuable output in the file.
- Is the name a former name, a trading name, or the name of a successor entity after a merger. Registers publish previous names with validity dates, and a payment party named under a name the company dropped in 2021 is a resolvable record rather than a broken one.
BIC to LEI, free and monthly
GLEIF and Swift publish a free monthly BIC-to-LEI relationship file. For anyone doing this work that is the single most useful open artefact in the space, because it turns a bank identifier — which a payments system always has — into a legal entity identifier, which the register-facing half of the problem needs, with no commercial licence in between.
Be precise about what that mapping gives you. It relates a BIC to the legal entity that holds it, which lets you check that the financial institution named in a message is the entity you believe it is. It does not identify the underlying commercial counterparty of a payment, and it does not verify that an account belongs to a company. Account ownership verification needs a payment service provider or an aggregator feed, and we have neither.
The LEI itself carries the other half. Its Level 1 record holds the legal address and the headquarters address, the legal form as an ISO 20275 code, and the registration details that link back to the register of incorporation. Where the LEI's registration has lapsed, that record is still the entity's identifier and its addresses should be read as of the last verification date rather than as of today — which matters more for this use case than for almost any other, because the address is the field being repaired.
Where the repair should refuse
The important design decision in an address repair pipeline is what it does when it is not sure, and the answer that survives the change, whenever it lands, is that it declines and says why.
In our own pipeline nothing binds below 0.90 confidence: A match below 0.90 confidence is unrepresentable. The record comes back as an abstention with a ranked shortlist instead. Applied here, that means a payment party whose entity cannot be established comes back as an exception with a ranked shortlist and the field that would settle it, rather than as a confidently structured address attached to the wrong company.
The measured behaviour that matters most for this workload is what happens when the input address is wrong, which in a payments file it frequently is — a trading address typed years ago, an office the company has since left. In the historical 50-record wrong-town fixture, 72% resolved and zero wrong bindings were observed. This is a measured adversarial sample, not a guarantee for every misleading description. False context degrades to an abstention rather than to a wrong answer, which is the property an address repair needs and the one a similarity-scoring matcher does not have.
The input shapes are the ordinary ones. A payment party carrying an LEI or a registration number decides deterministically at 100% (317/317) on the live-adjudicated fixture. A name with an address resolves on the postcode where there is one: 98.74% (313/317). A name with country and registered-town prose historically measured 99.37% (315/317), 95% CI [97.7, 99.8]. Historical 2026-08-29 recording with earlier identifier arrivals seeding the catalogue. This does not measure a business description, email footer or generic verification purpose alone. Two same-stem groups remained unresolved. Historical results on an internal UK fixture with a preloaded catalogue. The September 5 replay has no full-prompt-verified calls and cannot establish current calibration. No independent customer holdout or global coverage claim.
A sequence that works
Start with files and payment-party fragments rather than a live payment-network integration. The exceptions are what you need to see, and you can see all of them from an extract without touching the payment rail.
- Extract the payment parties from a representative period of real traffic, with your own reference on every row so the output joins back.
- Tier the file before spending anything: which parties carry an identifier, which carry a name and a usable postcode, which carry a name and a free-text address block, which carry a name alone.
- Resolve the parties, and treat the abstentions as the work list rather than as failures. Each carries a typed cause and the cheapest field that would settle it.
- Structure the addresses for the resolved parties, and check the structured form against the register's published address rather than only against itself.
- Produce an exception file with a reason per row, distinguishing an address that cannot be structured from a party that cannot be identified. Those are two different backlogs owned by two different teams.
- Attach the decision id to every repaired party, so that the repair can be explained after the change rather than only asserted before it.
What this does not do
It is not a payment-network integration and it does not send, validate or format messages. It resolves the counterparty behind a payment party and reports whether the identifiers and the address are consistent with a register; the message construction stays where it is.
It does not verify that a bank account belongs to a company, for the reason given above: that needs a payment service provider or an aggregator feed and we have neither.
It is not sanctions screening, and a payments compliance programme should not read a resolution as one. Scope is company and organisation identity only.
And the address a register publishes is a registered office, which is frequently not where a company trades and is sometimes an agent's address. Structuring it correctly makes it a valid ISO 20022 address; it does not make it the right address for a business purpose, and a project that conflates the two will produce clean messages and confused counterparties. A historical 2026-08-29 blend across six input shapes in a preloaded UK catalogue. Its value depends on that mix: truncated names measured 58.10% while the blend measured 95.75%. Neither establishes the current minimum-input target.
What to take away
- Fully unstructured postal addresses are being removed from CBPR+ cross-border payment messages. Town name and country must be structured; a hybrid address remains acceptable. The removal was scheduled for 14 November 2026 and Swift delayed it on 27 August 2026, so plan against the requirement rather than the date.
- Swift publishes a free open-source address structuring model, so parsing is not the deliverable. Verification is.
- A structured address attached to the wrong company is worse than an unstructured one, because it passes validation and fails silently.
- GLEIF and Swift publish a free monthly BIC-to-LEI relationship file, which turns a bank identifier into a legal entity identifier with no commercial licence in between.
- False context degrades to abstention rather than to a wrong answer: In the historical 50-record wrong-town fixture, 72% resolved and zero wrong bindings were observed. This is a measured adversarial sample, not a guarantee for every misleading description.
- Separate the exception types. An address that cannot be structured and a party that cannot be identified are two backlogs owned by two teams.
- A registered office is a valid address and is frequently not where the company trades. Structuring it correctly does not make it the right address for a business purpose.
Those takeaways hold for anybody's data. The number for yours comes out of your own rows — a few hundred of them, with the matches you already have beside them.
Start freePrefer to put it to a person? Talk to us instead →
Where this article is applied
3 pages name this method as the working behind what they claim.
Is this your file?
The article is for anyone. The measurement behind it is worth commissioning for one kind of team.
Teams with a company master they have to defend — an MDM or stewardship queue, a CRM after a migration or a merger, a supplier file before a payment run, or counterparty onboarding that has to survive an audit.
Buying breadth as the product: we hold a fraction of an incumbent’s records and are not building a global company graph. Entity Bind resolves companies and organisations only. It does not resolve people, vessels, bank-account ownership, sanctions exposure, emissions or geolocation, and its results may not be used for eligibility decisions about individuals, including employment, credit and tenancy.
Sources
The papers, regulators and registers this article quotes, each with the caveat that travels with it.
- Bank of England, “Delay to the November 2026 RTGS standards release”, 27 August 2026
Reports Swift's decision of 27 August 2026 to delay the November 2026 Swift Standards Release, which carried the removal of unstructured postal addresses from CBPR+, and defers the Bank's own CHAPS release with it. It gives no replacement date.
- GLEIF, BIC-to-LEI relationship files
Built on a mapping process established by Swift and certified by GLEIF, published as CSV and updated monthly. It relates a BIC to the entity that holds it, not to a payment's underlying counterparty.
- GLEIF, “The Legal Entity Identifier (LEI)”
The operator of the system, describing the twenty-character code and the four ISO 17442 principles it adheres to. It is GLEIF's account of the standard rather than the standard's own text.
Internal fixtures only. The historical 2026-08-29 per-tier recording covers 317 GB companies with identifier-rich arrivals seeding the catalogue first; the context tier includes country and registered-town prose. Its legacy replay has no full-prompt-verified calls and cannot certify current calibration. The September 5 CI reports cover 1,176 labelled pairs and 705 records over 250 companies using offline stubs. These are not independent customer holdouts or live production validation; the 99% minimum-input product target remains unmet. Scope is company and organisation identity only — not people, vessels, bank-account ownership, sanctions or emissions. Results may not be used for eligibility decisions about individuals, including employment, credit and tenancy.
Figures read off the product repository on 2026-09-05. The per-tier rates come from the live-adjudicated 317-company recording of 2026-08-29; the gate figures come from the stub-adjudicated continuous-integration run and are a floor rather than a ceiling. The two are never averaged. Entity Bind holds no SOC 2, no ISO 27001 and no other certification, and claims none. Every figure, with the population it was measured over and the method behind both recordings, is set out on the accuracy page. The retention, erasure, tenancy and sub-processor detail a security review asks for is under Trust and security, with where assurance stands: no external validation of the accuracy figures and no customer holdout.
The same measurement, on your own rows.
Create your workspace, verify your email and run your first company file. The Free plan needs no card. Create API keys in your workspace when you need an integration.
300 credits. No card.
For a guided review of your file, explore the Merge Safety Sprint →
The questions this article answers
What is the ISO 20022 structured address deadline?
It was 14 November 2026 until 27 August 2026, when Swift delayed the November 2026 standards release that carried it, at the industry's request for more time to prepare. The Bank of England's notice of the delay names no replacement date. When the change takes effect, fully unstructured postal addresses will not be accepted in CBPR+ cross-border payment messages: the town name and the country must be carried in structured elements. A hybrid address — structured town and country, with the remainder as address lines — remains acceptable. The requirement is published by Swift as part of the CBPR+ migration.
Is this just an address parsing problem?
No, and the parsing half has already been given away — Swift publishes a free open-source address structuring model. What is left is verification: establishing that the structured address, the named counterparty, the BIC and any company identifiers describe the same legal entity. A well-formed address on the wrong company passes the network's validation and fails silently, which is a worse outcome than the unstructured address it replaced.
What happens to a payment with an unstructured address?
Once the change takes effect, it is rejected by the network rather than by a counterparty, which is why treasury and payments teams treat this as an operations deadline rather than a compliance one. The practical consequence is that the failure is immediate and visible on the day, and the remediation queue is whatever your file could not repair beforehand.
Can you verify that a bank account belongs to the counterparty?
No. Account ownership verification needs a payment service provider or an aggregator feed, and we hold neither. What resolution contributes is the counterparty itself: the checks your bank or treasury system performs run against a registered company that has actually been identified, with a citation, rather than against a name in a field.
How do you handle a counterparty named under an old name?
As a register fact rather than as an inference. Companies House and several other registers publish former names with validity dates, and those are stored as facts on the entity with their own provenance. So a payment party named under a name the company dropped years ago resolves to the current entity with the register page carrying both names cited on the decision. This is a case string matching handles badly, because the two names are often not similar at all.
Should we start with a live payment integration?
No. Start with files and payment-party fragments from a representative period of real traffic. Every exception you need to see is visible in an extract, the tiering step tells you what the run will cost before you spend anything, and nothing has to touch the payment rail to produce the exception file that the remediation is actually driven from.