Will the last COBOL guy turn the banks’ lights out?

I regularly blog about the same subject, namely CHANGE YOUR CORE SYSTEMS.  Banks do a great job of not listening to me, but that’s because they’ve caught themselves in Catch 22: screwed if I change them and screwed if I don’t.  How did they get into this mess and how can they get out of it?

Well, there is a way but most banks aren’t taking this way because they’re led by bankers who don’t get technology and don’t know how to implement digital transformation.  94% of the C-Suite team of banks are bankers with no background or experience of technology.

This is how banks got into this mess, as they’ve layered tens of thousands of dollars’ worth of infrastructure on top of these rotting old core systems.  How rotten are they?  Well, in another amazing statistic, I found that 43% of American banks’ core systems are written in COBOL, often dating back to the 1970s.  The issue that raises is that the people who wrote that code are now dying or retiring.  They’re old.  The average COBOL programmer’s aged is 50 and over, and the banks are asking guys riding buggies on the golf course in retirement to come back for $1000 a day.  This is the issue.

How long can you 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 it’s darned ugly underneath.

So, banks got into this mess because people who don’t understand technology have been in denial for years about the issue.  They’ve been told that if the bank tried to switch their core systems, then the bank could crash as it’s like changing the engines on flight at 40,000 feet.  It just can’t be done.  But I claim it can be, and I can see some banks that are doing it.

At that point, there’s two ways to go: use a renowned technology company to do if for you, or do it yourself.  The former approach will cost the bank about ten times more dollars and years, because most of the renowned technology companies are also stuck with legacy, but at least you’ve got someone to blame if it all goes wrong.  Oh yes, and you can take them to court for breaking their service level agreements, so that’s a good fall-back.  But I say it’s a delegation of duty.

If a bank has allowed itself to fall into the trap through years of core systems change denial, then it’s time for the bank to stand up to the issue and deal with it themselves.  This is why I’m an admirer of just a few banks who have taken up the challenge – such as Commonwealth Bank of Australia – and dealt with it themselves.   They also all seem to have a common approach.

It begins with cleansing their data.  This is normally built into an Enterprise Data Architecture (EDA) managed in a private cloud.  An EDA is important as you cannot apply artificial intelligence (AI) and machine learning to a customer’s digital financial footprint if their data is held in multiple nodes and segregated by product lines.  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 then 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 should be an action that was taken five years ago.  If your bank still hasn’t started on this path, then for heaven’s sake do it now, before the last COBOL programmer turns the lights out.