Considering an overhaul of core banking systems is often likened to open heart surgery, it’s understandable why bank CIOs would want to stay on statins for as long as possible.
Bank IT failure, however, isn’t a theoretical possibility. Cases are frequent and costly.
An IT glitch on August 2015 rendered HSBC’s customers unable to send or receive funds. The system failure took 7 hours to fix and a couple of days to clear the backlog. In 2013, the bank’s branch IT in the UK failed, leaving many customers unable to access basic banking services.
The Royal Bank of Scotland has also seen a slew of IT failures in recent years. Last year, about 600,000 payments “went missing” due to a technical failure at RBS. A year earlier, the bank was fined 56 million pounds for a 2012 IT failure that left millions of customers unable to make payments. The direct cost of that IT failure was estimated at £175 million. A day after RBS paid the fine, another IT glitch prevented the bank’s customers from making payments for a window of 90 minutes.
In 2014, Lloyd’s customers were unable to make payments using debit cards and about 7000 ATMs were offline due to a server problem.
Bank IT systems are gargantuanly complex. A bank’s IT structure is like an onion, with a core and many layers around it of supporting applications. At the core is the source repository of information about customers, accounts and balances. Most banks have multiple cores for different products like Demand Deposit accounts, savings, securities accounting systems, trading, payments, and various loan products. Each core is surrounded by back and middle office systems, a corporate CRM, and are then connected to customer-facing applications.
In order to support advanced customer facing technologies like ATMs, debit cards, mobile banking or real time payments, legacy core banking systems need to be mirrored, processed on different servers and have the back end reconciled later. Multiple M&As, vendor onboarding and patchwork internal innovation through the years added layers of additional IT complexity and risk.
One large bank, for example, required 9,000 applications to keep its old core system running, as told by Mark Hurd, president of Oracle Corp., to a group of financial services executives in 2012. “Most of those applications are old and homegrown, and most of the people who developed them are gone,” Hurd said.
According to a recent survey from NTT Data, 41 percent of banks add new functionality to their core system through external and third party applications. 26 percent engage in significant changes to the core deposit system to support new functionality and 22 percent change little to their core system.
Only 8 percent are considering, or in the process of, re-architecting their core system and 3 percent are considering, or in the process of, a complete change to a new core system.
The threat of IT failure isn’t just periodic failures. It is the longer time to market for new features and products. This lag can lead to increased customer churn.
Upgrading core banking systems is a risky business, considering the huge financial commitment to the process. In 2011, AIB sued Oracle for €84 million, blaming it for the failed implementation of Oracle’s Flexcube core banking system. In July 2011, the Union Bank of California cancelled the implementation of Infosys’ Finacle Solution – almost two years after the program was initiated.
Cognizant estimates that 25 percent of core banking system transformations fail without any results while 50 percent do not achieve transformation objectives, as costs and implementation times double or triple. Only 25 percent of the transformations can be called successful.
According to Peter Olynick, senior practice lead for retail banking at NTT Data, banks looking to upgrade their core system should make sure they fully understand the business case and have a clear vision of their business goals.
A bank that wants to differentiate itself through technology and innovation should invest heavily in an agile and fast core, whereas a bank aiming to differentiate itself by being the lowest cost offering, can probably make do with mitigating the risk of an aging core system.
A main part of an IT renewal project is simplification, says Olynick. Many banks have thousands of different products, each with different IT demands, that add risk and complexity to the system.
Most banks don’t opt for a complete renewal of their core systems. Banks frequently choose to shrink the footprint of their core by moving data and applications to other, more modern databases.
Database firm MarkLogic’s platform, for example, can capture a bank’s various data streams, including from external sources, in real time, which then allows that data to be analyzed and used in other applications. This can be done without touching the core systems.
“I don’t see appetite for upgrading core systems,” said Sinan Baksan, solutions director at MarkLogic, adding he thinks the current set up of core IT surrounded by multiple layers will continue.
The only ticking clock, according to Baksan, is a skillset shortage for core banking systems. As fewer programmers know how to work with old programming languages used in core systems, like Cobalt, the maintenance cost of legacy systems increases.
Other ways of shrinking the core includes building APIs that allow any service to get access to the core in an agile and flexible way. This, in essence, serves to isolate the core and separate it from the services the bank offers.
There have been some successful case studies of core banking renewal. BBVA Compass, Zions Bank and Commonwealth Bank of Australia are among the well-known cases.
Infosys Finacle, Oracle Flexcube and SAP Banking lead the pack of modern core banking vendors. Other top hitters include FIS, Fiserv and Temenos.
Aging core systems might not spell doom and gloom for the industry yet. But the current state of bank IT will make it hard for the industry to keep up. Whether it’s building layers around the core, a complete swap out or a partial migration to a new core, something needs to be done.