Core systems strategy for banks

May 4, 2020Core 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.

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.

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.