PegaWorld iNspire 2024: How Navy Federal Credit Union Leverages Pega to Empower Military Members and Fulfill the Servicemembers Civil Relief Act

(upbeat music) - Welcome to the Illuminating Session, Pioneering Excellence: Navy Federal Credit Unions, Pega Power Journey to empower military members and uphold the service members Civil Relief Act, which is the acronym is SCRA. So, I'm Suzanne Clayton, I'm the Global Senior Director for the EY relationship at Pega, and it's truly an honor to introduce our distinguished speakers today. Firstly, we have Roya Johnson leading the charge in product engineering and delivery services at NFCU. Roya brings a wealth of experience and dedication to her role in serving over 13.6 million military members and their families. Joining Roya is Deepak Tiwari, an esteemed executive director at EY and Technology Consulting, where he spearheads our financial services Pega practice with unparalleled expertise and vision. Navy Federal stands as a beacon of support for our armed forces, and today we're privileged to learn how NFCU in collaboration with EY embarked on a transformative journey, leveraging Pega technology to craft an automated solution, ensuring compliance with SCRA. Thank you. (audience clapping) - Thanks, Suzanne. Yeah, go ahead, Roya.

- Thank you so much, Suzanne. Good morning everyone, it is absolutely great to be here. What a pleasure and privilege to share with you the experience that we had to develop one of our very complex product with with so many other fantastic development that happened by Pega with such a great, you know, group of professionals here. My name is Roya Johnson. Let me actually share you a secret about myself, and the principle that I apply not only to my personal life, but also to my profession. It is actually the principle, the first principle of thinking in engineering, how to approach a complex- Solving big, complex problems. The way that you approach that as far as the solution is to basically look at the problem and really breaking in down to the very simple unit, and then building it from bottom to top. It works when I was working in physics area, and when I was working as an electrical engineer, and then network engineering, and really became part of my professional personality. But this principle is not really limit to engineering.

It is actually apply to many, you know, area of industry, including the financial services. When it comes to the product delivery and services, it is very important to ask simple but critical questions. What is it that the product is doing now? What is it that we want the product to do? Is what we want the product to do is what our customer want? These are very simple question, but when you dig deeper into these questions, you really walk into the such a uncharted territories, because there are so many solutions out there. Product and services, they are always evolving. The pace and the quality of the evolution depends heavily on the tenacity of the team asking these questions and answering them. That is why partnering and collaborating with EY make it very easy for us because of the fact that they absolutely believe in the same principle.

They worked with us over the last year and a half to really break down this complex process to raise simple unit and really help us to build it from bottom up. - Yeah, thanks, Roya, thank you very much. And thank you very much everyone here as well for prioritizing this session. I know there are plenty of sessions out there. Couldn't agree more, Roya, very well said. You know, I've done lots of Pega implementations in the last 10 years or so, and this one is definitely at the top of the projects I've done. And really a large part is the impact. You will hear a lot about the story today, and there is such a direct impact on the service members. So it's really very satisfying to see when you have done an implementation, it has gone live in production and the users are really getting the benefits out of it.

And we're talking about service members, as you all know, they put a lot of personal sacrifices out there to make things work for the nation. So truly a special project and the philosophy we talked about, it was really great to apply that in this. All right, so with that, let's actually talk a little bit more about Navy Federal. - Absolutely, absolutely, yeah. Allow me to tell you a little bit about Navy Federal Credit Union. As a member owned and a not for a profit credit union, Navy Federal's mission is always to put a member first. As a matter of fact, we have a slogan that the heart of what we do is really our member. If you look at the, you know, our organization in different areas, from technology to our customer care, to business, to finance, we all share the same purpose, which is basically our members' financial goal is our top priority. Navy Federal is the largest credit union, and is really a leader in this technology.

We're are basically leading so many, so many innovations and in that area. As a matter of fact, our team in Navy Federal won the innovation prize in this, you know, conference. Very, very proud of them. So we have 30, no, we have 13.6 million members and they're all from Department of Defense, Navy, Army, and, you know, the Coast Guard, active duty contractors, their family members and also personnel. And they, actually as a wife of a former Navy, I'm very proud to say that the, you know, Navy Federal Credit Union is a military focus. They actually have a dedicated, you know, VA mortgage loan and servicing. They also have the early pay for the, you know, for the active duty members. We also have the free, basically active duty checking services and discount and also 25 by 7 support for our members. - Yep.

- So let us talk about SCRA. What is SCRA? SCRA actually is a Service Member Civil Relief Act that was passed in, actually completed in 2003. But this is not a new act by our congress. Actually, this was in, I think it's 1940. - 40, yeah. - It was considered as the Soldier and Sailors Relief Act. But over the time, the act actually, you know, evolve by not only, because of the rates that, you know, become available and also because of the military changes happen. So by 2003 it became as a service member, you know, civil relief act.

So the SCRA actually is, if I switch with you a little bit, sometimes that, you know, the light is... - Yeah, that's okay. - You know, is on my eyes. So the SCRA actually applies for, you know, active duty members who are serving at other countries. Also the member of the coastal guards, National Guards, when they are serving for more than, you know, consecutive 30 days. For those that the member of the, you know, reserve component of the military, and also any active duty commissions on the public health area, and also the oceanic and atmospheric area. So there are five areas that SCRA provide protection. The number one protection that we have, we basically reduce the interest rate for any pre-service, you know, member to the maximum of 6%. However, Navy Federal offer 4% of the interest rate.

- That's hell of an interest rate. - Yes, absolutely. - In this high interest rate environment, like 4% is like a real deal. - Absolutely, absolutely. The second protection is that from any default of the, you know, judgment on the civil cases, the third one is basically against any type of foreclosure that other member may face during that time. The next one is any type of repositions of their property during the time that they're serving, and then also any type of termination of their residential housing or automobile and their cars leases without, you know, without any penalty. - Yep, yep. Awesome. - So how did we leverage Pega for the Service Members Civil Relief Act?

One of the things that we did, you know, we're collaborating with the EY is really, you know, as I mentioned in the beginning, we really look at what our customers or the business customers are looking for. They were really, you know, we wanted to really address a key problems with these solutions. One of them was really support by helping to ensure that it really compliance with the SCRA act. The next one is to make sure that extension, which is part of the process of SCRA, it really works. And the way that extension, what extension means that, our, you know, military members, they go back and forth, so it's very important to make sure that we cover them when they go back to their activities here and then when they come back. So that was very important for us. Also, very more important to really reduce the challenges that we have on the SLA, on, you know, on the compliancy, and also the quality of the process. And really simplify the process as well for our business partner. And the last one is really improving the other specialist and a member experience.

So... - Yeah, yeah. So I wanna highlight a few Pega capabilities, very fundamental out-of-the-box capabilities, because that was one of our principle that as we do this implementation, we've gotta stick to out-of-the-box. If you have to do this in time, then we have to stick to out-of-the-box and SCRA, all the problems that you see there, pretty much most of the out-of-the-box functionalities of Pega solves that. So at the very core of it is building a centralized system through the case management capabilities of Pega. You all saw the blueprint. So visualize the blueprint with all of the steps, starting of the case with the intake, determining the eligibility of the customer, then doing any kind of refund calculation, if at all applicable for them. There are a bunch of audit processes, QA processes. We have so many stakeholders in the process, right?

Member service representatives are there, you have QA people, audit people, SCRA specialists, it's like an army of people. So we really build all of that as the core workflow. And that basically made sure that all of the previous processes, which were manual, they were probably in Excel sheets, SharePoint, communication was probably happening via Outlook, all of that basically got into this one single unified workflow in the new Pega application. And that alone was basically a very, you know, significant uplift. The business rules in general, so I will highlight, you know, those who know Pega would know that Pega has a pretty strong business rules engine. SCRA Act comes with a lot of rules, and we saw significant opportunity to configure or codify those business rules into the application. One example I would do is refund a calculation. So, you know, let's say there is service member who doesn't realize that they are even eligible for SCRA, and they are paying at a 21% interest rate on the credit card. And by the way, it does happen, when people don't realize and they don't apply for their SCRA benefit, and then suddenly somebody tell them one day that you should be eligible for SCRA and you should apply for it.

And then suddenly they realize that all this time they should have been paying at a 4% interest rate, not 21%. And that difference in 21% and 4% interest, that calculation SCRA specialists used to do manually. Because now Navy Federal is supposed to refund it back to the customer. So all of that business rules, all of those calculations that the SCRA specialist used to do manually to drive compliance with the SCRA Act, we codified all of that into our application, which certainly made the lives much easier. Even though there are a lot of audit and QA processes in the current manual environment, nothing beats the calculations that are being done by your system, right? And then, you know, SLAs and reporting are very fundamental out-of-the-box features, providing very good visibility to executives of what's even happening with a certain case. - Yes, absolutely. - Okay, so, we'll talk about a few critical success factors. Some of these may actually sound very obvious, but I think the key is in execution.

And thanks to Roya and, you know, our team here as well collective EY and Navy Federal team, you really executed some of these points quite well, in my opinion. The very first is MVP approach. We have actually done another SCRA implementation at another bank, so we know that this could be complicated and this could take time. So pretty much from day one, we had this alignment that we would take an MVP approach, you know, six months if I look at the absolute core timeline, there was a target that credit cards, you know, would be the MVP, and then we would go live with that. And that basically allowed us to break down the huge scope of SCRA to something very specific. And even within MVP, I would say within those six months, it wasn't a target six months away, we broke down these six months by monthly dark releases, as we like to call it, which is basically you take the code all the way into production, you don't actually roll it out to the end users, but you at least drop the code in production. So the technical dependencies at least gets validated. There is so much that, you know, that validation is required from a tech perspective, at least that gets done. And then ultimately you do the MVP.

- Absolutely, I think, you know, this slide, the title of it is the Critical Success Factors. You're absolutely right, there are, you know, many people, they're familiar with these, you know, points that we have here. But really one of the major critical success factors for us, it was our team. I do have actually in the audience, I do have Abulash Vishwakumar, my lead developer and also Sundar Sekar here. And also we have our automation center of excellence, who are absolutely great partner in Navy Federal to really make this happen. In addition to that, we have Namish, our our lead developer here and Tulshi as well too. So when it comes to really a success factors, you know, for any project, the team that they work together, and that collaboration is really the essence of the success for us. - Yeah, people are the most critical success factor. - Yeah, absolutely.

I mean, so when it comes to agile approach, they, you know, in practice agile means collaboration, people who collaborate. So really we approach that as Deepak mentioned, we were able to really go with the dark releases, and make sure that each of these building blocks that we were building for this process would be deployed in production without really having users there. So that would allow us to really control the development and also, you know, be able to go to the next phase. - Yeah, and I would highlight that T-minus that you see on the slide there, you know, most places do sprints so I'm pretty sure everybody's aware of the sprint planning that happens on day one of the sprint, the concept of T-minus was to do a advanced sprint planning four weeks prior to the start of the sprint. So that's T-minus four, some places even do T-minus six. And, you know, our suggestion and thought there is to have that T-minus approach so that everything, whether we talk user stories, whether we talk about making sure APIs and dependencies are ready, whether we are talking about test data, pretty much anything we can think about, that is already in place. So that way when the developers and basically our sprint team, when they actually get to the sprint, they're just choosing the maximum possible velocity. There are no obstructions in place. And I do think that, you know, that was a big reason why we were able to go live, you know, much quicker.

- Absolutely, absolutely. So, I mean, when we talk, the next one is the infrastructure planning. One of the things that we did, we really had the, you know, version control, very robust version control. As I said, you know, we partner with our, you know, automation center of excellence to really allow us to work very well with them, with the versions that we have in order for us to really have all the lower environments that we wanted to have from a, you know, from a development to integration, to the UAT, and really go through this without really impacting any of these environments, you know, on each other, and be able to really test each of them with the different, you know, criteria that we had. - Yeah, I remember in the early days of the project, we had one or two instances where just the fundamental setting up of the certificates was taking time. - Yes, yes. - And I'm glad that we attempted that very early in the project, so that the underlying infrastructure got established and then we did not have to deal with that, obviously over the whole duration of the project. It's kind of taking care of the non-function aspects of the project while also focusing on the function side. - Absolutely, absolutely.

- The solution architecture, I guess everybody would realize the importance of that. The way we executed is what I'll focus on. We had a very robust sprint zero. This was the first four weeks of the project, and basically the idea there was to have a vision for the ultimate architecture right from get go. Obviously there are nuances that need to be figured out apart from Pega, we had broader technical stack involved. So all of that had to be thought about. But the key, and I think one good thing we did in the early part of the project, to have that pretty much figured out, 80 to 90% in sprint zero itself. And after that, now you're just focusing on the building blocks and making them as better as you can. I would also touch upon the process first very quickly as well.

This is really the focus on the business process side of thing. And as we briefly touched upon the existing environment, the way the SCRA processes was happening, it was a very manual and cumbersome process. And when we do implementations like this, the intent is not to just lift and shift into the new environment, right? The intent is to optimize wherever possible. Automation definitely is a big uplift, but there is a process optimization angle as well. So I believe our process team ran almost three to four months. - Yes it did. - Ahead of the actual sprints. - It did, yes.

As, you know, you mentioned about optimization, and I think that goes back to the next one, which is operational efficiency, as Deepak mentioned, and our first MVP was really to automate credit card. After that, by getting direct feedback from our business partners to make sure that the automation works for them, we actually worked very closely with them to really enhance that process as well to make sure that when we are introducing the next product, we have a very solid, mature product that they can actually, you know, introduce the automation of the rest of the products. - Yeah, yeah. And I think it, you know, I like to say that go live is day one of the project. - Yes, yes. - You know, no matter how well we plan things, especially for a use case as complex as this, these things will come up. And having a plan for having a proper operational efficiency phase was I think a great thing. And since we go live last few months, business has been really actively providing the feedback. - Absolutely.

- And that is taking the application to the next level. - Yes. - It's actually setting the foundation for several more years to come right and the other products that we'll do. - Yep. - By the way, I think we'll wrap up in like five, seven minutes, and after that there'll be a Q and A. So we'll pause for everyone. So this is a little bit about the partnership, you know, what EY likes to bring to the table for every project. I do wanna say that this is not just about EY, this is also about how various aspects of the program we collectively managed together, starting with the Pega talent itself. Yeah, certainly we have pretty great Pega talent, a lot of the folks here, and we got them to the table.

We had done an NSCR implementation previously, so one of our biggest focus was to bring folks who have done actually SCRA work, or at least the access to them, to this project. And at the same time, it was very important to work with Navy Federal Pega talent as well. So I'm really glad to say that, you know, it was really a one team. It just, you know, there was never a day where, you know, one would've said that, you know, it's a different team, right? So it was really well done there. Change adoption. We were providing inputs into change adoption, you know, we kind of knew from day one that this is gonna be a six to seven months of effort, and when you build so much of a code and then you put it in production, there is going to be a steep learning curve for the business team. So we kind of touched about operational efficiency earlier that complemented the ongoing change adoption. And maybe something that I wanna share on that, how business adopted to the changes.

- Absolutely, so I think for any other, any project when you basically move from, you know, Excel sheets and non-automated process to something that you don't have control over it anymore, and you really have to trust the system, especially for something as important as SCRA from the compliancy perspective, you know, other business actually they've done a great job as far as really bringing the full forces behind this. And, you know, from a training, from understanding what needs to be done. As a matter of fact, one of our great success is the fact that business, you know, emphasizes on the fact that they didn't want to go between two systems. They wanted to go from completely a manual process to automation. And, you know, that really takes a lot of guts for business to do such a thing. And I'm very proud that we partnered with them for such a, you know, important, you know, product. So we had to basically move everything from the, you know, old process to the new automated process. So the adoption of, you know, of the new process, you know, business really went behind that. - Yeah.

And I must say that, you know, I do get visibility across a lot of projects across banking industry, and the data migration work that was done, really heads off to that. - Let's not talk about that. It was the most painful part of it, but it was with a great success. - I think at one point of time even we suggested that, hey, how about we just start the new population on the new system, right? - Yes. - And let it be on the road. But the business was very particular about moving over the old data to the new one, and after a lot of back and forth ultimately, and this was the part where EY was not that much involved. - Correct. - So really that's up to the Navy Federal team to pull that part.

And it's very, very important. - And I joke about let's not talk about it, to be honest, this is one of the things I'm very proud of, the Navy Federal team, because the team really went after the data, understanding what it was in the old system. They mapped it as far as where it needs to land on the new system, and the way that they approach that, it was very- And Sundar here is really behind, Sundar and Abulash, they were really behind thinking of how to really map, you know, these cases that they have different places in the old system to the new system with the new queues and new places. And it was really successful, it really took us a while, but we approached it as a phase by phase, and we successfully migrate everything to the new system. - Absolutely. - We did not leave any case behind. - Yeah, no, it was really awesome. Industry standards, two types really. Number one was how SCRA has been done on Pega.

We had other clients, we did have some experience, so thankfully we were able to share that. It's a continuously moving act. So, you know, if you did the implementation two years back, some of the pieces were outdated. So it was a learning curve for us as well. But certainly bringing in that perspective that how SERA others have implemented, that was certainly very helpful. And from a Pega perspective, I think there was probably an ongoing education to business almost all the time that what are the right standards? Certainly business was used to doing things in a certain way, but Pega has its own style. So sometimes we had to actually communicate the same thing multiple times. But, you know, that was really something which we brought to the table.

And I think very, very important for any project. Sometimes the pushback is so hard that tech teams just kind of give up and they do whatever is told, but- - Not in case, not in this case. - Not in this case at all, you know? There was a bold and brave face put together. - Yes. - And through collaboration, I think we, you know, got it across the line, which I really feel we might not realize the value of that now, but three, four years down the line, when the application would've sustained without too many upgrades and customization and modifications, the value would be clearly seen. Architecture, we talked about that a little bit, you know, really making sure that we have a solid Pega architecture as well as the product architecture. You know, sometimes in Pega projects we just tend to focus on the Pega piece of it, but we were very particular collectively that we gotta look at the broader stack as well, specifically around APIs. I think in the early days of the project, the APIs were not available.

We needed some new data elements, but that is another area I would highlight where I think Navy Federal team really caught up so fast, so quick, and it was just never an issue after a few sprints. - Absolutely. Yes. - Add anything more than that? - Yeah, no, I think, I think you nailed it. You know, when it comes to API development and, you know, just going through Agile and really redefining the requirement, you know, we had, you know, again, we had a great partnership with our API team, and we were able to really accommodate some of the need that we had in order for the project to move forward. - Yeah. And one part of adherence we had to ensure was adherence with Navy Federal Pega COE. So there are guidelines out there which we had to follow.

And that was again, a very important part of this, because we wanted to make sure that whatever COE already has, we build on top of that, instead of, you know, reinventing the wheel. Tech governance, every single week, I believe on Wednesday, 10 o'clock, that's a call I just never missed. Because, you know, issues come up, and at a leadership level, we and few others, Sanjeev and a few others, we would basically come together and, you know, solve for the problems, and then the direction would basically go to the team. And that I think was, you know, quite helpful in mobilizing the project. - Absolutely. - And really tackling issues head on right. - Absolutely. And if I miss it, I would get a call from Tulshi or from Deepak. That's why I'm not there, but no, absolutely, those weekly call help a lot to be aligned as far as what we want to do, what is our next course of actions, how do we overcome some of the obstacles that we have on the project.

So really helped us a lot. I truly appreciate those calls. - And last but not the least, the budget is always gonna fluctuate. Something that else will happen, and I think it's very important to sustain those low budget times and have the right momentum in place so that, you know, when you do get the budget, you pick it up from there. And you know, I think we collectively managed that really well as well. - Yes, yes. - Okay. So we don't really have a slide on benefits as such, but I think Roya, if you wanna talk a little bit about, you know, what are ultimately the benefits back to this service members and to Navy Federal out of this project? - Of course, I mean, some of the member- Some of the benefits I think as you mentioned, is really the refund calculation.

One of the things that this product is gonna bring to our, you know, our member is the reduction of any type of the human error on those calculations. Make sure that they consider all the products and that members are eligible for SCRA. Their eligibility is also another one that it really brings a lot of, you know, streamline all of these together. So at the end of the day, as I mentioned, really our members financial goal is our priority. So this project is gonna bring that, this project is gonna bring that, you know, value for those who, you know, serve. I mean, yeah, Navy for all, you know, absolutely honor to serve those who serve. So this product is very important in that aspect. - Well, they're getting accurate refunds for sure now. - Yes, yes, absolutely.

- All right. - So I think we have some time for Q and A? - Yeah, that's the presentation for Q and A. I think there are two mics there, so please get to those and ask over your questions, - Any questions, comments? - [Participant] I have one question to ask. - Yeah. - [Participant] How did the Navy Credit Union measure the ROI and the inflation rate? - So I'll just repeat the question for everyone. How did Navy Federal measure the ROI out of this project, right?

- As far as the measuring, measuring that it's based on, you know, how much we save for other members, how much we streamline the number of, you know, you know, specialists that they are working, the resources that we have on the product itself. And to be honest, is the efficiency and the effectiveness of the automation itself, how much it really brings the, you know, reduction of the days that may impact, you know, the process itself. - Yeah, and the dollars calculation is always subjective for something like this, right? It would need to be a very thorough, hourly based study. But, you know, one example I can think of is that these refund calculations for example, right? When those were being done, there is an audit process after that and there is a QA process after that. And we know from this implementation that earlier when the refund calculation was being done, the audit and QA team really had to seriously review it. And when we were starting the project, somebody told us that this is the area where there are the maximum errors, right? And now that this implementation has gone live, we did build those audit and QA steps in the new platform, but those are really double checking and triple checking, right?

The fundamental time that the analysts were probably spending. - Yes, exactly. - Know, it's obviously much lesser, and it's just a matter of time that it's almost gonna become like perfect, right? We're still in the early days, so we have to keep those audit and QA steps, but I'm pretty sure at some you might even think of removing those, right? If the calculations just continue to stay almost a hundred percent accurate. - Correct. - Okay. - [Participant] Hey there, really great presentation. One question that I had is, so clearly great moves on the back office for efficiency, time, accuracy, all of those great things.

So thinking about like the roadmap, is it time to where you have a client facing application, you can actually present that new rate in a client facing application? Or is that something that kind of like what Alan was talking about today, we have the core decision making process in the middle between the back end and the front end, and how can we utilize Pega to make those decisions? - Do you wanna take that? - Yeah. So just to make sure I get the question that how can you actually extend some of the benefits of this to the actual client itself and make it more client facing apart from the back office optimization? - [Participant] Well, right now it seems like it's all back office. - It is all back office right now. - [Participant] Is there a roadmap for it to be client facing? - Yes, absolutely.

We basically, a part of our roadmap is to bring the member portal, so we have our members directly interact with the, you know, with the business and yes, and as a matter of fact, some of the... I don't know if Abulash or Sundar if you wanna add anything as far as some of the roadmap when it comes to the client base? (Participant speaking faintly) - [Participant] Yeah, awesome. There's a lot of stuff that I think we're all trying to do to try to streamline those client interactions that are there, so I just wasn't sure how you guys were tackling that, thank you. - Absolutely. - No, absolutely. And just to summarize, you know, what Abulash basically said for everyone, you know, there is another front-end system that is basically used by Navy Federal. So ultimately in an ideal state, the customer should be able to ask for SCRA benefits through their online banking pretty much, right? - Right.

- And then from online banking through the CRM system, the whole back office piece we are talking about, which has so many manual steps, some it can be absolutely straight through processing. So I'm sharing this a little bit from one of our other implementations, but that absolutely is a vision I think, you know, you all can execute easily. - Exactly. - Yeah. - One more question. So the act changes every two years, right? So how configurable the application is, and then how extensible the application is? - Great question, it's absolutely configurable. You know, one thing, I've been doing Pega for a long time, and one thing I absolutely believe in about Pega is the build for change.

As long as we follow out-of-the-box, changing Pega is not difficult at all. So you're absolutely right, the act does change a lot. Now, since 2003, there hasn't been that substantial changes in the act, but I would say that if there's a change tomorrow, you know, the application is ready for it, most of the things are out-of-the-box. The operational efficiency phase that we talked about, that operational efficiency phase has been one of those few months where business would ask us to make a change and we'll pretty much turn around in a week or two, you know? So that absolutely is at the core of how the application has been designed. Yeah, I think you had a question and then we'll come back to you as well, yeah. - [Participant] Do you use any personalization utilizing Pega and what type of Pega are you using your- - So this is a very interesting question, just for everyone, the question is that do you use any personalization in Pega? Right? Interesting enough, Chris at the back, he leads the Pega systems portfolio at Navy Federal.

There is actually a session, Chris, right? On personalization at Navy Federal. It is a different initiative. So far it has not been in the context of SCRA, but I believe tomorrow around three o'clock, if you see there is another Navy Federal session, which is absolutely on personalization. And it's about CDH, it's a CDH implementation, how to give more relevant and more direct responses to the customers. SCRA is not part of it, but I'm sure, you know, some data can be tacked to it. Yeah. - Great presentation. - Thank you.

- [Participant] The question I have is, so we saw on the slide that the rate changes, you know? And someday if Navy Federal decides to go, say from 4% to 3.5 or 4.5, depending upon what it is, are we giving the ability to business partners to make that change? Or they'll have to come to the IT folks to get that change implemented? - That's the question for the guys here. - Wow, so they can, yes. - Okay. - [Participant] Our business partner can absolutely change those interest rate. - Thank you. - Yeah, the business rules delegation is an absolute awesome functionality of Pega.

So this was again, very well done. They have the power, they can change it, yeah. And there are a lot more rules, right? This is just one, there are a lot more rules that can be extended to them. - [Participant] Hey, you mentioned how critical it was to get feedback from the users after go live. Can you talk a little bit about how you gathered that feedback and assessed it? - How did we gather the feedback from the business users post go live? - By listening to them. Seriously, I think it's very important when business users, any type of a product, the tool to really become objective to audit, and really try to understand what they're trying to do with that.

I think, again, going back to having that type of collaboration with our business partner really allow us to do that. And, you know, also I can share with you that through a UAT testing and also the, you know, the SQA testing, we actually brought our business partners to those with us, and our development team worked very closely with them to really, you know, finish those UAT testing. So it is a matter of really listening to your business. As I said, you know, in the beginning it's very important that what we want to do with the product is really what the customer wanted, you know, internet to do. So that really helped us tremendously to, we had several long sessions, I mean, day sessions after we deployed that, and really try to understand what they want to do, what are they pain point for them, and try to break them down to understand what needs to be done in order to make it more efficient. - Yeah, and I think the set for the operational- The stage for the operational efficiency was set many months prior, right? - Exactly. - When we were actually, I remember when we did the kickoff presentation, we had the business sponsor in the room. It was our day one of the project.

And right from that meeting we had the inputs. So Tulshi knows how, you know, we have gone through so much of conversation, so that's why, you know, we smile about it. But certainly that, you know, that active business participation, even though there were varying points of view, the active business participation was absolutely the reason why, you know, this has gone so well, so fast. - [Participant] Yeah, if I can add quick point to that, like business 5% was the most important one, right from the beginning of the project we had a dedicated team from the beginning. And SMEs worked very closely with us. We wouldn't normally use the system, right? So from that to today we have a like, you know, dedicated business team and we work very closely with them. That's the biggest investment I think I have done, I have seen done by the client like in a lot of successful projects. And having very strong COE from the client side was another key because they were the referees when we have to make critical decisions.

Sometimes like business and IT have their own point of view, but having a strong COE, that really helps us mitigate those things because COE has a long, from the technology point of that companies is, and when IT and business works together, they have their like, you know, what do you call it? Competing priorities. So that really helped us a lot to meeting different disciplines. - Absolutely. Any more questions? One more question, yeah? - Great presentation. - Thank you. - I'm Sudashan from Citi.

I work as a solution architect from the risk perspective. So I see like there are a lot of slides on solution architecture as well as you mentioned about the different set of versioning. So I know SCRA is an act, which is mostly on the core banking, consumer banking. So it is less like an horizontal. So it's not just like a credit card or like a lending or anything. It actually goes across banking, right? So I see that you have the EY partnership as well. So do you have, like what is your audit and governance process? So do you have any centralized auditing process across core banking?

You have a individual silos for auditing. - [Participant] What we actually do, we have- (Participant speaking faintly) - [Participant] Yeah, the thing is like, so if you have... What do you call? Silos in the auditing process. So again, maintaining those silos will, again, be difficult, right? And also like if you have too many versions because as the CRX changes. - Yeah. - [Participant] So your auditing process should also change or evolve or automate in the same manner so that we actually give much benefit to the customers. - Absolutely, I mean, you are absolutely right.

I mean, that's why Deepak mentioned that the way that we design it is very configurable. And as I said, you know, native role is really focusing to make sure that we continue, you know, our product evolve not only with the changes, you know, from a, you know, from the compliancy perspective, but also with technology as well too. So yes, it's a very important, you know, aspect of the product development. - Absolutely, the product such will configure if let's say there are new auditing requirements I'm pretty sure that those can be easily incorporated into Pega. I think the other things he talked about is that there's an internal audit team as well, right? Which is really looking from a compliance angle, whether Navy Federal is able to comply or is properly complying with the SCRA Act or not. And that's honest and ongoing exercise. I know CFPB probably is also doing audit for you guys also and for every financial institution out there, and CFP is the one to watch for almost always, right? - Mostly failed lending, yes.

- Yeah. So we work across several banking clients where, you know, the projects are happening simply because there was CFPB audit, you know? So that absolutely is an ongoing target, but this tool is now enabling and making it all easier. Right? - Absolutely. - Even CFB would be happy when they will look at that Navy Federal action now has a tool to drive better compliance. - As a matter of fact, our next phase is a CR enabler. - Yeah. - So...

- [Participant] So another question, so is it like you are using only Pega or do you have any other integrations? - I think actually our... Can we answer that or- - I think we can quickly answer that, we are way over time, but we'll answer that very quickly. Go ahead. - No, go ahead. - Okay. Yeah, there are other platforms involved. On the CRM side, there is Microsoft Dynamics that's part of the stack. And then there are a lot of other systems from where the system is basically retrieving data.

So the overall stack is bigger, but the core back office process for SCRA from start to end, it basically sit in Pega. - Thank you. - Yeah. All right, so with that, you know, the last thing I wanna quickly say is that while we talked about SCRA here, the story, the design principles, the approach would pretty much apply to anything in the regulatory compliance area. For all practical purposes, if you are thinking of doing automation for a back office process, which has a lot of workflows and business rules, a lot of these principles would straight up apply. So, you know, please keep that in mind, you know, as you take away this presentation. So with that, thank you very much. I guess the lunch is waiting for all of you. - Yeah, thank you so much.

(audience clapping) (upbeat music)