ISO 20022 Structured Address Migration

Skip key takeaways

Key takeaways: ISO 20022 structured address migration 5

Updated August 4, 2026

What actually changes on the two November 2026 dates, which two fields are mandatory in every surviving address format and why a file already sitting in the warehouse can already be in scope.

• Two dates, one cutover weekend: Swift's SR 2026 go-live on 14 November 2026 and the EPC's inter-PSP settlement date of 15 November 2026, which bites at 03h30 CET for SCT Inst and OCT Inst. 22 November 2026 is superseded The two dates do not conflict. They measure a Saturday network release and a Sunday settlement date on the same cutover weekend, and the EPC states its own date is aligned with the Swift release. The earlier 22 November 2026 date belongs to an older version of the guidance and still circulates because that version remains published elsewhere.
• Country and town are mandatory in both surviving formats, so a record missing either is an enrichment problem and not a formatting problem Both the fully structured and the hybrid formats require the same two elements, so a record with no resolvable country or town fails under either target and no format choice saves it. The EPC also states that only these two fields are needed for regulatory screening, which is where enrichment budget earns most.
• Filling the structured fields and then dumping the original free-text address into AdrLine is non-conformant, and Swift's public page does not tell you that The hybrid format requires every element available in structured form to be mapped into structured fields and forbids repeating those same elements inside the free text address lines. A mapper built from Swift's page alone can ship that shortcut and still look conformant at element level, because Swift's page states no equivalent rule.
• 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 governing date is the requested execution or collection date on the instruction rather than the date it was submitted. Standing orders and scheduled collections are exposed earliest, because their instructions were authored long before this guidance existed.
• The rejection 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 Originator PSP that lets a non conforming instruction through has already broken its own duty, and the same instruction can still be rejected or returned further down the chain days later. Enriching an address from records the PSP already holds is contemplated. Passing through free text unchanged is not.

Copy takeaways

If your ledger holds addresses as free text and the November 2026 cutover is closing in, we can help you build the parse, enrich and return routing before the deadline arrives.

See our FinTech development services

An ISO 20022 structured address becomes the entry condition for an EPC payment scheme message on 15 November 2026. If your core ledger holds addresses as free text, the work ahead is a record by record adjudication: which rows a parser can split, which need enrichment from elsewhere, which go back to the customer and which you reject at initiation.

In short: EPC153-22 v2.1 §6.3 (p. 8 of 19) sets the cutover at 15 November 2026, biting at 03h30 CET for the SCT Inst and OCT Inst schemes rather than at midnight. Swift's 14 November 2026 is a different event, the SR 2026 network go-live on the Saturday of the second full weekend of November, and the EPC calls its own date aligned with that release weekend. Two formats survive, fully structured and hybrid, and both make Country <Ctry> and Town Name <TwnNm> mandatory. Hybrid permits two 70-character Address Line occurrences, but §5 forbids repeating structured elements inside them, which is what makes the commonest migration shortcut non-conformant. And the deadline is already behind you: a pain.001 uploaded weeks early with a requested execution date on or after 15 November 2026 must already hold a structured or hybrid address.

Every address record in scope

The population is larger than the pacs.008 flow most programs scope first. Customers send pain.001 for SCT, SCT Inst and OCT Inst and pain.008 for SDD, while PSPs forward pacs.008 and pacs.003 in the inter-PSP space (EPC153-22 v2.1, §7.4 and §7.5, pp. 15 and 16 of 19). The ban reaches both halves: §6.3 covers "Inter-PSP EPC payment messages where applicable, and for PSUs when they send electronic Customer-to-PSP files based on ISO 20022 standard-based XML payment messages". A program aimed only at the outbound message misses the file the customer uploaded, which is why this belongs with payment gateway integration cost and not in a compliance line item.

The cross-border rail carves out more than most summaries admit:

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. For agents, use of the BIC only continues to be a valid option rather than providing name and address.

Six exempted identifiers and a BIC-only option for agents is attrition before you touch a record. Nothing else drops out: the requirement "applies to all payments, including corporate, securities, trade, FX and funds". Page level, retrieved 2026-08-04: Swift publishes no clause numbering.

The records that survive the date on your rail

Two dates sit on one cutover weekend and they are different events. The EPC's is a settlement date:

As of 15 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, and for PSUs when they send electronic Customer-to-PSP files based on ISO 20022 standard-based XML payment messages ... The use of an unstructured address will no longer be allowed and will hence lead to rejects.

Read the parenthesis. The 03h30 CET qualifier attaches to SCT Inst and OCT Inst and to no other scheme: a date-only implementation is wrong for the instant schemes, a blanket 03h30 rule wrong for the rest.

Swift's date is a network release date: "From 14 November 2026, the fully unstructured messages may be rejected or delayed, in line with the deadline set by the payments community through the Payments Market Practice Group (PMPG)." That is the SR 2026 go-live. The EPC's change history at §0.2 (p. 3 of 19) states the relationship:

Throughout the document, the earlier communicated date of 22 November 2026 as of which the unstructured address format is no longer permitted, has been changed into 15 November 2026. This amended date is aligned with the November 2026 Swift Standards MX Release date scheduled in the second full weekend of November 2026.

There is no disagreement to reconcile, only two units: a network release on the Saturday and an inter-PSP settlement date on the Sunday. The 22 November 2026 date belongs to EPC153-22 v2.0 and is superseded, still circulating because v2.0 is live on the EPC site and a June 2025 ECB and ERPB status update carries it.

The v2.1 timeline table (pp. 4-5 of 19) sets three windows: structured and unstructured up to 5 October 2025, all three formats until 15 November 2026, then structured and hybrid. Hybrid survives with "No end date set for the time being", a landing zone with no published expiry rather than a destination.

The records that carry a country and a town

Now the first attrition on the data itself, the expensive one. Both surviving formats make the same two elements compulsory. EPC153-22 v2.1 §4 on fully structured:

Data element "Address Line" <AdrLine> cannot be used • Data elements "Country" <Ctry> and "Town Name" <TwnNm> must be used • All other data elements may be used depending on the components of the address.

Section 5 makes the same two mandatory in hybrid. A record with no resolvable country or no town name therefore fails under either target, and no format flip saves it. That is an enrichment problem living in whatever system does know the town, and the one gate whose remedy is data acquisition rather than mapping code.

The EPC says where enrichment budget earns most, at §6.4: "Only the structured address fields 'Town' and 'Country' are needed for regulatory screening." Everything parsed beyond those two is correctness work.

Records that survive the no-duplication rule

Here is the gate most secondary coverage does not have, and it kills the shortcut nearly every team reaches for first. EPC153-22 v2.1 §5 (pp. 6-7 of 19):

The hybrid address is a mix of structured and unstructured address details. 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. The structured elements "Country" <Ctry> and "Town Name" <TwnNm> are mandatory. Structured elements cannot be repeated in the <AdrLine> elements.

Two sentences do the damage. The mapping duty makes structured population mandatory wherever the source data supports it, and the no-duplication sentence forbids leaving a copy behind. The shortcut, filling <Ctry> and <TwnNm> from your best parse and then dumping the original free text into the two AdrLine occurrences so nothing is lost, fails on both counts: town and country are repeated in AdrLine, and the street and building number were available in a structured format and were not mapped.

Swift's page, as retrieved on 2026-08-04, states the element-level rules identically, and no equivalent of the no-duplication rule appears in its text. A team that builds its hybrid mapper from that page alone will ship the shortcut and believe it conforms, because at element level it does.

The records a parser can repair

Of the population surviving that gate, the question is which repair route each record takes. The three-way split is our framing rather than the EPC's: parse it, enrich it or hand it back.

Parsing is narrower than it looks, and Swift is direct about the tooling most institutions already own:

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. They also cause other critical data quality challenges when the end of a name that exceeds 35 characters is mapped into the first line of the Postal Address.

Run the 35-character check against your own data first. An overflowing name does not produce an obviously broken address, it produces a plausible one whose first line is a fragment of a name, which a downstream parser will map into a street without complaint.

Handing a record back is the slowest route, which is why the EPC recommendation at §6.5 (pp. 8-9 of 19) is worth taking seriously: "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."

Routing through hybrid first means asking the same customer twice.

Two numbers from Swift's FAQ pages set the context, and both read 65 while measuring different things. On message traffic: "Today, approximately 65%of payment messages still contain unstructured addresses". The missing space is on the page, and the figure carries no measurement date beyond "Today", so read it as of the 2026-08-04 retrieval.

Separately, on infrastructures: "Approximately 65 MIs do not yet have plans to align timelines".

Records already sitting in the warehouse

Payment files already sitting in your warehouse are exposed to this rule before the November deadline formally arrives. EPC153-22 v2.1 §7.4 (p. 15 of 19) describes exactly that file: Originators, Creditors and Payers "may submit respectively pain.001 (SCT (Inst); OCT Inst) and pain.008 (SDD) payment files days or even weeks before 15 November 2026" carrying a requested execution or collection date on or after that date.

The same provision continues: "Such initial files may have been submitted with an unstructured address of the Originator or the Beneficiary, the Debtor or the Creditor, the Payer or the Payee."

The operative rule closes the same section's guidance at p. 16 of 19:

This means that 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.

The governing date is AT-T013, the requested execution or collection date, not the submission date. A pain.001 uploaded in September with a December execution date must already carry a structured or hybrid address. The upload date does not save it. Standing orders and scheduled collections bite hardest, their instructions authored long before anybody opened this guidance.

The remedy here is deliberately soft. The duty sits at "should" rather than "must": the Originator PSP, Creditor PSP or Euro Leg-Based Payer's PSP "should perform internal checks on ... payments files received with an AT-T013 ... registered in their payment transaction warehouses (e.g., for SCT standing orders, SDD Collection files sent 14 calendar days before due date)". Handling is then bilateral, "on a case-by-case basis with each PSU concerned".

That is section 7.4, the customer to PSP space. The inter-PSP space has a different rule, and a harder one.

The records that survive the double gate

Two duties, two parties, one record: this double gate lets that record through only when both duties are met. Section 7.2.1 of EPC153-22 v2.1 (p. 10 of 19) puts one record in front of two parties carrying two different obligations. At initiation:

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.

Then downstream, in the same block:

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.

An Originator PSP that lets a bad instruction through has broken its own rule, and the failure surfaces again downstream as a reject or return, on a payment the customer believes was accepted days ago.

The middle paragraph closes the workaround: where the Originator does not submit its own address, the Originator PSP "can only include a structured or a hybrid Originator address in the subsequent Inter-PSP pacs.008 message to the Beneficiary PSP". Enriching from your own records is contemplated. Passing through free text you already hold is not.

Section 7.5 (p. 16 of 19) covers the mirror scenario, a PSP forwarding pacs.008 or pacs.003 a few days early for execution on or after the date, and its remedy is not a conversation:

In any case, for SCT (Inst) Transactions/SDD Collections/OCT Inst Transactions to be 'executed' as of 15 November 2026 and containing address details, 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.

Keep §7.4 and §7.5 apart in the controls. Section 7.4 governs the customer to PSP space, where the check is a "should" and handling is bilateral. Section 7.5 governs the inter-PSP space, where an unstructured address leads to a reject or return. Collapsing them produces a control too soft on one leg and too hard on the other.

One thing this article will not tell you is which reject reason code comes back. No primary source we hold names one. The EPC guidance states the duty without naming a code, and Swift's normative CBPR+ Usage Guidelines sit behind MyStandards authentication and were not read. Confirm it with your CSM and your correspondents.

Records you can prove conformant before the cutover

Everything above is a gate, and a migration has to deliver evidence the gates were applied. Three artefacts carry the weight, and this part is our engineering view rather than a scheme requirement.

A per-gate count of the live population, measured rather than estimated: how many records have no resolvable country, how many no town name, how many reach fully structured and how many can only reach hybrid. A conformance test running against both format definitions rather than one, because a record valid as hybrid is not valid as fully structured. And the no-duplication rule as an executable assertion instead of a code review comment: for every hybrid address emitted, no value present in a structured element also appears in an AdrLine occurrence. That last test is the one almost nobody writes, and the one that catches the shortcut.

Test against the network too. Swift's Test Sparring Partner catalog describes one of its cases as "CBPR+ ISO 20022 with hybrid or structured address (unstructured addresses are NAKed)". That is a test environment rather than a production rule, so read it as strong evidence of intended production behavior and not as the rule itself.

The EPC's note on the move from 22 to 15 November records that participants and their technical service providers "will thus have one week less in 2026 to make the switch from the unstructured address format to either the structured or the hybrid address format". Address structure belongs on the same obligations register as everything else on the rail, which is how our FinTech compliance checklist treats it, and where the work reaches the ledger, the mapping layer and the initiation channel at once it is payment solutions development rather than a data cleanup project.

How Pharos Production helps

Here is how Pharos Production helps: we start every address migration with a number, not a mapper. Profiling live records against both format definitions comes first, before anyone writes a mapper. From there we build the parse, enrich and return routing as a control with a per-record audit trail and wire the no-duplication assertion into the test suite so the shortcut cannot ship quietly. The warehouse sweep for requested execution and collection dates on or after the cutover is usually the first query we run, because nobody has counted that population. This is FinTech development services work on live payment rails.

Sources: EPC Guidance Document Provision of Addresses under the EPC Payment Schemes, EPC153-22 Version 2.1, 19 numbered pages, sections 0.2, 2, 4, 5, 6.3, 6.4, 6.5, 7.2.1, 7.4 and 7.5, via europeanpaymentscouncil.eu, with the EPC document-library note recording what changed in that version. Swift material is cited at page level only, retrieved 2026-08-04, from the removal-of-unstructured-address page, the November 2026 milestone news item, the call-to-action page and two Postal Address FAQ pages on swift.com. Swift publishes these with no clause numbering, no version identifier and no body-text publication date, and they can change under the same URL, so nothing attributed to Swift here carries clause-level authority. Source-side typographic faults inside quotation marks are reproduced as printed. The parse, enrich and return split, the gate ordering and the evidence set are ours. This is engineering guidance, not legal advice.

FAQ

Last updated: August 4, 2026 · Reviewed by: Dmytro Nasyrov (Founder and CTO)

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 7

• ★ Featured question. What changes on 15 November 2026 for SEPA payment addresses?

  Copy link Copies a direct link to this answer to your clipboard.

  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.

• Is the deadline 14 November or 15 November 2026?

  Copy link Copies a direct link to this answer to your clipboard.

  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.

• Is 22 November 2026 still the deadline?

  Copy link Copies a direct link to this answer to your clipboard.

  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 an ECB and ERPB status update from June 2025 also carries it.

• Can I fill the structured fields and keep the original address in AdrLine?

  Copy link Copies a direct link to this answer to your clipboard.

  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. In fully structured, AdrLine cannot be used at all.

• My customer uploaded a pain.001 in October with a December execution date. Is it in scope?

  Copy link Copies a direct link to this answer to your clipboard.

  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.

• Who rejects a payment carrying an unstructured address?

  Copy link Copies a direct link to this answer to your clipboard.

  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.

• Which reject reason code is returned for a non-conforming address?

  Copy link Copies a direct link to this answer to your clipboard.

  No primary source we hold names one. The EPC guidance states the reject and return duty without naming a code, and Swift's normative CBPR+ Usage Guidelines sit behind authentication and were not read.

  Confirm the code with your CSM and your correspondent 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.