Executive Summary

Traditional banks are reinventing themselves to meet rapidly evolving customer expectations, to deal with constantly changing regulations, and to compete more effectively with pure digital fintech challengers. Many banks believe they can play a broader role in their customers’ financial lives. They recognize the importance of a seamless, personalized customer experience, leading them to embrace technologies like artificial intelligence and even to partner with competitors to enhance the value they deliver and their differentiation. The solution for this new era is multifaceted, but a key strategic element is to modernize the core banking system.

Today’s banking customers (particularly the millennial generation, an expanding market in terms of wealth) expect a lot. They expect their interactions with their banks to be seamless, frictionless, always on, and omnichannel. This style of interaction is more expected of upstart fintech companies and pure-digital banks, which benefit greatly from a lower cost structure and more contemporary information technology architectures using cloud, artificial intelligence, and advanced analytics. For banks that have been around for decades, the legacy systems that form their core banking platforms are ill-equipped to deliver the kind of customer experiences provided by newer arrivals in the financial-services marketplace.

Legacy platforms are still getting the job done – handling high volumes of mission-critical operations very well – and many banks are understandably reluctant to change the status quo. Their systems hold critical data and are used 24/7/365. If not done well, modernization risks compromising the existing business capability offered by the legacy core system.

But legacy platforms are challenging and expensive to maintain, in part because the technical skills required to maintain them are getting scarcer. Legacy platforms are not flexible enough to make banks agile, and they cannot handle a lot of the requirements for digital experiences. Moreover, legacy platforms are not designed for emergent regulatory initiatives like open banking.

Still, modernization must take place, in some shape or form. This requires thoughtful strategic planning and execution to address five key challenges:

• Core systems are heavily customized and often inadequately documented. Many legacy core platforms have been customized by internal and external IT teams over the years. Many of these customizations are not documented or have been documented with thin details. Also, they are rarely updated for any further changes after implementation. The knowledge generally resides with internal specialists, and that knowledge is lost when these people switch jobs or retire. Without an inventory of existing requirements, it is challenging to build and execute a modernization plan that assures ongoing business functionality and operations.
• Legacy systems typically don’t operate in real time. Many legacy systems process transactions in a batch mode during an End of Day process. Customer balances, then, are only updated at the end of the day, and many legacy systems have shadow balances instead of real-time balances. Systems that interface with a legacy core are architected to receive and process data via batch rather than real-time. Re-architecting the entire ecosystem, which is interfaced with the core banking system, can be a challenge and needs careful consideration. 
• Business rules are usually hard-coded, not parameterized. Computation of interest, charges, fees, and withholding tax are generally business rules that are hard-coded, and the only way to implement changes in business rules can is by modifying code. The costs and time to implement change are high and lead to loss of business opportunities and, sometimes, loss of customers. Modern core systems, on the other hand, allow business rules to be configured through flexible parameterization and a relatively simple user interface.
• Difficulties in meeting market expectations. Customers are increasingly accustomed to great digital experiences in sectors like retail, hospitality, and travel, and they expect the same level of experience from banks. Many fintechs and modern banking systems offer capabilities like seamless account onboarding, real-time balances, and contextual offers, among others. All customers also expect data privacy and security when transacting with any kind of financial-services provider. New standards like open banking will require banks to open their core systems to enable other banks, fintechs, and third parties to access customer data and account information to the extent permitted. All of these require core systems to offer functionalities through APIs, which third parties can consume. Legacy systems cannot readily offer extensibility of their core systems – another reason that banks using legacy core applications risk being left behind.
• Meeting dynamic regulatory requirements. Banking is heavily regulated, and changes to regulations occur often, making dynamic core systems that can be modified quickly that much more important. Required functions like “know your customer” checks for customer and account onboarding, sanction screening and anti-money laundering checks during transaction processing, and reporting to internal and external stakeholders require data to be stored and accessed seamlessly. Legacy applications store the data in file formats that are difficult to access and modify. 

The bottom line is clear: Banks need to overcome the challenges with legacy core systems to stay relevant. It is a difficult decision to replace core systems given the costs and the associated challenges to modifying the ecosystem. 

Banks with legacy systems have several choices when it comes to the modernization challenge:

1. Modernize legacy code. Legacy code is difficult to change (dated technology, poor documentation, and a lack technical skills specific to the legacy code). Plus, mission-critical processes run on core banking platforms, so care must be taken in handling legacy code. A developer may change the code without understanding the dependencies and that may lead to undesirable consequences. Banks running core banking applications built on mainframe technology are saddled with this legacy code. They get little or no support from vendors or OEMs and are mostly dependent on their in-house IT team. The knowledge is usually with the SMEs. Mostly, little or no updated documentation is available.

Here’s an example: A bank running a legacy teller application on a mainframe realized that the amount fields on the UI were stored in an encrypted format in the backend database. But the bank did not have the decryption logic and faced a significant challenge to migrate the data when it undertook a core banking transformation exercise. It might have been appropriate to rewrite or refactor that piece of code in the legacy application, which would help in the maintenance of the existing application. However, a proper analysis of the particular application is required to understand the implication of the change being taken, which is a challenge if there is no appropriate existing documentation available.

Here are some of the legacy core banking application areas that could be considered for modernization:

User interface (UI): UIs on mainframes can be considered for modernization without replacing the back end. Modern web technologies and cloud native architecture can be leveraged to replace the UI.

Batch: Batch processing represents 70% to 80% of the workload on mainframes. Significant savings can be achieved by reengineering batch workloads.

APIs: Consider exposing monolithic legacy code. Compatible integrators can be used to expose mainframe functionality as services via APIs.

2. “Big bang” modernization. For some banks, a complete transformation program that replaces the legacy core with a modern core banking system is the best approach. Usually, the legacy estate is dotted with multiple applications and product processors handling different aspects of a business process. Depending on the size of the bank, the planning phase for this kind of modernization could last anywhere between three to 12 months, and the execution will require 18 to 36 months. It’s critical to articulate interim deliverables, through minimum viable products or proofs of concept, to ensure that there no surprises at the user acceptance testing (UAT) stage.

A big bang modernization requires thorough planning to ensure that all aspects are considered, including:

• Digital capabilities
• Number of business products
• Volumes – to size the hardware
• Non-functional capabilities
• Data migration – including a history of the data to be migrated
• Integration aspects
• Data extracts, reports, and customer communication
• Training end-users – A challenge if there are many branches spread across large geography.
• Deployment/cut-over timelines – If the volumes are high, the cut-over window may be longer

3. A progressive transformation. A phased, progressive approach is particularly helpful for large banks dealing with a legacy estate and numerous banking application catering to various business lines, capabilities, products, and processes. An example: A loan life cycle may require multiple applications for credit origination, disbursement, amendment, interest accrual, repayment, delinquency, and customer communication. When the legacy IT estate is complex, a progressive transformation helps ensure a better allocation of resources and budgets and a better outcome.

A progressive transformation could entail:

• Rollout of a new core banking system through selected modules (business capabilities)
• Rollout by branches (mix based on the size of the branches)
• Rollout by geography
• Rollout by customer category (e.g., retail, corporate, small- and medium-sized businesses, high-net-worth clients)

Extend the core using APIs (Application Program Interfaces) and microservices. Many banks have developed their core banking systems over many years, using built or bought source code, an approach that provided differentiation in the form of unique products or services. Some of the core systems are well engineered to handle large transaction volumes or numbers of users, offering horizontal and vertical scalability. Moreover, if banks in this category have not experienced any issues in their run operations, the investment in modernization is a difficult decision. These banks could consider extending their core system leveraging APIs/microservices to rationalize their core solution or offer digital solutions to their customers.

Microservices allow non-core functionality to be moved a different layer. For example, a bank enhanced their core system to run credit checks on prospects, a processing load that occasionally damaged core system performance. Moving the credit check function to a microservices layer improved the performance of the core significantly.

Expert Guidance

Decisions to address the core banking system modernization are never going to be easy. But they should be done, and the effort begins with documenting the requirements and capabilities required to enable and support the future ambitions of the bank. It’s essential to have a real understanding of the kinds of business a bank wants to handle – and the kind of customers a bank wants to serve. And it’s essential to understand the relevant regulatory environment and (desired or mandated) open banking capabilities. The resulting vision of the future state of the business can guide the development of a target operating model and an IT architecture. With those ideas in mind, banks will be better equipped to think about, and choose, from the modernization approaches outlined above.

Wipro has assembled a dedicated team to handle this kind of analysis and work: Core Processing Transformation (CPT), which focuses solely on helping banks evaluate core modernization options and provides an independent and impartial view of the choice of platform that serves the best interests of the bank.

Learn more about Wipro and the Wipro Core Processing Transformation team by getting in touch with us.