Core Banking Replacement Strategies

Introduction

Core banking systems are the heart of the bank’s software applications. Banks rely on core banking systems to manage customer accounts based on the bank’s product processing rules. It is the primary job of the core banking system to maintain account balances, to validate and commit incoming transactions against the accounts and to perform periodic functions such as paying or collecting interest and maturing accounts based on the product processing rules agreed with the customer.

Core banking systems integrate with other key applications. Integration with channel applications provides customers with up-to-the-moment access to their accounts at the bank’s branches, call centres, ATMs and Internet Banking channels. In addition, integration with other downstream systems feeds account and transaction data to regulatory and internal reporting, monitoring and analytical applications. Together, the core banking, channel and downstream applications form an internal web of applications without which no bank can operate today.

A flexible core banking system that allows the bank to rapidly launch new products and services can give the bank a significant advantage over its competitors. However, many banks have legacy core banking systems that are into their third or fourth decade of operation. In such cases these systems are packages or in-house applications that have been heavily customized to support the bank’s changing requirements over the years. Aging technology and the heavy customization have made these systems challenging to support and slow to respond to market needs. Adding new products and services can take months of development and testing at considerable cost and effort.

Banks that find themselves in this situation are eventually forced to consider replacing their existing system. Modern core banking systems promise new products and services can be launched in days, rather than months, at minimal expense and risk to the bank. However, the banks know that implementing a new core banking system will require significant investment and time during which limited IT resources will be further stretched. The promise of a flexible, responsive core banking system is great but the implementation risks are significant. Stories of failed core banking systems implementations abound in every market. How can the bank proceed with this strategic IT initiative and maximize its chances of success?

Anatomy of Bank’s IT Environment

If we think of the banks software applications as a virtual body, the channel applications are the face the bank puts forward to its staff and customers. These include the applications that support assisted channels such as branches and call centres, as well as the direct channels such as ATMs and Internet banking, to mention a few. Enhancing these applications and keeping them friendly is as important as keeping a smile on your face in the world of sales and service. Replacing these applications can give the bank a much needed face lift and keep it looking young and lively.

Similarly, the data warehouse, portfolio monitoring, risk management, accounting and operational and regulatory reporting applications can be likened to the liver, kidneys, bladder, spleen and a host of organs that work with the immune system to keep us healthy by monitoring and purifying our blood from natural toxins. These applications monitor the data that flows through them and help identify and promote healthy accounts while reporting and regulating problem accounts and suspicious transactions and behaviour. Enhancing or renewing these applications is necessary to keep the bank healthy and in compliance with regulatory requirements.

All these applications depend on the data flowing from the core banking system, whether in response to a customer enquiry at a channel or an automated flow of data to the downstream monitoring applications. For this reason, data should flow continuously from the core banking system through the bank’s network like blood flowing from the heart through the body’s veins and arteries. Consequently, enhancing or replacing the core banking system is likened to open heart surgery on a bank while it continues with its day-to-day operations.

Implementation Risks

Core banking systems implementation projects face significant challenges, not least of which are:

Application risk – the risk that the application selected for implementation is not operable or does not meet expectations.
The risk that the selected system is not operable refers to inability of the system to operate or perform appropriately. For example, if the new system cannot support the bank’s business volumes in a stable and reliable manner, then it can be considered inoperable.
The risk that the selected system does not meet expectations refers to inability to satisfy stakeholder expectations. For example, key stakeholders for the new core banking system expect the system to support rapid deployment of new and innovative products.
Customization risk – customization of the new application adds disproportionately to the application risk.
Enhancements to the new core banking system to support local regulatory and business requirements introduce core systems development risks to the project. These risks are proportional to the amount of customization required. The greater the customization the greater the risks that the customization inadvertently creates deficiencies in the new system or does not meet stakeholder expectations. These risks are further heightened when undertaken by an implementation team and not the original developers of the system.

Legacy Applications Integration risk – risks inherent in customizing and integrating the bank’s legacy applications to operate with the new core banking system.
Enhancing the bank’s other key applications to integrate with the new core banking system is typically the largest effort of the core banking implementation project. Minimizing the change to the legacy applications is essential but must be balanced with minimizing customization of the new core banking system. Risks inherent in customizing and integrating the bank’s legacy applications include budget, schedule and delivery risks.
Large project risk – large, long running IT projects are more likely to fail or be discontinued due to changing business priorities or market conditions.
Long running projects are more likely to experience significant changes in the organization and in external factors. Changes in the organization’s business priorities and market conditions can adversely impact the original business case for the project. Retirement, promotions and new hiring can also change the key business stakeholders and sponsors. At a minimum the project will need to re-establish common understanding with the business stakeholders and will lose the shared vision developed with the departing stakeholders. To manage these risks, large projects incur higher change management costs and risk losing support at critical times in the project lifecycle.

There are many other implementation risks to be sure, including data conversion risk, team skills and capabilities risk and so on. However, rather than itemize the risks and present mitigations for each, we want to propose a more strategic approach to mitigate these risks.

A Strategic Approach to Core Banking Systems Replacement

Our business goal is to replace (or complement) our legacy core banking system with a new system capable of rapidly launching new and innovative products. Our strategic options are:

Big Bang Replacement – Implement new core banking system and replace legacy core banking system simultaneously.
Big Bang Replacement refers to a one-time, en masse conversion of existing accounts from the legacy core banking system to the new core banking system. Key characteristic of this approach is that the existing accounts are moved en masse from the legacy system to the new system. Another key characteristic of the Big Bang Replacement is that the legacy system and the new core banking system do not coexist in production.
Phased Replacement – Implement the new system and replace legacy system simultaneously in stages.
Phased Replacement can be undertaken by Branch or Geographic Clusters, by Product or Product Groups, and by Customer or Customer Types, for example. Other phasing options may be available depending on the legacy environment and business considerations of the bank. However, the common characteristic of the Phased Replacement approach is the piecemeal replacement of the legacy core banking system in a series of “mini-bangs” each involving migration of a certain portion of the existing accounts from the legacy system to the new system.
For example, Phased Replacement by Product Group would result in all accounts belonging to that Product Group being moved to the new system en masse. Under this approach, the legacy and new core banking systems would co-exist though each Product Group would be processed on only one of the core banking systems at any one time.
Similarly, Phased Replacement by Branch or Geographic Cluster would result in all accounts belonging to that Branch or Region being moved to the new system en masse. Under the Phased Replacement by Branch approach, the legacy and new systems would again coexist though each Branch or Geographic Cluster would be processed on only one of the core banking systems at any one time.
Gradual Transition – Implement new core banking system for new and innovative products first and then gradually transition existing accounts from the legacy system.
The key characteristic of the Gradual Transition approach is that the new core banking system is implemented for new business first, in order for the bank to rapidly offer new products and services supported by the new system. Subsequently, in a separate phase, the existing accounts are converted to the new system either en masse or in a gradual manner (e.g. by product, by branch, by customer or by account).
New World Implementation – Implement new core banking system for new and innovative products and retain the legacy system for existing accounts.
This approach is similar to the first part of the Gradual Transition option but does not include transition of the existing accounts to the new system. Instead, the legacy core banking system is retained to process the existing accounts and the new core banking system is used to launch new and innovative core banking products and services.

These options span the continuum of options ranging from one-time, massive replacement to complementary new world implementation, Let’s compare these options and consider what criteria a bank can apply when deciding on their appropriate strategy.

Which Strategic Option to Adopt?

As we noted there are four strategic options to consider:

Big Bang Replacement – Implement new core banking system and replace legacy core banking system simultaneously
Phased Replacement – Implement new system and replace legacy system simultaneously in stages
Gradual Transition – Implement new core banking system for new and innovative products first and then gradually transition existing accounts from the legacy system
New World Implementation – Implement new system for new and innovative products and retain the legacy system for existing accounts.

The right approach for any given bank will depend on the circumstances specific to the bank and the priorities faced by the bank. For example, a bank that is suffering in the market place due to inability to deploy new and innovative products in a timely manner may opt for Gradual Transition or New World Implementation. However a bank that is faced with major investment to overhaul its existing system in order to keep it operable may favour Big Bang Replacement or a more rapid version of Phased Replacement.

However, the decision needs to be considered in light of the risks we discussed earlier. Let’s compare the strategic options in light of these risks, too.

Big Bang Replacement

The Big Bang approach has the advantage of reduced integration effort compared to the other options because it avoids coexistence of the new and legacy core banking systems. With only one core banking system, the other applications do not need to support interfaces to two core banking systems simultaneously. In addition, all things considered equal, the Big Bang approach requires less time to replace the existing system since the accounts are converted to the new system as soon as the new system is launched.

In summary, the key benefits of the Big Bang Replacement approach are:

Lower integration effort compared to other options that require coexistence of the core banking systems
Promises fastest path to replacing the legacy core banking system (though not the fastest to implement the new core banking system)
Lower ongoing maintenance costs because the legacy system is immediately replaced upon deployment of the new core banking system.

Here’s how we see the Big Bang approach in light of the key project risks:

Application risk – the risk that the application selected for implementation is not operable or does not meet expectations

The risk that the new core banking system is inoperable is high under the Big Bang Replacement approach since the system will be responsible for the existing business volumes immediately upon deployment. This risk is mitigated by testing stages that are required under all options. However, the impact of this risk is greatest under the Big Bang Replacement option since the impact, if realized, affects the bank’s business for all accounts.

The risk that the selected system does not meet expectations is significant for Big Bang Replacement projects. The reason for this is that the selected application must support the existing products and services in order to replace the legacy core banking system. Typically, the legacy core banking system will have been customized over the decades to support products and services unique to the bank. Starting with a “replacement” mindset establishes expectations that the replacement system will support the old system’s capabilities and provide new and advanced capabilities. Consequently, either expectations will not be met or significant enhancements will be required (see customization risk below) before the application can be launched.

An appropriate mitigation is to agree with the business stakeholders that some of the old capabilities will not be supported. However, in practice, this can have customer impact as the existing accounts will be processed differently once converted to the new system. Compromises will be required and will add to the customization needed before the new system can be deployed as compared to the other options. Furthermore, even where compromises can be avoided, there will be additional effort required to consider and negotiate all existing capabilities and confirm with all stakeholders whether they will be supported by the new system.

Customization risk – customization of the new application adds disproportionately to the application risk

Customization risk is high for Big Bang Replacement because the new system is required to support new and innovative products and services plus the existing products and services before deployment. This results in greater effort throughout the project phases, from requirements gathering, design, build and testing. The additional effort in each phase also incurs additional risks at each phase. For example, incomplete requirements gathering will result in rework and delays when identified during testing.

Additional customization is also required to build the data conversion facility, extracting data from the existing systems and loading to the new system. The data conversion process is complex and highly sensitive as it impacts customers’ accounts. Establishing controls and reconciliation processes is a time consuming and intensive effort that also adds significant risk.

Legacy Applications Integration risk – risks inherent in customizing and integrating the bank’s legacy applications to operate with the new core banking system

Legacy Application Integration risk is high for Big Bang Replacement because all existing interfaces must be replaced with corresponding interfaces to the new core banking system before deployment. However, the risk is lower than for other options that require legacy applications to integrate simultaneously to the new and legacy core banking systems.

Large project risk – large, long running IT projects are more likely to fail or be discontinued due to changing business priorities or market conditions

Large project risk is high for Big Bang Replacement because implementation of the new system and replacement of the old are combined into one project. Consequently, the critical path for first deployment includes customization of the new system to support the existing products and services, development of the data conversion capability and the replacement of all legacy interfaces.

Phased Replacement

The Phased Replacement approach takes longer to fully replace the legacy core banking system as compared to the Big Bang Replacement approach. However, the Phased Replacement approach has the benefit of dividing the work so that the initial phases are deployed earlier as compared to the one-time deployment of the Phased Replacement approach.

Similar to Big Bang Replacement, the Phased Replacement approach can also avoid coexistence when the phasing is based on the modules of the legacy core banking system. For example, if the legacy core banking system has distinct modules or applications for each Product Group then phasing by Product Group may avoid coexistence for that Product Group. Similarly, where the legacy core banking system is distinct for each geographic region, then phasing geographically may avoid coexistence within each region.

In summary, the key benefits of the Phased Replacement approach are:

Lower integration effort compared to other options that require coexistence of the core banking systems
Faster deployment of initial phases as compared to the Big Bang Replacement approach
Lower ongoing maintenance costs than Gradual Transition and New World Implementation approaches because the legacy system is replaced upon deployment of each Phase.

Here’s how we see the Phased Replacement approach in light of the key project risks:

Application risk – the risk that the application selected for implementation is not operable or does not meet expectations

The risk that the new core banking system is inoperable is high under the Phased Replacement approach since the system will be responsible for the corresponding business volumes immediately upon deployment of each Phase. This risk is mitigated by testing stages that are required under all options. However, the impact of this risk is second only to the Big Bang Replacement option since the impact, if realized, affects the bank’s business for all converted accounts.

The risk that the selected system does not meet expectations is significant for Phased Replacement projects. The reason for this is that the selected application must support the existing products and services within each Phase in order to replace the corresponding portion of the legacy core banking system. Typically, the legacy core banking system will have been customized over the decades to support products and services unique to the bank. Starting with a “replacement” mindset establishes expectations that the replacement system will support the old system’s capabilities and provide new and advanced capabilities. Consequently, either expectations will not be met or significant enhancements will be required (see customization risk below) before the application can be launched.

Customization risk – customization of the new application adds disproportionately to the application risk

Customization risk is high for Phased Replacement because the new system is required to support new and innovative products and services plus the existing products and services before deployment of each Phase. This results in greater effort throughout the project phases, from requirements gathering, design, build and testing. The additional effort in each phase also incurs additional risks at each phase. For example, incomplete requirements gathering will result in rework and delays when identified during testing.

Compared to Big Bang Replacement, Phased Replacement can spread the customization risk across multiple Phases. However, Phased Replacement also adds complexity to the data conversion processes as subsequent Phases will need to convert into an operational core banking system without impacting the previously converted accounts.

Legacy Applications Integration risk – risks inherent in customizing and integrating the bank’s legacy applications to operate with the new core banking system

Legacy Application Integration risk is high for Phased Replacement because all existing interfaces must be replaced with corresponding interfaces to the new core banking system before deployment. However, the risk is lower than for Big Bang Replacement due to phasing and for the other options that require legacy applications to integrate simultaneously to the new and legacy core banking systems.

Large project risk – large, long running IT projects are more likely to fail or be discontinued due to changing business priorities or market conditions

Large project risk is high for Phased Replacement because implementation of the new system and replacement of the old are combined in each Phase. Consequently, the critical path for first deployment includes customization of the new system to support the existing products and services, development of the data conversion capability and the replacement of all legacy interfaces for the first Phase.

Gradual Transition

The Gradual Transition approach proceeds in two distinct and sequential stages:

New World Implementation – implement the new core banking system for new and innovative products and services
Legacy Migration – migrate the existing accounts from the legacy core banking system to the “new world.”

Gradual Transition offers an earlier deployment of the new system so that the bank can start launching new and innovative products. This is a considerable advantage since the ability to launch new products is a prime driver for most core banking systems implementation. However, as we have mentioned, coexistence of the new and legacy core banking systems requires additional integration effort for the other legacy applications.

In summary, Gradual Transition offers the following benefits:

allows the bank to realise competitive advantage of new and innovative products earlier
allows the business users to familiarize with the new system before moving the existing accounts from the legacy system
minimizes the customization required before initial launch (at a minimum, customization is required to support regulatory requirements only)
New World Implementation stage can be conducted incrementally, starting with a pilot branch and then progressing by branch clusters, to reduce risk of disruption during deployment
postpones the customization required to support existing products and features (and the associated risk) to be in parallel with the gradual transition of the existing accounts
can be executed as a series of smaller projects (with smaller risk), starting with implementation of the new core banking system and followed by a series of enhancement phases to transition the existing accounts to the new system.

Here’s how we see the Gradual Transition approach in light of the key project risks:

Application risk – the risk that the application selected for implementation is not operable or does not meet expectations

The risk that the new core banking system is inoperable is medium under the Gradual Transition approach since the system will not be responsible for the existing business volumes immediately upon initial deployment. This risk is mitigated by testing stages that are required under all options. However, under the Gradual Transition option it is further mitigated by phasing the transition of the existing accounts to the new system. Thus the impact of this risk is lower under the Gradual Transition option (as compared to the Big Bang and Phased Replacement options) since the impact, if realized, affects the new and transitioned accounts only.

The risk that the selected system does not meet expectations is medium for Gradual Transition projects. The reason for this is that the selected application must support the existing products and services eventually in order to replace the legacy core banking system. Typically, the legacy core banking system will have been customized over the decades to support products and services unique to the bank. Starting with a “replacement” mindset establishes expectations that the replacement system will support the old system’s capabilities and provide new and advanced capabilities. Consequently, either expectations will not be met or significant enhancements will be required (see customization risk below) before the project can be considered complete.

An appropriate mitigation is to agree with the business stakeholders that some of the old capabilities will not be supported. However, in practice, this can have customer impact as the existing accounts will be processed differently once converted to the new system. Compromises will be required and will add to the customization needed during the Legacy Migration stage (though not before the new system is deployed). Furthermore, even where compromises can be avoided, there will be additional effort required to consider and negotiate all existing capabilities and confirm with all stakeholders whether they will be supported by the new system. This too, however, can be postponed to after the initial deployment under the Gradual Transition option.

In addition, the Gradual Transition option can be open to doubt and uncertainty as the project team focus on the initial deployment and the business team become concerned that although the initial deployment for new and innovative services may technically deploy, the system may fail to support the bank’s existing accounts in subsequent stages. Given that the expectation set at the outset is for the application to support the existing business, these doubts will need to be managed during the software selection, initial implementation and subsequent transition initiatives.

Customization risk –customization of the new application adds disproportionately to the application risk

Customization risk is medium for Gradual Implementation because the new system is not required to support the existing products and services before initial deployment. This postpones the transition effort and risk associated with customizing the new system to support existing accounts and building the data conversion facility to the Legacy Migration stage of the project.

Legacy Applications Integration risk – risks inherent in customizing and integrating the bank’s legacy applications to operate with the new core banking system

Legacy Application Integration risk is medium for Gradual Transition because the existing interfaces do not need to be replaced before deployment. However, new interfaces need to be developed with coexistence support. For example, the channel applications need to interface to the new system for new accounts while continuing to interface with the existing system for existing accounts. Similarly, downstream applications will need to continue to receive data from the existing core banking system and additional data from the new core banking system. While coexistence support introduces challenges, the channel and downstream applications are typically adept at supporting multiple core systems since it is rare for a bank to support all its deposits, loans, credit cards and foreign currency accounts, for example, in one core system. The challenge from coexistence is to determine the method by which the channel and downstream systems will distinguish the new accounts from the existing accounts. A typical solution is to use different account number formats and ranges.

Large project risk – large, long running IT projects are more likely to fail or be discontinued due to changing business priorities or market conditions

Large project risk is medium for Gradual Transition because implementation of the new system and replacement of the old are separated into two or more projects. Consequently, the critical path for first deployment does not include customization of the new system to support the existing products and services, development of the data conversion capability nor the replacement of all legacy interfaces.

New World Implementation

The New World Implementation approach also offers early deployment of the new core banking system. In addition, it helps focus the entire project on the desired capabilities of the new core banking system, namely the rapid deployment of new and innovative products. The project team no longer needs to consider the limitations of the new system vis-à-vis the legacy products and services. Furthermore, the business team does not need to fret the demise of existing capabilities. However, the New World Implementation approach does require the additional integration for coexistence of the new and existing core banking systems.

Similar to the Gradual Transition option, New World Implementation has other major advantages to offer, including:

allows the bank to realise competitive advantage of new and innovative products earlier
allows the business users to familiarize with the new system while existing accounts continue to operate as normal in the legacy core banking system
minimizes the customization (and the associated risk) to support regulatory requirements only
can be deployed incrementally, starting with a pilot branch and then progressing by branch clusters, to reduce risk of disruption during deployment.

A disadvantage of the New World Implementation option is that the existing system is not replaced. However, for banks that are not under pressure to decommission their existing system, the New World Implementation addresses their immediate need for rapid deployment of new and innovative products and allows for alternative solutions to be considered for existing accounts as a subsequent initiative or initiatives.

Here’s how we see the New World approach in light of the key project risks:

Application risk – the risk that the application selected for implementation is not operable or does not meet expectations

The risk that the new core banking system is inoperable is low under the Gradual Transition approach since the system will not be responsible for the existing business volumes. This risk is mitigated by testing stages that are required under all options. However, under the New World option it is further mitigated by addressing new accounts only. Thus the impact of this risk is lowest under the New World option since the impact, if realized, affects the new accounts only.

The risk that the selected system does not meet expectations is also lower for New World projects. The reason for this is that the selected application does not need to support the existing products and services, a critical issue in all core banking replacement projects.

Customization risk – customization of the new application adds disproportionately to the application risk

Customization risk is low for New World projects because the new system should be implemented for new and innovative products that it already supports (assuming a package is being implemented). Furthermore, the new system is not required to support the existing products and services. This avoids the effort and risk associated with customizing the new system to support existing accounts and building the data conversion facility.

Legacy Application Integration risk – risks inherent in customizing and integrating the bank’s legacy applications to operate with the new core banking system

Integration risk is medium for New World projects because the existing interfaces do not need to be replaced. However, new interfaces need to be developed with coexistence support. For example, the channel applications need to interface to the new system for new accounts while continuing to interface with the existing system for existing accounts. Similarly, downstream applications will need to continue to receive data from the existing core banking system and additional data from the new core banking system. While coexistence support introduces challenges, the channel and downstream applications are typically adept at supporting multiple core systems since it is rare for a bank to support all its deposits, loans, credit cards and foreign currency accounts, for example, in one core system. The challenge from coexistence is to determine the method by which the channel and downstream systems will distinguish the new accounts from the existing accounts. A typical solution is to use different account number formats and ranges.

Large project risk – large, long running IT projects are more likely to fail or be discontinued due to changing business priorities or market conditions

Large project risk is low for New World projects because replacement of the old system is no longer within scope. Consequently, the critical path for whole project does not include customization of the new system to support the existing products and services, development of the data conversion capability nor the replacement of all legacy interfaces.

Other Considerations

Other considerations that have a bearing on the options include:

Package versus in-house development – a package solution that has been assessed to meet your business and performance needs should be considered lower risk under each option as compared to in-house development.

Package Maturity for Market – a package that has been implemented multiple times in your market is already proven and will support the local market and regulatory requirements. Such a package would be easier to implement and is likely the only feasible solution for a bank forced to Big Bang Replacement. However, for banks that need to differentiate themselves in the market through the use of a modern package not yet established locally, the lower risk options of Gradual Transition or New World are the reasonable options to consider.

Conclusion

The risk associated with core banking replacement projects is significant. Most projects fail to achieve their original objectives of enhancing the Bank’s IT infrastructure with a modern, flexible platform for the launch of new and innovative products to gain market share. Banks wanting to maximize their chances of success should consider their strategic options and align their approach with their business priorities, primary objectives and current circumstances. We believe that the New World and Gradual Transition approaches offer the highest chances of success, respectively. They do not guarantee success and nor do they transform the project into a low risk endeavour. Transplanting the heart of the Banks IT systems is not a low risk initiative. They can, however, help you avoid fundamental risks associated with migrating accounts en masse and with customizing the new system to support products and services that the existing system has been tailored to support over many years. In so doing, they raise your chances of success for one of the largest IT investments your bank will undertake.