

Financial Services

Core systems strategy for banks

Next-gen cloud-based core banking systems are gaining traction and have the potential
to become alternatives to traditional core banking systems.

  

By Vishal Dalal
Serves financial institutions, helping them get their legacy technologies ready for the digital age

By Ondrej Dusek

By Anand Mohanrangan
Specializes in getting legacy systems “digital ready”

May 4, 2020 ‑ Core transaction processing engines for banks—or “core banking
systems”—have been making news in the world of banking technology of late.
Some of the major global banks have announced partnerships with new cloud-
based core banking systems providers. There have been a few instances in the US
of these partnerships as well. Many small and midcap banks in the US and Latin
America are known to be shopping around for new cores. This topic seems to have
suddenly gained visibility in the US and the rest of the world

In this article we look at the forces that are raising the core banking profile, and at
the alternatives available to banking leaders as they consider their technology
roadmap.

Banks all over the world spend millions of dollars each on maintaining their core
banking systems, which usually interface with tens or hundreds of systems. Core
banking systems handle a high volume of transactions and are expected to function
without interruption—prolonged outages can invite regulatory scrutiny, customer
opprobrium, and significant loss of revenue.
Legacy core banking systems have traditionally succeeded in terms of reliability.
Failures are rare, with some banks going without an outage for months, if not years.
However, with the advent of digital banking, cloud, and APIs, banks have seen a
significant shift in the way banking products and partnerships are constructed.
Banks are now expected to process transactions in real time, be able to stitch
together partnerships with fintech companies in a matter of weeks, release new
features frequently, be able to scale (up and down) their infrastructure needs at will,
and even execute on M&A quickly. Older core banking systems— usually designed
for reliability rather than open architecture—may need to respond to this new
requirement, which, to their credit, many are doing with alacrity.

In addition to the existential issues listed above, banks endure some tactical day-
to-day pain points with legacy core banking systems. These problems vary from
bank to bank, but include a dwindling engineering talent pool, excessive
undocumented customization leading to a complex code base that can be difficult
and risky to change, and various vendor-support issues.

In response to these issues, a new breed of core banking systems has emerged in
the last few years. They are, or will be, cloud-ready and open-banking compliant,
and, in some cases, have very advanced architectures that make frequent feature
releases easier. Some of these systems are also pushing the envelope in customer
experience and offering innovative and reasonable pricing schemes for core
banking replacements. More importantly, they claim not to compromise on the core
tenet of faultless transaction processing.

Most banking leaders are aware of the significance of their core banking system,
but many do not have explicit strategies tied to the core. And as banking continues
to be disrupted, the traditional core architecture may not be able to deliver for
incumbent banks; and given the long lead times required for transitioning to a new
core, they need to set their strategies in motion now.

The best place to begin this effort is by answering five questions:

1. Does our legacy core banking system require intervention?

2. What interventions are possible to stave off a full transformation?

3. If a core banking replacement is needed, what are the options?

4. What are the core elements of a good business case for such a transformation ?
5. What does a bank do next?

Does our legacy core banking system

require intervention?

Another set of simple questions can give decision-makers a sense of the urgency
of their core system problem (Exhibit 1). Affirmative answers to more than two of the
questions indicate a potential problem and merit further intervention.

Exhibit 1

It is important to carry out this exercise dispassionately and in a business-risk

focused manner. This does not mean taking a myopic view of the problem. If a bank
believes that there are no problems now, but there could be in the future, then
preparing for an intervention now may make sense. It is common for core banking
projects to take two to three years to complete, so the assessment should be made
considering a medium-term horizon.

What interventions are possible to stave

off a full transformation?

Contrary to popular opinion, a “rip-and-replace” is not the only possible

intervention—and often it is often actually not the right choice. Depending on the
urgency, several responses are possible, ranging from small tactical changes to
large-scale re-architecture. Measures like this can extend the life of a core banking
system by as long as five to ten years, which is especially valuable for banks that
lack the capital to install a new core banking system, have other near-term
priorities, or want to wait until more advanced offerings come to market.

Many banks have used these measures (popularly known as “hollowing out”) to
extend the service life of their core banking system by many years, with a lot of
success, and more importantly without slowing down their “digital” journeys.

Exhibit 2 shows a (non-exhaustive) range of options available for extending the

effective life of a core banking system. It is important to remember that these are at
best medium-term measures.

Exhibit 2
If a core banking replacement is needed,

what are the options?

There are two main options (with a few variations) for banks that conclude that they
need to replace their core banking system: a traditional enterprise core banking
system (self-hosted or as a utility) and a next-generation cloud-based core banking
system.

Most current implementations are still of the traditional variety. But we are seeing
an increase in banks of all sizes putting off traditional core implementations with
the aim of experimenting with next-gen systems.

There is some evidence to suggest that banks will try and shift en masse to a
cloud-based microservice architecture in the next few years. The core method of
communication between machines will be APIs. Armed with a micro-service based
architecture, the new core banking applications will become core enablers of the
shift to this architecture. Traditional core banking providers have become aware of
the need and potential inherent in a cloud-based microservice architecture;
banking leaders should keep a close watch on developments here. We also expect
to see some M&A activity between traditional and next-gen core banking system
providers.

For now, there are four primary issues that prevent banks from replacing their core
applications with next-generation core banking applications.

The “at-scale” problem: Banks are very risk averse when it comes to core
replacement, and rightfully so. Given how embedded these core applications are,
banks tend to prefer a tried and tested system to replace them. It is likely that
once the first bank successfully implements a large, “at-scale” next-gen core
system, the floodgates of demand will open. We increasingly see banks willing to
experiment with these players and put their own engineering resources to work
to accelerate this trend.

The “functionality” problem: Traditional core banking systems come with a

range of product and process functionality and are made for heavy customization
to meet the individual needs of the bank. Next-generation core banking systems
are designed to support a slightly more limited set of products and processes,
but with a versatile toolkit (a software development kit, or a repository of APIs),
and fulfill additional needs using an ecosystem of fintech or traditional partners.
This is the right architectural answer, as it ensures loose coupling and fewer
customization problems down the line, but will take some getting used to for
traditional banks. We see this as an opportunity for banks to start building their
ecosystem muscle

The “integration” problem: This problem is proving to be a little more

intractable. Banks expect new core banking systems to integrate with their
existing stack of channels, customer-relationship-management systems, data
architecture, risk systems, and middleware—all of which are very difficult to
replace and represent hundreds of millions of dollars of investment over the
years, meaning they cannot be written off without causing significant disruption
and losses. The problem is that this integration entails high risk and high cost.
The incumbent core banking system has usually undergone significant
customization and development, reflecting changes in business logic over
decades. Untangling the integration from the old system and re-integrating the
 new core banking system is an extremely difficult exercise—the banking
equivalent of a high-risk brain surgery. For a medium-size bank, the cost of this
integration could exceed $50 million depending upon its complexity; for larger
banks, $300 million to $400 million is not unheard of (based on estimates for
traditional implementations). Most banks understandably have very little appetite
for this sort of expense. Banks expect to avoid this problem by installing next-
generation core banking systems separate from the current stack, migrating
customers gradually into the new stack over time and executing a “reverse-
takeover” of the old stack. We believe there is a significant opportunity for banks
to use this as a forcing mechanism to decommission their redundant systems,
simplify their product set, and improve their technology skills, specifically in the
areas of cloud, API based ecosystems, and automation in general.

The public cloud problem: There are a few other issues related to core banking
systems on the public cloud. Most banks are just finding their feet in this arena
and starting to come to grips with the security implications of the cloud. It will
take some time for banks to start storing public data on the cloud without any
fear. We see a lot of positive momentum in this area, with “neo banks” leading the
way. We also see very sophisticated; and constructive engagement by regulators
as far as cloud hosting is concerned. We anticipate that as banks start honing
their cloud operating models, this will soon become a non-issue.

What are the elements of a good core

banking business case?

Whatever option is chosen, an initiative like core banking transformation requires a

solid business case. This is not a trivial exercise: a core banking transformation is
akin to replacing the foundation of a building, and is therefore not always amenable
to a straightforward revenue-based business case. Traditional core banking
replacements have tried to make their case by adding in cost-saving elements
through process automation and clean-ups, but it has proven very difficult to pay
for a core banking transformation purely through efficiencies.

Next-generation core banking systems may present some additional advantages in

making a business case because of their architecture and business model. Some
examples:

Faster time to market for new products if they are truly API driven

Faster set up of ecosystems

Reduced cost of change if testing is truly automated and if core banking vendors
follow a “train the trainer” model and not a “consulting plus model”

Reduced upfront costs if the core banking vendor charges fees based on
revenue-like events such as customer uptake or profits

What does a bank do next?

The next steps for any bank depend, naturally, upon the context. For some banks,
the core system is an urgent priority; for others less so. Some banks have an
appetite for experimentation, while others prefer to be followers and wait for other
incumbents to pioneer a new core banking system. In general, we expect that core
banking implementations will become cheaper and their architecture will become
more and more open. Irrespective of appetite for change, there are several no-
regret moves banks can make now:

Make a list of tactical modernization needs for the current core banking system,
but invest only if there is a burning need. Minimize any strategic non-reusable
investment on the current core banking system, unless it is expected to be the
bank’s core system for the next decade.

Maintain general preparedness for a migration. This includes maintaining a clean

Chart of Accounts and a clean set of customer accounts. Ensure that duplicate,
unpopular, or redundant products are minimized, and dormant accounts or
inactive accounts are reduced where regulation allows it.

If you can experiment with a new application, do so. If an affordable opportunity

arises to set up a new stack using a next-gen core banking system, a bank
should grab the chance to get learn about managing a core system in the cloud.

Build up core talent. Start building up a core team made up of cloud specialists,
data engineers, and core banking subject matter experts in product, finance, and
operations. This core team does not need to be more than six to seven people.
Even if the core banking system is not an immediate issue for a bank, it is very likely
to reach the C-suite agenda at some point. Next-gen cloud-based core banking
systems are gaining more and more traction, and they will rapidly try to become
natural alternatives to traditional core banking systems. Banks should start laying
the no-regret groundwork and do all they can now to prepare for a migration to a
newer system in the medium-term without neglecting tactical modernization of the
existing core.