Competition in the banking industry is intensifying. As established banks seek to compete with digital-native neobanks and other fintechs, addressing aging legacy core technology becomes increasingly critical. With new advances in cloud-based technologies, this massive task is becoming more approachable. In this episode of Talking Banking Matters, our guests are Brian Ledbetter, a McKinsey digital banking expert, and Paul Taylor, the founder and CEO of Thought Machine, which provides cloud-native core technology to banks. The company is one of many in the open ecosystem of tech providers with which McKinsey partners in our banking technology work. The following edited transcript presents highlights from our conversation.
Matt Cooke, McKinsey: Brian, maybe we could just help our listeners navigate where we are today because, we’ve been talking about core technology transformation in banks for it feels like forever, but recently it feels like there’s a different impetus and an acceleration.
Brian Ledbetter, McKinsey: I would characterize it as the second era of digitization for banks. Banks come from a predominantly branch- and call-center-based customer service arrangement. If you needed something, you’d either ring on the phone or go into the branch and get it done. Then, with the advent of smartphones, we discovered that mobile and digital technology was the primary way to engage with customers, with branches and call centers as a secondary channel for more complicated service needs. And so we had a boom in people building apps and automated journeys, which banks hooked up to their existing systems.
Underlying this are a few basic problems that banks have always had. One is that that customer data is held in many different places. Another is that products are provided by a number of different systems. These systems are not consolidated, and when the banks put all this new digitization together, they did it with the technology they had at the time. And over time, those older systems have become obsolete. So banks are now at an upgrade point for both the front and back ends because they have accumulated this profound technical debt.
It’s still quite a complex problem, as it always has been, but today solving the core technology problem offers a lot more opportunity than it might have in the past, because the underlying technology is much more mature and powerful than it was when we started this digital journey.
Matt Cooke: Paul, do you want to tell us why you wanted to start Thought Machine and take on this challenge of core technology modernization in banking?
Paul Taylor, Thought Machine: A lot of the thinking behind Thought Machine came from working at Google. A big part of that was looking at how to build incredibly scalable, automated, robust platforms that could handle enormous amounts of transactional and customer data and do it very securely, safely, and resiliently, without a lot of resources.
I was also enamored of the world of fintech. So those two bits were there: platform company, cloud-native company and fintech.
I formed the company, had a few friends join, and we searched for a problem and looked at various things. We eventually came across what Brian described when talking to banks, and we thought, “You’ve really built a nice front end to a pretty shocking back end, and maybe we could help you with that.” So we said, “Let’s build that.”
So I thought these banks are trying to do AI, they’re trying to do customer service, trying to automate all their journeys. They’re trying to be safe. They’re trying to obey new regulations. And it’s all incredibly painful because of the back end. They’re building on top of something that didn’t want to be built on top of. We thought, “Why don’t we build a core banking platform and be platform people where we enable user experience, and we build that and then sell it to banks?”
Matt Cooke: Where are banks now, in terms of adoption? Do they feel they can do this themselves? Where are they on that journey?
Brian Ledbetter: Banks are a little bit bipolar about this whole thing. In the main, banks understand the value of modern technologies in getting the digital part of what they’re providing to customers to move fast, to provide new propositions, new functionality. They value modern technology for that. But they’re let down by their existing systems, which have built up for 30 years within banks like silt at the end of a river, with layers and layers of integration, products, configuration, and connections. The reason I say they’re bipolar is they really want to move fast. But I have to say it’s a bit exhausting for banks, because it’s a constant prioritization to try to inch forward in terms of modernizing the technology and pushing new functionality out to customers. We end up entertaining discussions about how they might bypass that problem and just go clean from the very beginning.
Matt Cooke: What does that mean? What would “going clean” look like?
Brian Ledbetter: I would say there is going clean technically and going clean product-wise. There are two types of really “unclean” things in the bank—at least two types. An average medium-size bank has probably 2,000 to 4,000 systems. If you do the math of point-to-point connections among them, it’s a lot of connections. So that’s one thing.
The other thing that’s a mess is products. Banks are really good at introducing products. They’re really bad at taking them away. An average medium-size bank has about 3,000 products on the books. By our reckoning, you need about 30 to serve a population like that of the United Kingdom. But if you try to get rid of the 2,970 other products, there’s always somebody left with one somewhere. Or if you try to delete it from the system, you have an unexpected consequence because there’s a chain of products.
Matt Cooke: And will they often have had their own systems built alongside them?
Brian Ledbetter: They will, but there’s actually an even worse situation, beyond having a separate system. This is going to be very technical, but the problem is that a lot of the products are manifested in the overnight batch cycle of the existing systems, which basically means that when somebody opens the product or they make a transaction of the product, it goes into a line item in the ledger. Then overnight, there’s a set of logic that transforms it into another product, and that’s how the customer understands it.
But all the code that’s in that overnight work is not normalized and understood in the ledger, which means that it’s hidden. And if you try to unwind it, it’s linked to a whole bunch of other very important things that happen overnight, and unwinding it is quite difficult. These two things take a long time to unpack.
Matt Cooke: So it’s easier just to leave those.
Brian Ledbetter: Yes, it’s almost easier to leave all that than to do something new and very selectively touch any of it.
Matt Cooke: How did banks try to solve this before there were options such as Thought Machine? Were they piecemeal doing this themselves?
Brian Ledbetter: There were choices. You could go buy a core banking system, which was traditional technology, like a relational database on a server somewhere with a bunch of functionality and workflow around it to make things work. And then you have to copy what existed in the bank into the new system.
But it requires you to clone what you had. And as I just said, the cloning is a mess because of all the point-to-point connections and all the product manifestations. It wasn’t a very flexible process, and you had to really plan it all out from the very beginning. And even then it was a multiyear journey, and you would discover landmines along the way.
Paul Taylor: Sometimes, when you look at a bank’s systems, you think they don’t get enough sympathy for the position they’ve been in. It’s something that people slightly ignore when they ask, “Why haven’t you gone to the cloud earlier?” It’s not that easy. It has to be a virtuous ecosystem whereby the cloud providers can provide the fundamental platform technology.
I’ll pick up on another point you made about product complexity in the bank. Let’s use your figure of 3,000 products in the bank but only 30 that are really needed—and even that’s a large number—and which a customer could understand, such as a car loan, credit card, debit card, a current account, savings account, all the usual things. We said if we’re going to do this and sell this to every bank, we cannot have a requirement that we need to change the platform code to run a new product in the bank. Because the burden on us or the bank, if we have to change our source code every time we want to mimic a product or launch a new product, is too high. It’s going to be too expensive, exotic, too slow, and everything else.
The alternative is some sort of limited product functionality whereby if you imagine a dashboard of various sliders and knobs, you can say, “The interest rate is this; the repayment period is that.” That will give you something that will build something that is recognizable as a “High Street” bank.
But that’s not going to do what Brian says. That’s not going to allow you to exactly clone the financial behavior of the products in the bank. There is only one answer to that: you need to write it in some sort of code.
We have a system of smart contracts that run on the platform, but they’re separate from it. They’re written in Python—super high level, so you need some programming experience to do it, but there’s no dependency on us or the versioning or anything else. This way the bank can create its own ecosystem of these products, and it can run them side by side with the existing products, and be sure that it’s the same [products and data as existed on its previous system] while ensuring they have the correct degree of power in the product engine.
And then once you get that done, you’ve solved two of the big problems. You’ve got universality, which means you could do all the products in the bank, and you’ve got configurability without reliance on the platform source code. That’s a huge part of the problem solved.
Brian Ledbetter: What you provide is something of a more flexible palette to be able to solve the problem—flexible not only to accommodate products, but also flexible in the other dimension, which is front to back. As I was saying, we have a front-end problem to solve, which is how do we introduce new digital products and services to customers. And we also have a back-end problem to solve, which is how do we get rid of these obsolete systems or simplify the connections. Your simplified palette and piggybacking off of cloud services allows you to much more easily solve both ends, front and back, at the same time.
Previously, Matt, to your question, people thought of this as a technology replacement, as opposed to a proposition build. What I mean by that is it was something that the IT people were going to take care of; the business didn’t want to know about it. What we now know is that you mustn’t consider it that way. You must consider how to solve both the customer-facing problem and the back-end systems problem simultaneously, so that you’re delivering something out to market at the same time as you’re doing the renovation.
Paul Taylor: I’m still finding myself looking in amazement at how some banks work. You look at a typical, large Tier 1 bank, and it will give you the illusion that there’s a mortgage and a few things, but these things split into different systems very rapidly.
One of the things we can offer is exact one-to-one product mapping, but do you want to do that? Let’s say you’ve got 100 different mortgage variants on offer. We could do that with one product that has a proper lever for fixed rate, length of term, repayment, penalty, fees, all those sorts of things, loan-to-value ratio. Put it all in. It’s all nice and neat because they’re all kind of doing the same thing.
If you want to make a change to the mortgage products, that’s a single change. I’ll give you an example. In the United Kingdom at the start of the pandemic, the government said that people could have a repayment holiday on their mortgages. In a system like Thought Machine, that’s a simple change: put it in, put it live the next day—repayment holidays, there you go, everything recalculated. This was not an easy thing for banks to do, so they effectively ended up having to make manual adjustments to every customer’s account.
Brian Ledbetter: It’s a very simple concept. Your contracts are interpreted on the go, which makes a massive difference.
Matt Cooke: Let’s step back a little bit and talk about what’s at stake here. Why is this so important today? What’s the scale of benefit for a bank?
Brian Ledbetter: Here’s the problem in a couple of dimensions. If I’m a High Street bank, I spend anywhere between £700 million and a couple billion pounds on technology every year. Of that, 85 percent goes to maintain what I’ve got. Just 15 percent of my spend goes to build anything new and valuable for the customer. On a year-by-year basis, it gets eaten up to the tune of 3 to 5 percent year-on-year, which means I’m approaching no money left for building any new stuff that the customers value.
Imagine next door I’ve got a clean-sheet challenger bank. It spends a lot on technology, too, but the proportions are completely reversed. Maybe they’re spending 15 percent on maintaining what they have, and they’re spending about 85 percent of it on new things. In absolute terms, it may look like the High Street bank is still spending more money because 15 percent of a billion is quite a lot of money.
Matt Cooke: And the challenger bank is not falling over the kind of legacy issues as well.
Brian Ledbetter: They have no legacy issues at all. So the problem with High Street banks is time is running out: to the tune of, say, in the next five to seven years, they will run out of discretionary spend to be able to build anything interesting for the customer.
They have to figure out how to continue to deliver and maximize their delivery to customers of new stuff: “How do I get buy now, pay later out? How do I address less affluent customers? How do I build something digitally reasonable for small businesses?” All with this giant millstone around their neck with the existing systems. In the meantime, the challenger bank is speeding along, outpacing them.
Matt Cooke: And delighting its customers.
Brian Ledbetter: The High Street banks do have brand trust, though, which is what’s saving them right this second. Maybe the challenger banks never get to brand trust that you get with more traditional High Street banks that have been around for hundreds of years.
Paul Taylor: One thing we need to realize in this is that the cloud isn’t one of two options that are viable. The cloud is the only option. Twenty years ago or even 15 years ago, it was viable to say there were two types of world: a traditional legacy mainframe world and a cloud world. But now there really aren’t two paths anymore. Every student graduating, everybody doing a project—it’s all cloud computing. They’re all learning Go and Python. We’re operating in the world of agile, continuous deployment. Well, who’s going to run the old systems? It’s becoming a smaller and smaller pool of people who can run the old technology, and that is a risk in itself, regardless of cost.
Brian Ledbetter: We talk a lot about this with our clients in terms of making use of cloud technology and how to balance the kind of old world with the new world. The first thing that makes a difference is to not think of it as a systems replacement, but to think of it as proposition development.
The other thing that makes a massive difference is education within the bank. The business know broadly they should be making use of the cloud, because they get hammered with that message all the time. But they don’t know what that means. They don’t know “What can it do for me? How does it speed things up? What functionality do I get automatically? How can I build things?”
So it’s almost like you have to get over two mindset hurdles in the bank for this next wave of digitization. First, it’s not a systems replacement, it’s an enabler; you’re building something new for the customer. The second one is being open to education and to understanding the new way of doing this and doing something completely different.
Paul Taylor: When we talk to banks, they say, “I get it, but what’s in it for me? What’s the benefit?” When you bring up their frustrations with their current technology stack, a classic one is disparate use of customer data. They say things like, “We’ve got these different systems, and we don’t have a single source of truth of the customer.” Another one that’s very quick to come up is inability to launch fintech-style products. They’ll say, “We wanted to launch a buy now, pay later product” or “We wanted to launch a credit card with a savings plan. But we went over it and said it’s going to be $150 million and it’s going to take two years.”
They try to compare the cloud world or the modern technology world to the old one, but there aren’t really any trade-offs. We’re not sacrificing resilience for speed of launch or anything like that. And it is all better. It’s just a long journey to get there.
Brian Ledbetter: I’ll make one more point about talent. Let’s look at skills in the marketplace. If we look at bank demand for skills, the most acute areas are data engineering and data science and these sorts of things. The amount of skills arriving on the scene in the United Kingdom relative to what universities and training schemes are able to push out is a very small fraction of what is predicted to be needed. So that’s the first problem.
The second problem is all those people work in the cloud, to your earlier point. They have to be able to operate in an environment they understand quickly and reliably, and that is a very immediate problem. Even if you were to question whether you get cloud-based stuff to work in your business, you don’t really have an option because of the skills you’re going to be able to get, which you’re competing for with everybody else in the marketplace. That is going to be a big, big driver of this next transformation.
Matt Cooke: Brian I think some people listening would be forgiven for not quite understanding where McKinsey fits in all of this. What’s the typical route, if you like, for McKinsey to be part of this conversation within the bank?
Brian Ledbetter: In the old days, clients used to call us up just to ask us, “What should we do?” Now they call us to help figure out how to do it, especially when they’re very constrained and there’s not an obvious path.
For example, [there is] the situation I laid out before, which is when a bank has only got 15 percent discretionary spend, and it needs to go to market with a number of propositions in order to grow their customer base, and they have a ticking landmine in terms of existing systems. What technologies should they use, and what should the road map be for them to balance, step by step, all of these requirements: growing the business, renovating the technology, and figuring out how to organize to get it done?
We generally don’t do the system integration. We do the blocking and tackling of the road map to figure out how to get stuff done. And then inevitably new technologies like Thought Machine have a role to play in that because the only way that you can move forward fast is to make use of the cloud and these kinds of technologies.
Generally, where we work together, we go together to be able to have that open discussion with the clients to try to figure out how to proceed and where the places are for Thought Machine versus other technologies or other techniques.
Paul Taylor: We find the relationship incredibly productive, for a number of reasons. We have to get into the conversation with each other and the banks to the point that we are discussing what good looks like for that bank, where exactly we are going to go, and how we are going to get there. I don’t know how many banks we’ve worked on together, but it must be dozens.
Brian Ledbetter: It is dozens. The partnership has come about in different ways. We end up optimizing for each other, really. We’ve built technology harnesses and frameworks and these sorts of things that let us help a client get going with Thought Machine quickly.
Matt Cooke: Can you give us a sense of how many have yet to begin this journey? Are any of those left, or is everyone at some point on the path?
Brian Ledbetter: Is everyone on the path? Yes, they’re all somewhere on the path because they recognize that it’s an irreversible trend. They may not know that their time to move has come, or how. But I think everybody’s mentally on the path.
It’s mindset that makes a difference more than anything else. The mindset is that in order to make the best use of these technologies, all the stuff and process that you have as a bank has to change, organizationally and process-wise. To make use of new technologies, you have to free yourself from the old to take advantage of the speed and flexibility you’re going to get. When you’re using cloud technologies, a lot of control is baked into the cloud. You don’t have a huge amount of degrees of freedom to mess yourself up like you used to when you were constructing everything with raw materials in your own data center—with operating systems, hardware, etcetera. Most banks’ surrounding processes are still geared for that, and they have to be radically thinned out to make use of cloud, to make use of Thought Machine, to make use of these modern technologies, for you to get the benefit.
The reason I say it’s a mindset problem is that style of risk management is in the DNA of employees of a bank and the way they’ve worked for the last 15 years. You’re now asking them to do something radically different: you’re asking them to put the controls in code, not put the controls in processes.
Checklists, for example—that is huge. If you don’t do something about that before you start using a Thought Machine or you start using cloud, you will bog it down to the point where you will think that Thought Machine can’t handle the problem. But the problem is your processes and controls around it are unsuited for these technologies.
I actually think it is a mindset issue within the bank that requires a radical rethink of end-to-end risk management in terms of change processes, service introduction, code release, and all this other kind of stuff. Unless you do that, you’ll crush the benefits you would get from introducing the technology.
Paul Taylor: There’s a wide range of approaches to how banks adopt Thought Machine. At one end there is “Let’s build it as close to the current functionality as possible” through to “Let’s build something like a challenger bank but at Tier 1 bank scale” or something like that.
Then you realize there’s a lot of traffic in here, and there’s a lot of detail, but there’s not anywhere near as many systems and people to run the systems and everything else as we might have thought. You also realize that when you get banks moving along those lines, it’s more successful when banks see it as purely a hidden back-end problem.
Matt Cooke: This is now a CEO or board-level conversation in a way that it wasn’t before. Also, it causes the CIO and perhaps the CTO to hold a very different seat within the organization. Talk about how this has been a cultural and talent management change over the last couple years and how executive committees and nonexecutive directors are reacting.
Brian Ledbetter: It has changed massively. If I were to do the analysis that showed the evolution of the profile of typical bank executive committee members over time—those people running business units—I’m pretty sure I would see a “technology-ification” of those individuals. They were technology professionals previously, in their more junior roles. Bit by bit, we’re populating business unit heads with people who understand technology.
So that’s the first thing that’s happening. What that means is that this subject is at least a bank executive-committee-level discussion always, because their question is “How do I quickly deliver new propositions and functionality to grow my revenue line at the same time as renovating these very tricky technology problems that we have in the back?” At every single executive committee meeting, that discussion is happening.
It’s a very short step from that to “What are our weapons to try to maximize the 15 percent and solve my back-end problem?”—which Thought Machine might be a part of discussing.
But increasingly they’re very comfortable, they’re very fluent in having these discussions at the board level as well and understanding how to trade off risk around these issues. I think a lot of nonexecutive directors have educated themselves over time.
Paul Taylor: I completely agree. I’ve seen the changing of the guard in multiple banks. When a new CEO role opens up at a Tier 1 bank, it is not credible to go into that interview and say, “I’m not really a tech person.” You have to be on top of the tech world, because of the threats and because the challenger banks and tech giants are there. You just cannot sit still in this world, so you have to be at least a very tech-competent person.
Similarly, new board members can’t go in and just say, “I’m an old-school city person. I’ll be fine; I’m great at relationships.” So as board members rotate off, we’re seeing far more tech-savvy people replacing them. It’s a very different mindset from ten years ago. The previous view was that technology is there to help run the bank, whereas now I would say the technology is the bank, right? It actually runs the bank. The executive committee is there to do strategy and all that, but the bank should be running automatically, and that’s not a strange conversation anymore.
Brian Ledbetter: I’ve been in a few board meetings over the last few months, and the same topic came up in every one: tech talent. The boards are pretty clued in to it. We’re having the discussion in the board at the level of ratios of personnel within the bank: How many code-committing engineers do we have relative to other personnel in our change teams? Where are the scarce resources? Where are they located? Where are we going to get them from?
Then the conversation changes to the environment we’re creating for engineers. Nonexecutive directors are actually having a very detailed discussion about that. Are we doing all we can to make this an engineer-friendly, inviting environment to maximize the number of excellent code-committing engineers? And how do we maximize that? Because the war for them in the talent market is acute.
Paul Taylor: Previously, in traditional legacy organizations, engineers were seen as being there to implement stuff that the business people wanted. That model is dying rapidly. It’s much better that the business people do the business in partnership with the engineering people building the systems.
A traditionally run organization is demotivating because people don’t have much of an impact, and they see that they’re not pushing it forward, not launching anything new. So any organization in the world that wants to attract the best talent has to realize that the way the best tech companies work is highly engaging and highly attractive to engineers.
Brian Ledbetter: Yes, this is critical.
Matt Cooke: That’s a beautiful segue to our final question, which is, What happens next? I’ll pass you a metaphorical crystal ball and ask you to think about the next five years. What’s going to be new in this space, and what are we going to see?
Brian Ledbetter: I think the adoption of these technologies will accelerate, because I think people are starting now to learn the big lessons, which are big, executive-committee-level lessons, as I said, around mindset, around unblocking things, and the way we think about risk and controls.
I think, to Paul’s point, we’ve gotten over a whole bunch of hurdles. The technology works, the regulator understands it, and so now we’re in acceleration mode, which in my mind, involves quite a lot of organizational issues and how we get things done. Many banks have changed the way they work to be much more agile, pushing technology up into the business and getting it closer to the front line.
I think it will accelerate because banks don’t have a lot of options relative to the disappearing 15 percent that I talked about earlier. That puts pressure on things to happen. Speed is super important for banks to get things done, and technology is one of the major speed unlocks you get.
Paul Taylor: I think putting times on things is risky business, but that’s different from saying what’s going to happen. I’ve said for many years that the cloud is a one-way street. You can go up it quickly or slowly, but there’s no reverse.
Matt Cooke: Gentlemen, thank you very much. Fascinating conversation.
On behalf of McKinsey’s Banking and Securities Practice, thanks for listening to Talking Banking Matters today. We’ve got a series of conversations planned, so we look forward to you retaking your front-row seat and listening to more industry leaders from the world of fintech, banking, and digital talk about their work shaping the future of this industry. Wherever you are today, thanks again for listening.
