PegaWorld 2026: Modernizing VB Claims with AI-Driven Insight

Good morning everyone. Good morning. Thank you for joining us today. I'm Gautam Roy, chief technology officer for Unum. And I'm joined by my colleague Jeramiah Moody. So let me first start introducing Unum. We are 175 year old insurance company. We are a leading provider of employee benefits, serving 45 million customers in the US, UK and Poland. And the core of what we provide is to protect what matters the most, providing financial protection and peace of mind when it's needed the most, and we do so by our products such as disability, life, critical illness, hospital care and many such products. Also, services such as total leave helping the working world thrives throughout its life moment, and we have built this business over decades via trust, expertise and reliability and stability. So we are today at an inflection point. The speed of the market is changing, the customer expectations are changing, and the opportunity for technology to transform are all converging.

And that's what brings us here today. So what we are going to talk today is not just the technology story. It is how we have focused on core parts of our business and enable it to meet the need of the future, with the same trust and stability that has defined us over decades. So imagine for a moment that you've been handed the key to a beautiful historic building in the middle of the town. It's iconic. You can see it, right? And it has served the people well over decades with the trust and stability. Now, over time, the need of the customers are changing. Over time. I better stay here. Over time, the needs of the customers are changing. The expectations are different. And the thing that people rely on the building is changing right now. When you step inside, you can really see the reality.

From the outside, it still has a character. It still tells a story. But as I mentioned, when you step inside, you can still see the the reality. The wiring is outdated, the system is aging and parts of the structure is aging. Now, it is true that some of it can still be maintained. The skills and the knowledge that it requires to maintain is harder and harder to find. Now that's what a legacy modernization looks like our task is not to tear it down and rebuild. Our task is to renovate and modernize. This is not a new build. This is with transformation, with intention. Now let's go a little deeper, because the real challenge in modernization is not what you see from outside. It's what you don't see. There is no building original building plans. The architects who have designed the system are long gone. But what remains and what matters is really behind the walls at the surface level.

Some things are clear. You can still see the load bearing walls. You can see the structural beams, And you can plan around that. But that's not where the complexity lives. Is really behind the wall. Hidden pipes, older wirings, unexpected connections, things that makes the building really function. And the truth is, you don't really know what is inside until you open it up. Our task is not to tear it down and rebuild it. Our task is to my bad. This. Okay, good. The truth is, we don't fully understand what is inside until you open it up. Right. And when you do, you see the layers that has built over decades. Workaround patches. rerouted connections and the quick fixes that has defined us for decades. And then there are constraints. You simply cannot ignore. There are certain parts of the buildings that has to be true. For example, the facade, the staircase, the these are the things that brings the building, the identity, the risk of tearing something down that is actually matters important.

The value of preserving what works. And then the real cost of making the change. These are the hidden complexity of modern transformation. Now let's bring this analogy into reality. So this is not a greenfield project, right? It is far away. Far from it. The people who have designed these systems the architects, the developers, the domain experts have largely moved on. What remains is the system that has been working well over decades. But inside the system, the business logic has been embedded directly in the code. And that's the part we need to make sure we we transform with intention. And just like the hidden building analogy, the hidden pipes problem exists here too. You don't know what depends on what. You don't know where the integration live. You don't know what will happen if something breaks. And then there are constraints that you cannot simply ignore.

They are regulatory requirements. There is data retention obligation. These are the things that you you cannot simply discard and start all over again. It is the deeply embedded business capabilities that needs to be carefully transformed. So this brings us to the real questions. How do you modernize something without impacting what matters? How do you reduce risk while making sure that you are making meaningful progress? And ultimately, how do you safely move from where you are today to where you want to be? And the journey we are going to take you today is not a technology journey. It is not a big bang rewrite. It is a thoughtful, disciplined renovation. Welcome to the beginning of Unum renovation, J. Thank you Gautham. So before we start talking about the directions we went down, let's talk a second about the paths we avoided because these are just as important as the direction we actually did take.

A couple of years ago. We had some consultants come in, did an estimate of a big bang transformation for our entire claims plant Platform that estimation came in at about seven years duration and $25 million. Now, given that was a couple of years ago, AI is not was not then what it is today, but even given AI that, uh, that approach still introduces significantly delayed value and a really large disruption to our user base. So we decided to forego that approach this go around. We also looked at the data layer first approach, um, which in many scenarios and maybe some of yours, it's a really viable approach. In our case, we found quickly that the, the business logic and the data was so tightly coupled together that it didn't make sense for us. That especially paired with the delayed value. So both of these approaches, as you've heard, have significantly delayed value user disruption and more importantly, a really concentrated level of risk.

And we're relatively risk averse. So where did we land? We landed on an API enabled AI accelerated decomposition strategy that was user focused and one that delivers business value quickly. And these things are really important to us. A modern architecture with modern tools. And we wanted to prioritize the people in the equation. This was not something we're willing to compromise on. So that's where we landed. How do we get there? Well, as Gautham said, the modernization journey and our strategy doesn't revolve around technical decisions. It revolves around outcomes because we're not modernizing for the sake of replacing the mainframe. Right? We're trying to redesign and modernize for what the experience should be. And this means being very explicit about what our outcomes are and what success looks like. So we started from the back, started from the end to work forward. And for us, those those outcomes and that success, it means, um, modernizing our customer experience.

You may have heard Sheila talk about that this morning. This is extremely important to us. Again, this is people in the equation, our customers first and foremost, we want speed. We want transparency. And we want to continue to build on the confidence that our customers already have in our process. Non-Negotiable. Our employee experience. Right. We want to take them from fragmented workflows to an intuitive prescribed workflow. We want to give them, you know, less swivel chair activity. Let's, let's let them focus on one single application to do the job. And also importantly, business outcomes. We needed to reduce our cycle time, increase the accuracy and cost efficiency of how we process claims. These outcomes that we are focusing on. These are the things that define our renovation strategy, not the current system itself. So that brings us to our technical roadmap. This is probably why a lot of you are here.

Um, and I hope you take something away from this. We started with the user experience. We're going from mainframe screens, if you can imagine, in today's age, we're going from mainframe screens to user interface with Pega in the cloud. And we're initially using transactional APIs for very specific mainframe replacement. And we're not just talking about the user interface here. The user interface, while it's important, we're actually talking about the holistic user experience. We're going from fragmented workflows to, again, a prescribed workflow, one that guides a user from A to B, guides them through how to do their job in a way that makes sense, in a way that's repeatable. We're talking about error prevention, so we capture data in our mainframe. Right. But we're not really validating it. Now we've got data capture error prevention. And even more importantly guided error recovery. So when there is an error that's unexpected, we tell our users how to recover from that and we help them.

Then we start moving more business rules, logical chunks of business rules by maturing those transactional APIs into domain level orchestration APIs. That means we can abstract and move logical chunks of business code by domain and by function. And finally, we move the batch and the data. This approach again, is meant to enable us to modernize piece by piece. So let's dive into that a little bit more. We talked about doing this safely. And in order to de-risk the modernization, we need to break up that monolith. If you have a mainframe and you're familiar with it, you know, it's this one big abstract structure that sits in a basement somewhere, right? That's our vision of it. It's this big monolith. We need to break that apart because if we treat it like one solid structure, every little change that we make becomes high risk. And as I mentioned, we're very risk averse here.

So we got to stop thinking about the system as one part and start thinking of it as a collection of parts. So simply put, our approach was to break it down. We want to identify separable components, isolate dependencies, and create controlled areas where change can happen safely. We're essentially sectioning off this building and working on it in little areas at a time, while the rest of the building continues to operate normally. But before you begin to preserve anything or break anything down, you really need to understand what you have. And this is where the hidden pipes problem becomes very real in it. We're not just dealing with undocumented logic. We're dealing with business rules deeply embedded in code green screens full of business logic, which is not ideal, right? So decades of fixes as well, layered upon, layered over time. Again, our system is 40 plus years old and really unfortunately limited SM availability.

Our subject matter expert, um, essentially has a lot of domain knowledge locked away in their head, which makes it obviously really hard to, to get at. And importantly, these things that we're talking about, they're not noise. This is the value of a legacy system that we're trying to get at and preserve and understand. So discovery essentially isn't just technical analysis. It's an extraction and understanding of our institutional knowledge. And once we start to understand our system, then we can begin to decouple it because we know where those domains lie. Or we have a good idea, at least of where those domains lie. And we want to do this because again, if everything is bound tightly together, you can't change anything without risking everything. And we're not risk averse. So we break this down into, into domains. And these domains, they encompass business rules. They encompass data models and access integrations.

And we're not going to again decouple this all at once. We we identified those domains. So we're going to separate those domains one at a time. We're going to do it intentionally. We're going to do it in a way that allows us to start moving piece by piece. And now we iterate. Simple, right? But this is where this is where we're a little bit different from some of the earlier modernization efforts that you've probably heard about. And you've probably also heard that they didn't go well. Um, we're not again, you'll probably hear me say this a lot of times. We're not, we're not doing this. Throw it over the wall. Big bang transformation, all or none anything, whatever you want to call it. That's not what we're doing here. We're currently we're in production with our claims intake. We're still pre-production with our post intake claims capabilities.

And honestly, that's intentional because instead of trying to throw it all over the wall at once, we're doing it piece by piece, logical domains, one after the other, and we're taking that time in between to evaluate our process. What's working well? What's not? What other AI accelerators can we introduce? Before we get to the AI accelerators, let's take a second to talk about the first step in our roadmap. In my mind, this is one of the most important parts. I like to categorize it as digital ergonomics for our internal users. Why? Because we're taking that claims examiner experience, which is fragmented across different applications. And we're pulling it all together and streamlining it for them. In other words, we're modernizing the experience layer first, the part that users touch and feel. Ultimately, we're removing the green screen dependencies, process workarounds, consolidating those seven different applications that we talked about into one application, things like fillable word documents that users have saved on their desktops, rate calculators, and ICD lookups, all of these being ported into one application, one user interface, one user experience.

And starting with the user experience, I think it's often overlooked, but it allows us to quickly deliver value. We're improving. We're improving the usability of our application, which inherently means that we're reducing the time to process a claim just based on the fact we've improved our user interface, we're improving quality because now we've got error prevention, error recovery, and we're starting to deliver value without touching the most sensitive parts of our system. This is this is key and I can't stress it enough. So delivering value quickly without that much risk. So we've talked a little bit about what we didn't do. We talked a little bit about what we did and and what we're going to do. Let's talk about how. This is where AI has essentially changed the equation. And if you haven't heard already, you. You will hear more about this as we, we go through the week.

But, um, we used transform to do things that we, we couldn't do a year ago. And it's essentially giving us the ability to do a structural assessment of a system that is 40 years old. It's a incredibly expedited reverse engineering. And we're not, we're not just reverse engineering, right. We're doing a lot of other things. But what we did initially was analyze 1.5 million lines of code, 1.5 million lines of code in a matter of hours. And again, not just scanning it. We're we're identifying domains. where mapping dependencies and integration points, and the output of that as a business rules extract documentation and technical documentation. And this documentation is is talking about our business logic, our transaction flows, our dependencies and our integration points. We get data model out of it. It's, it's pretty powerful. And this is just something that we've never really had before.

We've never had this capability to, to get what we got out of this. And it essentially helps us understand how our system actually works. It's the AI is giving us that ability to see through those walls and find those hidden dependencies before they ever become a problem. And while this is an essential ingredient and ingredient to our our roadmap, it's really only half the problem. Understanding what you have, of course, is the first step. But what you do with those insights to design the future is where the real value lies. And this is where Blueprint comes in. Blueprint essentially allows us to take that import that export from, transform, import it into to Blueprint. And we have a foundation for workflows, business rules, personas, and ultimately the entire user experience. And while this is really, really valuable, I just want to touch on something that Karim mentioned as well.

The best part of this is that it's an incredibly intuitive user interface, and it's something that you can put in front of your business stakeholders. And before anything is ever built, there's no money spent on on building code and getting into a stage environment. They have a really good understanding of how the process works. They'll have a really good understanding of what the outputs are. so there are a couple of other AI accelerators. We mentioned that we are iterating through our process, and we have introduced a couple more AI accelerators into our process more recently. So let's take a minute to look at our AI accelerated coal to cloud pipeline. We've broken this down into four different stages where we analyze, decompose, and document, where we validate, where we reimagine and rewrite and test and deploy. We talked about AWS transform and the way that we implemented this is we uploaded our code to a secure S3 bucket, pointed it toward transform, gave it a couple, um, prompts.

And the output of that was our technical documentation and our business rules extract. Now I mentioned, I mentioned 1.5 million lines of code. You can imagine that 1.5 million lines of code outputs thousands of pages of documents. And it does. And while AWS transformed today is more mature than it was even 4 or 5 months ago, it still can hallucinate. In fact, one of the things that told us in our first run was that we had a kick based mainframe, and we don't. So we iterate. We added the validation step into this process. And the way that we did that was using Amazon quick. And we created a knowledge base with Amazon Quick and a rag chatbot and gave that to our subject matter experts and our developers. And they're quickly able to query that using natural language to query those documents and validate the output of those.

We also use Pega.com Modernization Accelerator. This is a relatively new AI accelerator, and I believe it's named Pega Foundry. Now you can learn more about that in the Innovation Hub. This is also another game changer. One of the first chunks of business rules that we we looked at to pull into Pega was our routing for our claims, and there was six very large COBOL programs that handled a lot of the routing. So we took the documentation from transform regarding those six programs, piped it into the accelerator, and we got about 1200 Pega rules in around an hour. Now, Pega is a low code platform where you don't need to know Java or Python, but given that 1200 business rules was this output, you can imagine you have to have a large team of developers in order to to meet that same output. And while it's not, it's still it's still new.

It's incredibly useful. It does not produce spaghetti code, but you may want to also validate its output. And we do that by importing those rules directly into Pega Platform. And it's more of maybe we want to combine these decision tables or these when rules rather than rewriting anything. So again, human in the loop here to validate importantly, what this pipeline gives us is the ability to using AI quickly discover and preserve what the value of our existing systems is. And in order to preserve what's valuable, we need to look at the existing system in context. And again, that's what that helps us do. I love this lyric from Poe, so I digress a little bit. The past is a pebble in my shoe, if that makes any sense to anybody here. I'm sure I've just aged myself incredibly. But, um, to keep things in context, I just kind of want to call out to Po and remind her that we didn't always have shoes, so let's not chuck the shoe out.

Right? All right, I'll bring it back, I promise. So now we have we know we have two things that we didn't have before, right? We have a clear understanding of the existing system, both the existing structure and more importantly, its context. And we have a defined vision for the future state. And that allows us to move from renovation of systems to intentional redesign. And this is key because solutions are built around systems and they're shaped by the Platform Limitations and the the technical constraints of the day. And they're, they're made up by decisions that made sense at the time. But when you can take a step back and start redesigning intentionally, you can stop building around those systems and start building around user journeys and customer outcomes. Why is that important? It's important because to a customer there is no system, right? There's only an experience.

And while we're preserving the past, we're we're not just moving that value from one place to another. Again, not a big bang transformation, not a replatform. We're rewriting in the process. And this is where everything that we talked about earlier all comes together. Discovery helps us understand what we had. Blueprint helps us define what we should have. And now architecture becomes the means that connect the two. So what does that actually look like? We have a Pega in the cloud solution. So right out of the gate, right? It's composable, meaning that we can assemble capabilities based on need. It's in the cloud. So it's reliable, it's scalable, it's secure. It's importantly it's reversible. How quick is business changing these days? How quick is your business changing their mind on how they want to do business or the decisions that go into those business, those business decisions?

So these aren't permanent. And with this composable architecture, we can adapt as we go, as Pega likes to say. We can build for change. So going back to our building analogy, we're no longer just repairing rooms, right? We're designing for how people interact with it, how they enter the building, how they experience the building holistically. And importantly, this architecture isn't something we're waiting till the project is over before we achieve it. We're applying our principles as we go. We're removing green screens, we're introducing new Pega interfaces, and we're iteratively moving logic into Pega. So instead of creating that monolith from here and putting it over here, we're building something that is ready to evolve over time. New products, no problem. New business rules. With Pega, we can empower business users to add or update them themselves. So while we're pretty sure that no one size fits all for any project, let alone a modernization project project, and your time is too valuable to only learn from your own experiences and or mistakes.

What you've all been waiting for. What we know now. Our lessons learned. Firstly, the system knows more than the documentation. Plain and simple. And discovery is always deeper than what you expect it to be. No matter how well you think you know it, there's always hidden dependencies. There's always edge cases, and there's always behaviors that show up once in a quarter that you don't really know until you really dig into your system. Second, focus on outcomes and start with the user experience, not the logic. By removing green screens and modernizing our user interaction layer, First we're able to to to deliver value without taking unnecessary risk. Doing so, we're decoupling the UI, moving that green screen embedded business rules into Pega user interface. And it's it is important to remember that we're entering into a hybrid state here where we have Cloud a Pega in the cloud and mainframe.

So you want to make sure that you have a well documented and defined approach to move completely off the mainframe. So you're not stuck in that hybrid state. Third, while AI is an extremely powerful accelerator, its outputs still need to be validated. We can get more closely aligned outputs these days than we could even six months ago, but it doesn't replace the need for good architecture, strong domain knowledge, and a deliberate decision maker. It helps you move faster, but we still have to decide where to go. And you need people for that. Finally, one thing that we learned really, really quickly is that value depends on perspective. What matters to your customer, what matters to your business, and what matters to it. Those are rarely the same. So design for all three while always staying grounded in your customer. And remember to innovate empathetically. Great.

Thank you. You know, though we are still very early in our journey, we have started to see some value emerging by reducing manual handoffs, by pointing work correctly and by removing capabilities from the mainframe incrementally. Over time, we have started to see the value, and this has led us to to project a $20 million in value over the next five years. That's quite a lot. And that's just the business impact. It does not include the systematic value that includes over here, for example. This will also provide us help with simplification, reducing complexity, and over time it will help us to reduce the cost of running the system. These are real values and we are evolving it step by step into a I of the future to help us with the same trust and stability that has defined us for decades. This is our last slide.

We did not set out just to renovate a building, but we wanted to make sure that the building that the system serves, the people, that depends on it, not only for today, but for decades to come. This is not just a technology story, right? This is a story that helps us to renovate faster, be agile, quicker, and create value with an eye, an expectation of the future. And this is our journey and we are just starting. Thank you for joining us today. Good job. So we've got about ten minutes for some questions. If you have any questions There are some microphones out here. Alan. I believe you have a microphone. There you go. Can you hear me? Yes. All right. Um. All right. Thank you. Um, so I work for the VA and we have a lot of similar challenges where we're moving from old green screens to more modern GUIs.

And the thing that we've encountered is that our people are actually pretty fast on the old green screens. You know, it's keyboard based. They can fly through it, they're accustomed to it. And, um, we've encountered a lot of opposition and resistance to change as we've been modernizing. So my question for you is, have you experienced a similar thing? And how have you managed the change management human element, part of the transition? All right. Dang it. Um, People. We said this story is about people, and people are part of the process. People are the hardest things to change. So I think setting expectations up front is, is a very real way to approach this, but including people in the process. So we talked about setting stakeholders in right in front of Blueprint. This is huge because what you get out of that is you're incorporating the folks who will use your system in the designing of your system.

They feel more bought in and they feel heard, and they're more apt to change with the technology itself. So I guess short answer is include them, take their feedback, and usually you'll get change champions out of that. And then when you have the capabilities like Blueprint, they are co-creating with you. It's easy, fast. You can try it, test it out and can renovate it faster. So it's not like a decade old. It takes ever to test your theory. It will cost a lot more if you fail. So getting them together in a box with you helps them to renovate and be part of the solution. Thank you. Thank you for your question. Hello. Thank you for the presentation. Very interesting. Bill Goodwin. I'm an editor at Computer Weekly, and I'm interested in how far through the project you've got, how much more work there will be to do.

And following on from that, the 20 million value that you see coming in in five years, could you explain how that value will arise and and what it will come from? Thank you. Yeah. So a great question. So where we are, we are just about starting. We have focus on one part of our business, which is the VB. We are looking into different business process. Instead of trying to do a Big bang rewrite. We are looking into it incrementally, trying to reimagine the processes and then and then working with our business partners to provide the reimagined solution. As far as the $20 million in value over the five years, this includes things like reduced handoff manual labor for moving the work correctly into the in first place, reducing the total time to completion of the work. All of these goes into the value calculations. Just to add on that a little bit, one of the things that we talked about was routing our claims.

While there was some code that put it into queues. We have nine different claims managers that are giving that to people and it could be anywhere between depending on your your manager, 1 to 3 hours a day of work just to hand out a claim to, to somebody who's capable of doing that. So out of the box with Pega, you immediately get that uplift of routing. It's it's configure it once and it's go time. So there's a huge uplift there. A lot of value. And if, if um, again, depending on the user, if it's three hours and nine managers, we're talking about over 7000 man hours a year saved just by moving into Pega. And we believe these solutions will incrementally would be a hockey stick because as we are developing these solutions, we have to build the integration with our back end systems. So as more use cases we work on it, it would be we should be able to reuse those integrations with our with our back end systems.

So you mentioned. At the beginning that when you were looking at a big bang approach, it was like seven years and 25 million. So do you have an estimate of what it is with this new process? And the other question I had was, the first part of your transformation was basically API enabling a lot of your mainframe logic? Did Pega, Blueprint, or AWS transform help with that, or did you use any other AI tools? Because you'd have to refactor all your mainframe code on the mainframe to even API enable it. Yeah. So, um, I'll try to break down your question into a couple of different parts. So but I'll address the other one. The last one so I don't forget. Uh, yes. Um, the APIs we actually have, we have a couple tools in our tool belt, some of which were, were evaluating. Um, firstly we have z OS connect to that can actually create those transactional APIs that we were talking about.

And when we want to move to, we're moving, we're trying to move actually to the more orchestrated transactional, I mean, domain level APIs. There are tools out there that will help us. And one of the tools that we're we're planning to evaluate was actually in this work stream, but we didn't quite make it. There was open Legacy and open Legacy is a tool that will deterministically help you create APIs, rewrite if you need it to your COBOL code and put those in an orchestrator, or containerize them and put them in an orchestration layer. They'll. They're here somewhere. Actually, you can probably talk to them in the Innovation Hub, I would imagine, but. Oh. Um, I'm Vanessa co, I'm actually from Pega And I'm just curious that when I speak to a lot of insurers in in Europe, one of the biggest objections about moving away from legacy claims is they want to spend 20 to 30 million implementing guidewire.

I'm just curious, have you ever considered guidewire and your thought process or decision making process, and what was the main reason why you eventually to settle into having Pega to process your claims? So let me take that first. Okay. So an implementation like that usually takes a long time, cost a lot of money, usually big bang. But the approach that we have taken may be wrong, but the approach that we have taken is how we can decouple these problems and view it as a bit at a time. Right. And Pega, since we have been already using Pega, we are very comfortable with the technology and the new capabilities like Blueprint, Blueprint and others that it has and rolling it out. It gave us the confidence that we could attack this problem one chunk at a time. Prove the value. Instead of taking a huge organizational bet on a platform to transform.

And the value we we will see would be several years down, as I've shared. Even focusing on one part of our business is still early on. We are starting to see the real value that the business is achieving. Awesome. Um, I just we just got the ax. I see you have a question. I'm happy to stay. And yeah, we can talk after. Okay. Yeah. Um, thank you all for coming. This was great. I appreciate it, and I hope you enjoy PegaWorld. Thank you.