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.