How to get SR 2026 ready

Client: A large North American financial institution (FI) 

Sector:  Payments of every kind: high-value, cross-border, real-time and batch  

SR 2026 address changes impact: adherence to structured or hybrid address; additionally richer party and bank data, enhanced remittance information data  

Problem: The FI treated SR 2026 changes as message formats upgrades. But it turned out to be about more than that, the underlying data flow needed fixing.  

What we did:  Mapped how payment data flows from end to end, cleaned it up, and helped the client settle decisions it had put off for years  

The result: A clean, safe path to the new format and readiness that carries across all of the region’s payment systems. 

The numbers:  

• 60% migration readiness achieved against the structured address data requirements underlying SR 2026 (independent of the latest Swift announcement) 
• 37% of institutional clients supported end-to-end on testing readiness

Before we start: A note on Swift’s announcement

On 27 August 2026, Swift confirmed it would defer the November 2026 enforcement deadline for structured addresses. The postponement came after several community banks asked for more time to comply. A partial SR 2026 package is expected in Q1 2027 for non-payment items. Swift is expected to confirm the exact date in mid-September 2026. In the meantime, SR 2025 will remain in effect until its replacement is live.

What changes

The timeline. Institutions now have more time to close the gaps this case study describes, reducing the risk of payments being rejected because of the old November rules and guidelines.

What doesn’t change

• The data quality issues rooted in legacy systems, ERP platforms, and free-text address capture remain exactly where they were.
• Domestic and regional deadlines that already passed are unaffected. SEPA payments have supported structured addresses since November 2025, for example.
• Sanctions screening, straight-through processing, and reconciliation still depend on structured data, regardless of when SR 2026 rules are eventually applied.
• Short-term bridges like translation tools still can’t invent structure that was never captured at source. That risk has only been delayed.

November’s deadline has moved, but the risk still exists. What we experienced while implementing SR 2026 changes for a large client is no different from what institutions will experience chasing the new timeline.

This case study offers a proactive view of what needs to be considered for an effective implementation, whatever the eventual deadline.

Case study: The challenge

A Large North American financial institution needed to get ready for the ISO 20022 deadline (SR 2026).   

While adhering to address change was a major part of the SR 2026 guidelines, there were underlying data quality challenges. They were rooted in legacy systems and exposed significant gaps in customer master data, ERP systems, and varied source applications.  

The current systems did not have the field-by-field complete mapping of payment data, and tracing that uncovered good data being lost at every step.  

It could start when a customer typed an address into a free-text box on their phone. The message instructions would pass through channels, middleware, and validation checks with individual limits on field length. Then, they’d arrive at a payment engine designed around the older “MT” format.   

From there, the payment data traveled outward. It flowed to sanctions and fraud systems, reconciliation, downstream reporting systems, the ledger, and the data warehouse. Each step was an opportunity for data to go missing. 

If a downstream system lacked room for the richer fields, it would trim the new data to fit. There was no error, warning, or failed payment. So the client believed it was screening against complete information. 

The issue only surfaced when someone went looking. By then systems had already been working with incomplete data for too long.  

And the issue was not limited to retail customers. The same was true when one of their corporates sent a file built in accounting software using 20-year-old formats, crammed into a few lines.  

So, to fix this, the FI bridged old and new formats using translation tools. But this was a short-term fix. One that could cause issues post-November 2026. Following SR 2026, fully unstructured addresses are no longer permitted in CBPR+ payments. A translator can’t invent structure that was never captured, so payments might face delays, repairs or rejection at the counterparty or get flagged during screening.  

The translation tool may have meant messages travelling to other banks were ISO 20022 compliant, but the client’s  own systems still had unstructured data.   

SR 2026 changes: same impact despite the delay

Mapping data lineage reveals where problems live—but it doesn’t solve them. While SR 2026 appears to be a data enrichment exercise on the surface, the reality is broader. Successfully migrating to ISO 20022 requires simultaneous decisions across three interconnected domains: 

Data: Address models, party information, and remittance field structure must align to the standard. 

Standards: Message versions, interoperability rules, and CBPR+ guidelines reshape what’s permissible upstream and downstream. 

Architecture: Microservices, mapping layers, and end-to-end channels (from pre-processing to payment engine to SWIFT) must be redesigned to enforce those standards.

Layer bank-specific rules on top, and there is no single path forward. Each institution’s legacy systems, customer base, and operational constraints force different tradeoffs, creating what amounts to a portfolio of decisions deferred from prior releases, which are now all due at once. 

Our work gave a clear, safe path to prepare for the SR 2026 migration with clear data traceability, turning a mandatory upgrade into an opportunity to improve data quality and automation across its payments.

We turned a mandatory upgrade into a chance to improve data quality and automation across its payments. A similar approach will hold true for future implementation.

The result

Rich data is now a permanent and integral part of the payment journey. It’s now captured and kept on every payment and has become an asset owned by the financial institution.

This new system creates multiple benefits:  

• Clean, structured data removes the guesswork, meaning more payments process automatically and fewer land in manual repair queues. Systems now know the difference between a street name and country, or safe party from a listed one, creating sharper sanctions screenings and reducing false alarms
• Reconciliation is much easier, because payments now carry the details needed to match them to an invoice automatically
• Fraud detection gets better data to work with, which matters even more as instant payments systems arrive  
• And in correspondent banking, clean data becomes a selling point: banks that send tidy, complete payments cost their partners less, and the best partners go to the banks with the cleanest data
• Beyond the SR 2026 scope itself, we also helped to design new process flows and capability expansion for the client’s payments orchestration layer. This aligns to their Payment Engine traffic but offers the flexibility for other payment rails.  

These benefits grow over time, but maintaining data quality is non-negotiable. Without ongoing data governance, STP rates and rich data quality will be impacted, and you’ll face the same data-quality challenges that predated ISO 20022.  

10 things you should know ahead of SR 2026

It’s not an option to transition to ISO 20022, but how you make those changes is.

Here are ten ways to approach the migration:

1. Run it as a data project: Ensure there’s a dedicated team for supporting the data enrichments across all layers of payment flow. 

2. Map the data: Do this field-by-field, across your payment engine and all connected microservices before writing any code and keep the map up to date afterwards.

3. Standardize inside the bank: Canonical data model stops you repeatedly making the same changes.  

4. Treat data clean-up as an ongoing job: tools to parse and score data, people to review the hard cases, and controls that stop bad data getting back in.

5. Treat customer and channel onboarding as a project: The bank cannot send structured data if a customer hasn’t provided it. 

6. Factor in client and channel readiness as change management: Phase-out timelines have to be planned around client segments, not just internal milestones. 

7. Don’t reinvent the wheel for every customer: Every custom tweak is a small change that you have to maintain, test and support forever.

8. Measure before you go live: If you don’t measure automation rates, false alarms, repair rates, cost per exception first you can’t prove the value later.

9. Hold your vendors to the same yearly schedule: ISO 20022 requires annual maintenance, so your contract should hold vendors to ensuring updates keep pace with the latest messaging versions. Applied AI tools, like our own Payments Expert Agent, can help to manage the cadence and navigate each year’s release changes year-on-year rather than treating each cycle as a fresh project.

10. Plan for a moving target, not a fixed date: Build governance, budgets and vendor contracts on the assumption that the timeline itself may shift again, so the program doesn’t stall every time Swift issues an update.

Need help with your ISO 20022 migration? 

We’ve helped major banks and financial institutions across the globe with structured address migration. From end-to-end mapping of payment data, to building rulebooks and keeping data quality in place long after go-live. If any of the gaps in this case study sound familiar, you don’t have to solve them from scratch.  

Payments Expert Agent, our AI-powered solution for payments modernization, helps teams to navigate ISO 20022 and annual SR-release changes, so each cycle can build on the last.  

If you’re evaluating where your own project sits or what Swift’s SR 2026 deferral means for your roadmap, get in touch today.