For people interested in the full version of this article, please click here.
Trade is certainly a river with many branches and tributaries. The secret of its source though is far less elusive than the Nile's. The Trade Quest is not about finding its source, but using it source most efficiently, understanding its currents and how its tributaries are connected to the main river.
Bills of Lading, AWBs, Bills of Exchange… key documents in Trade yes, and absolutely worth digitalising, but they are branches and tributaries to the main river; they are generated in the context of a logistical and financial service, following a Trade agreement between a buyer and supplier.
I believe everyone agrees that a Digital Strategy in Trade or any other business goes hand-in-hand with Customer Centricity. But where does Customer Centricity start in Trade, where is the source or the Jewel of our Trade River?
The quality and intelligence of the service provided to an importer or exporter is a result of a process that starts much sooner. True digitalisation starts when the first character of trade data is captured.
Quality Data => Knowledge => Customer Centricity
Trade data is originated between buyer and supplier, but is then reused and further enriched by many different parties. This article is mainly focussed on the data flows between banks and its customers, using standard SWIFT based trade messaging channels. What’s the quality and usefulness of that data today? To what extent is there any automated flow of data from the Trade agreement or origination stage between buyers and suppliers through to the document presentation stage and the ultimate settlement process, maybe with financing in between?
Most Trade transactions start the same way. A buyer requests a quote, which ultimately results in a contract, a Purchase or Sales Order. This is when the goods data, payment terms and settlement method, transport information, responsibilities and documents to be presented usually get confirmed as well. That data subsequently is exchanged with many different parties and systems, so an efficient Data Strategy is essential to proactively and efficiently manage financial and physical operations.
Pain points
The 2 key documents in any type of Trade transaction, generated by buyer and supplier, are the Purchase/Sales Order and the Invoice. You could call it the ‘Golden Record’, as shown in the diagram further down.
In the context of Trade transactions, e.g. LCs, reuse of structured (!) PO data is almost non-existent apart from currency, amounts and dates. All the goods information and conditions in an MT700 LC is stored in free format text blocks which cannot be used to perform any calculations in case of partial shipments. That leads to the situation that in an LC, at least 3 parties are performing a document check, and the Importer ultimately still has to do the same job to ensure they keep track of what is still outstanding at PO level.
UCP 600 Article 10(c) – Mission Impossible?
The situation gets more challenging when several amendments have been made to the LC and then multiple sets of documents get presented simultaneously. Based on Article 10(c) of the UCP600 “The terms and conditions of the original credit (or a credit incorporating previously accepted amendments) will remain in force for the beneficiary until the beneficiary communicates its acceptance of the amendment to the bank that advised such amendment. The beneficiary should give notification of acceptance or rejection of an amendment. If the beneficiary fails to give such notification, a presentation that complies with the credit and to any not yet accepted amendment will be deemed to be notification of acceptance by the beneficiary of such amendment. As of that moment the credit will be amended.” Good luck with that if a number of amendments are outstanding with partial shipments allowed under the LC, and even more if a number of presentations are made simultaneously. In whose interest is it to create ambiguity on what the LC status is? Either a workflow change is needed or an amendment to the IMHO impractical UCP 600 Article 10(c). More info on this in the full version of this article here.
Enough rant and cant … what improvements could be made?
I believe these are some examples of realistic improvements on current SWIFT messaging standards. Some data mining on additional conditions (Tag 47 in MT7xx) could allow us e.g. to create codes for the most commonly used top 10 conditions. The same structured approach can be applied to the documents required (Tag 46 in MT7xx); those are well known to all, also the different types and required variables for each document.
It would become so much easier to perform AI assisted document checks and reduce the amount of manual work and risk of wrong interpretation by machines. The more structured the data, the lower the risk of errors and the more powerful AI can become in the checking process. For Goods Descriptions (Tag 45 in MT7xx), we could allow 2 options: keep using the current unstructured format or allow a reference to a FileAct attachment. The use of FileAct together with the relatively new MT759 (Ancillary Trade Structured Message) is already being promoted to exchange Trade documents in the context of an LC Drawing. Those documents could be scanned, structured (e.g. ISO20022) or even digital original documents. So, why not complete the ‘source to settlement’ circle and refer to trade documents (PO/SO or Proforma Invoice) when the LC is issued or amended…? For the exceptions on Additional Conditions and Documents Required, you can always provide a free format ‘OTHER’ option.
I have focussed on the LC inefficiencies, but also for Collections and Open Account transactions, buyers may want to update their orders automatically based on received invoice data. The buyer is not really interested in the type of trade instrument, what counts is the status of his orders and related financials across all his activities. This means that, when we design data flows for trade instruments, we need to take a consistent AP/AR approach instead of an individual product approach.
The inertia of Status Quo
It would really be a shame if an instrument like the LC falls out of favour because it has not evolved and has run on the same engine and the same set of wheels since I saw my first one in 1990. Any financial instrument needs to move at the pace of the business and the available technology; otherwise it becomes dysfunctional.
DLT technology can certainly optimize the data exchanges between all the parties, but if it only does that and still replicates current SWIFT data formats, it will not stop the LC volumes decreasing further. To truly become customer centric, we must close the loop between trade origination and settlement and start defining the common denominator data required to exchange structured PO/SO and Invoice data across all Trade transactions, to start with.
Look at what the Digital Container Shipping Association (DCSA) are planning to do.
As Thomas Bagge, DCSA CEO recently mentioned "We want to sit down and take all of the nine different bills of lading and come up with a syndicated electronic version that we can then go out and present to all the providers in the industry, and hopefully drive greater adoption."
Since the B/L is generated using a lot of the Trade Origination and Invoice data, the same initiative should be applied to Trade’s Golden Record. In the diagram below, I illustrate something that everyone knows. But when you visualise it, it becomes so obvious that we urgently need the industry to collaborate on defining standards for the PO and Invoice, so that buyers, suppliers and other involved parties spend less time on trade data re-entry, verification and reconciliation in all subsequent processes.
If that Golden Record standard can be agreed upon, then establishment of API based collaborative workflows with all Trade related service providers such as Logistics, Insurance, Customs, Certification Agencies, Document Registries etc. will become more cost effective and realistic at a large scale. 
We need to learn from developments in the industry that have already proven their value. If e-invoicing platforms can ‘flip’ PO’s into Invoices, why is it not possible to have a standard process to ‘flip’ a PO or a set of PO’s into an LC (based on common CCY and supplier) and subsequently flip an LC into an Invoice and other Trade documents, just like it is already possible today to flip an e-Invoice into a Payment Instruction. We need to standardise this at industry level so that we can truly become customer centric and automate and collaborate on trade contract data sourcing, trade processing, settlement and reconciliation so that the banks’ customers have immediate insight into AP/AR information and related goods order status, allowing them to pro-actively manage their inventory, materials and resources as required to run an efficient business.
As always, it will be interesting to observe whether the inertia of the “forces of status quo” will remain strong enough to keep Trade developments in patchwork mode and to compete with the combined pressure of the negative forces of dissatisfaction with paper based processes, triggered by the COVID-19 crisis, and the positive forces of a vision for a more streamlined Digital Trade future. Sounds pretty dramatic, but that tension is a reality in the Global Trade ecosystem and within many of its participating organisations, especially if they have significant market share. It seems that the momentum is with the latter combined forces. From our side, we want to keep developing the vision while creating and proving value today.
