Do MA-CUGs Meet the Needs of Corporates with Multiple Bank Relationships?
Corporate access to SWIFT has long been a topic of some debate among the international banking community; the larger banks in particular repeatedly raising concerns about the possibility of disintermediation if corporates were to be allowed to communicate freely over the SWIFT network.
Until relatively recently only a select number of multinational corporates were able to access SWIFT, and even then only to confirm foreign exchange transactions with their bank counterparties. The decision therefore in June 2001 to grant corporates wider access to a potentially much broader range of messaging services over the SWIFT network represented a very significant step forward towards fuller corporate participation in SWIFT. Going forward corporates would be able to join SWIFT as service participants in what is now known as a ‘Member Administered Closed User Group’ or MA-CUG.
However, SWIFT being a cooperative owned by and run for the benefit of its member banks, it was not altogether surprising that MA-CUGs were designed from the perspective of a bank offering services to its corporate customers rather than from the perspective of a corporate wanting to use SWIFT to interact with the many banks it has relationships with. To make this distinction may perhaps be splitting hairs, but the current MA-CUG model is arguably a contributing factor towards its somewhat slower than anticipated take-up in the market.
A MA-CUG is a mechanism by which a bank can use the SWIFT network to communicate with a closed user group made up of its corporate customers.
In what is sometimes referred to as a ‘hub and spoke’ model, corporate members of a MA-CUG are connected via the SWIFT network to the administering bank, which is in turn connected to all the other SWIFT member banks over the same network. The rules dictate that corporate members of a given MA-CUG can then communicate with the administering bank, but cannot communicate directly with any other SWIFT member bank over SWIFT, nor can they communicate directly with each other in this way.
Of course the corporates for whom SWIFT connectivity is of most interest, typically have multiple banking relationships. This may be for geographic, legal, contractual, business or tax reasons, or in order to broaden the financing of their business. These corporates are therefore looking not only to communicate over the SWIFT network with one bank but potentially with all of their banking service providers.
SWIFT MA-CUGs are currently able to support multi-banking in two ways. Firstly, the bank administrating the MA-CUG can offer to act as a relay for messages between its corporate customers and other banks, i.e. forwarding messages from the corporate to a second bank and returning responses from the second bank back to the corporate. Clearly, this model is not suited for types of business where the corporate wishes to deal in private with the second bank. The alternative is that the corporate becomes a member of many MA-CUGs, one for each of its banks. Given that MA-CUGs are set up and administered by the bank and not the corporate, in practice this can mean having to persuade each of the banks in turn to offer this service. Where a corporate has a large number of banking relationships or those banks have not yet fully embraced the idea of corporate access to SWIFT, this process can prove cumbersome.
In order to join a MA-CUG, corporates need some means of interfacing to the SWIFT network. Depending on the service being offered by the administering bank, this can either be a traditional FIN interface system (i.e. where the service is based purely around the FIN message set) or one of the newer SWIFTNet enabled applications, which support browser-based, interactive and/or file based means of communication over the network.
In the situation where a corporate is a member of several different MA-CUGs, the same interface can be used for each. Therefore, with a single interface to the SWIFTNet network, the corporate is effectively able to streamline its communications with its various banking services providers.
There is of course a cost for the corporate to implement, operate and maintain this infrastructure (including hardware, software and networking) over and above the usual messaging fees. However, lower cost solutions for SWIFTNet connectivity are now emerging in the market. One such solution is to use a SWIFT Service Bureau. Where the expected volume of SWIFT traffic does not warrant an upfront investment in a dedicated interface along with the overheads of running and maintaining such a resilient infrastructure, an alternative may be for the corporate to use an established SWIFT Service Bureau and take up SWIFTNet connectivity on an ASP (Application Service Provider) basis. In this way the corporate is able to benefit from a fully resilient, high-end solution, operated and maintained by a third-party and only pays for his usage of that system.
SWIFT MA-CUGs offer a number of benefits both to corporate members as well as to the banks that administer them.
For corporates, the opportunity to replace multiple front-end systems and networks with a single SWIFT interface and network delivers the benefits of streamlined connectivity and standardised communication across the spectrum of banking relationships. The associated standardisation of data formats, record layouts, report formats as well as the availability of standard interfaces also greatly eases the integration with back-end ERP (Enterprise Resource Planning) systems, leading to improvements in STP (Straight-Through Processing) and cost reduction at the corporate end.
For banks, there are also benefits to be gained from offering a MA-CUG. In many cases, communications with their corporate customers can be achieved over their existing SWIFTNet infrastructure, removing the need to maintain dedicated networks and interface systems for this. The standardisation of communication and data formats can also bring STP gains and cost reduction for the banks.
Disappointingly, the take up of MA-CUGs in the market has been relatively slow to date. At the time of writing it is estimated that some 35 banks worldwide are operating MA-CUGs, with approximately half that number of corporates taking up the service. The vast majority of MA-CUGs appear to follow the model of one bank and one corporate customer each and clearly, given this ratio of corporates to banks, it follows that some corporates are members of more than one closed user group.
The reason for this relatively slow take-up can be attributed to a number of factors. Firstly, it is the banks that are responsible for marketing, setting up, and administering MA-CUGs, but in the main they have been fully occupied with ensuring a smooth and successful migration to SWIFT’s new IP network – SWIFTNet – before the September 2004 deadline.
Another factor is that bank departments responsible for providing services to their corporate customers have, in many cases, only recently invested in proprietary internet-based delivery channels for their corporate services. Understandably, they are keen to see some return on this investment and still draw comfort from the fact that the corporates using these services are to some extent tied in to a technological investment in terms of their systems, network and data formats. Consequently, these departments are not always in a hurry to promote a move to a more standard and open SWIFT-based communication channel, which may be viewed as levelling the playing field and potentially making it easier for corporates to switch service providers to the competition.
But the fact that multi-banked corporates today frequently have to persuade each of their banks in turn to first set up a MA-CUG in order to reap the full benefits of standardised communication across these various relationships is undoubtedly another factor influencing the take-up rate of MA-CUGs in the market.
SWIFT MA-CUGs represent a giant step forward in terms of facilitating corporate participation in SWIFT, and provide the potential to deliver significant STP gains for corporates and banks alike.
The current model is bank-centric by nature, effectively enabling multiple corporate members of a MA-CUG to communicate over the SWIFT network with the administering bank. While MA-CUGs do support multi-banking in two ways, neither solution is ideal from the corporate point of view. The relay approach has privacy issues, which may not suit all types of corporate business and the other, which involves a corporate joining a separate MA-CUG for each bank, can prove cumbersome and time consuming to realise.
What corporates ideally need is a flexible way to communicate with all of their bank relationships across the SWIFT network. Until such time as MA-CUGs are more widely available from the major banks around the world, perhaps what is needed is a more flexible ‘many to many’ form of MA-CUG where rather than each bank being responsible for individually setting up and administering its own MA-CUG, banks and other financial institutions can share jointly in the setting up of a common MA-CUG (or otherwise join an existing MA-CUG) to provide a more flexible means of communication between a closed user group of corporates and their various banking service providers.