To be ISO 20022 ‘ready’ is not good enough

30
October
,
2023
By:

Yoav Ash, Senior Product Manager, Vault Payments

ISO 20022 is already here. Many payment systems, whether global or domestic, are gradually transitioning to adhere to this format. New systems, meanwhile, inherently support this standard from the outset and will supersede the ones that do not. Meanwhile, payment software vendors exert significant effort to ensure their systems can seamlessly support this standard.

So, what does it mean to be prepared for ISO 20022? Most payment systems were initially designed with specific data structures for older, simpler message formats. We can imagine this structure propagating throughout the complex layers of an enterprise solution, from the most exterior connectivity layers to the database and the presentation layer.

Legacy systems are built to support legacy payment formats

Adapting these systems to handle ISO 20022's extensive dataset presents a significant hurdle. Vendors have explored various approaches and workarounds to address this challenge. Instead of attempting a complete overhaul of existing systems, including data stores, services, and integration points – a practically impossible task – the focus has mainly been on the periphery of these systems. This involves bridging the gap between ISO 20022 and their proprietary formats.
But is this approach sufficient? We will explore some of the issues that a bank might encounter.

Data completeness

Data transformation is inherently challenging, especially when dealing with vastly different data formats. Legacy systems data representation is incompatible with ISO 20022 data sets. It often lacks the space to accommodate them, leading to the need for auxiliary data storage or, in some cases, data loss and truncation.

Storing ISO 20022 payloads within legacy systems poses significant challenges


Truncating payment messages and losing ISO 20022 data pose significant problems. It disrupts interoperability and causes complications in data exchanges. It can lead to inconsistencies, errors, and inaccuracies in transaction data, potentially affecting financial operations and decision-making. It could result in non-compliance with regulatory requirements, potentially leading to legal issues and penalties. It hinders automation efforts, slows down processes, increases manual intervention and reduces operational efficiency. It might prevent a bank from participating in a payment scheme. Finally, ISO 20022 often includes essential security-related data. Losing this can compromise security measures and make systems more susceptible to fraud.

In both scenarios, valuable information remains inaccessible to the payment engine, rendering it unusable for crucial processing tasks like AML checks, fraud detection, sanction checks, reconciliations, and matching. Furthermore, managing and sharing this data with downstream systems becomes considerably more complicated.

Vault Payments was purpose-built to handle ISO 20022 messages natively. Its data structure aligns with the latest ISO standard, with specific configurations for each payment system, ensuring its unique implementations are respected. More importantly, all the original data sent and received from the payment system is preserved in ISO 20022, readily available for payment processing and downstream system consumption, for example, by core, KYC/sanctions screening, and reporting systems. All these systems must utilise the additional fields and information, making ISO 20022 a comprehensive and impactful change in day-to-day banking. This native approach ensures that data integrity and accessibility are maintained throughout the entire payment lifecycle.

Translation

In older systems, ISO 20022 fields get translated to the engine’s proprietary fields, and this translation is ultimately what downstream systems, integrations, user interfaces, and users interact with. This adds complexity, making it necessary to provide more guidance and interpretation for the bank to use the data accurately.

Moreover, a bank must build translators/mapping tools within an integration layer between payment systems, payment engines and the bank's applications. This poses a challenge to build, integrate, and maintain. Adding those mappers typically means procuring and installing additional software, high licensing costs (because banks often leverage existing middleware to achieve high throughput) and requiring trained personnel that can handle it, incurring further costs.

Incorporating translation layers introduces further complexity

Therefore, the optimal strategy entails adopting a native ISO 20022 canonical format as the fundamental framework for all aspects within the payment engine. Vault Payments stores instruction data adhering to ISO 20022 naming conventions and structure, all while preserving a minimal memory footprint using efficient data transmission protocol despite the richness of the data. Payments retain their original presentation, eliminating any potential confusion. The ISO 20022 representation is owned, maintained and updated by Thought Machine in line with changes, guaranteeing ongoing compliance with the standard.

This approach streamlines integration endeavours and significantly contributes to standardisation and simplification within the bank's infrastructure.

Introducing new messages

ISO 20022 isn't just rich because its payment messages are detailed; it also accommodates various message types for different purposes. Payment systems worldwide are increasingly adopting these diverse message types. However, integrating new message types into existing systems can be costly and time-consuming. Vendors often focus on other tasks, leaving banks without support, forcing them to seek alternative solutions or forgo using the new message types altogether.

Request to Pay messages are one example of this. If the payment engine cannot accept these messages, they will be delegated to a separate service. This exacerbates the issue of payment stack complexity. It adds a new service to the stack and requires integration with the existing payment system to facilitate the interactions between the two services.

The integration of new payment methods adds fresh elements to the payments infrastructure

In contrast, Vault Payments was purpose-built to incorporate new message types swiftly. Adding a new message type to Vault Payments is mostly a matter of defining the necessary ISO 20022 fields and structuring them for use within the platform. Once done, the new message becomes available via the API and across all Vault Payment services.

Business logic

Simply acquiring and storing messages isn't sufficient for banks; they also require business logic to act on these messages effectively. Banks frequently encounter inconsistencies in the support levels for new messages. Even though a payment engine can ingest and store a new message type, it might not encompass the business logic these messages provide. This limits the bank’s ability to capitalise on the enhanced format fully. New messages are stored in the engine and, in some cases, exposed to users. Still, neither the payment engine nor users can act on these messages, and their resolution depends on other, non-related services and processes.

It’s possible to observe new message types, yet taking action on them is not possible

In Vault Payments, once the structure of a message is defined, it becomes accessible through all public APIs. Moreover, it can seamlessly integrate with the configurable Instruction Flows, enabling our clients to define and maintain the message's business processing logic and lifecycle with their own flows, rules, and external call-outs, removing the dependency on the vendor to build and maintain these. 

This seamless integration enables the orchestration of sophisticated interactions with messages, swiftly introducing novel and valuable capabilities for customers, all achieved within a remarkably short time and with minimal effort.

A strategic imperative

Data serves as the lifeblood of modern financial systems, and ISO 20022 heralds a crucial advancement in data richness and standardisation. ISO 20022's expansive data model facilitates streamlined processing, enriched analytics, enhanced regulatory reporting, and superior customer experiences. Leveraging the potential of this standardised data format isn't merely a compliance obligation; it stands as an essential strategic imperative for financial institutions.

When evaluating potential partners for this transformative journey, you must ensure they can deliver a solution that ensures ISO 20022 data completeness, facilitates easy integration with your stack, supports new business processes and is future-proof, flexible and composable.

Choosing the right partner will ensure that your bank migrates successfully and reaps the strategic advantages, positioning your institution where you aim to be in the evolving landscape of global payments and financial services.

Read more about Vault Payments

<< Previous blog
Next blog >>
Empowering our clients to accelerate their modernisation
Read this blog
Money20/20 Banking Infrastructure Summit: What to expect with a core modernization program
Read this blog
Money20/20 Banking Infrastructure Summit: Building a modern technology stack
Read this blog
To be ISO 20022 ‘ready’ is not good enough
Read this blog
Building a winning team with a strong culture
Read this blog
Domain-driven design and the future of payments
Read this blog
How does Vault Core compare to closed-box systems, and what does this mean for product development?
Read this blog
Introducing our Enablement Portal – a complete resource for support, knowledge and training on the Vault platform
Read this blog
The Integration Library: a growing collection of solutions with best-in-class technology vendors
Read this blog
Building a bank on top of kubernetes
Read this blog
From speech technology to banking
Read this blog
Strategic partnership with Lloyds Banking Group
Read this blog
Cloud computing will save banks billions. Here's how
Read this blog
A demand for COBOL expertise underlines the fragility of critical infrastructure
Read this blog
Why are cloud systems so much more reliable?
Read this blog
Life may have slowed down but innovation doesn’t!
Read this blog
Building a core banking system in a distributed environment
Read this blog
Strengthening our commitment to cloud native design
Read this blog
Cloud Native - what does it mean? An interview with CNCF's Cheryl Hung
Read this blog
Shaping the future of banking IT: We’ve joined the Banking Industry Architecture Network (BIAN)
Read this blog
Why microservices are the future of banking
Read this blog
GFT and Thought Machine forge strategic partnership to accelerate global banking transformation programmes
Read this blog
Q&A with Nick Wilde, MD of Thought Machine Asia-Pacific
Read this blog
How Thought Machine can unlock the cloud for banks with Red Hat OpenShift
Read this blog
Round table: Meeting the challenge of a digital future
Read this blog
How to go full cloud native with CockroachDB
Read this blog
Meet our chair Andy Maguire
Read this blog
Core banking transformed: accelerating migrations with cloud-native cores
Read this blog
Let business justify your investments into digital-native core banking systems
Read this blog
How Thought Machine exceeds global industry standards in compliance and security
Read this blog
Thought Machine redefining banking with Standard Chartered
Read this blog
Sign up to our newsletter
Thank you! You will now receive some incredible content in your inbox!
Oops! Something went wrong while submitting the form.
For information about how we use your data please read our privacy policy.