SWIFTNet : Can Banks Afford to Delay Changing Track?

Almost 166 years ago, the first broad gauge train drawn by locomotive ‘North Star’ completed the journey from London Paddington to Maidenhead. For many, it heralded a new dawn and as the broad gauge railway network expended, so too did the benefits to both railway operators and passengers. The progress culminated in a Great Western Railways locomotive (The Flying Dutchman) becoming the fastest train in the world and remaining so for several decades.

Despite the obvious advantages, the huge leap forward in railroad technology that broad gauge represented met with a swift end. The other railway companies refused to migrate to the new standard and in 1846 the Gauge Act forced all new railroads to be built to the old, narrow gauge specifications.

The brief episode of our railroads’ flirtation with new standards provides us a salutary lesson when it comes to the adoption of new technologies in our industry – and one we would do well to heed when it comes to the adoption of SWIFTNet.

Clearly, there are many benefits to both banking organisations and their customers in the migration to SWIFTNet. First and probably most importantly, is cost. SWIFTNet will undoubtedly reduce the cost per message through its IP-based messaging. Moreover, real-time capabilities and the removal of the message size limitation will enable banks to deliver far more comprehensive information and services to their client organisations, adding a richness not previously possible. And if further incentives were needed, the threat of financial penalties for banks that continue to use the old service and its impending closure mean there is very little reason not to migrate as soon as possible!

These benefits add up to a clear rationale for migrating. When you add the additional benefit that SWIFTNet enables corporate access to SWIFT via Member Administered Closed User Groups (MA-CUGs) then there is even further incentive since it will enable corporate customers to communicate directly with their banks using SWIFT message types and SWIFTNet as the communication platform.

This represents a major benefit for customers, particularly those with many accounts or high transaction volumes. For a start, it means communication with the banks can be accelerated enormously, providing client organisations with real-time information. In turn, this means clients can make more informed decisions about their cash and how they manage it.

Moreover, the move to the secure SWIFT network may help overcome any lingering concerns regarding the use of the Internet for exchanging information between banks and corporate customers.

Finally, the use of SWIFTNet as a standardised messaging platform will help reduce system integration costs over time, particularly as client organisations start their internal transition from costly ‘fat’ client-based, dial-up technology to secure IP-based communication and as an increasing number of ERP and accounting systems will support SWIFT message types.

For banks, SWIFTNet represents an excellent opportunity to save costs, as the price per transaction using SWIFTNet will fall dramatically. This means that financial service providers whose business model includes providing standard transactions in high volumes will benefit enormously. In other words, tier one banks will benefit from the migration to SWIFTNet.

And therein lies the problem, because tier two banks are likely to suffer from the transition. Why? Well, put simply, they do not have the transaction volumes that allow them to get a return on their investment into SWIFTNet as fast as larger banks.

In addition, with the standardisation of processes via SWIFTNet, there is a danger that banks will lose control of their customers. If we take an extreme case, it will illustrate the point. In the medium-term, it is perfectly possible to see that electronic banking might be reduced to a customer’s system electronically communicating with a bank server using a basic set of standard messages. If this is the case, the bank quickly loses its ability to present a unique identity and becomes very expendable.

Taking a more mundane analogy, it’s as if banks suddenly become like electric sockets into which many different household items can be plugged and which access a standard product (i.e. electricity). The only differentiating factor is the price at which the product is provided.

A further problem for tier two banks is that many of their customers – in general, the smaller and medium sized corporations – are unlikely to migrate as comprehensively and as quickly to SWIFTNet. The cost, in terms of technology purchase, manpower to deliver the migration and integration or change of business processes, is prohibitive to many and will certainly slow down the majority in their decision.

A potential solution to these issues is the introduction of new business services from SWIFT, such as cash reporting and bulk payments. These may help provide quick and easy packages for tier two banks to sell onto their clients as a means to encourage integration.

But the standardisation of business services will mean differentiation may only be possible through price. And that is not a game many banks want to play, and one tier two banks cannot afford.

Consequently, the priority for banks should be on investigating how unique value added services can be created based on the new capabilities offered by SWIFT.

Banks in general, and tier two banks in particular, need to be able to identify how they can support their customers and build solutions that help them meet their business goals. The use of SWIFTNet as the core technology will facilitate this process and enable the banks to add real value by delivering solutions to real-world customer challenges.

For example, it would be possible to combine cash reporting with alerting to inform the CFO of a corporate customer of events having a significant impact on the financial situation of his company. Another example might be a flexible sweeping service, which monitors the cash position of a client across multiple accounts, held at various banks and then concentrates the funds where appropriate.

A further example is in payments. A bank could deliver a solution that enables clients to submit batch files with MT101 messages and then, based on individual transaction criteria, find the most cost effective way of making the payment.

These examples have one thing in common: they use the new capabilities available through SWIFTNet as a starting point for creating customer-focussed value-added services.

To my mind, they clearly show how SWIFTNet should be adopted across our industry. It should be used as the standard message exchange platform, but that’s where its involvement should end. SWIFT should empower banks to use the platform as the basis for delivering great solutions rather than compete against them with business solutions.

In other words, SWIFT should concentrate on its core strength of delivering a world-class messaging platform to the banking industry capable of delivering real-time, secure IP-based transactions as well as standardising basic messages, but leave business solutions to the banks. Otherwise there is a danger that at some time in the future SWIFT, with its business solutions, will actually start competing against its members. If all parties focus their strength, banks will be able to profit from the migration to SWIFTNet through a reduced cost per transaction while supporting their customers’ needs, which in turn will help the banks maintain their market differentiation.

If we are to learn anything from the near miss with broad gauge railways, then it is imperative SWIFT takes on the responsibility for laying the rails while allowing the banks to deliver the ‘locomotives’ that meet customer demands. Each party can concentrate on what they do best, providing the net result is solutions that help banks and their customers achieve their business goals.