Simon Scorer
What type of technology would you use if you wanted to create a central bank digital currency (CBDC) i.e. a national currency denominated, electronic, liability of the central bank? It is often assumed that blockchain, or distributed ledger technology (DLT), would be required; but although this could have some benefits (as well as challenges), it may not be necessary. It could be sensible to approach this issue the same way you would any IT systems development problem – starting with an analysis of requirements, before thinking about the solution that best meets these.
The subject of CBDC also raises a number of significant economic questions, but the focus of this post is primarily on the technological considerations. For the purpose of this post, I consider a universally accessible CBDC which is widely used by individuals as well as businesses – this forces the consideration of some challenging technological features. A CBDC which is used by individuals (i.e. a retail CBDC) could also be used by financial institutions and institutional investors (i.e. wholesale), but for these requirements I will focus predominantly on the retail aspects. The requirements I outline are technology agnostic; they should enable the consideration of both centralised and DLT-based solutions to a CBDC.
The table below summarises some of the likely technology requirements for a CBDC. These are discussed in greater detail below.
Resilience
Like current financial infrastructure, a widely used CBDC would likely be considered critical national infrastructure. Any unexpected downtime could have a major impact on the functioning of the financial system and on the real economy. It would need to be operational across the country, 24 hours a day, 365 days a year. This would require extraordinary levels of resilience. A minimum operational availability of 99.999% might not be unreasonable for the core settlement engine – equating to a downtime of approximately 5 minutes during a year.
Some aspects of the wider system may have lower resilience requirements, especially if users are able to switch between multiple service providers. But the central bank might still choose to set minimum standards for these providers.
Security
Security considerations would also be paramount. As highlighted by the increasing frequency, impact and reach of cyber-attacks, a CBDC would need to be secured against attack. It would need to be designed to protect against any unauthorised access to, and alteration of, data, as well as disruption to operation (e.g. DDoS attacks).
The threats faced by a CBDC could be much greater than the threats faced by private digital currencies like Bitcoin. Potential attackers may have different motivations (including simply disrupting or undermining confidence in the system) as well as greater capabilities and resources (potentially including state-sponsored attacks).
Scalability
We could estimate a top end requirement for the volume of transactions and the number of users by considering what would happen if every payment currently made via a bank account in the UK instead goes via CBDC, even if this scenario is highly unlikely.
Figures from Payments UK show around 700 electronic transactions per second. This rises to 1,200 if you also include cash and cheques. However, these figures are based on annual volumes being spread evenly throughout each day. Transactions during peak times will be significantly higher. A reasonable estimate of a peak figure may be in the region of several thousand transactions per second.
The current UK population is estimated at 65.6 million, and there are an estimated 5.5 million private sector businesses, implying a maximum figure of 71.1 million users.
Whilst this maximum scenario is unlikely, it’s also possible that the required figures could be much higher. For example, each user might hold multiple accounts (there are currently around 75.5 million active personal and business current accounts in the UK); a CBDC might be used internationally; or it’s possible that a CBDC might generate new areas of demand for payments – e.g. for payments between internet-of-things devices or for micropayments.
Transaction processing
In order to be useful for retail payments, CBDC transactions will need to be confirmed near-instantaneously and it will be vital that settlement finality is established.
Many existing UK payment systems employ a two stage deferred net settlement process. Payments are initially made in commercial bank money, often between different banks; this creates net obligations between these banks, which are settled in central bank money at a later point in time (i.e. settlement is deferred). Features such as the netting of payments can have particular liquidity saving benefits in systems where participants make multiple offsetting payments between each other in a short space of time (e.g. payments between banks).
However, payments in CBDC would, by definition, be in central bank money from the outset, and the flow of payments between individuals and businesses are unlikely to have sufficient offsetting payments to benefit from liquidity saving tools (although there may still be some benefits if a CBDC is also used for wholesale applications). Instead, the underlying transactions in CBDC would likely be real-time gross settled.
Confidentiality
New technologies could inspire questions around the appropriate level of privacy or transparency in the financial system. I don’t attempt to tackle these questions here. Instead I assume that something similar to existing levels of financial privacy would be needed: the system must be private (i.e. transaction details are only visible to the counterparties of that transaction, except perhaps in the case of infrastructure operators) but not anonymous (i.e. participants must be identifiable and relatable to real-world identities, to enable applicable regulations, e.g. Anti-Money Laundering and Know Your Customer).
Depending on the legal environment, certain authorities (e.g. law enforcement etc.) might also require the ability to view the transactions of particular parties under the appropriate circumstances.
Interoperability
A CBDC would need to coexist with the current financial system, as well as potentially with multiple other national CBDCs. Synchronisation of payments between these systems would be desirable to ensure that the final transfer of CBDC only occurs if the final transfer of an asset in the corresponding system also occurs (i.e. Delivery versus Payment or Payment versus Payment), although this is not a common feature in today’s retail payment systems. This functionality could, for example, enable greatly simplified and faster cross-border payments between various national CBDCs.
Innovation
A CBDC could act as an enabler of further innovation – I’ve already briefly mentioned internet-of-things, micropayments and cross-border payments. Other possible areas of innovation relate to the potential programmability of payments; for instance, it might be possible to automate some tax payments (e.g. when buying a coffee, the net amount could be paid directly to the coffee shop, with a 20% VAT payment routed directly to HMRC), or parents may be able to set limits on their children’s spending or restrict them to trusted stores or websites.
These innovations would not necessarily need to be embedded in the underlying settlement engine, but instead could be enabled by overlay layers. This would enable a CBDC and private innovation to coexist. The technology used to implement a CBDC would therefore need the functionality and flexibility to enable this overlaying of innovative features.
Future proofing
A CBDC would need to be fit for purpose for a long period of time. The external environment would not remain static during this time – the demands and threats it faces would evolve, impacting all of the above aspects of a system. A CBDC would need to be able to adapt to a changing environment.
For example, it might need the ability to alter the processing capacity in response to changes in demand. The cyber-security landscape is also likely to continue to develop rapidly – techniques that are secure today may become compromised in future, for example if quantum computing became practical reality. The ability to continually upgrade and enhance the security attributes of any system would be vital.
Further research
It’s unlikely that all of the above attributes could be perfectly met with today’s technology; you may need to make compromises between features – e.g. the trade-off between resilience and privacy discussed in my previous post. Deciding on your tolerance for various trade-offs could be vital in deciding on the ideal solution.
CBDC is far from just a simple question of technology; any central bank contemplating CBDC will need to answer a host of fundamental economic questions, as well as considering how feasible it is to achieve all the required features and what type of technology might enable this. Whilst it’s easy to write down a set of requirements, a great deal of further research is required before making CBDC a reality.
Simon Scorer works in the Bank’s Digital Currencies Division.
If you want to get in touch, please email us at bankunderground@bankofengland.co.uk or leave a comment below.
Comments will only appear once approved by a moderator, and are only published where a full name is supplied.
Bank Underground is a blog for Bank of England staff to share views that challenge – or support – prevailing policy orthodoxies. The views expressed here are those of the authors, and are not necessarily those of the Bank of England, or its policy committees.
The absence of more or less detailed models of how a system incorporating a cbdc might work make this an unsatisfactory discussion.
For instance, what might the system look like if banks could continue to create ‘new’ £, as they do now, by making loans to clients via cbdc?
Or you could just run it on top of bitcoin’s network?
While in may not be necessary to use a block chain it’s certainly true it’s proving to be a very secure technology. Actually that’s not true, it’s the block chain in combination with a token (such as bitcoin), a protocol and proof of work that makes it secure. I believe banks could issue true digital cash implemented on top of bitcoin (or ethereum).
I don’t know enough (yet) about bitcoin to describe such a system but here’s how it might work if banks ‘stored’ bitcoin (btc) itself.
The bank would issue you a btc address (= account) in which you deposit btc. It’d be a two signature address, you’re given one of the keys[1]. To withdraw bct to your phone say, you send a signed transaction (tx) to the bank, who add their signature and transmit the now completed tx to the btc newtwork. The btc miners do the rest and the btc move from the address in your bank to the address on your phone. Any one can pay into your btc bank address, which you can make public with out worry.
I think it worth noting that the bank does not need permission to run such a system, they can just do it. The transmissions of the partial and completed txs are secure[2]. An audit trail of all txs associated with the account is readily available on the block chain.
I very much doubt a private (permissioned) system can better that, in fact not even match it. At least for security[3]. It may be slow at present but that issue is being dealt with. Bitcoin is evolving and is in competition with other species, of which there are circa 1,000 (one being its own offspring!).
[1] Txs are signed using the key.
[2] Anyone can have a copy as they are (cryptographically) tamper proof, tampering invalidates the tx.
[3] bitcoin’s proven track record is about 6 years (if we ignore the early years where it was not really the subject of attacks).