Banks are like a 1,000 mph car

Talking about risk and innovation in creating the world’s first 1,000 miles per hour (mph) car, is like talking about changing the core systems in a retail bank.

You just don’t do it or, if you’re going to try, it’s incredibly tough and challenging.

In fact, in retail banks, it’s even more challenging as the first issue is how to get the car up and running at 1,000 miles per hour then, once it reaches full speed, the focus is to keep it there as it then can never stop.

That’s why banks never change core systems, as the difficulty is how to change the engines on 1,000 mph car when it’s travelling at top speed, an analogy used many times in many contexts: changing the engines on a jet at 40,000 feet being the usual metaphor.

So how do you change the engines of the bank at full speed?

Well it has and can and is being done, but most of the time it’s being done badly.

You see, once a core system is in play, that’s it.  It’s in play.  It can never change.

You place all of your customers live onto those systems and then the focus changes to: how do you ensure this system never stops.

That’s why we talk about five 9’s – 99.99999% high availability, fault tolerant uptime.

Any downtime is visible y’see.

The customers notice.

They complain if an ATM can’t dispense cash one day or if the internet banking site stops for five minutes.

Imagine when this occurs for more than a day.

So banks just don’t do it.

They have the car up and running at 1,000 mph, and know that any slowdown will irritate their customers so they just keep the car running.

All the focus is upon operational uptime and business continuity. 

None of it looks for innovation or change.

In fact, once a core system is up and running, there is an issue with innovation.

Any new channel, like mobile, is a potential disruption to the core system. 

This is why new things are appendages to the core system.

And, as many banks core systems were developed in the 1970s, it is the reason why ATMs, call centres and the internet are all add-ons to the basic account processing in branch structures set up forty years ago.

Now some brave banks have been changing core systems.

I wrote about this the other day, when talking about the migration of Abbey and Alliance & Leicester to Santander’s core system migration and the Australian bank debacle of NAB and others.  Santander's problems with migration issues are well-known and I've been blogging about them for over three years now.

In the case of the latter, the change was introduced due to the mess of forty year old spaghetti.  In the case of the former, it’s Santander’s ambition to have all the global bank operations running on one standardised system.  Therefore, as they acquire, they transition each acquired bank onto their core system but at a high cost.

The cost to Santander is that their customers hate them, but they stay because it’s too difficult to switch banks and Santander offer great interest rates.

Another bank undergoing similar upheaval is the Nationwide Building Society.

Their three-year old project to move the bank onto a core banking platform from SAP has not been without issue but, so far, not much of this has hit the headlines.

Unlike Tesco, the latest example of a bank crashing its core systems during a recent migration project.

Tesco, who pride themselves on being good with customers, have just seen their reputation take a big hit as thousands of customers were locked out of their accounts.

In mid-June, Tesco Bank migrated their customers from the Royal Bank of Scotland’s (RBS) systems – who had been their banking partner for the last fifteen years – across to their own platform, as Tesco is now going it alone with their own banking licence.

The whole thing was messed up, with the bank initially saying it was a customer issue with Internet Explorer and that customers should be mindful of how they access the bank’s service.

This soon changed as 2,500 angry customers contacted the media.  Soon after, the big guns were rolled out, with CEO Benny Higgins saying that he would ensure any losses were compensated and that customers would be looked after.

They still got a lot of things wrong, e.g. Tony Collins wrote up a good list of the do’s and don’ts of the Tesco farce, but a few people may have missed something fundamental in this process.

Not sure if true, but someone did say to me the other day that they suspected the issue was migrating from a system where those who worked on that system would be redundant.

In other words, the RBS IT staff who support the old system that Tesco is leaving would have no interest in helping the process.

Sounds  a little bit unprofessional to me, but you never know.

Either way, moving a system from one old system to another is hard; moving a system from a base that is bespoke, specific and old, to a new system that is global, generic and bold is harder; and moving from a partner who you’ve divorced to a brand new shiny system is the hardest.

Maybe this is why Lloyds Banking Group is moving the HBOS legacy systems to their own legacy core systems.  No new platform, no shiny upgrade, just getting one 1,000 mph car across to merge with another one.

Still not easy but watch the headlines about Lloyds in September as the HBOS customers are migrated to their core system.

I’ll place a bet today that you won’t read lots of scary headlines about their migration.

It may be pretty dull stuff to move legacy to legacy, but it’s very safe and, for a bank running at 1,000 mph, that’s what many need.