By Supratim Ghose and Henning Soller
Digital and virtual banking are table stakes for banks as customers expect fast, on-demand service and employees expect digital capabilities to become ubiquitous. In parallel, there is a massive push for the availability of digital solutions, such as new digital apps, that require access to core banking data and functionality. Banks therefore need to accelerate their digitization agenda. For most, digitization has become a major challenge often leading to workarounds that cause massive replication of data. To digitize quickly and efficiently, banks need to modernize their core banking systems (CBSs).
Based on our experience, there are three ways to modernize the CBS:
- fully replace it
- implement greenfield core banking technologies and suites
- revamp and decompose the existing CBS
While full replacement and greenfield approaches are effective, they are costly and come with high-risk profiles because of the migration of full functionality, products, and customer data. Decomposition isn’t without its challenges either—IT and business functions often struggle to identify which layers of the CBS to remove and in what sequence. A carefully planned and executed decomposition, however, can make the CBS nimbler, thus reducing system complexity and creating a viable path for a potentially easier full replacement or greenfield implementation later on.
While each modernization effort is different, there are seven common levers that can facilitate the decomposition process, resulting in a much nimbler core. To start, stakeholders should ensure they have a full view of the CBS and all its functionalities and interfaces in order to avoid missteps during decomposition.
Traditional CBSs consist of three key components: core of the bank; master data and other bank functions, such as payment clearing; and additional capabilities, such as cash management. Some banks may have expanded their CBS functionality to meet business needs through significant customizations, such as complex file-based and point-to-point integrations with other enterprise systems and multiple batch jobs for data synchronization across systems. Once stakeholders have a complete understanding of all the components of the current CBS, they can plan the modernization effort.
Selecting decomposition levers
Because the base functionalities of managing a bank account have not changed over several decades, it is generally accepted that decomposing the existing core banking system and decoupling it from auxiliary systems is the best way to extend the life of a legacy core. However, the levers needed to perform such decompositions are harder to identify.
In our experience, banks typically adopt seven decomposition levers, which are categorized according to one of three intended outcomes: reduced complexity, reduced costs, and ease of change (exhibit).
The associated complexity and benefits of each lever are guidelines; a lever’s effectiveness will vary with the CBS’s architecture. To select the right options, banks must consider their business needs, the estimated implementation effort, and the desired business benefit.
Reducing complexity
To simplify the CBS, banks can explore three options focused on the removal and carve-out of unused or unneeded modules.
Rationalize customizations or modules. Banks should analyze unused modules within the CBS code base, screen components, and evaluate other business logic and remove if necessary. This analysis includes the identification of unwanted customizations of an off-the-shelf platform. McKinsey analysis shows that only 10 percent of existing core-banking-system customizations are regulatory driven or business critical.
Carve out master-data components. In most cases, customer data is stored within the core banking system. However, requests directed to core banking for basic products, customer data, and pricing data create significant workloads and costs. To simplify, banks can carve out such functionalities and data, allocating them to dedicated master databases and thus reducing the overall load of the CBS.
Carve out core bank functions to best-of-breed systems. Core banking has become the hub for numerous functionalities, including payments and the general ledger. Carving out these functionalities and providing them through a dedicated system outside the CBS typically provides a better set of functionalities and a reduced burden on functionality in the core.
Reducing costs
To find cost-reduction opportunities, banks can focus on the rationalization of workloads and data extracts.
Rationalize data extracts. Because of the proliferation of batch jobs and reports, the CBS receives a large number of data-extract requests on an ongoing basis. Since batch jobs create unwanted disturbances in the environment, banks can minimize them by providing reports only from dedicated data environments and warehouses, which allows significant rationalization and simplification of data extracts.
Rationalize core bank workloads. In some cases, a few processes can be offloaded to other, less expensive, data sources—especially if transactions are not affected. The consumption of specific expenses databases or computation in core banking, for example, are workloads that could move outside the core. Banks could set up alternative data storage and serve read-only queries from channel applications.
Supporting ease of change
To make the CBS more amenable to later adjustments, banks can focus on the use of microservices and the ease of integration patterns with front ends.
Carve out functions to microservices. Core banking should be used only for core functionalities, such as storing account information for customers and posting transaction information. Functionalities such as statement generation and mandate management for direct debit should reside within dedicated microservices, reducing the need to customize within the core.
Decouple channel front ends from the CBS. The front ends of many banks and outside connections are often set up through tight coupling or even direct database connections. This approach hinders modern development principles and creates unnecessary dependencies. Replacing existing point-to-point connections with application programming interfaces (APIs), however, can remove dependencies and enable faster and more reliable front-end development.
Sequencing the levers
The sequencing of levers depends upon a bank’s underlying key reasons for undertaking a core banking change in the first place.
One bank, for instance, wanted to modernize its CBS using several decomposition levers, primarily to ease change. As a result, it prioritized both a full-scale API layer to decouple the channels from the core banking system and dedicated microservices to provide new digital features. To reduce complexity, it moved its core banking customizations to dedicated microservices and separately pushed all operational and regulatory reporting to its data warehouse. These efforts helped reduce the time needed for the CBS modernization from around four years to two, while revamping its digital channels in parallel.
Modernizing the CBS produces a nimbler CBS, making it easier for business functions to access critical data, effect faster pricing changes, and develop innovative propositions to meet current and future customer needs.
This post is part of a series based on a recent article that discusses common antipatterns in technology transformations and how to avoid them.
Supratim Ghose is an expert in McKinsey’s London office, and Henning Soller is a partner in the Frankfurt office.