In an era where customer expectations evolve at an unprecedented pace, financial services companies face immense pressure to deliver personalized, timely, and relevant interactions. Rocket, a leading financial services provider, has successfully tackled this challenge by building a robust, unified customer data platform on Amazon Web Services (AWS), transforming its approach to conversion and customer engagement.
“Unified customer understanding is far more important than isolated AI initiatives. Why? Because AI will be fueled by that shared context of your business entities.”
Customer expectations are evolving faster than ever. Discover how Rocket transformed its financial services by unifying customer data on AWS, driving unprecedented conversion rates and operational agility. Learn the three pillars for data-driven success.
Good afternoon. This is Sajjin from AWS and along with me joining Gimma from Rocket. >> Hi everyone. I'm Gurima Sharma from Rocket. >> Okay, let's start. So today we are going to talk about conversion more specifically how Rocket used unified customer data to scale it. So how many of you feel about conversion being a big problem at the organizations?
Okay. So why are we talking about conversion and what is the connection between data and conversion? Because the expectation of the customers keep changing faster than ever means they are expecting us to feel every interaction. I think I'm getting my own echo but I'll try to manage uh every interaction that the customer is managing with the systems they want to feel it is relevant, it is connected and it is timely. And the reason why it is being happening is that is pushing every organization to rethink how to understand the customer and how to engage with the customer across the business because that is what we are going to talk about. Let's get started. I think it's very much probably obvious that what every industry or every enterprise is thinking about or focusing on today. Any guess?
Any guess? >> It's AI. Yes. So more prominently how to adopt it, how to scale it and how to turn that into a real business value because all these organizations are investing on data platforms and AI to transform customer experiences and automate the business operations. At the same time, the customer expectations and on the flow on the journey with the business that they are doing is increasing at the same rate. So how are we going to solve it? So is there any way that we are going to solve? The more question is all about it's not the investment that we are making but how fast we could able to interact with the customer in the same pace that he's expecting to have. Uh let's move to the next one.
Okay. Thank you. So for a long time the conversion we are all thinking about is a mechanical problem. Why? Because we are always thinking that hey how can we make the frictionless funnel so that people can go through the funnel faster so that our top of funnel could be improving and the conversion rate would improve. But that is different problem because that is no longer valid in 2026 because now the conversion is no longer about solving the friction in the funnel. It's more about context. So the problem itself has been shifted from process optimization to context. So how are we building the context and the context it comes from a unified data. So when the data is going through the system so we have to capture across each and every touch point from the business so that we derive value out of it. So as we talked about conversion is being a data problem or data problem at a scale not a funnel optimization problem. So in that sense how can we solve it and what are the things that we'll be doing it because the main thing that I talked about having an understanding of customer at a scale then you might naturally ask hey in that sense we have collecting lots of data about our customers each and every journey because we open multiple channels either web mobile and different platforms that we open we are collecting among us of data from the customer then why didn't the understanding of the problem at a scale is being solved. But the problem is not about having the data. Understanding the data is the biggest problem because the data strategies that every organization and we are practicing is all about collecting the data coming into a centralized data platform and providing an access to the all the different teams. That is where the most of the data strategies that so far we are following. But in this era it's more about how well you understand the data because every organization in some form we are a data business organization. So how are we solving it? Because we realized the journey is more about understanding the customer not about having the data. So in this scenario we have seen the three things as an interconnected pillars to make the more value out of the data. One is connect,
curate and adapt or active. So connect is like bringing all your data across from multiple systems and curate is creating a sharable data understanding where your product teams and engineering teams can take value out of it and activate is going to help you to provide all the experiences that you're going to deliver with it. with that uh the rocket has been adopted this approach when they started their journey on the AWS. So with that I would love to hand over to Gara to talk about how it has been adopted in the rocket and how it did shaped the journey. >> Thanks Arjun and yes that in financial services that becomes very real very quickly. At
Rocket, our mission is simple. Help everyone home. And that mission shapes how we decide about technology, data, and customer service throughout the journey. Every capability we build with AWS is ultimately focused on making our customer experience simpler, faster, and more personalized. >> Yeah. Because we all know conversion is about trust, timing, and some of the biggest financial decisions our customers make. Transforming home ownership journey has been part of rocket strategy for decades. Over the past few years, we moved from offering digital mortgages to mobile engagement. from mobile engagement to now more AI connected customer interactions throughout the journey. And every step we took forward, the amount of data, customer activity grew exponentially. And with that came a realization for us and that was to scale personalized customer experiences. Modern applications and access to data wasn't just enough. What we required was a common
understanding of our customer across the entire business value chain and that became the foundation of our data strategy on AWS. So we built a unified data foundation with shared ingestion patterns, common open table formats and centralized governance. This was not an infrastructure decision. It was a decision to unify everything, bring data in one place, process it once and make it usable for everyone across the business. Data was no longer fragmented. Teams were moving faster. They were they had access to connected customer insights to personalize, to apply AI or to automate. And once this foundation was in place, the next challenge came for us. Can anyone guess what that challenge would be once we had this unified data foundation in place? It was scale. Operationalizing this data
now at scale was our next challenge. So we focused on building shared architecture patterns across ingestion, transformation, and consumption. No one-off pipelines, no isolated implementations, but common ways for teams to bring data in, process it, and activate it across the business. That meant supporting batch event driven and streaming workloads across all ingestion approaches. That also meant process data once, make it available for everyone. And it also meant enabling analytics, AI, machine learning workloads and other business activity across all channels. The goal here for us wasn't centralization for control. It was to enable teams to move faster without having to build these capabilities repeatedly separately.
And we went from unified data to unified understanding of it. Right? By creating shared business definitions around our customers, transactions, operational activity, everyone used that shared context for activation. There was no siloed implementation or understanding of a customer or a customer's preference or communication we were having with them. All our businesses knew where the customer was in the journey and was able to respond accordingly and more effectively to their needs. We moved from duplicated effort to shared context and from searching and connecting the data in silos to using the data that's already aligned in business context. Again I emphasize here aligned in business context. That was the key for us and the foundation became really very important for rocket when uh we acquired Mr. Cooper and Ruten. How many of you I'll ask a quick question here. How many of you have gone through a hope buying uh process? Maybe you yourself have or know somebody who recently has. Right? Most of us and I would say most of us understand how disconnected that experience can feel for us for us what rocket is building toward is
connecting the three together right you don't have to search for a home in a in one place go for financing it at another place and have another organization service it for you and repeat all the steps in all those three places. What rocket is building toward is connecting search financing and servicing together to offer a one experience for the customer because that's what c customer experiences when they buy home. It is not three different domains. It is not three different transactions but historically speaking the industry has evolved that way. It has evolved as series of disconnected different different transactions. But that's where Rocket comes in and is building toward offering the connected experience to our customers.
Our data foundation was put to test real soon post acquisitions because our data ecosystem expanded overnight. overnight. The customer touch points, new platforms, new operational demands dramatically increased with our acquisitions. But we were not starting over with every integration because we had the foundation in place. All we did was extend that foundation to this expanded ecosystem now and we were able to use the existing capabilities, build upon them and on board new data, new analytics, new operational demands and our business continued to accelerate while our ecosystem was evolving. So we maintained the speed, the accuracy and the experience of our customers through the expanded data footprint as well. And at this stage, so this is a highle architecture to give you an overview of what our data platform, modern data platform looks like and how this architecture helped us extend it for our increased data footprint. We didn't duplicate efforts. It was just simply extending ingestion, transformation, and consumption patterns. A new business use case came. We were ready to enable them and allow teams to use more data quickly and the way they wanted because if you look in our consumption pattern, we had all methods of exposing that data to according to the business need. New brands, new touch points, everything. Nothing stopped us from maintaining our speed and agility and we were able to offer the curated ready connected data sets to all the businesses across the organization.
One of the most important capabilities that this data foundation enabled for us was client 360. not just another customer profile. We built it as a connected view of a customer journey. So not behavioral attributes just stitched together and giving you a profile, right? As typically we are familiar with uh about a client 360 view. But what we did was we engaged all data points, stitched them and maintained those data points about a customer throughout the journey right from top of funnel to the servicing end of the life cycle of home ownership. So instead of disconnected interactions, each of our business area knew the context where the customer was and they knew what relationship they had at a certain point with us and they were offer they were able to offer personalized experience to the customers. And once client 360 was enabled, it just became the basis for other 360 views, the shared business views that again the entire organization was able to use. for example, transaction 360, mortgage 360, lead 360 and the list grows. But the fundamental problem that we solved with this was no repeated isolated representations of customers or their relationships with us. It was available in one place ready for consumption in any form that the different teams wanted and everybody was able to move faster without waiting to have access to this data and that's what changed for us how Rocket engaged with customers at scale
and the outcomes were significant. Our refinance pipeline increased by 20%. We saw a conversion lift of 10%. We achieved recapture rates three times the industry average. And during our Mr. Cooper integration, 40,000 leads were onboarded within nine days with the first client closing in just 3 days.
If there are three things that you were to take away from Rocket's journey, they will be these. Number one, unified customer understanding is far more important than isolated AI initiatives. Why? Because AI will be fueled by that shared context of your business entities. Hence, that consistent common understanding matters more. Number two, standardized patterns create speed for you. There is no shortcut to that. If you want to move faster, standardized architecture patterns are the answer all along your data transformation life cycle. Right? Number three, data creates most value if it becomes operational across your business. And that's what we did, right? Not just available in a platform, but usable, connected with the context. So that's the real shift from having data to understanding data for the foundation of decisioning AI measurable business impact and activation all across your organization in one single uniform way. Thank you. >> Thank you.
>> Is it room for any Q&A? Any question? Yeah, we are open for questions. I think we have time. So, if there are any questions um we'll take it there. >> Hey, thanks for the uh talk very interesting. Um interesting. Um from I I one of the points on the last slide was um that having this is more important than the unified customer understanding is more important than the A initiatives. What I'm finding is that once you actually do that, then you can sort of layer some of these AI tools on top of it. Have you found that to be the case? Like after you actually build this, has AI then be able to generate insights for you that you know sort of using uh skills or likememes that otherwise you wouldn't have been able to do. >> That's correct. Yes. So we we did we didn't we didn't know this, right? This is our learning. So we also started with some of the AI initiatives that were happening in silos and teams were trying to figure out where is the data how do I connect it how do I stitch it to build that context right uh once we did this then yes you're right any idea that came in any business team to apply any tech team to apply AI the data was available right so they were able to move faster for sure um I know it's initially sometimes >> far-fetched >> far-fetched not easy to right that everyone wants to move fast but we realized later at the end of a P or a POV that we could have right had curated data first and we would have been uh much faster and with the insights also that AI if you're creating AI agents they're relying on this context to do the work so it matters So in terms of um when you standardize your your data patterns and architectural patterns um what was the biggest challenge you faced in in that? I think the biggest biggest challenge was um the common the common question of do we have to wait for this right so initially because yes there was teams while we were building this the teams had to wait so I would say continue building it continue investing in it and start with proof of value on one business use case that's how we were able to overcome the challenge of how long do we have to wait will this give us value prove it out with one right um use case and then it's right yes that um but there is no I mean you will always get that uh question from different teams who want to move faster who think they have the data well um that's not true this helps it takes time a little bit time but then after that uh everybody realizes the value. So I would say overcome that challenge of questions asked or or uncertainty or doubt about whether this will prove useful or not. It has proven useful for us. >> I I assume that um your data ingestion is automated automated right? So what happened when the data provider change the format without telling you or if the data is corrupted how do you handle that automatically? So based on um it was difficult initially but now the stage we are at um at least at rocket we were able to formulate data contracts with our producers. Okay. Standard data contracts that they had to abide by right for for and if they are changing patterns we knew we knew beforehand what we needed for those. So it takes again it takes some time but once people see the value and once we were able to engage with our product engineering teams mostly the producers right um it it became simple >> that corrupted data data quality is always going to be a challenge uh I think there is no silver bullet to that right what I will say is We've put a lot of observability in place in our platform alerts around quality around mismatches around everything else and that is what you know would help checks and balances data quality validations during all the three phases that I said right ingestion transformation and then even consumption um helps with that problem. >> Um, based on your architecture, do you have a federated model? >> I know people um understand federated model slightly differently. So I would ask you what do you mean by federated model in this uh case? and get >> right >> right but just say it false. >> Well, many years ago that was the pattern but not now anymore. So it is not a federated model from that definition because even with standard patterns and services that AWS provides. We did see that um a certain skill set a certain discipline and rigor is needed to build and scale your data platform. If you have to provide the value for the entire organization for a team for a business one particular business area it could work but federated model um is not functional for scale. You know how >> because as right the data is same data is same you are now creating some version of it in different units or different areas and that's the exact problem we solved around having different versions of customer across our business areas in their own siloed lens right they were preparing and curating that information however we knew the more we knew knew about our customers. The more we understood about them and there where they were in the journey, the more all the business areas were able to help the customer better. So we knew that there are certain key business entities that what has worked for us and I can say being in this discipline for 20 years um the model to go with is a centralized unified data platform at least for your key business entities. Hi uh my question is regarding that last bullet point uh which is a value of data. I know you talked about that fragmented data bringing to a common data platform for the across the business. So that is something we are also trying to do bringing two different business use cases to the same platform. But uh the challenge is for data engineers they need to understand the both business which is difficult. So if you can provide a little more insight how did you make that happen like two different business units or data to come and I hope you're saying like take the raw data and have a curation layer. So if you can give a little more details on that. So the business context, business definitions, the use cases, we partnered with product, our product teams and analytics. Analytics team was our partner in building this the right way, right? Because to your point, sometimes data engineering, you care about engineering the data for the use case, but maybe sometimes you miss the context. sometimes you miss what it will be used for and that's where upfront partnering with product in analytics um helps a lot because ultimately again the goal here was that business and other teams were able to use this data right the understanding that we created here was not just okay it's now available in the platform and we are done we wanted to make sure it was used and the way they wanted meaning We exposed it through events. We exposed it through a APIs. We put it in snowflake, red shift, right? So we made sure it was available to them for using in all the formats and for that upfront you need to understand what will they be using it for and that's where product in analytics partnership worked for us and in case of machine learning AI models partnership with data scientists worked with us right worked for us here okay thank you everyone
Results Speak Volumes!
Data Success Secrets!
One Home Journey!
Deep Customer Insights!
Common Customer View!
Scaling Data Smart!
Context is King!














