SWIFT: The Magic Bullet for Treasury?
Today, SWIFT is well established within the world of banks and financial institutions as the standard for formatting financial instructions and the method of communicating those financial instructions. This is a remarkable achievement given the technological challenges that existed when the banking industry acknowledged the significant global problem presented by manual processes, isolated systems and language hurdles that prevailed more than a third of a century ago. It was 1973 when a group of 239 banks from 15 countries came together to create a communications link and a common language for international financial transactions. The Society for Worldwide Interbank Financial Telecommunication (SWIFT) was formed.
By the time the SWIFT network was implemented a few years later, the number of organisations as members of the co-operative had grown to more than 500. There was obvious demand for a solution to the growing problems faced by the financial industry that was rapidly expanding around the world. Almost 3.5 million transactions were processed in that first year.
The statistics published by SWIFT demonstrate that the solution has been embraced by the financial world. In January 2010, over 8,300 banking organisations, securities institutions and corporate customers in more than 200 countries processed some 300 million financial messages.
So, what is it that SWIFT provides that has created such recognition and demand? The network provides the proprietary communications platform, products and services that allow its customers to connect and exchange financial information securely and reliably. It is solely a carrier of messages: it does not hold funds, manage accounts on behalf of customers, or store financial information on an on-going basis.
As a data carrier, SWIFT transports messages between financial institutions. This activity involves the secure exchange of proprietary data, while ensuring its confidentiality and integrity. SWIFT transports financial messages in a secure manner and, possibly most importantly, guarantees message delivery, or ‘non-repudiation of emission and reception’, as the society defines the concept. SWIFT has defined message standards and has become the industry standard for financial message syntax. Its formatted messages are the de facto standard for messages between financial institutions. In fact, the dominance of the SWIFT message standard is such that many messages that are formatted to SWIFT standards will be generated and read by financial software systems even though they are not delivered via the network.
It is clear that SWIFT has solved many of the problems that the financial institutions were confronted with, and has undoubtedly saved huge amounts of expenditure at thousands of financial institutions that would otherwise have required investment in systems to recognise each bespoke message format. It also prevented adding the necessary personnel to use and support those disparate systems.
The question to ask now is, has SWIFT confronted and beaten all of the financial instruction challenges that the world has today? Any individual that has received a foreign denomination payment and then attempted to deposit it at their local bank will know that the problems have not all been resolved. At a time when an increasing amount of personal banking is performed electronically from a home computer, it comes as a surprise when the bank clerk asks requests that a paper form is completed and replicated five times using carbon paper. Are these problems restricted to high street banking, though? The short answer is no.
While financial institutions have driven forward the concept of straight-through processing (STP) for all of their international requirements, many corporates have been getting on with the task of growing their businesses around the world. Thousands of corporations are now recognised as global organisations with a presence in many countries, millions or billions of dollars in revenue, thousands of employees and, unfortunately, hundreds of banking relationships in a huge variety of countries and currencies. Those banking relationships present a real headache for global corporations. Invariably, there will be different banking relationships at each location and, commonly, those banking connections have proprietary methods of communication.
Each location will typically have specialists that have analysed the requirements of each banking solution and developed bespoke software to electronically interface with those banks. And it is common for each national payment system to have developed its own national payment format that has to be adhered to. Each interface will necessitate support associates to monitor the interface operationally and resolve issues when they arise, while treasury operations associates will be dedicated to collecting information from those banks. The systems are not set in stone though – they’re changing on a regular basis in response to the relentless evolution of message formats, connectivity protocols, security requirements and market changes. Alongside the cost of maintaining the messages, there is the ongoing cost of network connectivity, even though the connectivity can be idle much of the time in the smaller regions of the organisation. Therefore, the cost at each location is considerable – and when replicated at every location, the cost can be enormous.
Corporate treasuries are not immune to the pressures facing every organisation. Every firm has cost constraints and efficiency requirements. The corporate treasury department faces the conflicting demands of reducing costs while gaining greater control of the firm’s financial situation. The challenges facing these corporations, particularly the treasury operations departments, are not dissimilar to the challenges facing the banks 37 years ago. SWIFT has recognised the need and is now expanding beyond its core client base of banks and financial institutions into the world of ‘corporates’. Corporates are now being encouraged to connect to all of their banks through this one channel to gain the benefits of a messaging standard that is established within the financial community, combined with a highly secure global network and guaranteed message delivery.
The problem of multiple banking relationships and proprietary links to those banks has been identified, and SWIFT has a proven solution that is ready to meet the demand of corporates around the world – it already has the messages standardised and already has connections into a significant majority of the banking world. Corporates should just need to plug their systems into the network to begin realising the accessible benefits. SWIFT should have thousands of organisations banging on the doors to its offices, demanding the implementation of the SWIFT connectivity so they can embrace the revolution. That hasn’t occurred though, or at least not yet. Undoubtedly there are many examples of corporates that have approached SWIFT, have implemented the connectivity and realised the cost savings available. But there are many firms that have not undertaken the investigation at all, and others that have investigated the opportunity and then stepped away. Why is that?
Firstly, there is the undisputed history that SWIFT has been cultivated to meet the demands of financial institutions. That history has developed pockets of deep understanding within the financial sector with very sparse knowledge outside of the industry. It is a bold step for corporates to enter into a world where they have little experience and the concepts are unfamiliar to them. SWIFT messages have a terminology and a language that is readily passed around by experienced users, but which is meaningless to the outside world. The MT and MX messages, message tags, ISO 20022, the SAA and the SAG are all immediate examples of terminology that feels esoteric and potentially puts a barrier to entry.
To realise the benefits available from SWIFT, corporate firms need to gain the knowledge and capability to allow them to unify their current systems into a single, new interface. That requires specialists, which incur additional cost. Where many different banking solutions are used today, the SWIFT specialists, if resourced in-house, would conceivably need to be transported to each location to analyse and change systems, possibly on systems where volume and value of payments may not justify the investment. Even when the SWIFT interface is implemented, there will continue to be the ongoing costs of maintaining that interface and managing the hardware.
On top of all this is the risk of change. For many firms, the laissez faire situation is tolerated as the treasury operations department is seen as a necessary cog in the engine of the corporation, and banking interfaces are simply part of the cost of doing business.
However, there is an alternative approach that provides corporates with a straightforward transition to the services of the SWIFT network while also containing costs. SWIFT service bureaus are now being established and are welcoming corporates, as well as financial institutions, into discussions on how they can supply solutions to meet their needs. Firms of varying size are able to leverage a model where the costs charged are proportionate to the transaction requirements. These service bureau offerings provide connectivity for many concurrent clients from a data centre, generally conforming to internationally recognised standards of service with high degrees of security, resilience and disaster recovery.
Having many clients allows a service bureau provider to deliver economies of scale – and the costs can be far less than providing the solution from an in-house IT department. The data centre associates servicing the clients will typically provide support on SWIFT messages exclusively and have extensive experience with SWIFT terminology and the nuances of the messages. These specialists will usher firms through the process of gaining fast-track and low-risk access to SWIFT. Often these associates will have achieved qualifications recognised by SWIFT. Where the vendor firm is servicing corporates with a global presence, the service bureau will support the system around the clock or may have additional offices servicing the different time zones. Service level agreements ensure that users get the service they require. At a general level, the service bureau should typically have the scale, service orientation and financial backing that is expected of an entity that will be processing all of a corporate’s financial transactions.
Additional benefits to users of the service bureaus may come from the user functionality that is made available to them. The more advanced service bureau offerings will typically be highly functional, easy to use and browser-based. The software will support many demands, including message transformation of data received in a variety of proprietary formats from the back-office systems; data segregation for different locations; manual entry that allows non-specialised users the ability to enter SWIFT instructions; data and syntax validation; workflow for secondary authorisations if required; monitoring of messages; and STP – all within a real-time system. The service bureau providers will work with the users to customise the solution to the exact demands of the client. It is commonly possible for messages currently being sent to proprietary banking interfaces to simply be re-routed to the service bureau for message transformation into the SWIFT format with very little change to the back-office systems. Going forward, the service bureau may commit to proactively change messages in line with the evolving SWIFT requirements.
Corporations now have a viable solution to the problems presented by the internationalisation of their businesses and the resulting multiple bank connectivity requirements. The financial institutions realised SWIFT’s potential a third of a century ago and corporations now have a genuine opportunity to leverage the same solution and realise comparable benefits across their multiple banking relationships.