Published: September 22, 2008
When Shakespeare wrote Richard III in around 1591, he meant something different when he wrote these famous lines, but “True hope is SWIFT” is the essence of this Guide. Corporates have struggled for many years to connect to their banks in an efficient, consistent way. Telexes, faxes, electronic banking systems - each have represented a step forward, but each brings limitations. Few corporates today are fortunate enough to have a single channel for communicating with all of their banking partners; fewer still can send files in the same format to each bank. Each system has its own functionality, its own security requirements and user setup and receives and transmits files or messages in a particular format, often differing across country or region.
The ability for corporates to communicate to their banks through SWIFTNet (see Section 1 below) is in many respects a giant leap forward, but to date, it has left only a light impression on corporate treasurers’ consciousness. There is a definite increase in the number of corporates seeking to connect to their banks through SWIFTNet, but this growth has been steady rather than meteoric. Markus Straussfeld, Director, Cash Management Sales, HypoVereinsbank (Member of UniCreditGroup) explains,
“The largest corporates were the first to move to SWIFT with the highest value or highest volume of payments. Now, smaller companies see the advantages, providing a solution to a problem they have had for some time, namely finding a single application to connect to all their banks.”
As a common channel, SWIFTNet (the SWIFT network) should create a level playing field for all banks, and indeed all corporates which communicate through it. In theory, banks should all be able to offer comparable services, and standardised information through SWIFTNet. So too should corporates be able to access the same information from any connected bank. While there is still progress which needs to be made, there are significant advances being made by pioneering banks and their corporate customers, as the case studies in this Guide illustrate.
In the next section, we give a summary of SWIFTNet and an explanation of some of the terminology. Secondly, we discuss standardisation in more detail, particularly XML standard ISO 200222, and finally, we look at some of the challenges which still remain. [[[PAGE]]]
Section One: Frequently Asked Questions
SWIFT (Society for Worldwide Interbank Financial Telecommunications) is a co-operative founded in 1973 by 239 banks in 15 countries which aimed to establish a set of standards for communicating information on financial transactions. This has evolved into a financial messaging network which now has nearly 8,000 members across more than 200 countries. Its members include banks, broker/dealers and investment managers. Partners exchange a wide variety of financial messages across a common, reliable, secure infrastructure - SWIFTNet.
There is no ‘standard’ profile of corporates whose treasury and finance operations are best suited to SWIFTNet connectivity. In some cases, other connectivity options, such as web-based systems and host-to-host systems provided by the banks will still be more appropriate. For example, few corporates with a single cash management bank will gain considerable benefits from seeking to connect through SWIFT; however, as the number of banking connections increases, so too does the SWIFT value proposition.
SWIFT should not be confused with standardisation. Use of standards such as ISO 20022 (see Section 2 below) is a generic industry development which is applicable to any connectivity route, not just SWIFT. Some of the reasons for considering SWIFT connectivity include:
Improve straight through processing (STP)
Effective transaction processing requires a cohesive technology infrastructure both internally and externally. For example, if all payments are channeled effectively through a single payments hub within the organisation but then need to be sent to multiple banks through different systems, many of the benefits of STP are lost. By using a single channel, operational risk is reduced considerably and the timeliness and efficiency of transaction processing enhanced.
However, it should also be noted that having a single channel for external communication will only deliver advantages if transaction processing internally is similarly efficient, using a centralised payment system.
Reduce costs
Maintaining multiple banking systems, plus the interfaces between these and internal applications can be a time consuming and costly process. Replacing multiple systems with a single channel for bank communication can significantly reduce these costs. Markus Straussfeld, UniCredit emphasises that the business case for smaller companies may not relate to technology however,
“The smaller you are, the less resource you have available to deal with banking applications. Consequently, the business case is often about people rather than technology.”
Establish common approach to security
Each banking system has its own security requirements, so it is often impossible for corporates to implement a consistent approach to security. Furthermore, the integrity and confidentiality of transactions over SWIFT is guaranteed. Many companies have to deal with maintaining individual user IDs, passwords and user profiles in multiple systems, creating a major systems administration requirement Security is frequently the overriding reason for connecting through SWIFTNet, which is universally acknowledged to be the most resilient and secure network for financial messaging.
Achieve global cash visibility
Companies with bank accounts held in different accounts and regions often find it difficult to create an accurate global cash position on a timely basis. This can create problems with cash centralisation, working capital optimisation and ‘trapped’ cash overseas.
The business case for SWIFT connectivity can be compelling, as the case studies in this Guide illustrate. However, Linda Haddad, Senior Vice President, Global Integration and Product Manager, Bank of America urges caution:
"There have
been a number of high profile return on investment (ROI) statistics on the benefit of SWIFT for corporate clients. These need to be taken with a pinch of salt as the way they are calculated is not necessarily clear. In reality, corporates should have a sound long-term business reason to connect through SWIFTNet, not simply be seeking a 12 month ROI.”
Angela Potter, Head of International Trade and Cash Solutions, Barclays Commercial, continues:
“There must be a tangible and measurable benefit in joining SWIFT besides the efficiency gains available through the using the common/open standards provided by SWIFT. The specific benefits will differ according to the current challenges which a corporate may be experiencing; however, in our experience, some of the primary reasons for corporates to embrace SWIFT include:
Of these, bulk payment processing is probably the most compelling reason to join SWIFT. Companies with high volumes of payments (whether domestic or international) which are centralised through a payments factory or shared service centre (SSC), can achieve maximum STP and later cut-off times by delivering payments through SWIFT.” [[[PAGE]]]
What are MA-CUGs and SCORE? - and what’s the difference?
MA-CUG stands for ‘Member-Administered Closed User Group’, a model for corporate connectivity to SWIFT launched in 2001. A bank will set up an MA-CUG which its corporate clients can join in order to be able to send and receive information from all of the branches of that bank through SWIFTNet. Corporates with more than one banking relationship need to join each bank’s MA-CUG. For corporates which are eligible (see below) MA-CUGs have largely been superseded by SCORE (see below) but most corporates which already connect to SWIFT do so through one or more MA-CUGs.
Joining more than one MA-CUG was proving frustrating for corporates, due to the documentation which needed to be completed (although as we will discuss later, this problem has not yet been fully addressed) and differences in the way that banks presented information. SCORE was launched in 2007 to make it easier to connect to multiple banks and ensure more consistent access to information. Rather than having to join each bank’s MA-CUG, corporates have to join only once. Banks which are SCORE-compliant sign up to an implementation guide which outlines the way in which FIN and FileAct messages should be structured.
Not all corporates are eligible to join SWIFT through SCORE. Companies must be listed on the stock exchange of a FATF (Financial Action Task Force) member country, which includes European and North American companies as well as some parts of Asia Pacific, Mexico and Brazil. Companies listed in other countries or those that are privately held are ineligible for SCORE but can still access the SWIFT network through one or more MA-CUGs.
There are three messaging mechanisms on SWIFTNet relevant to corporate treasurers, the most significant of which are FIN and FileAct. Essentially, FIN supports the messages relating to treasury transactions and high value payments while FileAct provides functionality for low value, high volume payments.
FIN
Examples of message types include:
SWIFTNet FIN is an extremely reliable messaging system and works on a ‘store and forward’ basis. If the counterparty bank has a system failure, a message that cannot be delivered is stored centrally and transmitted once the counterparty is back online.
FileAct
SWIFTNet FileAct is a secure file transfer system for batched messages or large reports and is typically used to send mass payments (such as invoice payments, salaries, etc.) collections and reporting. Messages are exchanged in real time and a range of formats are supported. A rapid development of new capabilities through FileAct is taking place. For example, some banks are now delivering MT 940 messages through FileAct and Barclays is pioneering the new UK Faster Payments Scheme through SWIFT, which means that FileAct is becoming increasingly attractive to corporates. Markus Straussfeld, UniCredit emphasises,
“FileAct is the growing trend amongst corporates and there are considerable enhancements in the services which are being made available. Over time, we see FIN declining in favour of FileAct”
InterAct
SWIFTNet InterAct is a new service for queries and responses based on XML standards. [[[PAGE]]]
SWIFT connectivity can be direct or indirect. The majority of corporates now connecting to SWIFT do so indirectly through service bureaus and member/concentrators:
Direct
This means that the corporate sets up the SWIFT gateway software (or middleware provided by a third party) and manages it directly. However, the SWIFT gateway does not provide the validation or approval of messages, which needs to take place before messages reach the gateway. Consequently, the SWIFT gateway software is used in conjunction with a treasury management system or payment factory system so that these processes can be managed consistently.
Indirect
There are two types of indirect connectivity:
Service bureau
A service bureau hosts the SWIFT connectivity infrastructure. Service bureaus can be convenient and cost effective and avoids the need to maintain in-house skills. As Hans Cobben, Group Vice President, Global Payments and Messaging, SunGard explains,
“As corporates evaluate the costs and operational requirements for SWIFT connectivity, they often realise that they do not want to bear the upfront investment and ongoing management overhead of connecting to SWIFT directly, using their own in-house infrastructure. For this reason, many corporates are turning towards a service bureau to provide the infrastructure and connectivity.
A SWIFT service bureau is often a less expensive, faster and easier alternative to direct connectivity, allowing for a full range of SWIFT messages including securities, treasury, derivatives, payments and corporate actions in a fully serviced and secure environment. The indirect access model offers a continuum of service that helps satisfy SWIFT requirements from the largest to the smallest operations.
This method essentially allows the corporate to outsource the management of the network and connectivity while still offering the same benefits and level of access afforded through a direct connection. The added benefit is a lower total cost of ownership as well as lower operational costs required to support and administer and in-house solution.”
A list of service bureaus is available from SWIFT at www.swift.com/index.cfm?item_id=42521
Member/Concentrator
Member/Concentrators are SWIFT members which provide SWIFT access for smaller institutions. They perform the same services as service bureaus such as the connection to SWIFTNet and the conversion of transactions into SWIFT messages on behalf of its customers, and also manage the SWIFT administration. For companies with smaller volumes, member/concentrators are often the most cost-effective means of connecting to SWIFT. A list of service bureaus is also available from SWIFT.
Section 2: Standardisation
While establishing a common communication channel with one’s banking partners may be a step forward for many corporates, it is not an end in itself. If each bank transmits and receives data in a different format, there may still be significant effort required to create the relevant files for each bank, and to create rules for processing the files which are received, for example for account posting and reconciliation. These challenges frequently persist throughout the financial supply chain.
The answer to this dilemma is to standardise the way that data is presented, so that all parties to a transaction, and their systems, have a common understanding of a piece of information and can therefore handle it consistently. While this might sound logical, few issues in the financial services industry appear to have created more angst. Standardisation is an emotive issue. Oscar Wilde said,
“Consistency is the last refuge of the unimaginative.”
While Oscar Wilde said many great things, this was not one of them. After all, how would he have communicated this thought without an accepted form of words which other people would understand? Where is the beauty in a poem if you can’t understand the language in which it is written? How does a composer propagate his art without a score which every musician can understand? Language, music and art, arguably the apex of human achievement, rely on consistent means by which to communicate. [[[PAGE]]]
In the banking world, there have been various attempts in the past to standardise file formats which have had only moderate success, such as EDIFACT. As Linda Haddad, Senior Vice President, Global Integration and Product Manager, Bank of America explains,
“Originally, banks hesitated to open their doors to corporates by supporting standardisation as they feared that they would be forced to compete on price rather than service. In reality, this is not the case. Corporates want to connect through a bank-independent channel using standard formats not so that they can change banks but to remove the headache of connectivity and concentrate on their core business.”
Somewhat overdue, perhaps, banks now see the value of standardisation and are prepared to promote it actively. The outcome of this is ISO 20022 or UNIFI (ISO 20022 UNIversal Financial Industry message scheme). This is the platform which the various industry bodies, including SWIFT, have agreed upon for developing financial messages, based on XML, and will ultimately cover a wide range of financial messages. XML stands for Extensible Mark Up Language. It does not replace existing programming languages, but adds a series of ‘tags’ so that information held in different systems using different languages can be universally understood.
The standard includes rulebooks to ensure that every organisation applies the standards uniformly. Some banks and corporates have already piloted ISO 20022 formats successfully and as the standard for SEPA payments, there is considerable incentive for it to be successful. The difference between ISO 20022 is the manner in which it has arisen, as rather than being created by a standards group with limited members, the development of ISO 20022 has involved SWIFT, banks and corporates in a highly collaborative way. There are still challenges which remain in the wider adoption of ISO 20022, particularly to avoid individual parties developing their own variations, but the experiences of corporates and banks to date have been positive.
Section 3: Outstanding Challenges
As the case studies in this Guide illustrate, many corporates have had considerable success in their implementation of SWIFT. However, it is also clear that some have experienced significant challenges.
One of the objectives of SCORE was to reduce the amount of documentation which corporates needed to complete to permit them to access SWIFT. However, in many cases, this has not proved the case. Most banks require specific documentation to allow corporates to access and transmit data through SWIFTNet, in addition to existing agreements in place between the bank and its corporate customers. In some cases, these agreements are short documents which are quick and easy to negotiate while in others, lengthy contracts are required. Few corporates anticipate this aspect of the project, which can be extremely time consuming (some corporates have indicated that a bank contract for SWIFT has taken up to a year to conclude) and requires costly legal support. While every bank will continue to want to protect its own interests, the documentation required can be a major project hindrance. As Linda Haddad, Bank of America, explains,
“It’s surprising that the biggest complaint we see amongst corporates connecting to their banks through SWIFTNet is documentation and the technology is secondary. This is something the banks need to do more to improve the experience of their corporate customers. For example, at Bank of America, SWIFTNet is just another channel so we do not ask for any additional agreements when a company joins through SCORE. As most corporates don't encounter the issue of documentation until the implementation, they do not necessarily perceive it as a differentiator but it is a significant issue.”
If you are considering SWIFT connectivity, ask your banks for a copy of their SWIFT documentation when you first start discussions with them. This will give you a better idea of the time and effort which is likely to be required to complete this stage of an implementation project. There are also some discussions about establishing standard documentation but this is unlikely to happen soon.
Corporates that were amongst the first to implement SWIFTNet connectivity inevitably found that some of their banks lacked knowledge of the SWIFT corporate offering. While this may still be the case in some regions (such as Belcorp’s experience in Latin America) most major banks are now familiar with SWIFT for corporates and are actively promoting it. There are some surprising exceptions, however. We have discovered one or two major banks that have little experience and even less interest in SWIFT for corporates. Amongst the banks with greater experience, relationship managers have often had no exposure to SWIFT for corporates and do not know how to direct corporate enquiries. Working with a bank with sufficient expertise, and the ability to mobilise it effectively is clearly important. Markus Straussfeld, UniCredit explains,
“We have centralised our expertise on SWIFT corporate access into specialist teams who deal with sales, product management etc. so that we have the right concentration of skills.”
This is again an issue to address before embarking on a project: ask to meet the bank’s SWIFT experts, and make sure that these are the people who would be involved in an implementation. [[[PAGE]]]
As some banks still lack the experience in SWIFT for corporates, a related issue is that project plan templates are not always available. This makes it difficult to allocate project timelines, determine resource requirements and schedule tasks. While this problem was more significant for early adopter corporates, you should still discuss the implementation fully before starting the project and ensure you are happy with your bank’s approach. As Angela Potter, Head of International Trade and Cash Solutions, Barclays Commercial explains,
“Like any complex project, the success of a SWIFT project is dependent on the skills and experience of the implementation team. Barclays has invested substantial resources to ensure that we can help our clients achieve their business objectives, enhancing straight through processing and increasing reconciliation automation.”
SWIFTNet is not the only means of communicating with banking partners and it seems highly unlikely (and undesirable) that it will replace existing methods such as web-based and host-to-host banking systems. However, it is becoming a more realistic alternative for corporates with the appropriate business case. The reasons for connecting to SWIFT are likely to multiply in the future. For example, as corporates increasingly integrate trade finance and cash management, we see SWIFT becoming a more important communication channel for trade and cash transactions such as letters of credit etc.
As SIBOS last year saw the first announcements of SCORE, so this year we are expecting announcements on SWIFT Alliance Lite, a more accessible connectivity mechanism for corporates with lower transaction volumes. Many of the challenges that early adopter corporates have experienced are ‘teething troubles’ and implementation timescales are reducing now that expertise in SWIFT connectivity is developing.
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 […]
