SWIFTNet: The Bank-to-Corporate Dialogue
Since it was launched four years ago, the member-administered closed-user group (MA-CUG) has made its name well known throughout the corporate treasury community. However, the number of users has not reached the figure expected both by SWIFT and early adopters.
Was it born premature? Does the concept really fit corporate treasurers’ needs? Have banks made the real effort to support and sell it? Is SWIFT fully committed to this totally new market? How have vendors answered this new challenge? These questions are key.
About 10 years after SWIFT was set up for banks, the first corporate joined the community using its internal bank. Fifteen years later, just before the MA-CUG was created, 30 or so corporates were using SWIFT for their individual payments, FX confirmations or reporting needs. One of them, a pioneer, used IFT (the file transfer protocol over X25, ancestor of SWIFTNet FileAct). But there were too many restrictions, and the model could not be widely adopted.
With the creation of MA-CUGs, in 2001, SWIFT intended to fill the gap between corporate needs and SWIFT offering potential. At the same time, SWIFTNet, the new IP network, added new opportunities to the well-known FIN messaging service in terms of file exchange. Corporations found, with the combination of FIN and FileAct, a complete set of products to exchange all the information they needed to with their banks.
FIN gives the reach in terms of banks and products for individual orders, especially because all banks are using it, with the same set of standards, the famous MT (e.g. MT101, MT940). FileAct gives the opportunity to exchange also files, in various formats including the national ones, which are in many cases supported by ERP and TMS. The trend taken by early adopters was to leverage the use of FileAct to the maximum.
Even if the global picture is clear, many shady parts remain. The member-administered closed-user group concept created by SWIFT gave a large role to banks in the initiative and introduced many administrative locks. Moreover, banks understood the SWIFTNet potential for themselves and had to imagine how they could connect their internal banking applications to this new acquiring channel. This took time, and many banks are only opening their MA-CUG now. But even if opening a MA-CUG is quite simple and free of charge, running it is another matter. All banks have proprietary channels and e-banking software, and their customers intend them to provide the same level of service and security with the new SWIFT channel. And this new channel isn’t free for the bank. More than the fees charged by SWIFT for the MA-CUG itself, the bank has to re-invent its pricing for all the information it sends, which is charged by SWIFT as traffic.
If the FIN offering is quite similar from one bank to another for a restrictive set of messages (MT101, MT940, MT300), only some banks will supply the demands of their customers who would like to exchange also MT210 to announce incoming funds, MT900, MT910 and MT942 to manage their intraday liquidity.
Regarding FileAct, the situation is less attractive even if many banks have made a great effort to support the Total project1. Because of the multiplicity of formats and instruments depending on banks and countries, each bank has to invest more time and money to reach the quality of service provided by its own e-banking solution.
But this situation will probably find a positive issue with the new XML standards developed by SWIFT itself. These standards were created with the participation of banks, corporations and vendors, and were written at the same time as the new euro payment instruments. We don’t know, at this time, if the single euro payments area (SEPA) will adopt SWIFT standards as its own standards, but we hope that the community (banks and corporations) will re-use the work well done by SWIFT for the payment initiation standard. One of the main advantages of SWIFT is to clearly be the centre of convergence of all stakeholders in the financial community. Who will have more legitimacy to publish these new standards?
Another part of the global picture comes from the vendor side. In the SWIFT area, many vendors were dedicated to bank applications, and the ones who were dedicated to connectivity were those who provided sophisticated integration solutions, such as EAI providers. Corporations are used to dealing with software vendors who give them both application and connectivity, in a complete and unique solution. In this area, some competitors are running now and have started to sell or develop this full and masked integration. Some are traditional (eg SAP, Oracle, XRT), others are new (eg Trax, Datalog), but all understand the need of a complete integration. Probably a great evolution would be in the packaging of SWIFT interfaces (SWIFT Alliance software) directly in the solutions provided by these vendors.
Among SWIFT partners, some are providing outsourcing of SWIFT connectivity, known as service bureau. As of today the offerings are more or less still designed for banks, with a special focus on FIN messaging. But we see, as far as the demand for corporations is growing, some who also propose FileAct. Their role will be very important in the next few years, to extend the concept to smaller corporations who don’t want to hold connectivity in their premises, because of the total cost of ownership of the in-house solution which is, more or less two times superior than an outsourced solution. Moreover, outsourcing for treasury application is a real trend in the market.
Obviously, the use of SWIFT network, messaging services and standards makes sense for a corporate – for its risk and cash management, but also for A/P and A/R management. It allows a customer to use the same channel (in its extended sense, composed with network, security and formats), regardless of the bank, its location and the banking product. With software that really integrates the SWIFT connectivity, STP becomes possible and cost of global processing is clearly reduced. There is a new generation of vendors who intend (and have started) to provide this global offering. At the same time, the number of services bureaus that provide a service to corporations including both FIN and SWIFTNet FileAct is growing fast.
Nevertheless, the banking community has not totally switched to this requirement from its customers who want to consider separately the channel and the banking product, and will choose its banking partners no longer on their channels but on their products. If the larger part of main and medium banks has created a MA-CUG, some are still resisting and the offering is not as homogeneous as needed for a bank-independent solution. But time is helping treasurers, and banks are increasingly receptive to this concept.
1 Total, the French petroleum company started a global e-banking project that intends to replace all e-banking solutions in the whole group. This project includes the use of FileAct with a real large number of banks, for domestic payments and direct debits and bank statements.