Central Bank Digital Currency Experiments
Progress on the Pilot Program (April 2024)

Payment and Settlement Systems Department, Bank of Japan

CONTENTS
1 Introduction ............................................................................................................................. 2
2 Development of a system for the pilot program and experimentation ................... 3
2.1 Overview and development status of the system ......................................................... 3
2.2 Overview of and recent developments in the experimentation................................. 7

3 The CBDC Forum .................................................................................................................... 8
3.1 [WG1] "Connection between CBDC system and fundamental external systems" .. 9
3.1.1 Overview .............................................................................................................................. 9
3.1.2 Summary of discussions................................................................................................... 10
3.1.3 Next steps .......................................................................................................................... 13
3.2 [WG2] "Overlay services and CBDC ecosystem" ......................................................... 14
3.2.1 Overview ............................................................................................................................ 14
3.2.2 Summary of discussions................................................................................................... 14
3.2.3 Next steps .......................................................................................................................... 17
3.3 [WG3] "KYC and user authentication/authorization" ................................................ 20
3.3.1 Overview ............................................................................................................................ 20
3.3.2 Summary of discussions................................................................................................... 20
3.3.3 Next steps .......................................................................................................................... 23
3.4 [WG4] "New technologies and CBDC".......................................................................... 24
3.5 [WG5] "User devices and UI/UX"................................................................................... 26

4 Conclusion .............................................................................................................................. 27(Appendix) CBDC Forum member list ................................................................................ 28

1

1 Introduction
Based on "The Bank of Japan's Approach to Central Bank Digital Currency,"1 which
was released in October 2020, the Bank of Japan has examined whether the basic
functions and features of a Central Bank Digital Currency (CBDC) are technically feasible
through two phases of Proof of Concept (PoC): PoC Phase 1 (from April 2021 to March
2022) and PoC Phase 2 (from April 2022 to March 2023).2
Since April 2023, the Bank has been proceeding with a pilot program with the aimof conducting technical evaluation not explored in the PoCs, while leveraging the skills
and insights of private businesses. The pilot program revolves around two pillars:"development of a system for the pilot program and experimentation" and the "CBDC
Forum" (Figure 1). In the former, performance tests are conducted on the systemdeveloped by the Bank, and various types of desktop experimentation are carried out on
functions that are not implemented in the system. In the latter, the Bank acts as thesecretariat and conducts practical discussions on a wide range of themes with private
businesses related to retail payments. The findings gained through the two pillars are fed
into the work of each other as necessary. This report, compiled by the Payment andSettlement Systems Department of the Bank, summarizes progress made on the pilot
program as of the end of March 2024.
Figure 1. Overview of the pilot program

CBDC Forum
Secretariat

Secretariat

Discussion withparticipants

Secretariat

Discussion withparticipants

Discussion withparticipants

Secretariat

Discussion withparticipants
Development of a system for the pilot program
Experimentation

Bank of JapanFor details, see Bank of Japan, "The Bank of Japan's Approach to Central Bank Digital Currency" (October2020).
1

For the results of the PoCs, see the following references: Payment and Settlement Systems Department,
Bank of Japan, "Central Bank Digital Currency Experiments: Results and Findings from 'Proof of Concept
Phase 1'" (May 2022). Payment and Settlement Systems Department, Bank of Japan, "Central Bank Digital
Currency Experiments: Results and Findings from 'Proof of Concept Phase 2'" (May 2023).
22

2 Development of a system for the pilot program
experimentationandOne of the pillars of the pilot program involves the development of a system for thepilot program, the conduct of performance tests, and desktop experimentation focusing
mainly on functions that are not implemented in the system. The following provides (1)an overview and the development status of the system and (2) an overview of and recent
developments in the experimentation.

2.1 Overview and development status of the system
The pilot program is broader in scope than the PoCs. While the PoCs focused mainlyon the ledger in the central system, the pilot program has an end-to-end coverageranging from endpoint devices to the central system (Figure 2).
Against this background, the system for the pilot program goes beyond thedevelopment of the central system to include that of intermediary systems, theintermediary network system, which connects the central system with the intermediarysystems, and endpoint devices (apps for smartphones and tablets). We will eventually
test the end-to-end process flow while exploring potential challenges related toconnections with external systems and measures to address them.
Figure 2. System for the pilot program and its scope

System for the pilot program

Scope

Endpoint devices (for consumers/retailers)IntermediarysystemIntermediarysystemIntermediarysystemIntermediarysystemPilot program（multi-layered）

Intermediary network system
Central system

PoCs

Figure 3 illustrates an overview of the structure of the system currently underdevelopment, which adopts the CBDC ledger design of an account-based data model3

with shared management between the central system and the intermediary systems.3 Forclarification, this does not imply that the Bank has already decided on the ledger design
suitable for potential social implementation. Rather, the idea is that this ledger design
has a relatively complex system configuration and is thus expected to allow for further
examination of various issues. Other ledger designs will also be explored during thedesktop experimentation as we take into account the findings of the experimentation
using the system.
In consideration of privacy, we plan to separate the intermediary systems handlingcustomers' personal information (customer management component) from those
processing payment (CBDC ledger component).4
With regard to performance, we aim to build a system that can handle higher load
processes than the PoCs.5 In doing so, we will identify and evaluate technical issues andsolutions, so as to satisfy performance requirements in the possible event of social
implementation.
Furthermore, during the system design phase we plan to incorporate features that
support functional and performance scalability, which may lead to identifying andevaluating technical issues and solutions.

3This ledger design corresponds to Design 2 in the PoCs.

Other central banks in developed countries have similar considerations for privacy. For example, theEuropean Central Bank (ECB) has presented in "Digital euro market research" (January 2023) a preliminary
requirement that "[t]he Eurosystem will not itself be able to monitor the holdings of any individual or track
the transaction history or infer payment patterns of any user." Similarly, the Bank of England (BOE)
proposed at the time of joint consultation with HM Treasury in February 2023 that "[a]ny information
accessed by the Bank would have to be effectively anonymised off-ledger."4

In the PoCs, we assumed a typical load of tens of thousands of transactions per second and a peak loadof 100,000 or more transactions per second as the processing performance required for potential social
implementation.
5

4

Figure 3. System overview
Endpoint devices（e.g. wallet app）

Endpoint devices（e.g. wallet app）

Intermediary X

Intermediary Y

Intermediary system
Customer management
CBDC ledger（for each customer）

Intermediary systemCorebankingsystem(mockup)

Customer management
CBDC ledger（for each customer）

Core
bankingsystem(mockup)

Intermediary network system
Central system
Central system
CBDC ledger（for each intermediary）

BOJ-NET(mockup)

The system will be equipped with a series of basic functions that were also built into
the system for the PoCs, namely, issuance, payout, credit transfer, acceptance, andredemption (Figure 4). In addition, the system will be equipped with auto-swing6 andauto-charge7 functions, which can be triggered at the time of transfer, and limit check
functions against, for example, a holding limit. In the pilot program, we aim to cover a
wider range of technical considerations and solutions than the PoCs, by expanding thescope of the system to include not only the central system but also the intermediarysystems and endpoint devices.
Further, additional functions, such as scheduled transfer including batch transfer,debit transfer, and balance/transaction statement inquiry, which were built into thesystem for PoC Phase 2, are also planned to be incorporated.

An auto-swing function is the automated acceptance of CBDC for the amount in excess of a holding limit
into, for example, a bank deposit account linked to a CBDC account.
6

An auto-charge function is the automated payout of CBDC for the amount that enables a transfer from,for example, a bank deposit linked to a CBDC account, when the balance of a CBDC account is insufficientfor the transfer.
75

Figure 4. Basic functions and additional functions
User A

User B(7) Debit transfer(6) Scheduled transfer（Batch transfer）(8) Balance/transaction
statement inquiry(3) Credit transfer(4) Acceptance(2) Payout

Intermediary X
Intermediarysystem(8)Balance/transaction
statement inquiry

Intermediary YCore banking
system(mockup)

Intermediarysystem(1) IssuanceCore banking
system(mockup)(5) Redemption
Central system
Central system

Function

BOJ-NET (mockup)

OutlineBasic functions(1) Issuance

The current account deposit of intermediary X at BOJ is debited while its CBDC accountis credited.

(2) Payout

User A's deposits, for example, are debited and CBDC is transferred from intermediary
X to user A.

(3) Credit transfer

CBDC is transferred between users.
・Auto-swing, auto-charge
・Various limit checks (such as holding limits)(4) Acceptance

CBDC is transferred from user B to intermediary Y and user B's deposits, for example,
are credited.

(5) Redemption

Intermediary Y's CBDC account is debited while its current account deposit at BOJ iscredited.

Additional functions(6) Scheduled transfer(Batch transfer)

Transfer instructions to be executed in the future are registered and executed
automatically at a specified time. (Batch transfer is the batch execution of multiple
transfers)(7) Debit transfer

Based on the prior consent of the payer, the payee sends a debit transfer instruction to
the payer's account and initiates the debit transfer.

(8) Balance/transaction
statement inquiry

Inquiries are made on a statement of the user's current balance and its transaction
history of CBDC managed in an intermediary system.

6

2.2 Overview of and recent developments in the experimentation
After developing the system, relevant experimentation including performance tests
will be carried out using the system.
In parallel with the system development and relevant experimentation, we will
perform desktop experimentation on functional and non-functional aspects of a CBDC
system, such as system configuration and security measures.
Themes for desktop experimentation on functionality include (i) various functions
that are not implemented in the system, (ii) interoperability with external systems, (iii)
external connection interfaces, (iv) adoptability of potential offline payments, and (v)privacy enhancing technologies (Figure 5). Examples of non-functional themes coversystem configuration aspects, such as measures to minimize system downtime as well asfunctional and performance scalability, and facets of security measures.
These themes for desktop experimentation may be modified accordingly, taking into
account the results of the system development and experimentation as well as future
discussions at the CBDC Forum.
Figure 5. Examples of themes for desktop experimentation
Theme

OutlineFunctional aspects
Various functions not
implemented in the system- Explore functions that are not implemented in the system. These include
opening/closing of accounts, requests to pay, recurring direct debit, and limits
on number of account holdingsInteroperability with external
systems- Explore possible features of a CBDC system to ensure interoperability withother systems

External connection interfaces- Look into considerations regarding a CBDC system's interface for external
connections with intermediaries and overlay service providers (such as API
gateways)

Adoptability of potential offline - Explore functions and scalability required for an online CBDC system inpayments
realizing offline payments
Privacy enhancing technologies- Explore privacy enhancing technologies (PETs) taking into account related
legal and regulatory requirements

Non-functional aspects
High availability- Explore measures to minimize system downtime

Functional and performance
scalability- Explore scalability measures to allow for enhancement of functions andperformance

Security measures- Explore security measures necessary for a CBDC system

7

3 The CBDC Forum 8
The CBDC Forum consists of members from a wide range of industries. They arefinancial firms and non-financial firms including start-ups, which have insights intechnologies and business practices of retail payments (64 participating firms as of March
2024). The Payment and Settlement Systems Department of the Bank acts as thesecretariat, forming and organizing thematic working groups (WGs). The status of the
discussions held in each of the five WGs (Figure 6), which are currently ongoing, is asfollows.
Figure 6. Discussion themes for each WG
WG

Theme

- Connection with core banking systems[WG1]
Connection between CBDC system and - Connection with private payment and settlement
since Sept. 2023 fundamental external systems
infrastructure- Coordination with internet banking apps
- Business utilization of CBDC (overlay services)[WG2]
Overlay services and- External coordination of a CBDC system regarding
since Sept. 2023 CBDC ecosystemoverlay services- Design of CBDC ecosystem- Current practices of KYC and AML/CFT checks[WG3]
KYC andsince Oct. 2023 user authentication/authorization- Authentication/authorization[WG4]
New technologies and CBDC
since Jan. 2024

[WG5]
User devices and UI/UX
since Mar. 2024
TBD

Horizontal coexistence of CBDC andother payment instruments

TBD

Operational flow of basic functions- Back-end layer (e.g. alternative data models)- Front-end layer (e.g. "wallets")- Coexistence with other types of payment methods andassets (stablecoins, asset tokenization, interoperability
with DLT platforms, etc.)- UI/UX and accessibility- Endpoint devices- Offline payments- Smooth conversion to and from electronic money andother forms of money- Operational flow of basic functions- Conversion between cash and CBDC

Materials and minutes for each WG are available in Japanese(https://www.boj.or.jp/paym/digital/d_forum/index.htm).
88

3.1 [WG1] "Connection between CBDC system and fundamental
external systems"
3.1.1 Overview (Figure 7)
Since its first meeting in September 2023, WG1 has held eight meetings (as of March
2024) to discuss connection methods for a CBDC system. The purpose of WG1 is to gain
insight into technical and operational aspects of connection methods particularly withcore banking systems, after exploring connections between existing external systems andcore banking systems as well as their operational flow. At the first and fourth meetings,
the Bank provided an overview and assumptions of WG1, and from the second meeting
onward, members gave presentations on each given theme, which were followed bydiscussions. Specifically, members first explored the business requirements for payout
and acceptance of CBDC, and then discussed connection methods for a CBDC system,taking into account the given business requirements and in view of the connection
methods for core banking systems and existing external systems.
Figure 7. Overview of WG1
1stmeeting(i) Understanding business
requirements of
payout/acceptance(ii) Exploring various
connection methods(iii) Deep dive

TBD(i) Outline(ii) Outline(iii) Outline

Referring to the operational flow inexisting core banking systems,
examine how CBDC payout or
acceptance induces changes in thebalance sheet of intermediaries

Based on business requirements of
CBDC, explore various connections
between CBDC system and corebanking systems

Gain insight on technical or
operational aspects of eachconnection method with a view tofuture-proofing the system

93.1.2 Summary of discussions (Figure 9)
Assumptions for discussions (1st and 4th meetings)9
The Bank presented the following assumptions10 for discussion.
(1) Functions
The functions to be explored are payout and acceptance (including auto-swing andauto-charge) as well as transfer. Payout and acceptance are given a higher priority
for discussion among these, as their functioning requires core banking systems to
be connected with a CBDC system. Additional assumptions related to the functions
are as follows:









Instant conversion between CBDC and other forms of money, such as bankdeposits, is available.
CBDC system operates 24/7/365.
The number of intermediaries' end-user accounts equals the current number of
their deposit accounts.
Required settings for processing performance in introducing a CBDC are
maintained from the PoCs: typical throughput 11 of tens of thousands oftransactions per second, peaking beyond 100,000 transactions per second, anda latency12 of within a few seconds.
Non-functional aspects are to be discussed subsequently in the WG.

(2) System configuration and ledger design
A CBDC system consists of two parts: a customer management component13 and aledger component.14 The data model of the ledger given in WG1 is account based,
and both central and shared management ledger architectures are explored under
this model.15

The meetings specified in parentheses indicate those during which discussions were held on therespective topics.
9

The assumptions are for discussion purposes only. The Bank has not yet specified components suitable
for social implementation, such as ledger design and system configuration.
10

11

Throughput refers to the number of transaction requests that a CBDC system can process per unit time.

Latency refers to the processing time from the time the end-user terminal sends a request to the time it
receives a notification of, for example, process completion.
12

Customer management of a CBDC system is a system for managing information about CBDC users.
Specifically, upon receiving a request from an endpoint device, it sends messages such as a payment
instruction to a CBDC ledger. It could also handle the opening and closing of accounts as well as AML/CFT.
13

14

A CBDC ledger is a system for recording CBDC balances.

The central management architecture assumes that the ledger is managed solely by the central bank.
The shared management architecture assumes that the ledger is managed by both the central bank and1510

(3) Scope of discussion in terms of system connections
We assume connections with two types of systems: core banking systems and a
CBDC system. Given that WG1 prioritizes payout and acceptance as its discussion
topic, the connection between core banking systems and a CBDC system (customer
management portion) is specified as the scope of the discussion.
Business requirements in payout/acceptance (2nd and 3rd meetings)
WG members gave presentations on the business requirements for payout andacceptance and on the assumptions for connection methods between a CBDC systemand core banking systems.
The following views were expressed during the discussions.








Movements on intermediaries' balance sheets (CBDC issued by the central bankis paid out to a user, and an equivalent amount is deducted from the user's bankdeposits), as shown in the "Liaison and Coordination Committee on Central Bank
Digital Currency 'Interim Report,'" 16 could be realized by adding to andsubtracting from the account balances of core banking systems.
The following items should be considered in particular when exploring system
connections: connection interfaces (communication line, protocol, etc.),
online/batch processing, and 24-hour operation.
Measures to be taken in the event of a supension of deposit account-related
processes, during non-operating hours of the core banking system, for example,
are also issues for discussion.
When considering efficient connection methods between intermediaries, there
is a need for some kind of relay system connecting a CBDC system and corebanking systems of intermediaries (Figure 8).

intermediaries, with intermediaries managing the ledger for each user. Other data models, such as thetoken-based model, are explored in WG4 of the CBDC Forum.
For details, see Bank of Japan, "Liaison and Coordination Committee on Central Bank Digital Currency'Interim Report'" (May 2022).
16

11

Figure 8. Stylized representation of relay system■ Without a relay system■ With a relay system
CBDC
system cCore banking
system A

Core banking
system B

CBDC
system dCore banking
system B

Each intermediary is connected to one another

Relay system

Core banking
system A

CBDC
system c

CBDC
system dEach intermediary is connected to a relay system

Connection methods between CBDC system and the core banking system (3rd through6th meetings)
Members gave presentations on connection methods between core banking
systems and existing external systems as a potential source of reference for examining
connection methods between a CBDC system and core banking systems.
The following points were raised during the discussions.


The Zengin System, CAFIS, CARDNET, COTRA system, API infrastructure, J-Debit,
and integrated ATMs are examples of existing external systems that connect tocore banking systems. Existing connection methods include connection
interfaces (communication lines, protocols, etc.), online/batch processing, and24-hour operation.



The instant processing of core banking systems through the external systems
includes (1) money transfer within a bank, (2) interbank money transfer, and (3)cash deposit and withdrawal.

When considering the conversion between CBDC and bank deposits in view ofthese processes, the following issues need to be borne in mind. In the event thatthe conversion between CBDC and bank deposits is not completed within thesame intermediary -- for example, payout is processed by using the bankdeposits of one intermediary and CBDC of another intermediary -- fundsettlements between intermediaries are expected to occur. There will also be aneed to send out a response message to notify the parties involved of thesettlement.

Issues regarding various connection methods (6th and 7th meetings)
Members summarized the features of and the points of discussion for each method
presented at previous meetings.

12

The following issues were raised as additional points for discussion: (1) the optimal
intermediary network for achieving a simple process flow; (2) points to be considered in
the case of a shared intermediary system as well as the pros and cons of possible options
for CBDC system configuration; and (3) functions to be included in the relay system.
Figure 9. WG1 agenda and presenters
Date
1st

AgendaSept. 20, 2023 - Overview of the WG

PresenterBank of Japan
Mizuho Bank Ltd.

2nd

Oct. 13 - Business requirements of payout/acceptanceFukuoka Financial Group, Inc.
Sumitomo Mitsui Banking Corporation

3rd

Nov. 2

4th

Nov. 22 - Various types of connections between CBDC

Chiba Banksystem and core banking systems
5th

Dec. 126th

Jan. 17, 2024

Bank of Japan
Seven Bank, Ltd.
JAPAN POST BANK Co., Ltd.
BIPROGY Inc.
Aeon Bank, Limited
NEC Corporation

7th

Feb. 7 - Deep dive on connection methods

NTT DATA Financial Technology
Corporation
The Shinkin Banks Cooperative Center
The Shinkin Banks Information System
Center Co.,Ltd.

8th

Mar. 15

MUFG Bank, Ltd.

3.1.3 Next steps
As next steps, discussion points raised by members will be utilized forexperimentation using the system, another pillar of the pilot program. The Forum willcontinue to consider various possibilities such as discussing issues that need to be delved
into more deeply by treating them as additional themes in this WG or exploring them ina new WG.

13

3.2 [WG2] "Overlay services and CBDC ecosystem"
3.2.1 Overview (Figure 10)
Since its first meeting in September 2023, WG2 has held a total of seven meetings(as of March 2024) to discuss the concept of a CBDC ecosystem and survey precedents
in the payment landscape.
Figure 10. Overview of WG2
1st meeting(i) Overall concept and case studies(ii) Discussion on technologies(iii) Gaining insight into CBDC(i) Tentative agenda
 Concept of CBDC ecosystem Survey on precedents in the payment

landscapeOverseas CBDC ecosystems
Overseas FPS ecosystem designEmbedded finance, banking APIsOther payment services(ii) Tentative agenda
 External coordination of a CBDC system

regarding overlay services
Open APIs, SDKs

SandboxesUpdate and maintenance of
supporting functions
Developer community(iii) Tentative agenda
 Potential of overlay CBDC

servicesClassification of use cases

Utilization of dataSo-called programmability
 CBDC as an enabler for services

Anticipated features

Specifically, the WG has discussed the overall concept of a CBDC ecosystem in orderfor members to share a common understanding of its implications. As examples ofexisting payment ecosystems, members have presented overseas cases and efforts bymember firms of the WG. Alongside this, the WG has discussed specific technologies that
support the development of the ecosystem, such as application programming interfaces(APIs).

3.2.2 Summary of discussions (Figure 11)
Scope and assumptions for discussions (1st meeting)
The Bank introduced the following scope and assumptions for WG2. The WG focuseson overlay services (i.e., services provided by various players of the private sector byadding functions to basic functions such as the simple transfer of money) starting withdiscussions focusing on services related to domestic P2P and B2C fund transfers. While
discussions here would assume online payments, offline payments will be handled by adifferent WG.
The following views were expressed during the discussion.


The importance of being attentive to future changes in technological trends anduser needs should be addressed.
14

There is a need to consider what the uniqueness of CBDC is in providing overlay
services in the payment system.

Overall concept, case studies, and technology of ecosystems (2nd through 6th meetings)
The Bank introduced overseas case studies from ongoing discussions on CBDCrelated services and of Fast Payment Systems (FPSs), mainly in Europe and in the UnitedStates and Australia, respectively. Members also gave presentations on each of theirfirms' initiatives and technological trends.
A summary of the views expressed by WG members on each topic is as follows.
[API standardization and UI/UX]Standardization of technology, especially that of API, is important. From thisperspective, both interoperability and overall user experience (UX) should beconsidered.

Regarding API standardization, the following areas should be differentiated fromeach other: (1) common areas where the specification of APIs should bestandardized and (2) areas where overlay services should be considered whileproviding leeway for discretion by each player.

The shared thinking process between the API provider and the user allowed
them to develop a deeper mutual understanding of their respective positions,
resulting in a concrete discussion.

APIs need to undergo maintenance and updates regularly and as necessary;
accordingly, it is also important to update software development kits (SDKs),
which contain libraries and documents.

Regarding UX, because it is targeted for the wider general public, it is essential
to perceive matters strictly from the users' perspective. Developing a kind of userinterface (UI)/UX that stimulates demand is crucial for CBDC adoption.

[Programmability]
Regarding so-called programmability, it is better to distinguish between (1)programmable payments, which program the procedures of fund transfer that
occur in conjunction with a certain event or transaction, and (2) programmablemoney, which focuses on embedding specific attributes and/or programs in an"object" called monetary data so as to control their behavior individually.



Rather than embedding programs into CBDC itself (programmable money), it
would be appropriate to achieve advanced functions through externalmechanisms such as apps.

15

[Competitive environment in a CBDC ecosystem]When designing a CBDC ecosystem, importance should be placed on thelowering of barriers for participation, allowing for a healthy competitiveenvironment, and on the appropriate sharing of roles between private and public
entities.

[Instant payment capability]With regard to instant payment capabilities of CBDC, attempting the strict
achievement of instant payments might hamper the creation of user-friendly
services.

Whether to achieve instant payment finality is also worth considering withflexibility.

[Ensuring stability and standardization of authentication/authorization]
Authentication/authorization are particularly important, and given that past
security incidents related to retail payments have resulted from vulnerabilities inauthentication/authorization mechanisms, it may not even be an exaggeration
to say that authentication/authorization are the essence of payment.



Unless we adopt a standardized technology for authentication/authorization
and KYC, in the event that vulnerabilities manifest themselves, we would have no
choice but to deal with these individually, which would prove costly in terms ofboth time and labor. We ought to adopt the standard of the time; if today, Fast
IDentity Online 2.0 (FIDO 2.0).17



There is a trade-off in authentication/authorization, specifically, between
convenience and safety.

[Utilization of data in overlay services]17

Data utilization in overlay services might be more useful if data on items
purchased could be used for analysis coupled with the transaction value.



If said data is shared appropriately with other firms, this could have the potential
to support the creation of various applications.



In relation to this, for privacy purposes, the data distribution function for overlay
services -- even if introduced -- should not be built on the foundational platformof the central bank and intermediaries and should be left for the areas outsideof it.



Because obtaining user consent is a prerequisite for such data utilization, it isimportant to establish a solid framework that ensures effective consent.

FIDO is a registered trademark of FIDO Alliance, Inc.
16

[Ensuring interoperability]

While the importance of standardization and interoperability has previously
been shared and stressed among the parties involved, these have not resulted
in success in many cases.

The idea of a clean slate advanatage ought to be leveraged in designing a CBDC
from scratch.

[API sandbox]
At the fifth meeting, the Secretariat provided an overview of Project Rosalind by the
Bank for International Settlements (BIS) and the Bank of England (BOE). The Secretariat's
proposal to launch an API sandbox project (see BOX) as part of WG2's efforts, using
Project Rosalind as a source of reference, has attracted interest from members.
Figure 11. WG2 agenda and presenters
Date
1st

2nd

3rd

AgendaSep. 26, 2023 - Overview of the WG

Oct. 17- Concept of CBDC ecosystem

NEC Corporation- Overseas FPS ecosystems

Bank of Japan

Nov. 7 - Embedded finance and the potential of CBDC

Dec. 8 - API policy

5thJan. 18, 2024

6thFeb. 27

7th

Mar. 27

Bank of Japan- Overseas discussion on CBDC ecosystems (with a focus on
Bank of Japan
Europe)- Toward a CBDC ecosystem
4th

Presenter

Infcurion, Inc.
Money Forward, Inc.
Fukuoka Financial Group, Inc.

- BIS-led Project RosalindBank of Japan- Presentation

Merpay, Inc.

- API sandbox project

Bank of Japan- Potential use of CBDC

MUFG Bank, Ltd.

- Architecture and process requirements for development ofSony Corporation
CBDC- Challenges of CBDC social implementation from the viewpoint
TIS Inc.
of regional currencies in the Aizu region

3.2.3 Next steps
Going forward, WG2 will continue to consider and discuss the potential of overlay
services and the features of CBDC as "an enabler for services" while being increasingly
conscious of the implications of insights gained from case studies. In this process,17

members will pursue the right balance of stability, safety, convenience, and scalability of
a CBDC ecosystem. They will also discuss whether opportunities of leveraging newtechnologies and building new systems can bring greater convenience and scalability
while continuing to ensure stability and safety. Furthermore, leveraging the expertise of
members, the Bank and volunteer members of the WG have built a sandbox(experimental environment) related to APIs with reference to overseas cases. The WG will
discuss in greater detail how to provide overlay services for CBDC (see BOX).

18

(BOX) Approaches to developing an API sandbox (experimental environment)
Since April 2024, the Bank and volunteer members of WG2 have prepared an experimental
environment in the cloud with overlay CBDC services in mind and have been developing various API
functions. This project is separate from that involving a system for the pilot program described above(2. Development of a system for the pilot program and experimentation) and is an attempt to focus
on the external coordination of a CBDC system through APIs and to discuss the functional scalabilityof CBDC while gaining hands-on experience (BOX Figure). Specific examples and use cases of overlay
services are also expected to be discussed, taking into account the functionality of the built APIs.
(BOX Figure) Conceptual model of API sandbox
User (virtual)
Device and app (virtual)

Overlay services layer＝ cloud areas prepared andmanaged by participants…

Additional API endpoints…

DBs required for
API execution

Private sector systemproviding overlay services…

SandboxFoundational layer＝ cloud area prepared andmanaged by the Bank

System that combines
central system andintermediary system

Fundamental API endpoints

Pay

Fund

Defund…

LedgerLooking at developments overseas, the BIS Innovation Hub and the BOE have also been working
on a project to build API prototypes with private sectors (Project Rosalind), building functions such asaccount management, balance inquiries, funding and defunding, aliases, and programmability, andconsidering use cases with participants on this basis. The findings suggest that a set of simple core
API features are capable of supporting a variety of use cases. This has significant implications for
system design, for example, how simple API features should be designed to bring about highfunctional scalability for the CBDC ecosystem as a whole.

193.3 [WG3] "KYC and user authentication/authorization"
3.3.1 Overview (Figure 12)
Know Your Customer (KYC) and authentication/authorization are fundamental to thesafe and secure use of payment services. Since its first meeting in October 2023, WG3
has held six meetings (as of March 2024). Through their discussions, members have aimed
to grasp an understanding of KYC, anti-money laundering and combating the financing
of terrorism (AML/CFT), and user authentication/authorization processes in existing
payment services as well as the operational challenges they face in this regard, and to
gain technical and procedural insight into KYC and authentication/authorization for apotential CBDC system while introducing the latest technical developments and trends.
Figure 12. Overview of WG3
1stmeeting(i) Sharing existing
methods and processes(ii) KYC and authN/authZin a CBDC system(i) Outline(ii) Outline

Gain an understanding of KYC, AML/CFT, andauthentication/authorization processes inexisting payment services, explore latest
technological developments in the respective
fields, and deepen knowledge of necessary
processes in a CBDC system

Obtain insight into the characteristics of
KYC and authentication/authorization in
a CBDC system, considering risks andusability in the existing processes

TBD

3.3.2 Summary of discussions (Figure 13)
Scope and assumptions for discussions (1st meeting)
The Bank provided an overview, the scope, and the assumptions for the group's
discussion.
The following views were expressed by WG members in response.
With regard to KYC, the underlying risks vary depending on the aims of payment
services using CBDC; it is therefore necessary to respond accordingly.

Additional measures might be required in some cases, for example, whererequired documents for the identification process differ depending on suchfactors as whether the scope of users is limited to residents or includes foreign
travelers.
In order to ensure efficient discussions within a limited time frame, the Bank
responded that it would be preferable for certain cases to be discussed ahead20

of others, namely, situations where CBDC is used for domestic payments byresidents in Japan and where various procedures are not conducted in person.
KYC and AML/CFT in existing payment services (2nd through 5th meetings)
WG members gave presentations on user actions and operational processes
regarding identity proofing and authentication in KYC in existing payment services aswell as on current AML/CFT processes and their latest developments. The Bank also gavea presentation on overseas discussions concerning topics related to the WG.18
A summary of the views expressed by WG members on each topic is as follows.
[Identity proofing and authentication]

As for the effectiveness of identity proofing and authentication, it is important
to determine the required level based on potential risks and to adopt a method
tailored to meet that level.

At the same time, assessing the fitness of the methods and technologies to be
used might prove challenging, as is the case with striking the right balance
between usability and security given their trade-off.

Regarding the specification of identity proofing and authentication, there would
be room for considering efficient systems through standardizing noncompetitive components of the system, which would be separated fromcompetitive components.

[Necessity of security measures and guidelines]

18

Considering that a security hole in even a portion of the service providers isprone to affect payment services as a whole, it is necessary to incorporate crosscutting guidelines with reference to case studies abroad in order to maintain acertain level of security.

With regard to preventative measures for illicit use, it would be preferable toenable information sharing among service providers on threats andcountermeasures as well as to contribute to the sound operation of service
providers as a whole.

It is necessary to establish a structure that allows security measures to be
implemented swiftly in response to changes in malicious attacks.

As security measures become obsolete over time, it is necessary to not only takeadditional measures based on the reality of illicit use but also take into accountrisks that are not limited to online fraud, which include forged identification
documents and defrauded PIN numbers.

European Central Bank, "A stocktake on the digital euro" (October 2023).
21



It is necessary to conceive of possible scenarios of illicit use when discussing thedemarcation of responsibilities among relevant parties in the event that illicit use
is detected.

[Universal access]While completely online transactions and procedures via web browsers and apps
are proliferating every year, from the viewpoint of universal access, assistance inperson or by phone continues to be in demand to serve elderly users.

[AML/CFT and KYC processes]Given the highly public nature of CBDC, the sharing and collaboration of datacollected by each intermediary, and utilizing this to support AML/CFT measures,
might be an option.

When comparing situations where KYC processes are managed by individualintermediaries with ones where they are managed by a joint central unit, thelatter seems more reasonable in terms of work efficiency. Nevertheless, it should
be noted that there is a need to obtain consent from customers when collecting
their personal information and to take careful consideration regarding theprotection of customer privacy.
Figure 13. WG3 agenda and presenters
Date

1st
2nd

3rd

AgendaOct. 25, 2023 - Overview of the WG
Nov. 21

Dec. 11- User action and operational process relating to KYC andauthentication in existing payment services- Overseas discussion relating to this WG ("A stocktake on
the digital euro")

4th

Jan. 24, 2024 - Existing AML/CFT processes and latest developments

5thFeb. 15 - Existing KYC processes and latest developments

6th

Mar. 25 - Existing authentication processes and latest developments

PresenterBank of JapanNTT DOCOMO, INC. et al.
Aeon Bank, Limited
MUFG Bank, Ltd.
Bank of Japan
Microsoft Japan Co., Ltd.
Mizuho Bank Ltd.
NEC Corporation
Sumitomo Mitsui Banking
Corporation
SECOM Co., Ltd.
JAPAN POST BANK Co., Ltd.

22

3.3.3 Next steps
As next steps, WG3 will delve into each theme, such as authentication/authorizationuse cases, to gain insight into the methods and features of KYC andauthentication/authorization with regard to CBDC.

23

3.4 [WG4] "New technologies and CBDC"
Since its first meeting in January 2024, WG4 has held a total of two meetings (as ofMarch 2024), focusing on new technologies possibly relating to CBDC and considering a
CBDC system inspired by them.
As is the case with other WGs, the scope of the discussions covers the CBDC systemitself (back-end and front-end layers) as well as the coexistence of CBDC with other typesof payment methods and assets. At the same time, the discussions are expected to focus
on technologies that could be utilized in the future and are not necessarily based on
existing technical assumptions and constraints. Having begun its discussions with a focus
on the back-end layer, the WG will proceed with its exploration of other topics, including
the front-end layer and the coexistence of the CBDC system with other types of payment
methods and assets (Figure 14).
Figure 14. Overview of WG4
Coexistence with other types of
payment methods and assets

Back-end layer

Ledger system－ Alternative data models(such as UTXO)－ Database technologies
supporting a ledger systemStablecoins
Asset tokenization (such as
security tokens)Interoperability with DLT
platforms[Other WGs] Outlook from current perception

Back-end layer
Ledger system

User device(e.g. “wallet”)[WG4] Outlook inspired by new technologies
User

User
Front-end layer
User device

Front-end layer

Other types of
payment
methods andassetsCoexistence

Front-end layer
User device

Back-end layer
Ledger system

Other types of
payment
methods andassetsCoexistence
Coexistence

In discussing the back-end layer, the WG introduces examples of various technicalapproaches related to the data model, such as adopting an Unspent Transaction Output(UTXO) model, which is different from the linking of balances to accounts with respect tothe data model, devising ways of locking and updating data at the time of data update,and exploring alternative database designs (Figure 15).
The following views have been expressed during the discussions to date.
The parallelism of the UTXO model -- one of its strengths -- could be secured toa certain extent by devising a method for updating data even if the model were
account based.

24

The characteristics of the data model could change depending on the assumed
system configuration.
Figure 15. WG4 agenda and presenters
Date

1st

2nd

Agenda- Overview and scope of the WG

Bank of Japan- Characteristics of a UTXO model

SBI R3 Japan Co., Ltd- The future of a UTXO model

SBI R3 Japan Co., Ltd- Recent trends in data models and potential
usage of DLT for CBDC

Coincheck, Inc.

Jan. 30, 2024 Back-end layer

Mar. 13 Back-end layer

Presenter25

3.5 [WG5] "User devices and UI/UX"
WG5 held its first meeting in March 2024. After deepening its understanding of theflow of messages from user devices to intermediary systems, WG5 will explore universal
access and UI/UX in the context of CBDC and discuss how to make it available for anyone
to use, wherever necessary and under various circumstances.
Figure 16. How to proceed with discussions in WG5[Theme 1] Existing payment channels[Theme 2]"Available wherever necessary"・ For example, what kind of
overall design (devices, apps,
networks, etc. ) could be usedregardless of factors such as IT
literacy, age, disability, and accessto a smartphone?
・UI/UX will also be consideredbased on the above.

・ For example, what kind of
overall design would be suitablefor CBDC to be acceptable even in
stores without over-the-counter
terminals?

Devices primarily for
individual users[Theme 4][Theme 3]"Available for anyone to use"

・Specifically, the combination of
store and user devices will be
discussed.

"Available under various
circumstances"
・ For example, what kind of
overall design could be usedeven in times of disaster, poor
mobile reception, and system or
network failure?
・ Specifically, offline payments
will be discussed.

Devices, networks, and gateways
primarily in the store[Theme 5] Other issues
・Topics such as e-commerce and P2P transfer will be discussed accordingly.

Figure 17. WG5 agenda and presenters
Date
1st

Mar. 21, 2024

Agenda- Overview and scope of the WG

PresenterBank of Japan- Existing payment channels and issues Lawson, Inc.

26

4 Conclusion
In the pilot program, the Bank has been conducting experiments and discussions
from a broad perspective based on the two pillars of "development of a system for thepilot program and experimentation" and the "CBDC Forum."Taking into account the discussions at the CBDC Forum, the Bank will proceed further
with efforts to develop the system. The CBDC Forum also assumes the establishment ofadditional WGs, namely, a WG for considering the conversion between CBDC and otherpayment instruments such as electronic money (provisional name: horizontal coexistenceof CBDC and other payment instruments) and a WG for considering the operational flowof basic functions and the conversion between cash and CBDC (provisional name:operational flow of basic functions) (Figure 6). The latter is expected to be formed andmanaged while considering the continuity of discussions in WG1.
Whether to issue a CBDC in Japan should be decided by discussions among the
public. The Bank will continue to thoroughly explore CBDC with a view to providing abasis for such discussions.

27

(Appendix) CBDC Forum member list
Aeon Bank, Limited
Infcurion, Inc.
Canal Payment Service, Ltd.
Coincheck, Inc.
Cotra Ltd.
JCB Co., Ltd.
THE SHIZUOKA BANK, LTD.
Joyo Bank, Ltd.
The Shinkin Banks Cooperative Center
The Shinkin Banks Information System Center Co.,Ltd.
SECOM Co., Ltd.
Seven Bank, Ltd.
Japanese Banks' Payment Clearing Network
Sony Corporation
SoftBank Corp.
Soramitsu Co., Ltd.
Dai Nippon Printing Co., Ltd.
Daiwa Securities Co. Ltd.
Daiwa Institute of Research Ltd.
Chiba Bank
Tokio Marine & Nichido Fire Insurance Co., Ltd.
Toyota Financial Services Corporation
TradeWaltz Inc.
Nudge Inc.
NEC Corporation
IBM Japan, Ltd.
Japan Securities Clearing Corporation
Microsoft Japan Co., Ltd.
Nomura Securities Co., Ltd.
Nomura Research Institute, Ltd.
Panasonic Connect Co., Ltd.
EAST JAPAN RAILWAY COMPANY

Hitachi Solutions, Ltd.
Hitachi Channel Solutions, Corp.
FeliCa Networks, Inc.
Fukuoka Financial Group, Inc.
Money Forward, Inc.
Mizuho Bank Ltd.
Mitsui Sumitomo Insurance Co.,Ltd.
Sumitomo Mitsui Banking Corporation
Sumitomo Mitsui Trust Bank, Limited
MUFG Bank, Ltd.
Merpay, Inc.
JAPAN POST BANK Co., Ltd.
The Bank of Yokohama,Ltd.
Rakuten Payment, Inc.
Resona Holdings, Inc.
Lawson, Inc.
Lawson Bank, Inc.
au Payment Corporation
BIPROGY Inc.
BOOSTRY Co., Ltd.
Datachain, Inc.
JPX Market Innovation & Research, Inc.
NRI SecureTechnologies, Ltd.
NTT DATA Japan Corporation
NTT DATA Financial Technology Corporation
NTT DOCOMO, INC.
PayPay Corporation
Ridgelinez Limited
SBI R3 Japan Co., Ltd
Startale Labs Japan KK
TIS Inc.
TOPPAN Edge Inc.
（as of March 2024）28