MINDSPIRE BLOG
Follow MINDSPIRE on social!
Lessons from the Past
As an expert, I have been involved in the selection and implementation of several core banking systems over the past fifteen years. I have observed even more such projects sometimes closely and sometimes from a distance.
In the financial institutions of the region, including Hungary as well, the core banking systems currently in use were typically implemented in the 1990s and 2000s. Given the significant changes that have taken place in the meanwhile in terms of technology, regulations and customer requirements, most banks repeatedly face questions about the future of these solutions.
In my previous post I assessed the chances of the next-generation core banking systems. Now I examine the factors that a financial institution should consider when choosing a core banking system and add some personal examples to these points.
What is the exact justification for the replacement of core banking systems?
When replacing a core banking system, the objectives of the project have to be always defined in advance in line with the business and IT strategy. In addition, the support of the entire senior management must be obtained, even before the planning phase.
Although the above-mentioned points are well-known and basic requirements for all IT projects, in my experience these are often not met during core banking system replacements. This in turn, due to the complexity, cost and time required for the task, has a rather serious negative impact on projects.
I would bring up two recent examples, when, even though for different reasons and with different results, the preparation of the core banking system replacement project took place under far from ideal conditions.
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.
In the first case, the CIO of one of the regional financial institutions, recognizing the limitations of the application in use, came to a professional standpoint that the solution would be to replace the entire core banking system landscape. As head of IT, he assumed that the topic fell within his own scope, so he made little effort to convince either the retail or corporate heads of the bank of the need and timeliness of the task.
They, in turn, were concerned that such an undertaking would slow down the implementation of the developments that would support the achievement of business objectives for years, while not seeing any particular threat in maintaining the status quo, so they eventually obstructed the idea.
As a result, the CIO was forced to pursue his career elsewhere, while the core banking system in use at that time is still in use in the bank to this day.
Learning the lessons from what has happened, several subsequent IT executives in this financial institution avoided getting truly involved in this topic.
MINDSPIRE core banking experience and methodology
Knowledge of core banking systems (such as Flexcube, T24, Murex, CAMS and SMAC).
Proven and customized complex banking transformation methodology package.
We have created standard solutions to the most challenging banking transformation problems.
We use our own tools and templates to help reduce the risks of a classic implementation project.
Problems and solutions
In the second case, the managers of a group’s subsidiary bank reported to the HQ that their account management system was outdated and the developers were already beyond retirement age. Therefore, according to their views, the account management system should be upgraded or replaced, but both solutions would be such a shock to the organization that they would rather postpone the project.
Although attempted several times, they failed to properly communicate the partially correctly identified problem to the HQ. Finally, after receiving the repeated signals, it was decided unilaterally at group level that an account management system selected at the center should be implemented at the subsidiary bank immediately.
So, for the problem raised, a drastic response was made without a detailed investigation, which did not necessarily address the original problems completely and correctly. For me, the lesson learned here was that it is critical to accurately identify the problem for which we are responding with an answer having the complexity, cost and turnaround time of a core banking system replacement.
In my view, it would have been possible to find a significantly cheaper solution targeting the identified discrepancies for certain specific challenges. During the introduction of the new account management system, it was a significant challenge for the project team to measure the fulfilment of the business motives for the replacement, since they were not fully known to them.
Another lesson is that without unambiguous and comprehensible reasons it is very difficult to manage such a complex and costly project in accordance with its objectives. In addition to this, there is a significant risk that the existing political consensus will evaporate during the preparation or implementation phases of the core banking system replacement project, and the endeavour will fail, resulting in a semi-implemented and partially replaced system.
In order to create true value, my suggestion is that the focal points of the project should be identified based on a high-level business and IT strategy before embarking on a costly task.
Otherwise, it will be very difficult to answer the following simple question: Why do we plan to spend hundreds of millions of euros on a project that slows down or makes it extremely difficult to execute our other business objectives and operations?
Boundaries of the banking account management system
Before replacing the account management system of a bank, it is important to determine what the scope of the new account management system will be, and what functionality will we cover with other systems.
It is important to address this issue in time for a number of reasons. First, it can help us a lot in precisely defining the expectations of the new system. Second, defining functionality can also be the basis for a more general architectural renewal. Third, the realization of capabilities beyond the functionality of the future account management system can be initiated independently of the account management system replacement project.
End-to-end business processes, products and services and high-level business capabilities may also be worth to consider when defining the boundaries of a new account management system. Employing a standard vocabulary can be very helpful during this task, as misunderstandings about the concepts used in the project can be avoided with its use.
BIAN is currently the most popular such standard. Positive features of BIAN include that it incorporates a business capability-, a service- and a data model as well, and besides the largest account management system vendors a number of smaller ones, as well as many banks are also members of the community. Its disadvantage is that in certain areas the details are defined in varying quality.
Earlier I was part of an account management system replacement project in a bank, where questions about the boundaries of the solution were formulated correctly, even before the task began. Despite that, during the project, among others, it was unfortunately not determined whether the BI solution, the unified front-end, the loan origination, the collateral management or even the collateral allocation should be implemented as part of the new core banking system, or as part of another or several other applications.
As a result, the smallest and largest possible scope of the project differed drastically, which also meant a high degree of uncertainty during design and implementation phases. As a result, the different functional areas have been developed in varying detail. While detailed GAP analysis was executed for the most basic functions, for integral, but only sketchily examined areas, even the identification of alternatives was not truly begun.
Due to the high degree of uncertainty, the focus slowly changed over time. Although the project name still remained ‘Core banking system replacement’, but in reality, the purpose and the mission has changed. The original core banking system is still in use in the bank even to this day.
Basic requirements and challenges of a custom developed core banking system
Is it feasible for a financial institution to start developing a custom solution instead of the out-of-the-box core banking systems available on the market?
To put it very simply, I think the key question is how likely we think that the organization of the bank is capable to accurately and completely define the expected analytical account management operation, taking into account the extremely diverse context. In other words: what is the delivery capacity of the team of business analysts available to us.
In my view, pinpointing expectations is not an easy task at all. For better or worse, but this challenge has already been solved by suppliers of universal core banking systems for banks operating in a production environment.
During the execution of similar tasks, I encountered two different types of challenges. One was caused by the lack of appropriate custom tools, and the other was due to the alluring depths of process-, data-, architecture-, interface- and other modeling solutions.
At one endpoint of the first approach, a large number of Word documents and Excel spreadsheets were generated during the requirement gathering. These went through a predefined approval process in a Sharepoint repository and then were handed over for execution after the final consent.
Minor changes were undocumented or took months to approve, none of these can be considered an ideal solution.
With this approach, the traceability of interrelations and alterations is not possible or very difficult to maintain. It is recommended to employ solutions that can use links, such as a wiki tool (e.g. Confluence).
When the planning phase is mainly based on the preparation of textual documentation, then in the case of complex systems such as the account management solutions, I recommend using a tool that supports change tracking natively.
According to the other method, we use a modeling tool to track the interrelations between the information. Here, although the model was able to grow with the increase in the complexity of the task, two different problems may appear.
If the staff involved in the assessment is not using the selected modeling tool in a uniform fashion, an even more complex and difficult to overview material can come into existence than with the text-based approach. To prevent this, it is recommended to hold methodological trainings for employees at several times at the beginning and during the execution of the task. During these, it should be emphasized that the goal is to fully model business capabilities and data, with consistent use of terminology and detail. In addition, a regular forum should be set up where those involved in modeling can discuss the interesting professional tidbits that arise.
The other challenge is that it is difficult to find the ideal level of detail in the modeling. Since the information needed to be registered when performing a task of such complexity is overwhelming in quantity and diversity, a methodology built on this in itself can slow down the process of the planning tasks so much that for an outside observer it will be indistinguishable from walking in place.
An experienced and determined methodological lead can help with this problem. With strong professional leadership and continuous monitoring, repetitive training can create the expected professional uniformity and prevent the modelling from becoming infinite in depth.
In my view, both approaches can be used in practice. Without a modeling tool, the traceability of interdependencies and modifications must be ensured. With modeling solutions, special care must be taken to ensure consistency and avoid overcomplication.
Personally, I recommend to use modeling tools to accurately and fully define the operations of the analytical account management, because it provides a much greater chance to assess and continuously maintain the interdependencies.
Another particularly difficult to estimate aspect is the expected maintenance costs of a core banking system developed in-house, which I believe is a very important question. How many staff will be needed to ensure continuous operation? Will we be able to maintain this team, and will we be able to replace any possible churn or lost capacity from the labor market? What will be the total cost of the in-house operation, maintenance and development? How does this compare to the maintenance fee of an out-of-the-box product?
If we have data on a similar but smaller scale previous project (e.g., shadow balance), it is worth extrapolating the development and operating costs from it.
In the next part of the article, I wrote in more detail about the aspects that proved to be a key issue for me when choosing a boxed financial institution account management system.
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.
