Cash & Liquidity ManagementPaymentsSWIFTSWIFT MA-CUGs – Single Interface Opportunity

SWIFT MA-CUGs - Single Interface Opportunity

Q. Why do you feel that the ‘big picture’ opportunities for MA-CUGs are not more widely appreciated?

A. I think many client participants in MA-CUGs (Member Administered Closed User Groups) have probably seen payment processing as the lowest hanging fruit and so their initial focus has been on that. There’s certainly no denying the opportunities – we have clients who already had highly efficient payment processing who have seen their multi-country STP rates increase from 75-80 per cent to near 100 per cent. Furthermore that wasn’t a gradual improvement – we understand they achieved it virtually instantaneously after joining our MA-CUG and starting to communicate with us via SWIFTNet.

However, impressive though that obviously is, it is overshadowed by the opportunity of rationalizing your communication channels with your bank(s) to just one scalable interface. The efficiencies possible at the MA-CUG micro level are obviously very valuable, but this single interface represents a macro opportunity of an entirely different magnitude.

Q. How would this single interface concept work in practice?

A. SWIFTNet offers the following messaging services:

  • FIN – the store-and-forward messaging service for SWIFT message types, which includes messages such as MT101s, MT940s, etc. In MA-CUGs, FIN is typically used for payments and liquidity management.
  • FileAct – a file transfer service usually used for salary runs, pension payments, commercial payments, etc. A FileAct message can contain up to 250MB of data and the contents of the file do not have to comply with any particular standard.
  • InterAct – a messaging service for transporting SWIFT XML standards and SWIFTSolutions. Within MA-CUGs, it can be used for real-time reporting of transactions.
  • Browse – browsing and manual input of messages via HTML GUIs. Typically used for reporting.
  • Exceptions and investigations.

All of these are available to participants connected to a MA-CUG, which therefore provides comprehensive messaging coverage. However, the crucial point is that they can all operate via a single interface between bank(s) and client. A further advantage is the way in which these messaging services can be combined. For example, InterAct provides single messages, but if desired, the client can have these individual messages bundled together and delivered in a single bulk file via FileAct.

While all these services are valuable, FileAct is one of the most versatile, as there is no content type limitation on what it can carry. It therefore effectively provides a common channel without requiring a common standard. Apart from the possibilities listed above, it can also be used for any other types of data transmission, including electronic documents, e-mail and images. For example, we have had clients wanting to use FileAct with their enhanced security features as a means of sending us account opening and closing documentation. In certain business areas, such as property title, numerous accounts can be opened and closed in a matter of days. When you consider the paper chase that the account opening and closing process usually represents, that could be a significant efficiency gain for both client and bank.

Q. So presumably this single interface has implications in terms of investigations and transaction tracking?

A. Absolutely. Take for example a client making cross-currency wire payments. The client would be able to track the status of their wires in real time across all the relevant bank systems as a single snapshot through just one interface. This would include the FX component, so the FX rate could be instantaneously transparent. Ultimately this may make it possible to resolve any queries from a recipient regarding deductions from a wire in real time, as it should be immediately apparent whether any charges had been levied before or after the wire left the bank’s systems.

Q. But this assumes that all the relevant bank systems are appropriately connected to the SWIFT interface?

A. Yes. In a sense you could say that while this is a huge opportunity, it also throws down a similarly huge challenge to banks. They have to link up their various systems to the SWIFT interface so clients can enjoy transparency across all the elements of their relationship. That is obviously no small task, especially when you consider the diversity involved. For example, clients may want a consolidated picture of their net position with their bank(s) in real time – that could involve systems covering card processing, core banking, investment portfolio valuations, positive pay files, check images, lockbox, mark to market on derivatives positions, etc.

A further challenge for banks in the short term is that their costs will rise, as they will have to build and support this new channel for their early client adopters while still maintaining existing interfaces. However, this will improve in the longer term as more clients adopt MA-CUGs as their interface of choice and proprietary bank interfaces can be retired.

There is also a revenue consideration here for banks. This single interface will allow treasury clients to be far more efficient in managing assets held with their banks. For example, funds that might once have been left idle for lack of transparency (to the benefit of the bank) would now be visible and put to better use. While helping treasury clients to be more efficient should obviously be part of a bank’s role, some banks may see this potential revenue loss as a deterrent to their rapid adoption of the MA-CUG single interface model.

Q. You have both placed a lot of emphasis on the importance of the single interface available through a MA-CUG. In comparison with their existing arrangements, clients could presumably benefit from significant cost savings from this?

A. Very much so. Having a single interface that can be used for all banking relationships and provides global reach is much more cost effective than having to support multiple proprietary interfaces. Estimates obviously vary, but it is generally accepted that when all costs are included, each proprietary interface between a bank and a corporation costs between €50,000 – €100,000 per annum to maintain and operate. Banks have generally tended to operate on a product silo basis, so each of these silos will have its own interface whereby it interacts with clients. It is not uncommon for a client to have to connect to five or six of these silo interfaces, and in some cases there may also be separate regional variants per silo. Those organizations that have multiple banking relationships then have to multiply that again by the number of banks.

By contrast, the MA-CUG consolidates all this into just one global, pan-product, cost-effective interface with enhanced security features, whereby ingoing and outgoing instructions and data can be transparently consolidated or sliced however the client desires. Furthermore, it is possible in a multibank CUG for subsidiary banks to route data via the lead bank, so that a single interface onto all banking relationships becomes available.

Comments are closed.

Subscribe to get your daily business insights

Whitepapers & Resources

2021 Transaction Banking Services Survey
Banking

2021 Transaction Banking Services Survey

2y
CGI Transaction Banking Survey 2020

CGI Transaction Banking Survey 2020

4y
TIS Sanction Screening Survey Report
Payments

TIS Sanction Screening Survey Report

5y
Enhancing your strategic position: Digitalization in Treasury
Payments

Enhancing your strategic position: Digitalization in Treasury

5y
Netting: An Immersive Guide to Global Reconciliation

Netting: An Immersive Guide to Global Reconciliation

5y