Core banking systems dating from the 1970s are compromising bank performance. However, updating them is becoming less costly and risky.
Core banking systems (CBS) underpin nearly every major banking process. Think of them as the information technology that runs a bank’s central nervous system—the software and infrastructure that links services to business units, customers, and back-office functions. These systems not only drive the banks’ day-to-day operations but also serve as the core IT platform for new capabilities and growth. Yet many banks are saddled with underperforming systems and outdated architectures that barely support key processes, at a time when institutions face renewed pressure to tamp down costs and adjust to volatile conditions in a turbulent financial system.
The case for transformation
In recent years, banks have tried to hot-wire aging systems to improve their performance, but that’s becoming an uphill struggle. For many banks, replacing these systems may well be the best way to reduce complexity and support business growth. Until recently, such replacements gave many CIOs pause, since the magnitude of the change translated into high costs and high risks. But the processes and tools for CBS replacements have improved considerably, and research shows that banks that have rebuilt the CBS in part or in full have achieved measurable performance improvements over their peers.
Banks are struggling with outdated technology
Core banking refers to a bank’s basic functions, such as gathering deposits, making loans, and managing corporate cash. CBS—the systems that support this core—emerged with the introduction of mainframe-based transaction processing, in the 1970s. These systems allowed banks to coordinate their operations centrally, creating a dependable if rigid platform designed to handle large volumes of transactions efficiently and with minimal downtime. The systems served banks well until the past decade, when the IT environment changed markedly, and Web communications, network computing, and plug-and-play system design emerged as keystones of high-performing IT platforms. The core systems installed in the 1970s and ’80s are ill-equipped to support the range of functions, modularity, and scalability that today’s financial institutions need.
During recent years, merger activity and a changing operating environment have brought complexity to the breaking point. To cope, banks tacked on many new applications to address regulatory requirements, bridge system incompatibilities, and serve the customers they acquired through mergers. Meanwhile, the Internet has increased demands to deliver banking services over new channels, such as mobile phones. One private bank found that its old and unwieldy CBS was severely hurting its ability to control costs. Manual work-arounds and a burgeoning volume of custom applications ran up an additional €100 million in IT spending. Elsewhere, a rapidly growing bank dedicated to serving emerging markets fell behind its rivals in delivering online banking services. Its CBS platform—a mix of incompatible vendor packages and in house applications—made it hard to aggregate account data across the business.
Attempts to rebuild systems have foundered
Over the past decade, many attempts to replace systems wholesale went awry. Bank leaders, with plenty of other to-dos on their lists, often delegated the entire project—from planning to implementation—to vendors, removing themselves from the governance process. Vendors, however, lacked cultural context and often created architectures that didn’t fully mesh with business priorities. Dogged by cost, quality, and implementation issues, less than 30 percent of the first generation of CBS replacements succeeded. Systems tended to be inflexible, equipped to handle only a narrow set of functions, and needed costly custom fixes to update applications. Building such systems in house proved to be a difficult, resource-draining task that often cost organizations from €50 million to €300 million. Together, these factors put the overall business value of CBS transformations in question.
Healthy margins before the recession cushioned many banks from the need to act. A lot of CIOs rightly argued that rapidly changing technologies made it hard to know which standards, applications, and packages would endure long enough to pay off the investment. The financial crisis, however, tightened margins for most banks and forced a new look at the CBS and its potential to improve performance.
The CBS ecosystem is changing
In recent years, both CBS technologies and management’s understanding of them have matured. These developments have brought improvements in planning, project management, and platform design.
Smoother implementation. In early attempts at CBS transformations, leaders and technicians often learned by doing, raising the rate of failure. Today, global players have emerged out of what used to be a fragmented vendor market, bringing better IT capabilities and superior skills in coordinating large and complex projects. Next-generation CBS platforms, better able to deploy and integrate emerging technologies, have also improved markedly.
Faster delivery. Today, most transformations can be completed in less than five years, compared with a decade or longer when heavy customization, resource constraints, and unforeseen business requirements bogged down projects in time and cost overruns. Banks are investing more up-front time—on average, one-third of the total timeline for projects—in the planning and evaluation process, which helps reduce errors, build organizational consensus, and speed implementation.
Bigger payoffs. Studies of recently completed projects show that CBS replacements can help banks achieve higher asset and pretax-profit growth and better cost control. Of those institutions that made the transition, global tier-one and -two players operating in mature markets saw their their pretax-profit growth rate accelerate by up to 30 percent, and their IT cost/income ratios improved significantly. Emerging-market tier-three and -four banks that transformed the CBS experienced a 30 percent increase in their rate of asset growth. With the economics improving, the number of packaged solutions has grown by about 20 percent annually since 2004. That volume is expected to rise sharply over the next ten years as more systems reach the end of their lives.
Driving change from the top down
The most effective CBS implementations share similar characteristics: top-down planning, IT architecture development anchored in business needs, and a new partnership role with vendors. Companies can draw on a number of best practices.
Take a domain-based approach to architecture development
Banks have legions of disparate processes that focus on customers, lines of business, and day-to-day operations. These are often further segmented by region or business unit. Under the hood, however, many rely on similar software and deliver similar capabilities, such as managing customer data, handling transaction flows and ledger items, and preparing statements.
Next-generation CBS platforms take a modular (or domain-based) approach to architecture development. Because domains classify IT processes and their enabling applications by what they deliver rather than by business or process owner, they can help streamline the IT environment and standardize many common requirements. A bank might have 100 customer interaction processes that vary by product type, region, or income. Each might run separate software applications, even though the basic functional requirements may not vary substantially across the bank. Rather than housing multiple instances of the programming code required to run these processes, good CBS architectures bundle the common capabilities into sharable domains accessible by businesses that need the capabilities.
Get business buy-in by making IT serve strategy
Driven by business requirements and presented with basic business terminology, a domain-based approach helps cut through complex technical specifications and thus invites greater engagement between IT and business professionals. It also makes it easier for managers to examine the mix of domains in their portfolios. That in turn helps managers distinguish between activities, such as settlement processing, that are generic to most lines of business and might be suitable for standardized packages, on the one hand, and specialized, high-value activities, such as Islamic banking, where the market opportunity might justify customized design, on the other. The result is a simpler, more cost-effective and responsive architecture framework that corresponds to the needs of the business.
Recognize that vendor relationships work best as long-term partnerships
Because CBS replacements touch so many aspects of the enterprise architecture, selecting the right outside vendor can make or break a project. In the past, IT project managers, who often had little direct consultation with business leaders, commonly led the selection process. With the growing awareness that CBS is about fostering long-term business transformations, senior business and IT leaders are now more likely to be closely involved in the planning and selection process.
One multinational bank, for instance, devoted two years (one-third of the total project timeline) to planning the engagement with the vendor. During this period, the two partners carefully defined the business and IT requirements, established key performance indicators (KPIs) and performance milestones, and piloted a couple of small programs to test and refine the new architecture framework. Rather than viewing the vendor as a plumber engaged to hook up the pipes in the IT environment, the bank turned to a provider it could trust to serve as a full partner and adviser with specialized experience and a track record in managing large-scale projects.
Case studies: How two banks put CBS to work
Two substantially different CBS implementations illustrate how these principles can be put into practice. One involves a large, established European bank where cost and complexity issues needed urgent attention, the other a developing-market bank where growth and speed to market were critical for continued success.
Slashing complexity at a European bank
A leading European bank struggled with a tangle of applications that hampered its retail-banking operations. The bank’s organizational structure was decentralized around its city and regional branch network; the IT unit in each major metropolitan area supported several dozen local branches with core IT and back-office services. Because each center functioned more or less independently, there was little cohesion among the bank’s many locations.
This arrangement gave the bank flexibility in localizing its service. Nonetheless, the lack of unifying application standards created logistical snarls in satisfying bankwide business requirements, such as speeding time to market for a new corporate cash-management product or rolling out a new Internet security update. These problems in turn led to a logjam of custom fixes, which subverted the company’s cost structure. Despite a cost reduction drive, IT spending remained substantially higher than it was at the company’s peers. Its rivals were not only spending less overall but also more successful at directing funds toward new, growth-based initiatives.
The bank’s merger history added other constraints to the underlying architecture. Siloed data made it nearly impossible to gather a single view of large customers. While competitors went to market with integrated product suites, the weak linkage between the bank’s applications hindered similar product-bundling opportunities. What’s more, an aging architecture and legacy limitations made it hard to winnow out older projects as new initiatives came on board. As a result, the IT environment swelled: one review showed that the bank had close to 1,400 discrete IT initiatives, including multiple customer databases and several dozen reporting formats, more than half of which had budgets of less than €75,000.
An analysis by the CTO’s office showed that replacing the outmoded and poorly functioning architecture with a new, standardized CBS would close 75 percent of the total cost gap with the bank’s rivals. To that end, it would be necessary to eradicate redundant programs, shrink the number of applications, and reduce the number of developers, servers, and storage devices needed to support the legacy architecture. The remaining 25 percent would come from scaling back the IT portfolio, eliminating nonpriority initiatives, and ensuring that the remaining programs better served the bank’s strategy.
Having decided on a domain-based framework, the planning team brought together business and IT leaders from across the company to assess their business needs and to determine which IT capabilities could and could not be shared. The planning team translated the resulting outline into a new service-driven architecture. In some cases, pockets of bank activity required highly specialized product features or applications tailored to the needs of nontraditional clients. In these instances, the bank worked with its vendor to custom-build certain elements of the CBS system. For the vast majority of the bank’s needs, however, it could leverage the shared-domain approach to standardize application development, thus shaving costs and time.
Standardizing around a core set of banking applications allowed the bank to eliminate the redundancy that riddled its prior IT environment and to bring its cost structure back into line (Exhibit 1). What in the past would have taken a bank of this size nearly a decade to complete was now expected to take five years. In fact, just two years into the implementation cycle, the bank has already closed 50 percent of the cost gap with its competitors.
Targeting growth and agility at a Middle East bank
Several decades ago, a new bank set up shop in the Middle East. As one of the first financial institutions dedicated to serving the Arab market, the bank posted modest but consistent growth. Business took off exponentially, however, with the rapid expansion of Gulf economies in the 1990s. Over the space of 15 years, the bank’s revenues grew by 700 percent. Leveraging this success, it went on a building spurt, establishing new branches across the region in the ensuing five years.
The bank grew so fast that its core IT systems, developed in-house in the COBOL programming language from the early 1970s onward, struggled to keep pace. In recent years, the bank added other systems, such as payment processing, outside the norms of its architectural blueprint. When the bank wanted to introduce new products, such as flexible consumer lending or text message services, it therefore had to build them from scratch, so its delivery times were well behind those of its rivals. Similar problems hindered the bank’s ability to enter new markets, such as the rapidly growing Islamic-banking sector. The loosely cobbled software platform created isolated pockets of reporting data that made it hard for the bank to demonstrate that its financial practices complied with Sharia, the Islamic legal code.
Recognizing that the bank had reached the limits of its current software infrastructure, its leaders sat down with their strategic planners, who confirmed that without reforming core IT, the bank would not be able to stay on its strong growth path. The old system suffered from ad hoc governance: some systems were outsourced and others managed by an assortment of product and IT managers. The bank’s board therefore insisted on taking a larger, oversight role with the new CBS replacement.
Even so, the bank made a few early stumbles. At first, the board viewed the project as a straightforward IT implementation effort and directed the bank’s technology team to engage with its chosen enterprise package provider to get the job done. The provider immediately ran into difficulties. With the bank’s business and product managers largely disengaged, the initial architecture excluded key requirements, such as a unified customer database and an automated financial-reporting module to satisfy the new Basel II regulatory requirements. These omissions resulted in costly design changes. In addition, too much decision-making authority remained in the hands of the outside vendor, which was unfamiliar with the culture of the bank and alienated some people in it by attempting to push through changes without first proposing them to the affected parties.
When it was clear that the new plan wasn’t working, the board regrouped. This time, it focused on building stronger internal program ownership under the direction of a senior business leader. With a clearer project methodology in hand, the leader and his team worked with business leaders to develop a master plan that sequenced the CBS rollout to the bank’s growth priorities. They then linked the master plan to the core architecture and instituted a formal governance framework, with specific milestones and KPIs to track performance. The bank targeted gains of $235 million in net present value over ten years from a more flexible IT structure that would make possible faster responses to changing market conditions (Exhibit 2). That clear baseline allowed the team to structure the CBS architecture around a set of domains of particular importance to the business, including consumer loans, trade finance, and payments. These capabilities were especially critical, since they could allow the bank to deliver certain new products ahead of its competitors—fast-growing banks with similar internal growing pains.
In addition to making the bank more agile, the CBS replacement gave it a greater ability to adapt to changes in the banking market, including a major shift in the regional regulatory regime. With data silos broken down, the bank created an integrated, searchable customer database, something business managers had long clamored to have.
While a number of leading banks have begun to transform the CBS, many more are taking only tentative steps. This approach not only delays the inevitable but also can introduce new risks. Banks that engage a regional vendor for a pilot initiative, for example, often find themselves starting the selection process all over again upon recognizing that the vendor lacks the skills and project-management expertise for a global rollout. Although full-scale CBS transformations require significant up-front planning and investment, evidence suggests that the resulting efficiencies and growth more than compensate for the costs and management time required.