I was intrigued by a comment made by Anne Boden, founder of Starling Bank, on a panel I chaired the other day. Anne used to work for ABN Amro, AIB and RBS, and is now a fintech startup. Her comment went along the lines of: “I’ve now realised that the simple changes I needed to make in my old jobs would usually cost $3m or more, yet now I can make those changes for $3,000.”
I’ve heard this comment from another source, Monzo, where Tom states that they’ve built a full-service bank platform from scratch in months, with a team of 15 for $3m, that a bank has spent $300m to build with a team of thousands.
Equally, I recently blogged about Ant Financial, and the debate we were having between a senior banker and a startup. The debate went along the lines of: I guarantee that Ant hasn’t built a full-service platform marketplace for open market banking. It takes years to do that, and they’re too young and too inexperienced. The startup guy just said: Well, they’ve done it and there’s 40 Chinese banks using them.
This culminates in a question I was asked in another conference that really nails the point. The question was: Today, you talk about apps, APIs, analytics and marketplaces, Chris – won’t these all be irrelevant in 10 years, because a lot of the technology of 10 years ago is the legacy issue we have today?
Old thinking vs fast-cycle
The nub of this is old thinking. For most of my life, technology has been hugely capital-intensive, people-intensive and high cost, long-term developments. Banks would be investing millions over multi-year cycles, and would have high cost barriers that meant very detailed analysis of the return on investment and whether it was actually worth doing. Today, it’s all fast-cycle micro-developments that are cheap and easy and fast. However, if you’re stuck in the old structure cycle of capital and resource-intensive computing, you cannot adapt to this fast-cycle world.
That is the fundamental issue the old bankers were referencing in my opening statements: they’re stuck with old technology. Now, regular readers will know that I talk about this problem a lot – legacy systems – and how to replace them, but this is a different emphasis, because another dialogue started the other day about using cryogenic freezing to replace the old systems.
So basically, you convert functions and processes piece by piece to an app, API, analytic and then put that out into the marketplace as brand new and shiny tech. Eventually, you can do this through all the operations and find that you’re now in an open marketplace and have managed to shift off the old tech.
That’s a multi-year enterprise strategy again, which needs vision and leadership, but it can be done. However, there are two issues in a bank in dealing with this change:
The first is how to even contemplate the changes, as there are other things happening that must be done too, much of it regulatory and much of it that means those large-scale, old systems need to be changed first. These regulatory changes eat all the budget because, even if it’s just tinkering with a few lines of code in the old systems, it means multiple impacts across gazillions of lines of code. All of that needs checking and checking again before going live, so that’s why it becomes a resource-intensive change programme and costs millions. It’s why banks have little budget for innovation because most of it is eaten by those old systems, and as so many COOs say, the focus is just to keep the lights on.
Let’s consider that a bank can re-engineer its way out of that mess and start to move to open banking based on apps, APIs and analytics. What’s the problem then? Well, there is one and it’s a bit of an elephant in the room.
I’ve referenced it before and it’s about a new organisational structure based on moving from macro and monolithic to micro and empowered. Banks don’t like micro and empowered. Banks are control freaks and don’t like open and fast-cycle change. It needs to be slow and controlled … oh, and compliant. This means moving to a micro-services architecture – what today’s agile, cheap, fast and easy technologies demand – which is difficult for an institution that culturally is driven by control and compliance.
In discussing this, I usually say that a micro-services organisation has developer teams of no more than two pizzas in size. That’s a team that can be fed by two pizzas for lunch. If the team needs three pizzas, the team is too big; small, nimble, agile teams that can change things fast.A micro-services organisation has developer teams of no more than two pizzas in size Click To Tweet
Rejig code with empowerment
So let’s imagine a bank creates a micro-services developer organisation. Each of the teams in that organisation own their piece of code. Each team can change their code fast and replug it back into the architecture. They own the code and no one needs to sign off on it. And there’s the rub. Can a bank release its control freakery to allow legions of rocket scientist developers to do their own thing?
If it can, then a bank can reboot itself every day. There are some that do this: CBW in the US, the power behind Moven and Simple, and run by an ex-Google engineer, can update their core systems several times a week. But an incumbent bank? Really? Would an incumbent bank allow developers to rejig code with empowerment? I don’t think so, and for two reasons. First, the bank has a control-freak culture. Second, a bank has leadership that has no idea what I’m blogging about (another regular mantra). Maybe I’m wrong … let me know.
– This article is reproduced with kind permission. Some minor changes have been made to reflect BankNXT style considerations. Read more here. Main image: maxicam, Shutterstock.com