Challenges of developing a blockchain platform for trade finance


Lardies Pelegay Fernando of Grupo Santander, who is part of the we.trade Consortium*, describes the challenges of developing a platform for trade finance below.

Trade world has been unanimously considered a natural application of DLT and smart contracts (DLT) for quite some time. It does fit well with the DLT intrinsic characteristics delivering transparency, immutability, traceability, security, etc. Therefore, a considerable effort was launched in the last few years, with numerous PoCs, pilots etc. announced, to develop trade platforms on DLT. Efforts have been done to involve different players: banks, logistics companies, government entities, port authorities, tech providers, etc. So far, it seems that very few efforts have turned into fully operational solutions, and it is not clear if there is any already in use. What should we infer from this?

Before we get into a potential view on key challenges, let’s raise a couple of general considerations:

  1. The above “quick assessment” would not differ much for other potential applications of DLT: it is difficult to see an operational DLT solution widely used. Some would suggest that Ripple, in the international payments space, could be an example, but it is highly debated whether Ripple is really a DLT solution. Therefore, we could simplistically convene that there must be something in developing commercial, operational solutions on DLT.
  2. The trade services world has been working intensely on automation and digitalisation for many years, with arguably limited progress. Projects to digitalise Letter of Credit, or in general move to the document processing involved in trade to the digital world, have been happening for many years with limited impact. Recent efforts involving AI could have more success, but there is something in digitalizing trade service flows as well.

DEVELOPING A BLOCKCHAIN PLATFORM FOR TRADE SERVICES

The following three key challenges have an “end user service” in mind, that is, a platform which will be used by traders to support their business activity. That would be the case of most DLT Trade service consortiums that have appeared in past years: eTradeConnect, Marcopolo, Komgo, TradeLens, we.trade, Voltron...

IT platform

Developing a fully integrated service with a DLT core bears significant complexity. First, because of the inherent challenges associated with a new technology like DLT, it is rapidly improving but is still working to address aspects that have been discussed in numerous articles and assessments like response time, scalability, etc.

In addition, around any DLT solution (Hyperledger, Corda, Ethereum, …) there will typically be a good number of non-DLT architectural blocks interrelated to deliver any service. More so when all projects have taken data and logic out of the smart contracts to lighten the burden of the DLTs. This results in reasonably complex architectures, in particular if we are aiming for end-to-end, user-facing solutions, following strict cybersecurity requirements, complying with data protection regulations, running in a cloud, dynamically scalable, etc. The juxtaposition of all these elements is a considerable challenge for the different projects working on the matter.

It would seem that very few of the existing efforts have already managed this challenge, or are about to, and have fully operational platforms, ready for general commercial adoption.

Product/ solution attractiveness

A project might have overcome the IT platform challenge, and have a fully operational service, but this does not mean success. Is the service sufficiently appealing to drive adoption and usage?

End users do not care whether a service is powered by a DLT, or how neatly you have connected several modules in your architecture. They are driven by an improvement in their user experience, and/or better cost/service overall proposition. Whether the platform aims to digitalise L/Cs (like Voltron) or provide an alternative new product/service (like we.trade’s Bank Payment Undertaking), the service needs to be sufficiently appealing (the whole service, including on-boarding, transactions management, incident resolution, etc.) This might not be the top priority for the mentioned consortiums at first, since they are focused on the IT platform challenge, but it will eventually become key if they want to be successful.

It is difficult to say how well the existing efforts are addressing this challenge. Only after consortiums go past PoCs and tests, and move first into pilots and then commercialisation, will we have user feedback on service and usability

Network effect: achieving critical mass

Finally, the third challenge: the network. In every service where there are counterparties, there needs to be sufficient “reachability” in the platform. The platform might work (challenge one), the proposition might be attractive (challenge two), but if I want to use it to support my trade, it needs to support at least a relevant portion of my flows.

Some consortiums have gathered a decent initial coverage in a certain trade region, while some will probably rely on good customer references on its platform. Platform interconnection would solve the issue, but we still need to see how that will take place. For the moment, the challenge is there for all efforts underway (remember the experience of Swift’s BPO).

*You can meet we.trade representatives during Consortia event in London on 22nd-23rd of May 2019.