The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
From 14 November 2026, Swift’s cross-border CBPR+ payment messages will no longer accept fully unstructured postal addresses where an address is required. Both permitted formats, fully structured and hybrid, require Town Name and Country Code as separate structured elements. Thirty-six days remain from the date of this article, so the practical question is not how to write the XML tag. It is whether each Town and Country value can be traced to an authoritative origin and kept intact as the party record moves through every payment path.
What changes on 14 November 2026
Swift’s corporate guidance states that, from that date and aligned with CBPR+ and HVPS+ and the community’s move toward ISO 20022, “fully unstructured postal addresses will no longer be accepted in cross-border payment messages.” The rule applies only where an address is required. The scope is set out below.
Swift’s migration guidance adds that requests not following the required formats may be rejected or delayed by payment service providers, with possible payment delays, more rejections, and operational or compliance risk. How a particular message, channel, or bank handles a non-compliant address depends on the applicable message rules and that provider’s implementation. Check the current CBPR+ usage guidelines, the Standards Release 2026 materials, and your bank’s instructions before relying on any specific outcome, because these requirements are time-sensitive.
Which address formats qualify
The two permitted formats share one hard rule: Town Name and Country Code must be structured. They differ in what else they allow.
| Element | Fully structured | Hybrid | Fully unstructured |
|---|---|---|---|
Town Name (TwnNm) |
Mandatory, structured | Mandatory, structured | Not accepted from 14 November 2026 where an address is required |
Country Code (Ctry, ISO two-letter form) |
Mandatory, structured | Mandatory, structured | Not accepted from 14 November 2026 where an address is required |
| Address Line | Not permitted | Up to two occurrences, 70 characters each | Free text only; not accepted from 14 November 2026 where an address is required |
| Street name, building number, postal code | Structured fields where available | Structured fields where available and reliably assigned | Not structured |
Fully structured
A fully structured postal address uses distinct fields such as street name, building number, postal code, town, and country. Town Name and Country Code, with the country as an ISO two-letter code, are the minimum. This format cannot contain Address Line. Swift’s standards examples show the minimum as:
<TwnNm>LONDON</TwnNm> and <Ctry>GB</Ctry>
Hybrid
Hybrid combines structured fields with a limited free-text portion. Town Name and Country Code remain structured and mandatory. Swift’s industry guidance on removing unstructured addresses sets the free-text limit at two Address Line occurrences, each up to 70 characters.
Put every address detail you hold and can assign reliably into a structured element. Reserve Address Line for residual text that cannot go into a structured field, such as a descriptive location note. Hybrid is a transition format, not a reason to leave Town and Country embedded in a free-text line. The ECB/PMPG guidance on hybrid postal addresses (version dated 20 October 2025) covers the same practice, and the Federal Reserve Financial Services’ Format Frequently Asked Questions corroborates the hybrid requirements for US wire formats.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Fully unstructured
A fully unstructured address is a single block of text, typically with the town and country buried inside a street line. From 14 November 2026 it is decommissioned for the relevant messages. ERP systems often store addresses in this form or in semi-structured form, which is why the upstream work described below matters more than the format definitions.
Where the rule applies
Swift’s corporate FAQ lists the parties that carry addresses under this rule: the creditor, the debtor where present, the ultimate debtor and ultimate creditor where used, and agents only when no BIC is provided.
Rank #2
The BIC changes the agent case. Swift says no bank postal address is required in most cases where the beneficiary bank is identified by BIC, and a BIC remains a valid agent identifier without an accompanying postal address.
The migration guidance applies the rule to CBPR+ payment messages and lists the following messages as exceptions, meaning they are excluded from the requirement:
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsadmi.024camt.025camt.052camt.053camt.054camt.060
Do not extend this list to other rails or local services without checking the message-specific usage guidelines for that rail.
Channel notes for MT101 and SCORE+
- MT101: Swift’s corporate FAQ says MT101 users do not acquire new mandatory fields from the postal-address change. Where an address is supplied, use Option F for fields 50a and 59. The alternatives the FAQ previously cited should no longer be used for addresses.
- SCORE+ pain.001: The FAQ describes SCORE+ support for both hybrid and fully structured addresses over FINplus.
Confirm both points with your sending bank and the current release documentation before building against them.
Why the work starts upstream
A payment formatter can only output what it receives. Swift says corporates’ ERP systems often store free-text or semi-structured addresses, and that those systems and processes need updating. Swift’s migration guidance states the consequence directly:
Rank #3
As address information must be sourced at origin, it is not possible for Swift to develop a contingency solution for financial institutions who experience delays in readiness.
Recommended: Update Every Outdated Driver on Your PC in One Scan - Free →Recommended: Fix Windows Errors and Clear Junk Files in Minutes - Free Scan →Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
A downstream step cannot create reliable location data where the record is absent or ambiguous. Consider a free-text line reading Hauptstrasse 12, Springfield (an illustrative example). The street is clear, but the name Springfield applies to towns in several countries, so a formatter cannot choose the correct Town Name and Country Code from the text alone. If the customer record holds a verified country and postal code, the values can be structured at origin. If it does not, the answer has to come from the customer, an approved registry, or a reviewer, and the record should show which one supplied it.
What the August 2026 figures show
Swift’s migration guidance reports the following global adoption shares of hybrid and structured postal addresses for August 2026, in pacs.008 CBPR+ traffic. The shares are measured from observations of the XML elements used in that traffic.
| Address format | Debtor | Creditor |
|---|---|---|
| Fully structured | 24.1% | 20.0% |
| Hybrid | 16.5% | 10.2% |
| Unstructured | 54.8% | 56.2% |
| No address | 4.7% | 13.5% |
These figures do not measure completeness beyond mandatory elements. Read them as format shares in that traffic scope, not as a survey of every institution or a measure of migration readiness. The published columns total 100.1% for debtors and 99.9% for creditors, which points to rounding. The clear takeaway is that more than half of the observed debtor and creditor addresses were still unstructured in August 2026.
Building a data-lineage workflow
The sequence below is an implementation plan derived from Swift’s field rules and its description of legacy systems. Swift does not prescribe this plan.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #4
Step 1: Inventory where addresses originate
List every system that holds, assembles, or transmits a party address: ERP, supplier and customer masters, core banking, onboarding, the payment hub, and file-import layers. For each one, record which fields are genuinely structured, where free text is concatenated, and which payment messages and channels the flow feeds.
Step 2: Set a source-of-truth policy
Name the authoritative source for each party’s identity, Town Name, Country Code, and any optional address attributes. For each value, record its provenance, the date it was sourced, any transformation applied, and a confidence level where the value was inferred or enriched. A model prediction should never sit in master data looking like a verified value.
Step 3: Profile and segment legacy records
Sort records into these groups:
- already structured, with Town and Country in structured fields;
- hybrid-compatible, where Town and Country can be identified and the residual text is short;
- needing enrichment or human investigation;
- having no address;
- not requiring an address because a permitted identifier such as a BIC is used.
Step 4: Fix capture at origin
Change collection screens, schemas, validation rules, APIs, file layouts, and stewardship procedures so that Town and Country survive capture and mapping as separate values. Keep Address Line only for residual text. Fixing capture is the only step that stops the backlog from refilling.
Step 5: Use inference under controls
A model can propose Town and Country with a confidence score, but low-confidence, ambiguous, unusual, and non-Latin-script cases need an exception path. Validate against approved registries or accountable review before a critical payment is released. The limits of Swift’s own model are covered in the next section.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Step 6: Test every payment path
Validate serialization and business rules for each relevant message type, transport channel, intermediary, and receiving PSP. At a minimum, include these cases:
Best Value
- missing Town Name or Country Code;
- Address Line text longer than 70 characters, or more than two Address Line occurrences in a hybrid address;
- the same content repeated across structured fields and Address Line;
- unstructured addresses that the format no longer accepts;
- agents identified by BIC with no postal address;
- exception messages from the list above.
Step 7: Monitor lineage and outcomes
Track unresolved records, correction rates, inferences that reviewers reject, rejection reasons, field completeness, and changes made at each source. Send rejects and manual corrections back to the data owner who created the value, rather than patching only the outbound message. An outbound patch hides the defect, and it returns with the next batch.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Using Swift’s AI address structuring model
Swift describes its address structuring model as an NLP-based tool that infers Town and Country from unstructured legacy address content, particularly debtor and creditor data in MT 103 and pacs.008 workflows. It returns confidence scores, resolution options, and diagnostics to support automation and expert review. Swift says it can be integrated into internal systems, used as a standalone tool, or run as batch preprocessing. Swift describes it as open source and free of charge to the Swift community.
Its scope is narrower than its name suggests:
- It outputs Town and Country. It does not produce a complete, normalized postal address.
- Swift says it is not designed for free-format agent fields such as field 57D. Agents are better identified by BIC and available reference data.
- Low-confidence predictions, non-standard patterns, and new formats need validation or expert review.
- Swift says it performs best on English or transliterated inputs encoded in Swift character set X. Arabic, Chinese, Cyrillic, and Japanese or CJK inputs may produce unreliable or unexpected results.
- Swift says the model can be tuned with additional regional registries and repositories.
- It is distinct from Swift Translator. Translator maps fields when Town and Country are already available, while the model infers them from free text. The model is not integrated into Swift products.
Treat the model as a focused inference aid inside a validated remediation process, not as a compliance guarantee.
Comparing remediation approaches
These approaches solve different parts of the problem. The published guidance offers no independent benchmark or cost comparison, so accuracy and cost have to be measured on your own records. Compare each option on validation of Town and Country, handling of ambiguous and non-Latin-script input, confidence scoring and exception routing, provenance and write-back to the system of record, coverage of party types and channels, fit with your schemas and batch volumes, and ongoing registry maintenance.
| Approach | Where it fits | Main limit to plan for |
|---|---|---|
| Manual cleansing | Human judgement on ambiguous and non-Latin-script records | Slow at volume; consistency depends on the reviewer; needs a recorded audit trail |
| Rule-based parsing | Predictable and explainable when addresses follow consistent layouts | Breaks on new or irregular layouts; rules need upkeep for each country |
| Swift’s address structuring model | Free, open source, returns confidence scores, runs in batch | Infers Town and Country only; limited for non-Latin scripts; not for field 57D |
| External reference-data enrichment | Adds registry-based place data that can be validated | Check regional coverage and registry maintenance; provider terms and cost are not covered here |
| Changes to source capture | Fixes the cause; provenance is clearest | Takes time to roll out; does not clear the existing backlog |
Sources referenced
- Swift, “ISO 20022: Corporates” (corporate FAQ on the deadline, hybrid minimums, BIC treatment, MT101 and SCORE+).
- Swift, “ISO 20022: The Swift AI address structuring model” (model purpose, availability, target users, and limitations).
- Swift, “Unstructured address data is being removed. Are you ready?” (migration overview, message exceptions, format examples, August 2026 figures, and the origin-of-data statement).
- Swift, “ISO 20022 – Removal of Unstructured” (industry guidance PDF with the two-line, 70-character hybrid limits).
- BIS/CPMI, “Fostering ISO 20022 harmonisation” (broader standards context).
- Federal Reserve Financial Services, “Format Frequently Asked Questions” (hybrid requirements for US wire formats).
- ECB/PMPG, “Hybrid Postal Address,” version dated 20 October 2025 (industry guidance on hybrid postal address practice).
The Bottom Line
The output change is small; the risk sits in the inputs. For each in-scope party, be able to answer two questions before 14 November 2026: where did this Town Name and Country Code come from, and does it still match when the payment leaves your systems? If you cannot answer either question, route the record to review rather than into the payment message.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
