By Raphael Friese, Harald Kube, Sebastian Schöbl, and Henning Soller
An acceleration in customer appetite for digital experiences and rising competition from fintech and other digitally savvy companies are pressuring banks to modernize their core platforms. In response, banks are adopting modern technologies such as the cloud, a critical enabler of digital transformations and a potential solution to reduce technical debt (the accumulated costs from one-off tech solutions or integrations). Yet many banks soon realize that their core banking systems cannot support the demands of these digital solutions, such as real-time transaction processing and quick product releases.
To enable digitization, some banks are pursuing core-banking-system (CBS) transformations. Yet over the past decade, only about 30 percent of CBS transformations succeeded in carrying out a complete migration of ledgers and products to a new system, suggesting that banks have not yet cracked the code on full implementation.
To understand where the breakdowns occur, we analyzed more than 50 CBS transformations performed over the past seven years. While there is no one-size-fits-all approach, we identified eight common missteps banks make in their transformations across the categories of people, process, and technology, at least one of which was the root cause of the transformation’s failure. Furthermore, because CBS transformations are highly complex and resource intensive, they occur infrequently, so banks are likely unfamiliar with the impact of certain decisions on overall transformation success.
Talent is the fuel for a transformation, but banks often fail to put the right people in charge of the transformation, to adapt structures and processes, and to gain consensus on the transformation’s goals.
Misstep 1: Putting operations in charge of the implementation
Some banks put the teams that lead operations of existing systems in charge of implementing the new one. However, these teams often resist adopting a new architecture system and processes, or they may unintentionally migrate legacy processes into a modern core banking solution, creating delays. Instead, banks could set up agile implementation teams consisting of people who have experience working internally and people who have implemented CBS transformations at other banks and are knowledgeable about new technology.
Misstep 2: Defining the CBS transformation as purely a technology transformation
Most successful CBS implementations start with an organizational transformation that puts the right people in place—or the transformation occurs in parallel with the tech transformation. Banks that introduce DevOps and agile practices, such as sprint teams and continuous integration and continuous delivery (CI/CD), before the transformation are typically successful because these models work well within a flexible modern architecture. Our analysis reveals that even successful banks can miss out on performance improvements of up to 50 percent without these approaches.
Misstep 3: Failing to align stakeholders on the function and scope of the new system
While the business and tech sides of the organization may agree on the necessity of a new CBS, they don’t often share the same view of why it’s necessary. CIOs and CTOs want to modernize the system architecture to enable more capabilities, such as rapid product releases. Business heads, however, want to increase revenue through shorter time to market, and CFOs want to reduce overall costs. These competing priorities often result in significant misunderstandings and mismatched incentives and planning horizons. All stakeholders tend to underestimate the time required to migrate customers to the new CBS—in many cases, by as much as 75 percent. To achieve solid stakeholder alignment, an organization should find an implementation partner with a similar level of vested interest in the transformation.
Inadequate planning and the temptation to keep legacy applications can siphon off resources and sap a transformation’s momentum.
Misstep 4: Allowing planning and implementation to delay the rollout for years
Another major source of failure is long-term implementation phases that end with waterfall-like “go-lives” (new-system rollouts). The planning phase can take up to three years and the implementation phase more than four and up to ten. Such timelines, also known as continuous or evolutionary transformations, can cause “scope creep,” because regulatory and technology requirements and even market demand change over time. We’ve seen banks overspend by 100 percent and timelines increase by 50 to 100 percent. Banks could avoid scope and cost increases by scheduling go-lives every one to two years, evaluating the results of each one, and extracting insights to apply during the next transformation phase.
Misstep 5: Failing to be transparent about costs and implications of the transformation
If banks don’t adequately finance the CBS transformation, they may experience project breaks and delays when resources dry up mid-implementation. There are multiple reasons for this. Stakeholders want to avoid divulging how costly the transformation can be for fear it will be rejected. Relatedly, they may be less than fully transparent at the start about the implications of the transformation, such as possible stability issues during migration. In addition, a CBS transformation can also be “hidden” in a business initiative as one dependency among others, obscuring the fundamental changes it will require.
Misstep 6: Continuing to use legacy components to the exclusion of a broader system revamp
Some banks don't have a decommissioning plan for legacy applications, processes, and products at the start of the transformation, choosing to keep them running to reduce the transformation’s initial complexity. Unfortunately, this approach significantly increases spending in the long run, as legacy components are not cheap to maintain. If they are not decommissioned, the CBS transformation will not reduce the overall complexity of the IT landscape. In many less successful cases, legacy applications are still running at 10 to 20 percent of functionality more than five years after the CBS implementation.
A myopic approach to vendor selection and the customization of individual applications can undermine the impact of a new CBS.
Misstep 7: Choosing partners based on price
In many cases, banks choose a tech vendor based on price rather than the vendor’s banking industry knowledge and experience with a CBS. Yet these vendors can underestimate the complexity of the requirements, investing too much time and money in tech without considering whether it meets specific business needs. Consequences of this approach include overcustomization of a standard product and complex interfaces or scope changes during the runtime of a project. A partnership between the vendor and the bank can also be problematic, as each side lacks critical capabilities and cannot fill knowledge gaps. When organizations assess vendors, they should ensure that cost is not the only criterion they consider.
Misstep 8: Failing to integrate the CBS with the broader platform
In the mid to long term, customization increases the complexity of the CBS and can counteract potential efficiency gains. For instance, banks might underestimate how long it takes to integrate the new system with back-office applications, resulting in more custom solutions and complex interfaces that create significant budget and time overruns. Relatedly, banks may not detect missing functionality in the new system or fully understand its complexity. This lack of clarity can create project delays, and banks might build costly custom solutions to ease integration. However, banks that build a digital attacker in parallel with the existing CBS won’t deal with migration issues related to legacy systems.
Banks that avoid or proactively address these pitfalls will be more likely to achieve a successful CBS transformation without timeline and cost overruns. Furthermore, banks that regularly review their approaches within the areas of people, process, and technology can identify areas for improvement for future large-scale transformations.
Raphael Friese is a consultant in McKinsey’s Stuttgart office, Harald Kube and Henning Soller are partners in the Frankfurt office, and Sebastian Schöbl is an associate partner in the Berlin office.