Marten Nelson of M10 shares key insights gained from the development of a retail CBDC as a participant in Project Sela.
In our previous instalment, Richard Turrin, Author of ‘Cashless’, revealed the true potential of e-CNY that goes beyond retail payments and insights into ways of breaking the dollar monopoly on oil trade. Over the next two days, we will continue our CBDC series by sharing insights and lessons from CBDC pilots. We'll also explore additional technical options beyond what has already been tested, including the concept of cryptobanknotes.
Project Sela is a retail CBDC project led by the BIS Innovation Hub and supported by the Hong Kong Monetary Authority and the Bank of Israel. FIS and M10 Networks built the technical Proof of Concept (POC) with assistance from legal experts at Clifford Chance and IT security experts from Check Point.
The project wanted to answer the following questions: How can a CBDC system balance innovation, accessibility, and cybersecurity, and how can a CBDC system retain the desirable attributes of cash with today's digital payment experience?
First, let's define retail CBDC (rCBDC). Central banks today issue two types of money: physical cash (coins and notes), used by individuals and businesses, and reserves, used by financial institutions. Both types of money are liabilities of the central bank. Physical cash is considered legal tender. Somewhat simplified, legal tender means that the government has declared by law the money to be acceptable as payment. A retail CBDC is a digital form of money with the same legal status as physical cash that individuals and businesses use. Examples include payments between individuals, an individual paying a merchant, or a government payout. There is also the notion of wholesale CBDC (wCBDC), designed for use in payments between financial institutions, but this was outside the scope of the Sela project.
The Sela project introduced a new intermediary called Access Enabler to increase access to CBDC. The Access Enabler provides customer-facing services such as KYC and transaction screening (AML/CTF) but must never hold customer funds on its balance sheet. To determine who ‘holds’ customer funds, we applied the UNIDROIT principles' test of control. In Sela’s context, that translates into having control over the cryptographic private key (private key for short), holding the CBDC account and executing transfers and transactions, or taking responsibility for CBDCs under a custodial arrangement. As Access Enablers in the Sela architecture do not have access to end users’ private keys or their CBDC account other than to view balances and endorse payment instructions, we consider that Access Enablers would not legally hold CBDC for end users.
Possible Access Enablers include current Payment Service Providers (PSPs), fintechs, grocery store chains, etc. As the Access Enabler never holds customer funds, we expect lighter regulatory requirements for this new type of intermediary. The lighter regulatory requirements should lower the barrier to entry for Access Enablers and result in a rich CBDC ecosystem.
End-users have a CBDC wallet on their mobile device that securely stores the user's private key. The user's private key digitally signs requests before sending a payment or account balance request to the CBDC platform via an Access Enabler. Digital signatures serve as the method for authentication and authorisation.
We looked at several models for how to provide end-users with conversion between deposits (or physical cash) and CBDC. To facilitate conversion 24x7, we chose a pre-funded model where an end-user bank holds CBDC and acts as the rCBDC distributor upon customer requests.
The goals of the technical POC were to
Maximise access by lowering the barriers of entry for intermediaries,
Minimise cybersecurity threats by preventative software design,
Preserve the desirable attributes of cash, and
Capture the benefits of payment digitalisation.
We started with a design phase involving the legal, policy, and security stakeholders. The design phase was critical. As the old saying goes, ‘garbage in, garbage out’. Translated to the development of the Sela POC, it meant that a proper design phase would lead to a high-quality build. Consequently, we iterated on several designs with the help of the stakeholders, who accepted some ideas and rejected others. At the end of the design phase, we had a ‘blueprint’ to guide us through the build phase.
The technical solution for supporting a secure CBDC ecosystem powered with broad access through Access Enablers was to:
Restrict direct access to the CBDC system to approved parties (banks and Access Enablers).
Only accept fund transfer initiation requests from the account holder submitted via Access Enablers.
Have Access Enablers endorse customer requests before passing them on to the CBDC system.
Using a permissioned system, only approved parties could connect directly to the CBDC system. An onboarding process is required to become an ‘approved’ party. The authorised party would generate a key pair and upload the public key to the CBDC platform as part of the onboarding process. The connection between the CBDC system and the approved parties is secured using mutual TLS (mTLS), which is a type of authentication in which the two parties in a connection authenticate each other using the TLS protocol. The use of mTLS protects against unauthorised access and impersonation attacks.
Only the CBDC account holder can transfer funds from her account to another account. The account holder digitally signs transfer requests using her private key, stored securely on their mobile device. The CBDC system verifies the account holder's digital signature using the account holder's public key.
End-users send their fund transfer requests to Access Enablers, who perform their obligations according to the CBDC scheme rules (e.g. transaction screening). Before forwarding the transfer request to the CBDC system, an Access Enabler endorses the customer request by co-signing it using its private key.
Now, it was time to build. The build phase constituted a series of 2-week sprints where we performed three fundamental tasks:
Configure and deploy the M10 digital money platform for retail CBDC.
Build new software as a ‘reference architecture’ to address the new requirements for the new intermediary, Access Enablers. One example was a component that removed the complexity for Access Enablers to manage their private keys.
Last, we built emulators to simulate an entire retail CBDC ecosystem. For example, we created emulators for an RTGS system to simulate the loading of CBDC by banks and an ATM to facilitate the conversion of CBDC and cash.
An interesting aspect of Sela is that it allows users to have a single CBDC account and multiple Access Enablers. This model creates a competitive landscape with multiple Access Enablers. It also adds resilience to the CBDC ecosystem — should one Access Enabler fail, the user can easily switch to another.
While retail and wholesale CBDC projects accelerate worldwide, stablecoins are exiting the opaque world of decentralisation as they become regulated (e.g. MiCA in the EU), and bank deposits, which already live in a heavily regulatory world, are going the tokenisation route. Can stablecoins and tokenised deposits benefit from the work done for Sela? I think so. Stablecoins and tokenised deposits could also use intermediaries that perform customer-facing functions without taking possession of customer funds. Like for a CBDC ecosystem, Access Enablers could become a key driver for the proliferation of stablecoins and tokenised deposits. In fact, Access Enablers could serve as intermediaries for all three digital money types — simultaneously.
Besides validating the feasibility of balancing innovation, accessibility, and cybersecurity in a retail CBDC system and retaining cash's desirable attributes with today's digital payment experience, a key learning from this project was the value of engaging participants from multiple disciplines through all project phases. It helped us identify potential issues early in the cycle and address them before painting ourselves into a corner.
Don't miss our upcoming instalments in the CBDC series, where we will expand on these concepts and delve deeper into the technicalities of these experiments and learnings.
About Marten Nelson
Before starting M10, Marten co-founded Token, the industry leader in API platform solutions for banks and developers and served as its CMO. He is a member of ITUs Global Digital Currency Initiative, and was a member of the Federal Reserves Faster Payments Task Force.
Every day we send out a free e-mail with the most important headlines of the last 24 hours.
Subscribe now