The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →From 14 November 2026, Swift’s guidance says fully unstructured postal addresses will no longer be accepted in cross-border payment messages where an address is required. The accepted formats are fully structured and hybrid, and both require Town Name and Country Code as structured elements at minimum. That makes the migration less a formatting task than a question of where those two values come from. A payment platform can emit TwnNm and Ctry correctly and still send unreliable data if no one can show how the values were obtained. A downstream formatter cannot repair a town that was never captured.
Who the rule reaches
Swift’s corporate FAQ ties the change to CBPR+ and HVPS+, and its migration guidance frames the requirement around CBPR+ payment messages. In practice, the address rule applies to the parties that carry postal addresses in those messages:
As an Amazon Associate I earn from qualifying purchases.
- the Creditor;
- the Debtor, where present;
- the Ultimate Debtor and Ultimate Creditor, if your flows use them;
- agents, but only when a BIC is not provided.
A BIC changes the agent picture. Swift says that in most cases no bank postal address is required when the beneficiary bank is identified by BIC. Where an address rule still applies to a party or agent, the structured or hybrid formats apply in the same way as for any other party.
The migration guidance also lists message types that are exempt: admi.024, camt.025, camt.052, camt.053, camt.054, and camt.060. Those lists come from the CBPR+ context. Before applying the same logic to other rails, local services, or message types, check the current message-specific usage guidelines.
Fully structured, hybrid, and unstructured
Three formats matter. Only the first two are accepted after the deadline.
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 are the minimum, with the country expressed as an ISO two-letter code. A fully structured address cannot contain an Address Line element. Swift’s standards examples show values in this form:
<TwnNm>LONDON</TwnNm>
<Ctry>GB</Ctry>If an organization has the building number and street but cannot reliably separate them from the rest of a free-text line, the fully structured route may be the wrong target. Hybrid exists for that case.
Recommended Free Tools
Hybrid
A hybrid address combines structured fields with a limited free-text portion. Town Name and Country Code remain structured and mandatory. Swift’s industry guidance, “ISO 20022 – Removal of Unstructured,” permits up to two Address Line occurrences, each up to 70 characters.
The guidance is specific about use. Structured elements should carry every address detail that is available and can be assigned reliably. Address Line should hold only what cannot be reliably structured or does not fit the available fields. Hybrid is a transition option. It is not a reason to leave Town and Country inside a text block. The Federal Reserve Financial Services’ format FAQ describes the hybrid requirement in the same terms for US wire services, and the ECB/PMPG guidance “Hybrid Postal Address,” version dated 20 October 2025, sets out industry practice for it.
An illustrative fragment, with invented values and element order to be checked against the message schema, looks like this:
Rank #2
<PstlAdr>
<TwnNm>LONDON</TwnNm>
<Ctry>GB</Ctry>
<AdrLine>Flat 4, 18 Example Road</AdrLine>
</PstlAdr>Unstructured
Fully unstructured postal addresses are being decommissioned for the relevant messages. Swift’s migration guidance warns that requests not following the required formats may be rejected or delayed by payment service providers, with possible payment delays, higher rejection rates, and operational or compliance risk. Treat those as the risks Swift identifies, not as a fixed outcome. Actual handling depends on the applicable message rules and on each PSP’s implementation.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Channel notes: MT101 and SCORE+ pain.001
Swift’s corporate FAQ says MT101 users do not acquire new mandatory message fields because of the postal-address change. Where an address is supplied, the FAQ says to use Option F for fields 50a and 59, and that the earlier alternatives it cites should no longer be used for addresses.
The same FAQ says SCORE+ pain.001 supports both hybrid and fully structured addresses over FINplus. Those are statements about channel support in Swift’s own guidance; the sending bank’s release documentation determines what a given customer channel accepts.
Why this is a data-lineage problem
Swift’s migration guidance states: “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.” That sentence explains why the migration cannot be solved at the network edge. A bank or payment hub can reformat what it receives, but it cannot verify a town for a creditor whose record never contained one.
Swift also notes that corporates’ ERP systems often store addresses as free text or semi-structured fields, and that those systems and processes need updating. That is where lineage begins. A Town or Country value has to exist, be attached to the correct party, survive every transformation between systems, and stay correct when the party record changes.
Free tools Windows power users keep installed
One-click scans. No signup required.
The useful test is not whether the payment platform can produce the structured elements. It is whether an organization can answer four questions about any Town or Country that leaves in a message:
Rank #3
- Where did the value come from?
- Was it verified, entered by a person, or inferred?
- When was it last confirmed?
- How does it stay consistent on every payment path that uses the party record?
If those answers are missing, the formatter is only moving uncertainty into a standard field.
Implementation sequence
Swift does not prescribe a project plan. The sequence below is a practical order derived from its field rules and its description of legacy systems.
1. Inventory where addresses originate
List every system that holds party addresses or builds them into payment data: ERP, supplier and customer masters, core banking, onboarding, the payment hub, and file imports. For each one, record which fields are genuinely structured, where free text is assembled, and which payment message and channel each flow feeds. Without this map, later steps cannot be scoped.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors2. Set a source-of-truth policy
Define the authoritative source for party identity, Town Name, Country Code, and any optional address attributes. For every value, record provenance, source date, transformation applied, and confidence where the value was inferred or enriched from outside. Do not let a model prediction sit in master data looking like a verified fact.
3. Profile and segment legacy records
Sort records into groups that call for different handling:
- already structured records;
- hybrid-compatible records where Town and Country can be identified;
- records that need enrichment or human investigation;
- records with no address;
- agents identified by a permitted BIC, which do not need a postal address.
Segmenting first keeps manual effort on the records that genuinely need it.
Rank #4
4. Remediate at origin
Update collection screens, schemas, validation rules, APIs, file layouts, and stewardship processes so that Town and Country survive capture and downstream mapping as separate values. Keep hybrid address lines only for residual text. A fix made only in the outbound message leaves the source record wrong, and the next extract reproduces the problem.
5. Use inference only with controls
A model can propose Town and Country with a confidence score. Low-confidence results, ambiguous entries, unusual patterns, and non-Latin-script inputs need an exception path. Validate against approved registries or an accountable reviewer before a critical payment is sent. Swift’s model guidance is explicit that these cases need validation or expert review.
6. Test every payment path
Validate serialization and business rules across each relevant message type, transport channel, intermediary, and receiving PSP. Cover at least these cases: missing Town or Country, long address lines, duplicated content, unsupported unstructured input, BIC-identified agents, and exception messages. A path that passes internal tests can still behave differently at a receiving PSP, so include partner validation where it is available.
7. Monitor lineage and outcomes
Track unresolved records, correction rates, false inferences, rejection reasons, field completeness, and changes made at each source. Send rejects and manual corrections back to the owner of the originating data, not only to the payment team.
Swift’s address structuring model: what it can and cannot do
Swift describes an NLP-based model 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. Swift says it can be integrated into internal systems, used as a standalone tool, or run as batch preprocessing, and it describes the model as open source and free of charge to the Swift community. Its limits matter as much as its features:
- The output is Town and Country, not a complete normalized postal address.
- Swift says the model is not designed for free-format agent fields such as 57D. Agents are usually identified by BIC and available reference data.
- Low-confidence predictions, non-standard patterns, and new formats need validation or expert review.
- Swift says the model performs best with English or transliterated input encoded in Swift character set X. Arabic, Chinese, Cyrillic, and Japanese/CJK input may yield 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. Swift says the model is not integrated into Swift products.
The model is a focused inference aid inside a wider remediation and validation process. It is not a compliance guarantee.
Best Value
What the August 2026 figures show
Swift’s migration guidance reports the following global shares for pacs.008 CBPR+ traffic observed in August 2026. The shares describe the address formats present in XML elements, not the completeness of addresses beyond mandatory data elements.
| Party (August 2026, pacs.008, CBPR+) | Fully structured | Hybrid | Unstructured | No address |
|---|---|---|---|---|
| Debtor | 24.1% | 16.5% | 54.8% | 4.7% |
| Creditor | 20.0% | 10.2% | 56.2% | 13.5% |
These are observed format shares in that traffic scope. They do not survey every institution and they do not measure overall migration readiness. Neither row sums to exactly 100%, so read the figures as published rather than as a reconciled breakdown.
Comparing migration approaches
The available sources do not offer an independent benchmark or cost comparison of manual cleansing, rule-based parsing, model-based inference, external reference-data enrichment, or changes to source capture. The criteria below are the ones to use when comparing them, not verdicts on any approach:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- accuracy and validation of Town and Country assignments;
- handling of ambiguous, non-standard, and non-Latin-script input;
- confidence scoring, audit trail, and routing of exceptions to people;
- provenance, and the ability to write verified corrections back to the system of record;
- coverage of party types, message types, and channels;
- fit with current schemas, batch volumes, APIs, and operating controls;
- ongoing registry maintenance and regional coverage;
- cost and operational ownership, checked against a provider’s current offer.
When a payment is rejected or delayed for address reasons
Work the problem from the message backward, not from the outbound file forward.
- Identify the party and message. Confirm whether the address belongs to the creditor, debtor, an ultimate party, or an agent, and whether a BIC was supplied for the agent.
- Check the format. If the address is fully unstructured, it must be converted at origin. Patching the outbound message will not fix the source.
- Check Town and Country. If either is missing or buried in text, trace the value to the record it came from.
- Check provenance for inferred values. Confirm the confidence score and whether a reviewer approved the value before it was used.
- Correct the source, then re-send. Log the rejection reason and feed it back to the data owner so the same gap does not recur.
- Ask the PSP for the specific rejection reason. Handling depends on each PSP’s implementation, so the reason code is the reliable starting point.
Sources and what they establish
The points above rest on the following sources. Requirements and enforcement are time-sensitive, so check the current CBPR+ usage guidelines, the Standards Release 2026 materials, and your bank’s or PSP’s instructions before implementing anything.
- Swift, “ISO 20022: Corporates” (corporate FAQ): the deadline wording, hybrid minimums, BIC treatment, MT101 and SCORE+ notes.
- Swift, “ISO 20022: The Swift AI address structuring model”: the model’s purpose, availability, target users, and limitations.
- Swift, “Unstructured address data is being removed. Are you ready?” (migration guidance): message exceptions, format examples, August 2026 figures, and the origin-of-data statement.
- Swift, “ISO 20022 – Removal of Unstructured” (industry guidance PDF): the two-line, 70-character hybrid limits and advice to structure reliably available data.
- BIS/CPMI, “Fostering ISO 20022 harmonisation”: broader standards and harmonisation context.
- Federal Reserve Financial Services, “Format Frequently Asked Questions”: a corroborating US wire-service explanation of hybrid requirements.
- ECB/PMPG, “Hybrid Postal Address,” version dated 20 October 2025: industry practice for hybrid postal addresses.
This article does not test Swift’s model, any bank’s payment flow, or any vendor service. Its claims are limited to what the sources above state, and each one is attributed to the body that published it.
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.
