TL:DR
What Is Changing on November 14, 2026
This is not the ISO 20022 migration. That already happened. SWIFT retired MT103 and other core payment instruction messages on November 22, 2025. Cross-border payments now travel as pacs.008 (customer credit transfers) and pacs.009 (FI credit transfers) on SWIFT's FINplus service [1].
The November 2026 deadline is a separate, additional requirement about how postal address data is carried within those ISO 20022 messages. After November 14, 2026, SWIFT CBPR+ will reject payment messages whose party fields contain fully unstructured postal addresses. At minimum, the Town Name (TwnNm) and Country (Ctry, using the ISO 3166-1 alpha-2 code) must appear in their own dedicated structured fields [2].
In practical terms: an address crammed into two free-text lines like "123 Main Street, London EC2V 8BQ, United Kingdom" is no longer valid. The Town Name ("London") and Country ("GB") must be extracted into their own XML elements.
You can be fully November 2025 compliant (using pacs.008 instead of MT103) and still have significant work to do for November 2026. One is about message format. The other is about data quality within that format [3].
The Two Permitted Address Formats
After November 14, 2026, two address formats are valid. A third, fully unstructured, is retired.
One rule within the hybrid format is critical and catches people during validation: structured data takes precedence. If a component has a dedicated structured field, it must go there and must not also be repeated in an AdrLine. A message that puts "London" in both TwnNm and an AdrLine is not a compliant hybrid, it is malformed and may be rejected [4].
Which Messages and Fields Are Affected
The scope is broader than most teams initially assume.
The pain.001 row is the one most business teams overlook. If your company initiates cross-border payments through a corporate banking portal or treasury management system that sends pain.001 files, those files must also carry structured addresses for the debtor and creditor. The requirement flows upstream from pacs.008 to pain.001, meaning the structured address must exist at the point of payment initiation, not just at the bank's processing layer [3].
Not Just SWIFT: SEPA, CHAPS, and Major PMIs Are Aligned
This is not a SWIFT-only change. The European Payments Council has aligned the SEPA schemes (SCT, SDD, SCT Inst) to the same November 15, 2026 cutover date. From that date, the unstructured format is no longer permitted across any SEPA scheme [5].
CHAPS and the payment market infrastructures for the largest tradeable currencies (USD, EUR, GBP, AUD, CAD, SGD, and others) are also aligned to the same deadline [4]. For any institution operating across more than one of these rails, this is a single, synchronized cliff edge, not a series of separate deadlines to manage independently.
The Compliance Reality: 65% Non-Compliant, 44% Behind Schedule
By SWIFT's own assessment, approximately 65% of payment messages still carry unstructured addresses, and 44% of banks remain behind schedule in their remediation programmes [4]. This is not a population that can be remediated with a syntax change the week before go-live.
The non-compliance is concentrated in two areas.
First, legacy customer databases. Corporate ERP systems (SAP, Oracle, Microsoft Dynamics, and their equivalents) have stored counterparty and customer address data in free-text fields for decades. A typical corporate address record contains two or three free-text lines with no machine-parseable structure [3]. Converting these records to structured format requires parsing, validation, enrichment, and in many cases manual review for international addresses with non-standard formatting.
Second, upstream corporate payment files. Corporates initiating payments via pain.001 or through proprietary banking channels must source the creditor's address in structured format. If the corporate's treasury system generates free-text addresses, the non-compliance propagates even if the bank's internal systems are fully compliant [5].
What Happens If Your Payments Are Not Ready
SWIFT's position is clear: messages with unstructured addresses in the affected party fields will be rejected at the network level after the cutover [2]. Practically, this translates into payment failures, increased exception volumes, manual repair surges, and customer impact.
SWIFT's in-flow translation service is available for some transitional cases, but it is not a solution. The translation service attracts surcharges from January 2026, cannot reliably parse every address format, and is explicitly not intended as a long-term workaround [4]. J.P. Morgan's guidance is direct: "Payments not adhering to these formats may see their requests be rejected or delayed" [1].
For businesses sending cross-border payouts to suppliers, sellers, or contractors in multiple countries, the consequence of non-compliance is operational: payments that would have settled same-day now get rejected, triggering manual repair, resubmission, and delays that cascade through the settlement chain.
How This Affects POBO and On-Behalf-Of Flows
For businesses using on-behalf-of payment infrastructure to send payouts through a licensed entity on behalf of underlying merchants or sub-entities, the structured address requirement has specific implications.
In a POBO flow, the pacs.008 message carries the ultimate debtor's address data, representing the sub-entity on whose behalf the payment is being made. After November 2026, this ultimate debtor address must be structured, meaning the sub-entity's Town Name and Country must be in dedicated fields, not in free-text [6].
This has upstream consequences for entity onboarding. If your platform onboards sub-entities with free-text address fields at the KYB stage, that data propagates into the payment message and will fail validation after the deadline. The fix is to capture structured address data (at minimum Town and Country as separate fields) at the point of entity onboarding. For a detailed breakdown of how POBO infrastructure works, including sub-entity data requirements, see our white-label POBO guide.
SWIFT's AI Tool for Address Structuring
To help the community meet the deadline, SWIFT has released an open-source AI solution for address structuring. The tool uses a Natural Language Processing (NLP) model to infer Town Name and Country from unstructured address text, with confidence scores for each prediction [7].
The tool is available free of charge through the SWIFT download center and can be integrated into internal systems, used as a standalone batch-processing engine, or deployed through a FastAPI service for automated orchestration. It generates XML for all 13 supported pacs.008 versions and validates against the official ISO 20022 XSD schemas [7].
This tool is useful for bulk remediation of legacy address databases. It is not a substitute for fixing the upstream data capture. New address records entering the system after remediation still need to be captured in structured format at source.
The 4-Month Readiness Plan
With four months remaining, the remediation path has four phases. The specifics depend on your role in the payment chain, whether you are a financial institution, a corporate, or a platform sending payments through banking partners.
What Corporates Specifically Need to Do
If you are a corporate sending cross-border payments (not a bank), the November 2026 deadline affects you in three ways.
First, your payment initiation files must carry structured addresses. If you send pain.001 files to your bank, or initiate payments through a proprietary corporate banking portal, the creditor address data in those files must include TwnNm and Ctry at minimum. Your bank will reject payment requests that do not meet this requirement because they cannot construct a compliant pacs.008 from non-compliant input [1].
Second, your ERP and treasury management systems need updating. SAP, Oracle, Microsoft Dynamics, and similar systems store counterparty addresses in free-text fields by default. These systems need either configuration changes to enforce structured address capture, or batch remediation of existing records [3].
Third, your supplier and vendor master data needs auditing. Every payee address in your system that will be used in a cross-border payment after November 14, 2026 must have at minimum a parseable Town Name and Country Code. If your procurement team has been entering supplier addresses as "3rd Floor, ABC Building, Mumbai" without a structured Town/Country field, that address will fail validation.
What Payment Platforms and Gateways Need to Do
For payment platforms and gateways that initiate SWIFT payments on behalf of businesses, the requirement flows into the API and data model.
The platform's beneficiary data model must support structured address fields (at minimum TwnNm and Ctry) as mandatory, not optional, for any payout that will travel via SWIFT. This means updating onboarding flows, API schemas, and validation rules to enforce structured address capture at the point the beneficiary is created, not at the point the payment is submitted.
For platforms operating POBO infrastructure, the same requirement applies to the ultimate debtor (the sub-entity). The platform must capture structured address data for every sub-entity at onboarding, because that data populates the pacs.008 ultimate debtor field.
Platforms that currently accept free-text address fields in their API and then attempt to parse them at payment submission time are taking on parsing risk. SWIFT's NLP tool helps, but it returns confidence scores, not guarantees. The safer approach is to require structured input at source.
