ISO 20022 structured address requirements, and who has to meet them

The ISO 20022 structured address requirements are short. Every party's postal address carries at least theCountry and the Town Name in their own elements; street, building number and post code go in their own elements wherever the bank has them; and free text is allowed only in at most two Address Lines of 70 characters (a "hybrid" address) or not at all (a "fully structured" one). What the requirements change is not the payment message but the place every message copies its addresses from: the client and beneficiary master, where decades of addresses sit as blocks of free text. Botminds' ISO 20022 Structured Address Remediation exists for that master: agents split each address into fields, prove each field from a source, and a maker and a checker sign every change. This guide sets out what each rulebook asks and, more usefully, who inside a bank has to deliver it.

What are the ISO 20022 structured address requirements?

The common baseline is Requirement 11 of the harmonised ISO 20022 data requirements that the BIS Committee on Payments and Market Infrastructures (CPMI) set for cross-border payments in 2023 and updated in February 2026. Its solution is one sentence long: "Provide structured postal address information, avoiding unstructured, free-formatted address options wherever feasible." It names Country and Town Nameas the minimum required attributes and recommends adding Street Name, Building Number and Post Code "to the extent possible, as they may be required under applicable law along the end-to-end cross-border payment chain" (CPMI, updated report, February 2026). In the CPMI's own data model, Town Name and Country are marked required, Post Code recommended, and the Address Line element, which ISO 20022 allows seven times, is cut to two (CPMI, 2023 report, Table A2.1).

Three practical rules follow from that baseline, and the Bank of England's CHAPS rules spell out all three. A fully structured address has no Address Line at all. A hybrid address keeps Town Name and Country structured and may add up to two Address Lines of 70 characters. And nothing that sits in a structured element may be repeated in the free text. The hybrid or fully structured comparison works through those rules with examples; the point here is that they are rules about data a bank must already hold in pieces.

Character set matters too. Cross-border messages are held to a restricted Latin set, so an address held in Cyrillic, Chinese or with German umlauts has to be transliterated somewhere before it can travel. That, again, is a property of the stored address, not of the message.

Which networks set the dates, and how far do they agree?

They agree on the target and disagree on the calendar, and in 2026 the calendar moved. The BIS reported in May 2026 that from November 2026 a postal address in a cross-border message would have to be fully structured or hybrid (CPMI Brief No 13). On 27 August 2026 Swift announced a delay to that release, and the Bank of England now expects the removal of unstructured address fields to move into its November 2027 release, subject to confirmation (Bank of England). The same day, the Federal Reserve rescheduled the Fedwire release that brings the hybrid format to November 2027 (Federal Reserve Financial Services).

The differences that remain are of detail, and they matter to whoever builds the message. Until its 2027 release, Fedwire supports only fully structured or fully unstructured addresses for the debtor, creditor and their agents, so a hybrid address that is acceptable on a cross-border message is not yet accepted there. The full timeline, and how to plan around a date that is still settling, is in the structured address deadline guide.

Who has to meet the structured address requirements in a bank?

Whoever owns the data the message is built from. A payment hub can reformat what it is given, but it cannot invent a town that was never stored on its own. The CPMI says so in its section on implementation effort: "Persons, entities and FIs involved in cross-border payments – especially those FIs initiating payments – may need to update their systems and processes to collect, store and manage address information in a different, more structured way" (CPMI, 2026).

The Bank of England went further when it set its CHAPS rules, listing the channels a sending bank controls and must therefore clean: "This includes data received via online banking, direct file submission from a corporate client, and existing internal data (e.g. from an internal CRM solution)" (Bank of England, additional guidance). In a US bank the same list reads: the beneficiary master behind wire templates, the client master behind the debtor field, the treasury management portal where corporate clients keep their payees, and the branch forms that fed all three.

Why are payment addresses unstructured in the first place?

Because for most of the history of wire payments there was nowhere structured to put them. The fully unstructured ISO 20022 option, kept so that messages could carry what older formats carried, is three free-text lines of 35 characters. Templates were built to fill those lines, clients typed into them, and the master kept whatever the template needed. A US bank's beneficiary master therefore holds addresses as they were keyed for a message, often years ago, from client files, branch forms and bulk loads of old wire templates.

The clients' own systems are part of the problem. The BIS notes that "data quality issues further complicate progress, as many corporates are still in the process of upgrading their ERP systems to conform to ISO 20022 standards" (CPMI Brief No 11, April 2026). A corporate payee file exported from an older ERP arrives as text, and a bank that loads it as text inherits the same problem a year later.

The result is a master in which the same pattern repeats: a town buried inside a line, a post code glued to a city, a country spelled out in full, a district where the town should be, and placeholders such as "SAME" or "NOT PROVIDED" that satisfied a field once and never meant anything.

What the address steward decides that nobody else can

The steward decides what counts as proof. A parser can split "80331 MUENCHEN" into a post code and a town; only a policy can say whether postal reference data alone proves the town, whether a structured message from the payee's own bank outranks the master, and what happens when two sources disagree. Without that policy every analyst decides privately, and the same payee comes out differently on different days.

Examiners already expect someone to hold such decisions. The FFIEC describes data governance as "a set of processes for formally managing data assets throughout the entity" that "establishes authority, management, and decision-making parameters related to the data", and adds that "in smaller or less complex entities, these functions may be included in the responsibilities of a business line manager" (FFIEC IT Examination Handbook, Architecture, Infrastructure, and Operations, 2021). For the address master, that business line is payments operations.

In practice the steward's policy is a short list of settings: the confidence above which a batch can go to a checker, the level below which a person always decides, whether a post box with no street needs a person, whether hybrid is allowed only when the street cannot be proven, the sample a checker must read, and how long a payee may sit unpaid before it is retired instead of cleaned. In the solution's sample data those settings are 95%, 80%, yes, yes, 25 per batch of up to 2,000, and 24 months.

The payment message is the last place an address can be fixed, and the worst: by then nobody can ask the client, and nobody is accountable for the answer.

Who signs off a master data change?

Two people, and neither of them is the one who wrote the change. Address changes alter what goes into every future payment to that party, and they can change a sanctions screening result, so they deserve the same maker-checker discipline as a change to the payee's account number. The maker proposes or approves a single address; a checker who did not make it approves it, or approves a batch after reading a sample; and the value before and after is kept beside the evidence.

A batch sign-off is only defensible if the checker can say why the sample was enough. Risk-weighting it, so that it covers every high-volume country, the hard patterns such as post boxes and districts, the largest payees and the lowest confidences, is what turns "I looked at some" into a sample an auditor can re-perform. At the bank in the solution's sample data, a batch of 1,900 beneficiary addresses is approved after the checker marks 25 correct; one wrong item holds the whole batch and widens the next sample to 80.

Who changed which address, why, and on what evidence

How many addresses need remediation, and how many should be retired instead?

Fewer than the master holds. The first decision is which addresses are worth cleaning at all, and the payment archive answers it: a payee nobody has paid in two years needs to be retired, not structured. In the solution's sample data (Corvane National Bank, a fictional bank with fictional clients), 9,870 of 61,900 beneficiary addresses, about one in six, are proposed for retirement instead of repair.

Where each beneficiary address stands, in one band

The share that needs a person is the number that decides staffing. If the agents can prove most addresses from the bank's own payments and postal reference data, the human work is the hard remainder: disagreeing sources, unclear towns, post boxes, text that is not an address at all. In the sample that remainder is about 2% of the master, and the field-to-source map explains which sources prove which fields.

Is address remediation an IT or an operations job?

Both build it; operations owns it. IT owns the extract, the load and the connection to the payment hub and the screening system. Operations owns the decisions: which address is right, when a client must be asked, which payee is dormant. Compliance owns the question of how much address the bank sends beyond the minimum. The Federal Reserve's own checklist for its address change puts that question to legal: "Confirm with your legal and compliance teams whether additional postal address requirements (beyond minimum of town name and country) should be provided" (Federal Reserve Financial Services, January 2026).

Programmes that treat the work as a format conversion tend to stall at the same point: the converter runs, a fraction of addresses fails, and the failures land in a spreadsheet with no owner. The BIS makes the general point about the migration as a whole: adopting ISO 20022 messages does not by itself raise straight-through processing, which also takes reworked operations and digital payment channels (CPMI Brief No 11; the STP rate and the cost of a repair quotes the passage).

Where Botminds' ISO 20022 Structured Address Remediation fits

The solution works on the master, not on the message. Seven agents read the client and beneficiary addresses, split them into elements, prove each element from postal reference data, the payments the bank has exchanged with that party and the invoices and forms in document imaging, check the network rules, and screen the result in test mode. An analyst sees the address as it sits in the master beside the fields it becomes, each with its source, and approves as maker; a checker signs, singly or by sampled batch. Addresses the bank cannot prove go to the client once, pre-filled, through the treasury management portal.

It does not replace the payment hub's formatting, the screening system or the steward's policy. It does not decide a sanctions match, retire a payee or change the master without the two signatures. And it does not settle the compliance question of how much address to send beyond the minimum; it carries whatever the bank's policy says. What it changes downstream, from screening to payment templates, is covered in what moves when an address is structured.

Questions people ask

Is ISO 20022 mandatory?

For the payment systems that have migrated, yes: Fedwire has run on ISO 20022 since 14 July 2025, and cross-border payment instructions between banks moved to ISO 20022 when the MT coexistence period ended in November 2025. The structured address rules are a further step inside that standard, with their own dates per network.

What is address remediation?

It is the work of turning the free-text addresses in a bank's client and beneficiary master into structured fields that meet the ISO 20022 rules, and proving each field is right before it is loaded. It covers parsing, verification, asking clients for what cannot be proven, retiring dormant payees and signing each change.

Do domestic Fedwire payments need the creditor's postal address?

Fedwire's own format does not require it: the Federal Reserve says its specifications "do not require the creditor’s postal address in a pacs.008 and pain.013 message" (Fedwire ISO 20022 format FAQ). It sends the question to each bank's compliance and legal teams and to the receiving bank, whose own rules may require it.

Is a BIC enough instead of an address?

For a financial institution, often yes: Fedwire does not require a name and address for an agent identified by its BIC, and the CPMI lets a BIC or LEI stand in for an entity's name and address. For a person, no identifier replaces the address, and the revised FATF Recommendation 16 still expects at least the beneficiary's town and country.

Do the requirements cover our own customers as well as their payees?

Yes. The debtor's address in an outgoing payment comes from the client master, and the creditor's from the beneficiary master or the client's template. In the solution's sample data, about three in ten of the payments that would fail the new rules did so because of the client's own address, not the payee's.

How long does remediation take?

It depends less on the size of the master than on how many addresses need a person and how fast clients answer. The fictional bank approves about 2,310 beneficiary addresses a business day once batches start; client replies set the finish. The deadline guide lays out a plan stage by stage.