With new rules coming into effect on Jan 1 2015, this is the eigth in a series of posts on how banks and FI’s might adapt.
In most FIs, the product processing systems each communicate directly with SWIFT. Figure A illustrates the typical set-up. Over time, different entities have acquired their own gateways. A gateway is a piece of technology that forms a secure connection with SWIFT. It is not an application per se, just a switch. To make the point, it is not possible to open up the gateway and then bark a command at it: “Stop all payments going to Cypriot Bank X”. The more complex the SWIFT set-up, the harder it is to achieve the internal integration talked about above.
Where there are multiple entities in the same location, it is common to share the infrastructure. It is less common to migrate platforms when there are mergers, so it is possible to have old legacy SWIFT platforms. So in a large organisation, it is easy to find yourself with multiple SWIFT gateways. To illustrate, I’ll use the example of Credit Suisse, where I was intimately involved with an overhaul of the SWIFT connectivity.
Fig A – Typical SWIFT Set-Up
KISS. Keep It Simple, Stupid. 29 million reasons that prove banks can’t spell it.
At the start of the 2000s, SWIFT decided that it was time for a big change. Not just the annual release, but also a move to a brand new messaging protocol.
I think X25 was the old standard and IP the new one. It matters not; it was big. So with the goal fairly clear and some mandatory change in sight, at Credit Suisse we had to figure out the “where” part of the project. Where in the bank, globally, were there SWIFT installations that needed changing? A quick bit of research later, we found that the firm owned some 90 or so active BICs, i.e. the unique identifiers for a bank or its related group companies. These 90 BICs were spread across no fewer than 29 different SWIFT installations around the globe. Every one of them was creating very little noise on a day-to-day basis, and many of them had been inherited through acquisition. We did some quick math; each installation would require a minimum amount of work, which we estimated to be four man-years, which equated to about USD 1 million on a fully loaded cost basis. Per installation. So we were looking at costs of at least USD 29 million just to “keep up”, not to make a penny more in revenues but just to be able to operate. We pretty quickly found out that there was technology available to allow us simply to have two hubs to let the spokes feed into. Our recommendation to the steering committee was an easy sell: by centralisation, we could slim the whole thing down to 2 main connections and projects and to 27 small adjustment projects.
Lessons Learned: The point of a big change is a wondrous moment. You can make like President Putin in Russia: diktat. Say no, and tell those involved that any inter-divisional price and service issues should get sorted out in the CEO’s office. Gloves off if need be, but certainly, any inability to act rationally should not spill over to your world. Cut out the complexity.
Now, a word of caution is due here. In and of itself, a set-up with 29 installations doing the same thing would seem a horrendous inefficiency; however, it is wise to bear in mind the maxim, “If it ain’t broke, don’t fix it”. If no investment is needed, then all marginal costs are an expense and not a saving.
Clearly, there is a lot of benefit in terms of IT project work and in run-the-bank IT costs if you can centralise all these things. There is a huge potential upside in SWIFT messaging costs. In Figure 15, when entity A sends a message to entity B, this happens in the real world, for the usual fee plus expenses. We highlighted in the previous section how many internal trades there are. It’s quite normal to have internal trades make up 40% of your volume. Over and above the cost of paying the Nostro or the custodian, SWIFT wants its modest stipend too, for moving your message from your shop to its destination. Now, a SWIFT message is only a few cents, but a cent here and a cent there, and pretty soon you are talking serious money, even with today’s SWIFT fixed price model. (Where, rather like mobile phone plans, you pick a plan, and if you use fewer messages, the next business change does not need to add to the volume and potentially increase the fixed plan, or you can switch to a smaller plan.)
It follows that you can reduce the number of messages you pay for by using your own SWIFT infrastructure to move messages between legal entities. The ability to do this was an intended side effect of the project at Credit Suisse. When we told some of the longer serving staff that looked after our SWIFT connectivity about this, one or two of them were dismayed. “Well, our volume will go down and then so will our tiering, which will increase our average price, and of course, then we won’t be so high up the league tables in SWIFT.” Ignore all of these cries. What matters is the total spend and not the average price. The optimised set-up is illustrated in Figure B.
Figure B: Centralised SWIFT Set Up
A personal request: Finally. I have ventured into self-publising. The not so creatively titled, but practical guide: “Cash & Liquidity Management: Mastering the Challenges of New Regulations and a Changing Marketplace” is now available in print and on Kindle. All the bits form the Blog are there, together with a lot of detail on current challenges. Many of those challenges will take effect on Jan 1 2015. Time to be well informed!
UK: For the print version and Kindle users: Click Here
US: For the print version and Kindle users: Click Here
Hot on its heels is a book on wider operational matters: The Bankers’ Plumber’s Handbook. Coming soon.
Thanks for your support and thanks to the numerous contributors.
Share on:
