As banks come closer to completing migration of their FIN messaging requirements to the IP-based SWIFTNet platform, the potential for banks to use this new network to also offer new services to corporate customers is becoming clearer. In 2001, SWIFT voted to extend the right to access its global network to corporate participants, but only under a scheme known as Member Administrated Closed User Groups (MA-CUG). Although the concept has been around for a while, it is only now that practical consideration is widely being given to how it might work in practice and how banks and their corporate clients could benefit.
MA-CUGs were proposed as a way of bringing corporate users into the SWIFT environment without impacting the critical interbank function of the SWIFT network. They leverage SWIFTNet as a distribution platform for their own business applications or services.
MA-CUG's are controlled by the SWIFT member bank, with the available services and contractual agreements being between the member and its corporate users. SWIFT is not involved, other than by providing SWIFTNet connectivity through its WebStation or SWIFT Alliance Gateway products. Perhaps most importantly, the SWIFT member bank can 'sell' services offered in a CUG to anyone - no SWIFT eligibility applies.
As of February this year, 21 banks had registered a MA-CUG and the majority of these had gone live with at least one corporate customer. As banks get their own SWIFTNet connectivity requirements in order, more and more are beginning to work with corporate clients on pilot programmes for services that use MA-CUGs. These services include initiation and confirmation of payments, foreign exchange and securities transactions as well as cash balance and portfolio reporting.
A recent report from TowerGroup endorsed the model as "a great step forward" for communications between banks and corporate customers. "By using this communications channel over SWIFTNet, companies have access to a reliable, secure private network with standardised security for all communications with all their banks (or at least those that choose to offer MA-CUGS)," it says.
"The security system would also be standardised, avoiding the need to maintain multiple systems that are proprietary to individual banks. There would be no more need to send confidential financial messages over the public Internet."
"SWIFT's MA-CUG facility has a double advantage for global institutions," Anna Hannon, Vice President, CitiGroup, told the SWIFT website. "Where market infrastructures communicate with their participants through a SWIFT MA-CUG there is the potential to rationalise the multiple and different proprietary connections that a global institution must maintain to reach those infrastructures.
"The mirror image of that on the client side is the opportunity to make similar rationalisations and reach non-SWIFT eligible clients with all the benefits of SWIFT connectivity, standards and straight-through processing."
MA-CUGs support any type of file formats - not just those endorsed by SWIFT. So EDI, Edifact and even proprietary bank formats can be used. But these closed user groups within SWIFT's secure IP network will have the most benefit when further standardisation is achieved within the types of cash management and payments messages likely to be used over the network.
Besides SWIFT's Customer to Bank Initiation Standard, which is still being formulated, there are a number of similar and related standards efforts. These include IFX (mainly US based), RosettaNet (IT industry, supply chain focused with the remittance details related to the payment as the final link) and the Treasury Workstation Integration Standards Team (TWIST).
Even within SWIFT, work needs to be done to rationalise ePaymentsPlus, its secure, B2B internet-based payment initiation system, with the Customer to Bank Initiation standard.
Despite the potential of MA-CUGs, TowerGroup concludes that banks will move slowly until corporate understanding and acceptance of the concept grows. "In the current pilot phase, the value proposition for the corporations remains untested. Messaging fees will confront companies with the need to put a definite price on their concerns about the security and reliability of the public Internet."
