At EHDA our mission is to find new ways to disrupt the trade finance industry. It is only natural that we investigate the opportunities of Blockchain technologies for handling trade relations between a buyer and a seller and how the other actors could interact on the same platform, thus providing benefits to everyone.
In this article I will present how we approached the partnership with one of our clients and what we achieved. A second article will follow to present EHDA views on Blockchain, how it can change Trade Finance and what are the main challenges for adoption.
For many companies managing cashflow can be a challenging task. But even with the perfect cashflow management system there still exist some risks of a buyer becoming insolvent. There are services that can help with cashflow such as factoring, lending, trade credit insurance.
Since the companies proposing these services intervene late in the transaction and therefore suffer from a lack of reliable information. Trade credit insurance companies collect invoices from sellers but that only represent one side of the agreement between a seller and a buyer. Ideally Trade Credit Insurance companies can contact the buyer to confirm the invoice. However, this is not always possible as it is time consuming and not scalable.
We believe that Blockchain can improve the information collection process, and improve the general Trade Finance process. In order to test the idea, we partnered with HSBC GTRF to organize an experiment. Our objective was to evaluate how blockchain could ease the information sharing and synchronization between buyers, sellers, factors and credit insurer.
Our first test requires the seller to create their invoices on a Blockchain. ERPs and platforms like Quickbooks can propose an add-on for managing invoices on a Blockchain. We have already studied the value of invoices created as Smart-Contract in our previous experiments.
Second, for time constraint reasons we decided not to implement access rights because we know that solutions exists (either natively in some DLT technologies like Corda/Quorum, or via data ciphering before sending it to the platform) and we were more focusing on use cases and potential of the technology.
Third, since this is a simulation, we automatically associate an Ethereum address on our private network with the company behind it. Identity/KYC on the Blockchain is a topic of its own that we are also investigating on the side, so it doesn’t make sense to include it in this experiment.
Our solution is the first functional Blockchain based solution that could be used for exchanging relevant information between the stakeholders participating or financing a trade. This solution allows each actor to have access to information of identical quality and verifiability whether they are directly or indirectly involved in the trade.
We built our experiment using an Ethereum private network. But our objective would be to deploy it to a public network.
We first started by organizing meetings with collaborators from the companies, to understand their job and the process.After a few meetings we defined the scope and the specification of the project. We then tasked two developers to work for a few weeks on implementing the solution following the specification, we regular meetings to make sure the development stayed on track with our planning. The Blockchain back end was developed by EHDA, while the front end was developed by HSBC, but we made sure that both teams worked in close collaboration to be able to share the learning.
Since our experiment was focusing more on the insurances and factors side, and studying which interaction we could have among those actors, we didn’t model the whole commercial transaction and just simulated the upload of invoices onto the platform.
Here is a schematic of the whole process.
Illustration of the information flows exchanged between actors and the Blockchain based system
The process goes as follows:
(1) an invoice is uploaded onto the platform by the seller
(2) the buyer approves it (in the setup described in the introduction, the buyer’s approval would be already provided because the only way for the invoice to become an invoice is through the buyer passing a command thus “approving” the invoice by anticipation)
the invoice then becomes available for financing
At this point or in parallel:
(3) the seller asks a credit limit request to an insurer
(4) the insurer can reject, approve, or partially approve for a specific limit and duration
a smart contract is created representing the Trade Credit Insurance policy
Once above 2 steps are done:
(5) the seller can ask for his invoice to be financed and effectively submitted to the factor
(6) the factor can check whether there is a corresponding TCI policy, and if yes can approve or reject the financing
if the factor approves the financing, the invoice smart-contract registers itself to the TCI policy smart-contract.
the TCI smart-contract checks that there is enough credit limit to insure the new invoice, if yes, it let know the invoice that it is insured, and updates its status
Later on, if the factor gets paid (7), then it can update the invoice contract (8), which then will inform the TCI smart-contract. The TCI smart-contract can then free the limit used by that invoice, making it available for a new one.
The factor, insurance and the seller are able to access in real time the information regarding the invoices, their exposition, etc.
The code is available on our Github.
Here is a video showing the platform in action.
During our tests with HSBC, each stakeholder could access the information it needed instantly thus improving the efficiency of processes as well as reducing their costs. In the post-experiment discussions we discussed the possibility of automating most of the underwriting and monitoring processes, thus allowing for the proposal of low cost Trade Finance services. Those type of services would allow SMEs to access services tailored to them, supporting their growth nationally and internationally.
As we have sown with this experiment, there is a lot of advantages of using a Blockchain based solution for managing invoice states. And those advantages are even more relevant as the number of stakeholder grows. However before being able to leverage those advantages there is a lot of steps to be taken care of. We will talk about that in our next post, coming soon.