Learnings from Building NextGen Payments Infrastructure & Technology

In an age of rapid technological advancement, the banking sector faces the limitations of outdated payment systems. These legacy platforms impede the development of new features and struggle to adapt to evolving formats and regulatory demands. As we transition to an era of instantaneous transactions, it is crucial to maintain a 24/7 operational system that addresses the complexities of global regulations.

 Modernizing payment infrastructure is not merely an upgrade; it is the creation of a robust foundation that fosters innovation in a swiftly advancing industry. To navigate this modernization, banks must adopt a customer-centric approach, beginning with understanding customer needs and working backward to integrate technological solutions. This approach allows for the identification of challenges from the customer's perspective, evaluation of technological feasibility, and assessment of economic viability.

Infosys' upcoming panel discussion at the American Banker Payments Forum will explore the future of banking through first principle thinking and an MVP approach. The panel will examine the potential of next-generation technologies such as GEN AI-LLM, cloud, API, and blockchain to facilitate the transition from legacy systems to modern architectures. Additionally, they will discuss strategies for achieving scalability, robustness, and enhanced transaction efficiency, which are crucial for managing payment platforms on a large scale. Join the Infosys breakfast session, and learn about modern banking solutions that deliver both efficiency and innovation.


Transcription:

Manishi Varma (00:09):

Good morning everybody. Welcome to the Breakfast to Briefing and the the planet discussion around Learnings from Building Next Generation Payments Technology & Infrastructure . Just to give you a quick brief on the topic itself and why we here. So the landscape for banks has changed quite drastically over the last several years. Customers are demanding real time personalized experiences. We have customer relationships and loyalty, which is very fragmented and modular, and we have big tech that is making big investments in the banking space. Now all of that is resulting in disintermediation of banks and their ability to compete in the market. That said, banks have the data, they have the data, they have the transaction processing capability, and now with Gen AI and all the other tools that are there, they have the capabilities to rebuild that experience. The biggest challenge that they have is their legacy infrastructure.

(01:24):

So that's the topic for discussion today. There'll be three parts roughly as we go through the discussion. The first one is, what are banks trying to do that they've not been able to do, right? So that's part one. The second is banks have set a very lofty vision for themselves. They want a completely seamless environment, things like that, but their starting point is filled with legacy. So how are banks approaching this transformation? So that's part two of what we wanted to cover today. And the third part is as we look at our own organizations in terms of transforming organizations or investing or advising our customers, what are the pitfalls? What is it that banks need to avoid? So we have an amazing panel today we have just to introduce the panel we have Vivek Dwivedi is the Regional Head for payments, sorry, Regional Head for Infosys Financial Services.

(02:30):

He, over the last 25 years, Vivek has advised numerous banks globally on their journey from transforming their experience, their process, their capabilities, their data, and their infrastructure. So it'd be great to hear his perspectives on how they're approaching this. And we also have Chris, Chris manages Commercial Banking and Cash Management at McKinsey and he's been helping transform banks on the commercial banking side. So it'll be great to get both of their perspectives as we go through this panel discussion. So Chris and Vivek, welcome.

Vivek Dwivedi (03:11):

Thank you Manish.

 Manishi Varma (03:12):

Welcome to the thank you very much. Alright, wonderful. So we'll start off, let me come here. In fact, it might be easier, just do quick mic check on this one. Alright, yes. Okay. So Chris, maybe I can start with you, right? I mean you've been leading the cash management space for quite a while and have had exposure with multiple clients. So just the first part of the question and just so we all get our heads around the problem statement, what are banks trying to do today to get ahead of what bank fintechs and other big tech is trying to do that they're not able to do because of their infrastructure?

Christopher Esch (03:57):

Of course. So let's talk a little bit about, and also good to see everyone, I can't see, the lights are so bright. I feel like I'm testifying in front of congress right now, but we're going to move past that. So what do they want to do first, they want differentiation in their services. They want to have a B2C like experience. They want to automate their processes, they want to have digitized collection of data and they want to have good reports and data. They can book trust to make some informed decisions about their business. The challenge is there's barriers for this one, they have a ton of tech debt. Most of my clients that will serve have legacy cores and it's not uncommon to here, we implemented this 15, 20, 25 years ago. We've been building customizations on top of our years and as such we have kind of this spaghetti architecture we run in batch processes.

(04:41):

We can't do things in real time and we have this kind of monolithic block that really slows down the general one, our capacity to add new modern technologies, but also kind of pivot across those two, aside from just the pure infrastructure, you also have just legacy ways of working at a lot of these places, which can be pretty tricky. So the amount of clients I've had who've said, well we are waterfall, but now we're waterfall with agile or sorry, we're waterfall with Jira, really is kind of a bit of a challenge. So how do you actually bring the delivery mechanisms into a modern way that can support some of these modern cores, modern platforms? So you're trying to put in finally there is this disconnect between business and tech. So I'm just going to slide over rather than lean the whole time. There's a disconnect between business and tech usually that we'll find.

(05:30):

For clients that are struggling to deliver, they usually have a bit of a segment between well business throws their requirements over, they say, thank you, thank you for this. We'll come back in a little bit. You tell us when it's done, tech does their best, but then if you kind of don't have that cross-functional integrated team, it always ends up being a little bit of you expect a horse, you get back a donkey or a camel. And so the final part would be talent, right? There is always a struggle to get the right talent when you're developing and when you're kind of trying to drive these transformations internally. We have a client right now who's trying to digitize their TM onboarding experience right now it's extremely manual, right? You go in the treasury management officer calls, they collect their requirements, they hand it off to implementation team, it's captured in a Word document and someone on ops goes in and one by one plugs in these different fields across as many several different admin systems. You have one for the core, you have one for the remote deposit, capture something else for lockbox, it takes a ton of time. If you're a client, you want to just send a wire. It can take you if you're lucky five days, but depending on what you add, this can be a month, two month process, right?

(06:36):

And all of this is just set a couple fields in the background because we don't have APIs, we haven't set of RPAs because it's just not built on modern infrastructure. So how can you transform that? Happy to talk a little bit more about that one a little bit, but I know that was a lot of me ranting and it's early for folks.

 Manishi Varma (06:51):

No, no, this is very interesting Chris. And what I took away was one part about it is functionality, but then it's also the ways of working and getting the organization much more nimble to actually be able to deliver what exactly is required from the customer segments. Excellent, thanks Vivek. Just your thoughts from your payments perspective.

Vivek Dwivedi (07:13):

Yeah, I think Chris covered the commercial banking side of it, so I'll probably focus on the retail payments side of the house. I think they're in dealing with players who are on the issuing side or acquiring side and network for instance. We see really three big struggles. One is from a business perspective where to play because there is a question around a data localization, there are challenges related to that. Do you want to play in one market or the other? And how you want to play in the market. There is real time payment revolution that is happening and the question for our clients is that how do we play in the real time space where it is monetizable for them and where it is not depending on who you are, you're really trying to figure out what makes sense for you. How do you really monetize the real time payment space given the domain that you're in operating in?

(08:21):

That's number's the big, big issue where to play. The second is financial crime and that's top of the mind for all our clients. They're trying to figure out how do I prioritize my capital and across delivering new products services, expanding in the new markets while at the same time remaining compliant and having advanced fraud capabilities, making sure that you have real time response to or predictive response to such attacks and making sure that they have the trust of the customer, they don't lose the trust of the customer. So prioritizing the fight against financial crime is an important priority and that's also a struggle within the client base that we work with. And last but not least, I think Chris alluded to it, is the modernization of the legacy infrastructure which the banks and the legacy players are saddled with. You need to in order to respond to the competition as well as to remain relevant and grow in a compliant way, you need to look at the modern secure stack and make sure that the stack is designed, built to respond to market opportunities in a very agile way and in more real time way near real time way.

(10:02):

Those are the three things I feel are the current struggles and that is most of the conversation that we are hearing across our client base.

 Manishi Varma (10:11):

No thanks Vivek, that's really helpful. In fact, both of you touched upon real time either from a payments perspective or from a capability perspective. So Vivek maybe I'll just do a follow up with you as you're thinking, banks have this vision about how I want everything to be real time, but the fact is that over the last 20, 30 years or in fact even more several decades, they've built processes, they've built capabilities that are all batch, right? And just to think about how do I transform from everything that I could do it in two hours, I could do it in a day to doing everything in real time seems like a humongous task. So how are banks approaching this?

Vivek Dwivedi (10:58):

So I think that's a loaded question because you can come at it from different perspectives and basically more focus on the kind of conversations we are having in this space. One is that we are seeing across the board that there is a focus on customer journeys and keeping customer in the center rather than your product or your offering in the center. And then thinking about how do I remove friction in the journey? So focusing on customer journeys and fleshing them out is this important starting point in the journey towards real time. So one is that the second thing is moving to from an architecture perspective. So once you have the journeys mapped out and you have the things in front of you that this is how we want to transform the systems or the customer experience or agent experience, you're really looking at how do I design my architecture to support that?

(12:10):

And in that there is a clear movement towards event-based, cloud-based architectures, microservices based architectures, and that's enabling the banks to react, to move from the batch to an event-based mode where they're reacting not only to things in a bash mode but also in real time and also or maybe in near real time and dependencies are reduced on other systems and complexities reduced in the enterprise. And lastly, the focus on building first class data capabilities. I think that's once you have the architecture in place, you need to obviously worry about whether my data, which is quite fragmented in the legacy players who are incumbents or operate at scale, that how do you bring your data together and how do you build advanced first class data capabilities to allow your AI to function and also to make sure that you have the data is available through APIs and not really siloed across the organization in that sense. So really three things I would say customer journeys based thinking, event-based architecture and first class data capability. So these are the three things that we see banks are focused on.

 Manishi Varma (13:51):

Sure, and just from a prioritization perspective, you think it'll be the customer journeys, prioritize those journeys and then solve for journey at a time or how are banks looking at that?

Vivek Dwivedi (14:01):

Yeah, I think it really depends on what you're trying to do. If you're trying to modernize the core, then you have to be very careful because you have to take, these are systems which are built over 20, 30, maybe 40 years back. So how do you modernize them from taking customer journey as a starting point? You have to pick up the ones which will give you the best return, but at the same time you have to worry about the structure of the organization because if you can take something or prioritize something upfront, which requires a huge organizational change that you want to really weight against the risks. So I think that's a complex decision that which journeys you pick from a prioritization standpoint as the first ones to attack and which ones you kind of layer or prioritize later. Because anything that you pick to modernize will have not only a repercussion on the technology landscape but also a repercussion on the process side or the agent side operation side. So you've got to prioritize based on the returns you're getting as well as the risks that you will have in picking that up.

 Manishi Varma (15:25):

Sure. No, thanks so much Chris. Helpful Chris? Yes. You want to add something?

Christopher Esch (15:30):

No, just while we're on the topic of faster payments, just one additional consideration I thought was always interesting there is we talk about adoption. When are we going to see a massive adoption in the space? We'll actually change, will people move off wires and ACH towards some of these faster payment rails? You've got fed now you got RTP. One of the challenges, at least for the big banks, I think a lot of them already are on the networks. They're building that for the smaller banks, not long tail, the 8,000 in the US servicing is a major consideration for them. We talk about everyone wants to do things in real time right up until you have to support it 24 7 because these guys don't have the infrastructure for that. So what I think we will see, and we probably already seen to a certain extent is dipping the toe in with a receive only fashion because at least then you have some capabilities on the network and you can support certain use cases, especially if you want to have, you want to enable people to get real time paychecks for example.

(16:21):

The question is where is this rank in their priorities? And right now I think with the ISO migration deadlines, especially with that being pushed back, at least in the conversations we've had, once that is done, people have this next on their roadmap to look. So anyway, the nice thing is that gives more time for more use cases to emerge in the market. You're already seeing the limits on some of these rails go up. I think now what that now just went up to a million. I think RTP was a little bit before that kind of opens up the door for the different use cases you can have. So anyway, just an interesting kind of foil to that one.

 Manishi Varma (16:48):

Yeah, no, that was very useful, thank you. So Chris, just one more as we are talking about the build and the transformation side of the world, one of the questions that organizations or banks typically grapple with is especially since they have a lot of infrastructure, is the build versus reuse versus buy type of question. How should they look at this?

Christopher Esch (17:11):

Technically they put it very well. One time the quote was, I think buy is faster but it doesn't quite meet your requirements. Build on the other hand is a little bit slower, but it also doesn't meet your requirements and that was, there's a little suck a cheek in that, but it's a little true. So maybe just taking a step back, how do we think about buy versus build or generally what's the mindset? The mindset is if I'm going to buy something, I am somewhat flexible in my requirements. I have an idea of where I want to go, but I have some flexibility in there and it is worth me getting to market quickly and being able to do that with minimum cost, minimal configuration and I'm willing to give that trade off on differentiation and specification by requirements. I also might really value the strength of support and ongoing patches in the future.

(17:59):

From a buy perspective, or sorry, from a build perspective, you choose that route. If you're saying, well this is core to my business, I need this specifically work this way, if I'm going to be competitive in the market, if this is a core competency for you, you're more skewed towards going into that buy route. The trade-off being increased time, increased cost, and increased thought about how do you actually support this thing down the road. The third option which kind of sits in between is the reuse and it's saying, well I've built or bought things in the past and I think there's an applicability to apply that to the current use case I have. And the person in the room who's saying yes is the tech architect who's saying perfect, we're going to mitigate the proliferation of different systems we have in the overall enterprise and hopefully this makes it a little bit more streamlined, a little bit easier to manage and we get some efficiencies at scale.

(18:44):

Now the challenge with any of these things is there's some additional items that probably don't get as much attention. So when you think about things like ongoing support, right? If it's a build solution, you're going to have to make sure that this is, you build in a way that there's going to be talent available in the market. Who knows how to do this? You've documented this solution accordingly. You don't end up with key person risk. One example, I have a lot of clients who when they're building a new customer facing platform, they'll end up usually choosing a react just because the availability of talent on the network, they can actually get internal folks who know how to use it, they can easily find trainings for folks to give them upskilled. And then there's plenty of sis that have capabilities there.

(19:21):

I don't think anyone's building anything custom on COBOL lately. If you are, talk to me please, but you want to make sure there's some support there. Maybe the only other thought on this one is the worst thing you can possibly do is make a buy decision and then choose to build the heck out of it, right? If you are buying something, you should be at least willing to have some flexibility in your requirements, some flexibility in the delivery and kind of being willing to tweak your processes a little bit to work within that. If you're going to buy a platform and completely tweak it to the point it's unrecognizable, you might as well have built it in the first place. And by the way, you're going to have a ton of pain when you're going through any kind of standard update patch releases. You're going to end up a few generations back and they're going to charge you an arm and a leg for custom service and support down the line. So that's how we tend to think about it. I'm curious for your thoughts.

 Manishi Varma (20:11):

Yeah, and is there a sweet spot in terms of the level of customizations that you feel works? I mean is it 80%? Is it 50%?

Christopher Esch (20:24):

I love whenever we try to put a percent on something and it's a near impossible answer, I'd say look, if you can customize something and it is in a modular basis where you can remove it and it won't break everything, you're good. So it also changes to how you build it. A lot of the challenges my clients have right now is they customize, not configured, but they customize the heck out of their old cores. And so now they have to basically do a hollow out microservices strategy. If you're building your customizations in a microservices based component where you could in theory swap that in and out, you're good. Now that's going to depend on you having a platform that supports that. And so I'm sure your tech lead will say 0% customization and your head of design will want to customize everything, put 'em in a room, make and five out.

 Manishi Varma (21:05):

Yeah, sure. It makes sense. Vivek, you wanted to add to that?

Vivek Dwivedi (21:09):

No, I think Chris has pretty much covered it. It's a constant struggle and I think really it is very contextual in what we see. There's a bank that we are working with for now. They want to do something locally in a particular market. They want to replicate what they do at a global level in that market because of data localization loss. And the question for them is that should they take their global platform and extend it or rather take a copy of the global platform and basically install it on soil and for that market or they take something from a third party, which is a buy option, take something from a third party and use that for that particular market and not overextend their global platform. So they're choosing to go the third party route because of the context that they are in. So that decision is based on the fact that the third party is a local party.

(22:23):

They are bound to be compliant with the local laws over a longer period of time and they provide the functionality that this bank needs but not really completely maybe 50%. But the bank is choosing to go with them because they realize that on an overall basis when they do the comprehensive analysis of which way to go to that going the third party route or the buyout is going to be the best route. That said, the question is that the fiduciary responsibility of compliance and reporting and all of that will still lie with the bank. So they will have to build integrations from this third party platform to their ledger, to their compliance systems and all of that. So as Chris said, the decision about build versus buy versus reuse is a very complex decision. It needs to be taken very, there are multiple parameters.

(23:28):

It's very contextual to what you're trying to do and it's also depends on who you are and what kind of play you want to make with that particular capability. And do you have the capital to go the build route fully? There are players who in payment space who have the financial muscle and the market differentiation and all of that to build something out completely end to end then. But those are far and few in between. When you look at the business capability map of what you're trying to build, you can pick and choose certain capabilities that you will build and certain capabilities that you will buy for, but then you need to have a very strong in-house integration muscle, right? You need to have integrators within the organization or others that you trust who can stitch it together for you and then support it as Chris said. So I don't think that there is one size fits all. It's very contextual, but it has to be very deliberate.

 Manishi Varma (24:34):

Sure. Excellent. Thanks so much Vivek. So we've got about five minutes and then after that I'll open it up to the audience for questions. So in those five minutes, Chris, I'll give you two minutes and then we'll make another two minutes before we wrap up. But I didn't want to close this session without asking for the key watch outs as banks are going through this transformation. So what should they be aware of? And I think this is for the entire room, so go ahead.

Christopher Esch (25:03):

All right, I'm on the clock. So whenever we have a client who does a larger business build, there's a few things we try to make sure they anchor towards. First, make sure you have a shared vision at the top or make sure you have a shared vision. It starts from the top to the bottom. So we usually, I, I'm a consultant, we put it on a few slides, but you want to make sure there's a clear vision. This is what we're doing, this is what we're delivering to customers and this is how it aligns with our business objectives. You got to make sure the executive team understands it, your product owners understand it, your devs understand it. I want the QA guy who just got in 20 minutes ago to be able to recite this from facts. Now sometimes that's going to require boiling it down to something that's a bit more digestible.

(25:41):

You'd rather have everyone on your team understand 70% of the goal than everyone have a different interpretation and that they think is a hundred percent right. So second part is once you get everyone aligned, keep business in tech in sync, the worst thing you can do is throw the requirements over and suddenly try to circle back. So whenever we're on the ground, I'd probably say cross-functional teams three times a day. This gets particularly challenging over the course of a longer build and that's the next point. These builds take a long time. If you want to get something meaningful, and I'm not talking about a small tweak to your Salesforce environment or automating one load process, this is a full business build. That could be, if you're lucky, six months before getting MVP to market, but more like 18 to 24 and then past that, the payoff schedule is going to be a little bit longer after that.

(26:29):

It is a daunting task because the bigger change you want to make, the more money you're going to need to ask for, the longer it's going to take to pay it off and the more anxious everyone's going to be along the way. That's why you got to keep people engaged, communicate transparently, but also make sure everyone has a view of what that vision is. Because as you are on that journey and you move into the, alright, you had the commitment ceremony, the executive stocks, everyone got really excited about it, now you're building it and you are two PIs in the pressure's mounting. You're talking about can we hit our MVP date? And what's going to happen is if you don't have business and tech really close aligned those pure product and development teams, they're going to start figuring, well, if we trim down this feature or if we cut that element and the first things that go are the differentiated capabilities, and if you don't pay close attention, if you're not integrated throughout, you will get to an MVP that you cannot sell, right?

(27:24):

And so you got to make sure you are building something that actually people will buy and people will want. So that gets in the next part, engage your clients throughout and that means clients, not just your rms, not just your salespeople. So if you are a leader driving one of these transformations, your first question be, who did we test this with? Generally the first response is, did you test this? I say, absolutely, yes. The question is with who? And they said, well, yes, all our rms and sales folks, and they said, this is great. And look, you want to keep them engaged. It is important to get their feedback. They're a great source of initial calibration, but you need to test with one your own clients. And that can be tricky, especially if you're in a corporate or commercial setting. Those interactions are valuable and there is a sense of I don't want to bother these people and I only want to take something to them.

(28:06):

That's absolutely perfect. So the way you engage with them is you create a kind of early adopter panel. You say, Hey, we want you involved in the process. We're trying to do something transformational. We want to work with you. How interested are you in participating? If they say, look, we're busy, it's fine, don't bother them. You can treat them as normal, but if they want to get engaged, bring them in the fold. One, you're going to get some good feedback. Two, you're going to start to identify your early adopters. So that's key. Next part of this is how do you test the things that you don't want to bring to them? If you have a question on pricing, if you have a question on, well, would you actually work buy this from us and you want to get a straight answer, that's when you need to actually get a third party blind panel involved.

(28:44):

At McKinsey, when we do some of these, we usually set up a no names panel where we get industry actually. So I do a lot in treasury management, we get CFOs, we get treasurers, we get assistant treasurers, and we can bring sanitized ideas, them sanitized wire frames, get everything from a, Hey, do you understand what this screen is? Should this make sense to actually testing broader requirements that figuring out would you support these people from a market entry standpoint? That's an incredibly important part of calibrating that. The last part is your responsibility. I'm just going to hammer it on one more time. Your responsibility as an executive is to say, did you test this with who? What did they say? Because when timelines get tight, that extra cycle of having to test it with a third party rather than say, yeah, that looks good, that made sense to Steve on the design team, so we're going to go with it. That's what you need.

(29:34):

A few minor other things. Hiring is really hard. You're going to need the right people for this. If you want to build a new business, yes, you want people who, excuse pun, know where the bodies are buried and also know how to operate in the company you're in. But then also if you have to integrate with existing systems, you're going to need some sort of continuity. That being said, if you staff this thing with the people that built the last thing, it's going to look a lot like the last thing and you're going to be weighed down by some of those things. So what we tend to suggest is, or what we tend to find as a successful model is you build bring in maybe 25, 30% of your existing people, but then it can be a lot of FinTech talent.

(30:11):

It's a lot of FinTech talent, it's a lot of startup talent. In order to do this, you're going to need to start hiring and that's going to be really hard. So everyone thinks, okay, if we're doing a business build, I got to get business involved, I got to get tech involved, I got to maybe risk and compliance and legal to a certain extent, you'll forget about hr. You got to work with HR right away and set the expectation, we need to ramp up this many resources, the standard processes that will not move fast enough. How can we get aggressive and meeting our targets and start communicating with them early because the lead time on that will kill you. Last thing is moving train. People want to join something that the good talent won't join. Something that doesn't look like it's real. So you need to find a way to make progress before you get the people on the ground. That is hard. So you kind of need to balance this. We can't make decisions that we can't completely unpack and can't go back if let's say you haven't hired your head of product yet, you don't want to. 'em have made every single product decision and gone too far down the hill, but you also don't want to say, well, we don't really know what we want. We were hoping you could tell us. So anyway, that's a lot of random rants. I have 12 others if we had time.

 Manishi Varma (31:11):

Alright, no, perfect. Thank you so much Chris. And just to round up, you said choral round up common vision, engage clients early in the process and bring in the talent, find the right talent as quickly as possible. Excellent. Vivek two minutes. Yeah, I think,

Vivek Dwivedi (31:28):

Alright, I think Chris has again covered a lot of ground here. I'll just pick up on the point he made about the structure and the teams. What we see is that poor outcomes are partly technology, but it's largely about the structure, the leadership and the ways of working. So if you're trying to modernize a legacy core platform, you really need to pay attention to the structure because as he said, and we see this often is that the new application or the platform will look a lot like what the old platform was just in a newer technology. So you don't want that result. So you, I mean there is a conveys law that the architecture is a reflection of your organizational structure and unless you have thought through the business capabilities that you are trying to modernize, not just the application, you will end up with either a big bang approach to the delivery, which is never successful or your project will continue to be on and never ends.

(32:47):

Because as Chris mentioned, these programs are long running programs, they take about two, three years to pan out and therefore very important to get both as you were designing the point of arrival, both from a system and a structure perspective, we had to make sure that both are changing at the same time and not just the system architecture. So that's one thing. The other is that whenever we are modernizing complex legacy platforms, we also have to keep running our existing platform and we have to make sure that the BAU, as we call it, the business as usual goes on. So the challenge there is that how do you keep, keep them in sync in the sense that how do you ensure that at the end of the day when you deliver the new platform, that there isn't a wide gap between what you have envisioned originally and what the BAU is today or at that point in time because the BAU would've changed because you're doing small minor enhancements and other things to your existing platform and your vision will basically be out of the window by that time.

(34:05):

So that's a big challenge and there are strategies around how do you ensure that the new build is in sync with the BAU. So you have teams, again, it again goes back to not only the technology sync, whether it's data or whether there is your forking on ingress, and there are different other strategies that you can adopt to ensure that the changes you're making to the BAU platform are reflected in the new platform, but under the new architecture, but also the structure of the organization. So I'm coming back to the structure, coming back to the processes because BAU is not just the platform, it is also the process and you're making changes to the process. So that's the other watch item and that has to be very deliberate approach. The other is there is this trap of feature parity. When we start a new program of this size of a large complex transformation.

(35:07):

The initial selling point is that to the management is that there will be a feature parity that the new system will have all the features that are there in the old system. And I think that is a trap because rather than shooting for feature parity, you're really shooting for business capabilities to be delivered. Because if you have a process today, which is a legacy process which is serviced over a legacy platform, chances are that that process is not straight through. Chances are the backend processes, there is a lot of manual activity, there is a lot of handoffs. You have probably built the system over many, many years. So you are really doing a lot of patchwork in order to deliver a particular business capability in the new world. When you deliver the modern platform, you don't want those patch, you don't want that patchwork. So you are really thinking through, not at a feature level, you're really thinking through at a business capability level that the new platform and the new process therefore will deliver. So I would say those are the few things that we need to watch out for in such transformations.

 Manishi Varma (36:22):

Yeah, no, thanks so much Vivek. That was very insightful. So that's all we have time for on the panel itself. We do have some time for any questions from the audience, so I think Megan's over there with the mic. Thanks so much Megan. So any questions that you'd like to throw open to the panel.

Audience Member Edwin Gold (36:47):

Hi there, my name is Edwin Gold, I'm with Visa. One of the things that we're seeing now among FI clients is sort of a stratification of the haves and the have nots in terms of technology and budget. So for example, you have obviously larger financial institutions with mega budgets that can take various approaches. How do you recommend smaller institutions think about this because they do only have a few dollars to spare and limited resources. Thank you.

Christopher Esch (37:16):

A few things. I mean, when you think about that build buy spectrum, the smaller you are, the more you're going to move to that buy spectrum. And then also, quite frankly, the reuse spectrum. So I have a lot of, maybe one example of this, I have a lot of small clients, they use Salesforce to do almost everything. It tracks their leads, it tracks their openings, it tracks their servicing tracks, their implementations, and there's actually advantages to that. You got to have the one system that you can sell your people to use. You can consolidate your developers in that area. The problem I think happens for them is they have that one system and they treat it as everyone builds on it independently. So you your, oh, we have the sales team and the tech person sales builds this out. You got to have a platform strategy on that where it's like I have one person oversees it. We will strategically figure out where to deploy our resources, especially if you only have so much to do because you don't want people building things kind of that either conflict with each other or just not reusing some of the devices, some of the platforms you've put in place.

Vivek Dwivedi (38:09):

Yeah, I just maybe add another thing too, especially when it is a mid-tier bank or not as the big banks, I think it's how do you create the operating leverage? Meaning if you're, I think with digitization and with AI you can create that leverage within a smaller bank. What we have seen is that, for instance, you take customer onboarding as one business capability that a Mid-tier bank has and see if we can digitize customer onboarding and using the power of cloud, using the power of ai. What it does is that it allows the bank to have the headroom to do other transformations. I mean, as you said, they have limited budgets, but how do they keep the budget at the same level while they continue to grow their revenue? And then that's what I meant by operating leverage that creates that space for them to then do other transformations. So what we have seen, some of the smarter banks, the regional banks do is use this power of cloud, use the power of digital, and now the power of AI to take a business capability and basically digitize it. Just focus heads down on that because it creates that headroom for them to then fund or self-fund the other transformations.

 Manishi Varma (39:40):

But yeah. Great. So we are on the top of the arc. So thank you so much everybody here for joining us in this panel discussion. And as part of the audience and Chris and Vivek, thank you so much for being part of the panel. Thank you very much. Thank you. Have a wonderful rest of the conference.