On 15 November 2026, both the European Payments Council (EPC) and SWIFT will prohibit fully unstructured addresses in payment messages. This is the most operationally significant ISO 20022 data quality deadline since the original migration, and it affects every payment service provider processing euro or cross-border payments.
What Is Changing
Today, many payment messages still carry addresses as free-text blocks - two lines of up to 70 characters each, with no machine-parseable structure. From November 2026, this format is no longer permitted.
Before (unstructured): Two free-text lines containing the full address in any format the sender chooses. Example: "123 Main Street, London EC2V 8BQ, United Kingdom" crammed into address lines.
After (structured): Address components must be placed in dedicated ISO 20022 fields: Street Name, Building Number, Post Code, Town Name, Country Code. Each element is separately tagged and machine-readable.
Hybrid (transitional): A combination of structured fields (at minimum Town Name and Country Code in their dedicated fields) plus up to two lines of 70-character unstructured "Address Line" for remaining elements. The EPC permits hybrid format as a stepping stone, but fully unstructured is banned.
Two Parallel Mandates
SWIFT CBPR+ (cross-border): From November 2026, payment messages must include at minimum Town Name and Country Code in structured fields. Fully unstructured postal address blocks will be rejected. Institutions still relying on in-flow translation already face surcharges introduced in January 2026.
EPC SEPA schemes (domestic euro): The 2025 SEPA rulebook version 1.1 confirmed that as of 15 November 2026, the unstructured address format is no longer permitted across all SEPA schemes (SCT, SDD, SCT Inst). The EPC aligned this date with the SWIFT Standards MX Release scheduled for the second full weekend of November 2026.
The alignment is deliberate: both SWIFT and the EPC want a single industry cut-over date.
Minimum Required Fields
Mandatory from November 2026: Town Name - in the dedicated TwnNm field (not embedded in free-text) Country - ISO 3166-1 alpha-2 code in the Ctry field
Recommended but not yet mandatory: Street Name (StrtNm) Building Number (BldgNb) Post Code (PstCd)
The "recommended" fields will likely become mandatory in a subsequent rulebook change. PSPs planning their systems migration should implement all five fields now to avoid a second remediation cycle.
Who Is Affected
All SEPA scheme participants (banks, payment institutions, e-money institutions) All SWIFT member institutions sending or receiving cross-border payments Corporates initiating payments via pain.001 messages (the structured address requirement flows upstream to payment initiation) Payment processors and gateways that format pacs.008 and pacs.004 messages Correspondent banks that translate or enrich payment data in transit
What PSPs Need to Do
-
Audit your address data: Assess what percentage of your customer master data has parseable, structured address components versus free-text. Many institutions will find that customer onboarding captured addresses as unstructured text.
-
Implement parsing and enrichment: For existing free-text addresses, deploy address parsing tools that can extract town, country, street, and post code from unstructured strings. This is non-trivial for international addresses with varying formats.
-
Update payment message formatting: Ensure your payment engine populates the dedicated ISO 20022 address fields rather than dumping everything into AddressLine elements. Test with both SEPA and SWIFT message validation tools.
-
Fix upstream capture: Update customer onboarding, KYC, and payment initiation screens to capture address components separately. This is the most sustainable fix but requires UI and process changes.
-
Handle the hybrid period: Between now and November 2026, the hybrid format (structured fields plus address lines) is acceptable. Use this period to migrate progressively rather than attempting a big-bang conversion.
-
Test with your CSM and correspondents: Contact your Clearing and Settlement Mechanism (CSM) - whether EBA Clearing, STET, Equens, or others - to understand their validation rules and rejection handling for non-compliant addresses.
Common Pitfalls
Assuming this only affects cross-border: The SEPA mandate means domestic euro payments are equally affected Relying on translation services: SWIFT's in-flow translation will not save you - it attracts surcharges and cannot reliably parse all address formats Ignoring pain.001: If your corporate clients send payment initiation files with unstructured addresses, the problem propagates even if your internal systems are compliant Underestimating data quality: Address data accumulated over decades of free-text capture is often inconsistent, abbreviated, or incomplete
Key Takeaway
November 2026 is an operational readiness deadline, not a regulatory compliance date - but the consequences of non-compliance are immediate: payment rejections, surcharges, and failed STP. The EPC and SWIFT have given the industry fair warning. PSPs that have not begun their address data remediation should start now.
Sources: EPC - Guidance on Structured Addresses in SEPA Payment Schemes; EPC - 2025 SEPA Instant Credit Transfer Rulebook v1.1; SWIFT - ISO 20022 for Financial Institutions; The Paypers - Structured Addresses and ISO 20022.