For people interested in the details, please continue reading… for the TLDR version, 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. Another undeniable fact is that the speed and quality of service that an organisation can offer is directly related to the quality of the data that it has at its disposal to work with. But where does Customer Centricity start in Trade, where is the source or the Jewel of our Trade River?
Does it start after the customer has given an Import LC or Export Collection instruction, or presents an invoice for finance or payment? 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, and I am not talking about highly customised integration work done by banks or fin-techs for their large corporate customers, using H2H connectivity, ERP integration, API connectivity etc.
I am talking about the standard SWIFT format based trade messaging channels (MT4xx, MT7xx, MT798, single and multi-bank trade portals) used for the majority of buyers and suppliers out there, call it the basic or out-of-the-box processes. 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. Purchase Orders can be tied into Inventory, Materials and Warehouse Management software to monitor stock levels, create alerts etc. It depends on the requirements and the resources that buyers and suppliers have at their disposal, whether they are using sophisticated systems for this type of tracking or whether they stick to Excel files or use of other basic software tools. I am far from an expert on corporate back offices, but what applies to any organisation is that an efficient Data Strategy is essential to proactively and efficiently manage their operations.
Pain points
All data in trade transactions, whether they are settled on an open account, collection or LC basis originates from buyers and supplier agreements. 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 also shown in a diagram further down.
It is clear that financial institutions, fin-techs, buyers, suppliers and all other parties involved would greatly benefit from messaging standards that tap directly into those 2 key documents, both from an efficiency and a compliance perspective. The reality is that in the context of Trade transactions, e.g. LCs, this is almost non-existent apart from currency, amounts and dates. There is no structured (!) exchange of goods and transport data, documents required, additional conditions, no use of HS codes, Airport and Seaport codes, nada. "Free type in" yes, but that’s not very efficient. All the goods information 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. This is because the updates to the Goods delivered and still to be delivered is not a shared result; only some free format discrepancy information comes out of all that document checking activity.
And yes, there is OCR/AI technology available to assist, and in some cases this may be very helpful. In many cases it is very challenging to automatically perform reliable and accurate updates if a Goods Description contains multiple line-items. It is very difficult to predict how a user will fill out that information in a ‘dumb’ text block with a maximum 800 lines of 65 characters (i.e. 1 MT700 with up to 7 MT701 extension messages). Yes, I use the word ‘dumb’ because, as a technology company, it is very frustrating having to work with such data (non-)structures. I have been doing this since 1991 and it hasn’t changed, except for the number of MT701’s you can send.
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. Do you agree that the LC T&C are supposed to reflect what has been contractually agreed between applicant and beneficiary? If yes, in whose interest is it then to create ambiguity on what the LC status is? It’s beyond me. It is my opinion that an LC should not be amended or deemed to be amended unless applicant and beneficiary both explicitly agree on modified T&C. In a contractual context, with financial implications for both parties, opening the door to such ambiguous situations, as created by Article 10(c), does not make any sense, to me at least.
Here’s a small and what would appear to be a simple situation that demonstrates how easily ambiguities could arise.
- LC Issued for 100.000,00 USD with latest shipment 15st July 2020, Goods Type A, B, C and D
- LC Amendment nr. 1 decrease with 20.000,00 USD and latest shipment 20th July 2020, all Goods Types evenly decreased.
- Presentation of Document Set nr. 1 for 70.000,00 USD, shipped on 19nd July, Goods Types A and B
- Presentation of Document Set nr. 2 presented on the same day for 70.000,00 USD, shipped on 14th July, Goods Types C and D
**Question: which document set will be accepted by the bank, which will subsequently impact which goods still can be delivered under the LC T&C? How do you make a choice? This is a very simple example with 1 amendment. **
Depending on which set you would approve, just imagine then the other set, which has now become discrepant, would land on the LC document checker’s desk a little bit sooner.
Would your answer still be the same? OK, now imagine the 1st amendment would have stipulated that latest shipment would be changed to 17th July instead of 20th July. It would make the 1st set discrepant and the 2nd one compliant. But what happens then if the applicant would accept the 1st discrepant set despite late shipment. It would make the 2nd set which was considered to be compliant after the document check suddenly discrepant because the LC would be overdrawn. Can you imagine how painful it may become with many amendments involving changes to goods descriptions, amounts, dates, documentary requirements and other conditions…? A user and/or a machine having to judge which amendments are ‘deemed to be accepted’… what if a document set complies with certain non-sequential amendments and multiple document sets have come in at the same time and they comply with different amendments…?
Really… this cannot be intention of buyers and suppliers involved in such transactions. If you ignore how MT707 amendments are processed today and would have to define the most efficient process, then the smart thing would be to set up a processing flow whereby buyer and supplier first agree on amendment details (just like they should agree first on issuance details), after which the amendment instruction is passed on to the issuing bank, which can subsequently send the amendment to the advising bank.
Either a workflow change is needed or an amendment to the IMHO impractical UCP 600 Article 10(c). I think there must be a reason why the article has been defined like that, but is that a rule that really serves us best, if we want to create a clear and predictable process, assisting buyers and suppliers to properly plan their financial and physical operations?
Enough rant and cant … what improvements could be made?
Back to the lack of structure of an MT7xx-Letter of Credit. I know it is easy to complain about what the shortcomings are, but as I have previously mentioned in another article "let me make clear that in the absence of a more advanced, proven and widely available alternative, the SWIFT MT7xx, as an electronic version of originally a paper document, has done a great job… despite frustrations with some of its inefficiencies and related UCP rules on e.g. LC amendments, which make it impossible to perform straightforward automation." 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, e.g. "Each document must bear the LC number of the Issuing Bank" = code /LCNR-DOC/ or /ADCOND01/… whatever. Those codes could be used to trigger automated machine assisted checks, without any risk of misinterpretation.
The same can be done for the documents required (Tag 46 in MT7xx); those are well known to all, also the different types and required variables for each document, e.g. in case of a B/L, the consignee, notify party etc. So, why is this still a free type in text field? And yes, I know you need a way out for special cases, but that is perfectly possible providing an /OTHER/ option.
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 matching 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, whereby you could use a codeword in Tag 45 to indicate the attachment format, e.g. "/ISO20022/". ISO20022 was previously used for the Purchase Order in the BPO (Bank Payment Obligation) and also used by some other platforms for ‘BPO like’ instruments, such as the Payment Commitment and Bank Payment Undertaking.
The use of FileAct together with the relatively new MT759 (Ancillary Trade Structured Message) is already being promoted by SWIFT anyway to exchange Trade documents in the context of an LC Drawing. Those documents could be scanned, structured 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…?
In case the format used would e.g. be ISO20022, the SWIFT TSU or another TMA (Trade Matching Application) could be deployed as the LC document checker, but … too late, the TSU has been fired... and rebranded. Compliance engines and processes would also benefit from more structured goods descriptions so that it is possible to do targeted checks without having to verify entire blocks of unstructured data, as is the case today. One of the reasons that ISO20022 is introduced for Payments is that richer more structured data facilitates detection of crime and helps target financial crime. That is no different for Trade, so it would really be a shame if all the ISO20022 standardisation work done for Trade would be lost. Also, the most common discrepancies could be coded, so that they could more easily and consistently be exchanged between banks and between banks and their customers. If they are predefined in a code format, then it also becomes easy to predefine them in local systems in different languages when communicating with customers, if required. This allows for more automation esp. when the back office is integrated with OCR/AI engines for document checking.
For the exceptions on Additional Conditions, Documents Required and discrepancies, as mentioned before, you can always provide a free format ‘OTHER’ option. I know techies will shoot me down for some of these suggestions, as it is patchwork on top of an archaic FIN message format but as long as Trade does not go ISO20022, XML or uses e.g. a json schema for data definitions, it provides at least an option for the use of structured goods data, documents and additional conditions in the current SWIFT based LC process. The SWIFT messages would only store structured data and the more complex Goods Description, which originates from POs anyway, can be externalised using a FileAct attachment.
It provides coexistence with the current process and message format, but it also allows a move to a more efficient LC process, ready for the introduction of digital documents, during the issuance, amendment and presentation steps. ePresentations under LC’s or any other similar Payment Commitment/Undertaking instrument will only generate real benefits if they can be checked against structured issuance and amendment data.
I have focussed on the LC inefficiencies, but they apply to any type of trade transaction. 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. 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
Perhaps I have caused some slight irritation with some of the things I wrote, maybe on article 10 (c) of the UCP600, so I am ready for some counter-arguments and debate. To avoid any misunderstandings, I am turning 55 this year and have been working in Trade just over 30 years. We can all come up with many reasons why new suggestions would not work, that is easy. A solution is never perfect like a standard is never perfect because it continuously evolves based on what happens around it. A lot of things are and will continue happening in the Trade domain. 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 message 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, to start with. We need a "Trade Enterprise Service Bus (ESB)" approach. On Wikipedia it says "the primary use of an ESB is in enterprise application integration (EAI) of heterogeneous and complex service landscapes.". That sounds like Trade to me. We would need to agree on the "Minimum Common Denominator Data" library and allow for differences beyond that. As time progresses and standards work continues, the position of what is common can evolve.
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 Trade Origination data, this is an initiative that should also be applied to the common core trade dataset I referred to in the diagram at the top. The secret sauce should be in the customer service provided, not in the data standards used.
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 and suppliers out there spend less time on trade data re-entry, verification and reconciliation. Trade Contract platforms, FI’s, E-invoicing and Trade Finance technology companies need to collaborate to define Trade’s Golden Record (PO and Invoice standards), a common foundation for the benefit of all Trade participants. Something for the ICC Digital Standards Initiative perhaps?
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 ‘flip’ a PO or a set of PO’s into an LC (based on common CCY and supplier)? The simple reason is that the LC MT7xx data structures are not fit to store PO data… apologies for repeating myself. We have done such ‘flipping exercise’ on a project basis and there are other vendors out there that provide similar PO Pooling and Grouping functionality, but it is often a customised data parsing solution based on the formats used by specific buyer applications.
Besides a PO-LC flip, it should also be possible to 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.
But, 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.
