ISO20022, also known as the universal financial industry message scheme, is the platform proposed by the International Organization for Standardization (ISO) to develop all financial messages. It is not a suite of message standards, but a recipe to develop message standards for all domains in the financial industry. The main ingredients being syntax-neutral business modelling methodology, i.e. the business model of a message is not dependent on any technical language, and design rules which decouple the business standard from the physical message formats, i.e. the rules that describe how the messages represent the various business operational requirements are distinct from the rules that define how messages are constructed and formatted from a technical perspective. The model can evolve with the business, while the format can evolve with the technology to benefit from the latest innovations. At the beginning of the century, an XML was perceived to provide a common language for the industry.

However, since XML is not a language, but a meta-language (i.e., it is a framework with which you can define several other languages), numerous standardization initiatives resulted in the creation of many overlapping standards such as MDDL, FIX, FinXML, VRXML, RIXML, XBRL, FpML, IFX, TWIST, RosettaNet, OAGi and ACORD. This has led to a waste of resources through duplication of efforts and a high cost of change. Today we have complex, multi-standard XML-based interfaces which have made the architecture landscape complex and rigid for financial institutions. There are multiple point-to-point connections with data being mapped directly between one application to another. The process, routing and rules logic are developed to specific standards which have made change costly, unscalable and difficult to maintain. It has been difficult to adopt the latest technology services to improve business processes and offer new product features.

ISO20022 aims to decouple the point-to-point connections by enabling each standards’ message to be converted to an ISO 20022 standard which all other messaging standards can understand and process.

ISO20022 thus provides a way to rationalize the messaging standard landscape. However, dissecting the as-is architecture state - with multiple point to point connections, systems, data models, bespoke processing rules and logic - could be an uphill task. The scale of impact, especially in payments, in adopting ISO, is huge as it impacts most of the players and systems across the payments value chain. Further, the organizational inertia of avoiding business interruption for payments is also substantial. Capco has recently started to lead a multi-year payment transformation program for one of the UK’s Big 4 banks to transition the bank’s payment infrastructure to ISO20022 standards. We supported the bank to establish a target architecture state and implement foundational solution components that helped our client to offer real-time domestic interbank payments to their customers, using ISO20022 messages. These foundational solution components that we delivered have further enabled the bank to extend the ISO20022 adoption in their organization into offering real-time payments for other geographies and payment types. Based on this firsthand experience, we have numerous lessons learned and careful considerations about how the existing payments architecture landscape of banks can be evolved towards adopting ISO20022 standards. In principle, we advocate that a bank’s long-term objective should be for one single standard approach used by all systems. However, in the interim, several standards would need to coexist to respond efficiently to competitive pressures and regulatory demands. We believe the following six solution considerations will ensure banks looking to adopt ISO20022 standards for payments to achieve the long term ‘convergence’ towards a single ISO20022 standard, and at the same time also facilitate short-term ‘coexistence’ of several standards to provide a workable series of transition architectures.

The six recommendations:

1. Expose payment functions as internal APIs − Thereby promoting payments business capability reuse across the bank internally.

• Identify and expose the payment functions (such as payment initiation, payments validation and payments cancellation) as standalone APIs to consume ISO20022 payloads. Ensure the APIs which need rules and data states such as ‘validation’ are developed using micro-service architecture. • Ensure the APIs are compatible with old as well as new versions of ISO20022 messages for effortless adoption by front end channels, following a graceful upgrade approach.
• Ensure the APIs are reused for all payment types such as low value batch and high value payments across different geographies.
• Connect the external client facing APIs (such as Open Banking APIs) with these internal APIs to drive synergies.

2. Manage payment processing centrally − Have a central orchestration layer and rules engine to process all payments to ensure payment processing logic is not duplicated.

• Ensure payment processing steps are orchestrated as business process models which are modular and reusable The business process layer utilizes the APIs wherever possible to process the payments.
• Ensure channels do not determine the payment route (scheme/country). Most legacy channels currently have logic to determine the payment route. Make channels agnostic of payment route by refactoring the payment routing logic, if any, and use an orchestration layer to determine the payment route. This will make channels light weight.
• Ensure orchestration has intelligence to re-route the payment if the main payment rail is not available due to any reason. This improves resilience and end customer experience.
• Central processing should be used for all payment types across all geographies.

3. Take care of your rich iso payments data − Centrally store rich ISO20022 payments data which can be analyzed later to generate insights and unlock revenue generating opportunities. ISO20022 provides a rich data set and ability to carry more data. It has enhanced data model with new logical groupings via nested elements and additional new, dedicated and mandatory elements. For example, it provides granular data for each party in the payment chain and additional elements to identify intermediary parties in a payment.

We advocate storing rich ISO20022 payments data centrally, preferably in a cloud environment, as the payment progresses from channel through to the payment schemes. Hosting in the cloud will provide flexibility to scale based on your needs and enable you to use the off-the-shelf analytical tools available from cloud vendors.

• Analysis of the data can generate valuable insights to drive development of new payments products and features.
• Ensure an event driven architecture pattern, instead of point to point integration, is used to transfer the ISO20022 payments data at each processing step. The event driven architecture will enable you to retain historical ordering and context and use asynchronous messaging, which is more robust to heavy traffic or interruption, eventually becoming consistent with less likelihood of needing intervention

4. Enable STP by warehouseing payments centrally − Warehouse the payment separately in a central data store while orchestrating so that stalled payments can be automatically resolved and replayed to improve the STP rate.

Payments with future value date or bulk payments that need to be throttled to enable real-time processing can be managed better by warehousing the payment centrally in a separate data store. Further, if there is any issue while processing a payment, for example if any intermediatory processing service such as sanctions service is not available, then warehousing would enable replaying and retrying the payment again later instead of re-initiation.

The rich and granular data of ISO enables banks to decide on when a payment needs to be warehoused and enables banks to manage and replay stalled payment without the need of reinitiation thereby helping bank to improve their STP rates.

5. Develop central translators − Centrally translate data between the different messaging standards to avoid point to point integrations.

Today, payment processors use a number of financial messaging standards. Due to the disparate standards, data for cross-border payment processing is transformed and translated many times across the payments value chain. This makes the payment data susceptible to misinterpretation and very often needs manual intervention to prevent delay in processing.

ISO20022 provides a single message standard which acts as a central model and reduces the translation effort needed between the different financial messaging standards. With ISO20022, each standard would only need to translate to the master to ensure integration with any other standard.

For payments transformations, ensure that translators from MT to MX and between different ISO versions, of same message type, are exposed as stand-alone APIs that can be centrally used across the payments infrastructure to promote reuse and avoid duplication of efforts.

6. Improve the customer experience − Refactor channels to migrate any bespoke message validation and routing related logic to internal APIs. This will lean out processing logic in the channel and provide better performance, leading to better customer experience. 

To benefit from ISO, a bank’s customer involvement is a musthave requirement. The rich ISO structure provides the ability for channels to pass more granular remitter and beneficiary details and receive accurate and elaborative error details on payment processing. This is a great opportunity for channels to refactor their design to adapt to ISO20022 and provide better customer experience through improved data quality and data accessibility.

The diagram in the blog shows an example of target state that can be achieved by following the six recommendations.

Banks have been struggling to decommission and prepare their existing infrastructure for transition. In March 2020, SWIFT delayed the migration for cross border payments and cash reporting by a year to give more time to banks to manage their infrastructure change. This has given an opportunity to banks to rethink and validate their transformation strategy. Each of the recommendations discussed above, can help banks struggling to transform their infrastructure, to validate and enhance their payment infrastructure architecture target state effectively. By following these six recommendations, banks can de-risk their progress and save the cost of change and realize the benefits much quicker than anticipated.

It is critical not to implement all the recommendations at once, and for all the payments types and geographies. A scoped and gradual transformation approach with well-designed transition architectures will reduce the impact and risks to regulatory compliance or reporting needs, and delivery risks. If you are in initial stages of transformation, we propose transforming domestic inward payment types first and building APIs for business functions as the first solution components to start the journey. Later, design and implement central orchestration layers and rules engines. The refactoring of channels and generating insights from ISO20022 data should be handled in the final transition steps.

- Jaspreet Puri, Principal, Capco