Case Study 3: Chain of Shipping

Distributed blockchain ledger technology offers the potential to mitigate fraud and inefficiencies in the traditional paper-based Bill of Lading system.

Chain of Things will be coordinating an upcoming Case Study focused on how blockchain enabled IoT can help the movement of ‘things’ from A to B. The purpose of this event is to discuss the combination of the Internet of Things and blockchain in the context of trade, shipping and transportation.

Chain of Shipping

The concern about digital legal instruments is that (like most data files) they can be duplicated or hacked. However, bitcoin is a digital file (asset) that is 100% unique, non-replicable, and has never been hacked. Adding that attribute into a digital legal document, such as a Bill of Lading, can only strengthen the security of that instrument. 

Another advantage of a distributed ledger (blockchain) BoL system is that there will be no need for delivery of a physical BoL, and far fewer potential issues that might arise with physical BoL related fraud and theft. 

Further, everyone in the network will have the exact same original BoL that cannot be changed without consensus between all parties. A hacker would need to manually alter every BoL copy synced throughout the BoL blockchain network - a near impossibility. This avoids any disputes over the contents of contracts.

Distributed ledgers also offer the ability to extract certain terms and draft them in computer code in a manner in which ‘the code become law’ and self-executes certain parts of the contract. It is this feature of self-execution of contracts that could prove invaluable in the future for reducing the expenditure on legal disputes.

Lastly, we expect the Internet of Things will play a large role in ensuring compliance with certain contractual terms through the incorporation of ‘Smart Agent’ sensors. These connected devices can be physically attached to the shipment and relay environmental information specific to agreed upon BoL terms to all parties concerned with shipment quality. This adds a significant layer of real time transparency and accountability.

We therefore propose a unique Case Study to build a Smart BoL system that:

1. Will allow for the creation of an enforceable digital BoL contract and title;
2. Will exist on a distributed ledger shared with the contract parties and stakeholders;
3. Will be non-replicable and secure;
4. Will have a self-executing term in the BoL that will trigger an alert based on a connected device sending a signal that the terms have been breached.

Below is a fuller description of the background of the problem facing the transportation industry, the Chain of Shipping Case Study and the mechanics behind the smart contracts we intend to build. 

What is a Bill of Lading?

A Bill of Lading is a legal document issued by the Carrier or agent of the Carrier. The legal instrument is as old as trade itself. It has three main attributes:  

1. Document of Title to the goods: possession of the Bill of Lading is equal to having title in the referenced goods. 
2. Receipt - Evidence that the Carrier has received the goods of a certain quality etc in compliance with the Commercial Contract between the parties
3. Contract of Carriage - Evidence of the Contract of Carriage (CoC) - that the carrier will transport the goods in compliance with the Commercial Contract.

Problems with the current system

• THEFT - BoL is a bearer document of title. This bears a particular risk that anyone who has possession of the BoL has a prima facie claim to the goods. Because possession equals ownership this creates an incentive for BoL theft. 
• FRAUD - Manipulation/alteration of BoL to hide accountability due to shipment damage or other issues.
• INEFFICIENCY - BoL are issued as three original physical documents. One document is managed by the banks involved in trade finance. One document is couriered to the recipient of the goods. And one document is retained by the Carrier. 
• PHYSICALITY - Delay in distribution of the BoLs. Due to the originals only existing in a physical form, this means that the Carrier has to courier one of the originals to the Consignee. This leads to a situation where the goods have arrived at a Discharge port but that the Consignee has not received their BoL. 
• AMENDMENTS - Making amendments to a BoL are complicated. All three BoLs have to be sent to the Carrier who destroys them then issues a new set of BoLs with the intended amendments. 

Dependencies between BoL system and other supporting areas of financial services

Accuracy of a BoL affects Trade Finance documentation

BoLs cannot be viewed outside of the context of trade finance as they work directly with the Letter of Credit to facilitate the sale and transportation of goods. 

When a buyer has entered into a contract to purchase goods, the same buyer will approach their bank (Issuing Bank) to issue a Letter of Credit. This Letter of Credit is sent to the bank of the seller (Receiving Bank) however the Receiving Bank will not accept the Letter of Credit from the Issuing Bank if there are any defects with the BoL. Those defects could be as trivial as the wrong date or Shipper’s details on the BoL - the BoL must be accurate at all times.

Transparency on compliance with terms is delayed

When goods have been shipped and the Carrier confirms that the goods meet the required conditions, the Carrier will issue a ‘clean’ BoL. However, as the goods are in transit, it is difficult for the other stakeholders, including the Buyer and Seller, to understand in real-time the condition of the goods in transit. It is only when the goods reach the Discharge Port that the quality and condition of the goods are reassessed. Based on this lack of visibility over the quality of goods being shipped, there could be, in principle, a need to provide real-time transparency on the status of goods for all interested parties.

Existing solutions

Since 1994 Bolero has evolved the BoL resulting in the first approved electronic format for the legal instrument. Though largely secure and modernized, adoption is still low. At present Bolero does not employ distributed ledger technology for its electronic systems. 

Blockchain - overview advantages

Bitcoin is a decentralised payment system in which the ledger of transactions is maintained by a decentralised network of stakeholders who organize and sync the ledger across thousands of computers. All of the network participants hold a full instance (copy) of the ledger of transactions. This system is highly resilient to manipulation as one would need to hack and alter the ledger on millions of computers to successfully rewrite history.

When new transactions are suggested to the Bitcoin network they go into a ‘pool’. From that pool, certain actors in the network apply their resources to work out difficult mathematical challenges. If an actor succeeds in the challenge, they can prove to the network that they have found the right answer. When the network agrees that the actor has found the right answer then everyone individually updates their original chain of transactions and move to the next ‘block’ of transactions (the Blockchain). 

More detail on how blockchain technology works can be found here: http://www.chainofthings.com/readingmaterial/

A blockchain has multiple ‘originals’

Surprisingly a blockchain is a distributed ledger with each ledger being an original. People do not just have a copy per se of the ledger, everyone in the network has in fact an ‘original’ of the ledger.

This concept is not dissimilar to the BoL which is issued in sets of three originals. However, in this instance a distributed ledger may have 1000 originals depending on the size of the network.

Blockchain security features

There are two key security features about blockchain:

1. First: because the ledger is distributed and ‘original’ you cannot change one ledger without having to change them all. 
2. Second: each transaction (or data) is cryptographically ‘hashed’ before being added to the ledger. Hashing is a excellent way of detecting any changes to the input data that has gone into a file. If a contract dictates that ‘2 tons of soybeans will be sent to Italy’, running it through a hash will produce a unique number. If a trickster changes the ‘2’ to ‘1’ the unique ‘hash’ number will become 100% different.

To date, these basic security features have protected over $10 billion dollars of digital currency (Bitcoin). The same basic security features may very well benefit an electronic BoL system. 

Blockchain Smart contracts

Besides the transaction approval process, Bitcoin is essentially a set of instructions directing network participants to update their ‘original’ Bitcoin ledger. Moving Bitcoin from person A to person B is a simple instruction that states ‘deduct this amount of Bitcoin from User A’s balance and credit User B with this amount of Bitcoin’. No human is required to execute these instructions in Bitcoin as it is done through software. 

In a more modern iteration of this system, Ethereum (an alternative to Bitcoin) provides tools to write complex computer programs on a distributed ledger model. With Bitcoin the ‘smart contract’ element of a transaction is a simple set of instructions to move funds from one username to another username. With Ethereum, the protocol provides a new tool set with its own programming language (Solidity) so that complex rules (smart contracts) can be drafted and executed on a distributed ledger. Ethereum extends the possibilities of what you can do with a BoL.

Smart BoL

A standard BoL written in traditional legal text and signed by the carrier with an electronic signature, could have its terms represented by computer code.

Diagram A. is an example of a contractual requirement to maintain a temperature of less than 20 degrees inside the container as it is being shipped. The code could be written that if the Status of that term of the contract moves from ‘ACCEPTABLE’ (below 20 degrees) to ‘UNACCEPTABLE’ above 20 degrees, this Status change will trigger a payment to compensate the appropriate parties. 

In the same contract it would specify that a certain third party is appointed to provide information about the temperature within the container. This person could be an independent auditor, or in the language of distributed ledgers an Oracle. That Oracle would input into the distributed ledger the temperature of the relevant container and the contract will only change its status if it spots that the Oracle has increased the temperature above 20 degrees.

This smart BoL would therefore in summary enforce certain conditions in the shipping contract. The enforcement of the terms would be final and irreversible as the smart BoL is being run on every computer in the network meaning it is impossible to intervene to appeal the action. This ‘black’ or ‘white’ approach misses the nuances of contractual disputes so most likely the manner in which smart contracts will be leveraged will be make the status change not a trigger for a payment but rather an alert of a potential breach of contract. Instead of direct financial action, the status change could immediately notify all relevant parties and request a third party (human) audit and correction of the temperature issue.

Of importance is the fact that the Smart BoL runs code on a distributed ledger with all the stakeholders involved in a particular shipment. The Shipper, the Carrier and the Receiver all share the same ledger, meaning they all have the same ‘original’ BoL in electronic form and issues surrounding the contract such as a potential breach of a shipping condition are alerted to all parties at once. In this instance there is no fragmentation of information surrounding a factual event - all parties receive critical information at the same time and there is a record of everyone having symmetrical information over the same events. 

In the next section we explore how the Internet of Things can support independent auditors and how the Smart BoL can manage such devices.

Leveraging the Internet of Things

IoT can be fundamental in offering significant transparency into transportation of goods - especially when integrated with smart legal contracts. 

Ideally, a Smart BoL would be coupled with ‘Smart Agents’. These agents are connected sensors that are appointed under the terms of the BoL to monitor certain executable terms in a contract. For example, an executable term may be that the temperature of the container should not exceed 20 degrees (see Diagram A.). A connected sensor that monitors the temperature and relays that data to the Smart BoL in real time, would be placed on the shipment. This approach differs to that of appointing an auditor to check compliance as the Smart Agent provides data in real-time and (unlike a human) is less prone to corruption. 

In practical terms, Smart Agents would work alongside auditors (or Oracles) to ensure full compliance with BoL terms. 

In the case of Diagram A., the Smart BoL would designate certain devices as the monitoring agents of certain terms in the shipping contract. These devices would simply relay data to the Smart BoL, acting as a ‘hardware Oracle’ for shipment climate data.

The data would indicate if the temperature inside the container was above or below 20 degrees. If above 20 degrees, the status of the relevant term in the contract would change from ‘ACCEPTABLE’ to ‘UNACCEPTABLE’. So what happens next? In the world of smart contracts, non-compliance would trigger a payment or force compensation to the aggrieved party. However, as said above, it is infeasible to imagine a binary world of contracts in the near term. Most likely, the status change in the contract would alert the parties or stakeholders in the contract of the potential breach, in which a physical (human) auditor would be dispatched to check the shipment and correct any contractual (temperature) incongruences.

As devices become more secure and dependable, direct economic consequences will flow from a term State Change of a Smart BoL.

Collaborate

Further Case Study details will be released soon. Please contact Chain of Things if you are interested partnering or would like to participate. November event details are located here.