Blog

Mastering address management: The November 2026 deadline most treasury teams are underestimating

Over the past months, we've got the same question from many customers: "Do we have to restructure every beneficiary address by November 2026?" Here's what's really happening. Most treasury teams are treating the November 2026 address mandate as a compliance checkbox. They're missing the bigger opportunity: fixing the data that's been slowing down their cross-border payments for years.

Let us explain why this matters, what's actually changing, and how to turn a regulatory headache into an operational upgrade.

The regulatory perfect storm

Three forces are converging to make address management unavoidable:

ISO 20022 adoption is pushing the industry toward structured payment data. Think of unstructured addresses as handwritten envelopes in a world that's gone barcode. They might get delivered eventually, but they'll slow down every automated sorting system they touch. Eventually, the postal service (or in this case, the bank) will just stop accepting them.

FATF Recommendation 16 revisions now require, at minimum, town name and country for payment party identification. This isn't just about data quality; it's about strengthening the global AML (Anti-Money Laundering) and CTF (Counter-Terrorist Financing) framework.

G20 data quality commitments are accelerating the shift to structured formats across borders, aiming to reduce payment friction and improve transparency.

The hard deadline: November 2026. After this date, fully unstructured postal addresses (containing only Address Lines) and postal addresses containing only the country element will no longer be authorized by regulators for most cross-border transfers and some domestic transfers. The Town Name and the Country will need to be provided. This represents a hard deadline that organizations cannot afford to miss.

The payoff beyond compliance

Let's be honest: restructuring thousands of beneficiary records six months before a hard deadline means work. But the compliance mandate also forces a cleanup that most organizations have been postponing for years. And the operational payoff is real.

Here's what we're seeing with clients who've already made the transition:

Fewer payment exceptions, less manual rework

Industry benchmarks show that payment exception management (transactions requiring manual intervention, such as failed payments or ACH returns) cost, on average, $15–$25 per repair when you factor in staff time, delayed liquidity, and supplier friction. For a mid-sized multinational processing 50,000 cross-border payments annually, a 5-point improvement in straight-through processing (STP) rates can save $50K+ per year.

Reduced cross-border payment friction

The move to structured addresses eliminates many of the traditional speedbumps in cross-border payments. This means fewer payment exceptions, reduced repair costs, and improved straight-through processing (STP) rates — all critical metrics for treasury operations managing global payment flows.

Faster payments, better cash positioning

Structured addresses enable true automation. Payments that used to require manual review now flow straight through. That means faster value dates, improved cash forecasting accuracy, and better working capital management. In high-volume environments, the difference between same-day and next-day settlement can materially impact your cash position.

Stronger AML/CTF compliance with fewer false positives

With increasing focus on anti-money laundering (AML) and counter-terrorist financing (CTF), structured postal addresses enable a more effective and efficient fight against financial crime. Clearer, standardized beneficiary data improves screening accuracy. Compliance teams see fewer false positives, while genuine risk signals become easier to spot.

Better visibility across your payment ecosystem

When every payment carries consistent, structured party data, you can finally analyze payment flows by geography, counterparty type, or risk profile with confidence. The consistency creates a single source of truth across your payment operations, eliminating the costly rework associated with address validation failures.

What your payments team needs to know

Many banks have started to reach out to their customers indicating that they will not support non-compliant addresses and underlining the risk of payment rejection in case of invalid address transmission.

If you're managing payment operations or implementations, here's the technical translation of what's changing. Below are side-by-side examples for the three most common formats: ISO 20022 XML (Pain.001), MT101, and AFB320.

Understanding these distinctions will help you configure your systems correctly and avoid failed payments.

1. ISO 20022 XML (Pain formats)

What won't be valid after November 2026

What will be valid after November 2026

Fully unstructured addresses with only address lines:

Hybrid addresses with Town Name:

<PstlAdr>
    <AdrLine>Agustinas 641</AdrLine>
    <AdrLine>Santiago</AdrLine>
    <AdrLine>CL</AdrLine>
</PstlAdr>
<PstlAdr>
    <TwnNm>Santiago</TwnNm>
    <Ctry>CL</Ctry>
    <AdrLine>Agustinas 641</AdrLine>
</PstlAdr>

Partial address missing the Town Name:

Structured addresses with Town Name:

<PstlAdr>
    <Ctry>CL</Ctry>
</PstlAdr>
<PstlAdr>
    <StrtNm>Agustinas 641</StrtNm>
    <TwnNm>Santiago</TwnNm>
    <Ctry>CL</Ctry>
</PstlAdr>

Key takeaway: You need TwnNm (Town Name) and Ctry (Country) as discrete, structured elements, not buried in address lines.

2. MT101

What won't be valid after November 2026

What will be valid after November 2026

Unstructured addresses in tag 50 and 59:

Structured addresses in tag 50F and 59F:

:59F:/FR7630056002000200XX
THIRD PARTY
1 RUE DE PARIS
69001 LYON FRANCE
:59F:/FR7630056002000200XX
1/THIRD PARTY
2/1 RUE DE PARIS
3/FR/LYON

Key takeaway: Use tags 50F and 59F (structured formats) instead of 50 and 59, with town name explicitly called out in line 3.

3. AFB320

What won't be valid after November 2026

What will be valid after November 2026

Unstructured addresses:

Structured addresses with address qualifier:

12355 BROADWAY
12345 NEW YORK
US
12355 BROADWAY
US/12345 NEW YORK
23

Key takeaway: Use the address qualifier (code 23) and structure town name with country code prefix (e.g., "US/12345 NEW YORK").

How Kyriba can help

If you're staring at this deadline and wondering where to start, we've been there with many global clients. The pattern we see work: audit your data first, prioritize high-volume corridors, and automate the migration wherever possible.

Here's how Kyriba takes care of the technical plumbing so you can focus on data governance:

For ISO 20022 Pain formats: Kyriba's hybrid address aliases let you restructure beneficiary data once in your master records, then automatically map it to compliant output formats for both Creditor and Debtor parties. No custom scripting required.

For MT101 and AFB320 users: We've added address structuring parameters that trigger at the format level, converting your stored addresses into compliant output based on message type and bank requirements.

Built-in validation controls: Payment profile validation now flags transactions missing City or Country before they're released to the bank. You catch the error in Kyriba, not in a rejection message days later.

The technology handles format conversion. But the governance and data ownership? That's on you. Which brings me to what you should do next.

Our recommendation on your action plan

Step 1: Audit your beneficiary master data

Check Core data in Kyriba to complete all party addresses. Check your third-party database to add the city for all cross-border beneficiaries. You'll probably be surprised by how many gaps exist, especially for legacy suppliers or infrequently used entities.

Step 2: Prioritize by payment volume

Focus first on high-volume corridors and critical suppliers. A Pareto analysis usually shows that 20% of your beneficiaries account for 80% of payment volume. Start there.

Step 3: Assign data ownership by region or entity

Don't make this a central treasury solo project. Distribute accountability to regional finance teams or AP leads who know the beneficiaries. Set clear deadlines and track progress.

Step 4: Set an internal deadline with buffer

If the regulatory deadline is November 2026, aim for September 2026 internally. That gives you buffer time for testing, bank coordination, and fixing the inevitable edge cases.

Step 5: Automate the migration wherever possible

Use Kyriba's format parameters and validation rules to handle the technical conversion. Your team should spend time on data quality, not manual reformatting.

If you're managing 1,000+ beneficiaries across multiple entities, consider a phased rollout by region, entity, or payment type. Test in a low-risk corridor first, learn, then scale.

What's next

In the follow-up blog, we'll share how a global insurance company migrated their beneficiary records and the best practices we've learned together. If you're facing this deadline and want to learn, stay tuned.

Written By

Guillaume Metman

VP Product Management - Payments & Bank Connectivity

Guillaume Metman is VP of Product Management for Payments & Bank Connectivity at Kyriba, where he drives product strategy across payment processing, bank connectivity, and fraud prevention. With more than 20 years of experience in software development, product management, and IT operations, Guillaume brings deep expertise in payments, Agile transformation, and enterprise-scale solution delivery. A recognized payments expert and thought leader on topics such as ISO 20022 migration and cross-border transaction banking, he is focused on building scalable, secure payment infrastructure that meets the evolving needs of global treasury and finance teams.

Fred Dupas

Senior Product Manager

Related resources

Blog

ISO 20022 adoption is just the beginning: What to do now to lead in the new payment landscape

Read
Blog

Navigating the ISO 20022 Migration

Read
eBook

The Winning Formula for Your ISO 20022 Payments Migration

Learn more