Whitepaper 2.0 on Distributed Ledger Technology Annex Table of Contents 1 2 Table of Contents Table of Contents Annex A Trade Finance Contribution by Deloitte Consulting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Annex B Digital Identity Management on DLT by Hong Kong Applied Science and Technology Research Institute Company Limited . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Annex C BOCHK Mortgage Loan Application by Bank of China (Hong Kong Limited) . . . . . . . . . . . . . . . . 33 Annex D Six Control Principles for Financial Services Blockchains by Deloitte . . . . . . . . . . . . . . . . . . . . . . 38 Annex E Distributed Ledger Technology Security by PwC Hong Kong. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Annex F Innovative Application of Law to Facilitate DLT by Technology Committee of The Law Society of Hong Kong. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Annex G Blockchain & Liability by Dirk A. Zetzsche, Ross P. Buckley and Douglas W. Arner. . . . . . . . . . . 97 Annex A Trade Finance Contribution Author Deloitte Consulting 44 TTrraaddee FFiinnaannccee CCoonnttrriibbuu(cid:415)(cid:415) oonn Proof-of-Concept — Trade Finance and second, issues relating to the provenance of the relevant goods. In today’s world, a company After considering the benefits of deploying DLT in can use the same purchase order (“PO”), usually in trade finance in the first Whitepaper, the HKMA the form of paper documents, to obtain financing formed a working group involving five leading banks from multiple banks by using forged trade-related in Hong Kong, namely Bank of China (Hong Kong) documents, which are hard to detect. A recent Limited (“BOCHK”), the Bank of East Asia Limited case involved an invoice being fabricated for invoice (“BEA”), Hang Seng Bank Limited (“HASE”), the financing in which a bank lost US$700 million. Hongkong and Shanghai Banking Corporation Limited With banks facing the threat of such enormous (“HSBC”), and Standard Chartered Bank (Hong Kong) fraud losses, many corporates, especially small and Limited (“SCB”). The working group commissioned medium enterprises (“SMEs”), are unable to obtain Deloitte Advisory (Hong Kong) Limited (“Deloitte”) to financing for their normal operations. This in turn is develop a DLT prototype with the goal of visualising reducing the total volumes of production and trade in the target operating model and evaluating the the market. feasibility of the technology and its commercialisation potential. Additionally, trade finance processes today remain very labour-intensive, involving large amounts of Under the leadership of the HKMA, the working paperwork and a non-standardised workflow. The group deliberated on issues of regulatory uncertainty process of the transfer of assets is opaque, and in relation to the operating model, and spearheaded payments are frequently delayed and error-prone, efforts to solve real business problems. Given the resulting in very high costs for operating a trade scale of the participating banks within the global finance business. Those involved in international trade finance market, the working group was able trade are eagerly looking for breakthroughs that to adopt a global perspective. The Proof-of-Concept could enable them to cut time and costs in such (“PoC”) work has not just involved the development transactions. of a technology prototype, but also a thorough investigation of how DLT can potentially address DLT offers a revolutionary solution to improve trade a wide range of business, regulatory, legal, and finance fundamentals and boost trade in general. As technical issues related to trade finance. mentioned, DLT allows all players in the ecosystem to share customer information and transaction histories 1 Introduction securely over a distributed data infrastructure, Reportedly, US$16 trillion worth of global trades take without compromising customer privacy or sensitive place annually, but only one quarter of that amount business information. The ecosystem participants (US$4 trillion) is financed by banks. Despite this, can be certain of the digitised trading documents the World Trade Organization (WTO) has estimated being real, and are informed in a timely manner of that 80% to 90% of trades actually need financing. the progress of the manufacture, delivery and arrival Two major reasons for trades not being financed of the goods. Banks can therefore provide working are, first, a lack of trust among participating parties, capital financing appropriately along the supply chain. Trade Finance Contribu(cid:415) on 5 DLT comes with a feature called smart contracts. • To create alerts on duplicated financing to Smart contracts allow for the automatic execution reduce fraud loss; of business logics based on specified events. Many events occur throughout the trade finance process, • To automate selected manual processes such as the delivery of goods, the issuance of an with smart contracts and reduce the human invoice, and the receipt of payment. These events effort required for invoice reconciliations; are currently followed by manual reconciliations and and other operational tasks. Smart contracts offer the potential for automating these processes, reducing • To protect customer privacy and sensitive human error and increasing efficiency. business information from other players in the network, and allow only authorised At the beginning of 2017, the working group formed access to privileged data. by the five leading banks and the HKMA decided to ascertain both the business value and the technical The five banks actively participated in both the feasibility of developing a DLT platform for trade business and technical streams in order to resolve finance. Deloitte was then selected by the banks to issues relating to data standardisation, process flow be their technology partner. The Proof-of-Concept differences, interoperability of different technologies, project was completed in March 2017. etc. The enthusiasm of the working group members, the capabilities of the consulting partner, and strong The research project was structured into two support from the HKMA resulted in the great success streams, a business analysis stream and a technology of the project in a short period of time. Within eight development stream. The business analysis stream weeks, a trade finance platform was developed with focused on developing the case for business, studying two layers: a presentation layer that illustrated the the commercialisation options, and resolving various end-to-end user experience with the platform, and legal, compliance, data privacy, and governance an underlying DLT layer that distributed data across issues. The technology stream focused on developing nodes while protecting data security and integrity. an end-to-end prototype using an agile software development methodology. Design and methodology The trade finance DLT platform leveraged a trade Intensive discussions were then conducted to collect finance prototype developed by Deloitte called the key requirements from the major banks. As “Deloitte Mercury”. It was structured in two layers. suggested in the first Whitepaper, the PoC work The underlying layer was for data distribution and covered the financing of trade under open account consensus facilitation using an open source DLT terms, including both pre-shipment and post- network, such as Ethereum or Hyperledger. These shipment financing. Goals included the achievement networks have their own Application Programming of the following features leveraging the data Interface (“API”) for system integration. On top of distribution nature of DLT: these were built another layer of APIs specific to trade finance (such as fraud detection mechanisms). • To share the status of each transaction along These APIs are standardised and can be accessed the process to all trade participants in the from a common software library by all DLT network ecosystem, in order to prove the authenticity participants. of all trade documents, e.g. POs, bills of lading and invoices; 6 Trade Finance Contribu(cid:415) on Small/Medium OLopgeirsa(cid:415)tcosr FoFrrweiagrhdter EnterprisCelsi,e Cnotsmmercial Corporate Corporate Corporate SmEnaltle/Mrperidseiusm Regulator ors Act UI UI UI UI UI UI UI Mercury Integra(cid:415)on Layer Front ERP End nology Stack LSoygsitse(cid:415)mcs FSohFrriDwpeamiagtrahedntetr PBlaaCn(cid:414)okoriernmg PFlTianr(cid:414)aaondrceme PFlTianr(cid:414)aaondrceme PDFlTiaenr(cid:414)laaoondi(cid:425)rcemee PFlTianr(cid:414)aaondrceme FaPScrTeiorlriavtviadidc(cid:415)eeeorn h ec T Connector Connector Connector Connector Connector Connector Connector Trade Trade Trade Trade Trade Finance Finance Finance Finance Finance Mercury DLT DLT Trade Finance DLT (Dapp) DLT DLT DLT 2.0 (Dapp) (Dapp) (Dapp) (Dapp) (Dapp) Trade Trade Trade Trade Trade Finance Finance Trade Finance DLT Node Finance Finance Finance DLT Node DLT Node DLT Node DLT Node DLT Node NodeOperators CoBCoLruoorsdgktiieonsrm(cid:415)aactgeoserrs, FoFrrweiagrhdter Bank CorLpaorrgae(cid:415)on SmEanltl/eMrperdisieum HKMA Figure 1: T he PoC developed during the research project has two different layers: a layer containing the business logic and an underlying layer with Trade Finance DLT data distribution capability. On top of the data layer is the user interface and whole PoC prototype was hosted on the Amazon business application layer. It is optional for DLT Web Services EC2 cloud infrastructure, with the platform participants to adopt this layer. Large application built on an open-source MEANS stack banks and corporates can integrate their own trade (see Figure 2). MongoDB, AngularJS, and Node. JS finance and trade systems with the underlying data were used to develop the business logic and user layer without using this application layer. Other interface. Through the Web3 module, the application smaller players such as SMEs who choose not to be communicates with the underlying Ethereum connected via a particular banking portal can use network through remote procedure calls (RPC). a publicly available trade finance workflow system to conduct business. Government authorities can retrieve real-time data for supervisory purposes directly from the data layer, and will be immune from changes taking place in the business application layer. The PoC prototype was developed on “Ethereum parity”, a private fork of the public Ethereum. The Trade Finance Contribu(cid:415) on 7 App Server (Node JS) EJS Templates Web Sockets Contract Calls Callbacks Event Handling Truffle Database Helper IPFS Helper Web3 Mongoose js-ipfs Node (i.e. Smart Contracts) Mongo IPFS Business Contracts bc-mercury Storage Agreement PO Invoice Shipping Financing Accounts Purchase Orders Buyer Seller Contracts Invoice No(cid:415)fica(cid:415)ons Shipment Helper Contracts Encryptable Persona Owned Shipments Miscellaneous Figure 2: This logical diagram of the network architecture illustrates the underlying MEANS stack of the DLT PoC prototype. Due to the nature of Ethereum, the consensus contracts can indeed reduce the response time for mechanism supported was proof-of-work (PoW) or transaction enquiries. proof-of-stake (PoS). In addition, Passport was used for identity management, while Interplanetary File Another use of smart contracts is to distribute event- System (IPFS) was used for document management. triggered logic among the nodes hosted by the The smart contracts were programmed in Solidity. participants. Finance can be provided to customers more promptly according to the “triggering events” 3 Results and discussion that are built into the smart contract. As a result, transaction transparency is improved and banks can In the following sections, the results of the three use provide financing to customers in a faster and more cases identified in the first Whitepaper are described, efficient manner. and an overview of the perceived benefits given. The chapter concludes with a discussion of some 3.2 Tracking of trade transaction statuses considerations that arose during the research project. The objectives of this sub-use case were to enhance 3.1 T he use of smart contracts in open account trade the visibility of the goods and the flow of funds in a transaction, thus lowering the risk of fraudulent A trade transaction is normally formalised by a PO, transactions or financing. The DLT solution proposed which sets out the trade terms on which banks by the working group was to store and share key determine when and to what extent financing trade documents and information on the DLT should be offered to the buyer and seller. The use network so they are accessible by all stakeholders in of smart contracts has two functionalities. The first the transaction. is to store the various statuses (details in the next section) pertaining to a transaction with a stated During the PoC work, the working group managed to data structure so that an enquiry can be quickly track 14 statuses in six groups in the Mercury Trade made without having to go through the whole trail of Finance DLT platform: records. The PoC prototype demonstrated that smart 8 Trade Finance Contribu(cid:415) on Group Status Submission Purchase Order Confirmation Application Pre-Shipment Financing Approval Ship Order Submission/Confirmation Shipment Goods Departed Goods Arrived Submission Invoice Acceptance Seller Application Seller Approval Post-Shipment Financing Buyer Application Buyer Approval Payment Execution Table 1: Tracked statuses in the Mercury Trade Finance DLT platform Features such as shared repository, multiple read- improved transparency addresses issues of mistrust write access, elimination of intermediaries and among different commercial parties. Second, central authority, as well as timely notifications, the PoC prototype illustrates how fraudulent were all demonstrated. The status of financing, financing, including forged invoices and duplicated goods delivery, and payment were tracked and were collateralisation, can be avoided. transparent to participants in the DLT network. 3.3 Matching of invoices to purchase orders As a result, all participants in the platform have full visibility of the statuses of goods, financing and Paper-based processes such as the preparation of payments. This transparency means it is much invoices require much human effort and are prone harder to forge an invoice because it is virtually to errors, slowing down the trade process. Another impossible to forge all the other supporting records issue considered in the first Whitepaper was the (e.g. POs and bills of lading) that are digitally fact that the data inheritance feature of invoice signed by different participants. The PoC prototype preparation, involving the reuse of data from the PO, successfully demonstrated the benefits of adopting is only possible if the trade documents have been DLT in the trade finance environment. First, the digitised on the DLT platform. Trade Finance Contribu(cid:415) on 9