/*Blog module replace 'read more' text*/

U a

Potential issues and

possible solutions during
Core Banking System
replacement projects -
Part 1.

MINDSPIRE BLOG

Follow MINDSPIRE on social!

  

Dec 6, 2021 | Banking Transformation Blog

2
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:

Then next generation of Core Banking Systems

Choosing a Core Banking System
Main questions in the 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.

2
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.

2
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.

2
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.

2
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:

1. The bank does not wish to establish a new legal entity.

2. The bank does not plan to replace its entire architecture.
3. 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
2
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 cover the following:

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

Learn More I

MINDSPIRE’s Transport
Tool

Discover Transport I

Do you have a question or

comment?
2
 Please fill out the form and we will get in touch with you soon.

Your question or comment

Email Address

Name

I agree to the Data Storage and Data Processing Policies

Submit I

Our latest Banking

Transformation References

MUREX project last phase Erste Bank – George

implementation project
New Lending Front-End
implementation with BPR
2
4 PROJECT INFORMATION
CLIENT: Unspecified Bank PROJECT INFORMATION PROJECT INFORMATION 5
DURATION: 2019.07. – 2021.01. CLIENT: Erste Bank CLIENT: Unspecified Bank
MAIN INVOLVEMENT AREAS DURATION: 2019.01. – 2021.03. DURATION: 2017.03. – 2017.09.
Project planning MAIN INVOLVEMENT AREAS MAIN INVOLVEMENT AREAS
 Project execution Product owner roles BPR Methodology
Test co-ordination Enterprise architecture tasks Stream management
Scope management Stream leading Planning and follow-up of Milestone
Project reporting and monitoring Test co-ordination and Resources
Business consultancy Scope management Read more
Read more Business consultancy
Migration support
Read more

You can find more information here:

Learn more

Your business in good hands.

SERVICES
REFERENCES
CAREER
NEWS
ABOUT US
CONTACT

CONTACT US

f in
1027 Budapest, Ganz Street 16., 5th floor

[email protected]

Mindspire © 2021 Legal information Privacy policy Cookie policy Impressum

Legal information Mindspire © 2021

Cookie Policy
Privacy Policy
Impressum