Is it easy to break the shackles of the past that’s dominated by legacy vendors? Actually, it is, says Chris Skinner. You just need to have a plan.

I’m always blogging about replacing core systems, open source the bank, change the leadership to one that gets it and just do it. I’m saying it so much that I’m finding myself boring. So let’s change tack. Who’s the vendor?

Not gonna name names, but I’ve had a few really fun discussions with banks in the last month, where they tell me that their problem isn’t their legacy – it’s their legacy vendor. They’re stuck with ABC Software and know they need to be off it, but it’s too ingrained. The vendor has more of a proprietary lock on the bank than anything they do internally, and trying to get the vendor to adapt their software to an open-sourced API and apps world is like pulling teeth. It hurts and it bleeds a lot.

Oh dear.

Now I’ve worked with and for a variety of software firms, and yes, it’s not easy to break free of the shackles of the past. Let’s say that I’m the CEO of ABC Software and we have 100 banking clients. I’ll bet you that 25 of those banks are the current version of our software, which, for the sake of this blog, we’ll call version 5.1. But how many are on 4.3, 4.2, 4.1? There’s even a group of six who are still on variations of version three. There’s even a few wee pains in the derriere who are on version 2.9 and 2.5. So the software firm is supporting all these different guys on their different versions, and you come to me and ask me to update the whole suite of software for the fintech world? Hey … give me a few million more and I might consider it, but right now I’m more concerned about what OMG Bank is doing with version 2.5 that has been so bastardised by them that I don’t even recognise it as ABC Software anymore.

Get the picture?

Now when I hear this, I always go back to basics. If the issue is that a core system needs replacing – whether it’s a bank proprietary system or one provided by a legacy software company – then the plan must be made to change it. How do you change a rotten core system? Well, it’s the same as how you eat an elephant – not that I eat elephants of course, but if I did, it’s one bite at a time.

So my plan would be to look at the end point I want to get to and then work out the bite-size steps to get there. I want to replace a core system? OK, first I need to get the data off the old system. Once I’ve done that, I can replicate systems with the data feeding the old system and the desired new one. The best way to get the data sorted out is therefore to put it into an independent engine. That way the content is independent of the processing, so I’ll never get into this handcuffed by heritage problems again.

In other words, my data migrates into a cloud-based structure, where applied analytics can be brought to bear. Add into this process a sprinkle of machine learning and artificial intelligence and boom, you’re rocking and rolling. Meantime, ABC Software can go deal with bank 2.5 and 2.9 for as long as they want. I’m outta here.

Postnote: A great illustration of the problems in this world are illustrated by the mad map of FIX Protocol versions and users. I thought this was a standard guys?

READ NEXT: Legacy people is why we use legacy systems

– This article is reproduced with kind permission. Some minor changes have been made to reflect BankNXT style considerations. Read more here. Photo: marekusz, Shutterstock.com

About the author

Chris Skinner

Chris Skinner is an independent commentator on the financial markets through the Finanser, and chair of the European networking forum the Financial Services Club, which he founded in 2004. He is an author of numerous books covering everything from European regulations in banking through to the credit crisis, to the future of banking.

1 Comment

  • Hey Chris. I enjoy your posts and I think you are right about the general trend of the move, but this particular post lacks an example to which bank can relate to:

    How would you choose “independent engine”? Let’s say I have all data in SAP DW, Terradata, IBM DB2. Which one of them is independent? Shall we move all data into one Mongo DB (it will be a disaster, don’t even think about it), or Hadoop?

    Once we move data into cloud, we have a new challenge – cloud vendor lock-in, and we are now relying on core systems being available during cloud zone timeouts. And what is the benefit of the move? We moved from legacy vendor, who were selling software to new cloud vendor, where we have to pays per use? And by the way, old old MIPS-based vendors used pay per cycle model, are we going back 50 years?

Leave a Comment