ISO 20022 Structured Address Migration: What Breaks on 15 November 2026
The EPC's 15 November 2026 inter-PSP settlement date and Swift's 14 November 2026 SR 2026 go-live are two different events on one cutover weekend. This walks an address population through seven gates, from scope to the inter-PSP double rejection duty, and states at each gate which records die and what the remedy is.
Updated
16 min read
266 views
Technically reviewed by Olena Zaichenko, D.Sc.
Key takeaways: ISO 20022 structured address migration 5
The two dates on one cutover weekend, why country and town are the enrichment priority, why the lazy hybrid shortcut fails, why warehoused files are already in scope, and why the reject duty is double.
- Two dates, one cutover weekend Swift's SR 2026 go-live lands 14 November 2026 and the EPC's inter-PSP settlement date lands 15 November 2026, biting at 03h30 CET for SCT Inst and OCT Inst. 22 November 2026 is superseded.
- Country and town are the enrichment priority Country and town are mandatory in both surviving formats, so a record missing either is an enrichment problem, not a formatting problem.
- The lazy hybrid shortcut is non-conformant Filling the structured fields and then dumping the original free-text address into AdrLine fails the no duplication rule, and Swift's public page does not say so.
- Warehoused files are already in scope A file uploaded weeks before the cutover with a requested execution date on or after 15 November 2026 must already carry a structured or hybrid address.
- The reject duty is double The Originator PSP must reject at initiation, and the Beneficiary PSP and intermediaries must reject or return in the inter-PSP space.
An ISO 20022 structured address migration is not a formatting exercise you finish over a long weekend, it is a population of address records shrinking gate by gate until only conformant ones cross into November 2026. If you hold free-text addresses in a core ledger, the job in front of you is to decide, record by record, what a parser can repair, what needs enrichment from another system and what has to go back to the customer as a return.
In short: from 15 November 2026, and from 03h30 CET specifically for the SCT Inst and OCT Inst schemes, the European Payments Council's inter-PSP settlement date closes the door on unstructured addresses (EPC153-22 v2.1, §6.3, p. 8 of 19). Swift's SR 2026 network go-live lands the day before, on Saturday 14 November 2026, a separate event on the same cutover weekend rather than a disagreement between the two bodies. Only two formats survive the cutover, fully structured and hybrid, and both make Country and Town Name mandatory. Hybrid also forbids repeating any structured element inside its free-text AdrLine field, killing the shortcut of filling the structured fields and dumping the original address into AdrLine anyway. Because the rule keys off the requested execution or collection date rather than the submission date, a file already sitting in a warehouse with a December due date can already be out of compliance.
Every address record in scope
Start with the largest population: every address that will travel inside an ISO 20022 payment message on a SEPA or CBPR+ rail. On the customer-to-PSP leg that means pain.001 credit transfer files and pain.008 direct debit files. On the inter-PSP leg it means pacs.008 credit transfer messages and pacs.003 direct debit collection messages. Both legs carry the same address structure rules, worth knowing before scoping a payment gateway integration: the cutover applies to the message field itself, not to one side of the rail.
Swift's own scope statement narrows the population before a single record gets tested: "From 14 November 2026, town and country information must be provided in designated fields, at a minimum, for all agents and parties in CBPR+ payment messages, except for ISO 20022 message identifiers admi.024, camt.025, camt.052, camt.053, camt.054 and camt.060" (swift.com, "Unstructured address data is being removed. Are you ready?", page level, retrieved 2026-08-04). Six message identifiers step outside the population entirely, and "For agents, use of the BIC only continues to be a valid option rather than providing name and address" (swift.com, same page, page level, retrieved 2026-08-04), so an agent identified purely by BIC never needs an address at all. What remains is still wide: the requirement applies "to all payments, including corporate, securities, trade, FX and funds" (swift.com, same page, page level, retrieved 2026-08-04), so a firm treating this as a SEPA-only concern is undercounting its own exposure.
| Field | Detail |
|---|---|
| Customer-to-PSP messages in scope | pain.001, pain.008 |
| Inter-PSP messages in scope | pacs.008, pacs.003 |
| Mandatory in both surviving formats | Ctry, TwnNm |
| AdrLine in fully structured | Not permitted, the data element cannot be used |
| AdrLine in hybrid | Up to two 70-character occurrences, none may repeat a structured element already mapped |
| Exempted ISO 20022 message identifiers (6) | admi.024, camt.025, camt.052, camt.053, camt.054, camt.060 |
The records that clear the cutover on your rail
Two dates govern this cutover and they measure different things. The EPC's is a settlement date: "only the use of the structured address and of the hybrid address will be allowed for Inter-PSP EPC payment messages where applicable" as of 15 November 2026, extending equally to PSU customer-to-PSP files, and "The use of an unstructured address will no longer be allowed and will hence lead to rejects" (EPC153-22 v2.1, §6.3, p. 8 of 19). The 03h30 CET qualifier belongs only to SCT Inst and OCT Inst; every other scheme bites at the ordinary midnight boundary.
Swift's date is a network go-live, one day earlier: the SR 2026 Standards MX Release, on 14 November 2026, the Saturday of the second full weekend of November. The EPC states its own alignment plainly: "This amended date is aligned with the November 2026 Swift Standards MX Release date scheduled in the second full weekend of November 2026" (EPC153-22 v2.1, §0.2 change history, row V2.1, p. 3 of 19). One cutover weekend, two units: a network release on the Saturday, a scheme settlement obligation on the Sunday, neither replacing the other.
A third date still circulates and it is dead. EPC153-22 v2.0 fixed the cutover at "As of 22 November 2026 (and as of 03h30 CET for the SCT Inst and OCT Inst schemes), only the use of the structured address and of the hybrid address will be allowed for Inter-PSP EPC payment messages where applicable" (EPC153-22, Version 2.0, §6.3, published November 2024), a version still live and search-reachable and also carried by a June 2025 ECB and ERPB status update, which is why the figure persists. It was replaced in v2.1: "the initially determined date of 22 November 2026 as of which the unstructured address format is no longer permitted, has been changed into 15 November 2026" (EPC153-22 v2.1 document-library page, "What changed" note, retrieved 2026-08-04).
Three format windows sit either side of that history: structured and unstructured alone up to 5 October 2025, all three formats including hybrid to 15 November 2026, then structured and hybrid only from that date. Hybrid's own lifespan note reads "No end date set for the time being" (EPC153-22 v2.1, §2 timeline table, pp. 4-5 of 19), a durable second option rather than a bridge with a known expiry.
The records that carry a country and a town
The first attrition on the data itself, not the rail. Country and Town Name are mandatory in both surviving formats. Fully structured states it as a pair, alongside a ban on the free-text field: "Data element 'Address Line' <AdrLine> cannot be used" and "Data elements 'Country' <Ctry> and 'Town Name' <TwnNm> must be used" (EPC153-22 v2.1, §4). Hybrid states the same pair as mandatory inside a looser structure: "The structured elements 'Country' <Ctry> and 'Town Name' <TwnNm> are mandatory" (EPC153-22 v2.1, §5, pp. 6-7 of 19). A record missing a resolvable country or town is dead under either target, an enrichment problem rather than a formatting one: no amount of parsing produces a country never captured anywhere in the source system.
Swift's own definitions match the EPC's element-level requirements exactly, country and town mandatory in both, AdrLine forbidden in structured, capped at two 70-character occurrences in hybrid. As retrieved on 2026-08-04, Swift's page does not state the rule governing how those fields interact with AdrLine in hybrid. This gate is also the highest-yield place to spend enrichment budget, on the EPC's own account of what the two fields are for: "Only the structured address fields 'Town' and 'Country' are needed for regulatory screening" (EPC153-22 v2.1, §6.4).
The records that pass the no duplication rule
This is the section most secondary coverage skips, and it breaks the obvious migration shortcut. Hybrid is not structured fields plus whatever free text a record already had. The EPC's own definition binds the two halves together: "It allows the combination of structured ISO 20022 address elements and up to two occurrences of 70 characters of unstructured 'Address Line' <AdrLine>. Elements available in a structured format must be mapped into the respective structured address elements" and "Structured elements cannot be repeated in the <AdrLine> elements" (EPC153-22 v2.1, §5, pp. 6-7 of 19). Together, those sentences forbid the default rushed-migration record: country and town copied into their structured fields, and the entire original address, town and country included, dumped unchanged into AdrLine. That record fails, even with every mandatory field populated, because the same information now appears twice.
Fully structured removes the ambiguity by removing AdrLine altogether: "Data element 'Address Line' <AdrLine> cannot be used" (EPC153-22 v2.1, §4). Swift's public page states the element-level shape of both formats but, as retrieved on 2026-08-04, does not carry the no duplication sentence, so a team building from Swift's page alone, without the EPC guidance behind it, will produce a hybrid record that looks conformant and fails the rule the page omits.
The records a parser can repair
Whatever survives the first two gates still splits three ways: repair by parsing, repair by enrichment or return to the customer. Swift is explicit that automated translation tools are not the first option as often as teams assume: "Translation tools work with pre-defined mapping rules and cannot map free text information to structured data elements. As such, they can only be used to create unstructured Postal Address fields which will not be allowed after November 2026" (swift.com FAQ, "A brief introduction to the Postal Address field", page level, retrieved 2026-08-04). The same page names a corruption pattern worth testing for: "critical data quality challenges when the end of a name that exceeds 35 characters is mapped into the first line of the Postal Address" (swift.com, same page, page level, retrieved 2026-08-04).
Routing a given record into one of the three branches is engineering judgment, not a rule stated in the EPC or Swift text. A record missing a resolvable country or town belongs in enrichment, not parsing, because Ctry and TwnNm are mandatory in both surviving formats and no amount of parsing invents a value the source system never captured. A record that already carries a usable country and town, and only needs its free-text line reshaped, is a parsing candidate, but not by translation tooling, since that tooling works on predefined mapping rules and cannot map free text to structured elements, and a name field over 35 characters risks corrupting the first address line on the way through. Anything a parser cannot resolve with confidence, and enrichment cannot fill from another system, is a return to the customer rather than a guess.
The EPC's own recommendation skips the middle option: "the EPC nevertheless recommends that EPC payment scheme participants and PSUs use the time up to November 2026, as an opportunity to start right away with the switch from unstructured addresses directly to fully structured addresses" (EPC153-22 v2.1, §6.5, pp. 8-9 of 19). Hybrid is a legitimate destination, not a mandatory stepping stone, and building straight to fully structured avoids the no duplication trap above by removing the field that trap depends on.
The scale still needing repair is not small: "Today, approximately 65%of payment messages still contain unstructured addresses" (swift.com FAQ, "ISO 20022: The removal of unstructured address", page level, retrieved 2026-08-04), a figure the page attaches no measurement date to beyond "Today", so cite it with the retrieval date. A separate figure describes a different population and must not be merged with the first: "Approximately 65 MIs do not yet have plans to align timelines" (swift.com, same page, page level, retrieved 2026-08-04), market infrastructures rather than messages.
The records already sitting in the warehouse
This half of the migration is the one most teams miss, because it does not read like a deadline problem. §7.4 addresses a file already submitted, days or weeks in the past, carrying a future execution date: "Originators/Creditors/Payers may submit respectively pain.001 (SCT (Inst); OCT Inst) and pain.008 (SDD) payment files days or even weeks before 15 November 2026, with the AT-T013, 'Requested Execution Date' (OCT Inst, SCT and SCT Inst) or 'Requested Collection Date' (SDD Core and SDD B2B), as of that November 2026 entry-into-force date. Such initial files may have been submitted with an unstructured address" (EPC153-22 v2.1, §7.4, p. 15 of 19). This is the customer-to-PSP space, a PSU uploading to its own bank, not a bank forwarding to another bank.
The operative rule states plainly that the upload date does not save the record: "when (files of) EPC payment scheme instructions bear a requested ('execution' or 'collection') date as of 15 November 2026, the address(es) in these EPC payment instructions concerned must be either in a hybrid or in a structured format. The reason is that as of 15 November 2026, all relevant systems and applications of the other EPC payment scheme participants and of the Inter-PSP actors, will reject EPC payment scheme transactions when containing an unstructured address" (EPC153-22 v2.1, §7.4 Guidance, p. 16 of 19). A standing order filed weeks in advance is already in scope the moment its execution date crosses into November.
The remedy is deliberately soft, a "should" rather than a "must": PSPs are guided to "perform internal checks on SCT (Inst)/SDD/OCT Inst payments files received with an AT-T013 ('Requested Execution Date' or 'Requested Collection Date') as of 15 November 2026, registered in their payment transaction warehouses (e.g., for SCT standing orders, SDD Collection files sent 14 calendar days before due date) to ensure that the provided addresses are not in an unstructured format" (EPC153-22 v2.1, §7.4 Guidance, p. 16 of 19), and beyond that check handling is case by case: "It is up to each Originator PSP/Creditor PSP/Euro Leg-Based Payer's PSP how to handle such specific pain files on a case-by-case basis with each PSU concerned" (EPC153-22 v2.1, §7.4 Guidance, p. 16 of 19). No hard reject duty attaches directly, which is why a warehouse audit before November is worth more here than at almost any other gate covered above.
The records that make it through the double gate
The other half of the turn is sharper. §7.2.1 puts the reject duty on two separate parties for the same transaction. On the originating side: "For all SCT (Inst) Instructions in pain.001 messages to be executed or settled as of 15 November 2026 and containing Originator and/or Beneficiary addresses, the concerned address(es) in these Instructions must be structured or hybrid. If not, the Originator PSP must reject the SCT (Inst) Instructions concerned" (EPC153-22 v2.1, §7.2.1, "As of 15 November 2026", p. 10 of 19). Downstream, a second duty falls on different actors: "The other Inter-PSP space actors and/or the Beneficiary PSP must reject/return all SCT (Inst) Transactions to be executed or settled as of 15 November 2026 when such Transactions contain an unstructured address of the Originator and/or of the Beneficiary" (EPC153-22 v2.1, §7.2.1, p. 10 of 19). Two parties, one record, and neither duty substitutes for the other.
§7.5 covers a different scenario and must never be merged with §7.4's warehouse case above: a PSP, rather than a PSU, forwarding a message early. "Originator PSPs, Creditor PSPs and Euro Leg-Based Payer's PSPs may submit respectively pacs.008 (SCT (Inst), OCT Inst) and pacs.003 (SDD) payment messages to the next party in the Inter-PSP space, some days before the entry-into-force date of 15 November 2026, with an execution date as of 15 November 2026. SCT (Inst), SDD and OCT Inst transactions in these files may still contain unstructured addresses" (EPC153-22 v2.1, §7.5, p. 16 of 19). The remedy is not a "should"-level check, it is a hard consequence: "the Beneficiary PSP/Debtor PSP/Euro Leg-Based Payee's PSP or Euro Leg Exit PSP will only accept, execute/collect such payments when all provided addresses are structured or hybrid. The presence of an unstructured address in such payment will lead to a reject/return of that payment" (EPC153-22 v2.1, §7.5 Guidance, p. 16 of 19). §7.4 is a customer-facing, soft-remedy space. §7.5 is an inter-PSP, hard-reject space. A record can clear one and still die at the other.
One honest limit closes this gate: no source fetched for this article names an ISO reject reason code for a non-conforming address, on either side of this double gate, and none is offered here. The reject and return duty is stated without a code attached, and confirming a specific code is a question for a scheme member's own connectivity service manager and its correspondents, not something this article can settle from the public documents behind it.
The records you can prove conformant before the cutover
What an evidence set looks like before November is not complicated to describe, even where it is not simple to build: a per-gate count of records missing a country or town, hybrid records duplicating a structured element inside AdrLine and warehoused files carrying a future execution date against an unstructured address. Each count maps onto a gate covered above, turning the no duplication rule from a code-review comment into an actual test case, and belongs in any FinTech compliance checklist a payments team is already running.
Swift's Test Sparring Partner catalogue is worth naming for what it is and is not. Its own description reads "CBPR+ ISO 20022 with hybrid or structured address (unstructured addresses are NAKed)" (swift.com, "ISO 20022 in bytes for payments: Call-to-action for November 2026", page level, Test Sparring Partner catalogue description, retrieved 2026-08-04), and that line describes a test environment, not a production rule in its own right. Treated as strong evidence of the production behavior Swift intends to enforce, it is a useful pre-cutover check: a message NAKed in that catalogue today is telling a team what a live message will do in November.
Swift's own account of the stakes is blunt: "After November 2026, payments containing unstructured addresses will no longer be supported. This may result in operational disruption for banks and their customers if preparations are not completed in time" (swift.com news, "ISO 20022 milestone for November 2026: Unstructured addresses to be removed", page level, retrieved 2026-08-04). The EPC's own change history records that its move from the superseded date discussed above left participants "will thus have one week less in 2026 to make the switch" (EPC153-22 v2.1 document-library page, "What changed" note, retrieved 2026-08-04). A build plan drafted against the superseded 22 November figure is already a week short before it starts. Turning a per-gate audit into a working test suite is where payment solutions development work earns its keep, particularly for teams whose core ledger was never designed around structured address fields.
How Pharos Production helps
The population this article walks through gate by gate is also the shape of the engagement: a per-gate count of records missing a country or town, a conformance test run against the two surviving format definitions rather than one flat schema, the no duplication rule turned into an automated test case instead of a manual review step, and a warehouse audit of files carrying a requested execution or collection date on or after 15 November 2026. Our FinTech development services team builds the parsing pipelines that separate what a machine can repair from what needs a human decision, the enrichment integrations against address and geocoding data sources, and the conformance tests that check every gate above as code, ahead of the cutover.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 7
No matches
Try a different keyword, change the topic or clear filters
-
From that date, and from 03h30 CET for the SCT Inst and OCT Inst schemes, only structured and hybrid addresses are allowed in inter-PSP EPC payment messages and in customer-to-PSP ISO 20022 XML files. An unstructured address leads to rejects (EPC153-22 v2.1, §6.3, p.
8 of 19).
-
Both, and they are different events on the same cutover weekend. Swift's 14 November 2026 is the SR 2026 network go-live, the Saturday of the second full weekend of November.
The EPC's 15 November 2026 is the inter-PSP settlement date from which a SEPA transaction carrying an unstructured address must be rejected. The EPC describes its own date as aligned with the Swift release weekend (EPC153-22 v2.1, §0.2 change history, p. 3 of 19).
-
No. It belongs to EPC153-22 v2.0 and was replaced by 15 November 2026 in v2.1. The old date persists because v2.0 is still live on the EPC site and a June 2025 ECB and ERPB status update also still carries it.
-
No. In hybrid, structured elements cannot be repeated in the AdrLine elements, and elements available in a structured format must be mapped into the structured elements instead. In fully structured, AdrLine cannot be used at all (EPC153-22 v2.1, §5 and §4).
-
Yes. A requested execution or collection date on or after 15 November 2026 forces a hybrid or structured address regardless of when the file was submitted.
The upload date does not save the record (EPC153-22 v2.1, §7.4 Guidance, p. 16 of 19).
-
Two parties, on two different duties. The Originator PSP must reject the instruction at initiation, and the other inter-PSP actors and the Beneficiary PSP must reject or return the transaction (EPC153-22 v2.1, §7.2.1, p.
10 of 19).
-
No primary source held for this article names one. The EPC guidance states the reject and return duty without naming a code.
Confirm the code with your connectivity service manager and your correspondents rather than assuming one.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
