Two things to look forward to:
- Deep dive into building digital-first engagement models
- Learn from actual case studies featuring Finacle Clients
Rahul Wadhavkar: (
Thank you so much for being here. I know post lunch sessions are not always difficult. But thank you so much for attending. Let me just quickly introduce myself. I had the product management group for Infosys Finacle Banking, commercial banking product. And with me, I also have Dan Boone. Dan is the head of our client engagements for banking services products. Today what we want to do is, spend little time, talking about digitization in commercial banking. I think I know that's the theme that we have been addressing for the last one and a half days. What we are gonna talk about. We heard about experience. We heard about how personalization is important, what we wanna focus a little time on is how do we actually do it? We want to introduce to you our stack of applications that actually enable you to do it. When we were discussing this session, a few weeks back, one of the questions that came to our mind was, why, why this topic, right? And then it goes back just flashback to about 2015 or 2016 digitization in commercial banking was really not such a hot thing in the market. Yes, it was coming on. It was getting traction, but the general perception was, oh, if you're looking for some cool user interface, if you're really looking for some really, sexy experience, that's for the Amazons of the world, that's for the consumers banking line of business of the bank, as far as enterprise software was concerned, we are okay with clunky screens. It was okay with having green screens and a few extra clicks didn't really matter. And that changed in 2014, 2015, that entire paradigm change. We seen a ton of investment dollars flow into this. And for now, for the most part, most of our, when we talk to banks, most of the investments that they're doing in commercial banking space happens to be broadly in this area. For that matter, even if you go back to 2015 or 2016 timeframe, and I used to work with Bank of America, at that point in time, they were probably the top three or four banks that really had the best commercial banking, cash management experience applications. They were leaders. Those were sort of the benchmarks out there in the market. And they're still leaders today and they've got some really incredible, software applications, but you see a lot of other banks have really moved forward in the course of last five years and they have caught up with some of the leaders in the industry. So that's something that we see, that's incredibly important. We at Infosys, we have been in the commercial banking business for close to about 35 years, 35 years Dan?
Dan Boone: (
Yes.
Rahul Wadhavkar: (
35, 40 years. We are not just into the experience space. We understand this aspect very well. There are two things that really come out for us when we talk about experience and what really distinguishes us from some of the newer players is when we talk about experience, the interesting part that we see especially in commercial banking, it's the, what part has not really changed the, how part has changed and what do we mean by that? How you do your loans or overdrafts or your trade finance transaction, or how you apply for a letter of credit or your supply chain loans. The same thing, the underlying process remains the same for the last 15, 20 years. None of that has changed. So what has really changed it's how banks are offering those products and how clients are using those products and how banks are servicing that. That to us really is digitization. So we want to quickly introduce to you one slide and I promise this is the only slide I'm gonna show you. I know this is second day of the conference. We are not gonna show you any demos. We'll stick with just one slide and then just walk you through some of the concepts that we want to talk about. This is sort of broadly the structure that we use in our overall product philosophy. We believe that this is something that helps banks strategize in terms of their journey towards digitization. And also more importantly, and we'll talk a little bit more about that. It helps the banks introduce some of the newer more agile functionalities, open banking, I am pretty much sure everybody's talking about that. Everybody's talking about API and the framework. So this broad structure really helps us present to our banks, how they can actually implement the whole digital strategy. What's also important in here, and this is something that when we talk about experience, and then we talk about orchestration, what does get missed and I don't know if any traditional bankers, in the room here. Banking logic is complex and you can't leave that logic behind. Some of the reason I said earlier that the user experience in the commercial world was not all that great. It was not great because, you know what the underlying running logic for say, let's assume, supply chain finance or trade finance was complicated. It was difficult to transition that into a really great UI. So what our benefit or the experience of 40 years in the industry has done is we have been able to take that logic, the underlying dirty business complex logic, but that is required, which you can't get rid of, and then transition that into a better experience. And I think that's what really distinguishes us from some of the other players in the market. So let me start off really with the top player. As I said, all our products are structured like this. When we implement these solutions that we have done this close to about 450 implementations globally, broadly, they follow, a similar structure. So let me start off with the top layer. Again, most of the conversations last day and a half have been around experience, and that's incredibly important. What we did when we rearchitected the entire product set about six years back was to realize that the whole experience piece, no matter how good we define our user experience, and I'm sure plenty of bankers here would agree with me. The bank always would think that they can do a better job on that. So our product really comes up with a good user experience, a good contextual user experience, but the differentiator here is on day one of our implementation, we go to the bank and say, you wanna do a better job of this, be our guest, go and do it, build your own UI. It is the skin of that, that the bank gives us. And then that skin we put on top of our application, entire flexibility bank remains in complete control of your own destiny, gives us the freedom to basically just oversee the whole process, and gives bank that whole branding legal perspective they can bring in their own creativity in that. Having said that let me also qualify this for the most banks is more easier said than done. And why is that so? It's very difficult for two people in a bank to agree on a user interface. And it's not easy. It hasn't been easy on our side. I can't remember how many times I've had arguments with my design team and my product development team and my engineering team on how the user interface should be. So it's never easy to have two sets of people in a bank, especially within a larger setup to agree on what a good user interface is. So this is something that is great if you're able to do it, but it's easier set than done. People we have had, we actually have a separate business unit that just does the user experience part, several other companies outside of us, do that as well. The only caveat here would be, if you choose to go down this path and many of our clients have done that, they have done that so well that I will be honest in saying when we actually look at their applications, it's difficult to believe that it's our own application running at the back. They have completely transformed the UI. So if you have the bandwidth, this is just the way we enable you to do it. The next piece really is what we believe is the heart of the entire digital experience. The top part was the experience part it's UI. It's pretty screens. It's workflows. Sure. You can still manage that. So what is the bottom piece? That's what we call the orchestration layer. So let me explain this with a few examples. Again, since we're commercial bank in a commercial bank seminar. Let me ask you a question here. If your client happens to be Expedia, right, as a bank, if your client happens to be Uber, why should their experience be the same as what you would give to an ExxonMobil? There's no reason for that. If I'm either one of them, I'm gonna say this doesn't work for me. This is like a cookie cutter approach as in oil and gas. My specific needs are different. I need to see a different kind of an interface versus what an Uber treasurer would want. So the channel orchestrator there enables you to do that. What it does is based on who is the person logging in, it would look at what industry, what profile, what role profile, and then shoot up the right experience. Now, just go back to the conversation about experience that I mentioned before. It's not one experience that you're building. Now, you are basically in control of your destiny to the extent that you can build as many experiences as you like. You are very strong in a particular industry, in a particular role, you build an experience for that. You are in 50 industries, you can build 50 experience for that. That's what the product lets you do. All of that is controlled from that orchestration layer. So that's the channel experience management piece. It goes down further to the level of more granularity. You can have a different experience for the treasurer to manage liquidity because that person doesn't need to see how many cheques need to be approved. You can take it down to an AP clerk's experience is different from an AR clerk's experience. So, there's no limit to how deeper you can go. So it's the level of person. And then top of that, there is personalization, of course. So the moral of the story is that entire channel experience that we have been talking about a day and a half, what the digital engagement layer at the bottom enables you to do is you do it. Banks can be creative enough and they have done outstanding work over the course of five or six years. The layer at the bottom helps you orchestrate that. Well, what next? That's just one portion of it. It also does channel administration. Now, what that means is basically, well, your client wants your accounts payable clerks to log in only between 7:00 AM and 4:00 PM. during the day, or you want them to approve their payroll files only between 12 to 2:00 PM, whatever that your rules could be, or this person is on vacation. And now that person's access needs to be taken off. The entire, administration part of it, or the boss can approve a payroll file on phone, but the manager cannot, he needs to be in front of a terminal. So that entire, the channel administration piece as to who can do what, and by what limit, again comes back to the orchestration layer. So it's like sort of the quarterback for your customer experience that's happening. And I want you to appreciate the difference between the conversations, yesterday and today. Most of the conversations have been how good the experience is. What we are talking about here in the middleware layer is really the orchestrating layer for the experience. You give us the experience. We can give you ours, but if you can do something on your side, you give us the experience, we will orchestrate it. So that's the second part. What else does this do? Well, this is the enterprise bus, right? Imagine you have a situation where you have five DDA applications. Many banks have not, may not have five, but two, three, you have three payment hubs, two or three liquidity management hubs. How are you getting all that information to your client? Most times we see banks are building point to point integrations. Your data is disparate. Some systems is real time. The other systems don't support APIs. The third system is running on a batch mode. How do you really do that? So this being an enterprise bus, what this enables you to do is basically have one point of contact with all your backend systems. Pull the required data, could be data warehouses, could be your trade applications, your supply chain applications, invoice management, positive pay, risk, whatever, and then pull that becomes a wrapper on top of everything and present that customer view to the customer, what that enables. So it comes with its own database. What that also enables you to do is now run analytics on top of that, on your customer data. Now, when in my earlier days in banking, every time we had to run payment analytics, we had to run to the payment hub. We had to run to the payment warehouse, try to pull data. And then depending on that, we were able to give customers that information, now with this middle layer, because that one connection is already built into the application, or you can run all your transactional operational analytics on top of this, and you're not really touching your system of records, your core transaction processing engines. So it's from a architecture standpoint. That's what makes sense. Well, what else does this do? So, this is open banking. Let me ask you a quick, how many of you all are aware? How did open banking really start, or what is the genesis of open banking? Let me just quickly give you an idea. It actually started in 1982 and I'm pretty sure many of that would be a surprise to many people. It was a group of 20 German banks led by German post office that got together and created this concept. And then they did it as a POC to see how they can exchange data and exchange transactions amongst themselves. Now I'm pretty sure everyone has heard about it today. And all banks are trying to build API layers and API structures too, to basically support that. How do you do it again, going back to an earlier example, when you have three DDA systems and five payment tubs and two other liquidity management systems, it can basically plug into the middleware layer. So what it does is, it also has an API framework. It can expose the APIs to all the external parties. The same APIs can be used to pull data from your backend systems. Say tomorrow, if you want to connect with a PLA I mean, it's one of our Alliance partners. They're here in the conference room as well. You could do it right through the application. So it's something about how that middleware layer, how enabling that middle layer, enables you to basically fast track your open banking and API journey. Embedded finance. Another one of our clients very recently, and we only have a couple of clients who have done that, just full transparency. But how does that happen? So, anybody, any banks here offering payroll loans to an AP transaction, when the AP clerk is uploading a payroll file and how cool would it be? Right. And you may not even be doing that kind of a transaction right now, but now I have traditionally all the commercial cash management applications, we have had payroll transactions, right? Standard stuff, somebody uploading a payroll file, but how many of us right there at that instance are able to give an ability to be able to offer a payroll loan. And I think the lady from squares mentioned yesterday, they were trying to do that something on small business side. And that's the same concept that we have applied here. What the beauty of this is you as a bank, you may not even be in that business. You are probably for whatever reasons you want to go to your sister concerns, or you want to go to a different party, or you wanna go to a different application altogether, not even your core applications and offer these lending products. When going back to my example of payroll, the APIs will, the digital engagement hub API will let you connect to your backend systems or an external party, and then start a loan transaction within that payroll transaction that you're talking about. Again, it's the orchestrator layer that comes into picture there. So that is really the broad gist of the engagement hub. We believe that is really the heart of engines while everybody talks about how cool is it to have a good commercial banking and a cash management experience that if there's very few conversations around, well, if I'm the CIO in a bank, this all sounds great, but implementing it is so difficult. And that's where that middle layer comes into picture. Now, again, being a bank, you don't necessarily need to replace everything that you have. This is that middle layer. This is a virtual layer that comes in and you are doing this. I mean, if you look at your own application environment today, in some way, shape or form, you are already doing this, it was just that when I talked about having different experiences for different industry segments or SME experiences different from a large corporate experience, many banks are probably offering it today, but how did you do it? You actually had a separate application environment running. So this optimizes all of that. So that's why we feel this is the core of your digital transformation. The front end is good, but there's something else that needs to be at the back. And that is that layer to really make that front end contextual and bring in that operational efficiency. So at this stage, I'm gonna throw question to Dan, from a market perspective. Dan, I would love you to share what you're seeing in the market, especially from both perspectives, a large bank, a bank with more sort of complex application environment. How would they look at something like this and then, implement it in their scenario and then spread it on the other side, talking about a really small bank, the NOVO kind of an operation, and how would this kind of situation work for them?
Dan Boone: (
Thank you, Rahul. Well, in a large bank, there's a lot of interest to partner with FinTechs and have a FinTech firm with their clients come into your bank, and then you could do a lot of the processing and services that they wanna leverage. This is a perfect way to integrate the FinTech in with complete control and knowledge of what's going on and the flexibility for them to have different types of clients and arrange it that way. And we've seen a lot of interest in this, this piece, this digital engagement hub from large banks for that. But it also makes it ease of use for smaller banks too, because there's really one place where all of your user interfaces and client interfaces are gonna come through the bank and leverage the backend functionality. So we've seen that both, on a simplicity and control, but also a way to integrate with FinTechs without a lot of heavy lifting to go on, right. And it's all done through restful APIs.
Rahul Wadhavkar: (
True. And again, one of the things that we talk to clients about, especially we put ourselves into the shoes of the client, we don't expect our clients to come back and say, well, we are gonna change what we have, and we are gonna put something like this. Though absolutely, that's unrealistic. That's never gonna happen that almost never happens unless, it's a NOVO bank. All this again is microservices enabled. In most cases, what we have seen our experience of how banks have implemented this is they use the layer for bringing in an efficiency into their existing environment. They transition over their existing processes onto this. If they have multiple backend applications, they start off using this at the enterprise bus, trying to consolidate data and then slowly transition over and then increase the capacity of what this application is doing, the last but not the least. I mean, that's the core layer that we do wanna spend a little bit of time on. And again, as I mentioned earlier, what difference differentiates us from a lot of the FinTechs versus, Infosys Finacle? One of course, we have been close to about 40 years in business. Our first banking product was made sometime about mid of 85. And then of course we have subsequently rearchitected it at multiple times over the last one being about 2015, 2016 timeframe. But what that really gives us is that depth of banking and depth of having implemented this in over 450 different installations, what you see at the bottom, these are your core system of records. These are your core work horses in the bank. This is your DDA, this is your payment hub. This is the core sort of backend grunt application. That's managing liquidity and deciding how much money to move from client account A to B. This is doing issuing letters of credits. So we as number one, we as Infosys from a talent standpoint with deep experience in that bottom layer, this is what we have done for 40 years. So there's a very strong team that focuses just on that aspect of it, but how do we, when we said, we rearchitected this 2016, what is the reason for that one was of course scalability, but the other big reason was, how do these traditional or legacy areas of banking, but this is still the core aspect of banking. How do these legacy areas of banking scale up for being digital and everything that we talked about at the top, the experience layer, the digital engagement hub, they all work fine, but if your core aspect, the foundation is not right, none of that is gonna work and you might not buy any of this stuff from us and their customers who just buy the foundation there and then buy some of the other stuff from other vendors. But the understanding is the foundation has to be top to really be truly digital. And that's what our rearchitecture and investment was. It's a funny conversation, just about three or four years back. We were selling the core banking, DDA application to a bank in, in Europe. And, it's one of the largest banks. Eventually the implementation was successful. But I still remember one of the things that the CIOs actually told me, he said, look, I've got a banking system, which works great in terms of doing the traditional functionalities, but you know what my problem is, it doesn't give me alerts. It just doesn't have that capacity to send me notifications at the time I want. And then their operations was complaining, the customers was complaining. So it was good in doing the traditional things, but was not able to offer something as simple and as basic as notifications leave aside some of the newer cooler things that we talk about APIs and microservice and all that, that was beyond, these are traditional green screen applications and no offense, but more traditional legacy applications doing the grant work, doing massive processing, good at what they're doing, but that's about it. So our architecture, our investment in that bottom layer, which really forms the quarter banking was in terms of modernizing and enabling the banks for being digital. So many of our customers globally as talked about 450 customers, many of them have bought the bottom layer and then build the top layers on top of again, as I said from other players and that it enables them to do that because the bottom layer is solid. Now a couple of things only I wanted to quickly touch upon, on the foundational layers microservices enable. So again, going back with the earlier conversation I had, we don't expect banks to change their DDA systems every five years, six years, impossible, impractical, too expensive. So one of the things that we did in our architecture was every functionality was driven by microservices. So what that means is users just for a very, very small component of your processing, or what's hurting you the most. And we deploy the application again in cloud mode, on-prem we support all of that, whatever the bank's preference is, but deploy just for a specific functionality that is probably costing you more, or that is bothering you more, or that's a big lacunae for you in terms of being able to give that digital experience for the client. So that if clients have used us just for an aspect of loan processing, if clients have used us just for an aspect of supply chain management, and that has enabled because of the new architecture, we couldn't do that in 95, 98, because it was a monolith architecture. It was all or nothing, a standard bank in a box, kind of a thing. With the rearchitecture, we are able to offer very, very small microservices within the overall ambit of core banking, everything that you would do. We are able to break it down into a very small service and offer it to the bank as a service. So, Dan, again, I want to throw it over to you. We talked about the experience from the digital side, just wanted to share your perspective from a backend perspective. What are you seeing in the back market, both from a large bank and a NOVO Bank perspective, and this is a challenge, right? I mean, changing a payment tab or a DDA system, how do you go about advising your banks in, how to look at our solutions?
Dan Boone: (
Well, most of this is where digital crashes into legacy world. Most of the core that's running in the United States is gonna be an IBM mainframe or as 400 platform. So all the digital straight through process, it comes and slams into batch windows. The batches have to rerun. You made illusion to certain alerts, not being sent out at the times. You have a lot of shadow posting systems, which complicate things all day. So, one of the things that Finacle core is straight through processing. So when the transactions come in, they update the accounts immediately. Now, what this gives you is the ability then to think more broadly in, corporate cash management structures and leverage something, we have virtual accounts. So the virtual accounts are something that you can leverage with us. Most, there's not many people that even offer it, live in the United States. We have two top 10 banks that are running our virtual accounts at the moment. Our liquidity management structures and it's multicurrency and the way that, you can, especially for cross border payments and transactions work. Now, we are seeing a lot of interest in virtual accounts for FBO processing. Either if you're doing for benefit of processing, it's gonna usually be a one for one account, or it could be an Omnibus account that has to be reconciled. So think about the idea of having a FinTech with a hundred thousand close customers connect through, and then have virtual accounts on the backend of that each one for their customer, it changes the way things can be done. Not only that our whole processing model is based upon a composable banking, it's getting more composable with microservices, as we keep continue to modernize our platform year after year. So, you don't have to take our virtual accounts module and our core we've implemented it against Hogan core. So it's a very flexible way to get in and expand some of the offerings that you have competitive offerings without rearchitecting. Everything. What we do see is that, the core is kind of out of scope, from most banks to replace, but we're approaching it more from, hollowing out the core. So you could pull all of your file data out and put it in our customer data hub. Again, it's a cloud ready containerized cloud ready deployment. We're running it on the public cloud for some banks to currently or private cloud, or on-prem if you want. And, you could start pulling out the core and then implement subsequent changes, pull out product after that's done. And then you're just left with the DDA counts, which is much more, less risk to encumber when you go over at that.
Rahul Wadhavkar: (
Sure. Terrific. Thank you. And just one last, I know we are short of time. Just wanted to throw out the aspect that Dan mentioned, that how you actually hollow out the core and then how you selectively implement some of these systems. One of the example that really stands out in my mind besides the one that Dan mentioned was one of the top two largest banks in the US, in consumer banks with massive global operations. We signed up for 36 countries implementation for them. And, the approach was, of course they wanted to take all those countries digital, but the reason I bring that up, is because every single country is a different implementation. It's not like they bought the top layer, the middle layer and payments from us. Every single country went ahead and decided what they wanted, and they carved out a different portion from our stack. And that's the setup. So it's 36 different clients for us, 36 different implementations, but all of them fall in the same structure. So thank you again. Thank you everybody for listening. I really appreciate all your time. We are here. We do have a booth here. I think, the number is 310, but, look for Infosys Finacle. We'll be happy to talk to you more and share any more information that you would need about the products. Thank you so much for listening.