What Regulators Actually Require: EPC, SWIFT, and CPMI Decoded

I've spoken with enough payment operations teams over the past few years to recognise a pattern. When hybrid addressing comes up, most practitioners nod with the confidence of people who believe they understand the rules. Hybrid addressing is on their roadmap. It satisfies ISO 20022 requirements. They'll upgrade to fully structured later.

Every part of that sentence is wrong.

Hybrid addressing is not an equal alternative to structured addressing under ISO 20022. It is a constrained fallback permitted as a transitional measure, with specific fields that must still be structured even in hybrid mode. Unstructured addressing is not a fallback. It's a failure mode. And the teams currently routing unstructured address data through ISO 20022-formatted messages aren't approaching non-compliance they're already there.

What follows is a precise breakdown of what EPC, SWIFT, and CPMI actually require with citations and the exact field-level details that most compliance briefings omit.

The Hierarchy Most People Miss

Before decoding each regulatory body's requirements, it helps to understand the architecture they're all working within. ISO 20022 defines three address formats. They are not a menu of options, they form a hierarchy with a single destination, a constrained on-ramp, and a dead end.

The practical consequence of confusing Tier 2 for Tier 1: your messages pass internal testing today because your own validation accepts hybrid format. But correspondent banks running tighter validation particularly post-November 2026 — will generate exceptions or rejections. You've built toward a compliance floor, not a compliance solution. For a deeper technical breakdown of these field structures, see our guide to ISO 20022 address fields: TwnNm, Ctry, AdrLine explained.

What EPC 153-22 Actually Requires

The European Payments Council's SEPA Credit Transfer rulebook implementation guidelines EPC 153-22 does not frame structured addressing as preferred or recommended. It uses mandatory language.

For all SEPA Credit Transfer (SCT) and SCT Instant messages, EPC requires that address elements be provided in structured format. The PostalAddress element must be populated with discrete structured fields rather than free-text content. This isn't aspirational it's the current scheme requirement for all participants.

The specific constraint most teams miss: even when hybrid addressing is used as a transitional format during the migration period, EPC 153-22 specifies that TwnNm (town name) and Ctry (country) must be populated as structured fields. The hybrid permission is not a blanket licence to submit free-text addresses. It's a narrow accommodation with explicit structural constraints attached.

The scope here is significant. EPC requirements apply to all payment service providers participating in SEPA schemes approximately 2,500+ institutions across 36 countries. Scheme-level validation means non-compliant messages can be returned. This isn't a warning system, it's a rejection mechanism.

If your institution processes SEPA payments and your address data pipeline is still outputting unstructured or incomplete hybrid format, you are not approaching non-compliance you are currently non-compliant.

SWIFT's Cross-Border Payments and Reporting Plus (CBPR+) guidelines require structured addresses in pacs.008 (customer credit transfer) and related cross-border message types. The SWIFT Standards Release documentation specifies the PostalAddress element requirements in detail, mandating that postal components use structured fields rather than free-text content.

What changes in November 2026 is not message format adoption most institutions completed the MX migration during the 2022–2025 transition period. What changes is validation behaviour. Address field validation shifts from advisory (non-compliant fields generate warnings, messages still process) to hard enforcement where non-compliant fields can cause message rejection or routing failures.

This is the critical distinction that most compliance briefings miss: migrating to ISO 20022 MX message format and achieving ISO 20022 address compliance are two entirely different things. You can be running MX-formatted messages today and still be non-compliant if those messages contain unstructured or incorrectly populated address data. Format adoption was step one. Address data quality is step two, and it's the step most institutions haven't closed.

"SWIFT's November 2026 deadline isn't about adopting ISO 20022 — most banks have already migrated the message format. It's about address data quality within those messages. That's the gap."

There is also a correspondent chain dimension that is frequently underestimated. Structured addresses must flow end-to-end through every correspondent in the payment chain. If your originating message contains correctly structured addresses but an intermediary bank's system truncates them during translation, the beneficiary bank receives a non-compliant message. CBPR+ compliance is a chain problem, not just an originator problem — your compliance position depends in part on the capabilities of every institution in your payment corridors. Read more about the economics of this problem in The $8–12 Billion Problem: Address Data Quality Economics.

What CPMI Requirement #11 Actually Means

The Committee on Payments and Market Infrastructures does not enforce requirements directly. What it does is more strategically important: it sets the harmonisation framework that national regulators and infrastructure operators — including EPC and SWIFT — translate into enforceable rules.

Understanding CPMI explains why EPC and SWIFT requirements are converging, not just what they each require.

The CPMI Harmonised ISO 20022 Data Requirements for Enhancing Cross-Border Payments specifies Requirement #11 as the structured address mandate. This requirement establishes that the PostalAddress element in cross-border payment messages must use structured components — not free text — and that country and town name fields must be populated as discrete structured values.

Because Requirement #11 sits above both EPC and SWIFT in the regulatory hierarchy, and because multiple major payment systems are aligning to these harmonised requirements — US Fedwire Funds Service, UK CHAPS, Eurosystem TARGET — address structuring is not a SEPA-only or SWIFT-only issue. It is becoming universal infrastructure compliance. The institutions treating it as a regional requirement are building the wrong risk model.

The Progressive Validation Ratchet: 2025 → 2026 → 2027

Here is the enforcement reality as it stands today, and where it is headed.

Right now (2025–early 2026): Most validation is advisory. Non-compliant address fields generate warnings, but messages still process. This creates a dangerous dynamic — teams see no immediate failures and conclude they have more time than they do. The 60% manual intervention rate plaguing cross-border payments already reflects this data quality problem.

November 2026: SWIFT CBPR+ enforcement tightens. Address field validation shifts from advisory to hard rules. EPC validation at scheme level applies with increased rigour. Messages with unstructured or incorrectly structured addresses face rejection or manual routing. This is the inflection point.

2027–2028: Progressive tightening expected as CHAPS, TARGET, Fedwire, and other national RTGS systems align validation to CPMI harmonised requirements. The enforcement perimeter expands from network-level to infrastructure-level.