The hidden cost of ISO 20022 messages

When the Swift coexistence period ended in November 2025, around 80% of daily traffic and more than 3 million payment messages were already on ISO 20022. With Fedwire going live in July 2025, major high-value rails across the eurozone, the UK, and the US had already switched one by one. Banks could be forgiven for thinking the bill had been settled.  

But it hadn’t. Migration was a one-off invoice, with a clear amount, owner, and deadline. What came next was more like a subscription: recurring charges that weren’t part of the original business case.  

Swift’s decision to push the SR 2026 structured address mandate to 2027 is a reminder of that. The deadline moved, but the cost didn’t disappear. It will simply arrive on a later invoice.  

The unbudgeted costs

Banks spent years planning, budgeting, and migrating to ISO 20022. Storage and data cleansing were, for the most part, in the plan. The unplanned costs are those that continue to arrive after go-live.  

So, in practical terms, what exactly has changed? Let’s take the example of the name and address of the person making the payment. Pre-ISO 20022, in an MT 103, name and address sat in a single field across four lines, with 35 characters of free text per line. In a pacs.008 the name has its own field, with postal addresses broken into more than a dozen elements. Each has to be populated, validated, stored, and governed.  

It’s a significant change. And if you scale that up across billions of payments, that’s a huge step up in the amount of data being handled. This is one of several sources of ongoing costs, which break down into four categories:

1. Ongoing standards maintenance

ISO 20022 isn’t a fixed target. There are Swift annual standards releases, CBPR+ (Cross-Border Payments and Reporting Plus) usage guideline updates, and changes to domestic market infrastructures that all impact the same systems. Every update requires impact analysis, mapping updates, and a full test cycle. While migrations come with a project code and fixed cost, maintenance rarely does.  

2. Translations

Many core banking systems are still not ISO-native. A single payment can go through multiple translations from ISO 20022 into a proprietary format, pass through screening and reconciliation systems, and then back again on the way out. Each conversion risks data being truncated or lost, and every layer brings its own license fees, maintenance, and testing.  

3. Upstream remediation

Poor data in a payment message rarely comes from the payment engine. It starts in channels or customer master data and file formats sent by corporate clients. To fix it takes a lot of work on the bank’s side. It involves changing the channels, cleansing the data, and working with corporate clients to change their formats at the source. That work isn’t included in the original payments budget and relies on IT roadmaps outside of your control.  

4. Regulatory exposure

Raw data storage is cheap. The cost comes from managing the personal data that ISO 20022 messages now carry. 

Looking at the pacs.008 message again; it can carry structured addresses, identifiers, and, sometimes, dates of birth. So each payment becomes a rich record of personal data. This richer data is copied into production, disaster recovery, backup, and archive, and then again by every system the payment touches.    

This creates three additional, often unseen costs: 

• Privacy exposure: more personal data in more places means a larger footprint under GDPR and equivalent regimes. Also, more to lose in any data breach.
• Retrieval effort: If a customer submits a data access request or a regulator needs payment records, you have to find every relevant copy across your ecosystem. That can involve pre- and post-ISO 20022 migration formats.
• Volume-based pricing: Many screening, archiving, and cloud vendors charge by message volume or data size. Bigger messages and more copies mean bigger bills.

Why the costs stay hidden

On their own, each of these costs can look manageable, but each one lands on a different team’s budget. Infrastructure pays for storage. The data team handles cleansing. Compliance runs screening. Engineering builds and maintains the platform.  

That’s the difference between the migration and what comes after. Before there was a regulatory deadline, a named owner, and a dedicated budget. This meant funding was straightforward. Owning the data is an ongoing cost, spread across teams, with no end data or final invoice.  

Banks that add up the pieces will have a clear view of what their payment data costs today, and a baseline for deciding what it should deliver.  

Turning data from cost to asset

The most expensive data is the kind you pay for but never use. Storage, cleaning, and screening all cost money, but none of them generate a return on their own. Until a bank builds the capability to read and act on its payment data, it’s essentially hoarding very expensive XML files. 

Banks have two choices for what to do with this data. There’s store-and-ignore, where you pay for storage and cleansing, tick the compliance box, and the data sits in a lake where nobody goes fishing.  

Or store-and-leverage. Build an analytics platform and turn payment data into a live intelligence layer that delivers ROI. Here’s how the data lifecycle works:  

Each step is valuable. It’s about having consistent, structured data fields at each step that work reliably across different systems and situations.  

You’re paying for the data, why not use it?

Richer payment data isn’t a cost that you should try to minimize post-ISO 20022 migration; it’s an asset that you have already paid for. It’s up to you to maximize the impact. The data exists in every single payment message, so you can either let it gather dust or use it to reduce fraud, improve compliance, or make faster payments.  

If you aren’t yet using this data, start by understanding what you’re dealing with. Before investing in better cleansing or an analytics platform, run a small, focused audit to size the problem. Here are some examples of what you should measure:  

• The share of payments where the Ultimate Debtor field simply duplicates the debtor’s details  

• The number of truncation events that happen as data passes through each translation layer 

• The share of payments that rely on NOTPROVIDED or unstructured addresses 

• The volume of manual repairs driven by data issues  

Understanding those numbers will tell you where the real cost sits, and where you can get the quickest return.  

Before the end of coexistence, banks budgeted for the migration. Now it’s time to budget for the data. 

How can RedCompass Labs help?

RedCompass Labs has supported banks through ISO 20022 for well over a decade, and the work that follows migration. Get in touch and find out how our experts can help you get more from your payment data.