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

By
Guillaume Metman
VP Product Management - Payments & Bank ConnectivityFred Dupas
Senior Product ManagerShare
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


