How Bank Connectivity Can Throw a Wrench in Your ERP Migration

Frequently in information technology, new terms are developed without taking into consideration the importance of the words that make up the term.

This applies directly to the term “multi-bank connectivity” – with the focus being on “multi.”

Being able to effectively manage multiple – or more accurately many – banks is critical. What is important to consider is the four following elements of banks:

• A bank is an outside organisation and not an internal entity with typical IT Integration
• A bank is a very process-oriented organisation because of its compliance and security requirements
• International banks operate in different time zones that could have up to a 12-hour time difference with where you are located

Your contacts in some banks might have challenges with English or your native language and the technical work will be a challenge

How Many Banks are Often Involved in Multi-bank Connectivity?

When we say “multi-bank,” we don’t just mean connectivity to two or three banks. In some cases companies have to manage 10 or 20, if not 50 to 100 banks.

The Implications of Multi-bank Connectivity on IT Departments

When a home-grown, IT-led bank connectivity project is kicked off, the difficulty of adding successive banks to ERP software is typically one of the most underestimated areas of the project. The complexity and the very large scope of different tasks to be done make bank connectivity a very misunderstood and often underestimated domain.

The Work Involved in Integrating to Banks

Traditionally customers looking to deploy a global payments factory would require internal IT resources to build and test payment formats and flows to their banks.

The number of variables that go into a payment format means there are hundreds of format customisations that need to be modified and tested in each environment, then the testing begins with the bank which rarely works the first time.

These format customisations include:

• the bank
• the initiating branch
• the receiving branch
• the payment type
• if there is an FX conversion
• urgent or non-urgent payment
• the currency
• other regional or bank-specific fields

The magnitude of formats and scenarios that need to be built and tested can be enormous and overwhelming. This is particularly true because most application integration that IT departments perform is connecting one application to another application. When companies are entering a significant project, IT resources are already stretched incredibly thin with little time to build and test all required payment formats.

Payment Scenarios and Payment Scenario Variances

The variances between the banks in terms of protocols, file formats and security among other factors often become a one-off integration for a specific payment scenario for each bank.

A payment scenario could be Bank A – Initiating Branch Frankfurt – Receiving Branch Madrid- SEPA Payment-Non-urgent- No FX- Euro.

The payment scenarios need to be tested with the bank as errors will lead to payment failures. This is because for a payment to go through, everything must exactly meet the mandated requirements for each bank. However, then the IT department must keep track of the variances between banks.

In order to go live with a bank for connectivity, one will generally require between three, five or ten formats. However, there are roughly five hundred variants for international bank connectivity projects.

The sequence of steps to enable the bank connectivity is often the following:

1. Specification Development: With an ERP it is necessary to develop all of the data specifications after receiving the information from the bank.
2. Extraction and Transformation: The next step is to create the extraction and transformation code that will extract the right data from the ERP database. Alternatively, if a multi-bank connectivity application is used as their integration workbench to set up the payment files, they typically must be moved individually between the ERP software and each bank. In either case, the IT department is in for a large amount of work, and in our analysis, multi-bank connectivity increases the workload over using standard development languages to create the connectivity.
3. Testing: Then the interface is tested with a penny value with the participating bank. The first time the connection is run, it will, in nearly all cases, not work.
4. Working Out the Bugs or Errors in the Interface: The participating bank will explain why the integration failed. However, the customer’s IT team will often not understand the explanation provided by the bank as banks use their own terminology and domain expertise that is unfamiliar to IT departments. Each scenario will often change the information that is required to be sent. As an example, one scenario which sends payment information from Germany to Poland changes when the payment is sent from Germany to Dubai. This changes again when the payment types change. Whether or not the payment is urgent changes the data that is required yet again. Each scenario changes the data that must be sent, and a single missing field or incorrect format means failure for that test.

As a result of this complexity, it is very typical to take six to 12 months to add a new bank and a scope of 5 or 10 if not 80 banks could compromise the success of your ERP migration.

To learn how you can optimise payments during an ERP cloud migration, download our latest eBook.