Published: April 01, 2010
We use IT/2 as our treasury management system (TMS) at Johnson Matthey, which supports the majority of our treasury activities. The solution has web-based access for subsidiaries to enable in-house banking, and we have an interface between IT/2 and our accounting system, JD Edwards. We also have links to an online dealing platform, FXAll, and we import market data from Reuters. There are five banking systems in place in group treasury for making payments and retrieving statements which are not generally integrated with our TMS, together with a further 80 banking relationships elsewhere around the group.
As an in-country solution did not give us sufficient scope to manage our international requirements, the logical solution was to implement SWIFT Corporate Access.
Each of our banking systems has its own user IDs, passwords and control features, which would not be a problem if we were using only one system; however, as the number of banking systems increases and the number of user names, passwords etc. proliferates, the level of complexity grows and the control could be compromised as users struggle to keep track of each system’s security requirements.
In addition to our security concerns, our daily processes for retrieving statements and making payments through multiple statements were manual and extremely time consuming for our treasury team, and this effort was further replicated amongst our business units, many of whom hold multiple bank accounts. We also felt that our electronic banking environment was constraining our ability to move accounts between banks to optimise our cash management.
Elsewhere in the business we were aware that the same issues were faced, especially in our Precious Metals Marketing operations which also require access to multiple bank systems.
In Group Treasury we needed to communicate with our five key banking partners for obtaining statements and making payments across over 100 accounts on a daily basis. We also wanted to integrate our banking information with our TMS, without having to implement and maintain multiple interfaces.
The most obvious solution was to implement a single connection through which we could communicate with all of our banks. We looked at various options: bank-owned multi-banking solutions; multi-bank solutions offered in domestic markets such as Switzerland, Germany and France; and SWIFT Corporate Access. We decided that a bank-owned solution created too much risk to an individual bank and reduced our bank independence. As an in-country solution did not give us sufficient scope to manage our international requirements, the logical solution was to implement SWIFT Corporate Access. This gave us the benefit of bank-independent connectivity across all our banking partners using the secure, reliable channel (SWIFTNet) already used by banks to communicate with each other.
[[[PAGE]]]
Having made the decision for SWIFT, we put together the business case. In our case, this did not prove a difficult part of the process as we were able to quantify the advantages in financial terms. We worked with an internal IT consultant who monitored our existing processes and provided a comparison with our future processes with SWIFT. For example, SWIFT would allow us to reduce the time taken to retrieve balances and make payments from four hours to one-and-a-half hours per day.
Another key advantage was the ability to identify and unlock trapped or surplus cash across the business. As we have not had visibility over all accounts on a daily basis, it is not always clear how long balances have been on accounts. By achieving daily visibility, we would be able to centralise and make use of cash across the group more efficiently.
Security and control was the third major factor in our business case. Before going through this exercise, no one had documented all our business processes, so while we were aware of high level issues, a number of limitations were not apparent. For example, we had over 25 authorised signatories on the five banking systems. Each signatory was able to authorise payments on some systems, but not on others. We recognised that by implementing a single channel for bank communications, our internal controls and the efficiency of the approval process would be enhanced significantly.
Having made the decision to migrate to SWIFT, we had various alternatives as to how we approached the implementation (fig 1). For example, we had to decide whether to host the solution ourselves (direct connectivity) or to work with a service bureau (indirect connectivity). As we have a small team without access to dedicated IT resources, we chose the latter, selecting SMA as our service bureau. Although we considered a number of different service bureaus, we chose SMA on the basis of our confidence in their infrastructure, SWIFT accreditation, experience with working with similar firms to Johnson Matthey and the reference calls with existing users.
We looked at Alliance Lite, which was a new access option to SWIFT when we were starting our SWIFT implementation. We decided that it was not suitable for us for two key reasons. Firstly, we could not implement the specific security arrangements that we required; secondly, it was not scaleable enough to meet the needs of our business unit users.
We approached our banks and our TMS vendor to advise them of our decision to use SWIFT. IT/2 was very supportive and already had experience of implementing the interface with SWIFT with other customers. We had mixed responses from our banks. Some were actively promoting SWIFT, had their own service bureaus and had the implementation skills in place to support the migration. Others had a less defined strategy on how corporate customers could access their services through SWIFT and less experienced resources. We were also surprised that the costs charged by each bank differed substantially. Our expectation was that the banks that had invested heavily in proprietary software for multi-bank connectivity would be those most reluctant to support our decision for SWIFT, but this was not the case.
We decided that it would be easiest to start our SWIFT implementation with the banks that were most supportive and well-equipped to help us with the process, and adopt a phased approach, so that we would have more experience when it came to connecting to the other banks. We are now fully live with one bank and in our test phase with two others. We started with statements (MT 940) and then moved on to payments (MT 101). We will be implementing MT199 messages for precious metal transactions in due course.[[[PAGE]]]
The first decision we had to make was how to organise the business to make optimal use of SWIFT. Some companies have taken the opportunity to centralise payments into a payments factory, but although Johnson Matthey’s treasury activities are centralised to a considerable extent, other parts of the business would also need access to SWIFT, such as our metal trading operations. Therefore, we needed to organise our infrastructure to enable our business units to access SWIFT as well as integrating with our TMS (fig 2). We also had to decide what message types we wanted to exchange through SWIFT, and with what frequency. It was also important for us to create an infrastructure that would meet our future needs, such as in precious metals.
We submitted our business case in June 2009, which was followed by the negotiation of legal documentation with SMA, IT/2 and our banks. This took around three months, which was longer than we anticipated, particularly as in some cases, banks’ documentation was not tailored for corporate clients.
We then started the implementation in late September 2009, which commenced with a formal kick-off with our key partners in the project: our first banks, TMS vendor and service bureau. We then exchanged the first test messages with our pilot bank in early 2010.
Having now gone live with our first bank, with another two in the test phase, the next step for us will be to roll out SWIFT connectivity across our remaining banks. Although we had initially anticipated that we would implement SWIFT at our treasury centre first before rolling out functionality to our business units, we have already started this process in fact, allowing business units to access bank statements directly from the IT2 portal. We had originally assumed that the key savings and advantages of SWIFT would be at group treasury level, so rolling out to business units was a second priority: in fact we have found that the advantages to business units are more significant than we initially estimated. Consequently, we are planning to roll out SWIFT more widely than we had first envisaged, with the aim of optimising our banking and bank communications across the group.[[[PAGE]]]
Our SWIFT project is still in its relatively early stages, so we have not yet seen the full benefits, but it is already proving to be a highly successful project. Based on our experiences so far, there are some thoughts that may be of use to other companies embarking on a SWIFT project:
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 […]
