David Hennah of SWIFT answers some crucial questions on the introduction and application of the TSU (first published in Trade Finance supplement May 2007)
Many of the articles previously published on the SWIFTNet Trade Services Utility (TSU) have been designed to tell us what the TSU is, what it does and how it works. They mostly talk about market trends and pilot banks. They often include illustrations of data matching and workflow. Sometimes, these articles have also discussed ways in which the TSU might be used to add value to a bank’s supply chain business solutions and customer propositions.
At various events around the world I am often asked questions which reflect not so much on what the TSU is as to what it is not. So here are some thoughts and observations which may perhaps help to dispel some common misconceptions and explode a few urban myths.
The TSU is not a SWIFT invention
The TSU has not been conceived in an ivory tower. It is the result of a very broad consultation process involving at least 130 people from at least 30 financial institutions worldwide.
Over recent years, SWIFT has observed the relatively stagnant levels of growth in its Category 4 (collections) and Category 7 (letters of credit and guarantees) message traffic, as compared with high levels of growth in Category 1 / 2 (payments). This may be seen as a visible confirmation of the migration of business away from the use of traditional trade instruments in favour of open account. Empirical research studies carried out by various banks and management consultancies have confirmed this trend. Today, it is estimated that more than 81% of trade is conducted on open account.
Migration to open account clearly has implications for the banking industry. Under traditional trade the bank has visibility into the transaction from purchase order to payment. This visibility enables the bank to offer costeffective risk mitigation and financing options. In open account this visibility is lost.
Consequently, the bank’s involvement may be restricted to the settlement process at the end of the transaction.
As a result of these observations SWIFT has worked with a group of senior trade bankers, the Trade Services Advisory Group (TSAG) to define ways in which SWIFT can best assist the industry to develop an effective response to rapidly changing market conditions. It was on the recommendation of the TSAG that the SWIFTNet Trade Services Utility was incepted.
A Customer Requirements Group was formed to develop the detailed business requirements which have been translated into the functional specifications for development. In addition, a standards group and a rules group have provided the relevant inputs into the solution.
A significant number of banks took part in the piloting of the TSU and another extended group of business people representing both product management and sales functions has worked with SWIFT in the development and definition of the value proposition.
The TSU is not a next generation Bolero
Given the recent history of various initiatives designed to drag trade services into the 21st century, it is perhaps not surprising that any new directive taken will to some extent become confused with other activities that have preceded it. In the case of the TSU much of this confusion has revolved around Bolero. Historically, Bolero acted as a supplier of technology and supported the initial development of the SWIFTNet TSU in accordance with specifications defined by SWIFT and its community of financial institutions. Bolero is no longer involved in the definition, development and maintenance of the SWIFTNet TSU. Going forward SWIFT and Bolero have two distinct relationships (a) SWIFT is a founder and minority shareholder in Bolero and (b) SWIFT is the operator of Bolero’s services.
Perhaps the simplest way to distinguish the TSU from Bolero in practice is to position the TSU as a bank to bank solution. The TSU is a vehicle for banks to exchange matched data in a common message standard using the SWIFTNet messaging infrastructure. The TSU does not encroach on the corporate / bank relationship nor does it challenge existing business practices between the corporate and the bank.
Furthermore, the TSU focuses on open account business. Whilst the TSU could in principle be used by a bank to complement the processing of letters of credit, this is an ancillary benefit and not a primary design. The TSU has certainly not been built to compete with Bolero but it could in given circumstances potentially be used to complement it.
Another point to note is that the TSU deals in data elements. This brings me to the next section regarding what the TSU is not.
The TSU is not a vehicle for dematerialising documents
The TSU deals in data elements which have been extracted from trade documents, typically the purchase order (which is used to create the baseline), the commercial invoice and a variety of transport documents such as an advance shipment notice or a forwarders cargo receipt. In the next phase of development there are plans to accommodate additional data sets, including insurance and certificates e.g. certificates of origin. The latter would include qualitative data relating to the condition of goods. This is particularly relevant in the case of perishable goods such as agricultural produce.
The TSU is not a document substitution system. It does not seek to replace documents. The automated matching of data taken from the documents is designed to provide banks with a timely and reliable source of information which can be used in support of cost-effective value propositions, including pre-shipment and postshipment finance.
The TSU is not designed to replace traditional trade
As previously stated, the TSU focuses on open account which now accounts for more than 81% of world trade. The new range of XML message types that SWIFT has developed for the TSU does not replace the existing message types for traditional trade.
SWIFT continues to support and invest as required in the messaging and infrastructure required for the ongoing use of traditional trade instruments (see Figure 1). No-one has predicted the absolute demise of the letter of credit. Indeed, the recent introduction of UCP 600 may be seen as some indication of the continued demand for LCs. The updating of these rules will no doubt make it easier to process LCs but will not necessarily have an impact, positive or negative, on market demand. At SWIFT we actually saw a small increase in LC usage in the first quarter of 2007. The cause could clearly be isolated to the issuance of LCs in North America in favour of China i.e. to support US imports from China.
One aspect of the TSU which is sometimes overlooked is that the matching of data removes any risk of subjectivity. In processing an LC banks are sometimes required to exercise judgment. The decision whether the terms and conditions of an LC have been satisfied or not may require some degree of subjective evaluation. If the judgment is challenged it may result in legal dispute. With the TSU there can be no such doubt. Either the data matches or it does not.
The TSU is not just for big banks
The first group of banks to get actively involved in the piloting of the TSU included many of the world’s leading trade banks. Names such as JPMorgan Chase, BNP Paribas, Standard Chartered Bank, HSBC, Deutsche Bank and ABN Amro have become synonymous with the TSU.
To some extent this has fostered the impression that the TSU has been built with the needs of the bigger banks in mind. Not so ! The TSU is an industry initiative designed to serve the business needs of the industry as a whole.
Furthermore, the success of the Push Through model, where Importer bank and Exporter bank must exchange messages, selfevidently depends upon the active participation of partner banks.
To go a step further it is also interesting to note that indeed any institution satisfying the membership criteria can join the TSU. Consequently, membership is not confined to financial institutions only. Theoretically, others, including those in the insurance business for example could join the TSU.
The TSU is not competing with the banks
The TSU has been designed by the banks and built for the banks who are both customers and shareholders of SWIFT. What the TSU does has been consciously positioned to support collaboration between banks. The TSU enables banks to collaborate when and where they need to collaborate. The TSU does not encroach on the competitive space. In delivering data matching reports to the banks SWIFT is enabling banks to develop their own business solutions which may or may not require partnerships with other banks.
The value of the TSU to the banks and to the banking industry can be expressed in a number of ways. The central TSU application performs data matching and manages transaction workflow, providing banks with information on which important business decisions can be made. The shared messaging infrastructure of the TSU lowers the cost of investment for individual banks. The TSU standards support interoperability between the participating banks. The rules that have been incorporated into the service description specify the obligations of the banks and SWIFT towards one another. In addition, TSU functionality can be integrated into the bank’s front and back offices to support the delivery of value-added services to the corporate customer.
At the same time, it may be said that the real value of the TSU is obtained by the bank’s ability to take the matched data and apply the reported events to the creation of trigger points. These are points at which the bank will be able to identify specific events in the physical supply chain and match them to the provision of services, ranging from risk mitigation and financing to liquidity management and overall process efficiency, including data checking and dispute resolution.
The TSU is not expensive
The annual subscription to the TSU costs EUR 5000. This intentionally modest sum should not prevent any bank from joining the TSU club if it wishes to do so.
Included in the fee is a free piece of software known as the TSU-Interface. With this, a bank can set up a standalone link to the TSU for testing and training purposes. This has indeed been very useful during the pilot phase since it has allowed banks to experiment without having first to invest in front and/or back office automation and integration of TSU processes.
SWIFT has subsequently introduced a partner accreditation programme that enables software vendors to apply for a SWIFTReady label as an endorsement of an individual application to support TSU business functionality (see Figure 2). Misys Banking Systems has become the first vendor to be officially accredited under this scheme.
The TSU is not in pilot
The TSU was officially launched on 2 April 2007. A total of 33 banks from 17 countries across all regions have already subscribed to the live service.
The first live transaction was exchanged between JPMorgan Chase in London and BNP Paribas in Hong Kong. The transaction involved purchase order exchange / acceptance followed by invoice and transport data matching to the purchase order.
In conclusion
Perhaps, I can just add a short statement as to what the TSU is….. The TSU is live. It is a significant step forward in enabling banks not only to address gaps in the product range but also to take a more holistic approach to the delivery of supply chain business solutions. It is a step forward to a future way of servicing customer need and responding to ever-changing market dynamics.