MINDSPIRE BLOG
Follow MINDSPIRE on social!
Introduction
Transforming a CBS solution is an extremely complex task, where related lead times, costs and interconnections necessitate thorough preparation.
In our post, based on our practical experience we provide an overview of the main risks involved in Core Banking System transformations, and the potential mitigation methods.
In my previous articles, I have examined the activities to be performed during the process leading up to the selection of core banking systems:
- The next generation of Core Banking Systems
- Choosing a Core Banking System
- Selection of boxed Core Banking Systems
Continuing the story I started, I would like to present some of the typical situations that occur in practice during the steps following the selection of the core banking system, the dilemmas associated with them, as well as my suggestions.
In this post, I will write about the challenges that arise in parallel with the selection of the appropriate CBS solution, or perhaps following it, but in the phase prior to developments, and about my related proposals.
András Breuer
Head of Banking Transformation
András has gained 15+ years of experience in the Financial Sector as a Core Banking Systems implementation expert and project manager.
He is currently leading the Core Banking Transformation Services at MINDSPIRE, while supporting our key implementation projects as lead expert and QA.
He also spent 4 years as a line manager at K&H Bank having been responsible for e-channels, front-end, cards, treasury and investment system analysts.
His main strengths are Core Banking platforms, business and IT architecture design and vendor side communication.
The complexity of CBS transformation projects
It is difficult to overestimate the intricacies of a CBS transformation. It is worth considering that the complexity, cost, and turnaround time of such a task can be several orders of magnitude greater than the second most significant project that the organization was able to successfully execute before.
The fundamental reason for this is that every business service, application, and function in the banking IT architecture is connected to many other components at several points. These form a complex, large-scale structure, with the Core Banking System at the center. If we change the CBS, most of the other solutions will be affected. Accordingly, the smaller changes we make in the core banking system, the easier our task will be.
Accordingly, the transformation of the core banking system must be approached with humility due to the size and complexity of the project. The risk of failure is significant, unfortunately many times similar undertakings end unsuccessfully. For example, in this article, which I consider professionally credible, they mention a 30 percent success rate, which I think is realistic: https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-forward/how-to-get-a- core-banking-transformation-right-eight-mistakes-to-avoid
For this reason, it is particularly important to involve experts with experience and practical knowledge in the CBS transformation, who have already participated in such a project, preferably several times, and to take into account and consider their proposals. Even if some of these may seem unusual at first.
In connection with the assessment of complexity, I recommend starting the following tests as soon as possible and conducting them quickly, at a high level:
- products,
- processes,
- applications,
- interfaces,
- queries and reports run directly on the system,
- customer documents originating from the system (contracts, statements, advices, slips).
To estimate the magnitude, I recommend comparing the scope of the task and its budget with the most recent major transformation at the bank. For example, in Hungary, a recent big-ticket change was the implementation of the instant payment services (5 seconds end-to-end performance with a 99,9% uptime).
How do we define the goal of core banking transformation projects?
The main goal for me during CBS transformation projects as a Core banking system consultant is to maximize the probability of the new system going live.
For ‘going live’, I use the previously mentioned article’s definition as a basis, according to which, the task is considered to be completed, when the analytical accounting of products and services has been transferred to the new system, and the old solution no longer processes such tasks. I suggest trying to achieve the go-live of the new system primarily by reducing the expected complexity of the task.
Compared to keeping complexity at a manageable level, costs and project lead times are only of secondary importance in my perspective. In most cases, the client’s experts also agree with this, if not right at the beginning of the project, but almost certainly at some point later…
Also, the reduction of complexity typically has a beneficial effect on the costs and the turnaround times of the core banking system transformation. I recommend the distinction because conversations about complexity tend to occur faster and easier than discussions about expected costs and lead times.
The importance of go-live as a success criterion
I will attempt to cite some concrete, practical examples to illustrate why going live, as a fundamental success criterion, is such an interesting topic to me.
Without a precise goal, anything can be labeled as an achievement
Roughly three years into a CBS replacement project with a budget of more than one hundred million euros, one of the successful milestones was that the accounts created by the experts participating in the mission for this purpose specifically were transferred to the new core system as a pilot.
A year later, after a lot of effort and expenditure, these test accounts with very limited functionality were transferred back to the production environment. At that time, the organization acknowledged the second migration in the opposite direction as a significant positive result as well.
The mission ended a few years later, without the activation of the new solution. By this time, none of the management members who came up with the idea and initiated the transformation project of the core system were working for the organization.
It is clear that if the project aimed at replacing the core system had a precise and well-defined goal, it would not have been possible to communicate the above as achievements. Not even if instead of replacing the original solution the goal had been to migrate some accounts back and forth, since the timeframe and expenses would not have been commensurate with the skills acquired in the process.
If we don’t focus on the goal of the project, success is improbable
In another, less adventurous example, the replacement of the core banking system reached the GAP analysis phase, after which the project slowed down, transformed, and later quietly ended.
This is remarkable because in this case the basic goal was given, well-defined, and set by an external regulatory authority, due to previously discovered regulatory deficiencies.
However, during the project that was created to replace the core banking system, it was not possible to keep the basic goal in focus, so after a while the scope changed completely, and then the project itself was closed, unfortunately without significant results.
Therefore, even the exact success criteria defined at the beginning of the task are not a guarantee that the project will be successful if we cannot follow them during the execution.
What goals should we set?
Due to the above challenges related to the objectives of the CBS transformation projects, I usually define a well-measurable success criteria: Was it possible to go live with the new core banking system following the execution of the task, or not?
Even if it is possible to go live with certain system components, unfortunately it is not necessarily good news for the organization, because many CBS replacement projects end up with the need to maintain a new system in addition to the previous solution to be replaced, with virtually unchanged functionality. For example, the accounts and loans remain in the old solution, and only the deposits are successfully transferred to the new one, and this state is conserved.
Banks often aim to simplify their application architecture during the implementation of a next-generation core banking system. However, the simplification of the architecture is difficult to grasp and measure. Therefore, in certain cases, even when another solution appears in the environment in addition to the system to be replaced, the organization cannot reach the conclusion that it should actually be considered a failure.
It is important to clarify that the real goal is not the replacement of the CBS or the introduction of a new CBS system. In each case, the exact, well-defined, measurable, and concrete business goals that we want to achieve through the replacement of the core banking system must be determined. Also, the majority of the organization’s top management must agree on these goals.
The magnitude of the tasks to be performed can be affected, for example, by whether we want to provide 24/7 service, and, if the answer is yes, then for what range of services.
A similarly exciting question is nowadays whether we assume the existence of branches, i.e., whether we base our accounting, cost and sales-controlling solution on branches.
In addition to the go-live following the replacement of the core banking system, there are other possible alternative goals, and even a failed project might have positive effects. Nowadays such goals may be learning about microservices architectures, cloud operation, event-driven architecture, data lake and related data exploitation approaches.
In some cases, more tangible, smaller-scale goals can also be set. Acquiring skills, such as operating banking applications in the cloud, can also be defined as an achievable result. However, these goals can usually be achieved much cheaper and with less complexity and risk than replacing an entire core banking system.
When and how should the assessment of the current situation be carried out?
During the CBS transformation, banks often aim to modernize their IT architecture as well. Planning the future seems to be a much more important and exciting task than the assessment and evaluation of the current situation, which is to be surpassed.
When and how should the assessment of the current situation be carried out?
During the CBS transformation, banks often aim to modernize their IT architecture as well. Planning the future seems to be a much more important and exciting task than the assessment and evaluation of the current situation, which is to be surpassed.
This can be a problem mainly because many banks do not have accurate, up-to-date and complete documentation about their current (as-is) products, processes, business capabilities, applications and integrations. For this reason, documenting the current situation seems to be a paralyzingly huge challenge, which also carries the danger that the organization will lose focus on the core banking transformation during its implementation, if it devotes existing resources to a complex current situation assessment.
The danger is real, and according to my experience, it is easy to immerse yourself in the assessment and documentation of the as-is condition, and then, over time, in tracking the changes that take place during the journey.
In addition, the new core banking system will necessarily differ from the existing one, therefore it will cover certain needs in a different way or not at all, therefore the survey of the currently covered needs may seem counterproductive, since they can also be interpreted as an argument against the introduction of the new CBS.
In addition to all of this, the assessment of the current situation must be dealt with, provided that the following conditions are met:
- The bank does not wish to establish a new legal entity.
- The bank does not plan to replace its entire architecture.
- The bank does not wish to significantly alter its existing contracts with its customers (for reasons of regulations or significant churn).
These conditions are met with every core banking system replacements that I have heard of. Even when this is not the case, the program is in reality a greenfield fintech launch or a significant product rationalization (that may precede a CBS replacement).
The biggest challenge is determining the depth and form of assessing and documenting the current situation. This cannot really be precisely defined; the point is that it should not last too long and that we should not lose focus of the final goals. Since this advice is difficult to follow in practice, it is recommended to involve a seasoned expert in the task who has participated in many similar projects and due to their credibility, the guidelines provided by them are acceptable for the organization.
In short, I do not recommend increasing the complexity of renewing a CBS solution by simultaneously rethinking the remaining hundreds of elements of the architecture.
In addition, without establishing a new legal entity or drastically changing the current client and contract portfolio, we are forced to face, among other things, that:
- in domestic payment transactions, the integration of the current solutions has to be ensured in connection with the account number and the payment gateway,
- the integrability of the solution with the regulatory reporting engine has to be made possible as well, because the regulator expects exactly on set of reports from one legal entity,
- the integrations of the typically nearly 100 satellite systems of the core banking system have to be reconsidered, or the scope has to be expanded with the replacement of these as well (a big no-no in my book). This reintegration task associated with satellite solutions applies exponentially if there are similar products in the old and new systems at the same time (see our next point on phasing for more details).
Due to the above, it seems to me that a reasonable approach might be to assess the existing business capabilities required to support the current business processes, and then to identify which applications provide the individual business capabilities and by which topics are those connected to one another.
It is recommended to execute the smallest possible change in this capability and application model, which is consistent with the goals of the core banking transformation. The survey has to be straightforward; it is sufficient if the information discovered has 80-90 percent accuracy, it is not worth spending significant energy on the smallest details.
Considering the complexity and interrelationships of the processes of universal banks, I recommend focusing improvement ambitions on current processes and process steps. It is very difficult to plan the processes of a universal bank coherently and functionally on a blank sheet of paper. Other areas of the core banking transformation also cause a significant challenge in themselves, I do not recommend piling on these difficulties unless there is some conscious, strategic goal driving such a decision.
In practice, I find that many traditional banks create separate legal entities in order to experiment with new approaches. However, these are typically single-product entities, which may not be scalable to become a universal bank. In the region, we saw an attempt to do this earlier through the example of Zuno Bank, until its not very successful conclusion.
MOX bank, an Asian fintech subsidiary of Standard Chartered is a successful example, Intesa Sanpaolo’s solution called Isybank is another such case.
If you are looking for consultants and experts skilled in core banking system transformation projects during the planning or execution of the above tasks, please don’t hesitate to contact us!
In the next part of our article, we continue with the following topics:
- Modeling, specification, list of requirements
- Should we choose a Big Bang or a phased approach?
- Parallel changes
Please see MINDSPIRE’s related:
Banking Transformation
Services
MINDSPIRE’s Transport
Tool
Do you have a question or comment?
Please fill out the form and we will get in touch with you soon.
