Untitled - Fintech Facilitation Office - Hong Kong Monetary Authority

118 Pages·2017·1.32 MB·English

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