The Magic or Illusion of Bank-agnostic Integration

Donald Trump once famously proclaimed that “cash is king”, but did he really mean to say, “cash flow is king”? Failing to understand and manage cash flow is a common reason for a business to run into cash flow challenges. But a business doesn’t have to be failing to encounter problems. Even profitable firms can fall into a cash flow trap, and fast-growing companies are particularly vulnerable because their cash demands are that much higher.

As we emerge from the global credit crisis, managing cash flow more effectively is a top priority for treasurers. Further technology integration is one possible way to maximise investment in their enterprise resource planning (ERP) and treasury management system (TMS) platforms, providing the automation and tools to ultimately free up and identify every available dollar of spare cash.

But from a technology perspective, does a corporate face a quandary when progressing to implement a single bank-agnostic delivery channel, which is simplified and standardised to reach all their global banking providers? Surely not since, with SWIFT corporate access and ISO 20022 XML file formats, all the ingredients are now available for the mixing bowl – but do some corporate clients end up with a half baked cake?

Unfortunately, the answer is ‘yes’ if they misunderstand the recipe or the ingredients presented for their desired solution, which means they may not be completely happy with the final taste of the cake they were expecting. There are many people and organisations associated with SWIFT, ISO and standards bodies that we should acknowledge and thank. Over the years, they have given great support and commitment to enable us in 2010 to realise and increase simplification and standardisation for payments and information reporting solutions (SWIFT now transport across their network on average 15.2 million messages per day, with an estimated value of US$7 trillion – imagine how this would work without standards).

Standards and Solutions

These standards have formed the foundations for the integrated solutions banks refer to, but what do they comprise?

  • Integration – Providers of ERP, TMS and middleware applications.
  • Connectivity – Banks, SWIFT and service bureaus providing the delivery channels for carrying messages and data files.
  • Messaging and file – ISO and standard organisations that provide the message and file standards.
  • Financial services – Banks providing tools, products and services for the management of cash and liquidity.

Together they provide a standard delivery channel and standard format. Although local markets may not be as standard as we would wish, with the introduction of the single euro payments area (SEPA) in Europe, they are moving in the right direction.

However, there might be some cases within the industry that involve pushing corporate clients to interpret and manipulate standards, which then forces the corporates and banks to complete additional ‘customised’ development work for a particular integration solution to become feasible. For banks that have already invested heavily in providing SWIFT corporate access and ISO 20022 XML standards, this can be become very frustrating.

One area where this is prevalent is SWIFT corporate connectivity through a service bureau. There is a growing trend for corporates to request a single SWIFT BIC for delivery of all their payment messages (eg. MT101) from each of their provider banks, which are actually destined to multiple branches of that bank and would have their own unique SWIFT BIC. The main driver behind this is the difference in SWIFT message charges for domestic versus international delivery through the SWIFT network. A corporate originating SWIFT traffic from a Belgium registered BIC might request the ability to deliver all their traffic to their global banking partner in the same country (i.e. Belgium) in order to take advantage of the reduced domestic SWIFT pricing structure, thus avoiding additional cross-border tariffs.

Some service bureaus will also charge an additional set-up and ongoing maintenance fee for each destination SWIFT BIC supported on their system, so you can understand from a pricing perspective why clients request their banks nominate a single delivery SWIFT BIC address.

There are some 8,500 banks now registered in the SWIFT SCORE and member-administered closed user group (MA-CUG), which can give the impression that a corporate can connect directly with any global banking provider. In fact the 8,500 registered are banks and their associated branch network who have registered themselves to enable their clients to have direct connectivity via SWIFT corporate access; if a bank or branch is not registered then a corporate will not get direct access to that particular bank. Therefore, during the planning stage for implementing SWIFT corporate access, clients should validate with each of their account-holding banks that they support SCORE or MA-CUG connectivity.

So, if a bank does not offer their clients SWIFT corporate access, how does a client interact with them? Either through their existing proprietary electronic banking (eBanking) or file delivery channels, or via another bank’s SWIFT multibank service (MT101 and MT940). Historically, banks offering a SWIFT multibank service have built the capabilities through their back-end eBanking and electronic commerce (eCommerce) systems, so a client can leverage a single technology solution for all their banking needs. The payment message created (MT101) or payment file received is remapped into a MT101 multibank message and delivered to the third party bank via the normal banking SWIFT FIN network. As banks have access to interact with all banks on the SWIFT network, providing prior multibank agreements have been exchanged and agreed between the sending and receiving bank, and the relationship management application (RMA) set-ups have also been completed in each party’s SWIFT interface system.

But this can cause a challenge to clients who have previously used such proprietary SWIFT multibank services, and who now want to close down all their existing proprietary bank connections and migrate to a single SWIFT corporate access delivery channel. So a client now has SWIFT corporate access and no proprietary connections, they can communicate directly with their SCORE or MA-CUG registered banks, but what about the non-SCORE/MA-CUG banks that historically have been reached through another banks’ proprietary SWIFT multibank services?

“Hello provider bank, can we please send you our multibank MT101 messages via MT101 SWIFT FIN, for you to then relay straight back out via SWIFT FIN to our third party banks.”

Some banks can provide the capability of a SWIFT hub for a relay service, for other banks it is a major client customisation exercise and, for others still, a non-starter. Should SWIFT SCORE be used as it was originally designed, for direct contact for each bank with which a corporate client interacts? Corporates should question whether they only conduct business with SWIFT SCORE or MA-CUG registered banks, or whether they should be requesting their non-SCORE banks to become SCORE or MA-CUG compliant.

For clients selecting a SWIFT connectivity package, SWIFT Alliance Lite is an ideal solution to be considered if you are a low-volume user looking for a cost-effective option. Also, many corporates take this product as a tactical move to get experience of SWIFT, prior to investment in a longer-term strategic solution (such as a service bureau).

Corporates signing a contact with SWIFT for Alliance Lite can do so in the knowledge and reassurance that they are dealing with a very reputable organisation. But what if the corporate is looking for a service bureau, who do they choose? Typically they will select three or four providers and then issue a request for proposal (RFP), with risk assessment and pricing of the provider being key factors. This situation has led to banks becoming providers for SWIFT bureau services, typically a ‘white label product’ from a third party provider, but the risk and liability underwritten by the providing bank.

Another trend sees corporates requesting the delivery of MT940 bank statement information in a file via SWIFT FileAct (rather than via SWIFT FIN). True standardisation would be for the corporate to request ISO 20022 XML bank reporting via FileAct from their banking provider, as MT940 was originally developed as a message standard for delivery via SWIFT FIN. What corporates, or their ERP TMS providers driving this request may not appreciate, is that there is no published ‘standard’ defined for wrapping MT940s into a file. This will lead to banks developing their own interpretations for creating MT940s for delivery within a file. Each bank will have a slightly different flavour file output format to the next, creating more customisation development to be completed by the client to enable final upload into their ERP TMS process for reconciliation purposes. Banks will have similar challenges as they develop the capability to receive incoming MT101 and MT103 payment messages within a bulk file delivery via FileAct.


For corporates to succeed, they will gravitate towards banks that offer flexibility around their integration solutions, but also, more importantly, a bank’s ability to provide a high standard of data content to be carried across these integrated channels. Any ERP and TMS process will only be as magical as the data which fuels their process, and it is a critical component for them to maximise automation, reducing a treasurer’s processing time and freeing up decision-making time around management of their working capital.


Related reading