How to go about changing a banking core system?

Mariann Harrison

How to go about changing a banking core system?

Author: Máté Hidvégi, Head of Development at ApPello

Ever more banks are looking at the issue of replacing their legacy system. This can be driven by the pandemic, transformations in the ownership structure, or for strategic considerations. So how should one go about this? What are the main risks and pitfalls? Although the experiences accumulated at ApPello would be sufficient to fill an encyclopaedia, our colleague Máté Hidvégi has attempted to stay within the strict boundaries of the subject in his summary.

Ever since the appearance of the Covid-19 pandemic, digitalization has been coming out of our ears. It is not as though an online platform, or mobile app, was not a fundamental requirement in the case of banks earlier on, but the masses of people forced to stay at home were only prepared to arrange virtually their financial affairs that anyway they would not have been forbidden to go to their local bank for. Over time, this placed an unsupportable strain on the back-office systems of banks. Why? Going into a branch office when applying for a loan, we don’t get worked up when it takes several minutes to open and review our current account profile because in the meantime, the employee sitting in the office is happy to chat and reconcile our data. If a fault arises, then he/she just starts the whole thing over again. In the meantime, he/she opens another window where he/she arranges a request for a bank card and we don’t even notice a thing. If there’s a hitch, a superior is called over and we can feel ourselves a little bit more important because now two people are working on our case.

If, however, the same process does not happen within seconds on the mobile phone, the tendency is to get frustrated. It is evident that it is not possible to load everything onto systems tailored to the circumstances of a few years ago.

To take a pandemic example: if a chef who has just been made redundant becomes a food courier riding the same bicycle he used to cycle 1-2 kilometres to the park and back at the weekend, then this bike simply will not be able to stand the strain.

The fact is, the greatest asset banks have is not money but the trust invested in them. Protecting their reputation for reliability comes above all else. Therefore, large-scale transformations at banks such as the replacement of a core system can traditionally only take place very slowly. A service outage, data leakage, or God forbid the loss of an account balance represents such a level of threat that any bank manager will certainly think twice before going about replacing the system. The bad news is that banking systems that are 10-15 years old, possibly ‘conceived’ around the time of Y2K, do not have another 5-10-15 years, even with continuous ‘spot welded’ patches. Conceptual, functional, technological revolutions have taken place, which cosmetics can no longer disguise. And while on the subject of bad news: even if a bank switches over to a totally new system today, it won’t have 15 years’ lifetime either. Change is continuous.

If change is continuous, then it is worth coming to terms with that fact.

The simpler, thinner a core banking system is, the better it is. It should know the core functions, it should have the customer registers, current accounts, deposits and loans. Every task, payment hub, every channel output, every product should be in separate system elements that are replaceable and modular. The larger and more complex a banking core system is, the more likely it is that the client will become vulnerable to the developer, who precisely because of this, without the spur of competition, will become lazy.

If the current system of a bank is bulky and sluggish, then before making the change streamline, strip back and just replace the spine, and then from there upgrade the modules. In modern banking systems the components can be changed virtually constantly, and they are; with so-called microservice technology and a devOPS approach it is not impossible to implement updates even several times a day. In principle, many components do not even constitute a part of the system in the traditional sense, instead they are integrated on a SaaS – software as a service basis and operate from the cloud, with the subscribed parameters and capacity.

Replacing the system is actually only a small part of the whole task. The devil is in the detail: in the data migration, in the flawless movement within the new system, in compatibility, in usability, in the training of users, and in many other factors. And last but not least, in constant testing and in the systematic implementation of changes so that if anything goes wrong, there should be a way of taking one step back so as to leave as little trace of the unsuccessful implementations as possible.

Nevertheless, it is simply impossible to exist on a constant war footing. Even when the reality is that the system will never be finalized, that it will always need to be developed, tested and patched, it is still worth incorporating milestones into it. Whether they are 1-2-month, or even 6-month intervals, but there should always be an end in sight, there should always be a point for celebration, the feeling of achievement, a momentary slowing, the chance to evaluate the results that have been reached. Two years is a sort of psychological boundary that it is worth keeping to since a development cannot be stretched much beyond this. In two years, on average half of the participants will have been replaced, there will be a loss of focus, in-house influencers may drop out of key positions, and the project will fall apart. This is why it is always worth thinking within this timeframe.

We all know those specialists, whether car mechanics or bathroom renovators, who just can’t give a deadline and in the course of the project don’t want to let us see their ‘art’, saying that it only makes sense to see it as a whole at the end. These people are looking down the wrong end of the telescope because they are not artists but service providers even when they are practising what they do at an elevated level. In most instances, such cases end in disappointment. We should maintain a similar suspicion about IT developers. Partial performance builds trust, orientation, and provides an opportunity for correction. Secrecy, the promise of the ‘big reveal’, generally only serves to cover up delay.

When the technological conditions, the development team and by no means last the financial wherewithal are given, even then the development is not guaranteed to be a success. On the client side, there is a need for the type of skills that ensure the planning of such a project, the management and briefing of teams, the prioritization of tasks and their execution. If the client has no experience in this area or is not properly prepared, it is well worth involving a consultant in the task. However, since no consultant can do 100% of the thinking for us, the bank must also be able to outline its core vision. The key to this vision is whether the bank has the type of corporate culture that chases after the market, or whether it thinks ahead, anticipates and shapes the environment around it, whether it dares to innovate and dares to take risks. Decisiveness, genuine value judgment, delegation, or even accountability are all key skills, without which a system development is doomed to failure even if the best developers in the world are involved in it.

Leave a Comment