Tuum was honoured to host a joint webinar with IBS Intelligence on the topic of legacy core modernisation and the opportunities that NextGen Core systems can open up for banks and financial institutions. Watch the recording below to listen in as our panel of experts unravel the future of banking and explore the transformative power of NextGen Core systems.
Recorded Live: Wednesday, November 29, 2023
Banking across the globe is being reimagined by a combination of technological innovations and evolving customer expectations. The rise of neo and challenger banks has fundamentally altered the landscape of the banking industry, with traditional banks now facing competition from agile Fintech startups who offer innovative products and services.
The bane of traditional banks has often been the investments made in legacy core systems, which constrain the ability of incumbent banks to innovate quickly and compete with nimbler Fintechs. The complexity of such systems necessitates substantial spending allocation for system maintenance (”run-the-bank”), thereby limiting investments in innovation (”change-the-bank”).
NextGen core banking systems provide banks with a cloud-based, modular, and flexible banking infrastructure that enables them to reimagine their business models, innovate freely, and fully leverage the power of digital to unlock growth opportunities and quickly launch customer-centric offerings. IBSi’s proprietary SalesVision data shows a notable increase in the sales of NextGen Core systems, from just 1% in 2017-2019 to 15% in 2020-2022.
These agile systems support APIs, allowing banks to scale operations rapidly, add new functionality, and integrate applications and services with ease. More than half of the respondents in a recent poll conducted by IBSi identified “Microservices and API connectivity” as the most important attribute of modern core banking systems.
Meet Our Panelists
Moderator
Nikhil Gokhale, Director – Research & Digital Properties, IBS Intelligence
Nikhil leads IBSi’s team of research analysts, focused on providing real-time, data-driven insights on Financial Technology to clients. He comes with two decades of experience in business research for Financial Services, advising large financial institutions on strategy, technology, and performance issues.
Panelists
Edgardo Torres-Caballero, Chief Revenue Officer, Tuum
Edgardo has over 20 years of experience in the SaaS, IT, and financial services industry. As the former Managing Director at Mambu America and more recently, VP – Global Partnerships at Feedzai, he brings expertise in core banking technology, together with a wealth of experience in expanding global sales, marketing and partnerships.
Tarvo Okmees, Director of Engineering, LHV Bank
Tarvo leads LHV’s engineering function and has played a critical role in redefining technology strategy, delivery teams, and overall in-house vs SaaS architecture. LHV Bank recently launched a new cloud-centric BaaS platform, improving reliability and scalability.
Bryan Carroll, Co-Founder & Ex CEO, TNEX Bank
Bryan is a highly accomplished executive renowned for his clarity and expertise in driving positive business and technology innovation and transformation within the financial industry. As the Founder and former CEO of TNEX Digital Bank, Bryan played a pivotal role in revolutionizing Vietnam’s banking landscape. Under his leadership, TNEX became the country’s first digital-only banking platform, catering to the needs of young un/underbanked consumers and micro-SMEs.
Poll Results
Mission Possible: Unlocking the Future of Banking with NextGen Core
[Full Transcript]
[00:00:00] Nikhil Gokhale: Hello, everyone. Good afternoon, good morning, good evening, from whichever part of the world you’re joining us. A very interesting topic that we have today, Mission Possible: Unlocking the Future of Banking with NextGen Core.
NextGen Core systems provide banks with a cloud based, modular, and flexible banking infrastructure. It enables banks to completely reimagine their business models and leverage the power of digital to the fullest. Case in point of the growing importance of NextGen core, in the years 2017 to 2019, three years, only 1% of core deals were NextGen core. That number jumped to 15% for the next three years, which is 2020 to 2022. I think the trend is simply going to become bigger and bigger with each passing year.
Thank you so much for joining in. My name is Nikhil Gokhale. I am the Director for Research and Digital Properties at IBS Intelligence. Me and my team provide real-time data driven insights on financial technology to clients, be it core banking, digital banking, payments, lending, and many other banking technologies.
Joining me on this very interesting discussion are Tarvo Okmees, Director of Engineering at LHV Bank. Tarvo leads LHV Bank’s engineering function and has played a critical role in redefining LHV’s technology strategy. It was on his watch that LHV launched a cutting-edge BaaS platform for all businesses. Welcome, Tarvo.
[00:02:10] Tarvo Okmees: Thanks for having me here.
[00:02:11] Nikhil Gokhale: Next we have Bryan. Bryan is a highly accomplished executive renowned for his clarity and expertise in driving real life business outcomes. He is the founder and a former CEO of TNEX Digital Bank, and he’s played a pivotal role in revolutionizing Vietnam’s banking landscape. Bryan, welcome.
[00:02:42] Bryan Carroll: Thank you. Thanks for having me. Looking forward to it.
[00:02:44] Nikhil Gokhale: Last but not the least, Edgardo Torres-Caballero, Chief Revenue Officer at Tuum. He comes with more than two decades of experience in the IT FSI space. He understands core banking, I would say literally to the core. Welcome, Ed.
[00:03:06] Edgardo Torres-Caballero: Pleasure to be here. Thank you.
[00:03:10] Bryan Carroll: In the next 15 minutes or so you’re going to see me rack the brains of my experts here trying to find out the whys and the hows of core banking. To start the proceedings, let me call upon Ed so that he can set the context of what we are going to talk about today. Ed, Over to you.
[00:03:34] Edgardo Torres-Caballero: Pleasure to be here. I got to share some slides and some thoughts, but it’s as a baseline for our discussion. We come a long way, if we look at the historical context of technology in banking, hard coded system, closed systems, on prem batching, manual operations and stuff like that. The last decade we’ve moved into a public cloud world, where we operate with loosely corporate architectures. We implemented multiple systems where we can interconnect the APIs, leveraging the power of best of breed components out there in the market, especially fast growing fintechs and companies that provide a bunch of different services, allowing the banks to diversify their offering.
We are coming to systems that are real-time; systems that now, in a way, do not become legacy because you can service them on a continuous basis and do releases. As it relates to core banking, not having to wait for many years to do upgrades on systems. This has been a paradigm change in the way banking operations are run.
If we take a look at it, this is having the banking industry and the non traditional financial services institutions provide a new array of different services. Other than, which is very important, making these operations more efficient, cost saving, enhancing the way things are provided to the end customer, which is ultimately the end goal, enhance those services and get closer to the customer, we also see how these new technologies allow the banking institutions to embrace these new technologies within their offering.
If we understand this from the vantage point of the end customer, at the end of the day you’re trying to reduce friction in between the institution, their procedures, or faster onboarding processes. You’re trying to also embed new technologies in between, that allows you to use data in a better way, so you can provide better offerings as you are supporting, for example the SMB segment with a new array of lending options in the market. Embedding the solution, so you can extend operational activities.
If you understand this also from the vantage point of the banks, the competition that this has generated with non-traditional institutions also pushes the traditional ones to behave and move faster. Banking nowadays you can launch them in months and not years, especially on traditional brick and mortar organizations. If you look at the speed of implementing EMIs or non digital banking institutions, nowadays with a basic MBP account, a debit card and basic transactions like fixed income loans and the like, the speed of these implementations, the cost effectiveness of them has transformed the way the industry behave. Ultimately when you look at this, the technology has enabled most of these things.
The challenges on the flip side come from the expertise on regulatory aspects that impact most of these operations. The newer players out there are learning, ramping up their knowledge on the compliance space that they’re now operating or are intending to operate. They were faster on technology, but now they have to embrace compliance aspects.
Also, the increment on fraud activities pushes the institutions to also embed new technologies to allow them to have safer operations. In this sense, I think it’s a trade off. If you go back probably even less than 10 years ago, of even considering launching a core banking operation out of the cloud, studies in the past, where are you able to deploy this on prem? Nowadays it’s very common to hear, which cloud are you running? AWS, Google, Azure, any of these different vendors in the market.
In this sense, I think we’ve come a long way. Today, we’re going to be sharing some of these experiences. In relation to our install beds of clients, from the Tuum side, we are leading digital coin banking platform, which have expanded over the European markets and the UK. Now we’re in a process of expanding for the Middle East and additional global markets. I think the commonality of what I just explained is reflected in the clients that we service. Traditional ones coming from tier 1, tier 2, tier 3 institutions, non-traditional ones, telco companies launching EMI operations, traditional lenders in the market, they’re launching faster to market in months as opposed to years. They’re seeing cost savings in the way they are running their operations. They’ve been able to enhance their offering with additional ecosystems out there through the exposure for APIs, and embed new financial services that differentiate them in the market.
In a nutshell, this brings an opportunity. I hope this is just setting the tone of the conversation today, for more of these opportunities to enhance and grow. Maybe one topic I will be discussing today is migrations, coming from all legacy systems, and we do have a case in question today. Because ultimately, in order to exploit the benefits of all these technologies and all of these new capabilities, the question that lies is, can you migrate from legacy systems with all the risks that are involved with all the complexities and be able to consume this new technology? That’s a big question because that’s always been a complex topic for banking institutions and CTOs in the banks. I do believe it’s possible that the state of technologies has evolved. Nowadays, you can do smart migrations and properly plan these things out. You can solve end point solutions in banks and not necessarily to go on big banks strategies, and ultimately allow the national evolution of adoption of this new paradigm in the market.
Let me stop there. The idea is just to set the tone for the conversation, but I do believe there are specific cases of success. A bunch of them has to do with the way Tuum has evolved in the market, where migrations are possible, where launching new operations in record time basis are possible, and where the effectiveness and cost effectiveness of these operations with new technology is leading the path.
[00:11:41] Nikhil Gokhale: Perfect. Ed, thank you for setting the tone. I think some very powerful numbers here that I can see on my screen, you’re talking about migrating over a million accounts, having a return on investment in 12 months. I think anyone would take those very interesting and powerful numbers.
When I think of core migration, I literally imagine this to be a heart transplant operation where you are putting a new heart in a body with the bank functional all the time. I think this is a high risk, and as you said, we will talk about it in the course of today’s 45 minutes.
Before I open the room for questions and answers with all of you, I am going to hit the first poll question. I want our audience to be as involved in the conversation. Question number one: which of the following is the most pressing challenge that banks face with the current core banking systems? I assume here that when we’re talking of current core banking systems, it means legacy systems. Is it integration with new technologies? Is it scalability and performance limitations? Is it high operational costs? Is it difficulty in implementing regulatory and compliance updates? Or is it lack of speed and flexibility?
Unfortunately, the speakers cannot respond to this because it will be almost like biasing the poll. But if you ask me, I wish there was a sixth option, which was all of the above. But we want we want the audience to choose one so that we know whether what we want to cover today is relevant for our audience or not, so we can just quickly be agile and focus on that.
I’m going to end the poll in the next three seconds. Last chance.
Speed and flexibility to enable innovation. That’s the number one choice followed by integration with new technologies, and the third being the operational and cost. I think it’s less about the cost and a lot more to do with innovation, a lot more to do with new technologies.
Again, let’s start with the basic. Bryan, I’m going to start with you. Keeping it very crisp and clear question for you. What are the top three challenges when it comes to legacy core?
[00:15:09] Bryan Carroll: Firstly, great framing for the whole. I’ll probably end up repeating, I suppose I’m thinking through my answer, trying to buy some time here, probably end up repeating a few of your messages.
To answer this question, I think we need to do a little bit of framing first. The challenges are the same, but the depth or difficulty of those challenges depends on organization. I’m talking about incumbents rather than what I’ve been doing from the last 8 or 9 years building neos.
We’re going to look at across, I’d say probably 3 dimensions to get to the right answer. The first one is, what the hell is a core bank? Because it’s quite surprising how many different answers you’ll get from working in traditional banks. We’ll see a lot of people come back and say a core bank is, you will find it doing everything when calculating RAROC. In some cases, I saw two generating front ends to managing FX positions. But in fact, this is an issue. A core bank in itself was never meant to do this, a core bank was meant to be very much a thin layer, in my view, and I think in the new core banking providers view. But it has got quite thick. Core bank typically was operating in the back office, managing the ledger, doing product configuration, the ability to produce reg, but it has transformed into something much larger, making the problem bigger.
I think we also need to see a lot of organizations are on different periods or steps of their migration or evolution in core banking. I see three generations, and I’m old enough to have worked across all of these three iterations of core banking. The first one, the main frame, which is very much a ledger in reality, with some product features in it, but primarily a ledger. We got to making that better with some client server improvements where I was involved quite heavily in my younger years. Then we get to the third generation, which has been a problem. I think we’ve seen this in the industry with so many failed transformations, where the older core banking systems, be there in prem, on prem or third party or package, started to wrap their old core with APIs and REST services. That didn’t fundamentally address the they were implementing. In fact, what they were trying to do was create better versions of the previous iteration, where as we know, banking has changed, not going to work.
I suppose as I go through it, I think always of that saying that: old keys don’t open new doors.
Now we’re on the fourth generation, which represents a completely different banking landscape and is responding very much to the transformed needs and most important expectations of our customers.
It’s quite interesting, and I’ll move on; I’ve spent most of the last 10 years in Asia. If we look at the top 100 banks in Asia Pac, the average age of the core banking system is 17.5 years. The issue is far from addressed.
As to the second dimension, I’ll get through quickly, the banks are no longer positioned for those previous generations of core. They now belong to an ecosystem, which includes tech companies, AI, neobanks, non bank lenders, et cetera. The winners in this ecosystem have to have a core that leads with customer experience or supports customer experience rather than just products, because products are enablers and commodities at this stage.
Finally what it takes to succeed is, in reality what these new cores allow is that to succeed in this financial ecosystem where you’re no longer the bank and you own it, you have to be very hyper relevant to customers. You have to be emphasizing this experience.
To answer the question, I think the major challenges of legacy core banking is they’re unable to because they weren’t built to transition to this economy of customer experience. They were built for product. The second one, trying to refactor these old core banking systems, wrap them, refactor, you can do it. You can do anything. It’s how deep your pockets and how much time you have and how patient your shareholders are, but they’re very slow to change. They assassinate an innovation culture, because everything takes so long. You’re not going to innovate. They’re very product focuses. Small changes take months because they’re monolithic. They take testing; it takes many months to work, which in reality, in banks that I founded and run, it could take days, could take weeks to months in traditional cores.
The other third one, and there are many more, back to Nikhil’s point, it’s operational risk. The costs of running these systems are very expensive. The cost to serve customer are very expensive, and the cost to serve risk. If you look at security, scalability, reg, compliance, we saw how difficult it was for traditional banks to implement GDPR, which would be relatively simple in a digital core or even open banking.
I’ll finish. The next core systems for me are the ones that are prioritizing low cost, intelligent automation, fast change, and I think data driven decision. They have got the benefit, as we’ll talk in a minute, of having modular API, cloud, and headless architecture. Hopefully I’ve answered your question. I do get a little bit passionate.
[00:21:17] Nikhil Gokhale: You did. Interestingly, Bryan, even as you were speaking, when you spoke about the first point, why there’s a problem with legacy core, they were never built for the digital customer journeys, the immediate thought that came up was, why is the answer building NextGen core and why is it not building better core systems? Even before I could ask that question, you answered that in your second point and your third point. I almost feel you already started to answer.
[00:21:57] Bryan Carroll: I read all your research, Nikhil. That’s where I got my information. To sum up, I am built for rugby, not ballet. Or as one of my dear friends said, trying to do NextGen digital bank with an old core is like trying to teach an elephant to tap dance, if you want to keep that along. It’s not the core’s fault, they just weren’t built for this, similar to me in ballet. I’ll close it there.
[00:22:31] Tarvo Okmees: I would like to ass, I agree with what Bryan said. I think everyone understands what’s lending, what’s everyday banking, what’s savings. The question is how you are reaching to the customer. What’s the experience? What’s the additional value you’re providing? Building that on top of the legacy core banking system, literally no way; or you are building it, but then the go to market is going to be so long that you’re missing that opportunity. That’s the key thing. I believe it’s pretty much driving everyone towards at least thinking or discussion about how to move away from the legacy core banking solutions and what are the advantages to take in that NextGen core banking solutions.
[00:23:29] Bryan Carroll: I think the biggest warning, and I travel around the world a lot, primarily because my marriage wouldn’t survive if I was home 365 days a year, but while I’m traveling I meet a lot of failed transformations. This is important and a important message. I’ve been in banking 30 years, I built banks, traditional, whatever.
The last generation pre this were the big software providers who put lipstick on a pig. They told you that this old monolith, we could take a concrete block and draw little lines on it and that made it like Lego. No, gosh. I have many executive friends who have had those red face moments after 1. 2, 1. 4 billion dollars spent on a core banking replacement, when in fact they weren’t addressing the real problem.
I think we all agree, the real problem is how do you differentiate? How do you move away from commodity? How do you interact with your customers? How do you move away from this wallet focus and move to this experience focus? Because that’s where you’re going to win, and we see it time and time again.
[00:24:48] Nikhil Gokhale: While I have you, Tarvo, talk to us. You mentioned that you felt the need for having a NextGen core system and you went ahead, and within the LHV UK operations you upgraded to a NextGen core. How has the shift to a NextGen core transformed your operations? How has it improved customer experience?
[00:25:19] Tarvo Okmees: Before answering this question, I’d like to give a background why we made that choice. LHV Bank is an Estonian entity, or the bank in Estonia, is already more than 20 years as a company, and has a long history, although they started from the investment and then slowly moved to the everyday banking, then moved to lending, savings, corporate banking, so on and so forth.
This is one of the signs, if you see the evolution of the company growth and releasing the new products, then the question is how they have built. If it microservices architecture, or is it pretty much adding all the new functions on top of that one monolithic so-called core banking system?
When LHV decided to open the UK bank or apply the banking licensing, my role was to focus on the technology strategy and understanding what are the key benefits we would like to get out from the new customer experience. It’s not about the technology as such, what you are proposing. You can go crazy with the technology. But the question is what you would like to achieve. You’re starting from the customer. This is what many banks are missing. They focus on the processes, on the regulatory requirements and technology. The new generation, what I have seen as well in the practice, they are flipping the coin, saying, we need to think about customer experience and then applying the regulatory requirements on top of it. We can operate in that regulatory landscape still thinking about customer experience and how we are approaching it.
All these things were driving us to the position where we leveraged what that means to build or take the literally the copy of the previous core banking system, implement it to the new entity; versus going out to the market and understanding what the Next Generation Core banking can provide us.
A few key points, what we were looking to that was pretty much the service segregation. From the operational resilience perspective, if you have one monolithic, if something fails, your full bank is down. If you are services segregated, you can have, for example outage and lending, but the service is up and running and no impact to everyday bank or the card payments, which is critical for the retail customers. Or in the payment stack, even though that is up and running because it’s not coupled, it’s decoupled. You can pay focus on different services and service level agreements. In the monolithic system you only have one service level agreement.
The service segregation was another thing. The third thing was go-to market; low cost, can have that as a service. How can we achieve that? Even if it’s an internal service, there has to be a low cost.
All these key criteria were driving us to the position where we saw that the existing core banking system is expensive, mainly from the maintenance perspective. It requires two full, sometimes three full sized teams to run, and there is a huge cost on that. Versus if you’re going to the NextGen core bank solution, they are providing that thin layer for many banks and institutions, which is balancing that technical depth and that cost. Otherwise you’re paying for your own purpose only.
We decided to take Tuum as one of the Next Generation core banking, mainly because of the fact that they are microservice based. As Bryan mentioned, some of the old players, they are just saying that they are now NextGen, but only having the API layer, but the underlying platform is still monolithic. You have no way to speed up, speed up in terms of go-to market and so on.
Now, the answer to the question about what’s the customer experience, currently we have improved our service reliability. Previously running everything on top of the monolithic, every small error or a bug in the system caused the issue across the services. Now we can control that in a better way. We have introduced the quality gates, which are easier to implement, the tooling we can integrate, just to make sure that we are automating a lot of quality, a lot of release related processes, what you can do having this segregated service concept already implemented. Second thing is, customers are now able to integrate quicker, this a quick to go-to market. Time has reduced. The third thing is that now, as we are having a NextGen core banking platform, from the operational perspective the product had to change. They are able to define new products through the APIs or through the interface. They don’t need particularly any of the IT or engineering resources, except when they would like to change the customer experience. But as we are operating mainly business to business, so APIs, our customer experience doesn’t change so much except if you are introducing a new version of API. They can try out, test it out and reflect the customer feedback faster, quicker, and trying to understand how the market is shifting from that point.
[00:33:10] Nikhil Gokhale: Perfect. From what I’m hearing, I think it’s the faster go-to market, so you’re able to get to customer needs faster; and overall less expensive to maintain. Those stood out as big points. Of course, there’s several points that you made, and that’s where I’m going to bring you in, Ed.
I know that some of the points that Tarvo raised I would want to bounce off you as well. Do you agree with what Tarvo said, that there is some real difference between when you talk about legacy core versus a NextGen core? Is there a real difference? Or is it simply a marketing gimmick, or is it old wine in a new bottle? We putting you on a spot there.
[00:34:08] Edgardo Torres-Caballero: No, it’s good. One thing is, when you try to adopt the cloud, or if you are born to consume the cloud, there’s a bunch of different services that you can extract out of the cloud and all systems. I love what Bryan said about the lipstick reference. Many old systems and legacy core providers, there no option. They cannot just replatform everything from scratch. They have an existing business to support, so it’s impossible for them just to change everything. Which means that the new market demand has to be addressed in a different way, which is this lipstick concept.
Ultimately, there are challenges for these old systems. The most important one for me has to do even with Gen probably 2 or 3 digital core banking systems, some of them are monolith. They’re not even microservices. that brings a set of challenges because it produces a backlog even on producing features and capabilities when they have to release them, because they have to break lines on this whole system and record it. At times they might even hit a ceiling on those things, which means that probably some of these supposed newer generation cores that are monolith won’t be able to scale. Let me just put it like that.
That’s a big issue, because ultimately you need to scale these operations. You’ve going to be flexible. All this flexibility, launching fast and everything we’ve been discussing, it’s real. You just don’t have the luxury not to make that happen, especially for those that are launching new value propositions in the market.
But I do want to reclaim, both Tarvo and Bryan mentioned a few things which I want to recap, and it goes along the lines of these things. Defining what the core is, and frankly speaking I speak every single day with prospects out there, including old traditional banks, massive 100 billion and above asset-based banks, and at times there’s confusion. What is the extent of what the core banking system has to do? It even gets into onboarding processes and stuff like that, which has nothing to do with the core. At the end of the day, there’s many things you can modernize and implement technology about those things, but ultimately it is the definition of a proper extent of these things that allows you then to compose a proper architecture where you can then be fast, cost effective, adopt the best of great components that you need, for whatever use case you are launching.
Again, Bryan mentioned it. It depends on the institution, what they want to launch, or if they’re migrating something or launching something new. That may change the strategy of what you’re doing, and at times might be the case. In the case of Tuum, if there’s data residency requirements, such as in Saudi, for sure, we put our software in cybernetics and we go down there and we put it on prem locally. Because there’s certain limitations in that sense, and we don’t want to be limited on what we do on the SaaS, on a more mature geography where these things are already put on the cloud and we are flexible on those things. It depends on what are you trying to solve.
The other one, is and I think it goes back to Tarvo, they focus on, which is the right way to do this, what are we trying to launch? What is the expectation of my customer? How do I differentiate in the market? Then when you define that, then you go backwards and you say, these are the best technologies, this is the best process, this is the best architecture.
These guys have been around for 20 years. If they had replicated what they built in their old legacy in the new, just because they wanted to comply 100% with it, they wouldn’t be as fast. They wouldn’t be as successful, I’m pretty sure, and I’m involved in the process as a core banking provider, probably with more difficulties that we have.
The ambition was right. They built what they needed to build for this new challenge, not replicating the old. I’ve seen that very often. I have a story of a client after two years and a half, we mentioned these things during the sales process, he said, “Why don’t you just be what you need going forward?” Now I need to replicate there 100,000 different procedures, we have to comply with them all. And after two years, the client came back and said, “Frankly speaking in this new system, we have been on only 50 processes and it will do the same.” Because it’s not technology. You can do many more things if you reimagine banking.
Banking has to be reimagined considering the state of technology that we have today.
I’ll leave it at that. It’s very valuable to hear from the customer side, from experts that we have in the call today. The technology per se can do many things. As Bryan said, if you have patience, money, and the buy in from the board, with Java you can build the rocket and go to the moon. But that’s not the end. You’ve got to be cost effective, you’ve got to launch fast, you’ve got to capture new clients. Therein lies the challenge, and you need to understand and have a proper strategy, proper architecture, know what you’re buying, and then you’re going to exploit that in a beneficial manner and not just replicate the old because then frustration knocks on the door.
[00:40:07] Tarvo Okmees: Indeed. I would like to add that one of the challenges for us was as well to define what core banking platform needs and what’s the scope of that. Initially when we started to explore the market, we went like crazy. Can we have the customer portal as part of the core banking? Can we have some payment integration as part of the core banking? Can we have this and that? Then we realized that, but this is not the core banking, this is a full platform.
As Ed said, everything, which is the differentiator, the customer experience, is not core banking. Core banking enables that. We are calling it system of record. All the flows we are building, we have to have one place where it is keeping the latest state, the system of record, having it segregated, and can have certain processes keeping the status, keeping the history, keeping all the transactions, all these things. But everything, the business logic, the product logic, the experience is out from that, and that gives the speed. That gives the segregation and enables to avoid that massive testing and all these parts as well, because you can only change the experience and not the core banking or vice versa. Changing the core banking logic, understanding what’s the data architecture, you have to expose out from that to regulatory reporting or business intelligence, but that doesn’t change your experience.
[00:42:09] Nikhil Gokhale: Very interesting. I heard a lot of jargon, but I also heard a lot of simple words, which I think which stick to your mind, you end up remembering. What stuck to my mind very simply was the flexible, scalable, and the ability to use best technologies.
I also loved the fact that in your opening response, you mentioned how you had to think from a client first perspective when you’re looking at the core banking system. But as you started getting into what exactly is core, you realize that everything that the customer touches is probably not. Very interesting you already started talking about the journey. Before we go into the journey, I have two more things that I want to quickly do.
We have a question from the Q&A window. He says, what is the architecture off the NextGen core banking? Is this cloud native and microservices based? If yes, how many services are available on microservices? I think we covered the first two elements. Maybe Ed you can talk about the third one, how many services are available on microservices?
[00:43:34] Edgardo Torres-Caballero: In the particular case of Tuum, we have 38. You need to understand also the scope. There’s not many of these new digital core banking systems that were born natively with payment capabilities and even car management software capabilities. In our case, we do have those things.
Frankly speaking, I think it comes from the vision of the company of having a core account without a transaction. Banking doesn’t happen at the end of the day. You somehow need to enable these things. In that sense, we went beyond the core in having that, so that extends the microservices that we have. It’s important to understand also the extensibility of the core, and the microservices allows you to do these things. To Tarvo’s point, an architecture that is built to sustain changes in time, even the institution, if we are not serving well any particular customer, by having this architecture in a more flexible way you can even subtract and plug in new end technology that may supply those needs.
How many of them, that’s a question for a proper CPO that may define those things. But the simplicity, it’s important in relation to having an architecture that is workable with that you can exploit in an appropriate way, and not stories that I’ve heard about companies where they have contracting models that are multiplied in thousands because you end up with 2000 lines of code, which I heard the study the other day. That contract supposedly is 35 contracts that produce one product. I think that’s not where you want to go ultimately.
Bryan, you have an opinion on that?
[00:45:36] Bryan Carroll: Yeah, I think there are rules to get to that number and building on what Ed is saying. I’m ex CTO, so obviously I’ve been challenged with this, and most recently I designed this model for a digital bank. You have to adopt a domain driven approach.
Start with domain. Then you have to have massive amounts of governance around this, because the granularity, as Ed has said, I’ve gone and seen, “We’re microservice.” You’re not, you’re just a load of messy REST calls. Microservice isn’t just a set of the gateway and loads of messy REST calls and happy executives, because they can say, “We’ve got microservices.” By the way, if you ever hear an executive talk about microservices, who’s not an IT person, leave the room. That’s my general advice.
Take a domain driven basis, you know the domains, go from costumer, go from product, etc. Take the domain, have some good work done on this. We’re going to do some good work on this, and they’re pretty much there. The design patterns are readily available. But governance is key. Because you could end up having a microservice mess which is worse than your monolithic. I’ve seen that happen. That would be my recommendation. It isn’t that difficult do it by domain driven; these models are readily available. You want to have as few services as you possibly can, and getting that balance between few and little. Because if you’re calling one and you’ve got to do more work in the gateway or further down, they’re decisions that you need a good architect to be making those decisions. Making the mistakes too, you just get it more or less right.
[00:47:36] Nikhil Gokhale: In fact that’s where I’m starting to now focus on going forward. We just spoke a lot about the why part, why core banking, why NextGen core. I’m going to get into that how part, which is how to get to a NextGen core.
Before that let’s see what our audiences think about the point about migration. I’m starting to get a couple of questions on migration. Let’s do a quick poll. On migration, when considering a transition to NextGen core banking platform, what should be banks’ primary focus?
First, is it reducing total cost of ownership? Second, leveraging data analytics and AI for personalized services? Third, speed to market? Or fourth, is it strengthening cyber security? All important again, I feel. I wish there was the option of all of the above, but we are putting people on the spot and asking them which one they choose or which one they prefer.
I’m not going to tell which one is leading right now, because that could influence what people would choose. But I am compelled to say that it’s very interesting that reducing total cost of ownership is not one of the top scores. I’m going to stop in 5, 4, 3, 2, 1. There are the results. Very interesting results. Speed to market is the number one. I see a few nods from my experts, so I think they’re very much in line with what they would expect. Excellent.
Let’s focus on the how part. How do we get into core migration? There is a question on the Q&A board as well, which says when you have a challenge in terms of data cleaning from legacy to the new NextGen course, I’m going to throw this open to all three of you, what are the approaches for migrating the core banking systems? Is there a right way for anyone?
I’ll not let you fight, I’ll let Ed start. Ed, you have the floor for a couple of minutes, and then we move to Bryan, and then to Tarvo.
[00:50:30] Edgardo Torres-Caballero: I think probably Tarbo and Bryan as a former CTO will be in a better position. But from my side, I think it’s important to understand that at times there might be smart ways of doing these things. If you have, let’s just take a micro lender and there’s loans that are in short cycles and the like, don’t migrate them. Just let them die. Or fulfil the life cycle, and create the new ones in the new system.
Under whatever considerations, you’re going to have to build for a part of the system while you’re transitioning. Somehow you need to build up your budget and organize that, and Tarvo may share some experiences about that.
Also, the case of LHV may be different, but certain institutions you might have end point solutions that you want to fix. You don’t have to go all across the institution and change everything at the same time. There’s different strategies out there. Ultimately, I think that integrity, making sure whatever the core is receiving, the proper information on the fields are properly addressed. There’s multiple different strategies there. Again, I’ll defer to my colleagues here because they’re the ones that put those strategies in place.
[00:51:55] Nikhil Gokhale: Before Bryan, I’m going to throw in a jargon. There are words such as hollowing the core and the likes; do they even exist, something like that, or is it just jargon?
[00:52:13] Bryan Carroll: I think I changed the question completely guys. We’re asking a question that no longer makes any sense. What’s a core migration? Core migrations were about doing what you did before, better, faster, more flexible. The question now is when I’m looking at, being a CTO, CEO, CRO, but as a CEO sitting there in front of my shareholders and as a business and sustainability, I’m saying, “How do I become more relevant to my customers at a lower cost and make a higher return?” That’s what i’m trying to do.
A lot of that you’re not going to find in the core support space. I don’t like the concept of customer journeys. It just makes consultancy companies wealthy in many cases. It’s about coming down boiling down to what are the key metrics to make your business a success? Starting with customer. When you identify that, there are going to be elements of core there, and there are going to be elements of mid off and risk management, be it lending, be it fraud, be it whatever, and there are going to be elements of front office as well.
Remember core does not, Ed, you showed your old past there by saying loosely coupled architecture. But there was even a bigger architectural principle, and we seem to have lost a lot of this knowledge for some reason, called separation of concerns. When I’m building banks, I look at a taxonomy, I look at the process and I say, what is core concerned with? I look at it from those KPIs.
Now, does hollow out work? Yeah, it does. If I put on my architect hat rather than the CEO, when I identify these key tipping points that are going to make a difference to my customer, and both on my top and bottom line, there are architectural approaches. It’s not rocket science. We’ve seen architectural approaches, hollow out the core, fine, which means incrementally move away from your business. When I build a neo, I don’t have that problem. I don’t have a business, I could just go and build it.
When I’ve got a business that’s generating returns from my shareholders and serving my customers, of course, Big Bang doesn’t work. We know Big Bang doesn’t work, okay? It can’t work because that would mean that you have to develop the most perfect implementation, most perfect software package, then you have the regulator all over you. Your business could be fundamental, you could have a cyber tech. You could have so many issues. You’ve got to incrementally move.
What I would suggest is to hollow out the core, which means just move these income or customer interaction points incrementally across and use the technology that’s available or the design patterns available to do that safely. For example, look at strangle patterns and architecture where you can move, you can strangle the old and move it across. Look at programs like CQRS, where you can move a lot of the workload away from your own core system using event driven, blah, blah, blah, for you techies out there. But at the end of the day, it has to be an incremental move.
Now, don’t do the following. You cannot make me into a great ballet dancer. I wasn’t a bad second row forward in rugby. You cannot take an old core and transform it. Because what is attached to that old core is an operating mode, is a risk position, is a culture, a people view, a management organization. You cannot change that there.
My recommendation, guys, and very simple, don’t make the management consultancy companies any more money they should be embarrassed about. This does not include the likes of the intelligence people who are shouting about this. You’ve got to build it on the side. You’ve got to tackle the real issue, which isn’t technology. It’s your culture, your operating model, and how you view your business is going to be.
There is no longer an OTB and CTB, and all your bankers will know that because it’s the time of year for budget. What are we going to spend on run-the-bank and what are we going to spend on change-the-bank? We have moved completely now to continuous change. It’s CTB all the time. How do you support that model?
Back to answering the question, don’t try and rebake the old cake. It was fit for purpose for a different interaction and a different world. Build it on the side, invest in very good architects. They will show you the way, take a risk view of it where you can incrementally move away. Let’s put it this way. If you don’t get off your old core in the next 5 to 10 years, you’re not going to be relevant. Banks out there, if you don’t do it, you’re not going to be relevant. Caveat emptor, old keys do not open new doors. All of the old successful core banking systems out there are not modular. Because as Ed pointed out, they’re businesses. They’re not going to throw out 20 years of code and rewrite and then cause every one of the customers to do an upgrade, because it’s not possible. You have to look for new keys. I’m very excited about two. I’m very excited about, and just as Ed is, about other players in these marketplaces.
New keys for new doors. Be careful.
[00:58:01] Nikhil Gokhale: Bryan, I will be able to please take five or six of things that you said as headings of some of my articles that I write.
[00:58:14] Bryan Carroll: I read all yours.
[00:58:19] Nikhil Gokhale: Gentlemen, I have maybe a minute or two on the clock remaining. I do want to get for the last word, continue the discussion of what worked for you at LHV in terms of implementing the modern core.
[00:58:38] Tarvo Okmees: I would like to concur with all the previous speakers, that everything they said is relevant and needs to be accounted in when you’re thinking about migration.
Migration is not only about moving the data from one side of the platform to another side. There is going to be a huge mess if you’re missing operations, if you are missing all the strategy, if you’re missing let’s say even the internal customers experience. Internal customers are your own employees, how they are going to use it.
The cost of the migration is not only about the technical approach, or even the strategy is not only about the technical approach. It’s about how you are transforming all your operations, processes, all your company culture. If you’re keeping that the same, there is no point. Leave it as is and you’re happy. But if you are willing to change, and if you see how you can benefit from that change, whatever it is, automating all the incident management, automating some of the customer feedback processing, ticketing management, automating some reporting, you have to have some key drivers there. Because otherwise the bill is going to be quite huge and no one in the executive level is going to pay that or sign that off and say, go and spend. Nowadays that not the case.
What we did, as I said previously as well, we had the key drivers. We are a digital bank. We are optimizing our operations. We have a key matrix for cost per transaction, for process efficiency, all these things. We are measuring each and every quarter how we are doing, and that’s the driver. Core banking migration wasn’t the driver. That was like, what was the output? Output is to modernize your technology, to move over to the technology which enables you to do these things, like for your internal customers or for your external customers.
Our approach now from technical perspective was again, automation. I personally don’t like to build something like a modern platform, but using the old database extracts and importing these in. we look at what are the options available. There many automated frameworks available, but you can introduce. Meaning you can get all the reconciliation already in place, you can add it to your pipelines, you can control the quality, and most important from the migration is how frequently you can iterate. At the end of the day when we did the migration, we iterated migration twice a day. That’s the success you get from the data quality perspective, because you iterate, you learn, you iterate, you learn, you iterate, you learn. Then you’re leaving only a small portion at the end to say, now it’s a downtime, and the downtime needs to be minimal because downtime is your loss. Customers are not able to use services; you have to pay that bill.
This is what we did pretty much. Automation and focusing on the key metrics, what you would like to change as part of the migration.
[01:02:32] Nikhil Gokhale: Fantastic. Gentlemen, I think we are three minutes over. I wish we could have continued this discussion for at least half an hour more. We should be doing 90-minute webinars sometime in the future.
It’s fascinating to see, I had Bryan who I thought would be talking about the business side, spoke a lot about technology. I had Tarvo who was from the tech side, and he spoke a lot about business. I had Ed who presents the NextGen core, and I wanted him to focus a lot on the migration bit. But he said, “I let the people with experience do the talking.” It was amazing how incrementally you’ve built on to this whole subject that we’re discussing today. I do feel that we as a team did justice to the topic, which was mission possible.
If nothing else, if you are going down the road of migrating to a NextGen core, you should be listening to this webinar, because this is going to allow you to make the mission possible.
I would love to thank all of you, Tarvo, Bryan, Ed, thank you so much for being a part of the discussion today and giving your thoughts without holding yourself back. I really appreciate that. Thank you so much and have a great day ahead.
[01:04:14] Tarvo Okmees: Thank you so much.
[01:04:15] Bryan Carroll: Have a good day. Cheers.
Get in touch to find out more.