PegaWorld iNspire 2024: Smart Dispute Implementation for Truist Fraud Solution Services

So who is Truist? And Truist was founded in 2019 when BB and T and SunTrust Bank merged, which was the biggest bank deal since the financial crisis in 2007. Truist financials is a purpose driven financial organization which committed to inspire and build better lives for communities, and we are very dedicated to make a contribution to the communities in which we serve. Through Truist offers a wide range of products through our wholesale and consumer businesses. We are headquartered in Charlotte, North Carolina, and we are a top ten bank and we have 550 billion in assets as of March 31st, 2024. Our focus is relentless customer service, and I would like to share with you our new ad campaign. Hey, dad. Hey, sweetheart. What are you doing?

I'm gonna clean the fence. A lot of fence. You wanna help me aim up the wall? Go get closer. What the. All right. Side to side. When you work with someone who knows a lot and cares even more. You can do this.

You're unstoppable. I said you ain't seen nothin yet. Baby, you just ain't seen nothing yet. Are you kidding me? You can do this at Truist. We believe the same is true for banking. All right. I really love that ad when I heard it the first time. So why change?

Um, uh, we went through a merger, as I mentioned, and at the time when we went through the merger, truworths already or at the time already was busy with a journey to implement Smart dispute. The merger actually halted that endeavor for a minute. And then after the merger, we found in the March April time frame that our fraud was spiking through the roof and we became the new target on the block. And so at the time, we decided to re correct the effort and we went through a whole evaluation process. Again, we didn't just decide to go with Smart Dispute again, and I'm really glad to share that smart dispute once again came out on top and was considered the best solution for Truist. So why change? Why did we decide we already picked. During the merger, a best of breed application between the two organizations. So why change?

Why so quickly? After the merger, did we make decide to make another change? Well, um, the one thing was our customer experiences. Suddenly, um, we spiked on customer complaints. They called in, wanted to file a claim on a pending transaction, and we said to them, oh, sorry, when it's posted, call us back, then we'll help you. And so that became a big issue. The other issue was that we had, um, omnichannel. So we have the mobile app, we've got our online banking, we've got the branches and call centers using their individual experiences to capture claims from our clients. But the questions that we need answers for when we submit to visa was not consistent across the channels.

And so when the claim was or the dispute was submitted, our investigators had to call clients back to collect additional information before we could actually process their dispute. So that was actually a fairly poor experience. The other thing was because we were not integrated with visa, we had to submit each transaction that was disputed manually, and so we wanted to improve our efficiency and get our clients their credits much faster than having to wait for a couple of days to actually solve their disputes for them. So those were the primary things why we decided we we need some change, because now we were an organization with 15 million clients, and today I can hardly walk down the street and talk to somebody who who have not had an experience where they saw a fraudulent transaction on their accounts. And what we also learned was that 4% of the clients that had a poor experience would go and seek greener pastures, or what they perceive as greener pasture. So change was needed and we all got together and we defined seven objectives that we needed to achieve with our effort. One important item is always our governance, right. Meeting regulatory compliance. Ensure that we send letters to our clients in a timely manner.

Your SLAs, etc. then I'll group the others a little bit together, like your customer journey, your teammate experience, and your unified resolution. You wanted to make sure that your client can file for all claim claim types in one of the channels, so we wanted to give them a self-service omnichannel experience. We also wanted to remove the frustration with our teammates who are measured on performance. We wanted to remove that to so that they can more effectively collaborate with others with the client, um, to to work through the process. And then, of course, we wanted to have a one stop resolution. Platform. And with that, I mean, initially our vision was this big. We were going for deposit products like ACH, seek, Pin, Zelle, and then we figured out that this will be awesome for credit card as well.

And what does that afford us? It affords that you do better workforce management, because the people that are helping our clients can now be shifted between serving a debit or credit card. Your training is simplified because you train them on one application. And so that all gives you the flexibility to run more efficient operations. Then the second grouping that we have was really to have controls look at our financial gains and then analytical reporting. So from a controls perspective we wanted more transparency timeliness accuracy. And I don't know how many of you have dealt with a batch job that fell in the middle of the night. And the letters didn't go out on time? I mean, hey, those are real things.

We wanted to reduce our fraud losses. We wanted to be able to reduce the time for when we submit a transaction to visa, um, with straight through processing, which all drives our losses. And then we also wanted to make sure fraud didn't realize with the client on a pending transaction before we even blocked it to actually even post. And then lastly, when we looked at our detection and prevention, um, business, it was really, if you're awesome there, you really shouldn't get claims. And we all know that that's not a reality, right? We all always miss something. And fraudsters are the most smart people actually want to hire them. But with with feeding then out of our resolution or smart dispute database real time making information available so that detection and prevention can see. Ha!

This client just reported a claim. Why didn't we catch it and then provide those that data for them so that they can do analysis and improve their models will actually reduce the number of claims in the dispute. Platform, which is probably not a great story for our cost of ownership, but really a great story then for detection and prevention. All right. So those were the business objectives. So let's transition to key capabilities. We all everybody familiar with Smart Dispute knows that we the Smart dispute platform was developed to have five primary phases intake enrich investigate recovery and resolve. But then also Smart dispute is a case management system that comes with core capabilities. That makes it something that's already there.

So you can just build on it. You get guided workflow and SLAs that's built bold. And, um, you can do your workforce management through access controls. Who is in the system, what work you are they in? We prioritize their work for them. And then lastly, awesome, awesome audit history that you can actually go in and see what happened. Um, there's no more uh, let's go into the Splunk logs. Let's go here. Let's go there.

It is definitely something that is a big benefit for us. All right. So key capabilities. Let's talk a little bit about our solution. Um so we have our omni channels. And then we have integrations with other applications in the bank. Um we have a suite of shared services and maybe not as prominent here, which we in hindsight should have added. We actually developed an orchestration layer and then we have our smart dispute solution. It is built on Pega Infinity 8.7.

And then we implemented, of course more dispute on top of that. And then out of the box you get your different card layers, visa, Mastercard and then your different payment types. And then you can have two product lines. You can run both debit and credit card here. And then of course this takes care of RAC e and RAC Z. So that is a very powerful capability. Um, and probably one of the things that I'm mostly answer when I get audit requests on my application. So, um, the integrations that that come with a solution like this, of course, is something that you need to configure. It's not out of the box because it's fit for your use, right?

So you need to interface with your deposit system or your card processor or your, um, customer communication platform. We developed specifically a platform to be able to communicate with our customers that's reusable between debit and credit card. Of course, we interface with verify Ethoca. And then um. As something last week, as I mentioned, we wanted to have the enterprise data lake and all to serve detection and prevention in and then of course do some analytical reporting for our clients. Um, then I wanted to talk a little bit about the partnership that we have, this This project is challenging in many ways, in the sense that we have an existing legacy system and we are implementing a new system. And so when we started this, this journey, we acknowledged that we need a couple of experts, people that's out there running around in the market every day, serving several clients that can bring their knowledge and help us so that we don't have to start from the bottom up. So we engaged Pega, and we work for a month or two and we developed a roadmap. We referred to it as our Sprint one, and we came up with a minimum viable product to take something to market.

And we identified that we were going to do second pen first, because that really is 70% of the claim volume here at Truist and Truist. Responsibility was to work on an on the integrations with the other systems. We are familiar with that because we already have a system in place, and then we wanted to establish an orchestration layer a little bit more about that later. And then to just put the cherry on the ice cream. We also engage Cognizant as a Truist Global Delivery partner to help us with further further developing the capabilities for the Smart dispute implementation. I'm going to now introduce CJ Babin. She is my release train engineer and she's my left hand, my right hand and everything when it comes to the execution and the planning for the project. So all right, thank you. And Mary.

And first of all, I wanted to thank everyone who is involved here for giving me an opportunity to present on this event. Immensely thankful for that. Um, so let me begin by saying, if at first you don't succeed, redefine success, right? Because it really encourages a lot of persistence and resilience in the face of failure. And I say this because at the onset of our journey, after a lot of trial and error, what we realized is we needed a streamlined, flexible and adaptable approach to make this large program a success. So this small real estate I have here, I'm going to pop that question very emphatically, making sure Anne-Marie doesn't topple over. How did we do that? Right. How did we do that?

And that takes us to the approach. So as all of you know, we are trying to enhance and improve our claims resolution process in the bank and the claims resolution, the workflow associated to this has multiple resolution points. So when I say resolution point, it means it comprises of an end to end testable unit that actually provides business value. So to give you an example of some resolution points in our in a typical debit card processing workflow, right, would be the first one would be like a low dollar write off. Or the second resolution point would be like an early resolution by a third party vendor, like verify or Ethoca. A third resolution point would be a chargeback by with visa, right? So there are these key resolution points. And our approach is to iteratively develop towards these resolution points and incrementally deploy these, these these components in dark releases or dormant mode, which I will come to in a little bit later. And, you know, keep these components, get them ready as and when they are, you know, ready to be deployed.

We finally release the functionality to the business when we feel sufficient business value has been met. So how do we do that? We prioritize the minimum viable product first, and then we go and focus at, you know, addressing the large and subsequent, you know, complex features subsequently. So that is the, uh, you know, in a nutshell about how we approach the solution. And just to tie that to the methodology that we used. So our process is deeply rooted in agile methodologies, as you must have already inferred to when I use terms like prioritization and features and things like that. Right. And specifically save 6.0 because it combines scrum practices with agile principles, and it allows us to scale effectively at the same time, you know, always focusing on a continuous value flow. So just to give you an idea of how our teams are structured.

So our teams are, you know, we have a lot of scrum teams all rolling up to an agile release train or we call that an art. And there are different types of teams. So there are teams that focuses on business functions, business aligned functions, that is, you know, developing the components using the Pega smart dispute software. And then we have technology and subsystem aligned teams. So these teams focus on, you know, developing the necessary integrations or the downstream data needed for reporting and analytics or the the test automation or setting up the infrastructure. So those are purely subsystem aligned teams, right. So while each of these scrum teams follow a regular scrum cadences, we also have ceremonies at the art level. So that way everybody is working towards that common understanding of the uh, the program vision. Right.

So just to give you an example, I'm sure most of you who have operated in agile have are familiar with these ceremonies. We have the product owner sync, right, which happens on a weekly basis. What do we have there? We have the product owners and we ensure that the product owners are aligning the features right and prioritizing it based on these resolution points that we have identified so that it is, you know, fed into the team accordingly prioritized. Or we have the scrum of scrum, which also happens on a weekly basis, where we have the Scrum Masters who are responsible for ensuring that we execute towards this iterative development, that plan that we have, you know, laid out. They they try to find out the dependencies between the cross teams. They work towards resolving the impediments so that, you know, there's a continuous flow of work. And apart from these weekly ceremonies, of course, we have the quarterly planning sessions, which is called programing sessions, which is often referred to as pie planning, where we bring the entire like the teams, the stakeholders, everybody to ensure that they are all aligned to what is the focus for that quarter. Another example of a quarterly session is an inspect and adapt where we pause.

We look back at the pie that just completed and ensure that and look at what is the business value that we have met so far. So that that will help us to, you know, calculate the team predictability. So apart from these safe mandated ceremonies, we also have some technology specific ceremonies. So those are like the architecture sync. So we where we have our core technology team members come together and develop the solution that feeds to the framework. Right. Or we have a QA sync where our cross, all the cross functional testers come together and ensure that they are tracking the testing activities. So these are, you know, on a very high level are the processes that we follow. And just to highlight the the benefit of this methodology.

Right. So the iterative approach that we are we have adopted allows the business to have an early engagement and understand the start understanding the application much earlier, right. Rather than them coming at the very end when we are saying, okay, we are ready to go live. Let's get the business engaged. Let's, let's and they are seeing the system for the first time. That does not happen here because we are doing an iterative approach and our incremental deployments that I was referring to earlier as dark deployments. That is where we ensure that we have our UAT or the user acceptance testing, uh, team engaged so that they are continuously, you know, doing that user acceptance testing to the points where we are completed. We have completed the components needed. They do the user acceptance testing to up till that point.

They prepared the job aids and business procedures up to that point. So it's not all, you know, all you know, at the very end when we are going to go, for example, we are going to do our first release. We the everybody is already familiar with the system. They have already got their hands wet. You know, playing around the system is nothing new. So all we have to do is ensure that there's an end to end test that everybody feels comfortable sign off. So this iterative approach is very powerful in that way. And it actually gives us it also gives it also puts them into a continuous feedback loop. And they are they can make adjustments through data driven decisions.

Right. And the the lastly it also enables a lot of believe me, there's a lot of collaboration between the teams. And you know, it fosters a lot of alignment and collaboration between the teams because there are these different meetings, which I mentioned, the sync meetings, that brings the team together. And so everybody is working towards a common understanding of the vision that we are moving forward with. Right. So, um, just to move focus to the implementation strategy, this is what Anne-Marie was alluding to earlier, um, where we have a legacy system in place. Right. So we adopted something called a straddle approach. So that aligns very well with our iterative, iterative and incremental approach that we have used.

So what we do here is that if you look at the process here, the various claims that comes in are intake through various channels. It can be through external channels like the call centers. Uh, I'm sorry, from web and mobile or from the internal users, like the call centers and branches. So all of these claims from various channels are input into an API orchestration layer through an API gateway. So it is this orchestration layer which has the inbuilt logic to straddle the claims that are ready for the new system to over to the smart dispute platform, while those that are not yet ready are straddled towards the legacy platform. Right. And we have made a decision that we are not going to do any migration of the claims right from one system to the other. Instead, we will allow the straddle approach to continuously run until the pipeline runs dry. Right.

So that's the, uh, you know, implementation strategy that we adopted, um, very high level. So the orchestration layer has those critical business services and Luis and microservices built in for doing this particular logic. And lastly, I want to touch base on few of the lessons learned, because I'm sure that will be very helpful for people who are on a similar journey like us. Right? So Pega is a continuously transforming product, right? And it is very important that we adapt strategically according strategically, strategically. Right. So for example, uh, something that happened to us was that we delayed the version updates on our legacy platform, which is also based off on Pega. And because of that delay, it became a huge version upgrade.

Uh, you know, when we finally got doing the upgrade. And that put that put a lot of pressure on us, right? So, uh, again, just a word of advice. Ensure that you always keep your versions up to date. The second thing is establish a robust product management. I cannot emphasize this more. Right. Because continuous business transformation means continuous attention. And strong product management is the cornerstone for that.

Right. And we need to collaborate with our business and define clear requirements. We have to work with them to deliver incrementally with that feature toggles, we prioritize the features with a higher business value. So those are very, very important when we work in an agile methodology. And a good robust product roadmap is really needed from our product management. Lastly, um, some some points around budgeting and planning. So we need to budget adequately for implementation costs or plan adequately for uh, the initial setup capabilities. That was a big, uh, a little bit of a, you know, underestimation that we did because the initial set of capabilities would. We realize that it takes at least 6 to 8 weeks to ensure that we have completed all those set of activities?

So we need to plan that ahead. So those are some of the key lessons learned that I can think of. Uh, Anne-Marie, you want to add something additional? Yeah, maybe. Maybe not. Such a big lesson learned. But I think one thing as you were talking that came to mind is that when we started this project, we decided that we were going to embrace automated testing. And so we are automating all our test cases embedded in the scrum teams. We have functional testers that and then we've got a subsystem testing where they pass those test cases to that team that then automate the test cases.

And the benefit comes when you do UAT testing. You can run your automated tests, you can give the business those results, they can review that. And then instead of trying to write test cases, etc., they can focus on exploratory testing. And in using the system the way they are going to intend to use it. And then if they then break the system, that's really what we are after. So I think that was one of the things that initially we didn't give too much attention to it and then quickly realized that that's maybe a little bit of a mistake. So we are now full fledged automating doing automation. I think that brings us to the end of our presentation. And, um, we are ready for Q&A.

What I do want to do, though, however, is I do want to introduce two of the resources that work very closely with me and saying, Um, is our principal architect and Chandan is our business architect. And they are here to help me answer all the very difficult questions. All right. Can we get a big round of applause for Ann-Marie and seja on that great presentation? Now we've got our helpers. Come on up here. Helpers are going to help answer questions because we're going to we want to make sure that we can handle everything you want. So we have microphones in both aisles because we're taping this. We're not shouting out questions from the audience.

You got to come up if you want to ask a question. So just come down to one of the aisles and I'll recognize you. But I want to start off, I had one ready to go. I get this one all the time. Do you start with debit or credit for universal banks? Because and you made the comment 70% of your volume was coming through on debit. Was there more to that decision in terms of kind of where you thought your starting point was, or was it really just a volume question? So it's always interesting to hear one bank's version of why did you go down a particular path in terms of your starting point? What do you think?

Um, yeah, I think that in a large corporation like Truist, you will find that there's of course, multiple lines of business. And in each line of business, they have their unique priorities. So, um, fraud spans all these businesses, and you have to get buy in from all the businesses before you can actually approach a single product line. For us at Truist, we made a decision to change our credit card processor, and we are converting to thesis. And that would not have been the ideal time to during a conversion. Also try to, um, tackle credit card transaction disputes. So we focused on debit card first, which really a lot of the foundation that we need, we we believe that we probably have a 30%, um, flat out reuse. And then incrementally that um, reduces over time, but definitely a great fit for both products. Oh, come on, don't be shy.

You know, you want to ask a question. All right, I'll throw one more. Um, do you have an existing. You talked about the straddle approach. Yeah, an existing application. So let's talk about kind of like the whole how you make decisions around, you know, decommissioning and what goes in and versus not. Yeah. There's nothing that can eat into time to market like data conversions going from one system to the other and trying to, to to fit that data just right so that you can continue to work those cases. And because, we have had some previous experiences.

Um, we decided that we were going to run the pipeline route dry. Um, and as a result, we we designed the straddle approach in our orchestration layer. One thing that I feel like we didn't adequately address in our orchestration layer was that it actually is the layer that all the channels will call when they are performing a claim or a transaction dispute. And what we want, the flexibility we wanted was to be able to determine what claim type can be submitted from which channel. And we can control all of that in our orchestration layer. The other thing here, we now also in the orchestration layer Provide. Provide to the channels the questions that they have to present to the clients and the the hard coding of the questions in the channels are now being removed. So when we get the visa upgrades every six months or so, we will update the orchestration layer and it will be a separation of concern to the channels right here. Go ahead.

Did you do any uh. Yeah, just. Much better. Did you, uh, have to. So did you completely change over dispute types, or did you have, uh, intake for one certain dispute type working in the channel concurrently? Like, did you have to redo your intake questions is what I really want to drive to. Yeah, we we are actually just doing our intake questions dynamically, because when somebody serves a late, late steak, um, well, let's take a mobile application, for example. Um, the client will pull up their, their account, you know, their profile, get their accounts, and they will select the account that they want to dispute based on the account type. In the transaction type.

There we can determine what are the right questions that needs to be presented for that combination. So then you would only have dispute type A would be for new dispute Platform but maybe dispute type B would be for your legacy going at any given time. Yeah. Couldn't have them running concurrently. Did you have any time or did any any problems if you ran into changing a dispute type when you were processing a claim during that transition period? So we are actually in the process of testing Self-testing that and it is an incredibly complex situation. And so let me let me answer your question twofold. The first one is that our intake processes are, um, not focusing necessarily on the claim type, but rather just on what is the transaction being disputed. And the orchestration layer will then determine what is the what what claim type does that transaction translate to and will pass that along to either our legacy system or our new system.

Now, the challenge does come in. That smart dispute is totally driven by the new questions. And we do need to do a mapping in the orchestration layer, um, of the new questions or the current questions to the questions that are hard coded in the legacy system, and that is one of the challenges that we are working through. Because if your questions change now, you need to do version control on those questions, right? You literally have like a 15 second question, and then she can give you a one minute answer. And then we're going to have to wrap up. My 15 second question. Then for one minute answer. Did you have to do any orchestration with Multiprocessors when you were bringing in that new processor?

I'm going to pass that to Shayan. Yeah, I mean, right now we are dealing with a like a single processor, which is visa, but we have plans to incorporate the multiprocessor as we speak. We are also exploring with operations the process where there are some of the maestro application that goes through visa. Right. So we are trying to figure out the business rules and the and the logic behind it to how to Fabricate those processes and segregate those processes and the orchestration layer to ensure that it follows the correct path in terms of workflow. Workflow and then financial movement would be different per process. You're doing that in the orchestration layer. Yeah. Thank you.

The financial movement will happen on the on the smart display platform. The orchestration layer will guide the attributes towards specific workflows, which will then take care of the financial movement from within the back end application. Okay. Thank you. All right. Can we give them one more round of applause. And by the way, if you didn't if you were scared and didn't come up and ask your question, come to a lunch meet up tomorrow and we'll all be here. And we can have question and answer at that time, too. So thank you again very much.

Enjoy the rest of your show and hopefully I'll see most of you tomorrow. That's it.