ISO 20022, what is already changing in corporate payments and what to do next
After years of considered progress, ISO 20022 payment files are now widely adopted by corporates in the UK. But the migration is by no means complete: In 2026, banks and payment schemes will be asking their corporate customers to uplift the data provided in their payment files. These new requirements will influence how global banks accept, validate, and repair payment files.
The biggest risk for corporates executing payments at scale is not a single big bang migration date, it is fragmented deadlines, different bank interpretations, and silent friction in unattended payment channels. Those organisations that move early towards compliance reduce operational friction, failed payments, and last-minute remediation work.
What is actually happening to corporate payments
SWIFT deadline: November 2026 is the cut-off for unstructured address data in cross-border payments on the SWIFT network.
Swift have set a November 2026 deadline for their member banks to move away from sending payments with Unstructured Address data and to provide either Fully Structured or Hybrid Address data instead. The Banks will pass this requirement onto their Corporate customers who are sending payment instructions via unattended channels, i. e. Host to Host Connections and the Swift network.
Bank-led format upgrades are already underway, ahead of migration deadlines.
Some banks are taking the format updates as an opportunity to refresh their core payment infrastructure. This includes enforced moves from older formats such as pain.001 v3 and FIN MT101 to pain.001 v9. Though timelines and scope vary by bank, ISO 20022 is here to stay and now truly embedded in the banks’ infrastructure.
Scheme and market infrastructure rules differ, adding complexity.
Domestic and cross-border schemes are layering in additional requirements. These rules introduce requirements for Structured Address, Purpose of Payment Codes and Structured Remittance data. Rules differ by country, currency, and payment type, so there is no single global checklist.
No unified timetable for migration
And finally, banks, schemes, and infrastructures are not moving in lockstep, instead adhering to their own internal timelines which are only inconsistently communicated. This creates overlapping windows which could lead to a mixture of some payments passing cleanly, while others are delayed or repaired due to insufficient business data.
What this means in practice for your payments
1. More mandatory data
Fields such as town name, country, and purpose codes become required for certain flows. Missing data does not always cause hard rejection immediately, but often triggers manual repair.
2. File format changes
The format of the payment files sent to the bank may need to change, e.g. from pain.001 v3 to the newer pain.001 v9. Field definitions, validation rules, and allowable structures are tighter and more explicit.
3. Inconsistent bank behaviour
Banks will have different policies for handling payment instructions that don’t comply with the new requirements. While one bank may accept a hybrid address, another may insist on full structuring. Non-compliant files may be repaired, delayed, or rejected depending on the bank’s policy, increasing operational risk for corporates.
The result of inconsistent adoption: Hidden operational risk
Payment repair introduces latency, cost, and may reduce audit clarity. This risk only scales up with payment volume, geographic spread and a diversified banking portfolio.
What you should do now, not later
AccessPay have put together a practical ISO 20022 action plan to guide you through the best steps to take during this transition period.
1. Talk to your banks
Talk to your bank relationship manager to find out which payment types will be affected, what the timescale is for any changes that you need to make, and which address model they expect, hybrid or fully structured. Get clarity on deadlines by payment rail, not just headline dates.
2. Create an internal project team
Set up an internal project team to discuss the necessary changes with your internal IT and your TMS, ERP, and Payment connectivity providers to plan for any changes that are required.
3. Talk to your ERP or TMS providers and map data
Find out if you have the necessary data available in your systems or whether an exercise is required to enhance it. Where data is missing, plan remediation at source rather than downstream.
4. Move to early testing with your Payment connectivity provider
As soon as an ISO 20022-ready file is available, move to testing in your payment automation solution. Early testing reduces rework, especially where multiple banks apply different rules. We recommend that AccessPay customers contact us directly for advice and support with implementing and testing any changes that are needed.
How AccessPay supports through the ISO 20022 change
Implementation guidance: AccessPay provide advice on how to implement the ISO 20022 changes and identify key points for success. We help our customers to gain a clear understanding of bank and scheme requirements as well as file format compatibility.
AccessPay’s ISO 20022 uplift service: We upgrade our customers’ existing configurations to support new file versions and data points. We facilitate testing of new ISO 20022-ready files with SWIFT MyStandards and directly with your banks. Additionally, we support low-value testing and controlled cutover to production.
Please note: Enrichment is a master data challenge that must be resolved at the source (ERP or TMS). AccessPay does not enrich missing address or purpose data.
Conclusion
Updating ISO 20022 payment files to support the latest payment rail and Bank requirements is a long, fragmented transition that is already influencing how banks validate, repair, and process corporate payment instructions today. The organisations that treat this as a live operational change, rather than a future milestone, put themselves in a far stronger position.
There is, however, real work involved. Early preparation requires coordinating across finance and treasury operations, IT, banks, and system providers, and it often exposes weaknesses in master data. Organisations that engage now will experience the enhancements to ISO 20022 data as a controlled evolution of their payment processes, supported by their Payment connectivity partners.
To learn more about the coming ISO 20022 changes, we recommend:
- AccessPay: ISO 20022 Action Plan
- Swift: Swift Payments Market Practice Group document centre | Swift
- Hybrid & Structured Address: Swift Payments Market Practice Group: Hybrid & Structured Address
- SEPA for Corporates: 5 Things Corporates Must Know About SWIFT CBPR+
