Idea Transcript
Interbank Payments and FinTech
Yuji Kawada Akiko Kobayashi Akihiko Watanabe Shuji Kobayakawa
Joint Conference by the Bank of Japan and the University of Tokyo “FinTech and the Future of Currency” November 18, 2016
Presentation Overview
1. What FinTech means for central banking 2. Application of DLT to interbank payments 3. Issues for further work
* The views expressed in this presentation are those of the authors and do not necessarily represent those of the Bank of Japan.
1
1. What FinTech means for central banking
Central bank money: Monetary base (JPY 413.9 tri)
Deposits at BOJ accounts (JPY 312.8 tri)
Banknotes issued (JPY 96.4 tri)
Coins in circulation (JPY 4.7 tri)
Central bank digital currency?
Distributed ledger technology (DLT) ? * Figures are averages for October 2016.
2
1. What FinTech means for central banking Possible application of distributed ledger technology Central bank digital currency Euro area ECB: Published staff research paper on application of DLT in securities post-trading (April 2016)
UK BOE: Conducted a PoC with the private sector on the transfer of ownership of a fictional asset (June 2016)
University College London: Published a paper on central bank digital currency (RSCoin) (February 2016)
Canada BOC: Launched a project with the private sector to explore the possibility of issuing, transferring and settling central bank issued assets on DLT (June 2016)
Russia BOR: Developed prototype of a networking tool for market participants using DLT (October 2016)
China
Sweden
PBOC: Announced plans to consider issuing digital currency in the long term (January 2016)
Riksbank: Announced intention to investigate the possible issuance of e-krona as a complement to cash (November 2016)
3
2. Application of DLT to interbank payments: Overview of staff study
Objective: To deepen our understanding of the basic characteristics of the distributed ledger technology (DLT) by experimenting with a fictional DLT-based interbank payment system Points of evaluation Performance: how the number of nodes and the amount of traffic affect performance Smart contract (Chaincode): whether complex operational flows can be realized on a DLT arrangement DLT platform used: Hyperledger fabric
* We are grateful for the valuable inputs provided by IBM Japan, NTT Data, and Hitachi in conducting the study.
4
2. Application of DLT to interbank payments: Test environment Environment: virtual machine on a standalone PC Number of validating nodes: 4-16 nodes Consensus algorithm: PBFT (Practical Byzantine Fault Tolerance) Standalone PC (Windows, 64bit, 8GB) Virtual machine(Linux, 64bit, 5GB) Chaincode
REST API Client
- Consensus - Execute chaincode - Update ledger (blockchain, KVS)
Validating Node 検証ノード(VP) 検証ノード(VP) A 検証ノード(VP) B C D
Certification Authority
Authentication for - Participants/nodes - Transactions
5
2. Application of DLT to interbank payments : Process flow Client X (Sender)
Validating Node A
Validating Node B
Validating Node C
Validating Node D
1. Client X sends payment request with digital signature to Validating Node A. Send Payment Request
Receive Payment Request
2. Validating Node A acknowledges receipt of payment request.
3. Validating Node A broadcasts payment request to other nodes.
Receive Payment Request
4. Validating nodes check digital signature, transaction serial number, etc. 5. Validating nodes execute the payment after more than 2/3 of nodes confirm the transaction. 6. Validating nodes record balances to KVS, and add transaction information (payment request, time stamp, etc.) as a new block.
Receive Payment Request
Receive Payment Request
Execute payment
Execute payment
Consensus
Execute payment
KVS
Block -chain
Execute payment
KVS
Block -chain
KVS
Block -chain
KVS
Block -chain
6
2. Application of DLT to interbank payments: Performance Lower performance (longer latency between payment request and ledger update) as the number of nodes increases. Increased delay in latency with increase in payment traffic (RPS, number of requests per second).
It took 12.5 seconds on average to process a traffic of 1,000 RPS under 7 nodes without CA.
7
2. Application of DLT to interbank payments: Performance The extent of delay in latency caused by payment traffic increased with increase in the number of nodes. * Lower performance may be due to limitations in the test environment (e.g., CPU).
Certificate Authority (CA), which issues Transaction Certificates for each transaction, could become a performance bottleneck; however, no significant impact was observed in this study. Block Commit Latency (NoCA, BatchSize=500, Loop=5) RPS10
RPS100
Effect of CA (BatchSize=500, Loop=5)
RPS1000
RPS10
30
RPS100
RPS1000
2.0 1.8 1.6
x19.6
Ratio (CA/NoCA)
Latency (seconds)
25 20
x15.3
15 10
x6.1
1.4 1.2
1.0 0.8 0.6 0.4
5
0.2 0
0.0 4
10 # of Nodes
16
4
10 # of Nodes
16
8
2. Application of DLT to interbank payments: Liquidity-saving features Using “smart contracts” (chaincode), (i) centralized queuing and (ii) bilateral offsetting were programmed.
Payment instruction
Yes
Bilateral Offsetting
(Includes single gross settlement.)
Event-driven No
Settlement
Queue
No
Time-driven
Multilateral Offsetting
Yes
9
2. Application of DLT to interbank payments: Transaction data Liquidity-saving features, using actual transaction data for a high-volume day (March 31, 2016 ), were tested. Traffic reached its peak at around 9:00 with approximately 100 RPS and decreases thereafter. For this study, data for the period of 9:15-9:30 were used (approximately 12,000 transactions). Request Per Second via Queuing-offsetting Accounts on March 31, 2016 # of RPS
Entry-Bilateral Event-Counterparty
Entry-Single Multilateral
Event-Bilateral Cumulative Ratio
Event-Single 100%
90
90%
80
80%
70
70%
60
60%
50
50%
40
40%
30
30%
20
20%
10
10%
0
0% 7:32:42 7:46:04 7:57:08 8:08:11 8:19:14 8:35:32 8:52:21 9:05:55 9:17:11 9:28:47 9:39:59 9:51:47 10:03:23 10:15:58 10:28:18 10:41:12 10:54:24 11:08:14 11:22:56 11:38:13 11:53:39 12:08:12 12:25:22 12:45:27 13:02:38 13:18:42 13:34:43 13:50:35 14:05:38 14:21:28 14:38:06 14:54:05
100
Source: Bank of Japan.
10
2. Application of DLT to interbank payments:Preliminary results Due to limitations in the test environment (insufficient CPU power), it took more than 60 minutes to send the requests for the period of 9:15-9:30, with average latency of 2.1 seconds and maximum latency of 10.8 seconds.
11
3. Issues for further work Tentative results • Increase in the number of validating nodes and transaction volume results in longer latency between payment request and ledger update. • Complex business flows such as queuing and offsetting functionalities can be implemented in a DLT arrangement by using smart contracts.
Issues for further work • Evaluate other aspects of DLT including availability (e.g., whether the arrangement can continue to function in the event under which one or more validating nodes are not properly functioning) • Take into account ongoing improvements in DLT (e.g., next-generation consensus algorithm planned for Hyperledger fabric) • Evaluate potential application of DLT platforms other than fabric • Enhance test environment in order to obtain a more accurate view on factors affecting performance 12
3. Issues for further work
Role of Central Banks Catalyst
Operator Overseer
Financial Market Infrastructure Safety
Efficiency
13