De-risking Taken to the Core

Changing customer expectations

So, why risk system changes at all if services are up and running? In short, banks have to contend with a paradigm shift in customer demand. Young, digitally savvy consumers are entering the banking market, requiring personalized and seamless multichannel services. Established banks need to adjust to these expectations, on the organizational side as well as technical.

Many financial institutions are still running legacy systems based on mainframe architecture, with an on-premises setup as their CBS. These are already experiencing difficulties when connecting new services and integrating modern banking applications.

Eventually, most existing CBS will need a major refurbishment or a complete replacement. Most common reasons for CBS replacement are low stability of the legacy platform, long time to market for new functionalities due to accumulated technical debt and archaic architecture, complete loss of internal capabilities for further development, or end of support or/and maintenance from the CBS vendor. 

CBS Modernization entails many benefits

In principle there are four options for CBS transformation: upgrade, refactoring, augmentation and replacement.

For a bank, tinkering with their CBS is comparable with open-heart surgery, as a grave mistake might endanger the existence of the corporation. In addition to the risks associated with such undertakings, there are significant financial outlays. Due to these key factors, CBS modernization programs are rare. However, there are many benefits to be gained from such an undertaking.

New, modern applications with a lot of added value to the customers can be easily integrated, ensuring enhanced security and reduced time to market for new products. Moreover, modern architectures are much more flexible and scalable, thus allowing tailored systems requirements (to the actual needs) without excess capacities, thereby savings cost in the long run. Bearing in mind these advantages, some banks decide that a core system change or at least a significant upgrade is the best course of action. 

Possibilities for De-risking

There are several measures that can be taken to reduce or mitigate the risks associated with CBS replacement. To name some key risk addressing measures:  

• selecting appropriate release strategy,  
• designing interim application architectures,   
• isolating the CBS replacement activities,  
• choosing the most suitable deployment approach.

Furthermore, the data migration and deployment activities can be mastered through a series of trial migrations and dress rehearsals.  

“Big-Bang” vs. Gradual Approach

Principally, there are two of the primary options for a CBS replacement. One entails a complete replacement of the current CBS with a new, state-of-the-art solution in one go. This big-bang approach more or less eliminates the need for any two systems running in parallel and enables the financial institution to completely revamp its IT-architecture without the necessity to compatibility with the old one.

On the other hand, the associated risks are rather high, in extreme cases, a complete shutdown of the bank’s systems. To avoid this, intensive tests are unavoidable, prolonging the time the institution has to rely on the old CBS alone. Big-Bang is in many cases is simply not possible due to complexity of migration.  

As the other primary option, the gradual approach comprises of the implementation of new products in the new system while retaining the old one, thus augmenting the IT landscape. That way, the new, parallel core covers the advanced needs not met by the legacy system. Once the implemented platform is stable and proven, more and more legacy functions may be migrated.

In the end, the old CBS is gradually switched off until only the modern system is supporting the bank’s business. While this option sounds safer and more reasonable, before deciding which road to take, there should be an an in-depth analysis of costs and benefits. This is due to the significant additional effort required to enable the coexistence of legacy and target systems, and the need to plan the architecture around this.  

Stable Plateaus

A stable plateau constitutes a stable interim state of an IT architecture, providing clear business and IT benefits associated with IT architecture of that plateau. Achieving a state that could be maintained even if the transformation is not continued, allowing to change the direction.

In the hollow-out approach, stable plateaus allow financial institutions to manage transformation in risk-minimized way and do not hinder introducing new capabilities. Stable plateaus should be designed after each major functional release and should be carefully tested. 

Abstraction Layer

Even before starting the CBS replacement program, financial institutions should isolate the current CBS platform with the abstraction layer and remove all tight coupling integrations such as shared databases, database links, point-to-point Application Programming Interface (API) calls.

This step is required to hide the CBS replacement activities, both on legacy and target platform, from the rest of the application landscape. 

Deployment Options

We at BCG Platinion have taken a more comprehensive look at possibilities to further de-risk a gradual approach to CBS modernization. To achieve this, it is important to reduce the probability of critical issues occurring during release deployment on production and, should these occur, limit the impact. For achieving the latter, two options are available: 

• Pilot approach for executing this option, functionalities are activated in total, but only for a small subset of users.

• Phased approach where the functionalities are divided into subsets, which are activated one by one for all users.

Migration

The first sub-release of phase two started with the migration of all services concerned with retail loan and card origination. After confirmation that these services were running stable, the standard payments services were migrated, excluding deferred payments.

This preclusion was taken to limit the number of transactions affected in the case where problems could arise. Additionally, we did not want to risk overburdening the production support team with too many different strings of the architecture at any one time. 

Activating the next release only when predecessors are stable

Once the two sub-releases were confirmed to be in working order, implementation of the final sub-release of phase two could be started. This comprised of customer and deposit accounts, and the deferred payments scope.

During the rollout of this and every preceding step, the bank retained full control of all proceedings and had the authority as well as the ability to immediately roll back to the old system in case of impending difficulties. This ensured that the bank could minimize any down-time, and fostered trust and mutual understanding between the program’s partners.