Banking Blueprints

Welcome to the

Banking Blueprints
Podcast

Where we navigate the future of banking

Latest Episodes

Episode 4
In this episode of Banking Blueprints, we examine the dynamic landscape of finance, overcoming legacy system challenges, and unlocking the potential of modern banking
Banking Blueprints
Banking Blueprints
Navigating the ever-evolving world of finance and the hurdles of legacy systems
Loading
/

In this episode of Banking Blueprints, we examine the dynamic landscape of finance, overcoming legacy system challenges, and unlocking the potential of modern banking solutions.

Join host Dharmesh Mistry and special guest Leda Glyptis, an icon in the banking industry and author of Bankers Like Us, as we discuss how to navigate the ever-evolving world of finance, how to tackle the hurdles of legacy systems and the limitless possibilities of neo-core solutions in banking modernization.

Transcript

BW: Welcome to episode 4 of Banking Blueprints. For this episode, we’re doing things a bit differently. Today we will cover part one of the conversation between our host Dharmesh Mistry, and our guest Leda Glyptis, an icon of the banking industry and the author of Bankers Like Us.

In today’s episode Dharmesh and Leda dive into how to navigate the ever-evolving world of finance, how to tackle the hurdles of legacy systems, and finally, the limitless possibilities of neo core solutions and banking modernization.

Enjoy part one and we will soon be back with Part 2.

DM: Welcome everybody to innovation beyond the core. And this week is my special friend, Leda Glyptis. Hello, Leda.

LG: So good to be here with you today, Dharmesh. Thank you for having me.

DM: And so I mean, look, let’s for the benefit of the two people in the world that don’t know you later, can you give us a tell us a bit about yourself and your experience in banking?

LG: Absolutely. Hello, 2 new friends out there who don’t already know me. I’ve described myself as a recovering banker for a long time, partly because I fell into it entirely by accident and I found my calling in a way that embarrasses me to this day.

And partly because even though I have been outside traditional banking for the last few years, working in the core banking space, sort of on the technology vendor side, I still say we and mean bankers. I even wrote a book called Bankers like us, accepting that my, the way my brain works is still very much that of a, of a, of a banker rather than a service provider.

I think it’s fair to say, and it will touch on some of the things we’re talking about today, that I came into banking at the worst and best time possible.

I actually got my first banking job in 2007 just as the financial crisis was picking up immense speed. And I have only known the industry in the time of crisis. I have only known it in the time of stress, anxiety and profound change. Both positive change like the fintech wave was picking up speed at the same time and frustrating change through challenges, regulatory and market pressures. And it has been an amazing time to be doing technology work in banking.

So, although at the time it felt like the most counter intuitive decision anyone could ever make, it has been an amazing journey since then, having come from a sort of public policy and defence background, falling into an industry that was about to set my transformation journey that actually isn’t anywhere near finished. So, I’ve held some traditional tech transformation operation roles inside banks and then moved to client facing technology and innovation as we called it at the time.

In the last few years, I’ve worked in core banking, which has solidified our friendship Dharm because on top of everything else, we can geek out together.

DM: I mean, look, firstly you made me feel really old because you came in a banking when I’ve been there like 20 years.

LG: It wasn’t my first job though. It would, it should feel, it should make you feel old. If it was like I finished high school and entered banking, it wasn’t that at all. I did work in, as I said in in defence and I did some technology and M&A work in defence, which was mind blowing for all the wrong reasons. And it does, it definitely makes me feel old when the thing that is my second career I’ve been doing for 20 years.

DM: Right, right, right. Wow.

LG: See, see that’s old now.

DM: OK. So, can you say a little bit about your experience in the core banking space itself? You know, because you work with modern core vendors, right?

LG: Yes. So, I would say my experience in core banking is a, is a story in three parts, right? The first part is a tale of frustration because I spent the first 15 years of my career inside banks.

And as you know very well, because you’ve had the same, the same journey, anything you want to do inside a bank, particularly if you’re trying to implement any data first initiatives and no matter how big or small, very, very quickly you will come up against someone senior in either compliance or IT who will suck their teeth and go core can’t do that.

And that’s the end of the conversation, right? Because core replacement core transformation has been such a spectre of career limiting choices for senior decision makers over the years, because historically changing the core has been expensive, has been long drawn out, and it has been career ending for the CTO that signed off on it. So, I spent so many of my so much of my career having to work around the limitations of the core.

And it was an extremely frustrating place to be inside banks where you always had to clip the wings of the ambition of the organization to fit it in the box of our legacy technology, whichever shape that might have been. So, the first phase was one of frustration. So, you can imagine that when I, I got the call to come back to Europe, because I was living in the Middle East at the time, to work in that joint venture between 11 FS and D&B, their biggest bank in the Nordics, to build from scratch blank sheet of paper, a neo core.

I had a million questions in my head about whether that was the best way to go about it and whether that was the best thing for me. But the loudest voice was blank sheet of paper go and I have not looked back.

To be fair, I spent two very happy years at working with DMV and Foundry.

And then as things started shifting with the beginning of COVID, I moved to 10X and got to really scratch that itch of seeing customers go live under sort of my watch and my care.

So, the next phase, phase two is five years of building and, and seeing clients live onto neo cores with all the challenges and, and, and joy that comes with that.

And phase #3 started recently when I left 10X to go independent. And now you have all the scars of both sides of the fence, and you can, because you’re not picking a side anymore, I guess is the, is the reality.

You, you look at the landscape very differently. Still very, very close to my heart. There was a very long answer to a very short question.

DM: No, no, no, but it’s a good answer. And I mean, you know, just on that blank sheet of paper, because I find that bit fascinating is that, you know, when you’re in a bank, you kind of think if we could just start again, you know, and have this blank sheet of paper. But when you’ve got it, it’s quite a daunting kind of task to take on, isn’t it?

LG: It is, it is quite daunting. And the reality is that, particularly if you’ve got the scars of having been frustrated and limited in the past, you, there are a couple of things that you come in and you’re really opinionated about.

You’re really strongly because you know the reasons why the other thing didn’t work. So, I remember we all went in and was like, OK, we know what we want our data architecture to look like. We know what the sort of messaging and event streaming ethos of this thing needs to be.

And we also know that in order to prevent ourselves from becoming a monolith or as one of my clients named it a modulith in down there. A modulith. What a good word, right?

We knew that we had to create the sort of asset agnostic architecture where the Ledger didn’t care if you were dealing insecurities, FX chickens. And we sort of we created the sort of trigger-oriented architecture. Great. But then you come across a whole host of choices that become extremely important that that you don’t have lived experience on.

And there’s more of those than the others, actually. And sometimes you default to going. You know what? Not everything about the way we’ve always done things is wrong. And that’s a big mistake that actually a lot of us make when we’re building something new.

You try to move away from the old ways of working and everything. That’s your why quite a lot of it works. That’s why it’s still where it is.

And then there’s a whole host of things where you’re like, you know what, I don’t have a view on that. I don’t know, I don’t care. So, you have to go out there and do quite a lot of research and find that the market doesn’t care as long as it works.

And that’s where some risk enters the equation, and you make some good choices, and you make some terrible ones. And sometimes the terrible ones you can fix and sometimes you have to live with them.

DM: Yeah. I mean, I’m, I’m a big believer of this thing where, you know, not everything needs to be scratched, you know, otherwise, yes, I’d be redundant by now. But as not being a young man anymore. But anyway, so, so what’s your experience? I mean like when it comes to the implementation side, right? What’s your experience of like core replacement projects? How much fun were they? as they happened?

LG: As they happened, not at all.

DM: Not fun though, right? LG: As they happened, not fun at all, to be honest with you. Which was a very disappointing realisation to make, I think. Particularly as the core replacement project that I’ve worked on were either under duress. So, inside the bank something had gone terribly wrong and we needed to migrate some functionality at least onto a new infrastructure.

And the fact that it was under duress meant that the kind of scrutiny we all had on that work was anxiety laced. And then the go lives I’ve had on the neo side, there’s a lot riding on them because they’re early for the market, they’re early for you.

So, every little thing is again, anxiety laced.

So, I wouldn’t call them fun, but I would say that the journey of implementing a change like that, he’s so rarely or rather the vast majority of the things that you’re worried about and working with and dealing with have nothing to do with the core itself. And it’s all about the organization, the politics, the business priorities, the estate you’re integrating into, the stakeholders that need to be kept informed and comfortable. And depending what situation you’re looking at, that could be a regulator, which is never a set of comfortable conversations, right? Or it could be a board or it could be just business stakeholders.

So, that the yeah, it’s never fun, as it turns out. As it turns out, it was a lot of things fun wasn’t one of them, right, right.

DM: Right, right, and that’s like your is that is that perspective, both from working within the bank and also working for a supplier of a core is that it’s never fun to do these implementations.

LG: Yes, yes, yes.

DM: I I guess it’s not fun.

LG: It’s, it’s brilliant. And once it goes live, the feeling is amazing, particularly if it goes live with nothing or wrong, like the feeling is amazing. Although the reality is you never get that moment of triumph like you see in movies because chance supper the time it’s gone live, you’ve moved on to the next thing.

DM: Yeah. Yeah.

LG: So, you don’t even have the time to celebrate. But I think it’s fair to say that it’s creative, it’s interesting, it’s engaging. You do get an amazing sense of accomplishment. But the stress that goes around it because of everything that rides on it being successful. Fun is in short supply.

DM: I mean, in terms of the implementation, how does it? I mean, how does it vary between is it easier for a small bank than a big bank? I mean, small banks don’t have the resources to do these things. So pretty much reliant on a vendor or a partner. Big banks have all of the resources, right and tons of very smart people. So, you know, is it easier for one and harder for the other or is it all the same?

LG: So, in my experience, the factors that the lived experience of doing something this in a very large global bank is its own animal and doing it in a smaller organization is its own animal. But like harder or easier in my experience so far and it has been a surprise had more to do with why they were making the change and what the nature of the change was rather than the size.

So, for instance, in a very large organization that is launching a new initiative, say on a new call, and I’ve had this experience a number of times, some went live, and some didn’t.

The biggest danger when it’s something new and it’s not something that is already part of the critical infrastructure is that the organization could get distracted.

So, though the organization is big and kind of forwarded and there are a lot of other people around you will, if it’s not on fire and it’s a nice to have or a business enhancement, it is the biggest danger is the organization getting distracted. Whereas a small organization, for better or worse, will not get distracted.

But then I had a project that hasn’t gone live actually, so it’s not public many, many years ago change leadership. So, they didn’t get distracted. They just midway through a project like that, change of leadership and old steam leaves the engine, wind leaves your sails. So, that that is a danger you have in any big organization.

If you’re doing something new, if you’re replacing a piece of critical infrastructure that is already live and running and you have a migration from existing business in an existing geography, then that is not a danger. And then the realities of doing it in a big bank or a small bank are less about size and more about drivers.

So, I’ve worked on a couple of projects that were because of like disaster recovery, failures of a previous system or regulatory pressures.

The minute those words are uttered, it doesn’t matter what the size of the organization is.

DM: Yeah, I mean, you’re absolutely right. And that’s kind of mirrors my experience as well is that worked on the Tier 1 implementation it was really important to the bank that was very clear, right, because of the problems that they were having and you know, the position they were in their market, etcetera, right?

And so, you know, this thing actually did survive three different CEOs, right?

LG: Amazing.

DM: Yeah. I mean, in in five years, I mean, it was, I think some football teams have had fewer managers, right, in that time frame.

LG: Not Birmingham City DM: Not Chelsea, but anyway. So, yeah, I mean, I think I think that’s absolutely spot on. But you know, for a tier one bank, right? I mean, like typically the smaller banks, tier 4-5 banks, you know, they tend to go to a vendor that has the spread of functionality, you know, so that, you know, they’ve got almost one throat to choke as such, right?

But for a tier one bank, any one of them has got hundreds of points of integration. Is it realistic that they’ll ever replace their core? You know, will it ever happen or will they just kind of like build around it and add a new one?

LG: It’s my general view when it comes to any type of tech infrastructure inside a big organization. And I’ll get back to the small organization because I heard a brilliant story recently that you will love.

But in a big organization, it’s a bit like, you know, you have this broom and it’s your grandmother’s broom, but you’ve changed the handle four times and you’ve changed the broom brush 30 times and you’ve changed the binding and the is it still the same broom?

DM: Yeah, Yeah.

LG: And for all intents and purposes, it is still the same broom. And, and I do think that we need to think of technology infrastructure inside banks exactly like that because the reality is there isn’t a single year inside an organization of any size that some material technology change doesn’t happen, but it happens at a pace and in a prioritization schedule that is in line with their risk appetite, their resources and whatever else is going on.

And one of the things I am guilty of and I think all core banking vendors are guilty of, it’s because you’re so deep in this and you know how important it is. You forget that any decision about what you’re going to do with your core is contextualized inside the bank in terms of ambition, other projects, regulatory shift.

So, you see a lot of heightened activity in regulatory jurisdictions that are about to move into the cloud for the first time. You see a lot of activity then what the competitors are doing, but also what other projects are in flight because there are dependencies you want to risk manage exposure, right?

So, why am I saying this? I’m saying this because it would be naive to think of it as a binary thing. Although when you’re inside the vendor, you often do. They either change their core or they don’t. But the reality is they’re constantly changing things and they’re changing them in as big bites as they can take and a smaller bite as they can take at the same time. So, is it realistic that a big bank will

change its core in a big bank? No. And it would be stupid. It’ll be dangerous and they’re not going to do it because they’re not stupid.

Do I think that the vast majority of banks will have a very different core infrastructure by 2020, by 2050? Yes. Do I think they will have it by 2027? No. So, between now and then, I think it will be a case of deliberate, intentional movement in a particular direction. And by the time you get there, is it still the same broom?

DM: Yeah. Yeah. This is triggers broom from Only Fools and Horses. I’ve worked in the organization for 40 years, and I’ve always had the same broom. I’ve had six different handles, but, you know, four different brushes.

LG: Exactly. Exactly.

DM: Yeah. I love that analogy. That’s a great, great, great, great story. OK.

So, is there, is there proven, like is there one approach, a proven tested approach to replacing core that guarantees success?

LG: That’s the million-dollar question, right. I mean, the short answer to that is..

DM: Give it a wait to everyone because if there is, we’re going to make a lot of money.

LG: Yeah, actually there is. And Leda and Dharm can tell you what it is and you have to pay a billion dollars. So there, there isn’t, right? Because if there was, people would have worked it out.

Because the, the magic about core is that it is a utility everyone needs, right? It’s not a niche problem that people may choose to deal with.

Everyone needs to think about what they do here. I think there are a couple of characteristics that successful transformations have and ideally you have all of them.

So, the first one we already touched on is. Leadership continuity doesn’t necessarily need to be the same people, yeah, but it needs to see to be the same business vision. And usually that happens with some continuity in humans as well, to be fair. But you need a clear vision. If it’s an experiment to the side, then distraction is likely.

If you’re only doing it under duress and regulatory pressure, then not going all the way is also likely. So, that continuity of business vision and a realisation of where you’re going as a business helps. The 2nd, which is extremely hard to quantify, but I’ve seen it as the singularly most significant driver in my career is someone in the organization whose personal ambition and their personal view of their legacy or their accomplishment or the proof point for the market is tied to this work.

Someone’s personal life somehow ties to this project is such a such an obscure thing to be looking for, but essentially that organizational directional ambition and someone’s personal ambition need to coexist.

And then the last thing I would say that I see in those successful implementations is a properly calibrated risk management language because you need to have the hard conversations about risk management because you’re migrating data, you’re migrating live customers, you’re making the hard decision to switch things off.

So, you need to have the right language to speak to the risk teams and the compliance teams so that you’re agreeing on what is an adequate level of satisfactory stress tests before you go. OK, I’m flicking it. I’m flicking the switch. I’m switching it off now.

But equally not shying away from the one of the biggest things that I have seen as a thing that failed projects have in common is the attempt to keep as much of the work secret as possible and not bring their risk compliance main organization eyes onto this work till that’s advanced.

That’s possible. I see the urge, I get it. It also comes from years of doing innovation projects like that. So, all new technology was usually nurtured like that.

It does not work when you’re looking to migrate live customers and where you’re looking to touch critical infrastructure.

So, it’s a combination of ambition, people feel somehow personally bound to this work and the properly calibrated risk management from day zero.

You keep the risk and compliance folks out of the room long enough, you’re dead.

BW: Thank you for tuning into Banking Blueprints. We invite you to stay tuned for future episodes. On behalf of our Season one host Dharmesh Mistry and the team here at Zafin, we’re glad you’re here. Thanks again. We’ll see you soon.

Play
View transcript
Banking Blueprints
Banking Blueprints
Navigating the ever-evolving world of finance and the hurdles of legacy systems
Loading
/
Episode 3
In this episode, we unravel the complexities of modern banking systems, where innovation meets tradition and shapes the future of financial services.
Banking Blueprints
Banking Blueprints
Breaking free from legacy systems: advancing banking through core modernization
Loading
/

In this episode of Banking Blueprints, we explore the intricacies of core modernization initiatives: the challenges they pose, the rewards banks can reap, and how you can avoid the most common pitfalls when upgrading your legacy core.  

Join host Dharmesh Mistry and special guest Shahir Daya, Chief Technology Officer at Zafin as we discuss how to mitigate risks through a variety of modernization strategies, simplify integration processes in a multicore environment and, finally how banks can minimize disruptions to ongoing operations by implementing vertical slicing to grow incremental business value. 

Transcript

DM: Welcome everybody to the Zafin Innovation Beyond the Core podcast.

This week, I have a very special guest, Shahir Daya, who is the CTO of Zafin.

Shahir, would you like to give our audience a little bit of background on yourself so they get to know you a bit before we get into the topic of legacy modernization?

SD: Yeah.Thank you so much, Dharmesh.My name is Shahir Daya and I’m the CTO of Zafin. I’ve been with Zafin for just over 11 months.

Prior to Zafin, I spent 27 years at IBM. I was an IBM Distinguished Engineer and the CTO for the financial services consulting business and have gone through several waves of technology, everything from developing mainframe software to client server to cloud and decided to join Zafin at the beginning of this year.

DM:  Fantastic.

I mean, you have a career very similar to mine. I started off on the mainframes, but you look way younger than myself, so that’s fantastic.
I’d just like to understand a little bit more about your background because it’s fascinating that you spent 27 years at IBM. What drew you to Zafin?

SD: Yeah, that’s a good question. A couple of things. My IBM career was very focused on consulting client after client. And I did spend most of my time in the financial services sector and a lot of my time at banks doing modernization, and I wanted to try out working with product, building a product and Zafin had the perfect product, cloud-native, SaaS, in the financial services space, great company, great vision, and the timing was just right for modernization, core modernization and Zafin’s point of view around core modernization was in line with what my thinking was and it was a perfect fit.

DM: Fantastic, fantastic.

I mean look we know the topic of this conversation is legacy modernization, but I want you to break that down into 2 halves.

Firstly, for the general audience that isn’t technical, maybe just define what you mean by legacy. What’s a legacy system?

SD: Yeah, so Dharmesh, that’s a very good question because people usually attribute legacy to mainframe and that’s not correct because the mainframes are extremely modern. The technology within mainframes is state-of-the-art and what those mainframes can do is just unbelievable.  So the legacy part is nothing to do with the fact that it is running on the mainframe.  It’s actually to do with the software itself, right?  And if you think about it, I’ve dealt with core systems that are literally 4 decades old, right?  And they were built 4 decades ago using architectural styles and patterns that were very popular 4 decades ago.  And those things have changed. Programming languages have evolved and using the right language for the right task at hand and so on. And if you think about having a core system, every time the business needs something, you look at it and you’re like, OK, I’m going to make the change in the core.  So you continuously make changes in the core, normal adaptive maintenance, new feature request fixes, you keep evolving and changing the core.  And it gathered so much technical debt over the decades and to the point where now it’s a drag to make changes. So old architectural styles, old programming paradigms, scarcity of skills, all of those things make these cores legacy.

DM: Fantastic. So let’s get on to the meat of the topic then.

I’ve been in a core banking software company and we sell core banking software.

So literally we’re telling people you need to replace your core. But recently I’ve been hearing, not only from you guys but other players as well about this kind of terminology.

‘Well, look, changing your core is a bit like changing the engine of a plane while it’s still flying’ or other analogies like, ‘It’s like having open heart surgery while the patient’s still awake’. It’s so risky, it’s dangerous, right.

But newer players are now and Zafin are promoting this concept of modernization.

So what does that mean, versus rip and replace of your core, right, right.

SD:  So they’re actually right.

I mean core replacement, ripping and replacing: very high risk. I don’t, I don’t think you’ve seen anyone do it successfully without actual problems, right?

It is one of the big challenges with a core replacement is all around feature and function parity.

How do you achieve that before you can cut clients over? And core modernization, if you look at what comprises a core, it’s really three big boxes, right?

There’s the ledger, the subledger, there’s product and everything that comes with product, things like pricing, fees, rates, suitability, eligibility rules and so on.

And then there’s the customer master, right?

And if you think about the challenges and Dave spoke about these challenges right around Agility. If you think about the challenges we are trying to address and all the banks are trying to address, trying to become more agile and we know the legacy core is not agile. It’s very cumbersome, very difficult to make changes because of the regression testing and the languages and the architectural paradigm and so on.

So “hollowing it out” or you’ve heard the words “hollow out”.

You’ve probably heard “strangler”, “the strangler pattern”, “strangling the core”.

There’s many ways of terming it, but pulling these big capabilities out, if you pull the product catalog out or you pull the whole rates and fees out or you pull the customer master out and pull them out and go towards a more modern solution, you start becoming more agile in those areas.

So, if product pricing is an issue, pull out the product catalogue, pull out the capability to a more modern stack.

DM: Yeah, yeah, yeah, I get this.

So it’s a bit like, one of the challenges of the legacy cores that depending on the vendor, but the older the vendor, the more components that they actually have, which is great if you’re a small bank, you can get everything out of one box, but it means that you’re like a Jack of all trades and a master of none.

SD: Yes.

DM: Like you know that you’ve got everything there, but it’s not the best of one thing, it’s not the best credit risk module or the best customer management module or the best ledger.

It’s everything but not the best individual pieces.

And what you’re saying is that you can take out individual pieces and then replace them with something that’s much better. Is that right?

SD:  You’re absolutely right. You hit the nail on the head.

That is the exact strategy: let the core be what the core was meant to be, which was the ledger and use best of class, best of breed products for all of the other components and stitch them together in a very tightly integrated way.

DM:  Fantastic. And this sounds great, right? Because it means that I’m not doing a big rip and replace exercise, which is fraught with danger, right?

But I’m just going to take a small part of this and now pass that capability somewhere else.

Is that easy to do?

SD:   It’s not easy. Nothing in that space is easy to do. But it is a lot easier than trying core replacement.

The risks are minimized and the way you do it.

And because you know the technology has evolved so much that you can achieve coexistence and so on right. So as an example, pulling product and pricing out of the product catalogue out of a legacy core is not that difficult because once you pull out the product and pricing and now you’ve got a modern solution for product and pricing, you’ve got modern APIs and so on.

There are techniques that you can use like bridging the API calls from the legacy to the more modern one and that minimizes the amount of changes that you have to do on the bank side, right? Because the bridge is providing an API that’s exactly what you have today and it’s doing the necessary translation to the more modern one.

And these are temporary solutions.

It’s a transitional state architecture as they actually start modernizing and moving the APIs to move to the modern stack and so on. So there’s techniques like those that really help with minimizing risk and accelerating the timeline.

DM: Oh, that’s fantastic. I mean, what amazes me. The product catalog is such a good example because no bank has a single core anyway. Typically a bank has a different core for its accounts and loans versus it’s mortgages versus credit cards.

You know, there’s three there anyway, right?

And so you know, in the old world each one of those cores would have its own catalogue and now you’ve got 3 catalogues now rather than 1.

So it’s no wonder that we had this problem with the single customer view.

But externalizing it makes it much more sensible because you’ve now got the single customer view and you’ve got one way of defining the products rather than three different ways and you can do it in one system.

So I can, I can see lots of benefits here.

So if a bank wants to do modernization, like how do they start, what are the things that they have to consider before they get engaged in a project like this?

SD: Right. So I think just modernization programs are massive and everybody knows how risky they are. So proper planning on their side is extremely important. And what are the actual pain points we’re trying to address?

It’s very important to understand what are the pain points the bank has that we are actually trying to address. And the other piece of advice is start small, pick an actual use case and go using a vertical slice approach, right. So don’t do anything that’s going to be horizontal.

Always do something vertical that touches the clients because you want to deliver client value, business value incrementally, and that is one of the most important things in a core modernization point of view is yes, we want to modernize the core, but we don’t want to put a pause on innovation and tell the business,

“You know folks, you need to hold on for a while we modernize or get to a new core and that’s going to take us 2-3 years and don’t do anything innovative until the” — that doesn’t work. We need to incrementally deliver value.

So picking vertical slices that have incremental business value is the approach.

DM: And just for my benefit because I should know this I guess, But can you give an example of like a vertical slice? What do you mean?

SD: Absolutely. I’ll give you an example of a vertical slice.

So when you look at the business capability at the top and you look at the technical stack that it needs to call, typically you’ll have a user experience, you’ll have layers of APIs, you’ll have a system or record and so on. I’ve seen banks think that we’re going to build this layer of enterprise APIs and focus horizontally and we’ll build all these APIs and we’ll build them and they will come.

And I find that in some cases, yes, that works.

But in many cases, you’re spending so much time building this horizontal layer of enterprise APIs that you are not delivering business value at the same time. So if you do a vertical slice, you only build the pieces that you need to deliver that vertical slice in the business value associated with that vertical slice.

And you go vertical slice after vertical slice and your horizontal starts to take shape and get filled out.

DM: Right. I mean that makes a lot of sense to me.

Clearly, it’s like if there was a big cake that was the bank.

I’m just taking a slice all the way through and then at some point I finished the cake. So absolutely, and you know I’m a foodie so I had to get a food analogy in there somewhere.

So in terms of pros and cons, I mean it I can see the some of the pros, right?

For example, because you’re taking a vertical slice, you’re going through the entire software stack but not the full breadth of its capability.

So you’re containing its scope but still addressing all the layers. So I can see that lower risk than trying to do an entire horizontal thing like you mentioned about the APIs.

Are there any other positives around the modernization?

So it’s lower risk which means that it can be done quicker, right, with less manpower, What else?

SD: Yeah, it basically risk and incremental value are the key things, right. And incremental value is so important, you want to get the business excited early on as you go on.

And there’s so many strategies that I’ve got when you’re getting the product for a catalog up, for example, you don’t have to move control of all products to whatever new software immediately, right? You can deposit products and checking products and so on.

And like you said, there’s multiple cores, right?

Yes, deposits, credit cards.

And you want to externalize products from all cores to the same place because of the value you spoke about, right?

The whole being able to have the 360° view of the customer, all of the agreements they have with the bank, right.

So there’s just so many advantages, so many ways to do it.

And if you, if you think about it, integration and orchestration becomes the single most important thing, being able to integrate and to be able to then integrate incrementally so that I’m only concerned about this one thing.

Everything else remains the same and I want to be able to keep switching things on as we progress in our modernization journey and orchestrating across the different cores.

We know we are a multicore, we’re going to be in a multicore situation.

So orchestrating across the cores is very important as well.

But risk and incremental value are two of the biggest things that we need to focus on.

DM: Yeah. I love that incremental value thing because when I think about kind of core replacement, I just think risk, risk, risk cost, cost, cost, cost, it’s going to take a huge amount of time and several years later I’m going to get a brand new system that allows me to launch products quicker, etcetera, right, blah, blah, blah.

But it’s well at that time I’m thinking it’s like so much time before I’ve got any value back.

But this thing about giving a little bit of value quickly and often and repeatedly, I love that concept.

I mean, clearly, you’re coming from the consulting background, so you kind of get that very well.

So I love that. OK.

So, I know you want to pitch that “modernization is the way forward”, but are there any downsides to modernizations that you can think of?

SD: There has to be a reason why you’re doing it right?

You don’t want to modernize for the sake of modernizing, just because everybody else is doing it.

You know the pain points on agility are important.

If you don’t have the luxury of going with a new core that’s modern and cloud native and all of those things, again, you are going to modernize from certain standpoint because like you said the core you know they want to focus on everything, they want like a bank in a box, but they’re not going to be good and deep at everything.

You know they need to focus on the ledger and they have to be great at the ledger and leave product pricing, customer master, leave those things to others that are focused on those specific components, right?

So you can expect to see a modern cloud native core that’s built recently that’s still leveraging another component for a customer master, another component for product and pricing and so on.

And it’s focused on the ledger, right. So I see modernization happening whether it’s a legacy core or some of the newer cores. You may not specifically call it modernization because what are you modernizing, right.

But you see the idea of externalizing and using best of breed products and stitching them together to achieve what you need to achieve.

DM: Yeah, I mean I think again, I still love this point about the incremental value because I can see that one of the downsides could be that the overall replacement of a core might take longer because you’re actually releasing on a bit by bit basis, right?

I don’t know if that is the case, would it take longer or could it be quicker? Because obviously one’s a deeply complex project and you’re trying to eat this elephant in one bite whereas the other you’re trying to chop it up into smaller pieces and that’s even more manageable.

But would it take longer or not. I mean what’s your experience?

SD: The thing is if I saw one that actually was successful, I could tell you if it would be longer or not.

It’s very difficult to guess at that. You know trying to eat the whole elephant in one shot is very problematic. You know and there’s different banks have done different things, right.

We’ve got banks that have a legacy core and they stand up a more modern core and they try to coexist them. Coexistence, but having a solid coexistence layer and then you know introducing new products on the new core and then having an experience that’s stitched together.

So I could have products in the old core and the new core, but completely different products, not migrating the products over and that’s a start to try to get value quickly.

But you know, you have to ask the questions is that the right approach for a particular bank and there’s no one-size-fits-all right. Different banks are in very different situations.

DM: Yeah, definitely, I mean what you said about standing up another core alongside your existing, you know, my experience has just taken too long before the old core actually made, got made redundant at some point.

You might as well have migrated the whole lot because it’s been there. It just ends up being another core as opposed to a journey to replace one in its entirety. So I think you’re right on the, standing up one.

But another one that I’ve seen also is where they literally create a new bank, under a new brand typically called the Speedboat strategy, let’s create this brand-new organization and let the customers migrate to the new brand.

I mean again, I’ve seen that you know being done.

I haven’t seen, have I seen any of that as successful, maybe one that’s been successful but not too often. And again typically the new brand has kind of come out, it’s on a modern new platform is able to innovate, but it just didn’t get the customer traction and they didn’t launch enough products soon enough, right.

So it it’s a difficult one, that one as well, right?

SD:  Yeah. And that’s the, that’s one of the advantages of the legacy bank, right.

The legacy bank has the accounts, right.

They’ve got the balance sheet, they’re the ones that if they can just innovate fast enough in terms of product and propositions to the clients, they can grow those accounts significantly, right, and attract new clients, right.

So you know the hollow out strategy hollowing that core out and pulling product catalog and customer master, pulling those things out and making them more agile so that you can actually innovate faster in my opinion is a better strategy.

DM: So, so you’re advocating basically that don’t ‘replace the core, build around it with better capabilities.’

And typically you want to innovate around the customer experience, manage the customer separately.

You want to innovate with new financial products, manage the product management separately to the core and maybe just leave the core to the ledger, right.

SD: Yeah, absolutely.

DM: Wow, fantastic.

SD: You can introduce a new core at the same time and just as long as the product catalogue and the customer master are shared across the two cores, you could achieve that as well.

DM:  OK. So, all right let’s say that I’m like a bank that has successfully put in a brand new core banking system, it’s cloud native, it’s got micro services, I can do daily releases, it’s got APIs, etcetera, etcetera.

So I’ve got this new core.

Would I benefit from modernization as well or would you say that it’s a job done?

SD: You know if it truly is as you explained it is, then I don’t see what you would be modernizing,

DM:  I mean I’ve seen one of those.

SD:  I’m curious to see it myself, right?

DM: I think you have to explain what the problem is and if you may, I’m going to, I’m going to answer that one for you because I know where you’re coming from which is basically no bank has achieved putting all of their products onto a single core. So typically, they’re in a multi core scenario and they may have replaced one, but they still got the others to go right?

SD: Absolutely.

DM: OK. So what’s the problem with that?

So let’s say they’ve got a brand new core and when they want to do some new products, yes, they have to run some legacy products.

What’s the problem with that? I mean is there an opportunity for modernization on that?

SD:  Yeah, there is.

Absolutely there is, right. And you know if I look at product and pricing and all of the different capabilities, when I was in consulting and when I think about banks or when we think about banks, are we all bank, right?

We think about banks and you think, “Oh it’s a product, it’s a checking product, OK”.

“These are the fees I pay, these are the different ways I can avoid the fees, What’s so complicated?”

And then when you look at Zafin and how we do product and pricing and what’s involved and monitoring behaviour and it is complicated, it’s very complicated, it’s not straightforward, right.

So a new core, a new more modern core that might come out that might have a product catalogue and have product and pricing to match some of the capabilities that banks expect today?

You know I’d be very surprised if anyone could come up with that you know right out of the gap with a new core.

So for some of those capabilities that you just don’t exist in in in cores or that a new core may not have you know your best option is to externalize it to a best of breed product.

And when you think about this idea of a lot of banks are doing this right? They’re externalizing everything and picking best of breed products for all of the moving pieces because it’s a better strategy.

And they’re abstracting them away so that if later on they decide “Hey, what I picked for, anti-money laundering is not a good fit, let me switch it up with something else.”

They can switch it out, right?

DM: So one of the things that I’ve seen and I’ll be interested in your perspective on this is that there are standards like BIAN in Europe that standardize the interfaces between the banking components so that you can take out the ledger or you can take out the credit risk module and you know replace it with something-Yes, you might not get every single parameter matched, but it’s close enough that will minimise the effort for swapping in and out component.

And then you get to what I think the industry is calling a composable architecture, right, where you can mix and match much more like Lego bricks than you could do in the past.

Is that, is that what you’re talking about?

SD: Yeah, absolutely. And BIAN, we’re a big proponent of BIAN. We are BIAN-aligned as well. And so when you externalize and you settle on BIAN as the standard for the interfaces and the data model to replace a component as long as it’s BIAN-aligned becomes a lot easier, right.

And that’s what I’ve seen banks do is they want to externalize, use best of breed products and stick a BIAN layer above them so that if I need to replace them, I know BIAN, the vocabulary is the same and so on. BIAN is also very handy when you think about, Dharmesh, when you think about coexistence.

I have an old core.

If I get the data out and BIAN-align it, and I have a new core, I get the data out and I BIAN-align it.

I have BIAN-aligned data. It doesn’t matter which core it came from, right? The experiences and all don’t know where the data came from.

The BIAN layer abstracts all that away.

DM: Fantastic.

A couple of things surprised me because I didn’t know that Zafin actually was BIAN-aligned. I just mentioned it because it’s an area that I’ve been looking at recently under the banner of Composable and Coreless, right, but also I thought it was much more a European thing.

So it’s quite interesting that you as a Canadian/U.S. company is already BIAN-aligned, that’s fantastic.

SD: Yes.

And there’s there’s a lot of North American banks that are very much focused on BIAN, right.

DM:  Right. OK, cool. So what about in terms of adoption, have you seen much like this, this is the space that you’re in, you’re facilitating an aspect of modernization, right? What’s the adoption like and the success, right? Compared to a core replacement, maybe that’s a giveaway answer there, but, what’s the adoption like globally?

Where are the countries or regions that are most open to modernisation versus replacement?

SD:  Personally, I think, I’ve seen it across the board, yeah. And across the globe.

Like, I think everyone has come to realize that core replacement is not an option. It just isn’t, right?

Maybe in the last 11 months, I’ve encountered one client, one bank that is thinking that they’re going to replace the core and put everything on hold. And I think they’ll come to fast realization that that is not the right approach for them.

All of the others are very focused on core modernization. They’re all focused on hollowing out the core and many of them are doing it differently, right?

Some are doing it without picking a modern core. They just want to hollow the existing core out and go with best of breed products for the different components and leave the legacy core as the ledger and others are standing up another more modern core and want to coexist.

And so the coexistence becomes important, but with the coexistence again, it starts with hollowing out, get the product out and share the product catalog across the two cores, get the customer master out, share the customer master across the two cores, right.

So even the hollow out strategy and the coexistence going from 1 core incrementally to another core, the idea is still very, very similar in externalizing these big blocks and using best of breed products for these big blocks.

DM: Right.

It’s for some of the banks. I know because I was in one in the 90s roughly when you were doing the mainframes, I was also doing the mainframes and I was involved in a project where we put the customer file into the mainframe as a separate kind of application.

And everything to do with maintaining a customer record was done in one place. And prior to that, we had a few different cores and they had a customer record in each one, right.

And we quickly saw the problem that, hold on one sec, we’re not only duplicating customer data, but all the processes around managing a customer were separate according to each core, right? So it kind of made sense to me and we spent, in the mid 90s, we spent a billion dollars just on creating a customer database and admittedly you know that was in a big mainframe, it was at the time the largest customer database to be sitting on DB2, right?

But the logic stands up to what you said, it was about taking out a piece of functionality and making it so that it’s separate to the core itself, right?

For me that made sense. And later on, when I worked in a core banking software company, I was surprised, I was surprised that the customer record was in the core.

I could see the necessity for it, right. But one of the first things I did was to create a plan to kind of separate it out and we created a digital platform for managing the customer record and the interact customer channels like Internet and mobile etcetera, right?

So that all made sense to me because it was part of that picture.

But the penny never really dropped until I started speaking to you guys about the product catalog and how long has this been going on that people are wanting to centralise their catalog and pull that out of the core.

SD: How long?

DM: It makes sense-

SD: It’s been many years I think, or it’s in five plus years at least that people are trying to centralise the product category

DM: relatively new then, right.?

SD:  Yes.

DM:  And is that because they’ve seen the problems of having multiple cores and the different catalogues and the different ways of defining products in different systems, right. Any other reason why it’s been later?

SD: I think initially as the products and fintechs arrived and customers demanded better things and better ways of what the product architecture needed to look like and ideas of tiering.

And I can create an account at a bank depending on the amount of funds I have in the bank across different accounts, I could move from 1 tier to another, and it unlocks different capabilities.

Everything from like a Netflix account or when those kinds of capabilities start showing up and you realize, well we cannot do that in our existing core and our competitors are doing it. What, what are your options, right?

DM: Yeah.

SD: So externalizing products started to be a very important aspect because of innovation in the market and what customers demanded, right. So  Zafin’s been around for a long time, but over the last four or five years, things have really, really taken, taken off.

DM: Yeah, I can see now, I put some of the very first banks online in, 97 to 2001, right. And then that was the beginning of the Internet era and we were talking about like the high street’s been shrunk into a 14-inch screen. That is how big our monitors used to be, right. But, when you have that, you can do the comparison on these products, so much quicker, so much easily that actually the product definitions are now have become far more important than they were, pre the Internet and pre-mobile, right?

SD: Yes!

DM: Really, although we talk about the Internet banking starting in ’97, ‘98, right? It really only took off after the smartphone in 2015, right? Well, not 2015.

But 2015 was like the year it kind of really hit over into the mass market. More than 50% of clients, of banks clients were using Internet banking, right, because of the accessibility of things like smartphones, right?

So that all makes sense.

And now, what you are saying is well, fintech’s added another pressure because not only was everything much more comparable, but they were innovating faster than the banks on the stuff that customers wanted to compare, right. So that makes sense now, why you want to have a catalogue now and a single way of defining products separately?

SD:  Absolutely.

DM:  Have I summarized it correctly? Am I not putting words in your mouth?

SD:  No. You absolutely summarized it really well.

DM: OK, good, good.

Going back to the previous question though which was really about like the spread, is it global or is it more localised? I asked that because when I was, I guess I am more focused on Europe, and in Europe, I see a lot more projects started not always finished in around core replacement but in the US, I just do not hear core replacement being even muttered.

It’s almost like there’s no point in mentioning because nobody wants to do it.

Is that kind of right?

SD: That is absolutely right. Like, no one, none of the banks that I am dealing with in North America are even thinking about a core replacement. Everyone is thinking about core modernization. Some are thinking core modernization with a new core.

Some are thinking core modernization without a new core, but no one is thinking they are going to do a core replacement and they are just overly complicated.

DM: OK. And just to, again, I’m sorry, I’m taking a slightly different tack as well. On the modernization topic, we know that Zafin can help on the catalogue and the product definition side of things, right?

You also mentioned that you could go to another vendor for the customer management side of things. Is there any other kinds of modernization that people can do?

SD: Those are the first two starting points.

DM: Yeah.

SD: Yeah, the first two starting points are typically product catalogue and that means you know product, pricing, fees, and rates and offers and rewards and all of those capabilities and then the customer master.

Those are the two big blocks that I see most clients are, most banks are going down.

DM: And what about anything small?

I mean it’s funny because with tech companies they want to jump on a bandwagon, but they provide very niche components.

But I saw a company the other day that do market data distribution, right.

And they are essentially a layer on top of the Kafka, the messaging layer and they scale it really well and they take pressure off the legacy system. So rather than every single request going to the core banking system, they cache some of the data and they stop it almost at the edge of the network, right, and distribute from there.

And they have started talking about modernisation as well. And I am thinking, actually that is a form of modernisation.

It’s not a business modernisation like you’re talking about, like the catalog for the customer management, but it’s a technical modernisation of well, if the core can’t take all these new requests that are coming in, let’s take the pressure off and do it at this edge layer, which I thought was fascinating, and it kind of means that, there is this, it’s almost like CRM is a given for every kind of company.

It’s like modernisation is looking to start to be part of every kind of bank, I guess.

SD: Yeah, yeah, I’ve seen some of those as well and I have probably implemented some of them as well in terms of, when you think about the number of core systems a bank has and it is quite a few. And those systems of record are data silos, right?

The data is locked up in those different systems of record, and unlocking the data and streaming it out of those systems of record and making it available for querying for reading as a high performance cache after it’s streamed out and you could move all your reads from all your legacy application over to this new high performance cache.

You know moving reads off the legacy, especially mainframe, right? Moving reads off the mainframe and putting it against a cache that is near real-time has been a strategy that has been used many, many times, right. And it does work well.

If you are modernizing a customer master for example, you typically want to start by let me create a proper replica of this customer master in the modern state and I will coexist the legacy customer master and the modern customer master.

I’ll keep them in sync and then I will start by moving the reads off. Now I have all the reads are going to the modern one and I will see how things work and then eventually I will move the rights over, right.

But that progressive modernization of getting the data and saying moving reads over then slowly moving writes over mitigates risk because you could flip back and forth if you needed to, right?

DM : Great. And maybe one last question and we are going to drop into the technology now, right? Because I do like to try and appeal to as many people as possible, but I do love my technology too, right?

So when we talk about modern software versus legacy software, what does modern software look like?

What is it to be cloud native and APIs and what are the things that they should have a modern piece of software?

SD:  Yeah, so a modern piece of software. Typically, you hear the word ‘cloud native’ very often, right? And what cloud native means is that I can run in the cloud and not just run in the cloud.

I take advantage of the cloud, right. And the cloud has a lot to offer, right?

It’s not just about “hey, I’m horizontally scalable and I can take advantage of the on-demand elasticity and I can horizontally scale up and down”. But it’s also about taking advantage of the services that the cloud offers.

If you look at Azure, you look at most of the clouds, they have a marketplace of services.

You want to take advantage of those services which are fully managed that you can instantiate with a click of a button. You want to leverage those services, so you don’t try to build those yourself.

DM: What services are those?

SD: Whether it’s a database, you mentioned Kafka, whether it’s Kafka, you want to use fully managed services that you turn on with a flick of a switch and not waste time on doing those things that are not critical to what you do, right?

DM: Right.

SD:  So being cloud native is important. Microservices architecture and an event-driven architecture are also important. Microservices obviously you do not want to be a monolith. You want to be able to deploy multiple times a day. You want to give them squads that are developing the software, the freedom and full end-to-end accountability to manage their product and so on.

And people think about microservices and it is usually a technical discussion, it is actually less about technology, it is more about the how and the people and how you structure your teams and so on. And event-driven, because everything is moving to near real-time now and obviously Kafka played a big part in doing that and how you build software is so important, right.

Just like I said, microservice is more about the how, how you structure your team full stack squads into an accountability, use pair programming, use test-driven development.

Those are all aspects of modern software engineering that we need to adopt, right.

DM: So, I am going to try and summarize this for kind of business people.

Being cloud native means that you can take advantage of expanding the hardware for scalability and performance as well as the software for scalability and performance as well.

It means that you can take advantage of the facilities that are in the cloud, things like databases and stuff like that easily, right?

SD: Yes.

DM: Microservices mean that you are not writing one huge piece of software so that even if you make the tiniest of change then you have to ship the whole thing again.

If you ship the whole thing again, really you should have to test the whole thing, which means that you only do changes you know once a quarter at best. Sometimes once a year, right?

So it allows you then to deploy on a daily basis if you want to, right?

So changes can be much faster, but you are only making, you know, a small change means one component gets shipped not, the whole suite of software.

And then one moment, have I missed anything?

SD:  No, I think event-driven?

DM: Event-driven, yeah that’s key as well because we’ve come from a world when people used to come into branches or they ring, but now literally they can get notifications and it’s a two-way conversation in real time that’s happening on your phone or any other device and therefore we’re doing more of it, right.

SD: Absolutely.

DM: So that has more pressure on the systems, but it literally means we can’t afford to go down.

And for people that are old as you and I, we know that some banks are still having to switch off their mainframes at night. So, they do their reconciliations over a batch window. I mean that this is just mind blowing for me that banks are still having to do that.

But yes, that happens that ledgers are being reconciled overnight and so therefore in that period, they cannot do anything really. People have come up with solutions that allow you to switch it off and then carry on temporarily on the outside, right.

But yeah, so this event-driven architecture is also really important for real-time world that we’ve kind of moved into, right?

SD: Absolutely,

DM: Absolutely fantastic. I feel like we have covered so much ground. We have defined legacy, we have defined modernisation, we have discussed some of the challenges of modernisation, and also the pros and cons behind it, the different styles of modernisation. We have talked about why banks, even with a new core, could benefit from modernisation.

And then finally we talked, really, about or defined what a modern piece of software is. What a valuable podcast you have helped me create. Thank you so much for your time!

SD: Thank you so much, Dharmesh. It was a lot of fun chatting with you.

DM: Absolutely.

DM: I look forward to the next one.

SD: Absolutely. Thank you so much.

Play
View transcript
Banking Blueprints
Banking Blueprints
Breaking free from legacy systems: advancing banking through core modernization
Loading
/
Episode 2
In this episode of Banking Blueprints, we unravel the complexities of modern banking systems, where innovation meets tradition and shapes the future of financial
Banking Blueprints
Banking Blueprints
The next generation of customer experience: How product innovation is your bank’s next top priority
Loading
/

In this episode of Banking Blueprints, we unravel the complexities of modern banking systems, where innovation meets tradition and shapes the future of financial services. Learn why banks must reimagine their products and pricing strategies today to ensure the future of their banking operations and provide new value propositions for clients. 

Join host Dharmesh Mistry and special guest Charbel Safadi, Chief Executive Officer at Zafin, as we discuss how banks can unlock new capabilities and uncover the strategies that will define banking success in the digital age. 

Transcript

BW: Welcome to Episode 2 of Banking Blueprints! In this episode, we unravel the complexities of modern banking systems, and engage in a thought-provoking discussion about the delicate balance between customer experience and product innovation.

Learn why banks must prioritize product innovation and reimagine their products and pricing strategies today to ensure the future of their banking operations. Join host Dharmesh Mistry and special guest Charbel Safadi, Group President at Zafin, as we discuss how banks can unlock new capabilities and uncover the strategies that will define banking success in the digital age.

DM: Welcome everyone to the Innovation Beyond Core podcast hosted by Zafin.

And this week I have a very special guest, Charbel Safadi, and I’m going to ask him to introduce himself and just tell us a little bit about his role in Zafin.

Welcome.

CS: Well, thanks a lot. I’m not sure I’m that special, but name is Charbel Safadi.

I’m the President of Zafin. I’ve been here since the 3rd of January this past year.

And prior to that I spent 20 plus years in consulting at IBM, working in financial services and many, many other industries. And my role effectively today at Zafin is to lead a lot of our product and client delivery initiatives across the organization. So quite excited to be here with you and to spend some time talking about product innovation.

DM: Fantastic.

Look, in this episode we’re going to discuss why you think customer experience is not as effective strategy as product innovation.

And you know, just a caveat on this is I’ve been doing the web and putting banks online for far too many years. It’s well over 20 years. I think the first bank I put online was in 1997 and since that time it’s all been about customer experience as far as it goes from like a web or a mobile perspective.

You know, banks have been told consistently that they have to focus on the customer experience.

A poor experience means that you’re going to lose the customer, blah, blah, blah.

But tell me your perspective on this, right?

CS: Well, hopefully we don’t start a big, you know, a big debate in the market around what, whether it’s customer first or product first.

It takes me back to when I went to Business School around what comes first, strategy or structure, structure or strategy. But you know if I if I think about it and the way we’ve been thinking about it from it’s not even as a from perspective it’s a Charbel perspective.

I think customer experience has been the area of low hanging fruit for the past many years, right. If you think about the advent of the web and then mobile first capabilities, a lot of the organizations gravitated to creating and constructing experiences. If you think about it, it kind of makes sense in terms of where the market started and where bank started. Because even though you could construct product innovation, if you can’t deliver those products in an experience that customers can consume in a very simplistic way, then the product construction, the product innovation and the product dynamics don’t really come to life. Now having said that, there’s also complexities on how to construct product innovation.

So I would argue that customer experience has been easier to support and bring to market, whereas product innovation is very, very complex and nature of that is how banks, as you know, Dharmesh, they’re actually been structured over the past 20-30 forty years. They’ve been vertically structured, right. So each product sits in a vertically aligned part of a P&L within a bank and then the underlining systems associated with that are also vertically structured. So, so I would say product innovation is something that banks and financial services organizations are very much focused on. But it’s much more difficult than creating an experience layer that allows them to consume and abstract a lot of those product systems that have existed for many, many years, if that makes sense.

DM: Yeah, yeah, it does. And you know, like we, we in the previous episodes, we kind of discussed a little bit about the things that hold back the innovation, right.

Largely to core banking systems, right. That’s really what that’s been the holding them back from driving some products innovation, right.

CS: Yes.

DM: I mean I have to defend the customer experience side of it a little bit because

CS: –which is good, I’m good, I’m good with that.

DM: I only say that. I only say that because where you said it was easy.

CS: Easier, easier!

DM: OK, OK. It’s easier to kind of address the customer experience than to change your core banking system to drive innovation. That I totally agree with, right. I mean, there’s no dispute and I don’t think any bank is going to dispute that, that they–

CS: Oh, I don’t think so.

DM: –Drive, you know, a better experience or work on the experience better than they can on their cores, right. So that’s not disputed. The tongue in cheek part of this is really that I still see banks you know struggling with customer experience. I’m like, by goodness sake, just copy somebody else’s great experience.

CS: But they’re much if you think about it right, they’ve gone as far. I mean, we’re generalizing for the most part. But if you think about the mobile first era, you know post the web era, they’ve gone as far as they can with the limitations that exist around how the products actually are designed today, where they sit, how they live, all the constructs behind the product. Like if you think about a product, a single product within a bank, if you go into the DNA of that product and this is, you know, I talk a lot about the DNA of a product.

There’s over 200 dimensions and attributes of a product within a bank.

And you multiply that around 4 to 500 products across an organization that are active and probably another 2 to 3000 that are either dormant or you know a grandfathered in, you start to see the web of complexity that that make up the product ecosystem within a financial institution.

So when I say easier from the experience layer perspective, yes, as in terms of presentment, being able to show a unified front and be able to browse the various capabilities of products, that’s been accomplished or being accomplished.

And the various degrees of success are dependent on the bank and the right strategy and right execution of that strategy. But we’ve we’re coming to a place where there’s only so much more you can do at the experience layer, right?

There’s only so many origination workflows and ecosystem workflows that could stitch things together. It’s getting to a point where product innovation fundamentally has to change, like the way products are structured, both from a technical dimension perspective, but also from a business orientation.

The way the business model is executed in a bank, the way the P&Ls are structured, the way you start to think about loyalty and horizontal capabilities around product design and product construction to serve the client through an amazing customer experience layer is the era that we’re entering into which unlocks a lot of I would say value to both the end customer to the financial institution around stickiness, loyalty and wallet share.

But it also introduces a dimension of regulatory complexity and understanding the presentment, the suitability, the eligibility and how these products are brought to bear.

But I would say it’s a necessity now, right. We’re reaching a stage in our match where the product innovation, the product transformation, the business model evolution in banking is now a necessity, no longer an optionality.

In my mind.

DM : I’m going to come back to that because that’s a really good point. But you know, just going back to the experience side of things, you know, we, we, we love to talk about Uber experience. So great.

DM: You know, I don’t have to carry any cash and I can see where the cab is, etcetera, right.

And you know, I even I’ve written several articles on Uber-izing banks and stuff like that, right.

And then you know, lo and behold, literally every kind of taxi company has somehow managed to cobble together an exact same experience. You can, you know, load up your, your cards, you can see where the cab is, you can order one, choose the different types of cars that they’ve literally copied the Uber experience. So the experience is no longer the differentiator, right? And that’s, I guess, you know, one of the weaknesses of experience is that it’s not very defensible, right?

Like, you know, as soon as it’s out there, like every bank.

Now you can—not every bank–

CS: –but the vast majority of banks

DM: — from the fintechs, right, that you can on board somebody without them having to physically go into a branch and and provide a physical signature or physical copies of their passport and things like that.

You can do it all online in, you know, a matter of minutes, right. So you know, once somebody has, you know, created a compelling experience, it’s actually the, the problem with that is it doesn’t last for too long, right. So my point on the product innovation is, OK, so is product innovation as easy to copy? You know, what makes it more defensible than the customer experience?

CS: Yeah, no. It’s you’re making a very valuable argument in terms of where we are from an industry perspective, right?

The experience layer, it can be easily replicated.

It has been easily replicated and continues to be easily replicated and you reach that.

You know, a lot of these organizations have reached the me too mindset, right?

They’ve all from an AML KYC verification to origination to onboarding.

It’s pretty much the same, right? Anybody can open an account in less than 5 minutes. That claim to fame was great in 2010, 2012, 2013, but absolutely now we’ve reached a place where what’s next?

And it’s your point, product innovation is not an experience layer there.

There is a lot of sophistication and complexity that if banks do it right, they have a competitive advantage both from a market share perspective, but also in terms of competitors copying that dimension. You think about, you think about, you know, changing a product. It’s not creating a new mobile app capability. It’s fundamentally going back into the deep part of the organization both technically as well as structurally in terms of how the business model operates. And you’re effectively re-engineering a lot of the processes and the technology aspects. And to the point of the taxi cabs, you know, you think about those organizations, they effectively have one core right.

Whereas in banking, you know, credit card is a core, mortgages is a core, deposits is a core. All these products sit in these different systems and all the business units operate, you know, independently.

Yes, it may all surface up to 1 leader who runs for example, retail banking. But structurally the way the P&Ls are oriented, the way they’re effectively measured in success is individual product dimensions versus the notion of reimagining products to become more horizontally aligned.

And that’s where the banks that actually are spending the time, effort, energy and focus on this and money are going to be in a very competitive advanced positioning than the organizations that are still thinking about it. And the advent of a lot of the fintechs is they don’t have that history, right. People think that the fintechs are constructing phenomenal experiences.

The only reason why the experiences are phenomenal is because they don’t have the complexity on the back end. So they can’t construct these very unique product propositions that are very much horizontally aligned, that create the notion of depth and loyalty where you’re rewarded for net deposits and total deposits and they start to unlock capabilities and features across our product sets.

That’s something that they can do that effectively creates this phenomenal customer experience. But the experience is constructed on the back of product innovation, not purely from an experience layer perspective. So they’re symbiotic in my perspective that we’re reaching a stage where you can no longer create transformational experiences without product innovation.

DM: 100%. Yeah, no, 100%, I agree with you. I mean, you know, a lot of the banks, you know, I can feel the frustration in some of the banks, right?

CS: Yes.

DM: Because the fintechs have come in with no legacy systems, with no legacy business, you know, into an environment that’s, you know, purely digital. So they’ve been able to do things far quicker, far cheaper and you know, far more easily than a bank.

It’s not because they innovated necessarily. Banks have had these ideas, but they’ve been held back by their systems. They’re as you say that you know the different course, each one of them has their limitations on how quickly you can put change out, right.

But the fintechs haven’t had that.

And you know the other advantage that a fintech typically has, it’s a monoline products, right?

It’s one product, it’s not mortgages, credit cards, accounts that are there, right.

So, so I think you’re absolutely right.

You know fundamentally, you know the defensibility is those that have the power a system to allow them to define products easily, right, are going to gain competitive advantage against the banks that are still sitting on old cores with old ways of defining products, right.

Because I would agree.

DM: You know the case in example is like when I talk a lot about like product innovation, how bad banks have been at it. But I know the reason it’s because of their systems, right.

CS: Sorry to interrupt but the reality is a lot of the innovation ideas come from the banks like they know like the reality is, you know, you get consultants and I was a consultant.

You know I’m a recovering consultant and we go into these financial institutions, these banks and say oh you got to do this.

And they’re like, yeah we thought about this. We know this, right? We know that we need to do this, but what’s holding us back right is, is, is to the point that you’re making, is history. And you know, incumbency is, is a competitive advantage. But it’s also it could hold a lot of organizations back and the organizations that innovate during incumbency and reimagine the way they think about their product models or product designs.

And what we coined at Zafin, as an example, is this notion of a new product architecture, right?

It’s ‘how do banks think about the bank as a product’, right, in its entirety. And the capabilities of the products unlock themselves based on the experience of the client with that financial institution.

And we’ve been spending a lot of time, effort and energy in our organization trying to create that layer for banks to give them the opportunity to start to construct these new product architectures that fundamentally leapfrog them in the marketplace.

And that’s where I think a lot of organizations I’ve spent time with over the last six, 7-8 months having these conversations around how do you really get to new product modeling? How do you get to new product architectures?

How do you start to get to a place where products are looked at horizontally and served to the individual from a client experience layer perspective.

But, effectively, you’re absolutely right.

The next generation of client experience will only be derived, from my perspective, through product innovation. There’s only so much more tweaking we could do at the experience layer, at the UX layer, at the UI layer, at the orchestration layer.

Everything else now needs to come back to what is my product, what is my value proposition and how do I individualize that product through an amazing experience to that customer.

That the notion of ‘segment of one’ as you know has been discussed ad nauseam for the past 20 plus years. But the ability to serve that means that I could serve products unique to that individual not serve a new UI with colour schemes to that individual, yes.

DM: Yes, so I mean I guess you know this in answer to the question of, you know, is product innovation defensible.

CS: Absolutely.

DM: The reason it’s defensible is because everyone else isn’t able to create the parameters or the product as easily in their in their older systems, right?

CS: Correct.

And you know what, what’s interesting, it’s like you don’t even have to really innovate, right? More recently, if we look at, if we look at the very basic fact that inflation has driven interest rates up, right and now savers are expecting higher rates.

Yet in the UK the only players to increase their savings rates, right, which is beneficial not only to the end customers but also to the bank themselves, have been the new banks like the Monzos and the Starlings, the peoples that are on modern core banking systems been able to make that rate adjustment very easily, right.

So even at that level, a simple change is going to take, you know, six or seven months, right? And that’s why it’s defensible, right?

CS: Well, that’s why it is defensible. 100%, right. It’s a simple change.

DM: If you want to do something brand new like BNPL, well, how many banks have got that? Because that’s a whole new product set, right? It’s not, you know, tinkering with a rate or a charge anymore–

CS: Correct. You think about the deposit outflows right to the point that you’re making right if Monzo or even you know in Canada, Wealthsimple as an example, it’s everywhere, right? These fintechs giving you 5% interest for example, on your checking account. Think about that right, in Canada, on your checking account. On your payroll deposit, the money that comes in from your payroll that lands in your payroll account, the current account is earning you 5% interest right now how do you square that away if you’re a traditional bank? The argument is fintechs don’t have incumbency, but what they’re doing is they’re chiseling away, right?

I envision this big boulder and what they’re doing is just chiseling, chiseling, chiseling and these moments of high interest rates are giving them the opportunity to chisel a bit faster than customers, right. And once, once customers make that pivot because the notion of switching is a very difficult proposition for a lot of these clients, but when they make the switch, the ability to bring them back becomes a much more difficult proposition.

So I would argue it it’s defensible, but it’s a necessity at the same time because you have to have an outlook of the next three to five years, right, not today: outlook of three to five years. Because if you don’t start to create these compelling product capabilities, these innovative products, these products are cut across the verticals. You’re effectively putting yourself in a non-competitive landscape of organizations that are chiseling away at the customer base.

And at some point we’re going to reach that tipping point where if you haven’t innovated, your ability to compete and survive become a very difficult proposition. I know a lot of people say, oh, that’s a, you know, that’s we’ve been saying that about banks for the past 20 years with the advent of fintechs and Open Banking that effectively the incumbency will diminish.

But it is. It’s diminishing, right?

And it’s about looking at the long term, making changes today to support the capabilities that clients expect today, but also the next three to five years. Because if you’re not prepared, we’re going to reach this tipping point where it’s going to go from left to right very quickly.

DM: Cool. I mean, I so you know, I’ve made note of a few questions etcetera, and I think that’s kind of all of them… You know why haven’t banks focus more on product innovation and I’m like I’m guessing you know the core of this answer is because of their legacy cores right, because they’ve been haven’t been able to?

CS: Yeah.

DM: Anything else?

CS: You know to give you some perspective, you know every conversation I’ve had with Head of Retail, Head of Lending you know our conversation we’re having with our corporate commercial client base, they’re all thinking about this. It’s become a priority, right.

But I think that the way you’ve answered it is, is, is the area of their concerns.

So from a business perspective they all need, they know they need to innovate.

What’s good of what’s happening in the marketplace is the need to innovate on product has become a top priority.

The question is how? How do I innovate? How do I reimagine the product design?

How do I see what my competitors are doing?

And then how do I make the fundamental changes without waiting for the next three to five years to replace a core system that will allow me to innovate.

Because innovation cannot wait five years from a product dimension perspective, it needs to happen now.

So, I would say we are seeing the interest spike. We are seeing it become a priority and become part of the strategy of a lot of these organizations. I think what they’re trying to figure out is how do I accomplish that and make that a reality in the short term, in terms of bringing value to clients, but also create a sustainable innovation life cycle around product design that allows me to continue to sustain product innovation because fundamentally product innovation, you think about any, any, any industry, right?

You think about this, Dharmesh, you think about, you know, the electronics industry, you think about our phones, right? Imagine any one of these providers just stopped innovating their products, right?

Imagine that.

Imagine Apple decides that we’re stuck on iPhone 15 for the next six years, right.

What’s going to happen? There’s maybe competitive pressures. They’re eventually going to go out of market. Their market share will come down significantly.

So I would say we are seeing the advent of product innovation as a priority at the board level and at the most senior executive levels of a lot of organizations we’ve been spending time with.

The question they’re asking is how do I accomplish it with speed?

DM: Yeah, Yeah. I mean, it seems like on the electronic– The thing is you brought up the analogy.

I’ve looked at some of those companies like your Samsung’s and Apples, etcetera, right. But they not only have a road map for their products, they’ve already tested features and functions and they’re holding back the innovation. I mean like the innovation that we see on a new release is only what they’ve decided that they want to put out this time round.

And if you know, three months down the line, Samsung has issued a phone with a new, let’s say, GPS device, etcetera, you can bet your bottom dollar that Apple has probably been sitting on that innovation thinking, right, OK, we’re going to launch that in our next phone.

CS: But if sounds like we have a library, it’s like we have a library of innovation. It’s ready to roll, right?

DM: And this is where banks need to be, right, is we’ve got this roll call of stuff that we’re going to put out on a regular basis, right. But we’re going to, we’re going to be in control of it, not held back by anything else, right.

CS: I think you just hit on the point where you know when you started the conversation around customer experience, I just believe product innovation is the new frontier for customer experience innovation, right.

A lot of these financial institutions, these banks spent the last 10 years in innovation labs, digital entities. They’ve constructed all these sidecar initiatives. But to the point that you were making, they were all focused on innovation at the mobile layer or at the experience layer, right, Which is understandable because you know, customers were expecting that level of simplicity.

But I would argue, you know, the focus now needs to be to the point that you just made, which is deep product innovation, the core of what they do, you know, a bank is 2 things, its customers and its products.

I always say this, right, two things. That’s all a bank is.

It’s the customers and the products they serve those customers.

Everything else is a supporting cast.

And if you’re not focusing on the customer experience, which you know, a lot of money and time and effort and energy has been spent there, and you’re not focusing on product and product innovation, that means you’re not focusing on your business. I just still adapt to that simple level of one side of the coin is the customer, the other side of the coin is the product.

Now we’ve reached the place where if the product innovation isn’t heavily invested in and it’s not focused as a priority on a continuous basis, then you’re always going to be you know, one step behind, not one step ahead.

And this notion that a banking product needs to stay idle and dormant and the way it’s been structured for 10 years, I think we’re well past that notion. And for any organization thinking they could get away with that and then when a customer needs a different product they have to do with this crazy product switch mindset.

I think they’ve lost the plot. So fundamentally, I’m well-aligned with the way you positioned it and I do think product innovation must be the top priority for a lot of these organizations.

DM: Yeah, I mean, again, you know, I’ve written about this before where, you know, I’ve said, look, you know, an 18, like a child, an 18 year old, a 35 year old with a family and a 70 year old, you know, that’s retired, all probably have exactly the same current account. You know, if they went to the same bank, they all probably have the same account, no differentiation whatsoever.

And that’s got to change because, you know, our needs as consumers are totally different in each of those life stages, right. Yes, there are variations that you can get, but they ain’t too great, you know?

CS: Yeah, but let’s be clear, right? Like our perspective is product innovation doesn’t mean it’s just purely financially constructed, right?

A lot of the technical investments that banks are making in technology, those features can also be attributed to a part of a product design, right.

So, so if you’re if you have net deposits of X as an example, not only do you get this interest rate and these benefits and these features, but they also unlocks technical capabilities like you know, dynamic tagging or analytics, complex analytics or third party ecosystem capabilities.

You got it, you got it. So, so you know the bank spent a lot of time thinking that we are tech companies with a banking license.

No, no, let’s get back to being a bank that you know has products that serves its customers but also is technology-centric where the technology investments can also be monetized as part of the product modeling.

And I would even go one step further. The customer experience layer, right?

The ability to call into a contact center, the level of prioritization ties back to the value chain.

And you know who’s done this really well?

Airlines have done this really well. Right? Well, that’s not to say the airline experience is outstanding, but if you think about the loyalty dimension and the way they’ve monetized every dimension of their product model within an airline, they’ve done an effective job about creating stickiness, loyalty, right, as well as monetizing all dimensions of the product modeling.

So, So I’m not to say, you know, banks are an airline, but the notion of creating that loyalty, that stickiness and this continuous product innovation is going to be a necessity for every bank we foresee going forward.

DM: OK. Look, I’m going to play devil’s advocate on this question, right? And see how you bite.

CS: It’s all good. All good.

DM: Right. So like an account is an account, It’s got rates, it’s got charges, you know, it’s got maybe some reward points, etcetera. I mean, how much more can you innovate on a basic product like that? Yeah? I mean is, is there really opportunity for innovation on all these financial products?

CS: Well, individual, so you make a very, I like where you’ve opened this up and you and I did not rehearse this. So this is wonderful.

I would argue if you look at one product and that product that stands on its own and it’s a current checking account, whatever type of account it is, there’s only so many dimensions of attributes of value you can construct around that, right as a stand-alone product, as a product of 1.

So yes, you could give it, you know, loyalty points, maybe you could do six ATM withdrawal fees or maybe unlimited.

You can maybe create priority support. But where the value starts to come in is when you start to look at products as an end-to-end value chain across all product dimensions, right.

If a bank is trying to win on a checking product, they’ve lost the plot, OK.

Winning a customer is not about, you know, we’re all consumers and we don’t bank with a bank because we want one product. We need many products to live our lives.

We have families, you know, there’s tuition, there’s investments, there’s mortgages, there’s all these different things that we need. And banks play a very important part of our lives in multiple dimensions, from our lives to our partners’ lives to our children’s lives to our futures.

So if you think about it from that dimension, there isn’t a significant amount of product innovation that needs to occur when you start to bring products together.

This is what we coined the new product architecture. It’s effectively decoupling all the features of a credit card, of a mortgage product, of a savings product, of an investment account and be able to bring them together and start to design a proposition that’s unmatched, that’s unique to Dharmesh or unique to Charbel.

And that’s where we see the product innovation pivoting to, but to achieve that you need to be able to start having the capability to innovate on that checking account because you can’t even innovate on that simple checking account. Then how are you going to do everything I just said which is this multi-dimensional new product architecture that really focuses on the experience of the consumer through product innovation?

DM: Right, right, right. So let me backtrack a little bit on this.

So what you’re saying is there is, you know, I mean if you’ve got 200 odd parameters around a single product, that’s a lot of factors that you can control anyway. But when you start to combine that with other products, so let’s say behaviour on your deposit account and your current account, affects rates or rewards on your investment account, those combinations create a new product behaviour, right?

But, from one product driving behaviour in a different product, that’s what you’re saying, right?

CS: That’s exactly what I’m saying, which is now we’re focusing,

DM: I love that!

CS: But it goes back to how we started the conversation, the customer experience, right.

So, so you are no longer creating an experience that is you know one to many, you’re now creating an experience that’s behaviorally driven which means the product innovation, the product capabilities across the horizontal dimension of the bank start to unlock the value proposition to the behaviors of the individual.

So the more I engage with the bank, the better the bank engages with me.

The more experiences that I get, the more value that I get from mortgages to lending to deposits to all the dimensions of my financial well-being as a as a consumer.

And that’s, that’s the competitive advantage.

That’s where, you know, the fintechs are not encumbered with the past where they can start to think that way, construct that way and model it that way. And not only that, the notion of a new product architecture is that everyone starts at the starting point, OK? But your behaviors, your investments across all the product sets start dynamically unlock capabilities

So as you engage more with the bank, you, you, you create more loyalty with this institution.

The institution is more loyal to you, it gives you more and it creates more value for you and it helps you live a better life and it focuses on your well-being, versus treating everyone equally, the same.

It’s not about treatment of the individual, but more of the way the product model is structured that the product capabilities start to dynamically adjust themselves based on the engagement of that consumer.

So that’s where we think and we fundamentally believe and I fundamentally believe that product innovation, this notion of a new product architecture is going to be the competitive advantage and the banks that achieve this or begin the journey to achieve this will be lightyears ahead of any of their competitors

DM: Yeah, yeah. I mean it’s interesting because you mentioned earlier on and I’m big fan of you know the one to one marketing side of it. But what’s actually happened in the decades since that book was launched is people have kind of like, oh we’ll have, you know I’ll tell you what if it if it’s a Platinum customer, we’ll you know change the content, we’ll improve the layout, the colours, whatever–

CS: New logo!

DM: –personalized the experience. Well, great. What you’re talking about is personalizing the products.

CS: You got it.

DM: –dynamically based on what they already have.

CS: I mean the holistic products, all of the products and they all work together in the in this dynamic way where my engagement with the organization gives me a unique product proposition that’s unique to my behaviors, my engagement and my commitment to that organization,

DM: OK, I mean that sounds compelling to me.

CS : It does.

DM : How does the bank do that if they’ve got multiple cores?

CS : So, so the reality, the way we position it, you know and I’ll use my Zafin hat just for a second and—I tend to give you my opinions, my personal opinions, but what we’ve been spending a lot of investment in R&D and our product development teams is the ability to take product and pricing out of every core.

So, so we we’re working with organizations that have 18 cores, 17 cores.

You know that they use you know hosted credit card core, excuse me, and our on-prem deposit core. What we’re doing and we’re starting the journey of this notion of core modernization to product innovation is by externalizing product and pricing outside of these cores into our Zafin SaaS platform.

And by doing so, it doesn’t necessitate or require the core replacement.

But what it allows for is these dynamic product experiences that we’ve just been talking about to unlock and start to be able to provide these capabilities and allow the CIO’s office and the CTO’s office to begin their progressive core modernization journey, while the business is effectively being able to create these unique product architectures today, not two years from now, five years from now, but today.

So two things are happening.

We’re taking product and pricing out of these legacy cores and we’re centralizing them in a next gen SaaS platform. And by doing so, it unlocks the progressive journey for the technology teams, but it also creates the value proposition for the product teams that are responsible for the P&L’s of the business

So we’re creating 2 motions, happening at once and that’s what, you know, from a Zafin perspective, we spent a lot of time doing this and we’ve launched a bunch of tools around this tool called Product and Price index as an example, where we go and we pull the top 250 banks marketable products off their websites and PDF documents using AI.

And we start to, every evening, we do this every day, every day and start to provide insight on what your competitors are doing and what their rates are and what their structures are. So we’re starting to bring that research capability to our clients so that they can understand what the market conditions are.

And we’re also doing this internally, the ability to bring data in and allow them to understand the DNA of all their internal products and then unify that to be able to construct and design propositions of the future in these new product architectures. So, to bring that all together, you know we launched this thing called Zafin Studio which is effectively the co-creation and the tools required to be able to start to think about new product architectures end to end. So that’s the plug on the product. I appreciate the ability to plug that just for two, two minutes there.

But, but fundamentally we’ve been spending a lot of effort, time and energy on the new product architecture capabilities for the business, all while still managing our SaaS capabilities that allow us to begin the progressive core modernization journeys for our CIO and CTO partners.

DM : Yeah, I mean, I’ve been speaking to your team quite a bit and you know, the revelation to me on the modernization piece was the ability to actually hollow out the core so that it essentially becomes a ledger. While you know, a platform like yours starts to handle the product lifecycle from researching what the product needs to be, look and behave like to defining the product and then publishing the product in its own lifecycle based on the modern stack. Which means it will be done much easily and more cheaply, right?

CS : 100% you, you succinctly, you succinctly positioned that much better than I did. So I appreciate that.

DM : I mean, look, I just try to simplify stuff. That’s what I need to do, right. So, but in all of this, it all sounds good to me, but the reality is in the bank, right, some guy, no matter how quickly you define the product, you’re still going to have to get through the product in terms of you know, regulations, does it comply, compliance, you know, audits, documentation, risk management, etcetera.

There’s a whole lot more to product definition in a creation than just the product features and its behaviour, right.

So you know can that be accelerated as well?

CS : So thank you, thank you for keying that up. You think about today, you think about the regulators around a regulator coming to a bank and asking show me, show me how you’ve done controls around product eligibility, product suitability. You have, you offered Dharmesh this product two years ago.

What controls were in place for this offer presentment or product presentment and was Dharmesh suitable and eligible for this product.

And you’d be quite surprised to hear a lot of the answers in terms of how long it takes to just investigate that type of contextual insight. So, so as I mentioned to you, this notion of the DNA of the product, these attributes that make up a product.

What we do inherently as part of our platform is around this notion of trust, transparency and fairness and banking and inherently as part of designing a product all the suitability and eligibility conditions are all constructed within our platform. So we become the notion of this immutable capability that gives us the ability to present in real time to whomever that needs to understand one during product construction, what was the risk rating of the product, when was the last time the product was updated. So we have all the auditability of all product dimensions in the life cycle.

But two, when it’s presented to a customer, whether a product is presented or an offer is presented or a proposition is presented, what were the conditions of that presentment and what were the behaviors that we’ve tracked that made that become a reality, the eligibility dimensions?

So all of that is immutable within our platform. We capture all that data, and we have all that data and all the reporting mechanisms to ensure that, in fact, you accelerate the compliance dimensions of what the regulators are expecting of a financial institution.

So by shifting to this notion of a new product architecture, product life cycle management within our platform and innovating new product modeling, you get the benefit I would say out-of-the-box that gives you the suitability, eligibility and the regulatory constructs around that information to be in compliance.

So in fact, you’re putting yourself in more compliance, in a position of compliance by shifting here then you are by having 16 cores all have their own suitability and eligibility dimensions and trying to track and trace that data for a single customer that cuts across the lifecycle in the current model today.

DM : Yeah, I mean, yeah, I can see how this pans out.

And you know what actually is amazing about this is that the more complex of product, it’s like no more complex to have all these, the compliance and regulation etc., because it’s actually just the standard way that it works. So it doesn’t matter if you create something more complex and dynamic and highly personalized, you just create a vanilla product. It’s all built in.

Therefore it just handles naturally.

CS : I mean that’s it handles naturally. It’s part of the logic of how our core engine operates, right.

It’s part of the logic. And not only that in some organizations what we’re doing is we’re creating what we call transparency capabilities that exposes and emits the, the, the transparency data, which is ‘why was Dharmesh offered this product’.

DM : Yeah, right.

CS : So they could not only that. You know, when we think about fee presentment, why were you charged a fee? Why was a waiver condition applied? All that data can now be put on a digital statement or through online banking. So a customer could understand why a fee was charged at the end of the month or why they weren’t charged a fee. Both ways. And all that data, because it exists within our platform, becomes another layer of presentment from an experiential perspective that does two things.

One, it gives them the confidence of the consumer didn’t say, you know, the bank is looking after me, They’re providing transparency and fairness data.

And two, it reduces cost because customers don’t need to call into the call center or the contact center to inquire about why was I charged this fee or why was this discounted.

That level of transparency becomes very important and if you could show that end to end, then what you’re doing is you’re creating a lot more trust in the organization. And then from, I would argue from a compliance and regulatory perspective, you’re providing that transparency data even further, showcases that, that a financial institution has the controls and mechanisms in place to ensure that trust, transparency and fairness is being applied equally to the consumer base.

DM : Yeah, I mean, I know we like to beat up the banks sometimes, but what you said to me earlier resonates because banks have been thinking about this for a long time and I go back to like my time in Lloyds Bank. I was there between 86 and 94, right. And in that time, I was involved in working inside the business.

So you know I moved from IT into the business to work on a few re-engineering projects and I remember in one of those we discussed personalized products, how do we get to personalized products and the big challenge then this was pre-the Internet, right? So you know the big challenge then was really like well, OK, firstly how do, how we will find this in our system and even if we could define in our systems, how do we get to train the staff and produce the material. And you know get this through, you know the compliance teams especially if it’s dynamic, right.

But things have changed now. We’ve got the Internet, we’re not necessarily selling through the branch and the call centers and brochures anymore. It’s done digitally.

So you know the audit trail is built into the process, right?

CS : Correct.

DM : And then second thing is obviously with a technology that isn’t monolithic that is you know like micro-services based or component-size now you can start to get the flexibility that you need to make these you know personalizations much more of a reality.

So you know, yes, you know technology changed, times have changed. But that’s why it’s–I’m seeing now that’s why it’s kind of possible now and it wasn’t you know, 25 years ago like you say banks have been thinking about this. It’s just not necessarily been possible for them before.

CS : Right. And you’re 100% correct.

And I would, you know, I would argue every time I go meet with a bank and their product teams, they have a list. You know what we talked about you should have innovations, you know, ahead of what you’re releasing. We have you know an extensive list of product innovations and capabilities.

But every time you ask them you know why haven’t you done it, it all goes back to the ability to do it from a technology perspective, it all circles back to the inhibitors which is why as I mentioned to you today for us as an organization we’re in the era now of product innovation and we’re in the era of helping banks execute that product innovation through simplification of the technology architectures.

So, so we’re in the right place at the right time, I would argue, with the right technology that we’ve invested significantly in over the years and that we continue to invest in from an R&D perspective to really you know to really show up and help these organizations effectively transform their business models through technology modernization.

DM : Fantastic, Charbel. Look, you’ve been very eloquent in in explaining this to me. I am, I am a convert. I am a believer of innovation. And I understand, I mean, more importantly, I understand you know how it’s possible, why it wasn’t possible before and you know why that you know, banks can do it now, you know, and why they should be moving towards this. It’s become really important. Thank you so much.

CS : Oh, thank you. I appreciate it.

DM : Definitely love to discuss this topic a bit more with you in terms of like examples and case studies of innovation, but you know, let’s save that for another day.

CS : Let’s save that for another time. And it’s retail, corporate, commercial banking, it’s all the way through. So we’d love to spend some more time on those use cases.

DM : Fantastic. Thank you.

CS : Thank you Dharmesh. Take care. Bye, bye.

Play
View transcript
Banking Blueprints
Banking Blueprints
The next generation of customer experience: How product innovation is your bank’s next top priority
Loading
/
Episode 1
Join Chief Marketing Officer, Bhavna Wadhwa and Season 1 Host, Dharmesh Mistry on the first-ever episode of Banking Blueprints, brought to you by Zafin.
Banking Blueprints
Banking Blueprints
Overcoming banks’ growth challenges: Identifying successful strategies for innovation
Loading
/

Join Chief Marketing Officer, Bhavna Wadhwa and Season 1 Host, Dharmesh Mistry on the first-ever episode of Banking Blueprints, brought to you by Zafin. How do you know when it’s time to update your banking platform, or what to upgrade to when you do? And how? Here to help discuss the biggest obstacles to banking core modernization is Dave Revell, Chairman of the Board at Zafin. Join us as we discuss impediments to growth caused by aging technology, navigating modernization efforts, and how to speak to tomorrow’s needs even if you’re using ASM or COBOL.  

Transcript

Bhavna Wadhwa: In the world of banking, even among some of the smartest and most thoughtful people, the code remains something of a mystery at many levels. Does legacy automatically equal obsolescence? When is the right time to update functionality? An update to what, exactly?
The questions go on and on, and the banking lives of countless consumers depend on the right answers.
To join host Dharmesh Mistry on the inaugural episode of season one as he delves into these queries with the core technology luminary Dave Revell, Chairman of the Board at Zafin, exclusively on Banking Blueprints.
Welcome to season one of the Banking Blueprints podcast.
Dharmesh Mistry: It’s a brand new series by Zafin and me, Dharmesh Mistry, and I’m super excited to be your host for season one. Throughout this inaugural season, we’ll delve into the realm of banking innovation, exploring strategies for breaking free from traditional constraints and innovating beyond the core.
Now as I clearly don’t know everything, although I’ve been around a long time in banking, I’m calling upon the experts to join me this time. And this week, I have Dave Revell, who not only is the Chairman of Zafin, but has a long history with banks.
And I’m going to let him introduce himself because he does a better job of that than I would do.
So welcome, Dave.
Dave Revell: Good morning, Dharmesh, and thank you for having me here today. As you mentioned, I’m currently Chairman of the Board of Zafin. I’m also a director on a number of other financial services companies and FinTechs. Prior to that, I was the Global Chief Information Officer for CIBC for about a decade. I had 15 years before that as the Head of Application Development, Strategy, Architecture, Business Reengineering at Bank of Montreal, and as a kid coming out of school, I spent the first decade with IBM in a variety of sales, consulting and marketing roles.
DM: You have similar kind of background to me where you’ve been on the bank side as well as on the vendor side. So it’s a good breadth to have, right?
DR: Yeah, I’ve enjoyed it. And I guess the other thing that I’ve been involved in for probably the last 10 to 15 years, I’ve been involved with early-stage companies as a startup. I’m an Angel investor, so I sit on boards, I give advice and I write checks for companies as well, which tends to focus the mind a lot when you’re looking at new ventures you might get involved in.
DM: Well, I’d wish I’d met you a long time ago because I’ve been through a few start-ups myself and I promised my wife after selling the last one, I’m not going to do anymore. Don’t worry I won’t be tapping you up for some cash.
DR: No problem.
DM: But great to have you on the show.
DR: Glad to be here.
DM: This week, what we really want to delve into is, we hear a lot of chat about, you know, banks are being held back by their core.
DR: Right.
DM: You know, what is the problem here? I mean really when I look at some of the things that banks are doing, they’re not really innovating products. The core actually works, it’s been there. Does it need to be changed at all? From your perspective, you’ve been inside these banks: what is the problem with their core?
DR: That’s a great question actually. And I have lived with this through two different banks over 25 years, and I’ve seen the evolution of the cores. And as you mentioned, the thing about the old core systems, the legacy systems at many large banks is: they work. They’ve been there for a long time. They’re effective, they’ve been tuned and they run pretty efficiently over time and they basically work to serve the business needs. I think there’s a number of issues but for me it really boils down to two.
And I think the first and major one is a question of agility, and agility would be both time to market and cost to get to market. So, for a typical large bank, the time from having an idea for a new product to actually getting that launched and delivered, you’re probably looking at best case maybe 12 months, probably more accurately 12 to 18 months to bring something to market.
And part of that is a factor of the huge complexity that’s built up over years with these systems, plus the fact that they are very difficult to work with, which leads into the next item, which is around skills.
So increasingly, it’s extremely difficult to get people that are trained that can actually work on the bank’s legacy systems. They’re not training kids out of school on the type of technology that legacy systems are written in. And yes, you can train people, but it’s not really considered an attractive path. If you’re a new engineering or computer science grad and you’re coming out of school, the type of skills you would need to do work on the legacy system are not typically something that you would want to gain up to speed on and putting on your resume. And in fact, the people that could train you on that at the bank that have been around for multiple decades and understand both the technology but also the complexities of how it’s written is rapidly diminishing.
They’re pretty much all on the retirement corridor. Many of them have happily retired, lots of them have happily retired and are now consulting back to the organizations because the skills are needed. But it’s becoming increasingly difficult to get the skills that are required to keep the systems up to date.
So other reasons as well, but for me, the two big ones as I said are agility, which is time and cost to market and the skills to maintain and to build on those old systems.
DM: I get that, and I’ve heard that a fair bit, but let’s not take it, you know, at that level. Let’s delve a little bit deeper.
DR: Sure.
DM: When we think about the time and agility, right, I don’t see banks innovating on a very rapid basis. It’s not like they’re bringing out brand new products very regularly. In fact, if I think about it, the last time in fact, if I think about it, the last time I saw a really innovative product maybe was the offset mortgage. Some might argue ‘Buy now, pay later’ has become the latest, but you know there’s a 20-year gap between the two. So, everything else in between could be really just a rate change or some basic terms and conditions. Is time and agility really that important that they’re not able to change their systems in time?
DR: Yeah, well, take the two issues you just spoke about there. Even things like simple rate changes, simple rate changes and minor changes to the products that are not considered dramatically innovative in terms of something new out to market, they still take a lot of time.  They take a lot of time to do because the complexity of these systems, you could have hundreds of interfaces that have been built up over the years, all of which need to be individually tested, they need to be coded, they need to be tested. So, the time you’d be quite shocked at the time that it would take to do things like quote unquote simple rate changes and things for products. It would apply to an increasing number of regulatory demands that are coming out that also require tweaks and changes to your product systems.
So my view is that it’s not just coming out with a new creative product, it’s the bread and butter. The basic products you have to do are still overly long and overly expensive to go and bring to market.
DM: I think a penny just dropped for me. If I’m paraphrasing you or putting words in your mouth, just say so, right?
DR: As long as the words are better, feel free to put as many words as you’d like.
DM: I think the penny is that it’s not about how long the change takes, it’s how quickly you can test those systems and deploy that update. Is that what we’re talking about here? It’s that, when you said it’s not just retesting the core, but because the core is integrated with other systems that rely on these products and their data, then it becomes a big task irrespective of the size of the change, right.
DR: That’s absolutely true. And you think about these old legacy systems, even the words we use ‘legacy system’ makes you think of kind of a single monolithic system. But in fact, what’s happened over years and over decades, these things have continued to grow and there’s kind of a spaghetti nest of systems that are connected into it that have been added on. So, when we talk about the core, the core is really a very complex series of systems put together. And again, hundreds of interfaces into other different systems that have built up over time that all need to be tested.
So if I took the example of a modern, newly architected core system, what it would take to do a rate change is often times it wouldn’t even need to be involved. It’s basically the business could sit down and on a screen being able to go and choose and change the parameters and get that out to market very, very quickly without technology really being involved. An old legacy system, because of the things we just spoke about, have all the testing requirements, have all the work that has to happen.
So it’s months and months and months worth of work. And if you think about the environment that we’re in right now, you think of what’s happened with interest rates in the past year or so. For me that would be something that banks have had to struggle with a lot, a rapid change in interest rates in terms of how do you meet customer demands, how do you change your products. And those banks that have had to rely on changing their legacy systems have been very slow to being able to respond to that both to meet customer needs or also to try to address just basic profitability of how the bank does business.
So, it’s a real inhibitor.
DM: So, I get this now is that the time factor is a combination of two things in effect, really. One is the fact that the core is a monolithic application. So even though there might be a small piece of code that really handles, let’s say, a rate change, it’s part of this overall suite that does everything, you know from onboarding the client or creating the account, operating the account, applying the charges, producing the statement, etcetera.
Now those bits may not have been touched, but because you’re deploying all of that code again with this small change in it, it all needs to be retested, right?
DR: Absolutely.  And you have millions of customers that are relying upon this.
So if I could put on my old CIO hat for a minute, the thing you hate as a CIO when you’re involved in changes like this is, although there’s many factors that are involved in launching a new product, the business needs to be involved. There’s a variety of other things. But when you look at it, the thing I always hated as a CIO is when we’re the long pole in the tent, when the time frame to get something delivered has this big bulge in the middle, which is we’re waiting on IT, we’re waiting on IT to code, we’re waiting on IT to test. And it’s never a situation you really want to be in as a CIO.
DM: I love that analogy of the long pole in the tent. So in my naivety, I guess part of me thought, well you know by the time you update the call centre people with the new product, by the time you’ve created new collateral, by the time you’ve gone through compliance and regulation and then rolled out, you know updates to the branches, IT would be ready. But actually, in my simplistic view was just thinking about the small change that we’re making, not about how expansive that impact has.
And also, you know, everything that goes behind getting out an update in effect.
And I guess this is where like modern systems that are based around micro services fundamentally change the game because you’re not deploying A monolithic piece of software anymore.
If you make an update to 1 micro service, you test the micro service and redeploy just that one bit rather than the whole thing.
And the way that it’s tested with its automated test scripts mean that anything that was consuming that service is automatically retested at the same time, but it’s in an automated fashion, right.
DR: That’s absolutely true, and in fact I’ll extend that a bit more. So, the whole promise of modern systems where you have isolated, you’ve got the API and you’ve got the micro service.
So yes, you just have to change the micro service, but in many modern systems you’re not even doing that. It’s parameter driven for things like rate changes and things. I’m not changing the code. IT doesn’t have to be involved in doing that. I can sit on the screen, and I can decide that I want to change a number of the different factors related to rates etcetera and essentially build a new product and have it deployed without having to do. So, it’s basically you know a no code change to do some of the basic things you need to do.
DM: Yeah, I guess, you know, I’ve taken it for granted that the core is where you define the product and then you on board the customers and then you operate the product. But that doesn’t have to be the case, right? You can still have a call, but something else allows you to define the product and you know to apply any product behaviour to it outside of the core, right. Is that what you’re saying?
DR: Absolutely. And that can be in a no code environment and there’s many advantages to taking when we talk about product, again, product in the core systems has built up over time that there’s product for your consumer lending, there’s product for deposit systems and they tend to be isolated and embedded within different parts of the core. There’s a tremendous amount of value that can be gained by actually putting all that product information together into a central spot, in essence, creating a product master with all that information and then drawing on and changing that.
Once again, we think of the old core systems, and we think about them monolithically and we talk about them being engineered.
They’re not.
Maybe they were engineered when they were first built, but then they have been patched.
They have been extended; they have been Frankenstein’d over many different years on top of that.
So when you look at something and say, well this is the way it’s been built, it’s been built because 20 years ago someone had requested something different with a product or a regulator had asked for that and it never gets cleaned up. So, they are as far away from a tightly engineered system as you could imagine. And because of that, the complexity of trying to go and introduce things is much more difficult than it would be if you had a new modern, well-architected purpose-built system.
DM: So what you’re talking about here is that banks over a few decades have created silos or product silos quite often using different cores for different products sets like mortgages or for lending or for term deposits, etcetera, right?
DR: Correct.
DM: That’s okay, because maybe 20-30 years ago, or 50 years ago, certainly the credit card only came about in the 60s, right? Banks didn’t necessarily have the foresignt of all the products that they were going to have. Secondly, as those organizations grew, right—and I am making an excuse because it’s a valid excuse, businesses grow, and we don’t know where the customer’s going to go. Therefore, we have to build things flexibly. But how many times would we get a budget in IT that says, look, I’m building you this current account capability. It does allow you to have an overdraft. But you know, if we build in a bit more flexibility, we could treat it like a loan, you know. And we don’t get the budget for that because the guy that owns the current account says ‘No, just build it for me, and I need it as soon as possible’, right? So, there’s amny reasons why these silos exist, but having the silos is a problem because you have to make different changes for different products in different places, right?
DR: Yeah.
DM: And they all impact, you know, this ecosystem of systems.
DR: Yeah, I’ll tell you a story about that and one of my earlier roles that we talked about. These systems being around for decades? Decades is optimistic. In some cases, 20+ years ago at one of the banks I was involved in, we were doing changes to the credit card system, which I won’t name the bank, but the credit card system was called NCCS. And I never actually realized what the name meant. But as I found out afterwards, the name was the new credit card system, which was already 20 years old at that time, was a deep legacy system, was called the ‘New Credit Card System’.
And when it was built, it was intended to be the first phase of a launch that would then include other products. And as often happens, it, you know, took too long, became too complex to do so, it became just the credit card system. That’s pretty much the case of what occurs at many other banks and in an environment where all banks are created equal and they all have the same constraints, maybe that’s OK, it’s not great for customers, but maybe it’s OK.
I think what we’re increasingly seeing with banks is you’re seeing the neo banks, you’re seeing new startups, digital banks that have been created that are attacking that as a problem with banks. So, they’re saying we don’t have to have every single banking product the same way and create a full-service bank, the same with all the different channels. We can create a digital bank, we can have brand net new systems and we could operate at a fraction of the cost at a much higher pace, and we could actually bring innovation to banking and kind of dance around the old elephants that have been in the field there.
And that’s a real risk for banks. And as technology continues to advance, there’s more and more cases of either startups that are doing that or really large banks that have decided to innovate and attack themselves. Where they in essence have created their own digital banks. And they’ve decided it’s easier to start new and build a net new digital bank, maybe migrate their customers over to it over time. Because there’s this pressing need that they know that they need to modernize their systems and they’re struggling to find different ways to go do that.
DM: So, so true because here in the UK I’ve seen both Monza and Starling and some of the smaller neo banks launch new term deposit savings accounts in response to the interest rate hikes that we’ve had, right. And there’s been a backlash with the incumbent banks. People are saying, look, you guys have most of the customer base, but you’re not giving us the benefit of these interest rate hikes. You know, it’s OK when you’re lending to us at cheaper and cheaper rates, but now that we’ve got the chance to save and earn interest at better rates, how come you’re not raising the rates fast enough? And now I do understand that actually it’s not necessarily the banks just being greedy and not wanting to pay, but it’s their actual ability not to be able to, because who doesn’t want to compete for those deposits anyway? It doesn’t make sense to not give that extra rate and keep the customer rather than let them go away to somebody else, right.
DR: That’s true. Because of course every bank wants to be more agile, they want to be able to meet customer needs more and that drives the success of the bank. And you mentioned before, Dharmesh, about the more modern architecture about microservices driven.
And that’s another thing, when I think about core modernization in the past, core modernization often was seen as a single entity, a thing that you would have to do and for a large bank that could be a literally multibillion dollar exercise taking place over years. And because of the complexity, the rest of the activities of the bank really kind of shut down while you’re doing this. So much energy is focused upon doing the new transformation that you’re not really innovating with customers, you’re changing technology, you’re changing business processes.
And I think what’s happened now is that the technology has advanced to the stage that what we’re seeing much more of is really an incremental approach to modernization, which means I don’t have to rip and replace everything all at once. I can take those old core systems, I can skinny them down. I can externalize some parts of it. And externalize means take the mode, put them into a modern architecture, separated but connected back into the old systems. And I can get at the modernization in different pieces and I can actually deliver a better business case from doing so.
DM: Wow, so what you’re actually saying again is that there’s things like being able to launch new products, people deem that to be a core activity. But actually, you could externalize that, keep your old core, but now start by using a third-party component, start to launch new products faster without going through the full expense of replacing your core. Is that what you’re saying?
DR: That is what I’m saying. So, I’ll do a paid commercial announcement for Zafin, because it’s actually one of the things that Zafin does extremely well. Zafin is in the business, product and pricing platform. What you can do is you can actually take that product and pricing, you can take them out of the different core systems, create a single product master and basically have externalized that into a modern flexible architecture. You could have all the benefits on the product side of the business of being able to go and define your new products, bring the new market quickly and actually get a business case while you’re continuing to do the other heavy lifting about, you know, changing the rest of the core systems along with it. And in fact, you also have the ability to, if you have decided on new core system, you can connect to both the old core system and the new core and do them both at the same time as you’re doing the migration. So, there are techniques that are available now to make it simpler and also to reduce the risk like a rip and replace is a very risky operation.
Doing something more incremental where I can take it in stages and also see some business benefit of doing that is very attractive compared to what the alternatives were even 10 years ago.
DM: Look, I don’t want to join the bandwagon of promoting your products, but of course but what I have seen in the last decade or so is things that were in the core inherently have now got so specialised that it makes sense now to replace those bits of functionality with something that is just dedicated to that thing. I think of credit scoring and anti-money laundering, fraud detection, security, a lot of these things were packed into core at a time when you know the complexity behind AML processing wasn’t that great. But now with new data sources and new AI driven algorithms checking the data, you know these specialisms are far better than what was originally created in the core.
So, what I’m starting to see now is banks, I think you called it ‘skinning up the core’ right here. You know, I’ve heard the term ‘hollowing out the core’. So naturally it’s doing less and less and less while these specialized components are taking over and doing a better job of what the core used to do.
DR: Yeah. And Dharmesh, that’s a very valid strategy that a number of global banks are doing like rather than trying to approach saying I’m going to completely change the core, they do what you’re describing your Halloween out, you take the core and you reduce it back to the basic components are really what it was intended to be and you externalize some of the different functions along with it. You wrap it with APIs, you create microservices on the outside. So you wind up with a much smaller in your term hollowed out core, but still very effective and in some cases quite efficient core with many of the other systems that have been externalized and modernized and give both the employees and the customers that flexibility to market you need and again while reducing the risk of doing a complete rip and replace the system. So that’s a very valid strategy. I would say most banks have probably gone some way down the road on that strategy even if they are concerning at some point doing a complete change over the new core. That’s often the first path that you would take is to hollow it out, externalize some things and simplify the systems you already have.
DM: Great. Okay. So, at the beginning you said there were two main problems. We kind of discussed agility in the cost side of it. The other point, it was really about the skill set. Now, I get it. Even when I was at Lloyds, our core was actually written in assembly language, right? And yeah, I dare say there aren’t going to be too many people that really want to start to mess around with the assembly code itself or that, too many people that have that specific skill set.
But actually, a lot of the banks are running on COBOL. Again, I know it’s deemed to be a legacy language, but A., it works, B., there are still thousands of COBOL developers out there, right? And it’s a three GL. After all, it’s more verbose than something like assembly language. So, I can imagine even if I was a C programmer or a Java programmer, actually doing some COBOL would be relatively easy or easier for me to get onto. So, what is the issue with the skill sets really?
DR: So, I think Dharmesh, the issue with the skill sets really is, and you’re correct, there’s a difference between some of the old systems that were written in the assembler versus the COBOL ones. But in any case, it’s still a lot of skill that’s being trained out of school. And there’s the coding of the systems, but there’s also the complexity of understanding what happens in those systems in behind it, the architecture.
And those two things are intertwined, the knowledge of the systems and the knowledge of how the systems have been built and architected. So that when I make a change, it doesn’t have an unintended consequence. And there have been multiple issues around the world.
I won’t name some of the different banks where you’ve seen very bad major outages that have occurred based on what was considered kind of a simple routine maintenance change.
And in many cases, that’s a combination of you’ve changed or done something to a core system and really not understood what was in the background and behind that.
So I think the longer things go on, the more there is that risk associated with things of having people that are knowledgeable in the code but are also knowledgeable in the systems and architecture.
And you know, you’re right, you can train people to do some of the old systems.
At one of my previous organizations, we actually created a university program with one of the leading universities in Canada and we took new kids coming out of school.
We married them up with the guys that have been 2025 thirty years at the bank and had the knowledge and we basically put together like an old mainframe class, and we paid people on a basis where this was considered a hot skill, and it was great.
That’s a wonderful stopgap measure and it worked for a number of years. But eventually the people want to move on. If they look at their resumes and they look at moving on to another organization, saying, I have become like a Level 3 expert in COBOL, quoting at a Canadian bank in this situation doesn’t really get them where they want to go. So certainly, you can do those types of things with people, but you’re really pushing against the tide.
You can delay things; you can improve your organization a bit.
But the fact is that the new people coming out, they’re working with modern systems, they want to do that.
There’s advantages to it and you can push back time a little bit, but you can’t stop the flow of time.
DM: Yeah, this is my second penny drop. It’s the cost of these skills sets is one factor, right? But it’s almost like the change being small, therefore it shouldn’t take too long, right? But actually, even if you could get a flurry of these COBOL programmers, the fact that it’s a monolithic piece of code with millions of lines of code there, training somebody in COBOL doesn’t mean that they understand the system, which means that they make a change. We still have to retest everything and also the risk of them upsetting something is far higher because they really don’t know the impact of that change that they’re making, right?
DR: I cannot tell you I cannot tell you the amount of times over my career where you would have a ugly outage or something that occurred and you have the war room with people involved in it.
And I stare around the room at the people that have been in the bank with the most knowledge for 30 plus years fixing this. And you think, dear God, what happens if they leave?
DM: There’s a lot we take for granted, especially with compilers and stuff. They highlight the errors with modern languages, right? But I remember a time, and this shows my age, I was working on a mainframe batch program, and I got to the end of the week and I should have been done to hit my target and the program just kept going into the error routine.
I’m like, why is this going into error?
Everything, the data, the parameters, everything was correct. I followed this line by line and like I just can’t see it. And then I decided that, look, Monday morning this code has to be correct.
So I’m in at the weekend and I spent the whole day Saturday just checking the code.
I rewrote it and it still was going to the error routine.
And then Sunday evening when I was going back home with my tail between my legs, thinking, God, I just can’t understand why I’m such a bad programmer.
Looking at this piece of code on the green sheets of paper that you go off the mainframe, right printed off code.
And I noticed that my last statement before the error routine didn’t have this full stop.
And it’s like, oh, it thinks it needs to naturally flow, not break at that point.
It’s that one tiny little error that forced into the error routine. Jeez, I’ve just wasted a weekend over a full stop, right.
DR: The other analogy I do is, and I’m hoping this is an example that resonates in the UK, is when you’re looking to modernize.
If I’m building a house, I’m modernizing an old house around there and I can build on the old systems and things that are around. But if the house was wired electrical with old knob and tube wiring, at some point in time as you modernize and you build your house, you have to bite the bullet and you have to change.
You’re creating a fire trap.
You’re creating something that is extended beyond the architecture of what it was originally designed to do, and IT systems are the same away with banks. You can work around it to a certain degree; you can extend things.
But at some point you have to bite the bullet and recognize that technology has changed, the needs of the organization have changed, and you have to find a way to address it, either by the technique we talked about of either kind of incrementally hollowing out the core, hiring new skills, buying new products to come in, or complete system replacement.
You have to get at it, because if you don’t, people won’t want to be buying that old house.
They’re going to just buy a new house. They’re going to buy a nice, modern new house and it may not have some of the same features and some of the character of the old house, but it’s going to work and it’s going to be maintainable.
DM: Okay, okay. So I get your two points now, but, there’s a small subtlety I think that stops banks from changing their core. And because I have that privilege, I’m going to just spell it out and just say, look, there are CEOs, mainly CTOs and CIOs of banks that are probably about my age, reaching retirement, right? Do I really want to be changing the core at my time in life? You know, just can see my holiday home on the beach. I’m close to getting my pension: why should I take the risk? What would you say to those people?
DR: I would say to those people, “I have lived your situation.” I have been in that situation, and for me, the key word that you said is risk. And if you’re in that situation as a CEO or a CIO and you see this change as being overwhelmingly risky change to do, then you’re going to be very reticent about starting it. And to give people credit, it’s not usually because, hey, I just want to get out of here in a year or two. It’s ‘these projects could be long and complex and they need some continuity to get them done’. I think what’s changing these days and why we’re seeing more banks embracing this is that the modern systems, the techniques we talked about, about an incremental approach to modernization and the hollowing out, they’re actually reducing risk. So you can say, look, if I’m in the C-suite, either a CIO or a CEO, my responsibility is to the organization. And if I can help move the organization forward, and do it in a manner that isn’t taking on a crazy amount of risk, and I can do it in an incremental fashion, why would I not want to do that? Regardless of where I am in my career? So I think that the new changes, the new approaches we can have with technology, an incremental approach, change that equation because they actually make it less risky to go ahead and do the modernization, and it allows you to attack it in pieces, and begin seeing a business return for it as you do those pieces. So for me, I think that would be the answer I’d have to your question.
DM: Fantastic. I think you’re spot-on with the risk side of things. Is there any other advice that you’d give to a CTO or CIO that’s deliberating or sitting on the edge about thinking what they need to do with their core, whilst they’ve got the business in there going, well, look, I just want my new product out quickly.?
DR: Yeah. You know, Dharmesh, in my role now, I know a lot about banks as I worked within the organization of a couple of organizations over the last 25 years. In my current role acting as a corporate director and an advisor to many organizations, I actually see dozens of large banks around the world.
And I can tell you, I would be hard pressed to name a single one that isn’t thinking about this issue.
DM: Right.
DR: They’re either thinking about it and planning for how to do it, or they’re at some stage along the path of doing it. But if you’re not thinking about it and you have a major organization right now, you know, I think you really have to question why not because the world is moving around you and you need to have a strategy for it. The strategy doesn’t have to be the same with every organization, but if you don’t have a strategy for how you’re going to modernize, how you’re going to meet evolving set of customer needs, how you’re going to respond to the new competitors and how you’re going to change the cost curve of your business, if you don’t have a strategy around that, are you really doing your job?
DM: Fantastic. Look, Dave, it’s clear that you’ve got a wealth of experience. Thank you for sharing that with us. Thank you for helping me and the audience to understand what really are the challenges. You summarize them as two main things, as agility and cost. The cost being, you know, not just the change, but the impact of that change inside a monolith that’s then ingrained in, you know, a whole ecosystem or other systems that interact with it.
And the second being the skill set issue.
I now also understand that it’s not about learning that skill set, but the impact of that change on this monolithic piece of code.
Again, so appreciate that and also see that risk is a massive factor, but there is a different way of doing this other than just trying to do a wholesale replacement of your core.
I really appreciate your input on this, and it’s been great talking to you.
DR: Thank you, Dharmesh.  And well-summarized; it’s been a pleasure talking to you today.
BW: Thank you for tuning into Banking Blueprints. We invite you to stay tuned for future episodes. On behalf of our season one host Dharmesh Mistry and the team here at Zafin, we’re glad you’re here. Thanks again. We’ll see you soon.
Play
View transcript
Banking Blueprints
Banking Blueprints
Overcoming banks’ growth challenges: Identifying successful strategies for innovation
Loading
/