Can banks change their control freak cultures?

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 start-up and 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 $3 million or more, and 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 $3 million that a bank has spent $300 million 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 start-up.  That debate went along the lines of: I guarantee that ANT have not 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 start-up 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 ten years as a lot of the technology of ten years ago is the legacy issue we have today.

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 which meant very detailed analysis of the return on investment and whether it was actually worth doing.  Today, it is all fast cycle micro developments, that are cheap and easy and fast.  However, if you are stuck in the old structure cycle of capital and resource intensive computing, then 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 as 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 multiyear 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.  Those regulatory changes eat all the budget as, even its 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 is why it becomes a resource intensive change program and costs millions.  That is why banks have little budget for innovation because most of it gets 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 have referenced it before and it’s about a new organisational structure based upon 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 microservices architecture – which is what today’s agile, cheap, fast and easy technologies demand – is difficult for an institution that culturally is driven by control and compliance.

In discussing this, I usually say that a microservices 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.

So let’s imagine a bank creates a microservices 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 they can, then a bank can reboot itself every day.  There are some that do this. CBW in the USA, 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 for two reasons.

First, the bank has a control freak culture.  Second, a bank has leadership who have no idea what I’m blogging about (another regular mantra).

Maybe I’m wrong … let me know.