ISO 20022 Data Model Holds the Key to CBDC Interoperability

Over 100 countries, representing almost all global GDP,^[1] are at some stage of evaluating or designing an everyday-use, or retail, central bank digital currency (CBDC). In the wholesale space, proofs-of-concept and prototypes have sprung up for DLT-based cross-border PvP^[2] and DvP applications,^[3] and have matured into demonstrations involving real money^[4] and real regulators.^[5] However, there is little insight into the data model^[6] and associated messaging underlying these tests.

The lack of an explicit data model thus far is understandable. An ad-hoc data structure is fine for sandbox testing, where the information is sparse, and the limited number of implicated players all know what to expect. In the real world though, those chains will be longer, with more stops and less insight along the way. This is doubly true where CBDC systems — both retail and wholesale — will be expected to interoperate with existing payment rails and cross-border arrangements.

The Interoperability Imperative

Interoperability has been identified as a “core feature” for retail CBDCs.^[7] Broadly, interoperability may be defined as “...technical, semantic and business compatibility that enables a system to be used in conjunction with other systems.”^[8] In more concrete terms, “interoperability allows PSPs from different CBDC systems to make payments across systems without participating in multiple systems.”^[9]

These definitions may benefit from some delamination. Interoperability may occur “horizontally”^[10] over multiple stops on its end-to-end journey along a given payment rail. An example might be a closed-loop CBDC payment between users, intermediated by PSPs. Alternatively, it may be “vertical,” or “cross-system,” where a payment begins or ends its journey as, say a CBDC, but hops rails mid-journey to morph into commercial bank or e-money and arrives at the end destination with data intact.

Figure 1. A simplified generic view of interoperability illustrating a payment initiated as a CBDC and delivered into a deposit account via an Instant Payment System (IPS). Interoperability may be horizontal or vertical in nature. Horizontal interoperability results in payments and remittances information being successfully propagated along a given payments rail from sender to receiver Vertical interoperability occurs when the payment and remittance information “hop” rails and arrive at the end destination with all relevant data intact.

Cross-System Interoperability

Cross-system interoperability is illustrated by essential CBDC use cases: a user loads a CBDC wallet from a bank account or cash; a consumer pays a merchant from a CBDC wallet using a POS card reader. Online and bill payments are also prominent consumer-to-business (C2B) examples; in the reverse flow, an employer pays a salary from a bank account to a CBDC wallet, or government similarly disburses targeted emergency relief funds.

The most prominent use case, however, is the cross-border one where the bulk of design thinking is taking place. The Bank for International Settlements (BIS) suggests that interoperability can be supported by three broad arrangements:^[11]

• “Compatibility”: common standards, alignment of technical infrastructures, rulebooks and interfaces, etc.;
• “Interlinking”: shared technical interfaces or common clearing mechanisms, corridors, and atomic cross-platform transactions to reduce risk and facilitate FX;^[12]
• “Integration”: a common platform, using a common governance and technical system.^[13]

Figure 2. BIS models for cross-border interoperability.
Source “Options for access to and interoperability of CBDCs for cross-border payments” Report to the G20.

Compatibility is a base requirement for interoperability and applies equally to the domestic case. At the core of compatibility is the data model and, subsequently, message alignment. Accordingly, the G20-approved roadmap^[14] for enhancing cross-border payments, developed by the FSB and CPMI,^[15] features “data and market practices” as one of five focus areas, with its central building block focusing on “adopting a harmonized ISO 20022 version” and “harmonizing API protocols.” Other roadmap focus areas identify “the interaction between data frameworks” and “interlinking payment systems” as critical building blocks supporting alignment of regulation and existing infrastructures.

The ISO 20022 Data Model

The high-value payment infrastructures of the world are finally migrating to messages developed using the ISO 20022 standard recipe.^[16] Industry-powered “base” messages^[17] created under the standard have been developed for the totality of the payments chain (see Figure 1). Along the way, the messages support queries, exception handling and hiving-off of pertinent information for regulatory and compliance authorities.

Figure 3. Key ISO 20022 messages across the payment chain.
Source “ISO 20022 for Payments and Cash Management: A Business Perspective” courseware.

These base message definitions yield the data model to support a comprehensive range of transactions across different use cases. And the annual revision cycle and strict version adherence means that the messages can evolve to meet needs not covered in the existing data model, including the novel challenges that will accompany transacting with a CBDC.^[18]

The base message definitions are just a starting point though: the messages can be tweaked and boiled down to serve specific use cases like cross-border payments,^[19] high-value settlement,^[20] or real-time payments.^[21] These market practice usage guidelines can be tailored for implementation on payment infrastructures like the SWIFT system^[22] or domestic high-value payment systems, such as the EU Target2^[23] or US FedWire^[24] systems.

International Standardization and the CBDC Data Model

The danger in moving too far with CBDC policy and design decisions without incorporating a global data model, is that CBDC messaging evolves in a way that is incompatible with cross-system straight-through-processing (STP). In a world of converging models and practices, this could be a fatal blow to implementation and adoption by end users as hiccups, extra steps, and delays become increasingly intolerable.

But can existing international standardization processes, like ISO 20022, handle the unique requirements of a CBDC? Work has begun to consider this question, as evidenced below.

Bank of Japan

Notably, the Bank of Japan (BoJ) has delved into the applicability of the broad ISO standardization process to CBDC design.^[25] Their report suggests that the nature of financial transaction messaging,^[26] which can be developed at the level of the business model, logical components (message model), or physical syntax, is robust to the challenge of incorporating CBDC business processes. This can be accommodated through its existing logic and change management/ version control, as well as the ability to represent data in formats that accord with APIs^[27] and varying ledger architectures.^[28] The report also details widely accepted ISO identifiers^[29] for entities and transaction information that are aligned with ISO 20022 metadata. This accords with CPMI harmonization work exploring the use of structured and limited-code elements for natural persons, legal entities, and financial institutions.^[30]

ISO/TC68 — Financial Services

The ISO financial services technical committee has also weighed in on the role of ISO 20022 messaging for a retail CBDC, reasserting that “the suite of ISO 20022 standard financial messages for payments and card transactions is very comprehensive,”^[31] and that “there is the ability for additional messages to be created, if required, using the ISO 20022 development and governance processes, to support any specific needs for CBDCs.” Indeed, this committee has formed an advisory group of experts to explore the role of ISO financial messaging standards in digital currencies.^[32]

It should be noted that a key cross-system use case for CBDCs involves interoperability with card-based payments, which use ISO 8583-based messages. In this vein, the committee suggests that if “...CBDCs and commercial bank money are both used in card messages a further review of the ISO 8583 standard in relation to the ISO 4217 standard [currencies] would be required.”^[33] As an example of this potential interoperability, Visa has proposed a “CBDC Payments Module” that interacts with a blockchain-based CBDC initiated through card infrastructure.^[34]

G20 Roadmap

The G20 roadmap^[35] also provides a setting for CBDC design and ISO 20022-based messaging to come together in service of better cross-border payments. A recent update^[36] to progress on the CBDC building block^[37] acknowledges that “insufficient technical standardisation in areas such as message formats, data elements, cryptographic algorithms and numbering and coding systems would cause frictions and inefficiencies when attempting to achieve interoperability.”^[38] However, there is not much specificity about the process to align these messages.

Conversely, block 14 of the G20 roadmap does focus on message harmonization, but not specifically as it pertains to CBDC. A recent update concludes that “many of the inefficiencies that the financial industry and its end users face with cross-border payments are caused by interoperability issues that arise because of misaligned message flows and incompatible data models along the end-to-end payment chain.”^[39] The roadmap progress report commits that “the joint task force will publish its harmonisation guidelines for broader industry consultation at end-2022. Once a final version of the guidelines is published in 2023, their adoption will require a whole community effort that will potentially span several years.”^[40]

Closing the Gap

This “whole community” effort must include central banks and other prominent thinkers in the CBDC space if the new currency is to achieve cross-system interoperability — both domestically and internationally.

This effort can manifest at various levels in the international standardization process. In the international space, the message harmonization work coming out of the roadmap is an obvious first step. Other initiatives, such as SWIFT’s efforts to “connect digital [CBDC] islands”^[41] are important and also harness ISO 20022-based messaging for connector gateways but don’t specify the underlying CBDC data model used by participants.

Most importantly though, closer participation by CBDC designers in international standardization processes like ISO 20022 and its cross-border harmonization,^[42] other market practice and implementation efforts,^[43] and perhaps even the establishment of a CBDC ISO 20022 market practice group will be critical to achieving the data models that engender interoperability.

While CBDC systems need not use ISO 20022 messages – indeed other standards and payload representations (e.g., JSON) may be required for API access — they should at least adhere to the underlying data model to improve cross-system interoperability and meet user expectations.

Conclusion

The achievement of policy aims associated with a CBDC will require adoption by end users. The user value proposition relies in large part on frictionless satisfaction of key payments use cases. The associated CBDC transactions necessitate interoperability along — and most crucially between — payment rails. Harmonization of data models, via international standardization efforts, is a necessary underpinning of effective interoperability.

References