Project Dunbar

Download as pdf or txt
Download as pdf or txt
You are on page 1of 63

Project Dunbar

International settlements
using multi-CBDCs
March 2022
Contents
01 Executive summary 2

02 Introduction 3

03 International settlements with multi-CBDC 8

3.1. Expected benefits 9

04
Critical challenges 11

4.1. Access
4.2. Jurisdictional boundaries
4.3. Governance

05 Designing for a multi-CBDC common platform 12

06 Governance 14

6.1. Access considerations 14


6.2. General principles for shared platform 18
6.3. Decision-making considerations 19

07 Processes 22

7.1. High-level cross-border payments flows 22


7.2. Cross-border settlement 23
7.3. Non-settlement processes 23
7.4. Foreign currency exchange 24

08 Technology 26

8.1. Infrastructure 26
8.2. Applications 29

09 Summary and next steps 30

Appendix
1.1 Dunbar capabilities and considerations 35
1.2 Prototype developed by R3 on Corda platform 37
1.3 Prototype developed by Partior on Quorum platform 53
1.4 Glossary of Terms 61

Project Dunbar – International settlements using multi-CBDCs | 1


Executive summary 01
Project Dunbar explores how a common and 8. The technical design of the prototypes is
platform for multiple central bank digital summarised in Section 8, with further details of
currencies (multi-CBDCs) could enable cheaper, the technical prototypes developed by R3 and
faster and safer cross-border payments. The Partior available in the appendix.
project is a collaboration between the Bank for
International Settlements (BIS) Innovation Hub The final part of the report suggests areas for
Singapore Centre, the Reserve Bank of Australia, further exploration and would be of interest to
Bank Negara Malaysia, the Monetary Authority of policymakers and technologists. As one of the
Singapore and the South African Reserve Bank. first technical experiments in the nascent space
of multi-CBDCs, Project Dunbar focused as much
This initial phase of the project successfully on identifying problems as on solving them, and
developed working prototypes and demonstrated ended with more questions than answers – and
practicable solutions, achieving its aim of proving with more questions than before it started. Open
that the concept of multi-CBDCs was technically questions and challenges were identified and
viable. The prototypes validated the design categorised across the areas of policy, business
approaches taken to resolve three critical sets of and technology. Key milestones and next steps
challenges relating to access, jurisdictional were also identified.
boundaries and governance.
This final section describes problem statements
The first part of the report provides a broad that need to be explored in the multi-CBDC
overview of the multi-CBDC space, including key space and constitutes an open call for
benefits and challenges, and would be of interest collaboration to the central banking community,
to policymakers. This starts in Section 2, which banking and payments companies, and the
explains the motivations for the project and the broader blockchain technology ecosystem.
approach to achieving its objectives. Section 3 Multi-CBDC common platforms could make
elaborates on the expected benefits of a multi- cross-border payments cheaper, faster and safer
CBDC platform, explaining how cross-border – and see them approach the efficiency of
payments can be made faster, cheaper and safer domestic payments systems that we are familiar
through reduced reliance on intermediaries, with. However, this is a journey that we must take
simplification of settlement processes, together.
consolidation of common processes and process
automation using smart contracts. Section 4
explores three critical challenges of implementing
a multi-CBDC platform.

The second part of the report describes the


design of a multi-CBDC platform and would be of
interest to technologists. An overview of the
foundational capabilities required in a multi-
CBDC platform is outlined in Section 5, which
describes its capabilities across the areas of
governance, processes and technology. Each of
these is covered in greater depth in Sections 6, 7

2 | Project Dunbar – International settlements using multi-CBDCs


Introduction 02
Project Dunbar is a collaboration between 2.1.1 Inefficiencies of
the Bank for International Settlements (BIS) cross-border payments today
Innovation Hub Singapore Centre, the Reserve This fragmented network results in cross-border
Bank of Australia (RBA), the Bank Negara payments being generally slower, opaque and
Malaysia (BNM), the Monetary Authority of more expensive compared with domestic
Singapore (MAS) and the South African Reserve payments. A single cross-border payment might
Bank (SARB) to explore how a common platform pass through multiple correspondent banks using
for multiple central bank digital currencies the foreign currencies held with them. Each leg of
(CBDCs) could enable cheaper, faster and safer the overall transaction takes time and effort to
cross-border payments. process, with fees levied that add up quickly and
are passed on to customers, resulting in slow and
The area of cross-border payments is complex costly cross-border payments.
with multiple challenges, although several projects
are underway to address them. One key challenge In addition, there are significant operational
is fragmentation, which Project Dunbar looks to processes that are needed to comply with
address by exploring a common platform for regulations such as foreign exchange controls
cross-border settlements that allows participating and anti-money laundering/countering financing
central banks and financial institutions to transact of terrorism (AML/CFT) measures. These
directly with each other in CBDCs. processes, such as enhanced due diligence (EDD)
and know-your-customer (KYC) processes, are
2.1 Background often manual and must be performed in each
Cross-border payments are fund transfers for jurisdiction and by multiple parties in order to
which the sender and the recipient are in satisfy the unique requirements imposed by
different jurisdictions.¹ Such payments can be respective regulators.
further classified into wholesale and retail
payments. Project Dunbar focuses on wholesale 2.1.2 Global efforts to improve cross-
payments between banks (interbank payments). border payments
Globally, cross-border payments lag significantly
Unlike domestic payments, where banks can pay behind domestic payments in meeting user
each other directly on a single national payments expectations for services. Faster, cheaper, more
platform, there is currently no single international transparent and more inclusive cross-border
platform for cross-border payments and payments could have widespread benefits for
settlements leveraging CBDCs. Today, the citizens and economies worldwide, supporting
correspondent banking model is used, where economic growth, international trade, global
banks hold foreign currency accounts with each development and financial inclusion.
other. To complete a single cross-border transfer,
multiple correspondent banks may be involved, In October 2020, the G20 endorsed an ambitious
with transactions recorded on multiple ledgers roadmap to enhance cross-border payments
on multiple systems built on different around the world.² The G20 roadmap was
technologies and communicating in different developed by the Financial Stability Board (FSB)
message formats. in coordination with the BIS Committee on
Payments and Market Infrastructures (CPMI) and
other international bodies. It sets out a five-year
programme to address various frictions in retail

¹ See Bank for International Settlements et al, “Central bank digital currencies for cross-border payments”, 2021, www.bis.org/publ/othp38.htm.
² See Financial Stability Board (2020), Enhancing Cross-border Payments Stage 3 roadmap. https://www.fsb.org/wp-content/uploads/P131020-1.pdf

Project Dunbar – International settlements using multi-CBDCs | 3


and wholesale cross-border payment been projects on cross-border payments using
arrangements that contribute to the challenges CBDCs through bilateral connectivity, such as
of high cost, low speed, limited access and Jasper-Ubin by the Bank of Canada and the MAS.
insufficient transparency.
Building block 19 of the G20 roadmap seeks to
The G20 roadmap aims to address these “factor an international dimension into CBDC
interrelated problems through 19 “building designs”, and this has led to growing interest in
blocks” (ie workstreams) that will be run in exploring models through which multiple CBDCs
parallel over the course of the plan by the could be used for cross-border payments (so-
relevant international organisations and called multi-CBDC arrangements). Three
standard-setting bodies (Figure 1). conceptual models for multi-CBDCs were
described in a recent paper by the BIS:⁴
2.1.3 CBDCs as a potential solution compatible CBDC systems (model 1), interlinked
One focus area of the G20 roadmap is in new CBDC systems (model 2) and a single system with
payments infrastructures and arrangements, multiple CBDCs (model 3).
which includes CBDCs. CBDCs show great
promise in terms of improving payments, and
have been the subject of exploration by multiple What is a CBDC?
central banks. In simple terms, a CBDC is a digital banknote.
It could be used by individuals to pay
businesses or other individuals (a retail CBDC)
Prior explorations have focused on the use of or it could be used by financial institutions
CBDCs for domestic payments. Examples of or other wholesale market participants to
projects by our project partners include Project settle trades in financial markets or other
Atom by the RBA, Project Ubin by the MAS and transactions (a wholesale CBDC).⁵
Project Khokha by the SARB. There have also

Figure 1: Overview of the focus areas and associated building blocks³

³ See BIS, “Enhancing cross-border payments: building blocks of a global roadmap”, July 2020, p3.
⁴ See R Auer et al, “Multi-CBDC arrangements and the future of cross-border payments”, BIS Papers, no 115, March 2021.
⁵ See BIS, “BIS Innovation Hub work on central bank digital currency (CBDC)”, www.bis.org/about/bisih/topics/cbdc.htm.

4 | Project Dunbar – International settlements using multi-CBDCs


Figure 2: Multi-CBDC arrangements can facilitate Model 1 enhances compatibility for CBDCs via
cross-border payments similar regulatory frameworks, market practices,
messaging formats and data requirements.

Model 2 involves interlinked CBDC systems.


This could build on enhanced compatibility while
offering additional safety, via PvP settlement.
Further, common clearing mechanisms –
potentially operated by central banks acting as
super-correspondents in cross-currency settings
– could enhance efficiency, especially when they
are linked with FX trading.

Model 3 involves a jointly operated mCBDC


payment system hosting multiple CBDCs. All FX
settlements would be PvP by default, rather than
requiring routeing or settlement instructions
through a specific entity acting as an interface.
Trading venues could also be integrated into
an mCBDC system, to reduce complexity,
fragmentation and concentration.

Source: R Auer, P Haene and H Holden, “Multi-CBDC arrangements and


the future of cross-border payments”, BIS Papers, no 115, March 2021

Project Dunbar – International settlements using multi-CBDCs | 5


2.2 Motivations and objectives In addition to the central banks, the project was
Project Dunbar builds on the prior work and supported by diverse industry participants from
experience of its partnering central banks to the finance and technology sectors. R3 and
explore the development of a common shared Partior, which have been working actively in the
settlement platform which connects all area of digital currencies, supported the project
participating central and commercial banks. This as distributed ledger technology (DLT) and
is aligned with the model 3 arrangement of a platform providers, bringing a deep technical
single system for multi-CBDCs. and commercial perspective to the project.
Commercial banks also participated in workshops
A common platform for international settlements to review and discuss their perspectives on a
using CBDCs could bring about significant multi-CBDC platform.
improvements to cross-border payments, much
like how national payments systems have made Project Dunbar was organised in three concurrent
domestic payments seamless, instant and low workstreams to carry out design and technical
cost in many countries. At the same time, this activities.
new type of arrangement also brings new
challenges.
Figure 3: Workstreams

Project Dunbar aims to explore the potential


benefits and opportunities of a multi-CBDC Project Dunbar
platform, understand the critical obstacles and
challenges to implementing such a platform,
develop design approaches to address them, and
Prototype Prototype
prove the viability of the concept through the Design
development development
workstream
building and testing of technical prototypes. (Corda) (Partior)

Technical workstreams
2.3 Project methodology

2.3.1 Project partners and structure The design workstream was led by Accenture
(workstreams) with support from Temasek, and focused
Project Dunbar is a collaboration between the primarily on developing the high-level functional
BIS Innovation Hub Singapore Centre and the requirements and design of a shared cross-
central banks of Australia, Malaysia, Singapore border payments system. A series of workshops,
and South Africa. which were conducted across three sprints with
the participating central and commercial banks,
The partner central banks have published utilised a structured design-thinking approach
multiple reports and conducted technical to discuss and develop an innovative yet
experiments on CBDCs, bringing a wealth of practical solution.
knowledge and expertise to the project. This
has helped to generate useful insights during The goal of the technical workstreams was to
discussion workshops and led the team to develop technical prototypes on two different
develop an appreciation of the complexities DLT platforms – Corda and Quorum – to
involved in building a common platform, as well transform the idea of a multi-CBDC platform into
as on more abstract topics such as governance. working prototypes. The Corda platform
There were also two central bank observers of development was led by R3 while the Quorum
the project, the Bank of France and Hungary’s platform development was led by Partior (with
Magyar Nemzeti Bank, which contributed support from DBS, J.P. Morgan and Temasek).
substantially to the discussion, and their support The two prototypes were developed based on
is greatly appreciated. the proposed requirements and designs from the
design workstream, while leveraging the existing

6 | Project Dunbar – International settlements using multi-CBDCs


foundational features and architecture of their information that the technical partners needed in
respective platforms. These capabilities and order to develop their prototypes. For example,
features were enhanced to support the specific account structure was discussed in Sprint 1 by the
needs of a multi-CBDC platform. design workstream, and its outputs were used as
requirements and specifications for development
2.3.2 Scope of Project Dunbar by the technical workstreams in Sprint 2.
Many of the basic functionalities required of a
multi-CBDC platform, such as CBDC issuance, 2.3.4 Methodology
transactions and redemption, are similar to those Accenture’s financial market infrastructure (FMI)
of domestic wholesale CBDC systems. As this area capability model was used as a reference to
has been the subject of significant global research identify key areas for scope discussion within
efforts by central banks and technology providers, each capability across the three sprints. This was
many such functionalities have been developed to ensure a structured approach to identifying
and made available as out-of-the-box aspects of the scope required for designing a payments
the two DLT platforms. As such, Project Dunbar settlement platform. Over the course of the
did not seek to replicate these efforts, but rather project, a proposed capability framework for a
to focus on the specific requirements of a multi- multi-CBDC common platform was developed to
CBDC platform. represent the key topics that were covered. This
is covered in greater detail in Section 5 and in
2.3.3 Approach and sprint structure the appendix.
As an exploratory project with open-ended
questions to be explored within a defined Prior to Sprint 1, a Sprint 0 scoping workshop
timeframe, the Agile methodology was adopted was conducted for the central banks to discuss
for the project. Initial scoping workshops were and agree on the key focus areas. Their inputs
held to define logical groupings of areas to be were then cross-referenced to the FMI capability
explored in the project. User inputs were sought model, after which the central banks voted for
through iterative discussions, which also helped the five most important capabilities for further
to set the direction and scope of subsequent exploration and discussion during the sprints.
workshops. A total of three sprints were planned This formed the scope for the three sprints.
over a period of nine weeks with three
concurrent workstreams. During each sprint, the At the start of each sprint, key questions were
design and technical workstreams focused on identified to guide discussion throughout. These
their sprint objectives which are based on the key questions were first explored from the design
identified scope and high-level topics listed in perspective, which is elaborated on in Sections
figure 4 below. 4 to 7. Further discussion on how they were
implemented by R3 and Partior on the Corda
The sprint order is not a reflection of the and Quorum platforms respectively, is detailed
importance of the topic. Instead, the order was in Section 8.
determined based on the sequence of key

Figure 4: Sprint Objectives


Sprint 1 Sprint 2 Sprint 3
Design workstream Define participants and Define processes for FX and Review legal and regulatory
stakeholders, membership settlement services across policies, and define governance
structure and onboarding participant types and technical controls
processes

Technical workstream Enable multiple CBDC Enable foreign currency (FCY) Enable new models of FX, and
issuers and customise base transactions, with multi- technical controls to support
functionality (issue, redeem, tier account structure and governance models
transact) onboarding

Project Dunbar – International settlements using multi-CBDCs | 7


International 03
settlements with
multi-CBDC
On a multi-CBDC common platform, each currencies without the need for accounts with
participating central bank issues its own CBDC correspondent banks. As all participating banks
in its own domestic currency. Participating could potentially hold the different CBDCs
commercial banks are then able to hold these directly, they would be able to transact directly
CBDCs directly, gaining access to foreign with each other in the participating currencies.

Transacting on a multi-CBDC platform

AU bank A1 AU banks A2 MY bank M1 MY banks M2 SG bank S1 SG banks S2 ZA bank Z1 ZA banks Z2

AUD AUD AUD AUD AUD AUD AUD AUD

MYR MYR MYR MYR MYR MYR MYR MYR

SGD SGD SGD SGD SGD SGD SGD SGD

ZAR ZAR ZAR ZAR ZAR ZAR ZAR ZAR

As an example, Singapore-headquartered bank S2 is a banking group with licences to operate


in Singapore and Malaysia. It would likely already have access to the national payments
systems of both jurisdictions and access to the two currencies (Singaporean dollars and
Malaysian ringgit) in central bank money, shown in solid colours. The multi-CBDC platform is
intended to allow the bank to hold CBDCs directly even in jurisdictions in which it does not
have a presence – such as Australia and South Africa. In this way, it can hold Australian dollars
and South African rand issued by the respective central banks, shown in shaded colours. This
allows all banks participating in the platform to hold all currencies, enabling them to transact
directly with each other. S2 can hold AUD CBDC and use it for payment to South African bank
Z1 directly, which was not previously possible.

8 | Project Dunbar – International settlements using multi-CBDCs


Figure 5: multi-CBDC platform

South African Singaporean


banks banks

Transact Transact

Common Settlement Platform

Issue/Redeem Issue/Redeem

South African rand Singaporean dollar


South African CBDC CBDC Monetary
Reserve Bank Replicate
Authority of
Singapore

Distributed
Replicate

Replicate
Ledger

Replicate

Australian dollar Malaysian ringgit


CBDC CBDC
Issue/Redeem Issue/Redeem

Reserve Bank Bank Negara


of Australia Malaysia
Transact Transact

Australian Malaysian
banks banks

3.1 Expected benefits foreign exchange controls on the transaction. Each


International settlements on a multi-CBDC leg of the overall transaction takes time and effort
common platform could make cross-border to process, which adds up quickly when multiple
payments faster, cheaper and safer. This correspondent banks are involved.
is achieved through reduced reliance on
intermediaries, simplification of settlement A multi-CBDC platform would be designed so
processes, efficiency gains through consolidation that participating banks can transact directly
of common processes, and process automation with each other using different CBDCs without
with programmable money using smart the need to hold foreign currency accounts
contracts. with correspondent banks. Instead, CBDCs can
be transferred directly from the sender to the
3.1.1 Reduced reliance on recipient bank. However, although reliance on
intermediaries correspondent banks is reduced, it might not be
Cross-border payments today take place fully eliminated to the extent that correspondent
through a correspondent banking model in banks are needed for onboarding and transaction
which banks hold foreign currency accounts approvals – as explained in Section 6.1.
with other banks (called correspondent banks).
A single cross-border transfer may involve one 3.1.2 Simplification of settlement
or more correspondent banks using the foreign processes
currencies held with them to settle the transaction. With the correspondent banking model, a single
Correspondent banks also perform non-settlement cross-border transfer requires multiple ledgers to
processes such as AML/CFT compliance and be updated on different systems. Banks also need

Project Dunbar – International settlements using multi-CBDCs | 9


to reconcile their nostro and vostro balances to 3.1.4 Process automation with smart
verify that balances were correctly updated. contracts
Other than reducing duplicative processes,
On a multi-CBDC common platform, transfers there is also the potential for processes to be
are recorded on a single ledger in one step, automated through smart contracts. Business
and participants have full real-time visibility of rules or conditions – such as having sufficient
their balances. The settlement process is hence liquidity, technical validations and meeting
simplified and there is no need for reconciliation. business requirements – could be automated
using the smart contract features on a DLT
3.1.3 Efficiency gains with common platform.
platform processes
The multiple banks involved in a cross-border Smart contracts can also be used for conditional
transfer often perform similar processes payments, to hold funds and to release payment
individually, such as AML/CFT and sanctions upon the fulfilment of pre-defined conditions –
screening. Such processes are similar in nature, for example, with payment-versus-payment (PvP)
with a common aim of verifying the sender and delivery-versus-payment (DvP) transactions.
and recipient’s identities to minimise the risk Where the assets are issued on a common
of transactions facilitating money laundering, platform, they can be directly managed by
terrorist financing or other forms of financial smart contracts without the need for a trusted
crime. intermediary and coordination across different
platforms. Examples include PvP settlement for
A common platform creates an opportunity for exchange of CBDCs in different currencies, as
such processes to be performed centrally. For well as DvP settlement of tokenised assets with
example, multiple sanctions checks which are CBDCs if such assets were to be issued on a
performed for the respective jurisdictions could common platform. Where the assets are issued
be consolidated into a single check against a on different platforms, smart contracts can still
common sanctions list that is based on the UN be used, but with a higher level of technical
Security Council consolidated list⁶ or the FATF complexity due to the need for coordination
recommendations⁷. across platforms.

Differences in regulatory requirements across Automating conditional checks using smart


jurisdictions, however, mean the scope for contracts could help ensure each party’s
centralisation of compliance activities may obligations are clear and enforced. This could
be limited. For example, countries might give stakeholders involved in cross-border
have domestic watchlists that do not apply transactions greater assurance of efficient and
to transactions outside their jurisdiction. equitable processes.
Centralising common processes might create
efficiency gains in reducing duplicative processes,
but further exploration is required to ascertain
how feasible this is in practice.

⁶ UN Security Council, "UNSC Consolidated List", https://www.un.org/securitycouncil/content/un-sc-consolidated-list


⁷ FATF, "FATF recommendations", https://www.fatf-gafi.org/publications/fatfrecommendations/

10 | Project Dunbar – International settlements using multi-CBDCs


Critical challenges 04
While there may be significant benefits to The project took a design approach to
conducting settlements on a common platform, differentiate between settlement and non-
success also comes with significant challenges. settlement processes, which enables the clear
This project focused on challenges that are delineation of jurisdictional boundaries,
distinct to a multi-CBDC common platform. This adherence to regulatory policies of different
includes the cross-border and cross-jurisdictional jurisdictions, and the streamlining of settlement
aspects of international payments, and the processes. This is explored in detail in Section 7.2
challenges of managing a multi-central bank and Section 7.3.
shared platform. Many of the general aspects of
wholesale CBDC have been addressed in earlier 4.3 Governance
projects by central banks, and were not revisited Central banks traditionally have a high degree of
in detail. control over their domestic payments systems.
A multi-CBDC platform would serve as an
The project identified and focused on three international payments system for, and record the
critical sets of challenges, which had a significant liabilities of, multiple central banks. In such an
impact on the subsequent design. These were arrangement, how can multiple central banks
access, jurisdictional boundaries and governance. share a common platform while addressing the
financial system resilience and national security
4.1 Access concerns that may arise from sharing such a
As noted earlier, one defining characteristic critical payments infrastructure with other central
of a multi-CBDC platform is the ability for banks?
participating banks to hold and transact in
CBDCs of different currencies. This is critical in A shared platform implies a level of universality
reducing the reliance on correspondent banks – with features and capabilities that are common
for cross-border payments. However, there are and available to all participants. At the same time,
some key questions to be explored to ensure an adequate level of autonomy and control over
that this is feasible, such as whether non- each jurisdiction’s domain areas is required to
resident banks – ie banks which do not have a build greater confidence among the equal
local presence and are not authorised to operate participants of a shared platform.
or provide domestic financial services – can be
trusted to access and make payments with The project took a design approach of optimising
CBDCs when they do not have a presence in universality and autonomy. Governance structures
those jurisdictions? and decision-making authorities are designed to
ensure that the diverse stakeholders are
In designing the access framework, two models represented, and that collective decisions are
were explored: “direct” CBDC access and “hybrid” made fairly and equitably. Central banks are also
CBDC access. These access models are described granted autonomy within the boundaries and
in Section 6.1. parameters of a universal platform-level
framework. This is explored in Section 6.3.
4.2 Jurisdictional boundaries
Payments regulations are different in each
country, and participants in a cross-border
payment are subject to these different regulatory
frameworks. A key challenge is how to simplify
the cross-border payments flow while respecting
regulatory differences across jurisdictions.

Project Dunbar – International settlements using multi-CBDCs | 11


Designing for a 05
multi-CBDC common
platform
A multi-CBDC common platform requires foundational capabilities across the areas of governance,
processes and technology. These capabilities are outlined below and covered in greater depth in the
subsequent sections.

Figure 6: Capabilities and considerations for a multi-CBDC common platform

Governance

1. Participants and stakeholders


1.1 Commercial
1.2 Central banks 1.3 Regulators 1.4 Operators 1.5 Corporates
banks

2. Onboarding of members

2.1 Account setup 2.2 End-to-end onboarding process

3. Legislation, oversight, rules and policy


3.2 Legislation and 3.3 Rules and
3.1 Governance structure 3.4 Policy
regulations compliance

Processes

4. Processing, clearing and settlement services

4.3 Monitoring,
4.1 Integration/ 4.2 Interbank 4.5 System
reporting, control 4.4 User interface
connectivity payments administration
and notification

Technology

5. Technology and solution architecture


5.1 Application
5.2 Data architecture 5.3 Infrastructure 5.4 Security
architecture

limited discussion on the capability during the project

12 | Project Dunbar – International settlements using multi-CBDCs


Governance capabilities relate to the rules and Technology capabilities refer to the complete
boundaries for the operations and usage of the solution stack required to enable the technical
platform, and the mechanisms by which decisions delivery of the multi-CBDC common platform.
are made. Rules include internal rules that are Infrastructure includes the servers, network and
inherent to the platform, as well as the broader DLT platform that enables central banks to
legal and regulatory policies that the platform communicate with each other on a shared
and its participants must adhere to. A key part of platform. Data and application architectures
governance is about defining participants and define the CBDC tokens and how they can be
stakeholders, and their roles and responsibilities used for transactions by participants. Security
on the platform. Other aspects include access includes security features and controls that
considerations, how members are onboarded, the enable central banks to comfortably transact on
structures for making decisions, and how rules this shared platform.
are developed and applied.

Process capabilities relate to the series of actions


taken to complete a payment transaction, and
the functionalities required to perform these
actions. As this phase of the project focuses on
proving the viability of cross-border payments,
most of the work centred around interbank
payments processes. Capabilities relating to
integration and connectivity with central banks’
systems, such as those used for pledging assets
to back the issuance of CBDCs, were not explored
as they have been tested and proven in prior
research by central banks. Ancillary capabilities
such as monitoring, reporting, control and
notification were deemed to be a lower priority
and were not explored in the current phase.
Similarly, user interfaces and system
administration tools were deemed to be a low
priority and no further work was conducted on
them. However, these are often already available
as built-in capabilities of existing platforms, and
so were made available for testing by the
technology partners.

Project Dunbar – International settlements using multi-CBDCs | 13


Governance 06
Governance is a key consideration for a multi- stakeholders include parties that are directly
CBDC platform that is shared by multiple central involved in using the platform, as well as other
banks and involves numerous stakeholders stakeholders that may have an interest in doing
across jurisdictional boundaries. so. In defining the participants, there was a
deliberate decision to create granular groups due
The project identified key participants and to their different treatments from policy and
stakeholders, and defined their roles and technical perspectives. This differentiation at an
responsibilities, as well as considerations for early stage also allows for a common set of terms
access to the multi-CBDC platform. Decision- to be used across the different workstreams.
making considerations, including governance
structures and framework, were explored to Commercial banks were split into three groups.
understand how decisions can be made in a The differentiation of non-resident banks, which
manner that ensures representation of diverse do not have a presence in the local jurisdiction,
stakeholders and is fair and equitable. The was particularly important from the perspective
project also explored how central banks can be of access policies. The differentiation of
granted autonomy within the boundaries and commercial banks into “selected” and “others”
parameters of a universal platform-level was to cater for potential differentiation in the
framework. hosting of nodes and direct access to the
network, as well as the onboarding processes.
6.1 Access considerations
Participants must be granted access to transact A limited number of large commercial banks of
on the multi-CBDC platform. There are multiple proven financial standing in their respective
layers of access, each with its own set of jurisdiction would be identified as selected
considerations, and with different privileges and commercial banks. They would be provided with
modes of access for different participants. additional privileges and may be required to
comply with more stringent requirements. Other
First, participants must have access to the commercial banks would transact through these
platform to use it and communicate with others. selected commercial banks and may have limited
This could be directly through the nodes they privileges on the system and be subject to less
host, or indirectly through nodes hosted by stringent requirements.
others. Second, participants must have access to
hold the CBDCs as assets representing a legal Central banks, regulators and operators were also
claim on the issuing central banks. Third, split into three distinct roles. In some
participants must have access to transact with jurisdictions, a single entity takes on the role of
the CBDCs, to initiate and make payments to both central bank and financial regulator.
others. This could be directly between them and Similarly, central banks in some jurisdictions are
their recipients or indirectly where intermediaries also operators of the national payment systems.
play a role in processing the transaction. The distinction between central bank and
regulator is particularly important in relation to
6.1.1 Participants and stakeholders transaction processes, as settlement or the
The level of access granted will be different for movement of CBDCs is the domain of central
different participants. Defining the participants banks, while other processes relating to AML/CFT
and stakeholders is hence an important part of are the domain of regulators. Definitions of the
access policies and the broader governance participants are detailed in Appendix 1.1.
framework. For the project, participants and

14 | Project Dunbar – International settlements using multi-CBDCs


Each of the parties has a role which defines their rights and obligations on the platform – it is vital to
note that some of these roles apply only to the hybrid CBDC model and are not part of the direct
CBDC model.

Figure 7: Participants’ roles

Role

1. Initiate transfer and exchange of CBDCs


2. Perform AML processes on non-local banks
Selected
3. On-ramp/Off-ramp of CBDCs
commercial
banks 4. Exchange collateral with central bank for CBDC (primary
issuance)
5. Onboard other commercial banks/non-local banks
Commercial
banks Other 1. Initiate transfer and exchange of CBDCs
commercial
banks 2. Perform AML processes on non-local banks

Non-resident
1. Initiate transfer and exchange of CBDCs
banks

1. Initiate transfer and exchange of CBDCs


2. Issue/destroy CBDC
Central banks 3. On-ramp/Off-ramp of CBDCs
4. Onboard selected commercial banks
Including: set up and manage currency controls (if any)

1. Review members of the system (incl. during onboarding)


Regulators
Including: regulate members of their own jurisdiction

1. Onboard central banks


Operators
Including: execute operational policies set out for the scheme

Corporates – Customers
N/A – Transact only through commercial banks
of banks

6.1.2 Access to platform Access to the platform is managed through an


Access to platform refers to the ability to use the onboarding (and offboarding) process. This will
platform and communicate with others. The likely be governed in a federated manner to
primary means of accessing the platform is respect central banks’ autonomy within their
through hosting a node and connecting to other jurisdictions or domains. For example, while
nodes and components of the network. central banks will be onboarded by a central
Participants that host nodes have direct access to operator, commercial banks will be onboarded by
the platform, while participants that do not host their respective central banks. It should also be
nodes may access indirectly through nodes noted that there are two perspectives to
hosted by other participants.

Project Dunbar – International settlements using multi-CBDCs | 15


onboarding. There is a governance perspective – From a technical scalability perspective, there may
this is the decision to accept and onboard the be a limit to the optimum number of nodes on
participant. There is also a technical and the network. If so, access to the platform would
operational perspective of enabling network be implemented as a two-tier model, with only
connectivity of the nodes, and provisioning of selected commercial banks hosting nodes, and
network credentials and wallets. For example, other commercial banks connecting through
technical and operational onboarding of a new them. While technical scalability was not tested in
central bank will be performed by the operator, the project, access to the platform was still
following approval by a governance body. designed for flexibility with this possibility in mind.

Figure 8: Onboarding participants

Onboarding/off-boarding by
Selected
Central operator Central banks commercial
banks

Selected
commercial
banks

Commercial
banks Other
commercial
(If all banks (If only selected
banks host nodes) banks host nodes)

Central banks (With approval of


governance body)

Central banks Other commercial banks


The decision to admit new central banks to the Other commercial banks and non-resident banks
scheme would be undertaken by a governance could be onboarded by a selected commercial
body, based on a variety of factors (see Section bank for a jurisdiction and may be subject to
6.3.5). commercial agreements.

From a technical and operational perspective, When a new participant is being onboarded
onboarding would be executed by a central onto a platform, it needs to meet two sets of
operator. onboarding requirements. The first is a set of
common rules at the platform level. The second
Selected commercial banks relates to jurisdiction-specific requirements as
Selected commercial banks could be chosen and mandated by the local central bank.
technically and operationally onboarded by the
central banks in their country of domicile. These Non-resident banks
would likely be larger banks that are existing As banks only require a single point of connection
participants of other payment schemes. to the platform, access to the platform for non-
resident banks will be provisioned in their country
of domicile.

16 | Project Dunbar – International settlements using multi-CBDCs


6.1.3 Access to hold CBDCs the central banks receive through their national
One defining characteristic of a multi-CBDC payment systems. Non-resident banks can
platform is the ability for participating banks to receive and hold CBDCs by purchasing them
hold and transact in CBDCs of different from other banks as a foreign exchange
currencies. This is a change from conventional transaction.
models where only banks licensed in a particular
jurisdiction are granted access to its national 6.1.4 Access to transact in CBDCs
payments system and to central bank money. In transacting with CBDCs, there is a need for
compliance with local regulatory requirements
On the platform, all participants can hold CBDCs such as AML/CFT and foreign exchange controls.
that represent a direct claim on the central bank. Intermediaries may be required to fulfil these
In that regard, there is no intermediation of requirements. Two possible models for access
liability. All digital currencies transacted on the were explored: “direct” CBDC access and
platform are central bank money and are not “hybrid” CBDC access, both of which borrow
commercial bank money. heavily from the access models for retail CBDC.⁸
In a conventional correspondent banking model,
While all participants can hold CBDCs, central non-resident banks typically hold foreign
banks will likely only issue CBDCs to banks currencies through resident banks in the same
licensed in their jurisdictions. This is because the way that retail customers hold deposits with
issuance of CBDCs needs to be backed by a their banks. This similarity allows the retail CBDC
corresponding amount of pledged assets which models to be applied in a similar manner.

Figure 9: Potential access models

“Direct” CBDC model “Hybrid” CBDC model

Central bank Central bank

Commercial Non-resident Commercial


banks banks banks

Non-resident
banks
Legal claim

Transaction processing

⁸ See R Auer and R Böhme, “The technology of retail central bank digital currency”, BIS Quarterly Review, March 2020, pp 85-100, www.bis.org/publ/
qtrpdf/r_qt2003j.pdf.

Project Dunbar – International settlements using multi-CBDCs | 17


Direct CBDC access by non-resident banks and poses a challenge for commercial models
With a direct CBDC access model, non-resident and incentives for banks to play such sponsoring
banks can hold and transact directly with CBDCs roles. Various possibilities exist, including
without the need for sponsoring banks. However, reciprocal arrangements and obligations imposed
an onboarding process will still be required for as conditions of access and fees, and these
non-resident banks and they may be subject to need to be evaluated further. For example,
the central banks' internal controls and processes. one solution could see selected banks agree
Processes can be further streamlined and to sponsor each other’s transactions; banks
made significantly more efficient, but this may might also charge fees for transactions that they
require changes to existing regulatory policies sponsor.
and harmonisation across participating central
banks. For example, different jurisdictions might 6.2 General principles for shared
have different thresholds to identify significant platform
transactions that require enhanced due diligence. A multi-central bank common platform would
On a common platform, participants may be a shared platform where central banks issue
collectively agree to adopt the lowest threshold and record their liabilities on a platform over
to comply with the most stringent regulatory which they do not have full control. This is an
requirements. unfamiliar concept and there is a need to
develop principles that could engender trust and
Hybrid CBDC for access by non-resident banks confidence in using the shared platform.
With a hybrid CBDC model, non-resident
banks hold CBDCs representing a direct claim Participating central banks in the project were
on the issuing central banks, but they require polled on the considerations that are collectively
intermediaries, in the form of “sponsoring” banks, important in bringing about a high level of
for transaction processing. "Sponsoring" banks comfort in using a shared platform. These inputs
are resident banks which are subject to local were subsequently examined and distilled into
regulations, and perform customer due diligence six key ideas, which are further refined into
processes on behalf of the non-resident banks. general principles that act as a guiding step for
This includes onboarding and KYC processes as the right governance structure to be put in place
well as suspicious transaction monitoring and to maintain assurance for participants.
AML/CFT processes. As these control processes
continue to be applied in a similar manner,
a hybrid CBDC model is unlikely to require
significant amendments to existing regulatory
policies for implementation. However, this will
need to be further validated and may differ
across jurisdictions.

While the need for correspondent banks


is eliminated in the settlement process,
intermediaries in the form of "sponsoring"
banks may continue to play a role in control
processes such as KYC and AML/CFT. This limits
the efficiency gains of eliminating intermediaries

18 | Project Dunbar – International settlements using multi-CBDCs


Figure 10: Six governance principles

Transactions would need to comply with a common All participants (nodes or banks) will be subject
set of business rules enforced universally across to a universal set of security policies.
the platform, and additional currency or country-

6
specific business rules may be applied by the ❶ ❹
respective central bank.

Membership admission criteria should be


Data privacy should be upheld and based on
common and applied universally across the ❷ ❺ a need-to-know basis.
platform.
governance
principles
The central bank retains full autonomy over its
participation in the network including issuance, ❸ ❻ The platform is to be resilient and able to
destruction and maintenance of its own currency prevent and isolate specific failures from
(ie CBDC); and that each CBDC is unique. cascading to a platform-wide failure.

6.3 Decision making considerations 6.3.1 Governance structure


A shared platform implies a level of universality One major consideration is the composition and
– with features and capabilities that are common setup of one or more committees to provide
and available to all participants. Platform rules oversight over the various business activities
and policies are applied universally and fairly conducted in and for the multi-CBDC platform.
across participants.
At a conceptual level, the structure for a multi-
To enable this universality, governance structures CBDC platform is comprised of three levels
and decision-making authorities must be of decision-making: strategic and platform
designed to ensure that the diverse stakeholders decisions; tactical decisions; and day-to-day
are represented, and that collective decisions operational decisions.
are made fairly and equitably. At the same time,
an adequate level of autonomy and control Each level would be deliberated in committees,
over each jurisdiction’s domain areas is required comprising groups of stakeholders that have
to build greater confidence among the equal a diverse interest in ensuring the platform’s
participants of a shared platform. extended-term sustainability.

Figure 11: Governance structure

Levels of decision-making Applicable forums Relevant parties

Strategic and platform • Governance bodies Central banks, the BIS,


decisions selected commercial banks,
operator
Tactical decisions • Business management; governance-related bodies Central banks, the BIS,
• Technology- and architecture-related bodies selected commercial banks,
operator
• Risk- and compliance-related bodies
• Innovation- and research & development-related
bodies

Day-to-day operational • Business operations team Central banks (or their


decisions • Technology team appointed operator),
operator
• Risk and compliance team
• Innovation and research & development team

Project Dunbar – International settlements using multi-CBDCs | 19


6.3.2 Decision-making framework Tactical decisions – decisions that are
Decision-making on a shared platform involving unprecedented or somewhat familiar, and that
multiple countries is complex. For this reason, have a moderate impact and broad guidance
the types of decisions are classified in three available from the scheme’s policy/framework. An
categories below. Each category of decision- example includes the types of services that are
making may involve different governance. available to different members.

Strategic and platform decisions – decisions Day-to-day operational decisions – decisions


that are unprecedented or require judgment, and that are routine with low impact and have clear
which have a large impact or significance with standard operating procedures (SOPs)/guidance
little or no guidance from the scheme’s policy/ established. Examples include technical patching
framework. For example, taking a decision on or connecting new members to the platform.
who should operate the multi-CBDC platform, or
onboarding a new central bank.

Figure 12: Three levels of decisions


Impact and Established
Familiarity of
significance of frameworks, policies
decision
decision and SOPs

have little or no
Strategic are unprecedented or have a large impact or
Decisions that... guidance from scheme
and platform new significance
decisions policy or framework

are unprecedented
have broad guidance
Tactical or have a moderate
Decisions that... available from scheme
decisions somewhat familiar impact
policy or framework
(but meet other tests)

have clear SOPs


Day-to-day Decisions that... are routine have a low impact or guidance
operational decisions established

6.3.3 Common rules and autonomy Rules on the platform are thus designed to be
For the consistency of the platform, a set applied in three ways.
of common rules would be applicable to all
participants. Under a consortium structure, these • Platform-level rules – universal rules
common rules would be established through a applicable to all that participate in the scheme
consensus of the participating central banks. and applied at the platform level. These rules
are maintained centrally by the platform
At the same time, central banks demand operator. A potential platform-level rule
complete sovereignty and autonomy in: (i) could be managing access to the multi-CBDC
areas of critical functions, such as issuance of platform.
currency; (ii) the application of “local” rules and
regulations at the currency- and jurisdiction-level; • Jurisdiction-level rules – rules specific to a
(iii) the application and the recognition of the local requirement are applied on a jurisdiction
central bank’s mandate provided in its national level. These rules can be maintained by each
legislation; and (iv) data, including privacy and central bank. An example of a potential
selective sharing of data. jurisdiction-level rule could be limitations on
members which are allowed to obtain CBDCs
directly from the central bank issuing them.

20 | Project Dunbar – International settlements using multi-CBDCs


• Currency-level rules – rules specific to a a specified window and foreign exchange
currency on the scheme. These apply across controls.
different jurisdictions, and are applied on a
currency-level. These rules can be maintained When a new rule has been enacted, the following
by each central bank. Examples include flowchart may be used to determine whether the
payment transaction restrictions on members, rule will be applied at the platform, jurisdiction or
such as setting a maximum threshold for currency level.
the inflow/outflow of the currency within

Figure 13: Rule-mapping flowchart

yes Platform-level rule

Universal
rule related Greater Requirement
Local no no no no
to platform benefits in based on
requirement? applying rule Jurisdiction-level rule
governance specific
or platform consistently? currency?
economics?

Currency-level rule
yes yes

Achieving autonomy for central banks Strict technical controls are put in place to
Central banks are responsible for managing and guarantee this autonomy such that even a super-
regulating their nation’s currency to achieve user operator of the platform cannot violate
the objectives (fiscal or otherwise) set by that it. In addition, the platforms are designed for
country. This management of currency would resilience; this means failures at the individual
extend to a multi-CBDC platform, where a country level are isolated and therefore do not
central bank would need to be able to manage cascade into platform-wide failures. This ensures
its own CBDC on the platform. This entails not that the autonomised regions and components
only oversight over usage of its CBDC, but also of a central bank on this shared platform are not
issuance and redemption of CBDCs. infringed by the failures of other central banks.

The prototype platforms are designed to give From a technical perspective, both the R3 and
central banks autonomy within the boundaries Partior sandboxes were able to support the
and parameters of a universal platform-level necessary control that central banks require to
framework, such as in the application of manage and regulate their own currency. The
jurisdiction- and currency-level rules. Autonomy technical details are elaborated on in Section 8.
here is viewed as the ability for central banks to
exert control within the boundaries of their scope,
as well as the inability of any other party to do so
without the consent of the central banks.

Project Dunbar – International settlements using multi-CBDCs | 21


Processes 07
A typical cross-border payment includes multiple discrete sub-processes that could be performed
steps or sub-processes, including the exchange of separately. The processes are categorised into:
local currencies for foreign currencies, transfer of foreign exchange, cross-border settlement and
the currencies, as well as other supporting non- non-settlement processes.
settlement processes such as AML/CFT compliance.
As banks can now hold CBDCs in different
7.1 High-level cross-border payments currencies on the platform, they can perform the
flows foreign currency exchange independently of the
In a conventional cross-border payments flow, transfer, holding the foreign currency until such
multiple steps are often linked and performed as time as it is used for transfers. The process of
sequential and integral parts of the bigger exchanging local currency to foreign currency is
process. In designing the process flow on the explained in Section 7.4.
multi-CBDC platform, the steps were split into

Figure 14: Future payments flow

2a 2b
Sponsor bank performs checks Sponsor bank for Sponsor bank for Sponsor bank performs checks
on sender bank and approves/ sender bank recipient bank on recipient bank and approves/
rejects the transaction rejects the transaction

1 3
Sender bank Sender bank initiates When both approvals are provided, Recipient bank
transfer of FCY$1m transaction is recorded on ledger

The diagram describes how a cross-border Approval routing rules for Steps 2(a) and 2(b) are
transfer takes place between a sender and determined and set by the central bank issuing
recipient bank in different jurisdictions, using a the CBDC. In this example, the approvals are
currency from a third jurisdiction. The cross- routed to designated intermediaries as both
border transfer begins with Step 1, with the sender and recipient banks are not in its
initiation of a transaction by the sender bank, jurisdiction. If the recipient bank is in the same
which results in a debit or deduction of its CBDC jurisdiction, the routing rules would skip Step 2(b)
balance. After the transfer has been initiated, as no sponsoring bank is required.
sponsor banks for both sender and recipient
banks are notified in Steps 2(a) and 2(b) and A central bank could also disable the need for
would carry out non-settlement processes such Steps 2(a) and 2(b), allowing for a direct transfer
as AML/CFT and other control processes before from sender to recipient bank, without the need
they approve the transaction. Upon receiving the for any intermediaries. Such a payment flow
necessary approval from sponsor banks and would be akin to the direct CBDC model.
fulfilling the obligatory conditions of the smart
contract, the CBDCs are credited or added to the The technical choice of designing the payments
balances of the recipient bank in Step 3, which flow and the underlying technical architecture
marks completion of the transfer.

22 | Project Dunbar – International settlements using multi-CBDCs


based on the hybrid CBDC model enables the to the local regulations. Most non-settlement
technical flexibility to support different policy processes such as KYC, AML/CFT and foreign
choices. Central banks can amend the approval exchange controls are subject to the regulatory
routing rules to switch between the hybrid CBDC policies of the individual countries and fall within
and direct CBDC models. this category. This separation of processes enables
the clear delineation of jurisdictional boundaries
7.2 Cross-border settlement and adherence to regulatory policies of different
Transactions that take place “across borders” are jurisdictions, while allowing for the streamlining of
subject to the laws of the jurisdictions involved, settlement processes.
and hence to a higher level of complexity. To
reduce the overall complexity, there is an attempt Although differentiation between cross-
to differentiate between processes that take jurisdiction and single-jurisdiction processes is
place across jurisdictions and those processes commonly drawn between settlement and non-
that take place within a single jurisdiction, and to settlement processes, this may not always be the
minimise the scope of the former. case. One potential area for efficiency gains is in
enabling common processes for control processes
Cross-border settlement, or the movement of like AML/CFT. For example, sanctions screening
funds between the sending and receiving banks could be performed once only rather than
in different jurisdictions, is one that must occur repeatedly by each bank involved. However, this
across borders. Ensuring common treatment of would place such processes in the category of
such transactions would require common rules cross-jurisdiction processes and would likely
agreed by all participants. It is expected that the require the agreement of central banks and
settlement process will be governed and subject relevant regulatory agencies and/or the
to a common set of platform-level rules. harmonisation of legal and regulatory policies
However, there may still be domestic laws that across participating jurisdictions.
apply, such as laws relating to payment finality,
that may require harmonisation across the The settlement processes would be handled on
participating jurisdictions. This is an area that will the platform while the KYC-related processes
likely require more in-depth research. would still be handled off the platform, with
regulatory requirements performed by sponsor
7.3 Non-settlement processes banks subject to their respective jurisdictions.
Differentiating between settlement and non- There is a possibility that some processes may be
settlement processes allows non-settlement- embedded into smart contracts..
processes to be processed in country and subject

Figure 15: Processes in a cross-border payment flow

Other capabilities
Exchange control (that are not part of transaction processing)
Reporting (extraction monitoring
of information) (if applicable)
Central bank and regulators

Onboarding and setup

KYC/EDD KYC/EDD

Sponsor bank Risk mgmt Risk mgmt Sponsor bank for Integration
for sender bank recipient bank

FX
Processes embedded in smart contracts
Sanctions Payment and
Operations
screening settlement

Capabilities that are not required


Sender bank Exchange controls Recipient bank on platform
Reconciliation
Liquidity AML/CFT KYC/EDD Operations KYC/EDD Operations AML/CFT

Project Dunbar – International settlements using multi-CBDCs | 23


While settlement processes will be performed on the multi-CBDC platform (“on-platform”), many non-settlement
processes may continue to be performed in external systems (“off-platform”) due to their nature. One
consideration is the availability of data on-platform. For example, exchange controls based on annual limits can
be performed on-platform, while exchange controls based on verification of trade documents will require
connectivity to a source of trusted data. Certain processes are expected to be eliminated. As cross-border
payments are now completed in a single transaction with a single ledger update, and participants have visibility
of their transactions and statuses, there is no longer a need for multiple separate confirmations and
acknowledgements, and reconciliation across accounts.

Figure 16: Processes in to-be state


Dunbar capabilities Existing settlement On-platform Off-platform Eliminated
processes
2.1 Account setup Onboarding and
setup
3.2 Rules and compliance Exchange control

Sanction screening

AML/CFT

KYC/EDD

4.1 Integration/connectivity Integration


4.2.1 Position management, Payment and
4.2.6 Payments processing settlement
and 4.2.7 Settlement Such as funding, Such as charges (rate
charges (metering, table and billing,
usage reports), interim), and interest
account updates, calculation
settlement, and
warehousing
4.2.4 Risk management Risk management

4.2.5 Liquidity management Liquidity


4.2.6 Payments processing Operational
considerations
Such as confirmation
of receipt of funds
for initiator
FX

Depending on FX Depending on FX
model adopted model adopted

Reconciliation
4.3 Monitoring, reporting,
Reporting
control and notification

7.4 Foreign currency exchange obligations by the counterparties are fulfilled and
A foreign exchange (FX) transaction can be viewed discharged. An example of an FX trade is where a
as two parts: FX trade and FX settlement. buyer agrees to buy one unit of foreign currency
CBDC (FCY) from the seller with two units of local
FX trade is the agreement between two currency CBDCs (LCY). This implies an FX rate
counterparties to exchange one currency for (LCY/FCY) of 0.5. The settlement is when the buyer
another at a specified rate for a specified amount successfully sends two units of LCYs to the seller
on a specified date. FX settlement is when the and receives one unit of FCY in return.

24 | Project Dunbar – International settlements using multi-CBDCs


As part of the project, only FX settlement is in Beyond the scope of FX settlement, FX trading
scope, and FX trading was taken to be performed was a topic of interest for the central banks,
outside the platform using existing means. The particularly around understanding different FX
platform provided interfaces for settlement to trading mechanisms, how they might fit into a
take place within the platform on a real-time cross-border payments solution using CBDCs and
gross settlement basis. This was tested in the form the opportunities for efficiency gains. Given this
of an over-the-counter (OTC) transaction where potential to streamline the payments process
the FX trade has been agreed directly and further, performing both FX trading and
bilaterally between the transacting parties. settlement on the platform was of interest. One
specific area of interest is in automated market-
A common theme for FX settlement was the making (AMM), in which rates are determined and
elimination of settlement risk through the settled algorithmically.
provisioning of payment-versus-payment (PvP)
mechanisms on the platform. With the transfer of These areas relating to foreign currency exchange
both currencies taking place on a common have been of interest for project participants and
platform, PvP could be easily implemented as a the commercial banks, and could feature in future
form of conditional payment. The two linked phases of the project.
transactions would either succeed or fail together
as a set, eliminating the possibility of one
succeeding while the other failed, which could
lead to the loss of principal by one of the parties.

Figure 17: FX models

Model Who are the How are FX rates How is FX trade Connectivity
counterparties determined settled mechanism
A third-party, such as Matching of buy/sell Transfers between Integration with the
an exchange operator orders on the third- the participants and third-party platform for
party platform third-party exchange settlement on multi-

FX exchange
(and clearing) operator/clearing CBDC platform
house on multi-CBDC
platform

Bilaterally among the Agreed bilaterally Transfers between the APIs for PvP settlement
participants between participants participants on multi- to ensure transfers
CBDC platform are linked through

OTC between
participants unique identifiers, and
either complete or fail
together

Participants who Set by appointed Foreign currency FX bid-ask process


are designated as market-maker(s) exchange and incorporated into
market-maker(s) for the quoting bid-ask rates settlement could payment process flow

Designated
market-maker currency be part of payment
flow on multi-CBDC
platform

Liquidity pools, with Algorithmically Foreign currency Automated


liquidity contributed exchange and market-making
by participants settlement performed protocols deployed

Automated
market-making on multi-CBDC on multi-CBDC
platform platform

Project Dunbar – International settlements using multi-CBDCs | 25


Technology 08
In this phase of Project Dunbar, prototypes were 8.1 Infrastructure
developed based on the requirements and designs
proposed in the design workstreams. The 8.1.1 Cloud infrastructure
prototypes were developed by the technology Both prototypes were developed in a cloud
providers R3 and Partior, using the distributed infrastructure, with R3’s deployed on Azure
ledger technologies of Corda and Quorum cloud and Partior’s deployed on Amazon Web
respectively. Services (AWS).

Both R3 and Partior have done extensive work on Cloud services were ideal for deployment and
digital currency projects and were able to leverage testing of the prototypes, due to their elastic
platform functionalities developed previously. The nature that allows resources to be ramped up or
CBDC Accelerator by R3 has been used and tested down, or even suspended, depending on usage
by multiple central banks over the last few years, needs.
with a comprehensive feature set developed which
is based on the requirements of central banks. The For ease of experimentation, a single cloud
Partior Sandbox is developed by Partior, which has account was used for each set of deployments. In
since built a live platform for multi-currency a live implementation, it is likely that participants
clearing in Singapore. The Partior platform is being would manage their own nodes, either using
used for USD and SGD payments (with additional on-premises or cloud infrastructure.
currencies and corridors going live in 2022).
8.1.2 Network components and
As such, many of the basic features of a wholesale services
digital currency platform are available out-of-the- A typical network for both prototypes would
box (OOTB). This allows the project to focus on a consist primarily of nodes, which are hosted by
targeted scope of proving the technical feasibility participants. Both prototypes are built on a
of transacting on a multi-CBDC platform, while permissioned network, with access controlled by
leveraging relevant existing functionalities and the network operator.
user interfaces.
A Corda network is made up of nodes, each of
This section will describe the infrastructure, which runs an instance of Corda and one or more
application and data architecture of the two CorDapps. Communication between nodes is
prototype platforms, with additional technical point-to-point and does not rely on global
details included in the appendix. As the two broadcasts. Each node has a certificate that maps
platforms were built on different distributed ledger its network identity to a real-world legal identity.
technologies, the infrastructure is markedly A Corda network also includes other services such
different. On the other hand, the applications were as a network map service, which maps each well
built to specifications from the design workstream, known node identity to an IP address; an identity
and hence operate in a similar manner. manager service, which acts as the gatekeeper to
the network; and a signing service, which acts as
a bridge between the main network map and
identity manager services, and the public key
infrastructure (PKI) and hardware security module
(HSM) infrastructure. Additionally, a notary
service provides uniqueness consensus by

26 | Project Dunbar – International settlements using multi-CBDCs


attesting that, for a given transaction, it has not A Quorum node is a minimal fork of Go
already signed other transactions that consume Ethereum, providing privacy, new consensus
any of the proposed transaction’s input states, mechanisms, network-permissioning and higher
and an oracle service links the Corda network to throughput. It consists of the core Quorum
the outside world. platform, dApps, that act as a middle layer
between conventional systems to the DLT and
The Quorum network used by Partior consists serves as a translator to convert the user’s API
only of Quorum nodes, of which there are two into the required smart contract format, and
types. Participant nodes communicate within Tessera, which is a stateless Java application
the network to share transaction details for responsible for the encryption/decryption of
processing. Every node in a decentralised system private transaction data and off-chain private
has a copy of the blockchain. Validator nodes messaging. Tessera consists of the transaction
are responsible for verifying transactions on a manager – which allows access to encrypted
blockchain. Once verified, transactions are added transaction data for private transactions, and
to the distributed ledger. The central banks’ which also manages the local data store and
nodes are configured to be the validator nodes in communications with other transaction managers
this setup. Validator nodes are connected to each – and the Enclave, which is responsible for
other in a point-to-point manner. Participant private key management and for the encryption
nodes are non-validating nodes and are not and decryption of private transaction data.
required to be interconnected to all nodes in
the network.

8.1.3 Nodes
Nodes are key components of a DLT network. A
node usually consists of a platform core that
manages communications with other nodes, a
distributed application that runs the logic of the
smart contracts and an internal database for data
storage. Typically, there are multiple nodes on a
network, with each hosted individually by
participants. Integration with external systems,
such as integration with central banks’ systems
for the pledging of assets, is usually performed
at the node level.

A Corda node consists of the Corda Core,


CorDapps (Corda distributed applications),
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. A CorDapp is made of these
components: states, which define the facts over
which agreement is reached; contracts, which
define what constitutes a valid ledger update; a
legal prose document, which states the rules
governing the evolution of the state over time in
a way that is compatible with traditional legal
systems; and flows, which define a routine for
the node to run, usually to update the ledger.

Project Dunbar – International settlements using multi-CBDCs | 27


8.1.4 Network architecture commercial banks, global commercial banks and
The Corda network implemented for Project the central bank that represents the current
Dunbar is made up of four logically separated real-world scenario. Participants on the platform
sovereign networks, each representing a country. will each host a node, and central banks will each
This enables each domestic sovereign network host a notary service that is responsible for all
to be in complete control of its monetary transactions in their currency. Network services
sovereignty, as well as the design and such as network map, identity manager and
implementation of its own network membership signing services will be operated by the
criteria, and governance, policies, regulations network operator.
and compliance.
The Partior network implemented for Project
A regional platform like this would require a Dunbar consists of four distinct networks logically
network operator to perform activities such as separated by currencies, with each central bank in
day-to-day management of the network, control of its own network. A domestic bank that is
managing technical policies around the overall not a host may engage in transactions on the
upgrade schedule of the application, its Dunbar platform by initiating a transaction with its
infrastructure and maintenance, and network sponsor bank, after which the transaction flows on
services that control admission of participants to to the multi-CBDC platform.
the Dunbar network.
The decision on who should host validator and
Figure 20 depicts the multi-CBDC network as a participant nodes depends on several factors,
single Corda private network, with the four including performance, scalability, costs, resilience
domestic sovereign networks represented in and security. It is likely that validator nodes will be
circles. Each sovereign network is a combination hosted by central banks, and that participant
of selected commercial banks, regional nodes will be hosted by commercial banks.

Figure 18: Dunbar network in Corda

Dunbar network Legend

Selected
commercial
bank

Regional
commercial
bank
Corda Network Services

Austral

Global
commercial
bank
ia
Singap

Malays

Notary
Corda Oracle
Services
ore

ia

Network
map

Identity
service

Signer
S o u t h A f ri c a service

28 | Project Dunbar – International settlements using multi-CBDCs


Figure 19: Domestic transfer

SGD CBDC

Bank
A
AUD CBDC
Bank SGD
C CBDC Issuer Bank
... E

AUD
Bank ...
A
Bank
ZAR CBDC B CBDC Issuer

Onb
ar Bank
ds Bank D

o
Pro v
Bank B
J Bank
MYR CBDC
ZAR

id es a p pro
... H

CBDC Issuer a
Bank
Payment

va
F

MYR
Bank

l
C Smart Contract
... TXN ID:001
Bank
I CBDC Issuer
Std Conditions..

Bank REG Condition 1..


G

8.2 Applications For example, issuance of CBDCs can only be


Applications contain the logic for processes performed by the appropriate central bank.
performed on the platforms and are developed as
CorDapps using Java or Kotlin programming Such rules can also be applied at the currency and
languages on Corda, and as dApps using the jurisdiction levels. Central banks can apply their
Solidity programming language on Quorum. customised rules by developing and deploying
smart contracts that are used by participating
As the applications were developed based on the banks for transactions. An example of such
specifications from the design workstream, they currency-level rules includes the approval routing
are similar on both platforms. Some additional rules for sponsoring banks, where a transaction
functionalities, such as for issuance, transfer and initiated by a non-resident bank will be routed to
redemption of CBDCs – as well as balance enquiry its appointed sponsoring banks for approval.
were available OOTB, and were used for testing
purposes. Approval steps for the transactions were
simulated as manual approvals for the purposes of
testing and demos. These steps could potentially
be automated if integrated into existing systems.

One of the specific requirements for the project


was on membership types, and this was developed
based on the participants and stakeholders defined
in the design workstream, with different privileges
defined for different roles. Controls were built to
apply rules and ensure that only parties with the
appropriate privileges can perform certain roles.

Project Dunbar – International settlements using multi-CBDCs | 29


Summary and next steps 09
9.1 Summary The design approaches to solving the three
Project Dunbar is one of the first technical challenges were validated through the development
experiments in the nascent space of multi-CBDCs. of technical prototypes that demonstrated
As an exploratory project, the focus was to shine a practicable solutions. In that regard, this initial
light into the unknown and show that there is a phase of Project Dunbar has successfully achieved
viable path forward. The project focused on its aim of proving that the concept of multi-CBDCs
developing design approaches to address three was technically viable. This is an important step, but
critical challenges to the development of a shared still just a first step into the space.
multi-CBDC platform:
While prototypes have been successfully
Access – enabling non-resident banks’ access to developed and tested in the project, they were
CBDCs. Prototypes were developed to flexibly built based on a preliminary design, with the best
support both “hybrid” as well as “direct” CBDC possible set of assumptions known to the team
access models. In jurisdictions where the regulatory while doing the project. As the project progresses,
frameworks allow direct access to CBDC by non- new information and better understanding resulted
resident banks, approval routing to “sponsoring” in continuous refinement of the assumptions.
banks could be disabled to move from a “hybrid” Previously unknown unknowns were uncovered,
to “direct” CBDC access model. enabling a clearer understanding of the challenges
that need to be solved. Some unknowns also
Jurisdictional boundaries – differentiating became knowns, as challenges were better
settlement and non-settlement processes. understood and subsequently solved. However,
Differentiating between settlement and non- even at the completion of this first phase, there are
settlement processes in cross-border payments still more unknowns than knowns. Assumptions
allows non-settlement processes to be processed will continue to be challenged as new information
off platform and in country, subject to local arises, and designs and prototypes will continue
regulations. This separation would enable the clear to improve.
delineation of jurisdictional boundaries, adherence
to regulatory policies of different jurisdictions and 9.2 Areas for further exploration
streamlining of settlement processes. As an exploratory project with a limited timeline,
Project Dunbar ended with more questions than
Governance – optimising universality and answers, and more questions than before it
autonomy. A shared platform implies a level of started. This is to be expected of an exploratory
universality. Certain features and capabilities of the project, which focuses as much on identifying
platform are universal and available to all problems as it does on solving them.
participants. Rules and policies are applied
universally and fairly across participants. To enable The areas for further exploration can be broadly
this universality, governance structures and categorised into three themes: policy, business
decision-making powers must be designed to and technology. While the themes are useful for
ensure that a diverse group of stakeholders are grouping together related areas, many of the
able to be represented, and collective decisions are problems or questions cut across multiple
able to be made fairly and equitably. Central banks themes. For example, access for non-resident
are also granted autonomy within the boundaries banks may be considered primarily a policy
and parameters of a universal platform-level question, while the perspective of the sponsoring
framework, such as in the application of arrangements between banks would take on a
jurisdiction- and currency-level rules. business and commercial lens. Also, solutions

30 | Project Dunbar – International settlements using multi-CBDCs


could be devised from a different perspective Extending access beyond banks – while the
to the problem – for example, a policy challenge project focused on commercial banks as
could be solved via business or technological participants of the network, it would also be
means. Very often, advances in technological possible for non-bank financial institutions
capabilities create new policy options, allowing (NBFIs) such as payment services providers and
for policy concerns to be better addressed, or exchanges to transact directly on the platform.
break traditional trade-offs and achieve a The policy question of whether to extend access
superior solution that fulfils previously beyond banks should be considered. Within the
conflicting needs. participating central banks, some already allow
NBFIs to access their real-time gross settlement
Policy systems. Widening access to NBFIs may improve
competition, resulting in lower fees for
Trade-offs in access models – one recurring consumers but may pose risks. There is also a
debate relates to the comparison of access technical consideration of scalability and
models, with the “direct” CBDC access model performance in widening the number of
viewed as difficult to implement due to the need participants directly connecting to the network;
for harmonisation of and changes in regulations, this is discussed below under Technology.
and for mutual reliance on other central banks or
regulators, and the “hybrid” CBDC access model Impact of AML/CFT regulation – while the
was viewed as inefficient. More thorough project took into consideration the need to
analysis, including potential refinements to the comply with local AML/CFT regulations, an
access models, should be conducted to validate in-depth investigation into how AML/CFT
this view. For example, while regulations are regulations relate to CBDC, and cross-border
often different across jurisdictions, further study transactions using CBDC more specifically, was
is required to understand the specific differences not within scope, and is an area that would
and their consequences, and the actual require further exploration.
regulatory changes that might be required to
implement a “direct” access model. Also, there Regulatory changes – implementing a new
are likely to be differences in regulatory multi-CBDC solution may require regulatory
approaches across regions, and thus analysis changes. This needs to be analysed in greater
could be done at a regional level or within a detail, while also considering the potential use of
logical grouping of central banks. The technological solutions to address differences in
inefficiencies of needing intermediaries for policies – for example, a rules engine could
control processes in a “hybrid” access model should ensure compliance with the different regulatory
be analysed in the context that it may be possible requirements thereby negating the need for
for some of these processes to be performed in an complete harmonisation across the jurisdictions.
automated and straight through manner.
Business
Enabling common shared control processes
on-platform – one potential benefit of a shared Commercial models for “sponsoring” bank
platform is in enabling shared processes to be arrangements – a “hybrid” CBDC access model
performed on the platform. For example, would require commercial banks to take on
sanctions screening could be conducted just “sponsoring” roles and perform certain control
once in the cross-border payments process, processes on the sponsored banks. Banks
instead of at each bank. Such consolidation of typically perform such roles as part of the
processes may bring about system-level correspondent banking relationship, accruing
efficiency gains but may be difficult to implement benefits through holding foreign currency
due to the need for mutual reliance and shared deposits and charging fees for the transactions.
liability amongst participants. Improved visibility As they would no longer benefit from holding the
and traceability through technology may help to funds of transacting banks in a multi-CBDC
mitigate these risks. platform, new commercial models will need to be
explored. Various possibilities have been

Project Dunbar – International settlements using multi-CBDCs | 31


identified, such as reciprocal arrangements where platform. However, the platform would be only
banks take on a sponsoring role for each other one part of the end-to-end payment flow; it will
for different CBDCs, obligations imposed as likely also need to connect with central banks’
conditions of access where banks are required to systems for the pledging of assets backing the
sponsor a specified number of participants and issuance of CBDCs, and with commercial banks’
fees where sponsored banks are charged on a systems for customer transactions. Furthermore,
commercial basis. These will need to be further a payment is often only one part of a bigger
evaluated with industry participants to determine transaction. For example, it could be a payment
the commercial viability. in exchange for securities, or payment for goods
in an international trade. Such use cases could
Commercial use cases and applications – benefit from connecting directly to the multi-
another commercial perspective relates to the CBDC platform for automation of the end-to-end
use cases of the multi-CBDC platform. Aside from transaction, allowing the automated release of
cross-border payments, there may be interest in funds when goods are received. Further
other types of services that could be provided by development and testing of technical connectivity
the platform. Examples include issuance and and integration with external systems will be
transacting of other digital assets, conditional important and could be explored, together with
payments, and integration with other platforms the business perspective of supporting other
and applications to support use cases such as commercial use cases and applications.
trade finance.
Standards and interoperability – a multi-CBDC
Quantitative study on efficiency gains and platform will need to connect with other external
cost-savings – while the project highlighted the systems. Furthermore, to enable global payments
potential benefits of a multi-CBDC platform, across all jurisdictions and currencies, a regional
these were focused on qualitative aspects and multi-CBDC platform will need to connect with
were at a fairly high level. Detailed analysis and other national or regional multi-CBDC platforms.
quantification of the benefits would be important Interoperability, or the ability for these systems to
in performing a cost-benefit analysis and building communicate with each other easily and
a business case for future implementation. seamlessly, will be crucial for global connectivity.
Standards, or a common language and set of
Liquidity challenges of real-time settlement – expectations, will be key to enabling
real-time settlement requires transacting parties interoperability between these systems.
to possess, at the point of the transaction, the
required funds to fulfil their obligations. The high Technical challenges and trade-offs – in
liquidity requirements are costly for commercial designing a system, there are often technical
banks and may lead to slow adoption. Seamless trade-offs that need to be considered. Such
on-/off-ramping of funds may alleviate part of trade-offs may not be obvious in an experiment
the problem by allowing banks to easily manage due to the limited scope. For example, the project
their liquidity positions. Liquidity-saving simulated only five commercial banks per
mechanisms, such as netting, could also reduce jurisdiction for technical testing. Increasing this
liquidity needs. Further exploration is required to number could result in uncovering potential
understand how banks will likely use and transact technical challenges of scalability. Tiering of
on a multi-CBDC platform, the resulting system access is a possible option for resolving
challenges in liquidity requirements, and how that. While some potential challenges were
they can be alleviated. reviewed in the design phase, a thorough review
can only be performed through more
Technology comprehensive technical testing.

Integration with peripheral services and


features – the current phase of the project
focused on transactions within a multi-CBDC

32 | Project Dunbar – International settlements using multi-CBDCs


Design considerations: performance, scalability and privacy

Should other commercial


banks (outside five selected banks)
host nodes?

Option #1 Option #2
Hosts nodes Does not host nodes
• All local commercial banks are direct participants. • Some local commercial banks are indirect
• Large number of nodes may affect performance participants.
and scalability of network. • Accessing through other banks’ nodes may affect
• Approximately 400 nodes required for four privacy for indirect participants.
countries. As a reference, SWIFT links 11,000 FIs • Multi-tenancy solutions with improved
across 200 countries. technological controls may improve privacy.

Design considerations and trade-offs:

Performance Scalability Privacy

One design consideration was about banks that are allowed to host nodes and connect directly to the network, as
discussed in Section 8. The number of banks ranges from hundreds to thousands across jurisdictions. Besides the
business consideration of infrastructure costs, there is also a technical consideration of the optimum number of nodes
that can be supported on the network. Scalability and performance may be affected if all local commercial banks host
nodes as direct participants.
One potential solution to this scalability problem is to allow only central banks and selected commercial banks to host
nodes, with other local commercial banks connecting as indirect participants through these node hosts. However, this may
affect privacy for indirect participants as there is a possibility that a node host could view transactions passing through the
node despite the security measures implemented. Such technical considerations will need to be further evaluated, including
through scalability testing and security assessments.

9.3 Next steps high level of production fidelity. While still an


The vision and broader objective of Project experiment, this could be viewed as production-
Dunbar is enabling a global network of ready. This would entail the development of a
connected CBDC platforms and interoperable detailed platform rulebook, and reviewing legal
CBDCs. An ideal state and the epitome of and regulatory frameworks across participating
efficient cross-border payments would be a jurisdictions. It would also require the formation
single global settlement platform that connects of governance committees for the project and
all central banks and commercial banks. Given these could potentially transit into governance
the complexity of having multiple central banks committees for a future live regional platform.
sharing critical financial infrastructures and Finally, technical development and testing at a
the unique requirements of each jurisdiction, large-scale industry level would be required. Such
a common multi-CBDC platform may be more experiments could be conducted at a regional
likely to be implemented as a series of regional level within existing and established regional
platforms rather than as a single global platform. groupings.
This naturally leads to considerations around how
it may be possible to connect these individual Once such multi-CBDC projects have been
regional platforms to realise synergies such that established on a regional level, the next step
participants transact directly across jurisdictions, would be to develop mechanisms to ensure
including via the lower-volume corridors. connectivity between these multi-CBDC
projects and experiments. Other than technical
In the roadmap to achieving the vision of Project connectivity, there will also be questions around
Dunbar, the next major step is developing and governance and policies that will need to be
testing a regional multi-CBDC platform to a addressed.

Project Dunbar – International settlements using multi-CBDCs | 33


Acknowledgements
Project Steering Committee
Organisation Representative
BIS Innovation Hub Andrew McCormack
Reserve Bank of Australia Chris Thompson
Bank Negara Malaysia Tay Gim Soon
Monetary Authority of Singapore Sopnendu Mohanty
South African Reserve Bank Herco Steyn

Project Management Team


Name Organisation Name Organisation
Toh Wee Kee BIS Innovation Hub (Project Lead) Yip Kah Kit Bank Negara Malaysia
Benjamin Lee BIS Innovation Hub Alan Lim Monetary Authority of Singapore
Cameron Dark Reserve Bank of Australia Gerhard van Deventer South African Reserve Bank

Central banks
Name Organisation Name Organisation
John Kenyon Reserve Bank of Australia Alvinder Singh Monetary Authority of Singapore
James MacNaughton Reserve Bank of Australia Jonathan Chan Monetary Authority of Singapore
Riaan Louw Reserve Bank of Australia Vincent Pek Monetary Authority of Singapore
Adam Gorajek Reserve Bank of Australia Margaret Olivier South African Reserve Bank
Norasyikin binti Mohamad Razali Bank Negara Malaysia Annah Masoga South African Reserve Bank
Chai Yi Wei Bank Negara Malaysia Patrick Johnson South African Reserve Bank
Sharmaine Nadirah binti Roslan Bank Negara Malaysia Hein Timoti South African Reserve Bank
Zahilah binti Ismail Bank Negara Malaysia Pearl Malumane South African Reserve Bank
Charmaine Tew Shu Yi Bank Negara Malaysia Larry Cooke South African Reserve Bank
Ng Yin Shia Bank Negara Malaysia Jan Mohotsi South African Reserve Bank
Dr. Normasita binti Sidek Bank Negara Malaysia Darren Chamberlain South African Reserve Bank
Chew Ming Heong Bank Negara Malaysia Lyle Horsley South African Reserve Bank
Pham Khai Uy Banque de France Anikó Szombati Magyar Nemzeti Bank
Anne-Catherine Bohnert Banque de France Péter Fáykiss Magyar Nemzeti Bank

Technology and design partners


Name Organisation Name Organisation
James Gan Accenture Jason Thompson Partior
William Lim Accenture Dmitry Avramenko Partior
Desiree Teh Accenture Ng Peng Khim DBS Bank
Chan Chian Lyn Accenture Zhenqian Tay DBS Bank
Willy Lim R3 Yeoh Han Long DBS Bank
Pallavi Thakur R3 Lee Muh Hwa J.P. Morgan
Shobana Kandaswamy R3 Sai Valiveti J.P. Morgan
Indra Suppiah R3 Claire Ng J.P. Morgan
Stefano Franz R3 Pradyumna Agrawal Temasek
Arnab Chatterjee R3 Laura Loh Temasek

We acknowledge and appreciate the support of the following organisations for participating in project workshops: Absa, AMBank, ANZ, Bank of New
Zealand, CIMB, Citi, Commonwealth Bank of Australia, FirstRand, Goldman Sachs, Hong Leong Bank, HSBC, Investec, Macquarie, Maybank, National
Australia Bank, Standard Bank, Standard Chartered Bank, United Overseas Bank, and Westpac.

34 | Project Dunbar – International settlements using multi-CBDCs


Appendix
1.1 Dunbar capabilities and considerations

Governance
1. Participants and stakeholders
1.1 Commercial 1.2 Central banks 1.3 Regulators 1.4 Operators 1.5 Corporates
banks

2. Onboarding of members
2.1 Account setup 2.2 End-to-end onboarding process

3. Legislation, oversight, rules and policy


3.2 Legislation and 3.3 Rules and
3.1 Governance structure 3.4 Policy
regulations compliance

Processes
4. Processing, clearing and settlement service

4.2 Interbank 4.3 Monitoring,


4.1 Integration/ 4.5 System
reporting, control 4.4 User interface
connectivity payments administration
and notification

Technology
5. Technology and Solution Architecture
5.1 Application 5.2 Data architecture 5.3 Infrastructure 5.4 Security
architecture

limited discussion on the capability during the project

1. Participants and stakeholders


1.1 Commercial banks Commercial banks are entities which offer financial services to their clients, including
facilitating cross-border transactions. A local commercial bank must be licensed to
operate within the local jurisdiction.

1.2 Central banks Central banks are parties that manage and execute their monetary policy and
objectives. They may be operators of their own payments systems (see Section 2.4).
Central banks oversee the issuance, destruction and management of their own central
bank digital currency (CBDC).

1.3 Regulators Regulators are the regulatory authority for all financial institutions within their local
jurisdiction, and activities include supervisory and regulatory policy development.
There may be multiple different regulators within a jurisdiction – ie for prudential
oversight and AML.

1.4 Operators An operator is the central party that maintains the system and that coordinates
changes or upgrades from a technical standpoint.

1.5 Corporates Corporates are the customers of banks. In wholesale inter-bank settlement, they
transact only through the banks and not directly on the system.

Project Dunbar – International settlements using multi-CBDCs | 35


1.1 Commercial banks
1.1.1 Selected commercial These are a limited number of large commercial banks of good standing that have
banks been identified to be key participants of the scheme. These participants would
be provided with additional privileges and may be required to comply with more
stringent requirements.

1.1.2 Other commercial This refers to commercial banks that operate via a selected commercial bank. They
banks may have a limited number of privileges on the system, and are typically subject to
less stringent requirements.

1.1.3 Non-resident banks This refers to banks in other jurisdictions, and not in the local jurisdiction.

2. Onboarding of members
2.1 Account setup Set up participant accounts in the system in adherence with system’s principles of
account structure.

2.2 End-to-end Onboarding steps required for new members to participate in the scheme.
onboarding process

2.2. End-to-end onboarding process


2.2.1 Customer Support changes to a participant's settings or parameters with respect to the system,
configuration and based on each participant’s regulatory or specialised operating requirements.

2.2.2 Technical integration Integrate a new participant into the system or remove a participant from the system
with system based on defined guidelines and a checklist. This includes industry testing and
certification processes.
Eg a new participant must meet minimum standards to join the network, and must
meet local jurisdiction requirements to operate in the jurisdiction.
Eg a participant being offboarded needs to redeem all CBDCs in its wallet.

3. Legislation, oversight, rules and policy


3.1 Legislation and Ensure that the payments FMI complies with its obligations arising from legislation
regulations and any other regulatory obligations.

3.2 Rules and Ensure the payments FMI has defined rules aligned with legislation, regulatory
compliance requirements and the payments FMI’s policies, and that both the payments FMI and
participants comply with all required legislation, regulations and rules.

3.3 Policy Define principles, guidelines and courses of action for the payments FMI to achieve its
statutory objectives. Policy may be crafted into rules for implementation.

4. Processing, clearing and settlement services


4.1 Integration/ Standards and patterns for integration and connectivity of the Dunbar platform with
connectivity other systems. This may include payments systems for on- and off-ramping of CBDCs.

4.2 Interbank payments Core system functionalities that facilitate the transfer of funds between members in
various currencies.

4.3 Monitoring, Tools to allow participants to monitor their systems performance and payments
reporting, control activity, and enable alerting, reporting and management of user notifications.
and notification

4.4 User interface Front-end(s) for users to interact with the application. This includes the ability to
view and access payments data (position, history, search, collaterals), print, perform
reporting, login/logoff, manage permissions and block users, etc.

4.5 System Tools that allow the operators to change system configurations, enable rules and
administration procedures for creating and managing user access, and enforce security management.

36 | Project Dunbar – International settlements using multi-CBDCs


4.2 Interbank payments
4.2.1 Position Calculate and manage holdings in currencies that are supported by the system.
management

4.2.2 Issuance/redemption Issuance refers to the process of participants exchanging or pledging assets for central
bank digital currencies (CBDCs).
Redemption is the process of participants exchanging CBDCs with the issuing central
bank to redeem the assets backing the CBDC.

4.2.3 Default management Calculate and manage key metrics for default management (eg collateral pool and
participants' contributions, survivor's contribution to cover any default shortfall).
FUTURE PHASES: while the current phase takes the assumption of gross settlement, a
future iteration could consider handling defaults under a net settlement model.

4.2.4 Risk management Operationalise the system’s risk model through processes and tools (eg maximum
values on limits, checks against pre-defined thresholds, access control) to support a
risk framework covering credit/counterparty risk, settlement risk, AML/CFT, as well as
system risk.

4.2.5 Liquidity Processes and tools to: (i) allow participants to use liquidity pools to settle all payment
management priority, (ii) allocate liquidity for specific payment priority, (iii) reserve liquidity for
specific payments, (iv) and monitor liquidity.

4.2.6 Payments processing Core processes of payments including queues, message types and formats, message-
routing, viewing and tracking.

4.2.7 Settlement Manages selected systems processes, including the timing and cycles of settlements
and the debit and credit of participants’ CBDC wallets.

1.2 Prototype developed by R3 on Figure 20: Corda node anatomy


Corda platform

1.2.1 R3 Technical Architecture Corda Node


Built for the needs of highly regulated
institutions, Corda is an evolved distributed
CorDapp
ledger technology (DLT) platform that delivers (distributed application)
privacy, scalability and security, making it widely
used within financial services and beyond. R3’s
Corda is a scalable, permissioned peer-to-peer
(P2P) DLT platform, which differs from others
that operate based on the concept of global- Corda core
broadcast. This enables Corda applications to
foster and deliver digital trust between parties in
regulated markets.

At the heart of the platform is a Corda Node. It


uses Java Virtual Machine (JVM) run-time with Corda vault
a unique network identity that runs the Corda (database)
software components as follows:

Project Dunbar – International settlements using multi-CBDCs | 37


CorDapps (Corda distributed applications) – Corda vault – A Corda vault is the component
CorDapps are distributed applications that run that stores on-ledger shared facts for a node.
on the Corda platform. The goal of a CorDapp is Each node on the network maintains a vault,
to allow nodes to reach agreement on updates which is a database where it tracks all of the
to the ledger. They achieve this goal by defining current and historic states about which it is aware,
flows that Corda node-owners can invoke over a and which it considers to be relevant to itself.
remote procedure call (RPC). An RPC is the event
that takes place when a computer programme 1.2.1.1 CorDapp anatomy
causes a procedure (or a subroutine) to execute The CorDapp is made of several components as
in a different address space (commonly on depicted in the diagram below.
another computer on a shared network), which is
coded as if it were a normal (or local) procedure
call, without the programmer explicitly coding
the details for the remote interaction.⁹

Figure 21: CorDapp anatomy

CorDapp anatomy

Use Verify
States Contract code Contracts Legal prose Flows
reference reference

Smart contract code Legal prose


(Java/Kotlin) (Link to legal document)

States – These define the facts over which written in Java or Kotlin. Contract execution is
agreement is reached. States represent on- deterministic, and transaction acceptance is
ledger facts, and are evolved by marking the based on the transaction’s contents alone.
current state as historic and creating an updated
state. Each node has a vault where it stores any Legal prose – Each contract also refers to a
relevant states to itself. A state is an immutable legal prose document that states the rules
object representing a fact known by one or governing the evolution of the state over time
more Corda nodes at a specific point in time. in a way that is compatible with traditional
States can contain arbitrary data, allowing them legal systems. This document can be relied
to represent facts of any kind (eg stocks, bonds, upon in the case of legal disputes.
loans, KYC data and identity information).
Flows – Corda’s “flow framework” is a unique
Contracts – These define what constitutes a feature that enables moving of data around
valid ledger update. In Corda, contracts are the network just-in-time, on-demand and on
the mechanism used to impose constraints a point-to-point basis. These flows define a
on how states can evolve. Contracts in Corda routine for the node to run, usually to update
are quite different to the smart contracts of the ledger. They automate the process of
other distributed ledger platforms. They are agreeing ledger updates. Communication
not stateful objects representing the current between nodes only occurs in the context of
state of the world. Instead, like a real-world these flows, and is point-to-point. Built-in
contract, they simply impose rules on what flows are provided to automate common tasks.
kinds of transactions are allowed. Contracts are

⁹ See www.corda.net/blog/corda-rpc-reconnecting-client/#

38 | Project Dunbar – International settlements using multi-CBDCs


1.2.1.2 Corda networks IP addresses are used for messaging between
A Corda network is made up of nodes, each nodes.
of which runs an instance of Corda and one or
more CorDapps. Communication between nodes Corda nodes discover each other via a network
is point-to-point and does not rely on global map service. You can think of this service as a
broadcasts. phone book, which publishes a list of peer nodes
that includes metadata about who they are and
Each node has a certificate that maps its network what services they can offer.
identity to a real-world legal identity.
The identity manager service acts as the
The network is permissioned, with access gatekeeper to the network. It is formed of two
requiring a certificate from the network operator. components:

1.2.1.3 Basic Corda network • Issuance: Responsible for issuing certificates to


architecture components new nodes wanting to join the network.
A Corda network is a peer-to-peer network
of nodes. Each node represents a legal entity, • Revocation: (Optional) Responsible for
and each runs the Corda software (an instance handling certificate revocation requests as well
of Corda and one or more Corda applications, as hosting the certificate revocation list (CRL)
known as CorDapps). All communication endpoints that are used by participants to
between nodes is point-to-point and encrypted check a certificate’s revocation status.
using transport layer security (TLS). This means
that data is shared only on a need-to-know The signing service acts as a bridge between the
basis. There are no global broadcasts. All of main network map and identity manager services,
the nodes in the network have the potential and the public key infrastructure (PKI) and
to communicate with other nodes. Why do we hardware security module (HSM) infrastructure.
say “potential” to communicate? Because the This enables a network operator to verify and
connections on the graph do not have to be sign incoming requests and changes to the
persistent. On the networking level, Corda uses network. Large and important changes to the
persistent queues, but, as with email, if your network should go through a series of checks
recipient is offline, your messages will wait in an before being approved and signed, ideally with a
outbound queue until the recipient comes online. network operator manually verifying and signing
new certificate signing requests (CSRs), CRLs, and
Corda nodes network parameter changes. The signing service
provides this behaviour, with HSM integration
A node uses JVM run-time with a unique network enabling the signing of any particular data to
identity running the Corda software. Nodes require authentication from multiple users.
communicate with each other using Advanced
Message Queueing Protocol (AMQP 1.0) over TLS. Notary service

Network services Notary clusters prevent “double-spends”. Corda


employs notaries as an alternative to proof-of-
Each node has a single well-known identity. work. A notary cluster is a network service that
The node’s identity is used to represent the node provides uniqueness consensus by attesting
in transactions; for example, if the node were that, for a given transaction, it has not already
involved in a transaction to purchase an asset. signed other transactions that consume any of
the proposed transaction’s input states.
The network map service maps each well-
known node identity to an IP address. These

Project Dunbar – International settlements using multi-CBDCs | 39


Upon being asked to notarise a transaction, a Corda addresses this issue using oracles. Oracles
notary cluster will either: are network services that, upon request, provide
commands that encapsulate a specific fact (eg
• Sign the transaction if it has not already signed the exchange rate at time x) and list the oracle as
other transactions consuming any of the a required signer.
proposed transaction’s input states.
If a node wishes to use a given fact in a
• Reject the transaction and flag that a double- transaction, it requests a command asserting
spend attempt has occurred. this fact from the oracle. If the oracle considers
the fact to be true, it sends back the required
In doing so, the notary cluster provides the point command. The node then includes the command
of finality in the system. Until the notary cluster’s in its transaction, and the oracle will sign the
signature is obtained, parties cannot be sure transaction to assert that the fact is true.
that an equally valid but conflicting transaction
will not be regarded as the “valid” attempt to For privacy purposes, the oracle does not need
spend a given input state. However, after the to have access to every part of the transaction,
notary cluster’s signature is obtained, we can be and the only information it needs to see is the
sure that the proposed transaction’s input states embedded – related to this oracle – command(s).
have not already been consumed by a prior We should also provide guarantees that all of
transaction. Hence, notarisation is the point of the commands requiring a signature from this
finality in the system. oracle should be visible to the oracle entity, but
not to the rest. To achieve this, we use filtered
Every state has an appointed notary cluster, and transactions in which the transaction proposer(s)
a notary cluster will only notarise a transaction uses a nested Merkle tree approach to “tear off”
if it is the appointed notary cluster of all the the unrelated parts of the transaction.
transaction’s input states.

Oracle service

Oracles in Corda are Corda nodes running Corda


services which link the Corda network to the
outside world. They are not generally participants
in a business transaction but provide network
services. A node in need of any data served
by the oracle service would request the oracle
node to provide signed external data, which the
transacting node could then use in a business
transaction.

In many cases, a transaction’s contractual validity


depends on some external piece of data, such as
the current exchange rate. However, if we were
to let each participant evaluate the transaction’s
validity based on their own view of the current
exchange rate, the contract’s execution would be
non-deterministic: some signers would consider
the transaction valid, while others would consider
it invalid. As a result, disagreements would arise
over the true state of the ledger.

40 | Project Dunbar – International settlements using multi-CBDCs


1.2.1.4 Integration points

Figure 22: Corda node integration points


Network services
HTTPS

External Client application Corda Node


JVM RPC RPC CorDapp
based interface (distributed application)
app
AMQP/TLS
JDBC Corda
peer
JVM based nodes
Non JVM RPC
adapter Corda vault
based implementing
app (database)
RPC interface

Corda nodes communicate with each other using Corda nodes store states in a database (the
the asynchronous AMQP/TLS 1.2 protocols. vault) using JDBC.
HTTP communication is used only for the initial
registration of Corda nodes and for sharing the Integration with external systems
Corda node address locations by way of the
network map. Client applications communicate with Corda can integrate well with external world
Corda nodes using RPC calls. A node’s vault is a systems such as desktop applications, web-based
database that relies on a Java Database Connectivity applications, legacy systems and others. Each
(JDBC) connection from the Corda node. CorDapp can be accessed by invocating flows. To
invocate a flow to your node, you should be able
CorDapps are the functional aspect of Corda that to connect the RPC endpoint of the node to your
define the operations of a business network for a external system.
given use case.

Figure 23: Corda network architecture


Desktop Desktop
applications Corda node Peer Corda node applications

Web based CorDapp CorDapp Web based


applications (distributed application) (distributed application) applications

Internet banking Internet banking


systems Corda core Corda core systems

Bank Bank
connectors Corda vault Corda vault connectors
(database) (database)
Other external Other external
systems systems

Notary N Network services Oracle service

Identity service CorDapp (distributed


Corda core application)

Network map Corda core


Notary DB Internet

Corda vault
Signer service (database)

Project Dunbar – International settlements using multi-CBDCs | 41


1.2.1.5 Project Dunbar Corda network • Design and implementation of its own network
Keeping in mind the objectives of Project Dunbar, membership criteria.
R3 has designed the Dunbar network on the BIS • Governance, policies, regulations and
model 3. (For more on the model 3 approach, compliance.
please refer to the definition in Section 2.2
above.) It is a private permissioned regional A regional platform like this would require a
Dunbar network with four central banks, each of network operator to perform activities such as:
which has control over its sovereign domestic
• Day-to-day management of the network –
network through the notary node implantation.
tactical or operational role.
In other words, the Dunbar network is made up
of four logically separated sovereign networks. • Managing technical policies around the overall
upgrade schedule of the application, its
infrastructure and maintenance.
This enables each domestic sovereign network to
be in complete control of its: • Network services that control admission of
participants to the Dunbar network.
• Monetary sovereignty.

Figure 24: Dunbar network in Corda

Dunbar network Legend

Selected
commercial
bank

Regional
commercial
bank
Corda Network Services

Austral

Global
commercial
bank
ia
Singap

Malays

Notary
Corda Oracle
Services
ore

ia

Network
map

Identity
service

Signer
S o u t h A f ri c a service

In the network design diagram above, the global commercial banks and the central bank
regional Dunbar network is a single Corda hosts a Corda node. It is important to highlight
private network (marked by the square box). The that in our model it is sufficient that each bank in
domestic sovereign networks are represented as the entire Dunbar network hosts one node. The
four logical country networks in Corda (indicated following example will explain what this means.
by the four circles, each of which represents a
country). In this representation, each country Selected commercial banks – These are local
network is a combination of selected commercial banks within their country networks and do
banks, regional commercial banks, global not have a presence in any of the other three
commercial banks and the central bank that countries in the Dunbar network. The Corda node
represents the current real-world scenario. hosted will give capabilities to operate only in
the logical network of the specific country on
In R3’s proposed model, each of the selected Dunbar.
commercial banks, regional commercial banks,

42 | Project Dunbar – International settlements using multi-CBDCs


Regional commercial banks – These are banks Corda oracle services – These provide external
which have presence in two or more countries (off-ledger) data such as FX rates for validation to
in the Dunbar network. The single Corda node the different bank nodes in the Corda network.
hosted will give it the capability to operate in
those countries. 1.2.1.6 Installation and infrastructure
of Project Dunbar network on Corda
Global commercial banks – These are banks Each bank node and oracle service node is a
which have presence in all four countries in Corda node running the Corda core software
the Dunbar network. The single Corda node with CorDapps deployed on top of it that
hosted will give them the capability to operate in provide these nodes with business capabilities.
Singapore, Malaysia, Australia and South Africa. These nodes can be hosted on the premises or
in a cloud Infrastructure. These are the various
Central banks – MAS, BNM, RBA and SARB each deployment options available for Corda nodes.
hosts a Corda node in their respective country
networks. Because the central banks are the During Project Dunbar, R3 used CBDC
governing authorities managing the currency and Accelerator which is a CorDapp that lets central
monetary policies of each country, our model banks, commercial banks, payment providers
makes the central bank the notary of each of the and more collaborate with one another in a
logical country networks. The notary in Corda “ready-made payments ecosystem” to evaluate
provides complete control of the CBDC created CBDC use cases, learn, transact and test roll-
for each country network. out strategies and designs. The CBDC sandbox
CorDapp is hosted in Microsoft Azure cloud
Network operator – This provides Corda services. It is currently hosted in R3’s Azure
network services such as the network map, cloud subscription but can be easily moved to
identity service and signer service. In our model, another Azure cloud subscription.
we recommend that the BIS be the network
operator working closely with the four central
banks for governance. Please note that the
network operator functionalities can also be
performed by a technology provider on behalf of
Dunbar’s governing body.

Figure 25: Installation

Commercial CorDapp

Corda/CENM operation

Manual Deployment orchestration

Infrastructure
Manual provisioning

On-premise
Infrastructure
provider

Project Dunbar – International settlements using multi-CBDCs | 43


1.2.1.7 Privacy model for access to States Reissuance: When a new transaction is
information in Corda network created in Corda, input states are included in
Corda’s design is heavily influenced by the the proposed transaction by reference. These
requirements of the financial industry to share input state references link transactions together
data only with those with a legitimate need to over time, forming a transaction backchain.
know – thereby emphasising the significance of Long transaction backchains are undesirable
privacy. Corda’s unique approach on this concept as resolution along the chain slows down
contrasts with other public blockchains where performance. As well as all backchain transactions
all transactions data on the ledger must be are shared with the new owner.
broadcast to other participants on the network
and all of them must agree on all facts. In Corda, Prior to Corda 4.7, an approach to resolve the
a transaction is agreed upon with consensus problem with long transaction backchains was for
achieved only when all parties of that transaction a trusted issuing party to simply reissue the state.
provide their signatures. All transactions in Corda This meant that the state could simply be exited
are governed by one or more smart contracts, from the ledger and then reissued. As there
which define what operations are allowed and would be no links remaining between the exit
who can perform them. transaction and the reissuance transactions, the
transaction backchain would be pruned. Starting
Corda is built on a data-centric design sometimes with Corda 4.7, there is a new State Reissuance
known as a UTXO model rather than a compute- algorithm that eliminates the risk of being
centric design. By making data (contracts left without a usable state if the issuing party
and agreements) primary, Corda brings the fails to reissue the state for some reason (for
essence of data distribution to the heart of the example, if they are not online at the required
programming model. It is designed to answer time). This is achieved through the reissuing of
questions such as “Who should have this data an encumbered state before the original state
and when?” “Under which circumstances?” “Who is deleted. This allows the requesting party to
should verify or sign off on changes to this data?” unlock the reissued state immediately after the
“What evidence must be furnished to determine original state is deleted. State encumbrance
whether a proposed update is valid?” refers to a state pointing to another state that
must also appear as an input to any transaction
Advanced Privacy Techniques: consuming this state.

Corda uses several techniques to maximise Hardware based Confidential Computing:


privacy on the network: Conclave is a confidential computing platform
from R3 that enables the development of
Transaction tear-offs: Transactions are collaborative analytics solutions that aggregate
structured in a way that allows them to and process multi-party data—without revealing
be digitally signed without disclosing the the data to anyone. Confidential Computing
transaction’s contents. This is achieved using a describes a set of hardware techniques that fix
data structure called a Merkle tree. You can read this problem. It makes it possible to know what
more about this technique in R3’s document algorithm will process your information before
titled Defining transaction tear-offs. you send it to a third party, and to be assured
that the third party cannot subvert the integrity
Key randomisation: The parties to a transaction of the algorithm or observe it while it works.
are identified only by their public keys, and fresh Conclave makes it easy to write applications
key pairs are generated for each transaction. As a that utilise these capabilities. Conclave makes
result, an onlooker cannot identify which parties it possible to isolate a small piece of code from
were involved in a given transaction. the rest of the computer on which it runs (an
enclave). Remote users can be shown what code

44 | Project Dunbar – International settlements using multi-CBDCs


is running in the isolated world and then upload Software based Zero Knowledge Proof:
their secret data to it, where it can be processed Zero-knowledge proof (ZKP) is a cryptographic
without the owner of the computer in question method whereby one party (the prover) can
getting access. Enclaves can be used to protect prove the truth of specific information to
private data from the cloud, do multi-party another party (the verifier) without disclosing any
computations on shared datasets and make additional information. ZKP has been widely used
networks more secure. to enhance the privacy of blockchain functionality
and can be extended to solve inherent privacy
Intel SGX is an implementation of enclave- issues of any distributed systems architecture.
oriented computing. Conclave builds on SGX by The Dutch bank ING’s blockchain team has been
making it easier to develop enclaves in high level working on ZKP solutions for quite some time.
languages like Java, Kotlin or JavaScript. Their notable work has been the ZKP solution
for enhancing privacy on Corda blockchain for
There are three entities in an application that validating transactions so that their contents can
uses Conclave: be kept private without compromising on safety.

Clients - send and receive encrypted messages 1.2.2 R3’s CBDC Accelerator
to/from enclaves by interacting with the host R3’s CBDC Accelerator is the deliverable
over the network. in collaboration with the CBDC Working
Group, which started in September 2020 in
Host programs - load enclaves. From a security partnership with 140+ public and private sector
perspective they are fully untrusted and assumed organisations. CBDC CorDapp is built on Corda
to be malicious at all times. Hosts are relied on to Enterprise, hosted and offered by R3. R3’s aim
provide the enclave with resources but beyond with the CBDC Accelerator is to demonstrate
that work only with encrypted data. possible CBDC use cases on Corda.

Enclaves - are classes that are loaded into a Accelerator design is token-based, two-tier,
dedicated sub-JVM with a protected memory hybrid CBDC, where CBDC tokens can be
space, running inside the same operating system restricted to be issued by a central bank, as its
process as the host JVM. Code running in an liability, and distributed and transacted with a
enclave cannot be tampered with by the host vast set of intermediaries like commercial banks,
system or its owner, nor can the host system payment- or wallet service-providers catering for
or its owner see the data that the enclave is wholesale, retail and cross-border CBDCs in R3’s
processing. Enclaves communicate with clients CBDC Accelerator. R3’s cross-notary and cross-
via the host program. network interoperability have helped implement
features like delivery versus payment and payment
Figure 26: Enclave communication versus payment. The CBDC Accelerator has been
extended to support a UTXO-based decentralised
exchange enabling innovative solutions for
dynamic liquidity management and trade.

R3’s CBDC Accelerator is designed as a ready-


made digital ecosystem which brings to life
the idea of a regulated DeFi or Open Finance
solution, with CBDC as legal tender, at the core of
the ecosystem.

Project Dunbar – International settlements using multi-CBDCs | 45


R3’s CBDC Accelerator has the below features availability of CBDC tokens in a single- or multi-
prebuilt in: CBDC network. It allows users (commercial
banks/PSPs) to offer spare liquidity to other
• Token lifecycle management – Allows central users in the network at a certain rate (including
banks to track the lifecycle of a token created the fees).
ie pledge/ issue/ transact/ redeem/destroy
and ensuring clear distinctions of roles and • Distributed exchange – A DEX is an extended
responsibilities. version of the dynamic liquidity management
feature where users or a group of users can
• Member access – Allows central banks to be designated as market-maker. Rates can
control access to tokens and ensure KYC be set bilaterally (off-ledger) or using a bid-
compliance. ask process (off-ledger). Liquidity offers are
controlled broadcast giving flexibility to banks
• Re-issuance – Allows central banks to withdraw to choose their liquidity borrowers.
and re-issue tokens, an existing operational
feature mirroring how central banks manage • Token analytics/money supply – Allows central
fiat currencies in the current state. banks to track assets within the ecosystem, and
ensure they comply to regulatory and monetary
• Central banks will have visibility of transactions compliance requirements governing the money
at the point of re-issuance. Technically, it will supply. It helps central banks and regulators
limit the backchain from growing too big and by providing real-time, 360-degree visibility of
ensure good performance of the system. their assets in the ecosystem.

• Delivery versus payment – Allows users • Distributed interest – Allows central banks to
(commercial banks/PSPs) to exchange a real- implement positive/negative interest rates on
world asset (delivery) for digital currency their digital currency. Allows wholesale banks to
(payment). In R3’s CBDC Accelerator, bonds are loan spare liquidity for a fee (ie it is an incentive
exchanged with CBDC. mechanism).

• Payment versus payment – Allows users • Retail CBDC models – R3’s CBDC Accelerator
(commercial banks/PSPs) or central banks to extends end-to-end support for a general
exchange a currency (payment) for another purpose CBDC on a DLT framework. Features
digital currency (payment). In R3’s CBDC supported include token issuance by the central
Accelerator, one CBDC is exchanged with bank, and distribution by users (commercial
another CBDC, which can be extended to be banks/PSPs) that own and maintain retail
overlaid with workflow business rules. accounts of end-customers. Retail account
holders can initiate payments using the
• Programmable money – Allows central banks web app or mobile app using dynamic QR
and users (commercial banks/PSPs) to define code to pay at point of sale or for peer-to-
rules around assets so that they can behave or peer payments. R3’s CBDC Accelerator has
be used in a certain way. R3’s CBDC Accelerator other retail features built in such as payee
facilitates the ecosystem to explore innovative management, transaction-logging, and
use cases such as real-time direct government- business rules’ programmability.
to-citizen payments for citizens’ services such
as tax refunds, healthcare support, childcare R3’s CBDC accelerator has how-to guides for the
funding and stimulus payments. central bank and wholesale banks to learn how
to perform tasks on the user interface. The guide
• Dynamic liquidity management – Liquidity is accessed by clicking the clipboard icon in the
simply means “real time availability of liquid bottom right corner and provides step-by-step
assets or cash”. In CBDC parlance, it is the instructions for completing tasks.

46 | Project Dunbar – International settlements using multi-CBDCs


Figure 27: CBDC Accelerator guide CBDC Manager: As a central bank, digital
currency will be defined using the CBDC Manager
panel.

It allows you to name the digital currency and


optionally assign decimal places and/or make it
access restricted and/or add interest rates and/or
define controls around transaction usage.

For example, dAUD is created with 2 decimal


places, non-interest bearing and with access
required to hold this currency. Additional
transaction controls are configured where by
any transaction above 10,000 dAUD or after 100
transactions should be reported to the issuers.

Figure 29: CBDC manager

Member Controls: As a Central bank, you can


control access to digital currency using member
CBDC Accelerator Network – Central Bank access panel, where access can be issued or
revoked.

Figure 28: CBDC Accelerator Network


Figure 30: Member controls
– Central Bank

Project Dunbar – International settlements using multi-CBDCs | 47


Request: An authorised user of a Central Bank, CBDC Accelerator Network – Wholesale Bank
can approve or deny three different types of
requests ie request to issue CBDCs, request to Figure 34: CBDC Accelerator Network –
redeem CBDCs and request to provide access to Wholesale Bank
hold CBDCs.

Figure 31: Request

Treasury Dashboard: Authorised users of Central


Bank, can monitor the issued CBDC, the total
money in circulation, bonds that under held,
using treasury dashboard panel. CBDC Manager: Authorized wholesale bank
users uses this panel to check available CBDCs in
Figure 32: Treasury dashboard the networks where it has been granted access.
Depending on the user access, the panel extends
to key operational workflow with the central bank
issuer and counterparties.

Figure 35: CBDC manager

Transaction Log: Authorized user of a Central


Bank can view transactions (issue, redeem,
access) on a dashboard with the right timestamp
and the counterparty, on the transaction
dashboard panel.

Figure 33: Transaction log

48 | Project Dunbar – International settlements using multi-CBDCs


Member Controls: Wholesale bank authorised, Authorized users of wholesale bank can initiate
users can request access to a CBDC on the delivery vs payment requests by offering bonds
network by requesting the issuers of that CBDC, (pre-configured asset) for CBDCs.
using the access control panel.
Figure 39: Request DvP
Figure 36: Member controls

Requests: Depending on the user access granted,


wholesale bank user can initiate different types of
requests like request to issue CBDCs, request to
redeem CBDCs, DvP requests, access request to
hold CBDCs, using the request panel.
Authorized users of wholesale bank you initiate
Figure 37: Requests payment vs payment requests by offering one
CBDC for another, using the cross chain atomic
swap functionality in the request panel.

Figure 40: Request cross chain swap

Transfer: Authorized wholesale bank users, use


this panel to manage transfer of CBDCs to other
banks or PSPs on the network,

Figure 38: Transfer

Project Dunbar – International settlements using multi-CBDCs | 49


Authorized users of wholesale bank can initiate Figure 43: Treasury dashboard
either a pull request (example: scheduled
payments) or a push request (example: regular
payments) for CBDCs, using the transfer panel.

Figure 41: Transfer CBDC

Decentralised Liquidity Exchange: Authorized


users of wholesale bank can make an offer for a
currency pair, broadcast it to the network for an
off-ledger exchange or spot exchange. Users can
Treasury Dashboard: Authorized users of view the offer pool to look at offers from other
wholesale bank can monitor the different CBDCs wholesale bank and if in short of liquidity, can
that held, total amount of bonds in the vault and partially or in full, accept an offer.
balance over time, using the treasury dashboard
panel. Figure 44: Decentralised liquidity exchange

Figure 42: Treasury dashboard

In cross border payments today, a wholesale


bank has to manage it’s liquidity positions for
different currencies by inefficient and inaccurate
payment forecasting. In most cases this has
Transaction Log: Authorized users of wholesale resulted in situations when there isn’t enough
bank can view all your transactions (issue, liquidity to settle a cross border payment
redeem, access request, transfer) on a dashboard obligation, which leads to settlement delays.
with the right timestamp and the counterparty, With decentralised exchange, the aim is to offer
on the transaction dashboard panel. tools for buying real time liquidity from other
wholesale banks to settle a cross border payment
obligation. This tool can be further extended to
provide automated market making capabilities in
a multiple CBDC network for a basket of CBDCs.
This is currently not built in the accelerator.

Retail CBDC: As a wholesale bank, you can be


the distributor of CBDCs to end consumers and
businesses.

50 | Project Dunbar – International settlements using multi-CBDCs


All retail customers will have an account to hold Retail customers can send or receive payments,
and transact CBDCs. All retail customers are similar to a regular internet banking app.
onboarded using customer onboarding process
for a bank, adhering to KYC/AML requirements. Figure 48: Retail user functionalities
Retail customers can be managed, using manage
customer and accounts functionality.

Figure 45: Retail CBDC

Retail users can add payees, sent payments,


monitor your total CBDC balance and view
transaction history.

CBDC accelerator is embedded with dynamic QR


code-based payments, where using the mobile
app, retail users can tap and pay for goods and
Figure 46: Customer details services.

Figure 49: Dynamic QR code-based payments

Customers of wholesale bank can credit account


with CBDCs, by using deposit functionality.

Retail customer, can access their respective CBDC CBDC Accelerator Notary selection
account by logging into web portal or scanning a
QR code. In the CBDC accelerator, each central bank has
an associated notary or a selection of notaries,
Figure 47: Retail login responsible for issuance of CBDCs. These notaries
ensure there are no duplicate issuance, or any
double spend of CBDCs in the network. In
Corda, as the notary node provides the required
consensus, each CBDC is issued solely by the
central bank without any dependency on the
network.

Project Dunbar – International settlements using multi-CBDCs | 51


1.2.3 R3 Security Controls generation, will be delegated by the Corda
Designed primarily for financial institutions, the node to the HSMs, while operations involving
Corda platform offers security at multiple layers. public keys, such as signature verification, will be
performed by the Corda node. Corda Enterprise
Corda uses industry-standard protocols to supports a variety of HSMs such as Utimaco
communicate different software components in SecurityServer, Gemalto Luna as well as Azure
the network. Corda nodes communicate securely Key Vault and AWS CloudHSM from the leading
between each other using Advanced Message cloud providers.
Queueing Protocol (AMQP). This is a wire-level,
application-layer protocol for message-oriented 1.2.3.1 Security controls at CBDC
middleware and is a widely implemented binary Accelerator CorDapp layer
messaging standard. AMQP messages are Controls available on the CBDC Accelerator
encrypted using Transport Layer Security (TLS) include:
which ensures integrity and privacy of messages
in transit. Nodes use Hypertext Transfer Asset control – Asset controls are programmable
Protocol Secure (HTTPS) for their initial on the sandbox giving issuers (central banks)
registration in a Corda network and for sharing authority over how and when their assets are
node address locations through the network map. used.

A core component of the Corda Enterprise Transaction control – Issuers can programme
version is the Corda firewall component that transaction controls to give them authority over
enables a true Demilitarised Zone (DMZ). The how the assets they have defined are transacted.
Corda firewall, known as bridge/float component,
is designed for enterprise deployments and acts Notary selection – Notary selection lets
as an application-level firewall and protocol issuers (central banks) choose a notary (or
break on all internet-facing endpoints. The notaries) to use in transactions. The central bank
Corda firewall encapsulates the peer network designates a list of notaries that can validate a
functionality of the basic Corda Enterprise node, transaction when defining an asset. The sandbox
so that it can be operated separately from the automatically selects a notary from the list
security-sensitive Java Virtual Machine (JVM) during the first transaction with a particular asset,
run-time of the node. The firewall can also based on availability. It uses the selected notary
serve two or more nodes, thus reducing the for all transactions involving the CBDC tokens
deployment complexity of multiple nodes in associated with the initial transaction. Every
the same network. Corda is designed to prevent transaction requires at least one notary.
man-in-the-middle attacks by requiring that TLS
connections are directly terminated between By providing security at protocol and application
Corda firewalls. levels, the Corda platform safely stores and
secures end-users’ sensitive personal identifiable
Considering that cryptographic key lifecycle information (PII). Built for financial institutions,
management plays a crucial role in the Corda the Corda platform understands the criticality of
platform, the Enterprise version supports such user information involved in transactions on
integration with a variety of Hardware Security a CBDC ecosystem.
Modules (HSM). An HSM is well-trusted and
performs a variety of cryptographic operations
such as encryption and key management. An
HSM ensures that the hardware used is well
tested and has a security-focused operating
system with very limited access to the external
world. In the Corda ecosystem, operations
involving private keys, such as signature

52 | Project Dunbar – International settlements using multi-CBDCs


1.3 Prototype developed by Partior on There are two types of nodes:
Quorum platform
Participant nodes communicate within
1.3.1 Partior Technical Architecture the network to share transaction details for
processing. Every node in a decentralised system
1.3.1.1 Technical architecture has a copy of the blockchain.
Partior is based on an Ethereum-based
distributed ledger (Quorum) that is built with key Validator nodes are responsible for verifying
considerations such as ease of integration and transactions on a blockchain. Once verified,
data privacy. It is a fork of Go Ethereum client transactions are added to the distributed ledger.
(geth), the official GoLang implementation of the The central banks’ nodes are configured to be
Ethereum protocol, designed as a private network the validator nodes in this setup.
with a permissioned group of known participants.
Within the platform, the minimum necessary rule In Quorum, validator nodes are to be connected
is core-to-transaction-processing, which means with each other point-to-point.
information is retrieved on a “need-to-know”
basis. A network consists of multiple nodes, Non-validating nodes are not required to be
through which users connect to the platform. interconnected to all nodes in the network.

Each node comprises several components There are two ways for users to connect to the
including an API gateway, dApp, Tessera and the platform:
Quorum platform.
1. Self-hosted node by participants.
Figure 50: A node on Quorum
2. Third-party hosted node (PaaS): An
Bank systems Partior node independent operator is set and provides
Payment node-hosting services while at the same time
system Tessera
API API dApp
maintaining the integrity of the network.
gateway gateway
Core
banking Quorum
In establishing a connection with the platform,
users are required to leverage a component
Partior node – It is a Quorem node, which known as a Distribution Application (dApp).
is a minimal fork of Go Ethereum, providing
privacy, new consensus mechanisms, network-
permissioning and higher throughput.

dApp – A dApp acts as a middle layer between


conventional systems to the DLT, serving as
a translator to convert the user’s API into the
required smart contract format.

Tessera – A stateless Java application


responsible for the encryption/decryption of
private transaction data and off-chain private
messaging.

Project Dunbar – International settlements using multi-CBDCs | 53


1.3.1.2 Network architecture

Figure 51: Quorum network architecture


Participant 1 Regulator
Distributed app Distributed app Distributed app Distributed app
Single blockchain Single blockchain

Quorum Public
state
Private
state
Public
state
Private
state

Quorum node Tessera

Transaction Enclave Participant 2 Participant n


manager
go-ethereum Single blockchain Single blockchain

Public Private Public Private


state state state state

The Quorum network consists of three main components:


Quorum node, transaction manager and enclave. Participant 3 Participant 4

Transaction manager – allows access to encrypted Single blockchain Single blockchain

transaction data for private transactions, and manages the Public Private Public Private
state state state state
local data store and communication with other transaction
managers.
Enclave – responsible for private key management and for
the encryption and decryption of private transaction data.

1.3.1.3 Project Dunbar Partior network by initiating a transaction with its sponsor bank,
On the Project Dunbar Partior network, each host after which the transaction flows on to the multi-
is in control of its own “mini” network, which is CBDC platform. The following examples illustrate
depicted by the individual circles in the diagram (1) a domestic transfer and (2) cross-border FX
below. A domestic bank that is not a host may settlement.
engage in transactions on the Dunbar platform

Figure 52: Scenario 1 – Domestic transfer

SGD CBDC

Bank
A
AUD CBDC
Bank SGD
C CBDC Issuer Bank
... E

AUD
Bank ...
A
Bank
ZAR CBDC B CBDC Issuer
Onb

ar Bank
ds Bank D
o
Pro v

Bank B
J Bank
MYR CBDC
ZAR
id es a p pro

... H

CBDC Issuer a
Bank
Payment
va

MYR
Bank
l

C Smart Contract
... TXN ID:001
Bank
I CBDC Issuer
Std Conditions..

Bank REG Condition 1..


G

1. Bank A, a licensed bank in AU, is appointed by Bank B 2. As Bank B performs the domestic AUD CBDC transfer
as its sponsoring bank in the AUD CBDC. to Bank D, Bank A, which is the sponsor bank for
Bank B in the AUD CBDC network, will be required to
provide its approval for the transaction.

54 | Project Dunbar – International settlements using multi-CBDCs


Next, we consider a scenario of FX settlement from SGD to AUD.

Figure 53: Scenario 2 – FX settlement

SGD CBDC
PvP for the cross-CBDC
4 transfer completed
Bank
B
AUD CBDC
Bank SGD
C CBDC Issuer Bank
... E

AUD
Bank ...
2 B
Bank Payment
ZAR CBDC A SGD Smart Contract
TXN ID:002
CBDC Issuer
Bank
AUD D
Bank
Std Conditions 1.. Bank
J A
Bank
ZAR
PVP Condition 1..
... H 3
Bank Payment
CBDC Issuer F Smart Contract
TXN ID:002

MYR
Std Conditions 1..
Bank
Bank G PVP Condition 1..
I CBDC Issuer
Bank REG Condition 2..
C
...

MYR CBDC

1. Bank A has arranged for Bank B to perform the 3. Bank B AU will transfer AUD CBDC to Bank A’s
cross-CBDC PvP settlement (payment-versus- AUD wallet with the same transaction reference.
payment). The transfer will be effected once all pre-validation
2. Bank A will transfer SGD CBDC to Bank B SG. The conditions are fulfilled.
transfer will be effected once all pre-validation 4. Once both SGD and AUD CBDCs transfers are
conditions are fulfilled. completed, PvP is effected and the cross-CBDC
transfer is completed.

1.3.1.4 Installation and infrastructure 1.3.1.5 Access to information


of Project Dunbar network on Quorum Critical transaction data is processed on the
Each Partior node is an instance that can platform through the nodes. A natural question
be hosted on the premises or with a cloud that follows for indirect participants of the
service provider (CSP). During Project Dunbar, network is: Who has access to which parts of
the prototype was hosted with Amazon Web their data?
Services (AWS). AWS enabled efficient resource
provisioning (ramping up and down) as To illustrate the information that is available to
necessary, complementing the agile delivery each entity within a transaction, we consider the
methodology adopted by the project. following network scenario:

Considerations for deciding the number of nodes 1. Network of four nodes – Network operator,
and who should host them for a live platform settlement bank, ABC bank (participant bank),
include performance, efficiency and cost of XYZ bank (participant bank) node.
investment. As the number of nodes increases,
the resiliency of the platform against fraud or 2. ABC bank and XYZ bank have a digital balance
illegal activities increases by strengthening the account with the settlement bank (AC2 and
ledger. AC3 respectively).

Generally, it is acknowledged that, from a 3. Settlement bank has its own digital balance
feasibility perspective, central banks and account AC1 on the network.
selected commercial banks would be in the most
appropriate position to be hosting nodes.

Project Dunbar – International settlements using multi-CBDCs | 55


Scenario 1: Network instantiation Scenario 3: Transfer

• All contracts are deployed, and accounts • ABC initiates coin balance transfer to XYZ
created with “privateFor”¹⁰ for all nodes. bank via settlement bank.

• All nodes have the visibility of the account • The transaction is marked “privateFor” for all
numbers, and balances of all accounts are three nodes.
zero.
Figure 56: Transfer
Figure 54: Network instantiation
Node AC1 AC2 AC3
Node AC1 AC2 AC3 Settlement bank 0 1800 3200
Settlement bank 0 0 0 ABC 0 1800 200
ABC 0 0 0 XYZ 0 -200 3200
XYZ 0 0 0 Network operator 0 0 0
Network operator 0 0 0
Note:
• Settlement bank is able to see the true balance
Scenario 2: Deposit of both ABC and XYZ.
• ABC and XYZ can see the true self balance.
• Each bank initiates a balance deposit. • ABC and XYZ can only see their relative position
with respect to each other and cannot see the
• Transaction is marked “privateFor” for true balance of each other.
initiating bank and settlement bank (eg
(settlement bank, ABC). Scenario 4: Withdraw

Figure 55: Deposit • XYZ bank initiates withdrawal.

Node AC1 AC2 AC3 • The transaction is marked “privateFor” for all
Settlement bank 0 2000 3000 settlement bank and XYZ nodes only.
ABC 0 2000 0
Figure 57: Withdraw
XYZ 0 0 3000
Network operator 0 0 0 Node AC1 AC2 AC3
Settlement bank 0 1800 2700
Note:
ABC 0 1800 200
• ABC balances are visible to settlement bank
node and ABC node but not to XYZ node. XYZ 0 -200 2700

• Similarly, XYZ balances are visible to settlement Network operator 0 0 0


bank node and XYZ nodes only.
Note:
• Balance updates reflected only in settlement
bank and XYZ bank node.
• ABC node will not have any information of this
transaction.

¹⁰ "privateFor” is a feature which allows for making a transaction decryptable only to a selected few parties (private transactions).
https://consensys.net/docs/goquorum/en/stable/concepts/privacy/private-and-public/#private-transactions

56 | Project Dunbar – International settlements using multi-CBDCs


A smart contract is a programme written in a 1.3.2 Partior Applications
high-level programming language that runs on a
DLT. 1.3.2.1 Types of transactions available
on Partior sandbox
There are three categories of smart contracts on Partior’s CBDC sandbox model allows central
a Quorum platform: banks to leverage the existing banking
infrastructure and relationships between corporate
• A payment contract is used to facilitate funds or retail accounts and commercial banks.
transfer. Its capabilities include payment
conditions management, payment lifecycle CBDCs that are minted from the central bank
orchestration and status maintenance, as well are transferred into the CBDC-designated CBDC
as payment enquiry. “issuer” account. The corresponding CBDCs,
which are central bank money, can be redeemed
• A common contract is used for maintaining back to fiat currency where required.
information. Its capabilities include access
management, bank list and availability, and Participants will be able to utilise the Dunbar
common codes, etc. platform on Quorum to conduct cross-issuer
or cross-currency payments while at the same
• Lastly, a settlement contract is used to time reducing current frictions and latency, and
manage a user’s wallet. Its capabilities include minimising post-transaction exceptions-handling
transaction posting and balance enquiry. and reconciliation activities.

1.3.2.2 Partior membership types and their privileges

Figure 58: Partior CBDC Sandbox

Functions:
CBDC issuer
Central bank
1. Create CBDC issuer & commercial bank account
Central Bank 2. Mint / Burn CBDC
3. Transfer CBDC to commercial bank account

Functions:

Tier 1 Commercial bank Commercial bank


1. Create non-resident bank account
2. Transfers: CBDC issuer, commercial bank, non-resident bank
3. Transaction listing

Functions:

Tier 2 Non-resident Non-resident Non-resident Non-resident 1. Transfers: commercial bank, non-resident bank
bank bank bank bank 2. Fund/withdraw corporate account
3. Transaction listing

CBDC issuer – Central bank: Ability to create 1.3.3 Partior Security Controls
CBDC issuer and commercial bank account, mint/
burn CBDC, and transfer CBDC to commercial 1.3.3.1 Multi-network CBDC
bank account. governance model on the Dunbar
platform in Quorum
Tier 1 – Commercial bank: Ability to create non- Membership admission criteria are common and
resident bank account, transaction listing, and can be applied universally across the platform. All
make transfers to CBDC issuer, commercial bank participants (nodes or banks) will be subject to a
and non-resident bank. universal set of security policies.

Tier 2 – Non-resident bank: Ability to fund/


withdraw corporate account, transaction listing,
and make transfers to commercial bank and non-
resident bank.

Project Dunbar – International settlements using multi-CBDCs | 57


Figure 59: Tessera encryption
Encryted Payload,
Tessera A Encryted MK, HeP� Tessera B Tessera C

Encryted Encryted
payload Ack/Nack payload

No
42 HeP� HeP� 42 HeP� data

Quorum node A Quorum node B Quorum node C


Public Private HeP� Public Private HeP� Public Private
state state state state state state

¹HeP = SHA3-512 hash (encrypted payload)

Quorum’s decentralised architecture provides Privacy is achieved on Quorum through Ethereum


unique privacy advantages. modifications and Tessera.

Partior’s implemented sandbox did not place


reliance on a central node or service, and as such Ethereum modifications – State trie is split
there is no centralised datastore. This ensures into public state trie and private state trie;
decentralised privacy. A single-chain architecture “v” value of private transactions is set to
37 or 38; privateFor is added to transaction
with a chain that contains both public and private
parameters in order to specify an array of
transactions would guarantee privacy while recipients that will receive the transaction’s
ensuring better security. It is designed to meet details; and the Ethereum virtual machine
regulatory requirements around in-country data (EVM) is prevented from executing private-
and is compatible with next-generation crypto to-public writes.
primitives such as ZKP.

Figure 60: Simple privacy diagram

Participant A
Tessera node A
Quorum
1 node A 2 3 10
Dist. app Transaction
Public
store
Private
store manager Enclave
6 4 11
Block 1
LEGEND
Tessera REST Protocol

Txn AB 8 12
Ethereum P2P

Ethereum P2P Protocol


Protocol

7 5 Tessera REST Protocol

Participant B
9 Tessera node B 1 Private Txn AB
2 TxnPayload
Quorum 10
node B Transaction
3 En/Decryption Request
Public Private manager Enclave 4 Txn Response
store store
11 5 TxnPayloadStore (HTTPS)
Block 1 6 Txn AB Hash
8 7 Private Txn AB (Hash)
Txn AB 12
Ethereum P2P

8 Block w/ Txn Ab (Hash)


Protocol

7 9 TxnPayloadRequest
10 En/Decryption Request
Participant C
9 Tessera node C 11 Txn Response
(Not party to Txn AB)
Quorum 12 TxnPayloadResponse
node C Transaction
Public Private manager Enclave
store store

Block 1
Txn AB 8 12

58 | Project Dunbar – International settlements using multi-CBDCs


1.3.3.2 Tessera cryptography and key 9. All parties attempt to process the transaction.
management 10. Since C does not hold the transaction, it will
Tessera uses the NACL crypto library, which receive a NotARecipient message and will skip
includes payload encryption and authentication, the transaction – it will not update its Private
public key encryption/authentication and StateDB.
hashing. Tessera generates key pairs and holds 11. Enclave for A and B validates the signature
private keys, that are password-protected, locally. and then decrypts the symmetric key using
the party’s private key that is held in the
Sending a private transaction enclave, decrypts the transaction payload
using the now-revealed symmetric key
1. Participant A sends a transaction to their and returns the decrypted payload to the
Quorum node. transaction manager.
2. A’s Quorum node passes the transaction on to
its paired TxMgr. The transaction managers for parties A and B
3. A’s TxMgr makes a call to its associated then send the decrypted payload to the EVM for
enclave to validate the sender and encrypt the contract code execution.
payload.
4. A’s enclave checks the private key for A and, To lessen the likelihood of fraudulent
once validated, performs the transaction transactions, Quorum currently implements two
conversion: consensus mechanisms – Istanbul BFT and Raft
a. Generating a symmetric key and a random (the older QuorumChain is now deprecated).
nonce. Enabling one or the other is done via flags
b. Encrypting the payload and nonce with the passed at start-up time to the node client.
symmetric key from a.
c. Calculating the SHA3-512 hash of the
encrypted payload from b.
d. Iterating through the list of transaction Raft – Based on the etcd’s raft
recipients, in this case A and B, and implementation, and enabled via the
encrypting the symmetric key from a. with --raft flag upon geth start-up. It features
the recipient’s public key (PGP). high throughput with low latency.
e. Returning the encrypted payload from step Blocks are communicated using the raft
b., the hash from step c. and the encrypted transport layer, not Ethereum’s DEVp2p,
keys (for each recipient) from step d. to the and it is fork-preventing which ensures
transaction manager. transaction finality.
5. A’s TxMgr stores the encrypted payload then
securely transfers (via HTTPS) data to B’s Istanbul BFT – The Istanbul BFT (IBFT)
TxMgr. features a three-phase consensus
6. A’s TxMgr returns the hash to the Quorum commit that is BFT-hardened. Validators
node which then replaces the transaction’s are defined at the network start and
original payload with that hash. must have direct connections. IBFT is
7. The transaction is then propagated to the rest enabled via the custom genesis block
of the network using the standard Ethereum with Istanbul configuration option and
P2P protocol. validator list via etraData,¹¹ documented
8. The leader Quorum node (in this case A) in detail via EIP 650.¹²
creates a block containing Transaction AB and
distributes to each party node on the network.

¹¹ https://github.com/ConsenSys/quorum-examples/blob/master/examples/7nodes/istanbul-genesis.json
¹² https://github.com/ethereum/EIPs/issues/650

Project Dunbar – International settlements using multi-CBDCs | 59


Permissioning

This functionality on the Quorum platform


controls which nodes may connect to other
nodes. Permissions and public key whitelists are
currently managed at the node level.

Smart contract-based permissioning archetypes


(eg a single entity responsible for onboarding
and rules-setting) , where a centralised
governance authority does not need to replace
distributed blockmaking/validation, will be
supported.

Geth modifications

The “proof of work” consensus algorithm has


been replaced, and the P2P layer has been
modified to allow only connections to/from
permissioned nodes. The block generation/
validation logic has been modified to replace the
“global public state root” check. The State Patricia
trie has been split into two: a public state trie and
a private state trie.

Block validation logic has been modified to


handle private transactions. Transaction creation
has been modified to allow for transaction data
to be replaced by encrypted hashes in order to
preserve private data where required, preventing
EVM from executing private-to-public writes. The
price of gas has been set to 0 – gas itself remains.

60 | Project Dunbar – International settlements using multi-CBDCs


1.4 Glossary of Terms

AML Anti-Money Laundering


BISIH Bank for International Settlements Innovation Hub
BNM Bank Negara Malaysia
CBDCs Central Bank Digital Currencies
CFT Countering Financing of Terrorism
CPMI Committee on Payments and Market Infrastructures
DLT Distributed Ledger Technology
DvP Delivery versus payment
EDD Enhanced Due Diligence
FSB Financial Stability Board
FX Foreign Exchange
HTLC Hash Time-Locked Contracts
IPS Instant Payment System
KYC Know-Your-Customer
MAS Monetary Authority of Singapore
Multi-CBDCs Multiple Central Bank Digital Currencies
PvP Payment versus payment
RBA Reserve Bank of Australia
SARB South African Reserve Bank

Project Dunbar – International settlements using multi-CBDCs | 61


Bank for International Settlements (BIS)

ISBN 978-92-9259-543-2 (online)

You might also like