Welcome to the

Banking Blueprints
Podcast

Where we navigate the future of banking

S1Episode 4 (Part 2)

The challenges and strategies for core replacement in banks (Continued)

Banking Blueprints
Banking Blueprints
The challenges and strategies for core replacement in banks (Continued)
Loading
/

In this episode of Banking Blueprints, we continue the conversation between our host, Dharmesh Mistry, and our special guest, Leda Glyptis, an icon in the banking industry and author of Bankers Like Us. They continue their discussion on topics like exploring a rip-and-replace approach to code modernization, the need for a unifying architectural direction in modernization efforts, and lastly, the emergence of a gradual transformation as a new strategic approach.

Transcript

BW: Welcome to the Part 2 of Episode 4 of Banking Blueprints. Today, we will continue the conversation from Part 1 between our host, Dharmesh Mistry, and our guest – Leda Glyptis. She is an icon of the banking industry and the author of Bankers Like Us.

Dharmesh and Leda dive into how to navigate the ever-evolving, complex landscape of banking technology and discuss the replacements of banks’ cores in detail.

We hope you enjoy the 2nd part of this conversation!

DM: Yeah. I mean it’s fascinating really because I think, normally organizations kind of get kind of global, global when I say enterprise-wide kind of buy in on something that’s new and exciting. But core replacement isn’t new and exciting. It’s scary and hard, right, Because I do, I mean I was part of a business process reengineering project in the heyday of that, kind of trend, but it was new and exciting.

LG: I remember those.

DM: Yeah. I mean, it was, it was fun because you were actually told, you know, reinvent how we do things, make it better, faster, cheaper, you know, let the technology do the work so we can spend time with the people that are there, Right.

So we had, you know, representation from across the bank and, you know, you feel special to be part of the project. You’re excited about changing the bank. And then suddenly it fizzled out because, you know, actually, you know, some of the big changes that we wanted to make, right, were deemed risky or they were deemed extremely hard or very expensive.

And all of these things came into in the way of actually doing, the one thing that this project was set out to do was to reinvent the bank, right? And it wasn’t for replacement directly, right? What I’m saying is…

LG: This resonates, yeah, resonates so much right now. I, I started life in a, in a process business process for engineering function. And it was a revenue protection function, right?

So institutional clients when they’re unhappy with how it works, it’s not like I leave my High Street bank and they don’t even notice, right. So the share of wallet that each client represented meant that it was, it was so important to understand how we can use people, process and technology to be compliant, but also to do a better job for them.

And then once you fix it, when you rolled it out to the others and as you say, it was an honour to be a part of it, you had everyone’s eyes on you.

Because of course, clients are it’s clients and regulators, right? That these are the two sets of people you have to keep happy.

But as I said at the beginning, the minute your solution started hinting towards core replacement it, it fizzled out. You were always encouraged to find a different way to the extent possible.

And sometimes you would create a parallel infrastructure in order to service these needs. And of course, that adds operational and cost complexity to your technology estate. And Fast forward 10-15 years on, because you and I have been doing this work for quite a long time, right?

Every time we didn’t touch the core, but created either a workaround or a parallel database or a parallel infrastructure that would always plug back in and reconcile into the general ledger but would create these like these alternative intraday reality.

We added to the complexity of what needs to be changed now.

DM: Yeah, yeah, yeah. So I mean, I guess look, you know, so far we, we kind of agree that core

replacement is something that’s complex, is something that’s scary when you’re involved in the project. You know, we know it’s expensive and we know it takes time, etcetera, right?

Is there any other avenue that banks can take? You know, do they just have to bite the bullet and just say, look, we’re going to have to rip and replace this aging technology or can they do anything else in your view?

LG: So I think even the language of rip and replace is aggressive. And, and I think the key to, to this is exactly what we were talking about earlier. You never replace the core from a standing start.

You never, you know what we should do this year, Dharmesh? We should rip the, the core out.

It’s always in the context of pressure, either positive pressure, ambition, geography, expansion, new verticals or uncomfortable pressure, regulatory pressure, something going wrong your competitors getting ahead of you in the game.

So, in the context of that pressure, there will be a strategy that will entail quite a lot of detailed views around where the architecture and the infrastructure needs to be.

So in that journey, I firmly believe that there is no choice but to have a very different core infrastructure in 50 years time. And you know, I hadn’t said COBOL yet, so here it is.

There are components of our bank’s infrastructures of like almost 50% of all transactions are carried out on technology from the 60’s. As we move to a real time world with real time liquidity management requirement, it is not designed to be able to do that.

So there is a world where we’re going to have to move to a a different set up. But let’s let’s be honest with ourselves, why are those mainframes still here?

Because in terms of built in redundancy, they’re the cheapest way of securing ongoing service and they work. So only a fool would rip it out to replace it with something rashly. But we also know that only a fool would believe that we will be able to have non-real time reconciliations across the board in 25 years’ time.

So how do you get there? The first thing is you let your business drive, your business drivers drive, the geographies you play in, the verticals you play in, the types of services will you play in will dictate what you need to do imminently because you’re not going to be compliant or you’re not going to be competitive.

And the things you can do more slowly. The second piece is accepting you need to get there. What does your broom look like?

Because nobody will replace everything all at once, and no organization replaces nothing in any given year. So how do you sequence it?

And how do you manage both the risk and your risk appetite in that journey?

And for some it is parallel running of different cores with the intention of switching something off. For others, it’s hollowing out. For others, it’s modernization around the core.

I heard people Speaking of mainframe as a service and at first, I laughed to be honest with you. But then it’s like actually it just shares the load of that transition with your chosen providers. You know what, well done you.

I think the, the realization that we can’t hold on to what we have forever, in fact, yeah, for a pretty short time frame of a decade and a half, two decades is, is sinking in the ways there need to be aligned to your budget, you risk appetite and the realities of your market.

DM: Yeah. I mean, it’s interesting, isn’t it?

I mean, we, there’s some analogies about, you know, core replacement being like, you know, replacing a heart while the patient’s still awake. But, but actually, if you have a heart attack, you know, a major crisis or something, then what you actually do is improve the heart. You don’t replace it.

You actually put in some new valves or whatever it takes, right, or, or a pacemaker to bit make it beat better. But very rarely does somebody actually get a full on heart transplant if they’ve got a heart problem, right?

And, and what you’re saying and then you know…

LG: Yeah, it’s a very valid point. And I think it’s fair to say that. So I, I’ve just spent a couple of days in ICU because my cousin had emergency surgery this weekend. So this is all very fresh, right?

And the thing is that it’s always about the alternatives, right? He would have died. The alternative was major surgery. We’re grateful for it.

If your systems have had, I mean I worked on a system years ago that had a double failover.

The double failover meant that neither the clients nor the regulators nor frankly our own decision makers inside the band were willing to underwrite staying with the existing system.

So we had to make to have we had emergency surgery like my cousin in that when we had contained the problem, we went down an accelerated path of vendor selection and migration because it was the equivalent of emergency surgery.

If you don’t have emergency surgery, but you need an elective, then you manage your business affairs and your family affairs so that you go into surgery having lost a bit of weight and at the time of year where your family are most able to look after you, right.

The bank equivalent is you manage your other projects so that you risk managing and manage the cost. If somebody says to you, you’re in perfect health, you need to carry on having a healthy lifestyle, not smoking, exercising and eating well to avoid surgery, then you’re on a different path of keeping at what you’re doing, which the banking equivalent would be continuously modernizing, creating an evergreen infrastructure where you don’t let anything age so much as.

So, the reality is you don’t choose which one you are necessarily because we would all love to be the person who never has to have any intrusive procedures, but the reality is you don’t choose that.

So, without pushing the medical analogy too far, because I’m sure that someone will call in and go, you’re an idiot and you know nothing about medicine and you stay away from it.

I think if we think about it in terms of those 3 buckets, some of those choices might be taken away from you by a crisis situation. But even if you never find yourself in ICU, you will need to accept that you will continuously be changing and modernizing your stack.

Because we live in this era of unprecedented technological creativity and our regulators all around us are savvier than they’ve ever been before. And they will expect the service providers to do the best they can with the best there is.

Which means that the expectations of ever greening your infrastructure are there. Question is, will you do everything in your power to be in that third bucket that never needs surgery, knowing that it’s not always in your control?

DM: Yeah. I mean, it’s. To me this is fascinating because, you know, we get to this realization also that actually people aren’t really replacing anything that and it’s as you say, they’re modernizing, right.

And I worked as you know, in a, in a big core vendor too. And you know, the projects were only ever about replacing, right?

Never once did we think, you know, or is whether we thought, no, I don’t know. I think, you know, never once was it discussed, but actually, instead of taking out, you know, the core, what about adding new capabilities that may, that got rid of some of the other problems that they had in the organization, whether it was, you know, oh, we’ve just been fined for KYC AML. Let’s just, you know, get a better version of that. It’s built into our core, but let’s let’s upgrade that bit because that’s the problem or I can’t 100%.

LG: But like, as you were speaking, I had this flashback of 10-15 years ago, a very large chunk, if not the vast majority of business decision makers inside a bank wouldn’t actually know which core banking system they’re on.

It was an IT decision, didn’t know, didn’t care. And when I first started on the vendor side, I would speak to senior bankers and describe what we were trying to do when they were like, why is that special?

That makes sense. It’s like, but do you know how it works now? And I would find myself drawing diagrams not of what we did, but of the system they had in place.

So, I think if we accept that that was the reality we were in, the understanding of why core doesn’t can’t be taboo and shouldn’t be taboo and what does it do and how does it do it, He’s actually fairly new outside the IT people and the core banking vendors.

So, the conversations would have been about replacement because chances are the business people weren’t in the room for a very, very long time. That doesn’t happen anymore. The business people are now in the room.

The understanding of both what is possible and how much of it happens in the core, is actually helping a lot of these conversations. We won’t be able to talk about modernization and aligning the risk you take, the benefit you have to the business outcomes. You couldn’t have that conversation without the the business in the room, right?

So, this is definitely changing. I think it’s fair to say that. And I know you talk about modularization and essentially having a pick and mix approach, which is not the word you use, but I like food. So it’s always about food.

I don’t think that option existed before. So one of the things that we’re definitely seeing in in recent years and has made this job so much more fun, actually this is the fun is that the business are much more aware, educated and savvy about what is possible.

I’m frankly hoping that this will force certain discussions to take a different shape because we haven’t spoken about the, the, the true elephant in the room, which is that when the time comes to start creating cloud native, truly responsive infrastructure, the very big banks are always tempted to build it themselves because it’s fun.

That part is fun. The build is fun, right? It’s not the goal life and the integrations and the testing that’s fun.

That’s stressful, but the blank sheet of paper, daunting as it is, is fun. And all of the people who’ve lived in the same bucket as I did when I started my career, who’ve been constrained and restrained.

The temptation to build it yourself because it’s fun is huge. But it’s also the wrong instinct because it is a utility and it will take you a very long time to build something that is absolutely essential but not differentiating. So having those business-people in the room who speak the language now, who understand the art of the possible, who can overlay their business objectives, it will have three very salutary impacts.

The one is that it will contextualize the core conversation into a wider business strategy. And that will be good for everyone, frustrating as it will be for the core vendors, because you want to be at the heart of everything.

But the reality is sequentially, it might not be the first thing they need to do, but in the long run, being part of a sustained and aligned tech and business strategy is where you don’t have any of the problems we were talking about earlier, right?

They won’t get distracted because the whole organization is pointing in this way. It can’t be a side of desk project. It can’t be a hedging project. It has to be fully aligned with where the business is going.

DM: Yeah, yeah. I mean, we have kind of talked about, the core projects being difficult. We’ve talked about actually what really happens most of the time and actually successfully is kind of modernization is do you think at some point though, you know, replace, I, I think you’ve answered this one already.

Actually we, you know that at some point ageing technology will have to be replaced anyway, right? Like you know your COBOL programs.

LG: I do, I do. I think that everything has a lifecycle and we can’t anticipate that people that anything will live forever. And I do think that as I was describing before in my medical analogy, externalities might accelerate that.

But I think if we accept that no part of our technology is forever and approach the estate as the way we deliver against the business strategy, that business strategy and risk appetite, which is part of the business strategy will determine how much you change when and how.

You don’t need to change everything. And at the end of the day, you don’t need. I remember when I was working in my BNY Mellon days and you know the digital connectivity and, and of real time, everything was top of mind for everyone.

I remember talking to my boss and he was like, you don’t need real-time custody positions. They don’t change enough. It doesn’t like when the world is real time for everything. Sure, that will be real time too, but that’s not where we begin.

And that is the healthiest approach. There are a lot of things that a custodian does that it helps if they’re real time. The actual custody positions isn’t one of them.

And so, what does your business look like? What are your priorities? What are your needs? And what like those needs are important and what’s your risk appetite?

Do I think that if we had this goal in 25 years’ time, some banks will still be holding on to technology that by that point might be 100 years old?

Yeah, for sure. But there will be fewer of them. Yeah, because the reality of the economy is moving in a different direction.

DM: I’m going to give you a different analogy from a past experience as well, because I had similar kind of problem when I worked in NatWest, where, I was looking at this as state of technology. There were five different business units within hours, and each one had its own technology scratching.

And this didn’t make sense. Right. And you talked about the elephant in the room. So when I looked at this architecture, it looked like this like humongous feast of a thing with, you know, lots of things hanging off it, etcetera.

And I sat in my room one day and the head of delivery was in the room. And I literally sat and stared at my whiteboard for about 2 1/2 hours.

And then I wrote, you know, presentation logic data. And she said, is that what you’ve done after 2 1/2 hours? And I said, well, that’s how I think. That’s my Technology strategy. This is my job, you know, to redefine the epic.

What, what do you mean by presentation logic and data? And I said, well, look, you know, these are the kind of three layers.

We separate the layers and then in between, we can change things more easily. How are you going to change hundreds of systems?

And I said, well, you don’t eat an elephant in one go. You only set the table and eat it in one go. You chop it up in little pieces and you define, you know which you’re going to eat when. So first thing is, you know, you don’t eat the elephant in one go, you eat it in bites.

Second thing is you choose your bites, right? And so, you know, we migrate to this kind of layered architecture, which is going to be over time distributed, bearing in mind, you know, this is like pre Microsoft D com and things like which were the early distributed architectures, right? But we could see that that this is what was where the technology landscape was moving.

But we couldn’t wait for that. We had to get ourselves ready for it. And what I said is that look, when we buy a brand-new system or when we build a brand new system, it has to have 3 layers, very distinct, right?

They have to be like stuff that we can change at any level. Yeah, if we make a modification, we see if the modificate. Modification can introduce a separation, let’s say between the data and the business logic or between the business logic and the front end.

So, we kind of improve it. We don’t necessarily replace it, but, but eventually we’ll have taken enough bias that most of the lens looks like it’s gone, right. But you never seek to replace the whole thing in one go.

LG: And that’s 100%. And that’s unifying directional logic is frankly what a lot of the banks have missed.

And, one of the, the things that I bang on about a lot, particularly obviously since I’ve been outside of a particular vendor is that ultimately the reasons why you need to be disciplined about these things are very mundane. And they boil down to unit economics and cost to serve and operational complexity.

Because what you just described as an IT strategy actually helps you manage your operational complexity. If you allow things to develop in fiefdoms, you end up with an extremely unyieldy estate.

I remember many years ago I was inside a bank still and we had these two RFPs running.

One was inside retail payments and the other one was a unified payments hub across retail payments, credit cards, which were not part of retail payments, corporate cards, which was a separate division, and corporate payments.

Now, retail payments and corporate payments have slightly different needs, right? But they all sat together, frankly. But we had two RFPs.

We had two RFPs for payments hubs that were running separately with separate budgets with enough overlapping the committee’s to be confusing for us and so much overlapping the communities and in the requirements that the vendors were at times confused as to which person they were talking to about what.

But that is extremely common. This was not that particular bank being dysfunctional. This is extremely common.

And those two projects went ahead separately, creating a lot of redundancy in the process, a lot of wasted effort, a lot of wasted money, mostly for political reasons, frankly.

And the reality of it was that fast forward to now where you have some new regulatory requirements for payments and you have two systems that need to be updated, not one.

Now imagine how many times a day that happens across the estate and without the unifying architectural direction that you talked about from a strategic point of view, you are pointing in all different directions as well.

That unifying view is actually still quite rare.

DM: Yeah. I mean, listen, when, when, when I explain this to, to, to the head of delivery, she was like, I can’t believe you just spent 2 1/2 hours doing that.

And, and, and what couldn’t be seen was like the bigger picture. It was too simplistic a view. But anyway, we digressed slightly.

But I guess, we come to a conclusion or an agreement that most banks are modernizing anyway when they do this stuff.

But why isn’t that like the term modernization I’ve only been hearing in the last couple of years anyway, right? But, but this realization actually that look, you don’t have to do this big scary project.

You can start to address individual business needs as you require them. Like if you want to launch products faster than get a new product management suite, you don’t have to replace the Ledger. The Ledger just sits at the bottom of the products, right? Or if you want a new AML, get a new AML solution.

You know this, this approach of modernization, why isn’t that a general strategy when the banks, why isn’t that discussed more do you think?

LG: Big question. I think there are there are three reasons.

The first one is that the language was used elsewhere at times, right? So modernization was often language that was used by transformation teams. So it was associated with a whole host of things.

So we’ve been flying under the digitization banner, which actually isn’t wide enough.

So I think reclaiming the language of modernization really opens the box and goes, look, this is about how your business can operate in 25 years. It’s not about your core as such, it’s about everything. So I think part of it was reclaiming the language.

The second part is that, and we touched on it briefly, is that slow realization that the core isn’t a thing apart, that actually you need to have the right core infrastructure for the type of business you want to be. It’s not a, it’s not an objective answer, it’s not a standardized answer, it’s not even a static answer. So the fact that the core is not untouchable, it’s not a big scary thing out there, it’s actually an integral part of your strategy. Again, that is an emerging realization.

And I think the third thing that is an emerging realization is The Big Bang isn’t the only option, because we had Big Bang as the only option. And then in the last few years we’ve had the idea of experimenting, particularly with Neo cores on the side with a view of having a migration and switch off, which hasn’t happened yet, right?

I think there are a couple of instances out there that are close and we’ve had a lot of neocore go lives, but we haven’t had a neocore go live and switch off, which is the real test. And I think So what with those two options got a lot of decision makers going – “I don’t fancy either. I don’t have the resources or the time or the risk appetite for either”.

So that language of gradual transformation where you will end up with a new broom at the end of this, but you will manage the, you manage the transition, you’ll manage the risk, you’ll manage the cost in line with everything else. I think that is new, that strategic understanding that this is possible is new.

And it took a long time to come to this place because we needed decision makers at the table who understand technology and business deeply. And we have that. But we also needed service providers and technology providers who are willing to be part of a different conversation.

Because the reality is that some traditional vendors would come in, in a take me or leave me with everything in the box approach. And you’re seeing players coming into the space now who are much more aligned with the risk approach of banks and go like it’s a journey and I’ll go on it with you.

And that is, you want to call, call it hollowing it out. You want to call it modernization. I like the idea of lockstep transformation because whether it’s fast or slow, it’s that alignment and the realization that a core transformation project should never be stand alone.

And the reality is that for the bank, it never is. But if you’re the technology provider, the more you understand about the journey everyone is on, the better you support it. I think it took some time for the the decision makers inside banks to develop the depth of knowledge that they now have to demand a different kind of partnership.

But it also took a different kind of player to come into the market and agree to do it. You know, the traditional core vendors wouldn’t do that.

DM: Yeah, yeah. Look, I only just realised the time and we’re massively over, but it’s been a fascinating conversation with you lately. I knew it was going to be anyway, we’ve definitely got like room to do probably another couple of days worth of this. But thank you.

LG: And we should.

DM: And we will.

LG: Thank you for having me. Yes, thank you for having me.

DM: Thank you so much.

Listen on:

View transcript