© Debajani Mohanty 2019
Debajani MohantyR3 Corda for Architects and Developers https://doi.org/10.1007/978-1-4842-4529-3_5

5. Finance Domain—Real-Time e-Auction; Trade Finance and Letter of Credit

Debajani Mohanty1 
(1)
Noida, Uttar Pradesh, India
 

In this chapter, we will discuss real-life use cases that you can refer to for implementing in your business area. Just like Corda let’s start with the finance domain, where Corda is the primary choice among DLTs for implementations in banks and the Fintech industry. Let’s discuss two different use cases: e-auction and trade finance.

Real-Time e-Auction

Since the beginning of human civilization, auctions have been part of our system. An auction is the process where sellable products or services are offered for bid, and usually the highest bidder becomes the winner. The painful parts of an auction are many, and the following are some of them.

  • There could be cancellation-related disputes, as the exchange of money and products or services does not happen in real time.

  • Repudiation could also be a problem in traditional systems, as the user may claim that the bid or offer was not done by him.

  • As the highest bid wins, if any user somehow misses it by a fraction of second even then the trade would not culminate. Hence, automatic settlement is a bare necessity.

  • The entire auction process is not transparent, as the settlement that follows the auction is not accessible to all.

Solution

The Corda-based auction ecosystem shown in Figure 5-1 is a combination of an on-chain Corda ledger and an off-chain traditional database where we add KYC details of each of the organizations and their participants. One organization can have multiple participants, and their user IDs will be associated with every transaction that they participate in.
../images/475793_1_En_5_Chapter/475793_1_En_5_Fig1_HTML.jpg
Figure 5-1.

Corda-based auction ecosystem

The nodes/parties are as follows:

  • Exchange (the auction house)

  • Organization A: Can be an issuer/seller or investor/buyer

  • Organization B: Can be an issuer/seller or investor/buyer

  • Regulation (optional, in fact notary is doing this job for us)

Now in the beginning, the auction house will inject 100 stocks to the ecosystem. Hence, we will need to use a LinearState named StockState , which has the following features:

  • ownerParty

  • linearId

  • userId

  • type

  • quantity

  • offerRate

Before the auction begins, all participants in the organizations must have some deposits ready in their accounts in the off-chain database. Now Participant 1 of Organization A and Participant 2 of Organization B each have USD 1,000 in the beginning. Let’s create a LinearState called CashState with the following properties:

  • ownerParty

  • linearId

  • userId

  • currency

  • amount

  • bidRate

Finally, we will create a LinearState, TradeState, which as the name signifies keeps track of all trades that will occur on the system. The following are its properties:

  • linearId or tradeId

  • buyerParty

  • sellerParty

  • buyerUserId

  • sellerUserId

  • cashId (linearId of CashState)

  • sshareId (linearId of ShareState)

  • noOfShares

  • amount

  • offeredRate

  • bidRate

  • status

  • timeStamp

Now the flows will be as follows:

  • IssueStockFlow: To add stocks to the ledger. Here an output StockState is created and committed to the ledger. We can optionally add a regulator party who can check and approve or delete stocks through smart contract checks.

  • IssueCashFlow: To add cash to the ledger. Here an output CashState is created and committed to the ledger.

  • TradeFlow: The trade will be initiated by a participant from the cash issuer organization with a bidRate equal to or more than offeredRate, and the status will be “Initiated.” Orders can be added or modified between a particular start and end time scheduled for the e-auction.

At the end of the e-auction time slot, the auction house will match the orders, finalize the valid ones, and come up with the best bid rates. This can also be done instantaneously if required.

We can add many contractual obligations, as in the following examples.

OfferedRate should be equal to or more than bidRate.

Only the highest rate among all the bidders will be chosen, and this will culminate into a trade where the status will be updated to “Finalized.”

The regulation node can check the data history and can end the auction by updating the auction end time at any moment if things go wrong or are out of control.

We can come up with modification and cancellation flows as per business requirements. Note that in all transactions, we have the option to use the getParticipants() method in state objects, where we can choose to broadcast the details to all the participants or do it partially.

Advantages

Instead of organizations, the preceding nodes can be representations for agencies or dealers working for a number of individual users. A user can also opt to move from one agent to another; however, all these would be an off-chain process as Corda deals only with the B2B part of the transactions. Here are a few benefits:

  • Smart contracts facilitate real-time settlement of transactions

  • Visibility of the entire trading cycle to each and every participant across the platform

  • Auditing is made painless and superquick

  • No room left for fraud because of high transparency

Live Use Cases

Though most of the live use cases are implemented on Ethereum, people have started to realize the power of Corda, which can be a best fit to give solutions for decentralized auction systems. The following sections present a few examples of how people are working on Blockchain-based e-auction systems.

Trade Finance and Letter of Credit

As per the World Trade Organization, in 2017 $15.5 trillion worth of merchandise exports were transported around the world across sea, air, rail, and road, and up to 80% of this global trade requires financing. Trade finance involves complex cross-border trading with multiple parties such as importers, exporters, banks, financiers, insurers, export credit agencies, and service providers. In such a fragmented environment, many organizations might be doing business with each other for the very first time. As there is no central or intermediary party which can administer the whole process, coordination is cumbersome and investment risks are very high. It’s quite unfortunate that even though trade financing and letters of credit (LoCs) have been integral to doing business for decades, the supporting documentation and paperwork nonetheless have many process inefficiencies that increase costs, risks, and delays for all participants.

In such cases, an LoC is usually used as a method of payment in international trade, mostly to minimize the overall risk to businesses. The entire process is represented in Figure 5-2.
../images/475793_1_En_5_Chapter/475793_1_En_5_Fig2_HTML.jpg
Figure 5-2.

Trade finance and LoC work flow

The entire process is executed as follows:
  1. 1.

    Sales Contract: Buyer (applicant/importer) from New York and seller (beneficiary/exporter) from London mutually agree to do some delivery-against-payment trading that involves shipping of deliverables among different countries.

     
  2. 2.

    LoC Application: Buyer gets connected to a bank in the UK (termed buyer’s bank or issuing bank) for an LoC.

     
  3. 3.

    LoC Issuance: The issuing bank prepares and sends the LoC to the bank in the USA (termed seller bank or advising bank).

     
  4. 4.

    Advising LoC to Seller: The advising/seller bank does verification and discusses the same with seller for any modifications.

    Note The beneficiary and the advising bank must be located in the same country.

     
  5. 5.

    Finalization: There is a cycle here between both banks and buyer and seller; the LoC is finalized.

     
  6. 6.

    Shipment: Once all parties agree upon the LoC, the seller commences shipment of the goods as per the LoC contract. On delivery, the seller receives a delivery confirmation document. The seller provides that delivery confirmation receipt to the advising bank.

     
  7. 7.

    Dispatch Receipt: The advising bank dispatches the receipt to the issuing bank.

     
  8. 8.

    Payment at Maturity: The issuing bank verifies the delivery as per contract; if everything is fine, then payment is made to the advising bank.

     
  9. 9.

    Closure: The issuing bank transfers the payment to the seller as agreed and keeps its commission.

     
The preceding describes the happy path. The LoC is a contract that gives risk coverage to both buyer and seller.

  • Seller Protection : What if the buyer is unable to pay after delivery of goods as per contract? The issuer bank will do so upon the buyer’s behalf as per the contract.

  • Buyer Protection : What if the seller is unable to deliver the goods on time or up to quality? In that case, a penalty is paid to the buyer.

Also, the preceding scenarios could be much more elaborated to introduce prepayment and purchase order as well as the involvement of many more parties in the supply chain space such as shipper, customs, warehouse, insurance company, and so on.

Solution

Through Corda, we can provide a common ledger for all parties in an LoC. Let’s consider the following nodes/peers/organizations to start with.

  • Buyer organization

  • Issuing bank

  • Seller organization

  • Advising bank

  • Port 1

  • Port 2

First of all, we will create a LetterOfCreditApplicationState that all the four primary stakeholders have to sign. It can have the following variables:

  • IBuyer Organization (Party)

  • Issuing Bank (Party)

  • Seller Organization (Party)

  • Advising Bank (Party)

  • List of Ports (Parties)

  • expiryDate

  • portOfLoading

  • portOfDischarge

  • descriptionOfGoods

  • documentsRequired

  • amount

Then, another LetterOfCreditDeliveryState signifies the status of delivery of goods. This gets updated as the goods are shipped and gets loaded and unloaded port by port until they reach their destination. All stakeholders have to track this for fulfillment of the order and payment. It can have the following variables.

  • Applicant (Party)

  • Beneficiary (Party)

  • advisingBank (Party)

  • issuingBank (Party)

  • status (Party)

  • paymentAmount

  • applicationDate

  • expiryDate

  • portOfLoading (Party)

  • portOfDischarge (Party)

  • locId

  • linearId

Finally, we can have a ReceiptOfGoodsState that will be generated by the final port where deliverable goods reach as per contract. The variables it should contain are as follows:

  • Applicant (Party)

  • Beneficiary (Party)

  • AdvisingBank (Party)

  • IssuingBank(Party)

  • timeOfDelivery

  • descriptionOfDeliverables

  • locId

  • linearId

The flows can be as follows:

  • LoCApplicationFlow: LetterOfCreditApplicationState is created

  • LoCApprovalFlow: LetterOfCreditApplicationState is approved

  • ShipmentFlow: LetterOfCreditDeliveryState is created and updated from time to time till goods reach destination

  • PaymentFlow: LetterOfCreditDeliveryState status is updated with payment

Advantages

For many reasons, Corda seems to be the number-one choice among Blockchain and DLT technologies for trade financing and LoC applications.

  • Data is private and is shared only between the nodes concerned with the transaction and its rightful owner.

  • Blockchain reduces the overall time of settlement from many days to a few hours.

  • Reduced risk of currency fluctuation. The payment can be agreed as per the date and time of delivery and as per the rate of international currency exchange at that time, which the ledger can find out on the spot.

  • Fraud control, as all parties are on the same page and any discrepancy can easily be shared between concerned parties or among all parties in real time.

Live Implementations

Here are some of the live implementations of Blockchain in trade finance, though some of them are built on other Blockchain platforms. Similar use cases can be executed using Corda too.

  • In 2016, a Blockchain-based trade finance platform was announced between Ornua (formerly the Irish Dairy Board) and Seychelles Trading Company, which was built on a platform developed by Israeli startup, Fintech Wave. With the use of Blockchain, the trading cycle of seven to ten days has now been reduced to less than four hours.

  • Similarly on 6 July 2017, Japanese conglomerate Marubeni Corporation and Sompo Japan Nipponkoa established a Blockchain-based trade finance DApp that worked between stakeholders of two different countries (Australia and Japan).

  • Danish MNC Maersk has also come up with a similar platform for shipping goods between different countries and continents.

  • HSBC India and ING Bank Brussels have executed a Blockchain-enabled live trade finance transaction jointly with Reliance Industries and Tricon Energy.

References