Successful banks today realize that they are essentially technology companies operating under the rules of a banking license. The diverse portfolio of technology assets they manage should allow them to create a better customer experience, compete with digital native challengers, and cope with the myriad new regulatory requirements that add cost and complexity.

Yet the majority of banks find that their technology engines are sputtering and struggling to keep up with the competition. Many banks started with systems built more than 40 years ago, when the requirements consisted of accounting for products and business transactions between 8 AM and 5 PM,  only in branches, without real-time processing, and with customers defined strictly by their checking (current) accounts. Along came a succession of changes including regulated data and payments exchanges, different time zones as part of geographic expansion, near-real-time payments and always-on digital channels. Rather than propagate these changes throughout their systems, banks have tended to add new layers of technology to accommodate each new product, channel, function and geographic location. At one bank, for instance, because of the product and customer management system’s original design, a new customer cannot purchase a mortgage or card without signing up for a checking (current) account. This constraint is embedded so deeply that no one dares change it.

The payoff, when it works

So why bother modernizing the technology that delivers banking products and services? There are several reasons. For one thing, technology costs and process workarounds to patch aging technology consume resources that could otherwise go to improving customer experiences and innovating products. Batch and manual legacy back-office processing impedes the ability to deliver real-time customer services or straight-through transactions. Rigid systems that are difficult to update also have opened a door to nimble competitors with new business models. Each year, these issues hold back banks from lower cost-to-income ratios, higher growth and higher return on equity.

Even when senior bankers know they need to change, some worry this is a Sisyphean task, with slim hope of progress and no end in sight. They’re unsure how to sequence the massive changes involved, or map a path with certainty, or determine the most pressing issues to address, or even assess their organization’s capability to undertake the changes.

Fortunately, when banks fully or partially succeed in modernizing their technology systems, they have realized numerous benefits, ranging from operational efficiency, to a better customer experience, to reduced operational risk and greater speed and flexibility.

In Australia, Commonwealth Bank of Australia (CBA) went through a decade-long technology modernization, starting with the core all the way through digital technologies and deep analytics. CBA improved its cost-income ratio relative to its peers. Operating income increased at a faster rate than operating expense, with IT expense holding stable (see Figure 1). Another bank chose to modernize underlying technology practices, integration architecture and infrastructure. Previously, it had to wait for three monthly release windows to update its mobile app. After initial forays into modernization, this bank achieved release cycles of as little as three hours.

Figure 1

Beyond these benefits, the ultimate measure of success is how modernization enables a bank’s organization to rapidly adapt to changing market circumstances—with key technology systems contributing to its flexibility rather than being an obstacle to overcome.

New technologies beckon  

A new generation of technologies puts banking systems modernization within reach (see “A brief glossary of technical terms”). Whether open source, bought from vendors or rented as a service, these technologies enable architectures that are based on the following characteristics:

• Discrete and componentized. End-to-end services are assembled with pieces of technology performing discrete tasks, called microservices. Each microservice runs on its own individual and virtualized infrastructure, called containers, that are infinitely scalable in the cloud. They work together easily through application programming interfaces (APIs). By contrast, legacy technologies tend to consist of monolithic applications that function only through complex, customized add-on extensions deeply intertwined with and dependent on other systems.
• Easily served and consumed. Microservices architecture typically makes for a smaller size and scope of services. That allows independent and more frequent deployment, as well as easier scaling. By contrast, legacy integration patterns, such as service-oriented architecture, tend to have larger scoping, sharing of data and multiple process steps that must be orchestrated. That makes legacy architectures more complex to change and consume.
• Capital-light, scalable and elastic. Some technologies leverage hyperscale infrastructure from cloud providers in computing, data storage and security, and in business functions such as deep analytics. New technologies consume this infrastructure only when needed, without delay. That’s different from legacy platforms, which require tying up capital in infrastructure in order to scale up for every new requirement, often taking months to activate.
• Ecosystem ready. Advances in security and technology standardization, in particular APIs, allow a bank’s internal technologies to be part of a wider external ecosystem. Many banks, for instance, use open banking APIs to connect their payments systems across countries.
• Agile, automated and insightful. New technology now embeds automation that enables services to be built and operated by the same team (often referred to as DevOps)—and data to be recorded for analytics (known as telemetry). 

Combined with the virtues of being discrete and reusable, new technologies help organizations become more nimble. In addition, emerging technologies such as blockchain, artificial intelligence, augmented reality and eventually quantum computing could change the nature of banking in the future.

Four approaches to guide modernization

Banks cannot simply teleport to these new technologies; they need to modernize their architecture. Decoupling the modernization of each architecture layer is critical to the overall success of this endeavor (see Figure 2). Based on our banking technology experience, we have identified four broad approaches that leading banks have taken based on their starting point and intended destination. The right approach for a bank will also depend on the time, cost and risk that the bank is willing to incur.

Figure 2

Approach No. 1: Customer engagement and servicing

Most banks want to focus on the ways customers interact with the bank. A select group of banks are pursuing a modernization approach that focuses almost exclusively on the distribution layer and the customer engagement and servicing functions of the system architecture. Most of the effort involves building reusable core services that are available in multiple channels and that appeal to customers through their simple, convenient interfaces. Of all the modernization routes, this one often turns out to be the cheapest and fastest to market.

A caution about the fine print here: The approach requires a relatively modern and stable product and transaction layer. Most essential functionalities such as customer information, pricing, risk or origination should already be abstracted from core systems. Any differentiated capabilities required to better engage with customers would sit on top of current systems. The approach also assumes the bank has a modern, mature integration capability so that the customer engagement teams can work in Agile fashion even if other layers don’t. That level of maturity, abstraction and stability rarely occurs across all layers, which is why few banks undertake only a customer engagement modernization.

BBVA took this approach, identifying the top 50 reasons why customers would walk into a branch, then worked on ways that its mobile app could address these reasons through self-service. Now, 94% of the bank’s retail products and services are available as self-service transactions. Digital sales have grown to 41% of total sales as of the end of 2018, up from 16% two years prior.

Approach No. 2: Customer experience and product enhancements

This more common approach involves modernizing aspects of the distribution layer together with aspects of the product and transaction processing layer. It offers an opportunity to combine new products with improvements to overall customer experience. A typical approach is to define high-priority customer episodes, such as “take out a mortgage” or “resolve a fraudulent credit card charge,” and modernize one episode at a time. Customer and experience capabilities would be abstracted from core product and transaction systems, such as risk assessment, pricing or process orchestration. The bank would then build a set of modern, reusable services for the high-priority episodes.

To succeed, the current back-end systems must be modern enough to handle being refactored one function at a time, and must handle real-time transactions without posing serious downtime or security risks. Banks will often build a modern integration and information layer as part of this approach, but only to support new customer episodes. The legacy integration layer and other layers remain independent from such changes. The approach requires careful orchestration of architectural changes and often entails building foundational elements, such as a new customer information file. As a result, it is more complex and slower to deliver value than the first approach.

A large Italian bank wanted to speed up the time to market for its new products and services as well as further digitize its channels. However, the bank’s tightly coupled mainframe-based legacy systems made this difficult. The bank chose to modernize the distribution layer, build an integration layer based on APIs linking to the legacy core system and rebuild the customer information files. As a result, it reduced its product update time to market from 39 days to 19 days, at a lower cost. The modernized front end offers a common user interface that is easier for customers to use. And the rebuilt customer information files provide a complete view of the customer across business lines.  

Approach No. 3: Core focused

Transforming the core often stems from a bank’s dwindling ability to deliver further changes to customer experiences, core products or compliance requirements. This is a huge leap from the previous two approaches, as the bank concludes it needs to fully replace the core banking platform, often hand in hand with payments engines. Banks that have taken this route usually find their point of departure was a spaghetti tangle of systems unable to handle real-time transactions, with no visibility into how functions could be changed. Their front-end capabilities might meet current requirements for serving customers, but will lag if they do not tackle core systems issues. It’s complicated to untangle the spaghetti, replace each function with a set of modern technologies and propagate core changes into the other layers. Banks that pursue this approach will need a high degree of fortitude, discipline and engineering know-how.

Nordea, for example, aims to build a bank of the future, which will be easy to deal with anywhere and anytime, stable and trustworthy. Nordea has undertaken a multiyear transformation including a core banking system replacement across four countries, a new payment platform and consolidated and updated customer data. The transformation also includes an overall simplification of products, data and processes.

Approach No. 4: Front to back

This “all-in” transformation covers all layers of the system architecture at once. Banks rarely apply it to a fully operational Tier 1 entity, because the risks and disruptions are too severe. Instead, this tack typically applies to subsidiaries where the main bank built and tested a model bank in one country that can be deployed in another, such as DBS’s Digibank. Some banks test a new modern technology stack in a greenfield setting before migrating the core customer base onto the greenfield technology. When this approach succeeds, the entity being modernized can leapfrog others. It includes several traits: core systems architected to support Agile delivery of customer experiences through modern engagement and servicing systems; modern integration through APIs; and pervasive data and analytics capabilities.  

Openbank, the digital bank started by Santander in 1995, undertook a transformation after it identified in 2016 three areas where it needed to excel: payments, loans and investments. The bank relaunched in 2017 with a front end that is fully cloud-based, to increase speed, computing power, elasticity and open architecture at much lower cost. An open architecture also opens the door to connecting with an ecosystem of external fintech partners. Originally, the back end leveraged Santander’s legacy systems, but recently Openbank has been migrating away from the monolithic and mainframe infrastructure to a Temenos software platform. Now the bank will build different systems in a modular approach connected through an integration layer.  

Choosing the right approach hinges on a bank’s starting point, the main impetus for change—which could range from unsustainable costs to operational and regulatory risks—and the desired future state (see Figure 3). The bank’s ability to fund the modernization also comes into play. What’s clear is that banks can no longer afford to kick the can down the road.

Figure 3

Regardless of the path taken, modernization has become a persistent activity. Traditional incumbents, digital native banks, specialist fintechs and large technology companies all have accelerated efforts to capture new customers and serve existing customers better. They recognize that modernizing technology is an exercise in continual adaptation, not a race with a set finish line.

Marc van der Vleugel, Steven Breeden and Pascal Gautheron are partners with Bain & Company’s Enterprise Technology practice and Financial Services practice. They are based, respectively, in Brussels, New York and Sydney.