Email Contact Phone Company Visit Website

Surecomp Office

Two Hudson Place


Marketing Communications Manager


Murray Freeman
[email protected]
Back to all Surecomp announcements

Payments and Cash Management within Trade Finance

By David Toubkin, Executive Product Director, Trade Finance, Surecomp

Due to sheer volumes, most of the emphasis seen in Banking-related journals as well as that emanating from organizations such as SWIFT, tends to concentrate on pure payments processing (sometimes referred to as Clean Payments, Remittances etc.), covering both domestic and international payments. However, there is still a relatively high volume of payments which are made within the framework of traditional Trade Finance instruments including L/C’s, Reimbursements, Standby L/C’s, Guarantees and Documentary and Clean Collections.

This article seeks to provide pointers as to how they can be handled more efficiently by banks and also to focus on the issues facing banks wishing to implement payment systems, and how payment systems can integrate with Trade Finance Systems.
Finally, this article will touch on the linkage between Trade Finance and Cash Management, the two areas obviously being closely related.

Handling Payments in Trade Finance Transactions

The way in which trade-related payments are handled very much depends on the level of automation within the Bank, and, assuming the bank has an automated Trade Finance System, the way that system is structured. Some systems, such as Surecomp’s IMEX Trade Finance System, offer highly advanced STP services in order to maximize the data mapping of payments received via SWIFT. The following are a few examples:

Letter of Credit Payments

The Negotiating Bank may receive an MT752 message (authorization to Pay, Accept or Negotiate), in response to an MT750 message sent to the Issuing Bank. If the Trade Finance System is able to process this message automatically via STP and route it for approval, no user involvement is required in what is usually a highly labor-intensive task.

Collection Payments

When the Remitting Bank sends documents to the Collecting Bank, the payment, either at sight or at tenor, is usually made by the sending of an MT400 message (possibly with an MT202 Cover Message if no account relationship exists between the Remitting and Collecting banks). Again, the ability of the Trade Finance System to automatically process the message and route it for approval results in a considerable resource saving for the Bank.

Bank-to-Bank Reimbursements

These instruments can be highly profitable for banks which can generate sufficient volumes of business and are able to process the business with the highest levels of STP. As a minimum, the Reimbursement System should be able to provide total STP for the MT740, 742 and 747 messages. In addition, it must be able to handle Blanket (General) Reimbursement Authorizations with specific bank or country exceptions, handle Reimbursement Undertakings and be able to automatically generate Pre-Debit Advices and Nil-Activity Advices to the Bank’s clients.

Exception Handling

No system can currently provide 100% STP due to the facts of everyday life. For example, banks may add free text to SWIFT messages, accounts may have changed or been closed etc. The most efficient systems should automatically route failed STP items to a repair queue, accessible to authorized users, who should have the ability to directly open the item, repair the invalid data and return the item to the STP process. An additional facility which can prove highly beneficial is a "Keyword" database which can be built up by each bank over time, based on their experience. Such a database can instruct the processing system how to react when certain words or phrases are found in a specified SWIFT tag, i.e. to continue or halt the STP process, move a specified value to a specified field etc.

Bank Payment Systems – the Dilemma

Many banks currently have legacy payment systems, and many of them are looking to increase their business volumes and profitability by upgrading to the latest technology and functionality. The dilemma facing these banks is whether to try and leverage the capabilities of their Trade Finance System or alternatively to license a vendor system (or possibly to develop in-house, although this is hardly an option for any but the largest financial institutions).

As mentioned above, Trade and Payments are closely linked. For example, an Incoming MT103 might be a Clean Payment or might be a payment under a collection sent by the Bank. Furthermore, with the exception of bulk payment instruments, the techniques required to generate or receive payments under Trade Finance deals are virtually identical to those required to make and receive stand-alone customer payments. What differentiates Trade Finance payments from regular Clean Payments lies mainly in the area of specialized functionality. So what direction should a bank take which is looking to replace its Payments System?

The fundamental question is how robust is the Bank’s existing or target Trade Finance System and how easy would it be to integrate the required functionality? Clearly, the functionality available in a dedicated payments system would be greater than that currently available in the Trade Finance System. However, if the bank is able to achieve most of its required functionality through its Trade Finance System, the result would probably be considerably cheaper. Furthermore, a common platform could leverage all the existing interfaces which have been developed as well as enabling consolidated administration of both systems by a single team.

There are several critical aspects which banks need to carefully consider. For example, a bank with a million or more retail customers may typically only have a few thousand customers recorded as Trade Finance customers. When an incoming payment is received for a retail customer, if the Trade system is being utilized for payments it would need to link to the Bank’s CIF and automatically create the customer in the Trade System. Another aspect is the identification of customers. In many banks there are requirements to automatically compare both the account number used in the Incoming Payment Message as well as the name and address used prior to processing the payment. As the payment message does not bear any existing transaction reference number, the correct identification of the beneficiary is of paramount importance.

Cash Management

Clearly, many payments made by companies around the world are for payments for goods and services, both domestic and international. The corporate treasurer is, like his bank counterparts, faced with many options, typically finding that most banks are offering their own solutions.

Cash Management finds its place among the many products offered by leading banks on the corporate websites. The most successful ones offer easy to use links between Trade, Payments and Cash. Unfortunately, vendor systems which attempt to offer the best of all worlds in a single consolidated system rarely perform to the complete satisfaction of their users, as each area requires highly specialized functionality. The optimum solutions would therefore seem to be those which offer the easiest links and navigation between these products. Corporate customers will arrive at their own conclusions as to which banks offer the best services, and in the era of the internet it is relatively easy for the unsatisfied corporate to switch its business to any place on the globe.