Published: February 01, 2009
The following is an edited transcript of a roundtable discussion held at this year’s SIBOS event hosted by Citi. We are grateful to all those on the panel for allowing us to reproduce their comments to readers of TMI.
Richard Schwartz (Chair) Director, Information Partners
Ed Barrie, Group Manager, Treasury, Microsoft Corporation
Hans Cobben, Group Vice President, Global Payments and Messaging Solutions, SunGard
Manish Jain, Global Transaction Services, Citi
Thomas Martin, Head of Operations & IT, ABB Group Treasury
Welcome to the session! Firstly, I’d like to ask each member of the panel to introduce themselves. We have a good cross-section of representatives today, including Corporates, Banks and Vendors.
I am Thomas Martin, Head of Operations at ABB. We will be going live on SWIFT in a few weeks. I’d like to talk about how our journey has evolved so far. It’s a bit early for us to see how SWIFT has made our life easier at this stage, but as a decentralised company, we want to use SWIFT to provide a gateway to our banks, initially for treasury payments.
My name is Hans Cobben and I am Group VP with SunGard Banks & Corporates. We have seen a lot of change in systems both on the banking and corporate side and have been privileged to be part of these developments. We have also had a learning curve, and I will be glad to share some ideas with you and learn more about your experiences.
From our perspective, there are two areas of return on investment from SWIFT.
I’m Ed Barrie, Group Manager for Treasury at Microsoft. I’m responsible for two principle functions: firstly, our treasury technology and delivering on our five-year roadmap; secondly, our cash operations. Our cash operations team moves funds across all of our bank accounts worldwide. As part of my role, I’ve been leading our SWIFTNet initiative for the last 3 1/2 years.
I’m Manish Jain from Global Transaction Services at Citi. I manage a product called Citi SWIFT Exchange, which is geared towards corporate needs and which we have implemented with a number of corporates. From our perspective, there are two areas of return on investment (ROI) from SWIFT. One is obviously the rationalisation of the connectivity infrastructure, moving from connecting to ten banks in ten different ways through to connecting to them all through one single channel. So on that side, the ROI is fairly obvious. But why go through that exercise?
The ultimate goal of simplifying connectivity and messaging layer in your treasury is to achieve a smooth-running, automated treasury operation with a high degree of straight-through processing, with the ultimate goal of global visibility of your cash flows, so you can manage your liquidity more effectively. This is really the ultimate value of moving towards SWIFT and standardisation rather than focusing simply on technology rationalisation. From our experience, it can take two to three years to achieve that goal. The most critical factor in success is the partner that you choose. Not all banks are SWIFT members. Not all banks offer SWIFT connectivity to corporates. So a crucial question is: does your banking partner really offer the services that you’re looking for? Do they have global reach? Are they willing to partner with you from the beginning until you have completed your journey and achieved your ROI goals? [[[PAGE]]]
Richard SchwartzWithin the audience today, around 50% of corporates here have signed up for or implemented SWIFT connectivity. Ed, as one of the earlier adopters of SWIFT connectivity amongst corporates, what set you off on that journey? When you started, how ambitious were you and what were you seeking to achieve?
Starting with your second question, I think my ambitions were a lot bigger than what was realistically manageable. We took a step back and looked at how we could turn this from a treasury solution to an enterprise solution which could touch all aspects of our organisation, whether a local subsidiary in an emerging market or one of our major operation centres in Dublin, Singapore and in the U.S. I think this approach is really important when you’re looking at your overall ROI objectives. For us, our initial objective was to obtain a single view of cash across Microsoft, with the balances and transactions in every bank account. This is still an objective we’re working on: we have daily visibility of 96% of our global cash. It will probably be a ten-year project once we have reached that final 4%.
Thomas, am I right in saying that your initial ambitions are more limited?
Yes, our issue was really with bank platforms. With three platforms, your security is only as good as the weakest platform. If an e-banking platform has a ‘browse’ button to import payment files, the segregation of duties implemented in the Treasury Management System (TMS) can be circumvented easily and allows modifications to be made to the payment file outside of the TMS. Having a bank-independent application using SWIFT to connect to all our banks was a good way of achieving a secure end-to-end process for all banks.
To achieve security, automation, straight-through processing and better view of liquididty, you need the right infrastructure in addition to SWIFT.
You mention the business case, which is something we’ll come onto shortly. But before we do, Hans, we’ve heard two versions here of companies’ initial ambitions, one broad in its scope and one more limited, and you must have seen plenty of companies in between. Generally, how realistic are the expectations of corporates looking at SWIFT as an option for bank connectivity.
There are a number of different objectives we see amongst corporates: one is risk/fraud reduction; another is systems integration because of a multitude of local e-banking solutions. Ultimately, the end goal is liquidity management.
However, although SWIFT is an enabler, it is simply a channel and does not, in itself, satisfy corporate objectives. To achieve security, automation, straight through processing and a better view of liquidity, you need the right infrastructure in addition to SWIFT. However, often companies’ expectation is that implementing SWIFT will solve these issues, which can often create difficulties with expectations.
Thomas mentioned the business case. How do you go about constructing the business case for SWIFT? You mentioned you’d tried once but unsuccessfully. Who do you have to convince in your own firm?
In our case, it was actually very simple: I didn’t need to convince, I needed to implement. We wanted to have a secure process with the appropriate approvals and controls and this justified the cost of implementing it. If this had not been a sufficient business case in itself, there would have been various other elements such as range of banking services, which can be accessed through it. For example, this might include collecting bank statements for the whole group via SWIFT, providing visibility over group cash with external banks or using SWIFT as a single connection gateway to the banking world. For most of these reasons, cost is not necessarily the issue; it is more a strategic decision.
Ed, when you started to build the business case for SWIFT, what was hardest to sell internally?
Ed BarrieWe didn’t spend a lot of time doing an extensive business case. It was really a strategic decision in moving towards a single channel to communicate with our banking partners. I would say that our internal IT organisation was the most sceptical. Their concern was not with SWIFT as a “pipe”, but the use of the standards and how these would be enforced. We’ve now connected with 25 banking partners for statement reporting, both prior day and intraday, and we have a single map for each of those messages. So standardisation is achievable, which came as a pleasant surprise to our IT organisation.
[[[PAGE]]]
Manish, you’ve helped customers through this process. What advice or recommendations do you have in terms of building a business case?
Manish Jain
One thing I would mention is the importance of managing expectations. There is often the view that by moving to SWIFT, all your messaging standards will become consistent across banks and across branches. That’s not an easy task, as although standards exist, there are different interpretations. So a lot of these messages need to be customised so they can be imported into your back office systems. If you don’t have the time to invest in this, or for testing with your banks, the whole project execution is jeopardised.
The second thing is to build the ROI in stages, for example: first, focusing on rationalising connectivity; second, achieving global visibility; and third, rationalising FX etc. It is far easier to set smaller goals and measure your ROI against them instead of trying to deliver a whole diverse project.
I’ve heard a lot about FIN for treasury payments and how secure it is. In our case, we have a single connection already through Citi with excellent security. Through this channel, we have connections with many banks and many countries. We’ve already achieved this without the need for SWIFT. For me, the issue would seem to be getting the standards right. For a company like ours, SWIFT doesn’t seem to be the answer. People also talk about the benefits of FileAct, but if you have a shared service centre and are using one bank would you really need SWIFT? Possibly not.
Our focus has been mostly FIN MT940 and 942 statement reporting. We have just started using FileAct with Citibank to receive our billing analysis files for both our U.S. held accounts as well as our accounts in EMEA and we’re now looking at moving other traffic with Citibank to FileAct. You mention shared services - I assume that you’re referring to Accounts Payable. At Microsoft, Accounts Payable is not part of treasury and forms part of our global shared services instead. They’re looking to us to be a leader in using SWIFT and want to see how well it works out for us. So it goes back to Manish’s point about establishing the credibility of the organisation - within the organisation.
Could you perhaps give some information about how long the project lead-time was and the biggest obstacles you experienced during the implementation phase?
Thomas MartinOur implementation of FIN payments through SWIFTNet has been quite a straightforward experience. Our service bureau BBP and SWIFT have both provided us with considerable support and advice. Since making our decision following an RFP process earlier this year, it took 9 months to go live on our first bank in October 2008 with the remaining two banks due to come on board by the end of 2008.
More challenging than the SWIFT connection itself has been the interface to our internal system. Part of the complexity of this was due to our wish to improve our processes as part of the project, which made the integration more elaborate.
A considerable challenge in the project, however, has been the legal documentation process with each bank. While the contract with SWIFT is a boilerplate agreement, which can be concluded swiftly, the legal documentation with the banks can be lengthy and cumbersome. Each bank has its own set of agreements and there is no uniformity between them. This is even more surprising when Group Treasury already has contracts in place with banks relating to payment services.
A considerable challenge in the project, however, has been the legal documentation process with each bank.
For us, the biggest lesson was during the testing phase. We spent a lot of time up front asking our initial pilot banks to send us test statements from their system to our test environment. Ultimately, this proved to be a waste of time, both for us, and our banking partners. What we learnt instead was to how to build routing rules, so when we on-board a banking partner we just ask them to turn on production statement reporting. When we receive the reports, we then dynamically route them either into our test environment or our production environment. That way, we don’t have to get dummy statements from our banking partner, which has a cost to both their IT resources and ours, for something that really has little value. So when we on-board a banking partner, we can have statements routed to our production environment in less than four days, with almost no IT resources required on our side. Going back to what Thomas mentioned, there can be a significant lead-time to on-board a banking partner, because of the service agreement or the legal agreement. We’ve received a straightforward two-page service agreement on one hand through to complicated 50-page service agreements on another, covering many nuances of SWIFT that would never even apply to us: precious metals and commodities etc. that we will never use. In some cases, we’ve been able to on-board a new banking partner in several weeks from the start of discussions to actually receiving statements. At the other extreme, it took 11/2 years to on-board one banking partner just for statement reporting. While I think the banking community is starting to make this process a little more efficient, there is still a lot of scope for improvement in this area. [[[PAGE]]]
In addition to publications such as the TMI SWIFT Guide, where should a corporate go to get the information that they need? There’s SWIFT, banks, solution providers and other corporates who have already achieved SWIFT connectivity. What’s the most logical way to get the information you need to make the decision for SWIFT?
This is a very young space and it can take a long time for any standard or initiative to mature and be adopted on a large scale. In my view, the best place to go is to your partner banks - they have been through multiple implementations already and they can advise you of the pitfalls. For example, at Citi we have adopted a collaborative approach, which brings together all the relevant players - service providers, SWIFT, your IT organization etc. We look together at how your treasury will function when you move to SWIFT. We design a solution from every perspective: data, security, connectivity, message flows and visibility. So my advice is bring your bank into the picture very early on and work together with all your partners to build a business case and a project plan for execution.
Banks are starting to realise that the relationship between corporates and banks is changing with liquidity management at the centre.
Ed, do you have many corporates asking you about your experiences?
Yes, we get asked by other corporations to talk to them about SWIFT quite often. We also partner with our main banking institutions to share best practices or challenges that we’ve seen to contribute to the corporate community as a whole.
Hans, what about you?
We are frequently approached by both banks and corporates. SWIFT connectivity is not simply an infrastructure project, and it needs executive attention from treasury. The sooner you involve your partners, the better, and the most important of these are probably your banks. In some cases you would be surprised by the level of preparation and support the bank is able to provide to you.
Banks are starting to realise that the relationship between corporates and banks is changing, with liquidity management at the centre. The events we have seen in the markets recently are to some extent an indication of where we are likely to go in the future. In many respects, the best liquidity provider for a bank is its corporate customer base. Consequently, banks will go to great lengths to retain their valuable corporate customers by providing a wider range of services, of which supporting SWIFT connectivity is one. We are seeing a great deal of investment and commitment amongst banks to support their corporate customers on SWIFT and help them to tackle the challenges.
We talked to other corporates, SWIFT and our banks as a way of collecting the necessary information. When talking to corporates, I think it’s easiest to talk to companies that have some similarities to your own business. After all, Ed’s experiences are not comparable to ours as we are a decentralised organisation and do not use a single system in the way that Microsoft does. So the business case for us would be different. For me, it’s better to look at a corporate, which may be very different in industry terms, but is using FIN messages in a decentralised environment. Then SWIFT and the banks can help me construct the business case, which I can then challenge with information I received from other corporate customers and their experiences. In our situation, our service bureau also helped us with this.
To what extent should SWIFT be a discreet offering from the bank? Should it be like getting a computer that says “Intel inside”? - should there just be a box that says “SWIFT inside”?
Manish JainIt’s an interesting analogy actually. Intel makes microprocessors or chips - the brains of the computer. With SWIFT, it is more of a messaging tool within the computer, not necessarily the processor. It’s a very fine distinction but a critical one. I tend to think of SWIFT as a messaging pipe. It provides the highway on which the messages can travel in a standard fashion. SWIFT has made a lot of progress in making that model simpler and simpler, year-by-year. They’ve brought down the cost of connectivity considerably, but an area of focus now is the messaging standards. There are still a lot of complexities here. If you want to make a payment in Russia and they need Cyrillic characters in the beneficiary name, you can’t use FIN. Even if you use the ISO20222 XML standard, there will be a lot of clearing houses, which will not yet recognize it. So there’s a great deal of work to be done to bring infrastructure across the market into line. That’s where I think SWIFT needs to focus and can make a difference by acting as a facilitator between all the market players.
Ed, would you share that perspective?
[[[PAGE]]]
Absolutely. I think Manish hit the nail on the head. SWIFT has put a lot of energy into evangelising to corporates, but it’s not a be-all and end-all solution and may not be the right solution for every corporate. I think the value that SWIFT can add is to communicate messaging standards and encourage market adoption across the multiple segments that are affected.
Another question Ed, going back to the beginning of the project and the ambitions you set out. Have you achieved what you wanted to by this stage?
I think overall as an organisation, we are where we wanted to be. Personally, I wanted to be using more of the messages in the capital market space and around OTC derivative settlement, and standards like FPML. In that area, the market is still evolving and a lot of those standards are still being worked out. So from a personal perspective, I would like to have been further ahead but as an organisation, we have a level of visibility into our bank accounts, balances and transactions that we’ve never had before. We’re able to share that information across the company and automate processes such as general ledger posting and reconciliation. So we made the decision to focus on areas that have the widest benefit to the organisation.
A question for Hans: do your clients find that they achieve what they expected having implemented SWIFT.
Hans CobbenYes, actually they do, notwithstanding the fact that the learning curve for every customer’s implementation is different. And although it can sometimes be a bumpy road, once they’ve stabilised the connectivity with their banks and the process is under control, they start seeing the added value. Often we see companies add more traffic through the connection to their preferred banks and they automate their treasury operations. Companies think about concentrating all their payments execution and reporting across the enterprise, and looking ahead to how their use of SWIFT might develop in the future. That’s really the advantage of SWIFT: being able to look ahead and take advantage of the services, which are gradually becoming available.
SWIFT does an excellent job in setting the scene for standardisation. But we need to take into account that standards needs to cater for the past as well as the future i.e. when putting in place new standards, you also need to take into account everything that’s already out there, all those interactions you already have with your financial institutions, that are based on either de facto standards or completely non-standard messages.
As a banker, I am often asked questions by corporates who are thinking about XML, just as they were thinking about Edifact some years ago. Are we going to reach the levels of standardisation that XML promises?
Absolutely. I think XML is the way forward. When we talk about standards under the old paradigm, there were standards, but these were very loose and subject to interpretation. So each corporate, each bank, used them quite differently. As we move towards ISO20022, an XML standard, it’s very strict and every rule needs to be interpreted consistently. At present, Citi is going through the single largest rollout of XML ever, across every region of the world. I think the greatest complexity that corporates will find with XML is the need to learn about the standard and adhere to the rule set which in turn means having to learn a lot about the banking system. To facilitate this, we have created a very simple guide alongside our XML implementation that helps you create all the necessary payment information. This also provides the statement information in XML that you can use for reconciliation.
Thank you to all the panel for their contributions, and to our audience for your participation and interaction.
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 […]
