Mark Hurd, president of Oracle Corp., recently told a group of financial services executives an anecdote about a large bank customer that required 9,000 applications to keep its old core system running.
"Most of those applications are old and homegrown, and most of the people who developed them are gone," Hurd said during a February presentation in New York.
It was meant to be a cautionary tale about how little banks actually get for their bloated IT budgets, and how cranky and awful their legacy systems are. And though it was also a subtle pitch for Oracle's modern core system called Flexcube, much of it was a truism.
Many bank legacy systems were built as long as 40 years ago — but their age does not make them worthless. If the systems were really that bad, banks would make critical errors all the time. And, generally speaking, they don't.
But they do make mistakes, and these mistakes happen when increasing business demands drive decisions that exceed what these systems can do.
Unfortunately, those demands keep coming. Banks are under mounting pressure to increase profits by churning out newer products and services.
"The old systems run like the wind; they are lean and mean and fast in terms of core processing," says Steve Ledford, a partner at Novantas LLC of New York. "The biggest challenge facing banks that rely on these systems is the need to respond to change quickly, whether it is from marketplace dynamics and increased competition or regulatory dynamics, or the demands of a world that is moving faster."
Core systems are incredibly complex. In the largest banks they are vast machinery responsible for the financial life of the institution, including deposits, withdrawals, and all the channels that give customers access to their accounts, like the call centers, the branches, the ATMs and now Internet and mobile banking. Core systems can span continents, interacting with thousands of employees and millions of customers every day.
And as Hurd rightly pointed out, such systems have often evolved to encompass thousands of applications at the top global banks.
What's referred to as a legacy system has little standardization and actually varies greatly from bank to bank. (There can even be local variations within individual banks, experts say.) Legacy systems were created in the days before off-the-shelf software existed, or even the software shops that create such things today. They were designed for old mainframe environments, and they rely on sometimes antique programming languages and tools like COBOL, CICS and Assembler.
"These systems were designed to reflect the old reality of how banks did business in the '70s," says Bart Narter, senior vice president at Celent. Then, banks accounted for deposits and withdrawals in batches at the end of the day. Today, they are expected to operate in real time.
When banks consider replacing their legacy systems, they take the prospect very seriously. It can often take the largest banks more than five years to go through an upgrade, and it can cost hundreds of millions of dollars. Some recent core systems upgrades have even cost as much as $1 billion, says Jost Hoppermann, vice president, banking applications and architecture for Forrester Research.
On average the upgrades take 40% more time, and they are three times more expensive, than originally forecast, according to Forrester Research.
Upgrades are further complicated because banks can't have any downtime. And given the length of time it takes to make such changes, the business directives are often in flux, making a core upgrade project seem as if it's unfolding on quicksand.
"The business requirements that are in place at the end are often not the same as when they started," Hoppermann says.
Mergers and acquisitions are the key drivers for legacy system upgrades, experts say. Most of the top banks have merged numerous times with other banks over the past two decades, and each merger has required patching together disparate systems that can't communicate with each other.
Although banks often perform a kind of mating dance to determine which system will win out, it is usually the acquired bank that needs to make all the changes.
Legendary examples of botched upgrades include First Union Corp.'s merger with CoreStates Financial Corp. in 1998, during the first wave of bank megamergers. It was handled so poorly that CoreStates lost about 20% of its customers before the merger was completed. The banks encountered big problems getting the legacy systems to communicate with each other, which resulted in inexplicably blocked account access and payments not being applied to loans, among other problems.
(When First Union bought Wachovia in 2001 and took its name, the systems merger process was a study in contrasts to CoreStates. It took years to complete, but it has generally been lauded for its masterful efficiency.)