Migrating to ISO 20022: what have we learnt, where do we go from here? (Part 1)

It’s been almost two years since most Tier-1 banks in the UK embarked on migrating their payment messaging to ISO 20022; the goal was to move away from disparate, messy file formats and missing info therein, manual repairs and payment failures to a frictionless, toll- free, global expressway of payments powered by a wealth of data. With exciting technology modernisation plans by Pay.UK and global market infrastructures on the one hand, and alluring data enabled use cases for businesses on the other, stakeholders across banks and fin-techs providing overlay services readily bought into the dream. A land of sugar and honey.

In this two-part blog series, I look back at the dream, how far we have travelled, the roadblocks encountered, and where we go from here.

A recap

For the uninitiated, ISO 20022 messaging standard is a globally accepted methodology to transmit data. For payments, it is being used to drive consistent financial messaging standards globally. Its xml-based structure allows interoperability, as well as the ability to carry more comprehensive and structured data sets which offer the benefits of transparency and traceability. This not only makes Anti-Fincrime (Sanctions/AML) checks easier and more accurate, but also reduces the considerable friction involved, particularly in ‘many to many’ cross-border and high value payments. In the long term, the power of this ‘rich/better data’ offers wider benefits for the economy by facilitating competition, innovation and collaboration. This migration has been well underway globally, with more than 70 countries having already adopted it and almost 200 Market Infrastructures (MI) either already implementing it, or considering adoption (as per SWIFT).

Program management to the rescue

For the banks, existing cost pressures were intensified by a new breed of agile competitors, challenger banks and fin-techs, who were better able to react to the changing needs of the end customer; and then exacerbated by the pandemic which changed the world as we knew it.

With anywhere between 5-20 implementations planned for the big banks, migration to ISO20022 was a once-in-a-generation program management challenge, and opportunity, to save costs and deliver new use cases and business models. The dithering timelines and the scope, including delays by SWIFT for CBPR+ last year, and the New Payment Architecture for UK domestic payments, ensures it is still a daunting planning challenge.

Which is why it is crucial to align multiple implementations in a way that costs associated with siloed projects are minimised, bloat in existing payment and supporting systems is reduced, and centralised changes to business, process and IT are implemented first to enable the individual implementations to reap the benefits. In my experience, and I am happy to hear contrary arguments, the banks who have done better have put in a hybrid structure with centralised teams planning, directing and governing federated delivery teams. This has enabled them to a) solve centrally for common problems like budgeting, KYC processes, data quality, and b) test, monitor and report compliance progress, while ensuring the implementation is agile.

Carrier of faulty goods

Going in, the biggest challenge was expected to be the availability of customer data which is complete, structured, and up to date. Without this the objectives of transparency, traceability and reduction of fin-crime activities as well as ‘false positives’ related delays are at best partially achieved. Almost all the global banks have disparate KYC/customer on-boarding processes and systems for the different geographies and LoBs they operate in.  This results in a) different ways and formats in which the data is captured, often lacking in important attributes, and b) duplicate and/or disparate data, i.e. many localised views for the same customer. While it is tempting to see this as a payments problem, ISO 20022 or any other format is but a carrier of goods, and its efficiency is dependent on the quality of said goods. ISO 20022 migration, at its heart, is not so much a payments problem as it is a data problem, which means that it cannot be viewed as a problem for the payments team alone, it has to be viewed as an organisation wide data challenge.

The challenge again, like most things, comes down to the costs associated with large scale transformations at an enterprise level. I think the solution entails a centralised approach led by the Chief Data Office, together with the KYC and anti-financial crime teams as well payments teams to deliver innovative data strategy and cost-effective solutions that don’t take eons to complete.

Indeed, some of the banks have built modern data harmonisation overlay services that don’t impact existing processes and sources or require large scale transformation. These micro-services based solutions consume data from existing sources, centrally cleanse and supplement those using a variety of AI tools as well as external data sources, and then act as the provider of single customer view for any consuming function, including payments.

External API based solutions like the SWIFT KYC register, which has started with registering corporates, are a step in the right direction. Open banking led ‘read’ services around customer data are being increasingly used to alert banks to ‘refresh’ their customer’s information. The regulators need to allow for services where the most up-to-date KYC data from one PSP can directly be consumed by any other authorised PSP to automatically update the customer records in its systems.

Additionally, regulator led inter-bank standardisation on KYC processes and data sets across customer segments could lead to KYC function and data being served as a shared utility amongst banks/PSPs. Both of these would be a win-win for PSPs (who wouldn’t have to invest in costly KYC process completed elsewhere), as well as the consumers (who wouldn’t have to go through the same tedium with different banks each time they open their account/ change details).

This is a very broad and current topic that I expand on in part 2 of this blog, but in the meantime, if you would like to discuss it in more detail I would be happy to have a discussion.