Oceans Apart and Miles to Go
As the birthplace of SWIFT, for years Europe has embraced widespread use of open standards for cross-border payments, in addition to national and trans-European real-time gross settlement (RTGS) systems such as CHAPS and TARGET. In fact, more than 65 per cent of all SWIFT messages today originate from Europe. That said, there exists a striking contrast between the ways in which banks in Europe and the US are responding to a relatively new proposition that offers corporate clients direct access to SWIFT’s secure financial messaging network.
For the most part, eurozone banks have quickly recognized the benefits of extending SWIFTNet to corporate clients. In particular, the French banking community has led the way in pioneering corporate access to SWIFTNet. Yet despite this, UK and US banks continue to fall further behind in delivering these same SWIFT and SWIFT-related services to their customers.
In response to growing pressure from multi-national organizations to give treasuries direct access to SWIFT for payment and reporting capabilities, in 2001 SWIFT obtained their bank membership’s approval to launch Member-Administered Closed User Groups (MA-CUG). These closed user groups allow banks to entitle corporate customers with direct access to SWIFT’s financial messaging network. If a corporate client wishes to communicate with more than one bank, it must either join several MA-CUGs, or alternatively it can use an overlay bank to send and receive messages from other banks.
For corporate clients, joining MA-CUGs offers them the benefits of a single gateway to their principal cash management banks and improved straight through processing (STP) for better control, lower costs and less risk. As a result, the number of corporate clients on SWIFT has already grown to more than 60, with nearly 80 more in the process of registering their MA-CUGs with SWIFT. By the end of 2006, SWIFT anticipates the total number of corporate clients with direct access to SWIFTNet to climb to 350.
Across Europe, there have been several notable approaches to advancing the adoption of standards-based initiatives. For instance, before throwing emphatic support behind SWIFTNet for large corporate clients, banks in France have employed a common communication protocol known as ETEBAC. Germany has been driving organic adoption of common standards during the last two decades, as many banks in surrounding countries such as the Netherlands, Austria, Hungary and Poland have joined German banks in communicating with their corporate customers effectively and efficiently through Multicash.
While not as outwardly supportive of MA-CUGs as their European counterparts, there are signs that UK banks are warming to the notion. Early reluctance to direct SWIFTNet client access was due in part to the fact that UK banks have tended to operate behind the curve when it comes to “thin client” solutions that leverage the connectivity and accessibility of the Internet. Today, whether they offer “thick client” electronic banking workstations – requiring the customer to install proprietary software on each PC in order to interface with the banks – or thin client solutions, UK cash management platforms are increasingly well tailored to the needs of small businesses and mid-sized corporate clients.
In the UK, it is not uncommon for these businesses to conduct all their banking, including payments and collections, with a single institution. This single-bank tradition is largely due to an earlier consolidation of banks in the UK, and the structure of mortgage debenture under English law. This instrument enables a lending bank to take a legal charge over all of a corporate customer’s fixed and floating assets, which has discouraged commercial banks from providing unsecured credit facilities or other banking services to another bank’s client.
While the electronic banking platforms of UK banks meet the needs of SME customers, even the latest e-banking solutions arriving on the market are falling short of addressing the needs of many large corporate clients. More sophisticated by nature, corporate clients tend to be internationally oriented, and as such rarely maintain relationships with only one bank. Since many of these banks maintain their own proprietary banking platforms and formats, client interest in MA-CUGs has grown.
Unlike their French peers who have long enjoyed standard communication protocols nationwide, UK corporate clients have struggled to solve the back-office disconnect of having multiple bank interfaces and differing formats within their home country. They face similar challenges when trying to co-ordinate cash management across various subsidiaries in other countries. In such situations, a Web-based front end to these proprietary bank interfaces is used to bridge disconnects with ERP systems and integrate with multiple banks, applying reformatting and validation business rules.
Better still, banks beginning to sense the inevitable change on the horizon are realizing there is less to lose and more to gain by encouraging large corporate customers to use SWIFTNet as a secure vehicle for connecting with their banks. This important recognition that secure bank connectivity can be standardised to the benefit of all parties, will allow banks to move beyond the “old way of doing business” and concentrate on quality service and value-added products, such as working capital solutions and enriched remittance advice which are key to future growth.
It is not uncommon for software vendors based in Europe to fail at replicating the same success in the US. This is particularly true of companies that have deployed electronic banking software across thousands of corporate clients in countries such as France or Germany that leverage a single format, single channel.
What is often quickly discovered is something that vendors in America already know – sending payments to multiple US banks is far from simple. A standard such as ETEBAC 5 is clearly a foreign thought – far from the realm of existence for US banks. Although a standard format for ACH transactions had been developed in the punch card era (NACHA), it was at best a static standard. The actual transmission of these files reads like a history lesson of delivery methods – with formatting rules that are equally outdated. If a corporate client, for example, wanted to send a RTGS transaction, commonly known in the US as a wire, absolutely no standards existed for either formats or communication methods.
Today, US banking systems remain a quagmire for connectivity. Large corporations with multiple domestic bank relationships generally rely on numerous bank products to initiate payments; ranging from “wholesale channels”, historically referred to as “host-to-host” connections, Windows workstations, EDI services and browser-based applications. What would be considered a basic commodity in Europe – a clean, high-quality wholesale channel for making payments – could actually provide a US counterpart with significant market differentiation.
It is no wonder that unlike in the European Community, the introduction of SWIFT MA-CUGs into the US has been met with limited support from American banks. In the eyes of US banks, SWIFT could be perceived as a threat to profitable and successful products that help create substantial client “stickiness.” As a result, when corporate clients demonstrate interest in joining SWIFT, they often have difficulty trying to identify key individuals at their bank and the simplest details to assist them toward that end. To date, success on this front appears to be limited to only those clients large enough to issue meaningful ultimatums.
To make matters worse, most US banks offer little or no support for ACH transactions from SWIFT, since it was not within the normal payment methods required by their overseas correspondents (a majority of European and Asian banks have had the ability to make local ACH payments from a standard multi-credit SWIFT MT101 for quite some time). Domestic US balance and transaction reporting using SWIFT is also usually not an option since the DDA (current account) information extracts for correspondent banks that result in MT940/MT950 messages have nowhere near the richness normally produced for domestic corporate clients, which are usually delivered via BAI or printed reports.
Despite what many perceive as a level playing field in the international banking industry, US banks are truly concerned with exposing their SWIFT STP capabilities – or lack thereof – to their competitors. This has created a mindset by which ACH initiation and statement reporting transmitted via SWIFT is simply not an option for corporate clients today. The ongoing discussion surrounding the adoption of SWIFT XML or ISO20022, has been received with confusion by the market and is not likely to have a significant effect in the next three to six years, thus making it easier for US banks to maintain the status quo.
Over the course of the next 18 months, however, we may very well witness a shift in attitudes regarding standards-based initiatives. In the US, for example, there is evidence of mounting pressure among corporate clients who are pushing for creation of products using FileAct, the new SWIFTNet file transfer-based service capable of utilizing any format for payments and reporting. While similarities among US and UK banks are yielding mutual benefits, adoption of SWIFT will continue to be the dividing rod for the foreseeable future.