Banks need to stop keeping COBOL on life support

In my blog, I regularly call for banks to change their core systems. But banks do a great job of not listening to me.

Banks got into this technology mess because 94% of the C-suite team of banks are bankers with no background or experience in technology and they’ve layered tens of thousands of dollars’ worth of infrastructure on top of their rotting old core systems. How rotten are they? Well, in another amazing statistic, 43% of American banks’ core systems are written in COBOL, a computer programming language that often dates to the 1970s. The big problem for relying on COBOL is that the people who wrote that code are now dying or retiring. They’re old. The average COBOL programmer’s age is 50 and older, and the banks are asking guys riding around on the golf course in their retirement to come back for $1,000 a day.

How long can one expect to continue to run a bank built upon foundations of dust? The old concrete is cracking and split, and it’s no longer good enough to keep layering technology on top to disguise this fact. That’s just putting lipstick on a pig, as so many say, and the pig is darned ugly underneath.

noppawan09 - Fotolia

So banks got into this mess because people who don’t understand technology have been in denial for years about the issue. C-suite executives been told their bank could crash if the bank tried to switch their core systems, likening the process to changing the engines on a flight at 40,000 feet. It just can’t be done, some say. But I claim it can.

There are two ways to go: use a renowned technology company to do it for you or do it yourself. The former approach will cost the bank about 10 times more dollars and years because most of the renowned technology companies are also stuck using legacy systems. But at least you’ve got someone to blame if it all goes wrong. You can take them to court for breaking their service-level agreements, so that’s a good fallback. But I say it’s a dereliction of duty.

The better approach is for banks to meet this issue head on and deal with systems changes themselves. This is why I’m an admirer of the few banks that have taken up the challenge, such as Commonwealth Bank of Australia. Those few banks all seem to have a common approach.

It begins with cleansing their data. This task is normally built into an enterprise data architecture managed in a private cloud. An EDA is important as you cannot apply artificial intelligence and machine learning to a customer’s digital financial footprint if the customer’s data is held in multiple nodes and segregated by product lines — as is the case for legacy core systems. You need a single view of the customer to achieve AI effectiveness, and that mandates cleansed data in an EDA.

Once the EDA is in place, then the data can be fed into any engine, so you can change the engines even if you’re flying at 40,000 feet. This is the dream ambition of any bank with rotten core systems, and it should have taken place five years ago.