Published: October 25, 2010
Caterpillar first selected SWIFTNet for bank connectivity in 2007, and was one of the early corporate adopters of SWIFT Corporate Access under the SCORE (Standard Corporate Environment) model. In this article, Martin Bina, EMEA Treasury Operations Manager at Caterpillar discusses the company’s experiences to date. Before implementing SWIFT, Caterpillar had various arrangements for communicating with its banking partners in its six treasury centres, and proprietary tools for accounts payable at business unit level. In the European treasury centre, for example, we used our main cash bank’s multi-bank platform through which our key banks reported. Our main cash bank also acted as a third party payment agent for treasury payments. While this arrangement worked very successfully, we recognised the need to establish a standard approach to connectivity across the business, including both treasury and accounts payable. We were building a financial shared service centre for accounts payable, to create a common processing environment both for existing business units and new entities brought into the company through acquisition, and it was relevant to consider SWIFT as a component within the standardised, common infrastructure.
Caterpillar’s connectivity objectives can be summarised by ‘three S’s’: Simple; Standard and Secure. SWIFT connectivity was the logical and obvious choice to achieve these three goals, with the introduction of the SCORE (Standardised Corporate Environment) model in 2007 as the catalyst. We had been familiar with SWIFT Corporate Access for some time, but the value proposition for Caterpillar had been unclear: we did not have the trading volume to justify accessing SWIFT for confirmations (TRCO – Treasury Counterparty model) and MA-CUGs (member administered closed user groups) were too complex. SCORE appeared to be more straightforward and standardised, so we decided to look more closely at the opportunity that SWIFT presented. We recognised that not only would we be able to connect easily to our treasury management system (TMS) but also to our ERP as part of our global roll-out, enabling ‘plug and play’ access to key banking partners.
We recognised the need to establish a standard approach to connectivity across the business, including both treasury and accounts payable.
We first approached our primary cash bank to discuss our potential SWIFT project, and found them extremely supportive. We did a great deal of the preparation work with the bank team, and essentially worked with them as consultants on the project. Once we had decided to proceed, we approached the top ten to twelve of our major banks to ascertain their willingness to connect through SWIFT, and which formats they supported, with a view to using ISO 20022 standards wherever possible. We had mixed responses, with one bank not yet supporting SCORE, although they have since joined. However, despite varying levels of experience with SWIFT Corporate Access, we found that most were progressive and responsive.
We did not consider direct connectivity to SWIFT (i.e., hosting the infrastructure internally) as the cost and resource requirement was considered prohibitive, and could not be justified bearing in mind that it is not a core activity for the company. Our preferred supplier for treasury technology is also a hosting provider, service bureau and member concentrator for SWIFT, with considerable expertise, so we made the decision to work with them without approaching other potential service bureaus. We implemented our vendor’s payment solution as middleware to support the variety of payment and format requirements across the company.
We started first with treasury as a pilot project, with a view to then rolling out the solution to accounts payable and to our business units. As Caterpillar has six treasury centres globally, it was a complex pilot project, as we made the decision to implement all six centres concurrently. However, the project progressed quickly and was completed within six months of completing the contract with our TMS supplier. While other companies have used their SWIFT connectivity project as an opportunity to re-engineer their financial processes, which adds to the project time and complexity, we had already implemented highly efficient, automated processes, so our objective was purely to unplug one system and connect another.
We have encountered few disadvantages of implementing SWIFT connectivity compared to our previous arrangement. Inevitably, when changing users’ work environment, there needs to be a transition period so that people can become familiar with new systems, but this has not taken long, and we are very satisfied with our new infrastructure, with robust, transparent integration. [[[PAGE]]]
There are always some issues to overcome when implementing a complex project. In particular, while it is not always apparent when reading the financial press or bank communications, ISO 20022 is not yet widely supported, and brought some surprises. For example, FIN enables instant messaging between financial counterparties, which is particularly important for urgent payments to ensure payment before cut-off times. XML (on which ISO 20022 is based) is a file-based environment, so there need to be processes in place to ensure that payment is made before the relevant cut-off time. In addition, not all of our banks supported ISO 20022, particularly in Asia, and we had to remain with BAI formats. We are considering whether to transfer to MT940 or wait until the banks can support ISO 20022.
Our treasury centres are now fully operational on SWIFT for treasury payments and reporting. We were not able to progress the project during 2009 due to the demands of the financial crisis, but we are now completing a pilot project for accounts payable in France, as ETEBAC 5 will shortly be discontinued. We will then continue to roll out SWIFT connectivity for accounts payable across the business, although we have not yet determined internal priorities for this. Once we have achieved this, we will derive additional benefits, particularly control and visibility over accounts payable processes. Currently, with different systems in place at each business unit, there is fragmentation and a lack of standardisation across the business, which will be resolved once we have fully rolled out our payments system and SWIFT.
In addition, as our payments system is integrated with our TMS, we have full access to cash position information, replacing the existing arrangement where business units email treasury with their cash requirements or surpluses.In addition to using SWIFT for cash management, we are attracted to the potential optional convenience and control that eBAM (electronic bank account management) offers, and we will consider this once we have fully onboarded our banks and rolled the solution out to our business units. We also intend to move to fully XML-based reporting through SWIFT when it becomes available.
[[[PAGE]]]
Based on the experience we have gained so far, there are various factors which we would emphasise for a successful project. Firstly, it is important to keep in mind the big picture of what you are trying to achieve, as opposed to getting lost in the minutiae. Partner organisations, particularly software vendors and banks, often have a great deal of expertise which it is important to leverage, rather than trying to develop comprehensive skills internally. Based on the issues we have found with ISO 20022, it should not be assumed that a new initiative is widely available just because it is widely discussed or promoted. We found ourselves at the forefront of ISO 20022 adoption without necessarily expecting this.
SWIFTNet is commonly described as the most reliable network in the world, but a payments or cash management process is only as reliable as the weakest link in the overall cycle. With a variety of internal processes and systems, as well as SWIFTNet, attention needs to be given to increasing the resilience of the whole process as opposed to simply focusing on individual elements or relying on the final step. In addition, however automated and ‘leading edge’ a technology infrastructure, there are legacy issues to address on an ongoing basis, unless it is an entirely green field implementation which is very rarely the case. For example, our TMS reads files in BAI 2 format for reconciliation and automatic posting to the general ledger, and it would take a substantial rewrite to adapt the system to another format. Therefore file mapping needs to be included as part of the project, for which we use our payments system as middleware.
Although there have been some challenges and constraints, we have had a very successful and positive experience in implementing a new payments and cash management infrastructure, including SWIFTNet, and we have been greatly assisted by our main cash bank and our vendor, which provides our TMS, payments system and service bureau, in particular. We will maintain our existing multi-bank system provided by our primary cash bank as a back-up if required, but we do not envisage that this will be the case due to the expected resilience and reliability of our service bureau. We have achieved our visibility and control objectives and look forward to further advantages as the roll-out progresses.
How Thought Leadership Can Reduce the Cost of Sales by Patrik Havander, Havander & Partners A focused attention on the costs incurred by the global sales and marketing processes is becoming increasingly important for corporate banks and their transaction banking departments. While the client/bank relationship remains vital, research has shown that in fact relationship selling […]
