Migration to a sustainable banking solution or why banks are not software companies

More and more companies are deciding to fully digitise their banking processes as part of working towards Banking 4.0. This raises the question of whether the banking solutions currently used are ready to face the challenges of the future. In many cases the answer is shockingly simple: NO!
So they have to move over to a new banking solution.

more information on ennoxx.banking

Why banks act like software companies but are not software companies!

Let’s ask ourselves the question of why banks in the past provided (and in some cases still provide) their corporate customers with cheap or free banking solutions so that they could process their payment transactions electronically?

To optimise processes, of course:

But of the bank itself rather than the processes of the company!

With the belief that: Giving the customer software to transmit their payment files means they will deliver the data electronically and free the bank up from doing it. This means the bank benefits from the automatic processability of this data.

Thanks to this very early digitisation of their own processes, banks could be described as the FinTechs of the 1990s and 2000s.

As many banking solutions were created from precisely this approach and from the banks’ perspective, the idea of these solutions optimising company processes has fallen by the wayside to this day.

Where in the past an isolated solution was sufficient for data transfers between companies and banks, nowadays a lot more is required from a banking solution: Namely integration into the processes and infrastructure on the company side. Something that the bank can only partially do, or not at all – and furthermore, should not be able to do. Banks should focus on their core competencies and this is the handling of payment transactions and particularly the processing of transactions.

Why change the banking solution already in use?

Companies should ask the following questions:

• Can I automate processes using the banking system we currently use?
• How well can it be integrated into our existing infrastructure?
• Does it meet the company’s requirements for business intelligence, central reporting and archiving?
• How can future topics such as instant payments, new formats, etc. be implemented?
• Does the solution allow for flexible and mobile usage?

In addition, the following are reasons to change your existing banking solution:

• Internationalisation
• Changes to regulatory and in-house requirements
• Change of strategy of the bank (whose solution is used) or the manufacturer of the banking solution (e.g. outdating)
• Separation between the banking services and banking system

What are the arguments against migrating?

People quickly get used to processes and work around them, even if they are not optimal. This means that many users of outdated banking solutions think it seems perfectly normal to have to send a file to the bank manually. The reason why is very clear: so far there have been no alternatives and, even if there were, who knows whether they would work properly?!

What should you pay attention to when migrating?

Changing the banking solution you use always involves interfering with the core processes of your payment transaction system. However, if you pay attention to a few points, this can be done easily and also offers many opportunities. Firstly, all current processes and current cost structures need to be compiled. This will allow for the creation of a target scenario and enables you to derive the requirements of the future banking solution. After the right banking solution has been chosen, you can move on to implementation. In addition to the technical planning of the migration, you also have to pay attention to the organisational and contractual situation as part of the migration plan. The technical migration of the data should be used to clean up data files based on the premise of:

moving over as much as necessary and as little as possible

In addition to the purely technical migration, you must also not forget about the organisational and contractual aspect of the migration. All of these points have to go hand in hand. If, for example, a separate EBICS ID is to be used with the new banking system, the necessary contract has to be drawn up and taken into consideration with enough forethought. Migration plans can vary from company to company. In many cases, a phased changeover is advantageous. Sometimes it makes sense to changeover bank by bank; in other cases it may make sense to move things over by account or user. Doing things in an ordered way in line with the migration plan and ensuring the solvency of the company at all times is important for every migration process.

Changeover to on-premises or cloud?

The question of whether the solution used should be operated within the company (on-premises) or in the cloud is, of course, dependent on the company. Many companies do not yet have policies in place that would allow such a solution to be operated in the cloud or do not yet fully trust in these kinds of solutions.

As we can expect that banking solutions will increasingly be operated as cloud solutions in the future, a transition over to this later on should already been taken into account when choosing your banking solution. So you will not have to migrate your banking solution again in just a few years...