Banks deliberate tech vendor cycle

By David Beach | 18 February 2019

“At what point should a bank move away from a traditional vendor? The answer is probably at the point at which the amount of change you want to put through the platform is being slowed down by the vendor’s change process,” says Michael James, head of technical architecture in financial services at Altus Consulting.

“You might tell a mid-tier bank that it’s better to build it yourself - and it might be widely recognised - but then the bank would have two years of money going out and nothing coming in, even before the tricky migration happens. It’s a terrifying prospect and a very brave person who decides on that course,” says James.

‘Bravery’ would fall under the remit of the innovation office at banks, according to Benoit Legrand, chief innovation officer at ING. Speaking on the sidelines of FinovateEurope, Legrand commented on his own experience of system change.

“It comes back to the inability of human beings to be open to change,” he said. “Imagine you’re a 58-year-old IT professional who’s spent the last 30 years building a tech stack that you know precisely how to works and you feel a degree of safety that you can change it whenever regulation changes – it all goes back to psychology 1.0.

“If you suddenly have a new external tech stack that you just plug in and are totally dependent on an operation in Germany or Italy, you might question why you have less control. There’s no incentive in-built into human beings to embrace change.

“When I was head of private banking and investment products in the Netherlands, I switched off 112 spaghetti IT systems which managed our investment product into two systems in 2007-2010. It takes courage particularly when you see the downfall of some banks who’ve moved from one system to another. You can perhaps do it differently, but it’s important to do it in an orderly, calm way, taking your time otherwise the cost might be too high,” he said.

A more recent tech re-build – that of CYBG’s iB platform using RedHat’s open-source container infrastructure – was designed to give the banking group’s developers greater control to build on top of the Red Hat’s OpenShift Container Platform.

Tim Hooley, chief technologist at Red Hat - the firm supporting the build - believes external vendor dependency has put some banks at a disadvantage.

“I think firms that have traditionally used vendors are in a tight spot, because they can only innovate as fast as their vendor allows them to,” says Hooley.

Problem management

Not only does Hooley, a former head of IT at Goldman Sachs, think many incumbents are at the mercy of core banking vendors and their processes, he also thinks that banks must fight to have issues resolved - waiting weeks if not months.

“Banks have to get their requests to the top of the vendors’ list, get them to implement it, and to be honest, a lot of the core banking vendors are at the very early stages of modernising their platforms.

Red Hat’s products are open source, meaning that while the firm’s engineers work with clients, they also create a “community” support system whereby each client can operate with other software provides.

“From my experience at Goldman as the CIO of a group, I’m familiar with the continuous integration, continuous delivery aspect of software, where, traditionally with monolithic architecture, you would do a release every three to six months - it was slow, difficult and expensive,” says Hooley, who spent 20 years in the Goldman Sachs IT function.

CYBG will run its microservices and middleware in Red Hat’s OpenShift Container Platform; a way of working that Hooley believes is optimal for banks today.

“The scalability, the security and the operational support are all provided by the infrastructure allowing the CYBG developers to build the customer value-added features on top in minutes where it used to take three weeks to get their environment set up right.

“[The open-source container platform] gives CYBG, who have significant in-house development capability, a real edge at getting stuff to market quicker,” says Hooley.

Altus’ James had similar experiences during his time at Nationwide which at that time operated an Unisys platform written in Assembla.

“There was a scenario at Nationwide when some time previously the only Assembla coders decided to jump ship and start their own company and rake in the money which made change incredibly expensive.

“When those developers were still around, the pace of change on the system was very fast because you had the experts in the room. But then you had to take queries to Unisys and you began talking minimum spend, release cycles and delays. Aligning all of those things was just a nightmare,” says James.

It is also limited by a developer talent shortage due in part to banks’ appetite for vendor solutions as opposed to fostering an in-house developer culture as CYBG has done, Hooley says.

“CYBG has this strong developer culture which a lot of firms who have traditionally been dependent on vendor platforms just aren't going to have and are going to struggle to get.

“One of my big concerns about the industry is that there isn’t a surplus of good developers. Many firms will struggle to hire developers with the skills and expertise to go in-house,” he says.

While Hooley believes many big banks could benefit from working in an open source way, he admits in-house is not a “panacea”, something Altus’ James is quick to agree with.

“Small to mid-tier banks would struggle to cope with regulatory change and would benefit from a vendor who is multiplying updates across several other banks in its network.

It may be why many banks have turned to investing in separate fintechs, says Hooley, over traditional vendors.

“The big vendors - and the same five or six pop up in client conversations - are being challenged by a number of startups like Thought Machine and Tenex who are building microservices and container based core banking platforms,” says Hooley, commenting on the news that Goldman Sachs has recently injected $20m into the API based HSBC-backed Bud platform.

For James, there is a compromise between vendor-dependency and long-term technological sustainability in-house and that is utilising a core banking vendor platform that does the very minimum; allowing for greater flexibility in middleware and front end while retaining the benefit of a constantly updating core banking platform.

“That way, you could get some economies of scale and reduce the impact of the platform,” says James. “A CTO or CIO who is debating when to move away from a vendor platform and do it themselves, it’s a massive leap to shift it and years to build without ROI.

“They’ve first got to build a delivery capability for two years before they get something at the end of it because they’ll be starting from scratch. That is a massive thing to do for someone who’s already established, and migrations in themselves are painful and fraught with danger.

“The better option may be to suck up a fintech who’s built their own platform and not yet decided upon how to commercialise it,” says James.

Become a bobsguide member to access the following

1. Unrestricted access to bobsguide
2. Send a proposal request
3. Insights delivered daily to your inbox
4. Career development