<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=4138537&amp;fmt=gif">
Menu
Request demo

ISO 20022 by a Thousand Cuts

In our latest webinar “ISO 20022 by a Thousand Cuts” we discussed the pitfalls of ISO 20022 migration for banks. Usually, problems start to arise when the transition is done bit by bit and the overall picture may be missing - which usually leads to higher operating and maintenance costs because this approach is inefficient. Customers can also face difficulties if banks don’t create and maintain general guidelines for their ISO 20022 standardized messages.

 

There are a few common mistakes that can lead to a major headache while adopting the ISO 20022 standard. But first, what drives banks to migrate? Typically, the need for migration results from corporate clients who have already adopted the ISO 20022 standard in their own payments handling. These customers commonly work with multiple banks, and they want to use common global payment messages as much as possible. On the other hand, bank teams may be driven by the need to migrate to ISO 20022 because their clearing and settlement system is starting to support the new format. Especially with cross-border payments over SWIFT, it’s important to adopt unified message types. Finally, transformation becomes topical when banks want to build a new version of their own payments processing systems.

Let’s examine two of the most common scenarios that can lead to what we call the ISO 20022 “piecemeal adoption” traps. In the first scenario, customers ask their banks if they can use ISO 20022. As mentioned, these customers might already use this standard in Europe, and based on that, their ERP system is set up to do payments reconciliation and reporting quite efficiently. Thus, these corporates will want to utilize the new format both locally and globally, looking to unify processes. However, if the bank hasn’t set up a program to support routine use of ISO 20022, they might be tempted to just agree to support their customer’s version of it. Additional requests from other clients would then lead to multiple versions of tailored translation logic. Unfortunately, this approach can quickly lead to a long-term maintenance nightmare.

Furthermore, banks could start to consider ISO 20022 migration because they’re updating existing systems. As the transition to the new format might be demanding to corporate clients, banks rightly fear it could affect customer relations. Thus, it becomes tempting to hide the transformation and accept different formats from customers. Providing a translation service could help to fill the gap between the bank’s desire to utilize ISO 20022, and the customers’ need for more time. Still, again these efforts could result in multiple and expanding versions of translation logic and higher maintenance overhead.

We call these two scenarios ‘ISO 20022 by a Thousand Cuts’. If ISO 20022 is adopted in bits and pieces, involving layers of transformation logic for customers as part of the migration, it will likely lead to more complexity and higher maintenance costs, making ISO 20022 into a long-term annoyance - even though it should be embraced as a way to enhance overall efficiency and simplicity across payment channels. So, banks should avoid “hiding” the migration and be proactive with their clients. For example, if banks offer tools to their customers that help them work in line with the bank’s general approach, it makes everyone’s work easier and enhances customer satisfaction.

About XMLdation

XMLdation is a world leader in financial messaging. Our solutions are designed for banks and clearers.

Our solutions Request a demo today

Latest

More

Stay up to date

Subscribe to our newsletter