Designing the IT Solution Architecture

for a Central Bank Digital Currency

(CBDC)

In recent times, we have been witnessing well overdue transformational change and
increased digitization within the payments space. With the growing interest in private
sector digital currencies and their growing acceptance, combined with the reduction
in everyday use of physical cash in parts of the world, this has opened a wealth of
new opportunities and risks for central banks and financial institutions across the
globe. As recently stated in an AWS publication, we have seen over 85 countries,
representing nearly 90% of the global GDP researching the possibility of
launching their own retail Central Bank Digital Currency (otherwise known as a
'CBDC') [1]. However, as central banks begin to critically evaluate the benefits and
limitations to developing a CBDC, it has been documented that they are all
considering different approaches and designs, either individually or in conjunction
with other countries or international institutions (i.e. BIS) to address the variety of
localized needs, use cases and scenarios of each respective country.

It has been cited by global policy-makers that CBDCs have the potential to serve as
either a complement to or replacement for each of the different existing and
emerging payment instruments: cash, deposits, stablecoins, etc. Central banks will
need to determine where they would want their adoption to be focused, based on
either a limited number of specific use cases or widespread to bring about more
significant transformation to their jurisdiction. The desired role of a CBDC may evolve
with policy objectives but starting with a clear unifying goal and vision will help align
with other monetary policy decisions.

The future decision undertaken by policy-makers to implement CBDCs must also be

informed and facilitated through careful consideration of the associated risks. Many
different types of risks can emerge with the implementation of a CBDC system and
so the technical solution design for a CBDC is critical.
These include individual risks such as the loss of privacy and difficulty of use,
operational risks such as operational failure, data breaches, or novel cyber-
attacks; and financial system risks like credit disintermediation (as discussed in
one of my previous articles), amongst others [1]. A more extensive discussion of
these potential risks is available across existing CBDC based literature but in this
article, we will aim to examine the high-level solution architecture considerations to
the design of a potential future CBDC.

Introduction

As previously discussed, let's quickly take stock of what a CBDC is and what types of
models we are seeing either researched or developed to-date. A CBDC is a new form
of digitized sovereign currency, which is stated to be equal to physical cash or
reserves held at the central bank. In laymen terms, CBDC can be viewed as the
electronic form of central bank money that citizens can use to make digital
payments and store value. What makes it different to e-money is that it is central
bank money, or a component of the monetary base and a direct liability of the
central bank. Currently, central bank money is composed of physical cash (coins
and bills) and reserves held at the central bank by financial institutions with access
to the central bank’s deposit facility. Hence, a CBDC would constitute a third form of
central bank money (see diagram 1 below).

As of today, we understand that the general public holds central bank money in the
form of physical cash (coins and bills). For countries attempting to move towards
CBDC adoption, there are two primary methods of adoption, either through retail or
wholesale CBDCs. A retail CBDC (also called “general-purpose” CBDC), would
constitute the first digitised form of central bank money and liability the general
public could own. With a retail CBDC, in principle the public could have accounts of
the digitised fiat currency within the central bank, or hold CBDC on mobile devices,
prepaid cards or other forms of digital wallets. While the central bank issues and
manages retail CBDC (through ecosystem participants, such as commercial banks
and payment service providers - PSPs), they could be involved in the CBDC
monetary system through either a one or two-tiered structure, facilitated by the
offering of interoperable payments and services.

In a single-tier model, CBDC transactions would resemble transactions with the

private banking sector, except accounts would be held with the central bank whereas
in a two-tier model, this would require the central bank to assume an active role in
distribution and payment services that may exceed the scope of its current role and
mandate.

Alternatively, Wholesale CBDC could also be issued by central banks to commercial

banks and potentially other financial institutions for the purposes of being used for
interbank payments and security-based transactions. These institutions could hold
wholesale CBDC accounts with the central bank, akin to the reserve accounts they
keep today (it could be argued that wholesale CBDC already exists today in many
countries in the form of reserves) [2]. The wholesale CBDC is seen as the most
popular proposal amongst central banks currently examining CBDCs due to the
potential benefits it offers to the existing wholesale financial systems, making it
faster, inexpensive, and safer. The Bank of International Settlements (BIS) also
shares the view that wholesale CBDC could potentially benefit the payments and
settlements systems.

A visual representation of the two key model types for CBDCs is illustrated below
(diagram 2), demonstrating the relevant issuance mechanisms (one-tier vs two-tier).

Compared to emerging economies, central banks in advanced economies are not

overly optimistic or enthusiastic about retail CBDCs and this should not be a surprise.
This reason behind is that central banks do not wish to create competition between
central bank money and private sector money, taking into account the limited
potential benefits from using retail CBDC and the risks of disintermediating the
banking industry. Nevertheless, we should not discount the potential value that retail
CBDCs offer to citizens and the remainder of this article focuses on the technological
design of retail CBDCs in mind.

Key Design Decisions for a CBDC

As central banks pursue further research into the solution based technical
implementation of their CBDC, there are a number of technical design decisions that
will need to be factored in to determine and shape the high-level architecture of the
system. These no doubt lead and arise to a number of questions which can only be
addressed by taking a clear view of the problems that a central bank is trying to
solve. It is essential to consider the type of tool it seeks to build to address its
individual use case. The establishment and setting of a clear vision are indeed a
critical step in dictating the technical and operational parameters within which a
CBDC must operate.

After the end-state 'To Be' CBDC design is fully defined, realised and achieved by
policy-makers, the next evolution in the digital journey should be to identify and
investigate the most appropriate technology stack to deliver the CBDC. As
highlighted by the World Economic Forum (WEF) report on their Policy Toolkit
(January, 2020), it would be prudent and valuable to wait until as late in the process
as possible to identify the target technology solution, suspending preconceived
notions in order to allow for more flexibility and informed technology decisions,
something in which we've seen the US do compared to other nations such as China
[2]. It is cited that any CBDC issuance and design can be seen as a largely
technology-agnostic decision. It is important for policy-makers to conduct their
own research to fully evaluate technology solutions and providers, and they should
be wary of simply selecting a convenient technology solution without the
appropriate due-diligence.

This evidently leads to the key question, "what infrastructure might the different
CBDC architectures require for the central bank, and how could they be
implemented in the most resilient way?" This decision could be represented as the
second tier of the CBDC pyramid, which would follow immediately after the decision
on the IT architecture because the infrastructure requirements for the central bank
differ substantially across the three architectures. The CBDC IT infrastructure could be
based on a conventional centrally controlled database, or on a novel distributed
ledger using Blockchain technology. Diagram 3 below demonstrates how elements
of DLT could play a role in CBDC. The first DLT-related design choice hinges on
whether the authority to update the database is centralised or delegated to a
network of identified and vetted validators (see diagram below).
Indirect vs Direct IT Model Architecture for a CBDC

If we examine the indirect nature of a CBDC model, it would loosely follow and
imply loads similar to those seen in today’s banking system. By contrast, the direct
model for a CBDC would require massive technological capabilities, as the central
bank processes all transactions by itself, handling a volume of payments traffic
comparable with that of today’s credit or debit card operators [3]. There is a third
option which is the hybrid CBDC. This CBDC based architecture is more complex to
operate than the indirect model because here the central bank does maintain retail
balances which isn't what central banks are known to traditionally manage and
operate. Nevertheless, it could be potentially implemented at scale using today’s ever
evolving technology and with a relatively modest infrastructure.

As highlighted in recent BIS study (BIS Quarterly Review, March 2020), conventional
and DLT-based infrastructures often store data multiple times and in physically
separate locations [3]. The main difference between both of the infrastructure
designs lies in how data is updated. In conventional databases, resilience is typically
achieved by storing data over multiple physical nodes, which are controlled by
one authoritative entity – the top node of a hierarchy. By contrast, in many DLT-
based systems, the ledger is jointly managed by different entities in a
decentralised manner and without such a top node. Consequently, each update of
the ledger has to be harmonised between the nodes of all entities (often using
algorithms known as “consensus mechanisms”). This typically involves broadcasting
messages and then awaiting replies on multiple messages before the transaction can
be added to the ledger with finality (the moment at which funds transferred from
one account to another, officially become the legal property of the receiving party).
The IT overheads needed to operate and manage a consensus mechanism is the
main reason why DLTs have lower transaction throughput than conventional
architectures [3]. Specifically, these limits imply that current DLT could not be used
for the direct CBDC except in very small jurisdictions, given the probable volume of
data throughput. However, DLT based infrastructure could be potentially leveraged
for the indirect CBDC architecture, as the number of transactions in many wholesale
payment systems is comparable with that handled by existing blockchain platforms,
as also demonstrated in several wholesale CBDC projects (as discussed by Bech,
Hancock, Rice and Wadsworth in their paper on the Future of Securities Settlement
(2020)). Enterprise versions of DLT might also be feasible for the hybrid CBDC
based architecture but the existing research efforts on this area is still in its infancy
stages [4].

When it comes to achieving resilience, neither a DLT-based system nor a

conventional one has a clear-cut advantage. The vulnerabilities are simply different.
The key vulnerability of a conventional architecture is the failure of the top node, for
example via a targeted hacking attack. The key vulnerability of DLT is the consensus
mechanism, which may be put under pressure, for example, by a denial-of-service
(DDoS) type of attack.

Designing a Blockchain (DLT) Based CBDC IT Architecture

With blockchain and DLT based solutions that are currently being examined for
CBDC prototypes to manage ledgers, we have witnessed varying levels of
decentralisation. Most projects to-date have so far have chosen private,
permissioned iterations of open-source and public blockchain technology to
furnish pilots. Consensys stated in their technical CBDC paper (2020) that Blockchain
technology can be used by central banks to support both types of CBDC (retail
and wholesale). For example, DLTs could be leveraged as an alternative approach to
existing wholesale central bank systems, which includes either real-time gross
settlement systems such as CHAPS, Target 2, Fedwire, or deferred net settlement
systems like BACS, EURO1, TIPS, ACH. Also, it could potentially be used to create
platforms for the distribution and issuance for retail CBDCs on a far broader scale,
and offer a true government-backed electronic cash-base system.

In particular, Corda, Fabric, and Quorum have successfully proven that blockchain is
a formidable technology for the development of CBDCs, at least as a prototype.
More recently, we have seen next-generation public networks being developed and
utilized for high profile CBDC projects, including the Banque de France’s Digital
Euro program, built on Tezos, and the Marshall Islands’ pioneering their
sovereign currency, built on Algorand [5], to name but a few.

While neither blockchain technology nor a decentralised architecture is a prerequisite

a fully working and functional CBDC infrastructure, either can potentially provide
noteworthy benefits in creating greater trust through permissionless access and
distributed, peer-to-peer systems [5]. Having said that, we may see certain bank
opting to roll out what is essentially a digital version of cash with a structure that
mirrors the current financial models seen to date, with innovation hopefully trending
towards digital currencies that interoperate with other currencies and financial
systems. In any such event, a CBDC’s degree of interoperability will be a key value
proposition of the asset for policy-makers.

Key expertise in the infrastructural components of multiple blockchains is critical for

any successful CBDC development as the ability to interoperate with different chains
is becoming more of a requirement for the successful implementation of a CBDC. In
addition, we need to explore how different protocols will need to interact with each
other which can help put light to the different aspects of how the diverse players in
traditional financial infrastructure plays a role which turn become interoperable
within a CBDC network.

Whilst we have observed many central banks expressing some degree of interest in
DLT-based approaches (for both wholesale and retail use cases), most of the current
experiments or pilots conducted to date have focused on primarily on the wholesale
model. Existing projects include Project Ubin (Monetary Authority of Singapore),
Project Khokha (South African Reserve Bank), China’s DC/EB, and Project Stella
(joint research project by the ECB and the Bank of Japan).

The creation of any CBDC which promotes seamless and efficient transfers between
citizens can be viewed by regulators a means for establishing new market
standards, encouraging financial institutions operating in the retail space a new
way forward to improve their value proposition to consumers. Such
improvements could include potentially longer operating hours (24/7), richer data in
payment messages and greater transparency on the processing status for payments,
higher interoperability between different platforms and finally further development
of programmable money (which is one if key value propositions to adopting
blockchain technology).

It is still relatively early to make a judgement on whether DLT can be used for the
Retail CBDC use-case but with future innovation in this space, I am confident that it
can offer more depth for this solution design discussion in the future.

CBDC Design Principles

Any CBDC project should be encapsulated by thorough high-level design principles.

A CBDC design requires trade-offs, as all objectives may not be fully achievable with
a given technical solution and CBDCs may need to compete with other solutions in
the market. Clear and well thought through design principles can guide policy-
makers on such trade-offs and avoid the need to go back on early initial decisions.
Key design principles could potentially include the approach to privacy and
individual protections, mechanisms to manage CBDC adoption, and the division
of roles and responsibilities between the public and private sector.

As we have witnessed, many central banks are attempting to build on their

experience in managing payment infrastructures like real-time gross settlement
(RTGS) and fast payment systems, which will address and manage CBDC system
which entails increasing transaction volumes and a step-change in the proximity to
the retail users of financial services. The latter will require building a new retail
payment scheme. With this, a new set of rules and standards for the execution of
payment transactions will likely include rules around management of
chargebacks, litigation, and guarantee issuance for merchants [1]. Building such
an architecture is critical to generate the necessary trust between payers and payees
and to enable merchant payment use cases. The participation and orchestration in
developing a new retail payment scheme requires capabilities and skills that have not
typically been required by central banks int he past and it is likely true regardless of
whether the central bank is leading, coordinating, participating in, or supervising
such a scheme.

Furthermore, dependent on the technology chosen for the CBDC platform, policy-
markets will need to develop new forms of technical expertise (SME), particularly
given the great magnitude of consequences linked to economic activity, financial
stability and public trust in event of system failure. Such concerns could be partially
addressed by outsourcing or partnering with technology providers to support the
delivery of a CBDC solution, which has been seen across the globe in central banking
projects related to CBDCs. However, managing new third-party vendors and partners
may still require increasing technical capacity and should be appropriately vetted
and evaluated to determine the appropriate selection of the vendor.

There are a number of different design choices for a CBDC instrument and for the
underlying CBDC system [6]. These choices all have some bearing on one another
and thus making a coherent set of choices will be essential for smoothly functioning
and working system.

The BIS recently stated in their foundational principles and core features report
(2020), the impact of design choices is a complex challenge. Whilst CBDC research
remains a young field with limited pilot examples or testing at scale, it will be crucial
to examine how a system could work, which includes understanding the respective
roles of both the private and public sector.

Key policy makers will need to strive to better understand technology design choices.
As previously mentioned in this article, existing literature to date has discussed
choices around ledger technology (distributed ledger technology (DLT) versus
conventional databases) and their associated data structure (which either captures
individual CBDC units or maintains a combined balance for an individual’s account).
The architecture and design choices (for example, roles and information flow
between participants) can be more sensitive to policy decisions and require
specification early in the design process.

The design of a CBDC technical solution needs to be flexible enough to

accommodate unclear or changing policy objectives as well as produce sufficiently
optimized results which can be difficult [1]. However, if such policy makers can build
degrees of flexibility into their architectural CBDC design then it can be said it will
help enable experimentation and iteration.

Defining the Role of the Private Sector for CBDC design

Based on the above diagram which is taken from the AWS CBDC study with Oliver
Wyman [1], there are four primary roles that can be examined when it comes to
CBDC management. CBDC system management can be defined by how the core
ledger and processing infrastructure is run. At a very minimum the private sector,
acting as distributors, can play a role in connecting citizens to the CBDC network by
providing gateway access. However, if a more expansive role is desired, CBDC
distributors may also operate parts of the CBDC infrastructure, by processing
transactions (for example, validating those transactions are correct, posting
transactions, and producing the necessary messaging) or by storing relevant data.

The next item on the role list is CBDC account management. This can be defined as
the creation of end-user accounts and the processing of corresponding transactions.
Such policy- makers may want end users to have a CBDC distributor (potentially
through a third party) playing an expansive role in deliver which would include
managing access, authenticating the identity of users, and possibly even processing
granular-level transactions so the CBDC system only has to process distributor-level
transactions. Also, policy-makers may wish to minimize reliance on such
intermediaries and promote mechanisms for individuals to access the infrastructure
more directly (for example, through a non-custodial wallet). In such cases, the private
sector could still play a critical role in authenticating identity and performing know-
your-customer (KYC) checks as part of CBDC account creation process for end users,
if desired by central banks.

The third item is related to CBDC-based payment services which would include
additional customer-facing services that include user interfaces (mobile applications),
value-added functionality, merchant services, payment gateways, customer support
services and potentially other forms of programmability. These are not services that a
central bank currently undertakes or is involved with will be unlikely to consider
delivering itself but are critical to a country’s payment system. Distributors can play a
large role in end-user services. However, non-distributors may also be active in the
space by leveraging system access provided by a distributor. Policy makers should
work to ensure that non distributor access to the system has low barriers of entry.
This can then incentivize actors in these areas to adapt their services to support the
delivery of the CBDC and to encourage the evolution of a competitive and innovative
market.

Finally, we have CBDC governance which defines the processes by which policy-
makers undertake decisions over the structure, capabilities, and technical features of
a CBDC system. Policy-makers will need to consider not only what role the private
sector plays in the functions above but what role they play in how those functions
evolve over time. Central banks cannot assume the private sector will want to serve in
the role of distributor. Hence, it is critical that the central bank provides clarity
around expected investment costs, risks, and potential business models of this key
role which is an area that a lot of work is currently being explored by central banking
institutions. Such types of incentives that might be appealing are also likely to evolve
over time, which requires considering viable business models at time of launch and
at future points. Developing hypotheses and scenarios for how these business
models may evolve over time can support continued engagement and participation
of the private sector.

Designing the Privacy Approach

Financial privacy for transactions is individuals which is key debate when it comes to
CBDC design and privacy protection consistently ranked in public surveys as one of
the top priorities for payment systems [7]. At the most basic level, a payment system
can attempt to provide anonymity for its users by identifying them using
pseudonyms rather than persistent identifiers and such undertaking for CBDC is
crucial and central to its final design.
As stated in a recently published SUERF paper (2021) on "how to issue a privacy-
preserving CBDC", data relating to payments can be particularly revealing, and a
CBDC could potentially provide a great deal of data on citizens, making them
vulnerable to malicious use for political or commercial purposes. We thus believe
that a successful CBDC would need to provide credible transaction protections in
order to gain broad public acceptance. Moreover, privacy is not just an individual
value, it also has a social value. Privacy is essential for a free society and democracy.

However, privacy is a multifaceted concept and it cannot simply be addressed by

binary decision. Citizens are typically sensitive not just to what information is shared
and collected, but also with whom it is shared and for what purpose. While privacy
relates to the ability of individuals to control what, when, and with whom
personal information is shared, anonymity relates to the ability to not have
one’s identity captured. Cash is anonymous as it doesn’t require individuals to
prove or even provide their identity to make use of it, and individuals in some
jurisdictions may have strong preferences for maintaining that anonymity in digital
payment systems. The future design of CBDC must encompass the characteristics of
anonymity to truly be absorbed within mainstream society.

The potential privacy aspects for CBDCs must be designed to answer questions such
as “who should have this data and when?”, under which circumstances?”, “who
should verify or sign off on changes to this data?” and “what evidence must be
furnished to determine whether a proposed update is valid?” All are significant
questions that need to be well thought through. Central banks will need to make
careful decisions about user privacy in any CBDC system, factoring in a number of
different dimensions, starting with whether the identities of transaction participants
remain anonymous. Different participants in the system may be granted different
levels of visibility into user information, such as CBDC distributors, payment
services providers (PSPs), and central banks themselves. Policy-makers must also
need to establish the conditions under which public entities can access both
data and metadata from the CBDC system (for example law enforcement or national
security investigations), and how such data can and may be shared within the private
sector.

To achieve the optimal design for privacy, policy-makers will need to rely on a
multitude of modern technology, including cryptographic techniques that can
mask identity, and data governance policies, such as regulations that access and
limit usage. Such implementation of said technology can help reduce the probability
that the desired privacy approach is undermined by institutions violating regulations,
or by a change in political direction. Also, such implementation through government-
based policy can provide greater flexibility to adapt to changing societal expectations
and desires.
Furthermore, more advanced technological features to address privacy can include
transaction tear-offs where transactions are structured in a way that allows them to
be digitally signed without disclosing the transaction’s contents, key randomisation
where parties linked to a transaction are identified only by their public keys, and
fresh key pairs are generated for each transaction which leads to an onlooker not
being able to identify which parties were involved in a given transaction, and state
reissuance where when a new transaction is created, input states are included in the
proposed transaction by reference. These input state references link transactions
together over time, forming a transaction backchain. Long transaction backchains
are undesirable as resolution along the chain slows down performance. As well as all
backchain transactions are shared with the new owner [8].

Individual Protections and Rights

It's not just privacy that is crucial to evaluate. A retail CBDC has the potential to
impact individuals in many ways beyond privacy. Other considerations may include
how to ensure additional individual protection and rights. How these are to be
considered can vary across jurisdictions as will the approaches and philosophies used
in securing them, whether that involves policy, law, the market, or a combination of
mechanisms and some of these will have a greater influence on technology design:
the ready access of data collected about individuals, and redress in case of
mistakes through lost authentication, fraud, and systemic IT failures [1].

Beyond privacy, some jurisdictions may also want to provide individuals with access
to their own data as well as the ability to easily port their data and switch providers.
Some policy makers may want to provide even further means of individual
autonomy and provide individuals with the ability to interact directly with the CBDC
system through distributor managed software. Another important protection is
ensuring individuals have access to their claim over the central bank should a
distributor have an insolvency event or attack. Operational resilience will have to
meet or exceed current payment system standards.

Policy-makers will be able to undertake different approaches on how to secure

individual rights and services. One option could be to limit the role and
responsibility of the CBDC system to the payment rails and leave individual rights
to be secured through a combination of consumer standards and market
competition. Alternatively, another option could be to take on a more expansive
role in providing value-added services. In such circumstances the central bank
could build, or coordinate the creation of, a full payment scheme along with the
CBDC payment rail.
Technical Policy Design Trade-offs

Based on the above illustrative policy trade-off diagram, there are a number of trade-
offs that policy-makers will need to consider when discussing the above decision
points.

Depending on the current and future central bank capacity and the desired level of
public-private partnership, policy-makers can design a CBDC system to have more or
less centralised control over the core system. In this scenario, such policy-makers can
have full control over the regulatory environment. The key question here is the
extent to which there is distributed control over transaction processing and
storage of core ledger data. It can be argued that the control of the CBDC network
can be reserved entirely for the central bank or decentralised to incorporate a large
number of trusted private-sector entities. Incorporating fully centralised control
could limit the need to negotiate with a collection of governing entities, which would
afford central bank identities more control over system design and potentially
speeding decision-making.

What role the private sector will play will ultimately depend in part on existing
institutions and their relative levels of maturity We have seen that with central
bank in countries which are less developed financially may opt for more centralized
control, while the central bank of a country with a diversity of firms ready and
engaged in the payment system may opt for a more distributed model.

When it comes to individual control versus distributor control, policy-makers may

wish to decide on a system where individuals bear more of the responsibility and
risks related to CBDC delivery, or one where more responsibility is borne by
distributors. This decision will ultimately be shaped by the policy makers attitude to
individual rights, privacy, and the role agreed upon with the private sector. It is
important to note that individual protections and rights need to be carefully
aligned with the role of the private sector. On the one hand, policy makers may
envision individual protections being guaranteed through distributors. For example,
the system could be designed to have distributors manage individual data and
provide recourse in case of user errors, such as lost access to their CBDC wallet.
Alternatively, a country may view individual rights and innovation driven by providing
more autonomy, choice, and responsibility to individuals. Although, distributor roles
may somewhat narrower in this scenario, allowing more varied services to emerge in
the broader market based.

Finally, we come to the trade-off related to anonymity versus centrally, identity-

based services. We previously discussed that privacy is a concept multifaceted in
nature. Policy-makers may have differing and diverse goals in providing anonymity
to individuals, allowing the central bank or the private sector to provide identity-
based services, and designing services to reduce potentially illicit activities. From a
solution perspective, these trade-offs will be reflected in choices about how identity
is managed by the CBDC system.

Developing the Technology Stack

Conceptualizing how the technical layers of a CBDC will need to be designed and
structured is no simple feat. Firstly, the technology stack can be viewed as the set
of hardware and software tools/frameworks leveraged to provide the complete
set of functionalities needed for an application or system. There are many ways
to represent the layers of a CBDC technology stack, which will inevitably differ across
implementations which is evident based on the work undertaken to date by central
banks across the globe. In this section, we attempt to generalize this stack into four
distinct layers, which serve to represent functionality that would exist in both DLT
and conventional database architectures.

Incidentally, the BIS in their latest publication (2022) on Project Dunbar (international
settlements using multi-CBDCs) had a slightly different outlook on the CBDC
technology architecture, citing four key areas including Application Architecture,
Data Architecture, Infrastructure and Security [8]. It can be argued that these
areas loosely follow the layers below, with the network layer covering both the
infrastructure and security areas, with transactions being seen as something which
flows through the entire end-to-end technology stack.
The network layer controls the mechanism through which participants in the CBDC
system will be discovered, validated, and have information propagated to them. A
well-functioning network layer can be supported through high-speed network
connections, such as a cloud network’s internal backbone. Redundancy in these
connections also supports a resilient system across participants. As cited in the BIS
paper for Project Dunbar, if a DLT based solution was to be leveraged using say for
example the Corda network, it would be structured as a peer-to-peer network,
comprising of nodes. Each node represents a legal entity, and each runs the Corda
software which is an instance of Corda and one or more Corda applications
(otherwise known as CorDapps). All communication between nodes is point-to-
point and encrypted using transport layer security (TLS). This would imply that all
data is shared on 'a need-to-know basis'. Virtual machines would be leveraged to run
network identities running this software, with the use of messaging queues through
TLS encryption.

Other technical considerations for the network will also include network services
which identify the nodes involved in the transaction, identity manager services
acting as a gatekeeper to the network, signing services which would acts as the
bridge between the main network map and identity manager services, and the public
key infrastructure (PKI) and hardware security module (HSM) infrastructure.
Finally, a network cluster would provide uniqueness through a consensus by
attestation for a given transaction, has not already signed other transactions that
consume any of the proposed transaction’s input states. This would prevent the issue
of 'double spend' [8].

The transaction layer defines the CBDC data and transaction structure. This layer’s
design depends on choices made about how transactions are to be processed and
approved. Basic transaction posting and advanced payments logic can be supported
at this level to support multiple transaction types and validation structures.
Event-driven architectures can support scalable transaction processing and are
designed to optimize the per transaction cost structure.

The data layer defines what and how much transaction data is stored, current
global state, and system event logging. This layer’s design depends on choices
made around data management, access, and storage. High availability datastores
with synchronous data replication will underpin data storage for both centralized and
decentralized architectures. Additional data access controls will also support data
privacy. Going back to the Project Dunbar publication released by the BIS, CorDapps
(Corda distributed applications) would sit at this layer, which are distributed
applications that run on the Corda platform, and the Corda vault, which acts like a
database to store on-ledger shared facts for a node.

The final layer is the application layer, where end-user functionality and business
logic can be implemented. This logic, whether built into or built on the core CBDC
stack, can be implemented through cloud native or containerized solutions.
Additionally, the interface to distributor software can be supported through private
links or an API gateway. Such design configuration options presented in this
section will impact functionality within each of these layers, with policy-guided
system management design decisions impacting how differing participants operate
in each individual layer.

Decentralised applications (dApps) could be ultimately leveraged in this layer to

allow users to interact with the solution. Decentralized applications (dApps) are
digital applications or programs that exist and run on a blockchain or peer-to-peer
(P2P) network of computers instead of a single computer. dApps which are often
built on the Ethereum platform can be developed for a variety of purposes and in
this case, for CBDC. Some additional functionalities, including issuance, transfer and
redemption of CBDCs, as well as balance enquiry can be made available using OOTB
(out-of-the-box) functionality.

Finally, Digital wallets are software applications (dApps) through which users would
be able to interact with the CBDC system and would sit at the application layer. A
digital wallet typically allows users to view their balance in one or more accounts,
make payments, receive currency or digital assets from other users and sometimes to
trade assets or execute other financial transactions. The design and functionality of
digital wallets are crucial not only for usability but also for security (users do not like
to lose their money) and for privacy.

System Design Configuration

Beyond the architecture-based options previously discussed earlier in this article,

which highlights the potential role of participants and transaction flows, and beyond
core technology selections such as ledger type, a CBDC system’s design
configuration deploys the desired interrelationship between a CBDC system’s critical
functions and roles. The CBDC system design configuration will be pivotal in
fundamentally shaping how the system operates and thus its ability to support
different policy objectives. System management, wallet account management and
identity management will be key technological decisions that can be thought of as
levers that may move CBDC solution across the previously aforementioned policy
trade-offs.

System management defines how the core ledger and processing infrastructure is
run. This moves along a spectrum from highly distributed control of the CBDC system
across a set of distributors to highly centralized control of the system by the central
bank. Additionally, transaction processing would be a core function of the CBDC
solution for processing of transactions would cover the validation and transaction
logic. Data storage would also be a key component under system management
where central banks will need to set policies governing access to both transaction
data and transaction metadata.

Wallet and account management defines how end-user accounts are created and
how end users interact with their funds. This moves along a spectrum from high
individual control of personal funds to high reliance on a distributor for control of
those funds. Wallet and account types can be determined by leveraging three
separate design decisions, based on the responsibilities of distributors in the delivery
of CBDCs. But who bears responsibility for fund custody is a crucial design criterion. If
it is custodial based then a third party holds all information necessary to sign and
submit a transaction on behalf of the user, thus assuming custody over these assets
on behalf of the user. If it is non-custodial then an individual would hold all
information necessary to sign and submit a transaction on their own.

Another aspect to consider is whether the transactions need to be processed at the

distributor level or both the individual and distributor level. This is crucial as it could
be held at the individual level where every user has their CBDC holdings recorded
directly on the core CBDC ledger. If it's at the distributor account level then individual
users would access the CBDC system exclusively through a selected distributor, with
the core CBDC ledger recording only the total CBDC holdings of each distributor.
Transactions at the individual level are processed by distributors, either locally within
a distributor system or as part of a dedicated retail system.

Identity management defines what information about individuals is collected and

made available, and to whom. This relates to the level of privacy and moves along a
spectrum from high individual privacy to high provision of centralized identity-based
services. The relationship of individual identities to a CBDC system can be separated
into three broad categories, anonymous where the individual is not known to the
central bank and it would be challenging to identify true identities, pseudonymous
where the individual’s true identity is not directly recorded in the system, but an
identifier unique to each individual is linked to each of their transactions, or known
where the individual’s identity is known to the central bank and/or distributor, and is
linked to any accounts they own or transactions they perform.

Core Ledger Technology

The foundation to any CBDC would be a digital record of all of the transactions that
have taken place in a system. Such a record is often referred to as a digital ledger
and can be viewed abstractly as a digital bulletin board where all transactions are
posted [9]. The transactions in the ledger cumulatively determine the account
balances in the system. In the context of a retail CBDC, it would assign account
balances to individual users, necessitating a regime for account management as
discussed earlier, with a supporting notion of identity concepts.

One of the key goals for any CBDC would be to track the balance of its users,
allowing each to transact only his/her coins. This coin cannot be a simple file, and a
transaction cannot be the transmission of the file from one user to another. If it was
done this way, the sender could keep his/her copy and thus keep the coin whilst also
sending it. Existing global currency systems maintain a global state, comprising
the balances of all users. This includes everything from banks' per-client balance
tables. Updates to these states are called transactions, simple transfers of funds or
interactions (which in the DLT world are facilitated through smart contracts). If DLT
were to be adopted by central banks, they would be typically aggregated into so-
called blocks, each containing many transactions and the blocks are linked to form a
chain, hence the terminology ‘blockchain’.

There is a spectrum of decentralization designs, from bank balance tables, through

semi-centralized systems like Ripple [10] and Libra [11], to cryptocurrencies, and
there are clear trade-offs to be considered when designing a CBDC. The rise of
cryptocurrencies since 2009 incited rapid advancement across this spectrum which is
why we have recently seen an increased frezy in CBDC work by policy-makers.

To avoid any vulnerability to a crash or misbehavior to the system, the blocks and
state should be replicated, i.e. stored and processed concurrently by multiple
machines. The challenge here is to thus orchestrate these machines, despite
network latencies and arbitrary misbehavior by a subset of them. Even in a
centralised architecture-based setting, there are hardware failures so it is prudent to
IT system design to incorporate multiple nodes for fault tolerance.

For countries seeking a centralized governance model or that prefer technology

proven to meet the needs of large-scale payment systems, conventional database
systems may be most appropriate. Benefits attributed to DLT architectures, such as
cryptographically verifiable append-only ledgers and high levels of
programmability throughout the tech stack, can often be achieved with centralized
solutions. However, the centralized nature of the system may cause concern
regarding control of end user and transaction data.

In addition, a commonly cited requirement in current white papers for future CBDC
systems is the ability to perform offline transactions. The reasons behind this are
many, including the need provide resiliency in the case of lost network connectivity
and the enabling access to funds in case of natural disaster and in areas of poor
electrical or internet connectivity, which are critical to financial inclusion goals. Policy-
makers will need to bear in mind a set of high-level considerations regarding the
system design and challenges of offline transactions. A primary concern with
regards to offline payments is security. Online transactions are validated in real-
time to ensure and support funds are not spent more than once (double spend
problem) and that the funds themselves were in fact issued by the central bank. In an
offline setting, validation is dependent on a number of technological components
including the hardware and software of the devices which are used to complete the
transaction (this can include dedicated electronic devices, smart phones or
smartcards). A highly secure design to mitigate compromise of these devices is
paramount to any CBDC design.

The primary options [9] for policy makers for core ledger design includes the
following:

1. Centralised Ledgers
2. Centralised but Verifiable Ledgers
3. Semi-centralised Ledgers
4. Decentralised Ledgers with Central Bank Monetary Control

Centralised Ledgers: The most conventional and straightforward approach to

implementing a CBDC core ledger infrastructure is in a centralised manner. For
resilience the system should still be distributed (a computing environment in which
various components are spread across multiple computers on a network), replicating
the state among multiple servers. With centralised or semi-centralized ledger
designs, a small number of servers is usually sufficient. This small number is relatively
easy to coordinate and achieves good performance, as the machines can quickly
propagate messages among each other.

However, in a fully-centralised design in which the choice of nodes and their

operation are all under direct control of one authority (such as the central bank
itself), that authority – or a malicious insider – can potentially change the rules at
will, roll back system state or rewrite history, and censor or delay transactions.
Servers that behave arbitrarily for whatever reason such as by being hacked or under
control of a compromised insider can violate not only a ledger’s availability but also
its integrity.

It is important to understand that mere replication does not protect a ledger’s

integrity against arbitrary Byzantine failures such as hacking or insider attacks.
Even in a widely-replicated ledger, a single compromised server behaving maliciously
might be able to rewrite history illegally, “print money” without detection, or trick a
targeted victim into thinking a transaction has been committed while everyone else
sees a conflicting transaction, or no transaction, on the ledger.

Centralised but Verifiable Ledgers: Even in a centralized setting, there are still ways
to limit the trust that clients need to place in the servers maintaining the ledger. In
particular, authenticated data structures (ADSs) provide a method by which a
server, in possession of some data, can prove things about that data to a client who
does not necessarily trust the server to give accurate answers.

For example, a citizen receiving money in a CBDC may want to ensure that the
transaction in which they are being paid has gone through before providing any
goods or service; i.e., they want to check for the inclusion of this transaction in the
ledger. Rather than having the server simply tell the client if the transaction is
included or not, in an ADS the server also provides cryptographic proof of inclusion
that the client can verify. The main guarantee of an ADS is that it should be
impossible for a server to provide valid proof for a response that does not accurately
reflect the data it has stored.

To satisfy this requirement, clients must have some commitment to the data stored
by the server, which the clients can then check the proof against. This commitment
acts as a cryptographic fingerprint of the state of the entire dataset at a given
point in time and is updated as the data changes; crucially, while it covers the entire
dataset its size is a small constant that is independent of the size of the dataset.

Semi-centralised Ledgers: To reduce centralization, the CBDC can instead be

operated by a larger set of independent parties chosen or approved by the central
bank. Superficially, the solution is similar to the centralized approach – instead of
directly operating the different nodes, the central bank chooses the entities that run
them. In practice, however, this approach is quite different, as the central bank
forgoes total control of the system.

With dozens or even hundreds of independent operators and adequate technical

protection against Byzantine faults in the state machine replication scheme, no single
party or group of parties (below a certain size) can change the rules, perform
censorship or roll back the system state. Nevertheless, since the operators are all
chosen by the central bank, that central bank can facilitate an agreement of all
parties to perform arbitrary changes. This allows the operators to comply with
regulatory and legal requirements, as well as revert illegal operations due to attacks.
Indeed, the central bank can deploy complex governance mechanisms, where
different subsets of the operators can force a decision or exert veto power.

The basic design considerations of protocols for semi-centralized systems are similar
to the centralized case. Indeed, the distributed systems literature puts them in the
same category, implementing a replicated state machine by a set of predefined
nodes. However, the large number of nodes make classical solutions problematic –
the amount of communication they require is typically quadratic in the number of
nodes, making them prohibitively slow among many independent parties.

Decentralised Ledgers with Central Bank Monetary Control:

The most decentralized approach available is to use a blockchain infrastructure

similar to that of cryptocurrencies. Unlike those cryptocurrencies, the CBDC is under
centralized monetary control, but anyone can join and operate the system. This
approach is called permissionless, as operators do not need permission from the
central bank to join. Although the system operators can still change the system rules
(known in Cryptocurrency as a fork), in a permissionless system a fork requires a wide
agreement among independent parties. This makes controversial changes unlikely,
but also takes away control of the central bank.

On the positive side, decentralized blockchains demonstrate unprecedented

robustness – Bitcoin has been running continuously without interruption [12] for
over a decade. A decentralized implementation also prevents monetary controls and
transaction censorship – the open membership implies that the different operators
are not subject to the decision of any central entity. This is a desirable property of an
instrument that strives to replace physical cash.

However, this decentralization also implies no central control even when it is

necessary, e.g., no reversal of transactions in case of mistakes, and no prevention of
operator misbehavior like front-running [13]. The setup would therefore have to
include means aimed directly at these scenarios, which are active areas of research.

Finally, it is not immediately clear how to implement the decentralized approach in

the context of a CBDC. To ensure the security of such an open system, incentives are
used. System operators, often called miners as in Bitcoin, should receive rewards to
incentivize them to follow the desired protocol. Unlike cryptocurrencies, here the
central bank determines the inflation rate, and the rewards for the miners. Although
it does not choose the miners in the open system, the central bank in this setup is
still uniquely powerful, as it determines the reward rules.

Programmable Money Architecture

There is growing interest in the potential application of programmability which has
been cited as of the key innovations being brought under CBDC as it would offer
myriad uses. Motivations among stakeholders are varied, but its introduction would
offer benefits on a large scale. CBDCs may not only be trackable, they may also be
viewed as programmable. For example, in the event of a natural disaster a
government could send citizens digital money that could be spent on food and
medicine, but not alcohol. This means that governments will have a greater ability to
decide who has access to digital money.

In one example, central banks could program digital currency with logic so it can be
spent only for a designated purpose. For large companies at the helm of complex
supply chains, programmable currency promises the instantaneous delivery of
payment upon product receipt. A CBDC could bring a plethora of economic benefits
including automated payments, such as paying toll road usage; automated
checking of money laundering; automated collection of taxes; and distribution
of consumer support in emergencies [16].

As Alexander Lee of the Federal Reserve recently wrote, the term “programmable
money” remains ill-defined. Lee differentiates between “programmable money” and
“programmability” [16]. He notes that there are two natural components of the
definition: 1) a “digital form of money” and 2) “programmability” which is a
“mechanism for specifying the automated behavior of that money through a
computer program.” There is little new about programmability per se, as Lee notes
“given that various combinations of similar technology for payments automation
have existed for decades.”

Many state-of-the-art digital assets feature a smart contract programming

language [9]. This is a way that independent third-party independent developers
can extend the digital asset with new functionality. It is not necessary for a CBDC to
provide smart contracts in order to fulfill its primary role as a digital currency, and
some CBDCs (including the digital yuan, for example) are unlikely to do so [14].
However, smart contracts can be an important way that a CBDC fosters innovation
from other entities such as commercial banks and fintech providers. Some would
argue that CBDCs will cancel out the need for cryptocurrencies like bitcoin. After all,
how many different digital currencies are really required or necessary? It is my view
that the opposite is true. The rise of CBDCs highlights the importance of
decentralized cryptocurrencies that are relatively private and not controlled by any
government [15].

Before considering how “programmability” applies to CBDC, it is worth considering

one of the many examples of how the concept is used today. For example, provided
that such a procedure was arranged beforehand, when a payment exceeding the
available account balance is made, a bank may make the payment but place the
difference in an “overdraft account,” then create a charge for exceeding the balance,
and initiate a process to charge interest for the “loan” as long as the overdraft
persists [16]. All of this is done automatically by a computer program specifically
developed for this purpose by the bank.

It is also worth noting that each part of this process highlighted above is covered by
a formal legal contract signed (sometimes electronically) between the customer and
the bank; by formal codes of conduct adopted by the banking industry; by national
consumer legislation; and importantly, by laws relating to dispute resolution, where if
the bank is at fault, the actions will be reversed (and where necessary restitution is
made). In its original definition, this has been labeled a “smart contract” or a
combination of automated and legal processes to achieve a particular (in this case
financial) objective [16].

From a systems design perspective, it is important to note that programmable

money relies on the internet, making it much easier and accessible to use across
previously siloed systems. Instead of navigating fragmented organizational and
payment provider sites, digital currency would allow frictionless payments at the
precise moment goods were received through machine-to-machine payment [17].

We have seen with recent literature on programmable money that it is very much a
work in progress. One major key ongoing challenge (especially with cross-border
payments) is the prevention of money laundering, fraud, and terrorist financing.
Central bank digital currency (CBDC) can be programmed with anti-money
laundering logic to reduce and mitigate fraud.

At an extreme PoV, potential, desirable smart contract features that are not provided
by the CBDC platform itself, may be achieved by relying on third party custodians
[9]. This is already the case, for example, with stablecoins such as Coinbase’s USDC
which is backed by deposits of dollars custodied by Coinbase itself as a third party,
hence relies in trust in them as an administrator. It may be feasible that limiting the
extensibility of the CBDC in an attempt to improve safety may have the unintended
effect of driving more users to services outside the sphere of influence of the central
bank which could be a positive thing. This may be an argument in favor of the CDBC
providing smart contract features.

Whilst the technical design of a programmable money system is important, the

technology alone cannot intrinsically provide a sufficient coherence guarantee [18].
The system must also rely on a convincing set of external incentives to uphold the
guarantee, lest the overall product not be seen as credible in the eyes of its users. In
addition, the technical design of a system may lend itself well to reliance on certain
types of incentives.

As highlighted by Alexander Lee from the Federal Reserve (June, 2021), "These
incentives can be viewed as falling within at least three broad categories of
economic incentives, legal incentives, and reputational incentives. These
categories are not mutually exclusive, though certain would-be providers of
programmable money may rely more heavily on some of them than on others."

Whether future CBDCs are retail or wholesale based, it has to have the same price
stability and level of trust. It is important to note that trusting an organization like
a central bank also means trusting that country’s economy and that it will be pivotal
in determining if programmability can be designed into a CBDC architecture. While
"programmable money" as a term has originated within the public blockchain
community, as a concept it does not necessarily need to involve DLT at all.

There are multiple possible approaches to the design of a technological system

offering a digital representation of money with an associated programming
facility; what is more important than the specific technical approach is the guarantee
that the system will in fact cohere into a unitary product offering, rather than a
service offering associated with an otherwise independent non-programmable digital
money.

Conclusion

We have covered a broad range of technical design features in this article and we
have only just scratched the surface of what a CBDC technical stack could look like
for central banks. The complete journey for policy-makers for CBDC discovery all the
way through to their launch is a multi-year effort that requires close collaboration
between policy makers, technology teams, and all impacted stakeholders.

Throughout this journey, there will likely be many points at which various countries
decide to continue, or not, toward a CBDC launch which has been evident on the
work existing central banks have conducted. Research, experimentation, and
collaboration along the way can ensure that if a central bank makes it to launch, they
will have a well-designed policy-driven CBDC system.

Throughout the multi-year program for central banks and their policy-makers, many
new technological considerations (over and above what has been discussed here) will
likely emerge and have an impact on policy. Policy-makers must stay on top of such
developments in order to refine their policy choices which will ultimately dictate the
final design of their CDBC. Those closest to new technological advancements will be
best positioned to understand it. We should also consider that there may potentially
be second-order effects that are best understood when there is clarity on policy
objectives. As the iterative process progresses, every CBDC design decision needs to
be evaluated both for its technical ability to meet functional requirements and for its
impact on the ability to meet today's and tomorrow's policy objectives for central
banks.
Finally, experimentation by central banks should continue whether it's wholesale or
retail based but that does not require a final decision about whether or not to launch
a CBDC. Many countries are awaiting the results from their own and other’s
experiments before finalizing their decision. CBDC systems will need rigorous
technical experimentation around system requirements for resilience, throughput,
and scalability, for example, before determining if the system can achieve policy
goals.

Citations:

1. Retail Central Bank Digital Currency from vision to design: A framework to align
policy objectives and technology design choices (March, 2020)
https://aws.amazon.com/blogs/publicsector/approaches-retail-central-bank-digital-
currency-aligning-technology-policy/
2. Central Bank Digital Currency Policy-maker Toolkit (January, 2020)
https://www3.weforum.org/docs/WEF_CBDC_Policymaker_Toolkit.pdf
3. The technology of retail central bank digital currency (March, 2020)
https://www.bis.org/publ/qtrpdf/r_qt2003j.pdf
4. On the future of financial securities settlement (March, 2020)
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3561195
5. Infrastructure and design of Central Bank Digital Currencies (May, 2021)
https://bisontrails.co/downloads/bison-trails-infrastructure-and-design-cbdcs.pdf
6. Central bank digital currencies: foundational principles and core features (December
2020) https://www.bis.org/publ/othp33.pdf
7. How to issue a privacy-preserving central bank digital currency (June, 2021)
https://www.suerf.org/suer-policy-brief/27227/how-to-issue-a-privacy-preserving-
central-bank-digital-currency
8. Project Dunbar: international settlements using multi-CBCS (March 2022)
https://www.bis.org/publ/othp47.pdf
9. Design choices for Central Bank Digital Currency: policy and technical
considerations (July, 2023)
https://www.brookings.edu/wp-content/uploads/2020/07/Design-Choices-for-
CBDC_Final-for-web.pdf
10. Fast and secure global payments with stellar (October 2019)
https://dl.acm.org/doi/10.1145/3341301.3359636
11. Libra white paper: Blockchain (June, 2019) https://libra.org/en-US/white-paper/.
12. An ECB digital currency – a flight of fancy? (May. 2020)
https://www.ecb.europa.eu/press/key/date/2020/html/ecb.sp200511~01209cb324.en.h
tml.
13. Frontrunning in decentralized exchanges, miner extractable value, and consensus
instability (July, 2020) https://ieeexplore.ieee.org/document/9152675
14. How China’s new digital yuan app makes money programmable (September, 20210)
https://www.theblockcrypto.com/news+/117641/china-digital-yuan-smart-contract-
programmable
15. China's digital yuan shows why we still need cryptocurrencies like bitcoin (February,
2022) https://edition.cnn.com/2022/02/04/perspectives/china-digital-yuan-
cryptocurrency-bitcoin/index.html
16. CBDC: how dangerous is programmability? (September, 2021)
https://sites.law.duke.edu/thefinregblog/2021/09/21/cbdc-how-dangerous-is-
programmability/
17. As programmable money emerges, central banks ramp up for tokenized economy
(March, 20201) https://www.forbes.com/sites/sap/2021/03/25/as-programmable-
money-emerges--central-banks-ramp-up-for--tokenized-economy/?sh=6d352354c402
18. What is programmable money? (June 2021)
https://www.federalreserve.gov/econres/notes/feds-notes/what-is-programmable-
money-20210623.htm