Will the implementation of CBDCs be built on blockchain or on legacy mechanisms?

I’ve believed for a while Central Bank Digital Currencies (CBDC) are inevitable – even more so after reading The future monetary system in BIS’ recent Annual Economic Report 2022. But, how will the transition work? How on earth do we achieve interoperability between legacy and next-generation platforms? 

The ongoing global ISO 20022 migration is showing us the challenge of switching to a new messaging format. Switching from traditional ledgers that record balances (baked into the core of legacy banks) to shared blockchain ledgers where digital assets ‘exist’ in cyberspace…that’s a whole new ball game! 

So, I was intrigued by a report that SWIFT and CapGemini are collaborating to develop a gateway between CBDCs and existing payment networks, following a trial last year that successfully demonstrated cross-border payments between these two worlds. As the Chief Innovation Officer of SWIFT, Thomas Zschach, explained, interoperability is not just vital for realising the full potential of these technologies but also avoids the very real risk of market fragmentation (I’ve blogged before about the perils of closed-loop solutions). 

But, but, but, I hear you say, surely ISO 20022 is solving the problem of interoperability? To quote the JPMorgan POWER+ report, “With the emergence of ISO 20022 as a global and open standard for payment messaging, for the first time we will have a common language in which to transact with anyone, anywhere.” 

The challenge is that in the context of digital assets, interoperability is so much more than a messaging problem. 

Let’s dig into this a little deeper:  

In the past financial institutions sent messages to each other and updated their ledgers based on these instructions. To keep things accurate, elaborate reconciliation processes kept the ledgers aligned. I am using the past tense here, but this is in fact the reality of today. 

Across the globe, Back Offices perform these tedious checks and balances day in and day out, making sure no coins have slipped down the back of the proverbial couch (constant vigilance is required to combat human error, systems error and fraud).

Of course, the messages between financial institutions are no longer carried under physical lock and key by clerks and couriers, nor Telex (although the term TT is still in common use in parts of the world), but instead rely on secure electronic messaging services that use cryptographic locks and keys. Enter SWIFT, the doyen of financial messaging – the OG! SWIFT’s tried, tested and trusted secure messaging gateway links the banks of the world together. But, SWIFT only delivers the messages, they don’t actually do any settlement. Contrary to popular misconception, no money moves across their network. Sure, it moves BECAUSE of their network, but updating the ledgers (the actual movement of funds) is the role of regulated banks and central banks.  

Now comes the fun bit – blockchains don’t work like this! 

Blockchains (a type of distributed ledger) are a common ledger shared among all participants. When transactions are completed on the blockchain (each participant has a node of the ledger they update directly), no messages need to be sent from A to B, nor is any reconciliation required – the blockchain itself automates and validates all of the ledger entries and maintains its own integrity through a consensus mechanism. 

There is no need for tedious reconciliation processes, no need for back offices to verify balances with their counterparts at another bank, no need to investigate where a payment might be trapped. In fact, the entire audit trail of every single action on the ledger is recorded and can be directly verified by any participant. But, let’s come back to the key point here – THERE ARE NO MESSAGES! 

Ok, so that’s fine if you are all working on the same blockchain, but what if you want to transact with another blockchain? Well, this is actually the same challenge as we have with cross-border transactions in two currencies (I’ve said before SEPA is cheating, they do cross-border transactions in a single currency…too simple!). Two parties (one on each network) need to agree and coordinate an exchange with each other on each network.  

(There are a number of ways to link distributed ledgers together, in this one a bank has a node on each ledger) 

Blockchains enable atomic transactions. This means everything happens within a single transaction – it either completes or it doesn’t – nobody is left out of pocket as a result of settlement risk being realised. When bridging blockchain networks (or bridging to a legacy payment network), a mechanism is needed that delivers an equivalent outcome. Typically, a mechanism such as a Hashed Timelock Contract or Agreement (Interledger: Hashed-Timelock Agreements [HTLAs]) is used to co-ordinate settlement across two different settlement platforms (blockchain or otherwise).  

We can think of this as a ‘two-phase commit’– essentially earmarking or reservation followed by confirmation once all parties are aligned to complete the actual settlement. Mojaloop has this concept built-in thanks to their use of the Interledger Protocol, a mechanism for facilitating the exchange of value between different networks of ledgers. We know The Clearing House (TCH), EURO Banking Association (EBA) and SWIFT are using this exact mechanism for IXB; after all, it is built into most instant payment systems as best practice these days. 

Getting back to SWIFT, what is interesting for me is they are already the incumbent connectivity providers for many Real-Time Gross Settlement (RTGS) platforms globally. It makes sense to try and capitalise on this through the transition to CBDCs. But, they provide a messaging gateway, not a blockchain node – conceptually there is a massive difference.  

I always imagined that banks would join CBDC networks by hosting a node (or two) of the CBDC blockchain, providing them direct access to the central bank ledger. This makes sense in so many ways:  

• resilience of a distributed ledger (the network will continue to run even if the central bank or a cluster of bank nodes go offline, although there must be some constraints in place to protect or guarantee byzantine fault tolerance);  
• 24/7 access to a perfect replica of the ledger (and a way to verify that the network is healthy too); and, 
• the ability to have multiple ledgers across multiple data centres (any of the ledgers can be used and updated, with the network maintaining its integrity automatically, one of the beauties of the technology), among other strengths.  

It would worry me if a 3rd party replaced that node and provided a gateway to distributed ledger node instead. That defeats the purpose and adds an unnecessary intermediary. While it would reduce the upfront complexity – banks can leave the heavy lifting to SWIFT and continue to use the legacy mechanisms already in place for interacting with existing RTGS platforms – it could mean that SWIFT would actually be transacting on the network, not the bank.  

It is the job of the banks to update the ledgers – even if those ledgers are shared. This is not a job that can be outsourced to a third party, even one as trusted as SWIFT.  

Or, would SWIFT instead provide a trusted messaging bridge between CBDC and legacy RTGS networks? Perhaps enabling atomic settlement between the disparate networks of the legacy and distributed ledger world? Yes, perhaps this is more appropriate.  

But, but, but…this is exactly the same as using translation services for ISO 20022! It leaves the banks running on legacy platforms and not actually embracing the new world order. This traps them in the old world and slows the transition to next-generation technologies.  

However, perhaps SWIFT is the only player with sufficient gravity to create a wormhole that can bridge these two worlds…the one who can introduce the Next Generation of CBDCs? To boldly take us where no payment ledgers have gone before…