Diving straight into the tough and technical, we asked Tagai how financial institutions should position themselves to effectively capitalise on the vast opportunity ISO 20022 presents.

First and foremost, Tagai notes, there is a huge challenge for financial institutions moving from an unstructured to a structured data environment. “ISO 20022 is really about moving from unstructured to structured, moving from more human intervention toward automation. With more automation comes more informed decisions, better analysis and less errors.”

The issue, Tagai explains, is that one bank can’t do this alone. Change must be a community-based, collaborative approach: “We as a bank want to ensure that everybody migrates successfully because it is only then that we can really start to capitalise on opportunities that ISO 20022 offers.”

As ISO 20022 is being introduced to facilitate further automation in the underlying business processes, this new and enriched data format will change the way data is held and processed. He furthers that cross border payments still handle unstructured data in some of the key fields, and a migration to ISO 20022 would facilitate the transition to a further structured data environment which would allow for further automation.

Therefore, banks need to embrace structured, granular data and capitalise on automation opportunities (such as party identification or sanctions screening), focus on client pain points in their reconciliation of incoming payments, and explore any other unmet data transport needs in the bank to bank chain that may help the client

What are the technologies that will assist banks in their efforts to implement and reap the rewards of ISO 20022?

Also serving as chairperson of the ISO 20022 Registration Management Group (RMG), Tagai explains that the technology being assessed within the RMG focuses on ensuring that banks implement not just the ISO 20022 message, but that there is an overarching business and information model that drives the message.

“The current implementation that is discussed amongst the payment banks is really about the what they call the XML message - the fields, the formats, the data - but there is an overarching business and information model above that, which says, use this message when Bank A sends Bank B this type of payment. At RMG we’re not going into too much detail around trying to map the differences and formats, rather, we’re trying to make sure everyone agrees that they’re using the same message for the same purpose.”

This would mean everyone agrees at the business and information model level before discussing the granular data mapping issues. Tagai states that banks first need to take a step back and assess whether they are integrating ISO 20022 messages in a future-proofed way, rather than just ensuring everyone is merely complying with the Swift message format.

“We hear more about mapping data from application to application without paying much attention to the entities that pass along the financial message (the business and information model) and the data and the definitions that are passed across in the financial messages (the logical message model). This extra step should be helpful when you go to Year 2 and onwards when each of your applications operate in a silo today and when thoughts start to progress in terms of how to achieve interoperability across different business disciplines.”

He elaborates that as data becomes granular, banks should also be prepared to embrace that each domestic market in the cross-border payment chain operates differently and that the same term such as “purpose code” or “address” may have different definitions for local processing reasons.

“As the format becomes more granular, differences will come out clearly as well as the varying data quality that is highest when it originates at the debtor. The ability to reconcile your internal data dictionary against external definitions especially in extremely fragmented practices such as cross border payments would be a key to understand data quality at each firm.”

Are standardised APIs are the key to API process integration interoperability?

While a standardised ISO 20022 API does not exist today, and that there is no ISO 20022 standard once a company quotes an API (as ISO 20022 messages are expressed in lonstanding XML language), Tagai observes that there are many opportunities which would come with such standardisation.

For the sake of clarity, he adds that standardising the API development would require two steps:

1. Standardising the API Resources: API Resources represent data elements that a service provider exposes to its clients via API methods. Using registered standardised API resources will ease the integration of the APIs for the service provider and its clients with other standardised (API) services and with standardised ISO 20022 messages.
2. Standardising the APIs: This step relates to the design of the API calls that manage the resources (read, change, create, etc.).

“As there is no current standard, APIs have become very popular as they are flexible and easily customisable as a means of data exchange. Because of this however, while most institutions are using common elements for the same business purpose, they are developing their APIs in different ways. This means that clients are get confused and the situation becomes complex.”

Opportunities have started to be addressed where first the ISO 20022 community has defined the difference between Standardised APIs and Standardised API Resources. The community has also begun to accept API resource registration requests, and looked to formalise the API resources registration by establishing a group under the RMG that considers anything related to API Resource registration.

“The thing is, standards come a little bit after market development. Everybody wants to be first to the client and for their first product to become the standard. But obviously, this process is fast, but it's not pretty. As a result we start to see fragmentation and standards come a little bit later.”

While this process may have taken five to ten years historically, these days - particularly with the pace of cryptocurrency, digital assets and real time payments, the need to expediate this timeline is greater.

“What I observe in the ISO 20022 space is that even the slowest of the Standards people are really becoming fast and trying to get ahead of market.”

What are you most looking forward to at Sibos 2022?

Tagai concludes that Sibos is “an opportunity for me to have real industry dialogue, understand the true pain points of the clients.”

Importantly, he hopes to “light the beacon under the banner of data quality!”

Finextra will be covering Sibos live from Amsterdam from October 10th to October 13th. Be sure to keep up to date with all of the event’s news and announcements via Finextra’s Live@ Sibos page throughout the week.