Project Stella and the impacts of fintech on financial infrastructures in Japan

Kishi, Michinobu Working Paper Project Stella and the impacts of fintech on financial infrastructures in Japan ADBI Working Paper Series, No. 1017 Provided in Cooperation with: Asian Development Bank Institute (ADBI), Tokyo Suggested Citation: Kishi, Michinobu (2019) : Project Stella and the impacts of fintech on financial infrastructures in Japan, ADBI Working Paper Series, No. 1017, Asian Development Bank Institute (ADBI), Tokyo This Version is available at: https://hdl.handle.net/10419/222784 Standard-Nutzungsbedingungen: Die Dokumente auf EconStor dürfen zu eigenen wissenschaftlichen Zwecken und zum Privatgebrauch gespeichert und kopiert werden. Sie dürfen die Dokumente nicht für öffentliche oder kommerzielle Zwecke vervielfältigen, öffentlich ausstellen, öffentlich zugänglich machen, vertreiben oder anderweitig nutzen. Sofern die Verfasser die Dokumente unter Open-Content-Lizenzen (insbesondere CC-Lizenzen) zur Verfügung gestellt haben sollten, gelten abweichend von diesen Nutzungsbedingungen die in der dort genannten Lizenz gewährten Nutzungsrechte. Terms of use: Documents in EconStor may be saved and copied for your personal and scholarly purposes. You are not to copy documents for public or commercial purposes, to exhibit the documents publicly, to make them publicly available on the internet, or to distribute or otherwise use the documents in public. If the documents have been made available under an Open Content Licence (especially Creative Commons Licences), you may exercise further usage rights as specified in the indicated licence. https://creativecommons.org/licenses/by-nc-nd/3.0/igo/ ADBI Working Paper Series PROJECT STELLA AND THE IMPACTS OF FINTECH ON FINANCIAL INFRASTRUCTURES IN JAPAN Michinobu Kishi No. 1017 October 2019 Asian Development Bank Institute The Working Paper series is a continuation of the formerly named Discussion Paper series; the numbering of the papers continued without interruption or change. ADBI’s working papers reflect initial ideas on a topic and are posted online for discussion. Some working papers may develop into other forms of publication. The views expressed in this paper belong solely to the author and do not necessarily represent those of the Bank of Japan. Suggested citation: Kishi, M. 2019. Project Stella and the Impacts of Fintech on Financial Infrastructures in Japan. ADBI Working Paper 1017. Tokyo: Asian Development Bank Institute. Available: https://www.adb.org/publications/project-stella-impacts-fintech-financial-infrastructures-japan Please contact the authors for information about this paper. Email: michinobu.ki[email protected] Michinobu Kishi is associate director-general at the Payment and Settlement Systems Department of Bank of Japan. The views expressed in this paper are the views of the author and do not necessarily reflect the views or policies of ADBI, ADB, its Board of Directors, or the governments they represent. ADBI does not guarantee the accuracy of the data included in this paper and accepts no responsibility for any consequences of their use. Terminology used may not necessarily be consistent with ADB official terms. Working papers are subject to formal revision and correction before they are finalized and considered published. Asian Development Bank Institute Kasumigaseki Building, 8th Floor 3-2-5 Kasumigaseki, Chiyoda-ku Tokyo 100-6008, Japan Tel: +81-3-3593-5500 Fax: +81-3-3593-5571 URL: www.adbi.org E-mail: [email protected] © 2019 Asian Development Bank Institute ADBI Working Paper 1017 M. Kishi Abstract Project Stella studies the possible use of distributed ledger technology (DLT) on financial market infrastructures (FMIs). DLT solutions have the potential to improve the safety and efficiency of existing systems, as shown by research undertaken by central banks and FMIs. Yet, balancing performance and network size with the distance between nodes, as in the case of Stella phase 1, or the flexibility of cross-ledger delivery-versus-payment (DVP) using hashed timelock contracts without connection between ledgers and liquidity efficiency, as in the case of phase 2, remains a challenge. Project Stella studies the possible use of DLT for FMIs, including large-value central bank RTGS systems. Phase 1 implemented the processing logic of the standard liquidity-saving mechanisms in a DLT environment, and the analysis found that an application could meet the performance needs of an RTGS system. There is a trade-off between DLT performance and network size or distance between nodes. DLT solutions have the potential to strengthen resiliency and reliability. In phase 2, the project team proved that cross-ledger DVP could function even without any connection between individual ledgers. Hashed timelock contracts and digital signatures would be used to achieve interoperability between ledgers, while liquidity efficiency and settlement speed may be negatively affected as a result. DLT solutions have the potential to improve safety and efficiency of existing systems adopted at FMIs, yet balancing diverse system requirements demands careful analysis and consideration. As shown by increasing research and proofs-of-concept on DLT undertaken by many central banks 1 and securities exchanges in major jurisdictions, there are both opportunities and challenges for further exploration. Keywords: distributed ledger technology, financial market infrastructure, information technology innovation JEL Classification: G2, G15, F65, O16 1 See Figure 6 of BOJ (2018). Between the projects run by central banks, there is a difference in terms of industry participation and collaboration. Jasper III, for example, was commissioned by Payments Canada, TMX Group, and Bank of Canada in collaboration with delivery partners Accenture and R3. See Payments Canada et al. (2018). Project Stella is undertaken by the European Central Bank and BOJ, with technical advice from vendors (see footnote 10). ADBI Working Paper 1017 M. Kishi Contents 1. INTRODUCTION ......................................................................................................... 1 2. ENGAGEMENT OF THE BANK OF JAPAN IN THE PROMOTION OF FINTECH ..... 1 2.1 Establishment of the Fintech Center ............................................................... 1 2.2 Information Dissemination and Participation in International Discussions ...... 1 2.3 Research and Studies on Fintech ................................................................... 2 3. PROJECT STELLA ..................................................................................................... 2 3.1 Overview ......................................................................................................... 2 3.2 Main Findings of Phase 1 ................................................................................ 4 3.3 Main Findings of Phase 2 ................................................................................ 6 4. CONCLUSION ............................................................................................................ 8 REFERENCES ....................................................................................................................... 9 APPENDIX ............................................................................................................................ 10 ADBI Working Paper 1017 M. Kishi 1 1. INTRODUCTION Information technology (IT) innovation, global developments of various cashless payment means, including mobile payments, the emergence of crypto-assets, and distributed ledger technology (DLT) all have ramifications for central banks.1 Central banks are responsible for the stability of payment and settlement systems. They also conduct oversight on major financial market infrastructures (FMIs). From this perspective, they strengthen market infrastructures, financial systems, and IT. Central banks also provide basic economic infrastructure through large-value and securities settlement systems in their jurisdictions. Furthermore, they catalyze communication and cooperation among various bodies such as financial institutions, IT companies, start-ups, and users. In light of these functions, the Bank of Japan (BOJ) has researched fintech; section two explains its promotion of it. The third section introduces two reports of the European Central Bank’s (ECB) and BOJ’s joint Project Stella research study, which focuses on the implications of DLT on FMIs, specifically large-scale central bank payment services like BOJ-NET and TARGET2, which are their real-time gross settlement (RTGS) systems. BOJ does not plan to issue its own digital currency; therefore, this topic is not touched upon in this paper.2 2. ENGAGEMENT OF THE BANK OF JAPAN IN THE PROMOTION OF FINTECH 2.1 Establishment of the Fintech Center In April 2016, BOJ established the Fintech Center within its Payment and Settlement Systems department, aiming to link financial practices with advanced technologies and research studies, as well as to meet the demands of the digital world. 2.2 Information Dissemination and Participation in International Discussions BOJ, mainly through the Fintech Center, has held various fintech-related forums and collaborative conferences with the University of Tokyo and other entities.3 These meetings are characterized by: i) multifaceted discussions with a wide range of participants including financial institutions, IT companies, fintech ventures, and academic institutions; ii) important information dissemination platforms by providing presentations and speeches; and iii) a transparent framework such as the disclosure of meeting documents and minutes on BOJ’s website, since open discussion is critical for promoting fintech. Furthermore, BOJ is participating in international forums related to fintech and financial innovations, such as the Bank of International Settlements 1 BOJ Deputy Governor Amamiya (2018). 2 BOJ participated in drafting a report on digital currencies and central bank digital currencies published by the Bank of International Settlements Committee on Payments and Market Infrastructures (CPMI) (see CPMI 2015 and CPMI 2018). 3 BOJ (2018), p. 23–24. ADBI Working Paper 1017 M. Kishi 2 Committee on Payments and Market Infrastructures (CPMI), as well as various domestic conferences. 2.3 Research and Studies on Fintech BOJ is also engaged in various research studies related to fintech, beginning with the publication of the annex series of the Payment and Settlement Systems Report, in addition to its regular edition. Furthermore, BOJ has been making efforts for the timely disclosure of the research outcomes on fintech and financial innovations by using various vehicles such as its working papers and review series. Project Stella is part of these efforts. 3. PROJECT STELLA 3.1 Overview DLT is a set of tools for recording data, such as asset holdings or financial transactions, that allows a network of computers to verify and store updates without a single central management system. Project Stella, announced in December 2016, continues to assess DLT solutions in financial market infrastructures. This section introduces the first and second reports of the collaboration, published in September 2017 and March 2018 respectively (hereafter “phase 1 report” and “phase 2 report”) (see Figure 1).4 Figure 1: Overview of Project Stella Source: Project Stella phase 1 and 2 reports. Project Stella contributes to the ongoing debate concerning the feasibility of DLTs for financial markets.5 This joint research builds on the interest of central banks in ensuring that innovations facilitate safer, faster, and cheaper financial transactions. This project is exploratory within the described scope. The project’s first phase assesses whether specific functionalities of existing payment systems, specifically liquidity-saving mechanisms of BOJ-NET and TARGET2, could be safely and efficiently run in a DLT 4 ECB and BOJ (2017), ECB and BOJ (2018). 5 Japanese FMIs are researching DLT. See addendum of BOJ (2018). ADBI Working Paper 1017 M. Kishi 3 application, focusing on hands-on testing only. 6, 7 The areas of cost efficiency, market integration, and oversight are left for future study. DLT efficiency and safety broadly encompasses the design, functionality, and resource needs of the arrangement.8 Project Stella phase 1 is, however, a first step in the process of assessing DLTs with a limited focus on some facets of both the speed of processing and operational resilience. Furthermore, it should be considered that the analysis contained in the first phase is based on Hyperledger Fabric version 0.6.1, which is a, “developer preview release […] intended to exercise the release logistics and stabilize a set of capabilities for developers to try out”.9 While the first phase test series produced promising results, it should be taken into account that no direct conclusions can be drawn from the test set-up with respect to any potential production use. As of the publication of the phase 1 report, given the relative immaturity of the technology at the time, DLT is not a solution for large-scale applications like BOJ-NET and TARGET2. The objective of the second phase is to explore how the settlement of two linked obligations, such as the delivery of securities against the payment of cash, could conceptually be designed and operated in an environment based on DLT.10 Settlement mechanisms based on delivery-versus-payment (DVP) link the transfer of two assets in such a way as to ensure that the transfer of one asset occurs if and only if the transfer of the other asset also occurs. The settlement is either that both parties successfully exchange those assets, or no transfer takes place. Such a condition is also often referred to as “atomicity” in computer science.11 The second phase of the research examines ways in which DVP can be conceptually designed and technically achieved in a DLT environment drawing on existing models, as well as innovative solutions that are being discussed for distributed ledgers. In order to gain practical understanding on DVP functioning on DLT, prototypes were developed using three platforms: Corda, Elements, and Hyperledger Fabric (hereafter referred to as Fabric). The analysis is based on a basic, stylized scenario of two counterparties exchanging securities against cash.12 Phases 1 and 2 do not attempt to replicate existing payment and securities settlement systems and are not geared toward replacing existing central bank services with DLT-based solutions. Legal aspects have not been the object of the study. 6 Liquidity-saving mechanism smart contracts programmed and run by BOJ and ECB were designed based on queuing and bilateral offsetting mechanisms in BOJ-NET and TARGET2, respectively. 7 For Project Stella phase 1, ECB conducted its experimental work in a virtualized and restricted in-house test environment, while BOJ used cloud computing services. We programmed and ran smart contracts, and measured the performance of the DLT-based solutions. Each fictitious participant in the system was allocated an account and all related information was stored in the ledger. See section 4 of the phase 1 report for test set-up. 8 See CPMI (2017). 9 See release from Hyperledger Fabric dated 16 September 2016. 10 “The authors of the phase 2 report are grateful to R3, IBM and DG Lab for technical advice.” See footnote 2 of the phase 2 report. 11 Atomic operations, as implied by the term’s base meaning, cannot be divided; either all operations are fully performed or they are not performed at all. 12 Similar to phase 1, in the phase 2 test set-up, participants (buyers and sellers of securities) are fictitious. ADBI Working Paper 1017 M. Kishi 4 3.2 Main Findings of Phase 1 3.2.1 DLT-Based Solutions Could Meet the Performance Needs of an RTGS System The analysis found that a DLT application could process payment request volumes comparable to those routed to RTGS systems in the eurozone and Japan. Considering the average traffic of the two centralized payment systems (between approximately 10 and 70 requests per second [RPS]) (see Figure 2), transactions were processed in less than 1 second on average. When increasing RPS up to 250, however, the analysis confirmed that the trade-off between traffic and performance was significant. More generally, tests proved the feasibility of implementing the processing logic of standard liquidity-saving mechanisms (queuing and bilateral offsetting) in a DLT environment. Figure 2: Sample Requests per Second during Peak Hours Source: Project Stella phase 1 report. 3.2.2 DLT Performance Is Affected by Network Size and the Distance between Nodes The analysis confirmed the well-known trade-off between network size and performance. Increasing the number of nodes13 led to an increase in payment execution time. Furthermore, the impact on performance from the distance between nodes was found to depend on the network configuration: provided the minimum number of nodes (quorum) required to achieve consensus was sufficiently close together (see “concentrated” scenario in Figure 3), the effect of dispersion in the rest of the network on latency was limited (see Figure 4). Nevertheless, the nodes on the periphery of the network may produce inconsistencies with the quorum. If the quorum is sufficiently dispersed, the effect on latency will be greater. 13 Nodes, or “validating nodes”, are responsible for gathering and processing transactions to append to the ledger. See annex 2 of the phase 1 report. ADBI Working Paper 1017 M. Kishi 11 4. Following the implemented consensus mechanism of the platform, the submitted first cash instruction is verified and confirmed, and results are written on the ledger in the cash DLT network. 5. Bank A verifies the content of the committed first cash instruction of Bank B. Bank A then creates the second cash instruction (obtaining of the agreed amount of cash) providing 𝑿𝑿, signs it, and submits the signed instruction to the cash consensus mechanism. 6. Following the implemented consensus mechanism of the platform, the submitted second cash instruction is verified and confirmed, and results are written on the ledger in the cash DLT network. At this point, the agreed amount of cash is transferred from Bank B to Bank A. 7. Bank B obtains 𝑿𝑿 specified in the committed second cash instruction of Bank A. Bank B then creates the second securities instruction (obtaining of the agreed amount of securities) providing 𝑿𝑿, signs it, and submits the signed instruction to the securities consensus mechanism. 8. Following the implemented consensus mechanism of the platform, the submitted second securities instruction is verified and confirmed, and results are written on the ledger in the securities DLT network. At this point, the agreed amount of securities is transferred from Bank A to Bank B. Potential Settlement Fail Scenarios Settlement could fail if one of the steps described above is not completed. For cross-ledger DVP with HTLC, this could result in two different risk scenarios. In the first scenario, settlement is not successful and cash and securities are returned to the original holders. In the second scenario, settlement is not successful and one of the counterparties could be exposed to principal risk. In the first scenario (see Figure A.2 when the process is suspended at step 5), settlement fails could occur, for example, where the first securities instruction and the first cash instruction are completed, but Bank A (receiver of cash and generator of the secret) does not submit the second cash instruction within the predefined locking time (1 hour). In this case, while the transfer of both cash and securities is not successful, neither counterparties are exposed to principal risk as the assets are returned to the original holders after the locking time expires. The counterparties would, however, be exposed to replacement cost risk and liquidity risk. ADBI Working Paper 1017 M. Kishi 12 Figure A.1: Process Flow for Cross-Ledger DVP with HTLC DLT = distributed ledger technology, DVP = delivery versus payment, HTLC = hashed timelock contracts. Source: Project Stella phase 2 report. ADBI Working Paper 1017 M. Kishi 13 Figure A.2: Settlement Fail Scenario of Cross-Ledger DVP with HTLC (Process Is Suspended at Step 5) DLT = distributed ledger technology, DVP = delivery versus payment, HTLC = hashed timelock contracts. Source: Project Stella phase 2 report. ADBI Working Paper 1017 M. Kishi 14 Figure A.3: Settlement Fail Scenario of Cross-ledger DVP with HLTC (Process is Suspended at Step 7) DLT = distributed ledger technology, DVP = delivery versus payment, HTLC = hashed timelock contracts. Source: Project Stella phase 2 report. ADBI Working Paper 1017 M. Kishi 15 In the second scenario (see Figure A.3 when the process is suspended at step 7), settlement fails could occur during the process flow where one counterparty (here Bank A) already retrieved the agreed amount of cash and the other counterparty (here Bank B) did not complete the second securities instruction within the predefined locking time (2 hours). In this case, the locking time for the latter instruction will expire and the original holder (Bank A) can refund the locked assets (securities). Ultimately, this counterparty (Bank A) will hold both his refunded assets (securities) and the retrieved assets (cash), while the other counterparty (Bank B) will be exposed to principal risk for his settled assets (securities). In this specific fail scenario, only one leg of the transaction is settled and DVP will not be achieved.3 This scenario illustrates weakness of HTLC and stresses the need for further developments.4 3 Several arrangements may be considered to mitigate such risks. For example, the locking time could be set at a large interval (e.g., 24 hours, 48 hours). A larger difference between the two locking times increases the likelihood of successful settlements, while it also reduces the efficiency in the use of liquidity when a settlement fails. Another approach could be for Bank B to incentivize a third party to send the second securities transaction on its behalf, with the assumption that an instruction with a cryptographic signature can only be changed by Bank B. 4 Monetary Authority of Singapore, in collaboration with the industry, is exploring the use of DLT, which is named Project Ubin. The third report of Project Ubin explores how DVP settlement finality, inter-ledger operability, and investor protection may be realized through specific solutions. One of the differences between Project Stella phase 2 and Ubin’s DVP-on-DLT project is that the latter introduces a dispute resolution mechanism by an arbitrator. The arbitrator would intervene during a process flow when, for example, a buyer of securities is exposed to principal risk, and pass judgement on possible recourse. See Monetary Authority of Singapore et al. (2018). Project Stella phase 2, the report of which was published about 8 months earlier than that of Ubin’s DVP-on-DLT report, does not have such dispute resolution mechanism, as illustrated in the second settlement fail scenario (see Figure 8).