Can You Trust Your KYC Data? Ensuring Accuracy With Data Observability

Good morning. Good morning, good afternoon, good evening. Welcome to the webinar. Nice to see some of the attendees joining. I appreciate all the early birds who showed up on time, but we're going to start the session in about two minutes from now. It is the top of the hour, but we will get going here in a couple of minutes. I see some folks in the waiting room slowly joining the session.

So we want to give everyone enough time to get into the session. So you still have a little bit of time to grab your coffee or favorite beverage. And like I said, we're happy to see you joining the session. Looking forward to a productive one. We will get going here shortly. Thanks for your patience. I see a couple more attendees joining.

Welcome to the new individuals who have joined the session. We are going to get going here shortly. I see a few more folks in the waiting room. We want to give everyone a chance to hear the webinar from the beginning. Don't worry, we will have plenty of time. I think we only scheduled about 45 minutes, so we'll even give you a little bit of time back in your day. But we will get going here in a little bit.

Again, thank you for joining. All right, Scarlett, I got about two minutes past. I see, I think, one more person trying to get in, and I'll talk slow, and okay, we'll get going. Again, good morning, good afternoon, good evening, depending on where you're joining us from. Welcome to our third and final webinar in a series. We'll talk a little bit more about that. If this is your first webinar with us, happy to have you here.

For those returning to close out the series, welcome back. My name's John Wisencay. I'll be your host for today. Before I hand the floor over to our presenter, Scarlett, I did want to cover a couple of housekeeping items for those that are new to our webinar series. Just a couple of quick things. We do, unfortunately, have you all on mute so that we can run a pretty effective webinar. We've got a number of attendees on, so we wanted to make sure that we start the webinar on mute.

Throughout the course of the webinar, if you have any questions, please feel free to leverage our Q&A panel. For those that are new to Zoom, the Q&A panel, you can find that at the bottom of your screen. You probably see a little circle with three buttons and a more. If you click that, you will see Q&A. Please feel free to type your questions in there. I've got a team, or I've got Hal standing by to address your questions. I'll introduce him in a second.

This session will be recorded or is being recorded. The team will make sure that we get this recording out to you post-session. Like I said, we're going to run about 45 minutes, and all the resources that are covered today will be emailed to you post-event. One last thing, any technical issues, please feel free to hit me up on my email address. I'll try to work through those with you to get those resolved. So real quickly, let's introduce the team today. So as I mentioned, my name's John Wisencay.

I lead the sales engineering team here. I'm just one small component. Our main presenter and the person of interest for today is Scarlett Webbe. She will be our speaker and presenter. And as I mentioned, Hal Shriver, he is here to help man and support the Q&A window. So any questions you have, please feel free, again, to type those in there, and we'll be sure to get your questions answered. Next slide.

So as I mentioned earlier at the top of the session, this is the third webinar in a three-part series. If this is your first time with us, don't worry. We have built these sessions to stand on their own. But just to highlight the sessions, you can also go back and register for them and get the recording, so don't feel like you're missing out on anything. But we built this really around three components that fell nicely into our overall portfolio. Our first session was back in June, where we highlighted the activation layer. This was an overview of our AI analyst.

We then jumped into what we call our context layer with our data intelligence platform. We did this session about three weeks ago. This is where you're able to gather and gain context on your information. And we're going to round this session off today with the trust layer, and we're going to dig deep into our data observability platform. And so with that, those are the three webinars that we have, and today we'll focus on data observability. So I will hand the floor to our presenter, Scarlett. Scarlett, take it away Thank you, John.

Before we jump into the observability platform, I want to quickly connect this session back to the previous Know Your Customer Data Catalog webinar. And in that session, we focused on Actian data intelligence as the context layers John mentioned. The Know Your Customer, or KYC, onboarding process was defined as the mandatory process financial institutions use to verify customer identity and assess risk before allowing someone to open an account. We walked through the five steps of that process: account registration, identity verification, address verification, risk assessment, and approval and onboarding. The important thing the catalog gave us was business context. We could search for KYC onboarding, see the glossary hierarchy, understand each sub-process, identify owners, and connect the business language to the technical data assets underneath it. One of the phrases from that session that I think is worth carrying forward is that the catalog is a bridge between business language and technical data assets.

It answers the question: where is this business process actually represented in our data? We also saw the medallion architecture behind the KYC process. The bronze layer is raw customer data, where account registration, identity verification, address verification data first lands. The silver layer is staging customer data, where we enrich the record with external watch lists and sanctions information and assign a risk factor. The gold layer brings customer account and transaction data together so teams can flag potentially suspicious activity. The catalog also showed quality indicators directly in lineage. That was the teaser for today.

In the catalog, those indicators turn lineage from a static data map into more of a living risk map. And today, we are going to go under the hood to look at the Actian data observability platform that produces those signals, detects those issues, and helps teams investigate and act on them. So today's demo is all about answering one question: Can we trust the data that derives KYC decisions? For a bank, that question matters because KYC is not just a reporting workflow. It determines whether a customer is approved, whether risk is escalated, whether potential suspicious transactions are flagged, and whether downstream teams have confidence in their customer profile they are using. As we go through that flow, we will show how Actian data observability monitors KYC data across those layers, detects reliability issues early, validates onboarding data for freshness, schema, PII exposure, and format problems, uses data binning to separate high-risk and approved customer populations, and accelerate root cause analysis through Investigator. Now, before we move into the product, I want to spend a minute on architecture because it matters for this use case.

KYC data can be sensitive. It can include customer identifiers, address data, identity verification fields, and risk scoring information. So from an architecture perspective, the key point is that Actian data observability connects to the data where it lives. In this example, our KYC assets are in Snowflake. Before we move into the demo, I want to spend a minute on why the architecture matters because this is a big differentiator for Actian data observability. At the center of the platform is a decoupled Spark SQL processing engine. What that means is we can profile data, apply rules, detect anomalies, monitor quality KPIs without pushing that compute burden back onto the underlying data source.

So whether the data is in Snowflake, S3, BigQuery, Kafka, Delta Lake, or another part of the pipeline, Actian can analyze it where it lives and return the observability results back into the application. That becomes really important because modern data pipelines are not just made up of clean warehouse tables. They often include raw, semi-structured, and unstructured data earlier in the flow. Because our engine is decoupled and Spark-based, we can look across those different data types and pipeline stages, not just the final curated tables that downstream users see. So today, our demo is focused on KYC data in Snowflake, moving through a medallion architecture. But the bigger takeaway is that Actian is designed to detect issues much earlier in the pipeline before they become bigger problems downstream in compliance workflows. That is important because we can monitor large tables and raw data without forcing teams to copy sensitive KYC data into another system just to understand whether it's trustworthy.

Now that we've covered the architecture and why the decoupled Spark processing engine matters for monitoring data across the pipeline, let's bring that into the KYC business flow we're going to demonstrate today. We'll stay anchored in the same KYC onboarding process. So again: account registration, identity verification, address verification, risk assessment, and approval. But instead of focusing on business context and lineage, today we're going to focus on trust, whether the data moving through each step of that process is complete, fresh, valid, and behaving as expected. In the demo, we'll monitor KYC data across a medallion architecture, raw customer data, staging customer data, and gold transaction layers. We'll look at how Actian Data Observability detects reliability issues before they impact those workflows, validates onboarding fields like identity and address data, flags schema, freshness, format, and risk-related issues. We'll also show how data binning can separate high-risk customer populations from approved records, and then use Investigator to identify the exact fields, records, and segments driving risk.

The goal is simple: move from understanding how Actian can observe data across the pipeline to seeing how that helps teams determine whether KYC data can actually be trusted. So before we jump directly into Actian and Data Observability, I want to start where a business user, a data steward, or a governance team may actually notice the issue first inside Actian and Data Intelligence. Here we're looking at the transaction roll-up data set, which sits in the gold layer of your KYC pipeline. This is where customer account transaction information have been brought together to support downstream fraud detection and compliance review. On the Data Quality tab, Actian Data Intelligence gives us a business-friendly view of the health of this data set. We can see there are 12 total checks. 10 have passed, two have failed.

At a glance, this tells us that this data set is mostly healthy, but that there are some specific reliability issues that need attention before we fully trust it for KYC or fraud-related decisioning. What I like about this view is that it groups together the checks into categories that are meaningful to the business: consistency, completeness, timeliness, fraud, and validity. So rather than asking a compliance analyst or a data steward to interpret raw SQL or logs or pipeline alerts, they can immediately see most of my checks are passing, but I have a failed fraud check and a failed validity check. That is a much more actionable starting point. So the natural question is, what is driving those failed checks? This is where we move from context into investigation. Actian Data Intelligence tells us which trusted business asset is impacted and gives us the business context around it.

Actian Data Observability tells us why the issue happened, which records or fields are involved, and what action we need to take next. And we can go into Actian Data Observability directly from the data catalog. And now we're in Actian Data Observability. We're focused on that same transactions roll-up asset. And we were just viewing in Actian Data Intelligence. So this is where the trust signal becomes actionable. This is Investigator.

It is an interactive workspace analysts, engineers, or business users use to explore, diagnose, and resolve data observability issues once anomalies are detected. Here, we can drill into the monitor results. We can view trends over time. We can see the magnitude of the issue and understand whether it's a one-time event or a recurring pattern. For this scenario, which is KYC, that could mean which transaction types are driving the risk issue, which risk bands are overrepresented, or which customer records are tied to suspicious transaction amounts. So what's happening here is this is flagging individuals with a high-risk amount and also a high transaction amount over $10,000. So instead of saying the transactions roll-up failed a fraud check, we can say, "Here are the exact patterns and records causing that failure, and here's a subset of the data that needs review." So this is the handoff between data intelligence and data observability.

Actian Data Observability gives us the operational trust layer, so records that are fresh, complete, valid, behaving as expected, and when they are not, what exactly is causing the issue? And for KYC, that connection is critical. It means teams are not just documenting compliance data, they are continuously validating the data that supports onboarding, risk scoring, fraud detection, and regulatory review. So now that we've used Investigator to drill into the specific records, values, and patterns driving this issue, I'm going to zoom back out to the overview page. The reason I like to go here is that Investigator gives us the detailed root cause view, but overview page gives us the operational command center. It helps us understand how this one issue fits into a broader health of the KYC pipeline. So what else is open?

What's been closed? What's been resolved? Which assets are impacted, and where's the highest priority risks are across the environment? So we've gone from the alert into the details, and now we're coming back up to the overview. So a data team, compliance team, or operations leader can understand the bigger picture and decide what needs attention next. So within this control tower for data reliability, instead of starting with one table, one rule, this gives us the operational view of what's happening across the entire KYC data estate. Now, for this demo, we're just going to focus on KYC assets in Snowflake.

The types of information I want to call out here are the total number of incidents, severity or impact, incident creation time, and then the trends over time. This is useful for data operations teams because it answers What is broken? Where is it broken? How long has it been open? And who needs to respond? And for that, it matters because not every issue has the same business impact. A schema change in a non-critical column might be a warning, but PII exposure with missing identity fields or an unexpected volume drop or risk factor values outside of the approved ranges are much more serious because they can affect onboarding, compliance, review, or fraud detection.

So the overview is where teams can quickly understand the health of the KYC data flow before drilling into a specific asset. I'm going to open up this incident here so we can move from the overview view into the details of a specific reliability issue. At this point, a data engineer or a data operations analyst may know that something is wrong, but they still need help understanding where to start. Is this a issue at the data source? Is it tied to a transformation? Is it isolated to one field, one customer segment, or one run? That is where our data observability agent becomes useful.

Rather than manually piecing together the incident details, trends, monitor results, and asset context, I can use the data observability agent to help summarize what we're seeing and guide the investigation. The question I'm asking here is, what is the likely root cause of this incident? And what the data observability agent is doing here is helping translate the observability signals into an investigation path. It can summarize the incident, highlight the affected asset, point out the fields or patterns that are contributing to the issue, and help teams understand what to validate next. So instead of starting with a generic alert that says something failed, we're getting a more guided root cause analysis experience. We can understand whether this looks like a data quality issue in the source or transformation problem, or in the pipeline, or a business rule violation tied to KYC thresholds. And the business value here is speed and prioritization.

Ask AI helps the team move faster from incident awareness to incident investigation. It gives data operations a starting point, gives compliance teams a clear explanation of the business impact, and reduces the back and forth between teams trying to interpret what the alert actually means. Sure, we can still drill into the monitor itself, but we can use Investigator to validate the exact records and values involved. But now we're not starting from a blank page, we are starting with the context. So let's quickly orient ourselves to the rest of the assets that we're going to be looking at today. So as I mentioned earlier, the bronze layer will be the raw customer data, and this represents the data collected as the customer starts account registration and provide identity and address details. Staging customer, this is where we introduce risk factor scoring on external checks like watch list, sanction list, or other risk models.

And then the gold layer, we have transactions and transaction roll-ups where we combine customer risk with transaction behavior. This gives us a clean path. First, do we trust the raw customer data coming in? Second, do we trust the risk scoring and approval logic? And third, do we trust the transaction signals being used to detect potentially suspicious behavior? So we'll start with the raw customer in the bronze layer. This is the earliest point in the KYC data journey, and it is also where a lot of problems can be caught before they spread.

At this stage, customers are providing account registration information, identity verification details, and if the raw data is wrong here, every downstream decision becomes questionable. From the profiling page, we can see the attribute or column level health of each asset. This includes completeness, duplicates, correctness, uniqueness, cardinality, distinct values, any sort of empties, and other profiling statistics. Instead of saying, "We think the customer table looks fine," we now have a quantified health picture of the data. For KYC, some of the high-value checks in this layer are required identity fields populated. Are address fields present? Do fields like Social Security number and credit card follow expected formats?

Are customer IDs unique? Did the schema change unexpectedly? And did the volume of new registrations drop or spike compared to normal behavior? This is where acting data observability helps shift left. We are not waiting until a downstream fraud dashboard or compliance report looks wrong. We are detecting issues as close to ingestion as possible. Now, let's drill into one of the alerts from raw customer here.

In the Trends and Alerts page, we can see the run history of this asset and the specific alerts generated during each scan. The platform is monitoring expected behavior over time, so we're looking at what changed, when it changed, and how significant the change was. For example, if we are looking at PII exposure- The issue the platform can identify is sensitive patterns appearing in places they should not, such as freeform notes. If we are looking at a format issue, such as structure for Social Security or address, date of birth, or other onboarding factors. If we are looking at volume or freshness, we can detect whether customer registration data is delayed or incomplete. And when we go into Investigator, this becomes more than just a red or green status. Investigator gives us that interactive workspace to understand the records, fields, values, and segments driving the alert.

This is the difference between a noisy alert and an actionable investigation. The team can see which fields are affected, which values are causing the problem, when the anomaly started, and which records are involved. From here, they can export the drill-down data, they can create an issue, or route this to the right incident team itself. For a KYC workflow, that is critical because you do not want an analyst manually hunting through Snowflake, trying to determine whether the problem is a raw data issue, a pipeline issue, or a transformation issue. You want to quickly isolate the cause and protect the downstream process. Now let's move from the bronze into the silver layer. So, this is where the KYC process in staging customer becomes more risk-oriented.

We are no longer validating whether the customer filled out the form correctly. At this point, the customer record has been enriched with risk information from external sources such as watch lists, sanctions lists, or other screening processes. In this demo, we're going to look at high-risk factor score. A lower score represents an acceptable risk level. A higher score represents a customer who may need additional review or should not be automatically approved. And the reality is, your data never sits still. It's always evolving as applications, customers, and business processes change.

That's why static quality rules break down so quickly. You need machine learning-driven monitors that adapt with the data itself, catching shifts upstream before they become expensive downstream problems. It's about building trust that scales with your data, not just snapshotting it in time. And we have here 16 out-of-the-box monitors that are automatically applied to your asset upon that first scan. So Actian's machine learning monitors learn patterns in your data automatically without requiring you to write custom rules. They analyze data with each scan to determine normal distributions, relationships, and trends. So once the model is trained, it continuously checks incoming data in real-time or batch.

The automated checks provide value in a variety of ways. If you're a data engineer, this saves time with no more ad hoc rule writing. And if we look at, for example, this high-risk factor too high, let's look and break down the parts of a monitor. So a monitor is made up of three parts. You have the metric, what you're measuring. You have the threshold, how do you determine when something becomes an anomaly? And there are three ways to do that.

Machine learning-based, so learns from data patterns. You have relative, percentage drift between periods, and hard-coded ranges, explicit min and max values. And the third part is the action. Who do you want to notify when something goes wrong or the records don't meet that monitor? They provide machine learning baselines, reducing the need to manually define those thresholds. So in this example here, we're looking at a record validation rule. So within this expression here, what we're seeing is we're using your risk factor values from one to 11 that are considered acceptable for automated approval, while values above 12 are treated as high risk.

Now, that does not mean the data is bad in the traditional sense. It means the data is telling us something operationally important. This customer population should be separated, reviewed, or blocked from downstream approval. And this is a great example of why data quality and observability need business context. A number like 13 is not inherently invalid. It is invalid for this specific KYC approval workflow because it crosses the bank's acceptable risk threshold. And if we open this up in Investigator, we can see the distribution of values that are driving the violation.

So that one through 16, and we can see the number of records that fall into those risk bands. So this is where Investigator helps us move from detection to understanding. We can select a specific value, like risk factor of 13, and we can see the records that are associated with that value. That gives the KYC operations team a concrete population to review instead of a vague alert that says, "Risk factor issue detected." Another important capability is data binning. In this KYC workflow, we can separate records based on the risk factor threshold. Customers with an acceptable risk range can continue to the approved threshold. Customers within a non-acceptable range can be separated into an invalid or high-risk path for additional review.

And that matters because the pipeline does not have to stop just because some records need attention The good records can keep moving while the high-risk records are parked for review. For a bank, that helps preserve operational continuity without ignoring compliance risk. This is a control point between the silver and gold layers. We are using observability not only to detect that a risk threshold has been crossed, but also to isolate the impacted records and prevent them from silently contaminating the approved customer population. So now let's continue into the gold layer. At this point, the KYC process-- Let me go over here. The KYC process has contained...

Sorry about that. My Magic Mouse got a little bit crazy there. Contains transaction as well as transaction rollup information. So transaction represent the transaction-level activity, and the transaction rollup gives us an aggregated view that combines customer risk factor and transaction behavior. This is useful for fraud and anti-money laundering scenarios because suspicious activity is rarely about one field in isolation. It is usually a pattern across customer profile, risk score, transaction type, and transaction amount. So let's open up the suspicious transaction or money laundering.

The logic we're using here is that certain combinations should be flagged for review. For example, a customer with a risk score above an acceptable threshold should be escalated, but even a lower risk customer can still produce suspicious activity if they have certain transaction types or transaction amounts that are defined above a threshold, such as cash, Zelle, or foreign wire transfers over $10,000. And if we go into Investigator, we can see the values and combinations that are driving the alert. One way to show this is by grouping or aggregating the risk factor with the transaction amount. So the team can quickly identify whether the issue is concentrated in a particular risk band, transaction type, or range amount. The important point is that observability is not just telling us that the gold data set failed a check. It is helping us understand why it failed.

When customers or transactions are involved and whether the issue started upstream in the customer onboarding, in risk enrichment, or in transaction processing. That is the power of monitoring in the full KYC pipeline. We can start with the suspicious transaction behavior in the gold and trace it back to the investigation to the underlying risk factors and raw customer profile. Or we can catch issues earlier in the bronze or silver before they ever show up in the transaction workflow. For compliance, that means faster triage. For data engineering, that means fewer manual investigations. For the business, it means more confidence that the data used to approve customers and flag suspicious activity is reliable.

So once an issue has been investigated, the next question is how does it get to the right team to act on it? Actian data observability supports alerting and operational workflows. So teams can route issues by policy, asset, owner, severity, or channel. That might be email, Slack, Teams, JIRA, ServiceNow, or another process the organization uses. The goal is not to create more noise. The goal is to make alerts actionable. A high-impact PII issue in the raw customer should not be treated the same way as a low-impact profile drift in a non-critical field.

A high-risk factor threshold breach in staging customers should go to the team responsible for KYC review. A suspicious transaction pattern and transaction rollup may need to go to fraud operations or compliance. And after remediation, the platform can rescan the data and update the incident based on the actual data itself. So that means the resolution is tied back to whether the data has returned to an acceptable state, not just someone closed a ticket. So let's recap what we covered. First, we monitored trusted KYC data across the full pipeline, raw customer onboarding data, staging customer risk scoring, and gold transaction monitoring. Second, we detected compliance risk early at the bronze layer.

That means catching freshness, schema, PII, completeness, and format issues before they move downstream. At the silver layer, that means identifying customers who cross risk thresholds before they are approved. And at the gold layer, that means flagging suspicious transaction patterns that combine customer risk and transaction behavior. Third, we accelerated investigation. Investigator helps teams move from something failed to here are the fields, values, records, and segments driving the issue. That is what turns observability from a dashboard into an operational workflow. So the big takeaway is simple.

The catalog gives KYC teams context. Actian data observability gives them continuous trust. And together, they help organizations understand not only where KYC data flows, but whether that data can be trusted at every step. Great job, Scarlett. Well done. Very informative and a perfect way to round out the series. So for the individuals who are with us live, if you have any questions, feel free to type those into the Q&A panel, and we will be sure to address those here in a quick second.

I did want to provide our contact information. I know many of you watch these recordings post-event. And also, for those that are watching the recording, if you have any questions, need any additional information, I wanted to provide our contact information. Not only myself, but also Scarlett, who was our presenter, and Hal. Again, any questions, need additional information, any content, please feel free to reach out to us. One little call to action for either those on the session or watching the recording. As we mentioned during our first session, we offer a 14-day free trial for our Actian AI Analyst.

It's a great way for you to dig in and start to get a little bit of hands-on with our technology. It's very easy to learn, and a lot of our customers find immediate value with this 14-day trial. Full access to the platform, there's no restrictions. And then if you're joining us for the first time, I mentioned earlier that this is part of a three-part series. We round it off here with the trust layer. But if you're interested in registering, you can do so, and watch the previous webinars on demand. You can simply go out to our website and click on the Events section, register for those sessions, and gain access to the two previous KYC recordings.

And so with that, I think we're going to turn it over to questions. Again, for those individuals on the session, if you have any questions, feel free to type those in. Great. I think we just got a question coming in. Scarlett, hopefully you can address this live. So looks like we've got, "How is Actian Data Observability different from maybe traditional data quality tools or pipeline monitoring tools?" Really good question. So one of the biggest differences with Actian Data Observability is that we're not just sitting at the end of the pipeline checking whether data passed or failed a predefined rule.

As I mentioned earlier in the presentation, the platform uses a decoupled Spark processing engine to profile, analyze data at scale, which allows organizations to monitor data across different sources and stages of the data life cycle without being limited to a single warehouse or relying on SQL-based checks. That also supports a shift left approach to data observability. So instead of waiting until that bad data reaches a dashboard report, an AI model, teams can monitor data much earlier in the pipeline. So, for example, if the data lands in a raw or bronze layer and continues to monitor as it moves through the transformation and consumption layers, that gives team the opportunity to identify issues closer to where they were introduced. And then we also combine automated monitoring, such as freshness, volume, schema, top drifts, record IDs, distribution changes with specific business logic, in addition to data quality rules. So we can detect both unexpected behavioral changes in the data and also known business conditions that need to be enforced. So the practical difference, I would say, is that a pipeline can still complete successfully from- Hmm ...

an infrastructure perspective and still deliver incomplete, delayed, or incorrect data. And Actian Data Observability is focused on validating the reliability of the data moving through that pipeline and doing it early enough that teams can investigate and address the issues before they have a downstream impact. Great. Thanks, Scarlett. Mm-hmm. There's another one coming in. I think you touched on this a little bit.

I remember, obviously alerting and root cause analysis, but this specific question is around how does Actian actually help teams move from just alerting to the root cause analysis? That's another good question, and it frequently comes up when I talk to customers. The key is that Actian Data Observability is designed to give teams context behind an issue, not just tell them that a monitor turned red. So when anomaly is detected, teams can start with the monitor that triggered the alert and then look at the underlying profiling information, the historical behavior, to understand exactly what changed. Was there a sudden drop in record volumes? Did a particular attribute see an unexpected increase in nulls? Because Actian, again, has that Spark processing engine to profile the data, we can go deeper than simply just looking at pipeline execution logs.

And teams can investigate issues at the asset and attribute level using investigator to drill further into records contributing to the problem. And then If you need even more context, or maybe you're not that technical, you could leverage our data observability agent to help give you that guided root cause analysis experience. So I wouldn't position root cause analysis as the magic button that automatically tells you exactly who broke what. The real value is that Actian Data Observability is able to bring together anomaly detection, the context around the data through profiling, data investigation, and monitoring across the life cycle. And it gives teams the evidence they need to quickly move from something broke to here's what changed, where it changed, and which data is actually affected. That's great. Looks like we have two more questions.

Again, team, any other, please feel free to type them. We'll just address them live. This one's around business critical data initiatives and specifically how does Actian Data Observability support things like business critical data initiatives? Yeah. Really good question. So, what we really want to do is connect data observability to the initiatives that the business already cares about. So, let me take another example outside of KYC, and that would be insurance.

So in insurance, that could be underwriting, claims processing, pricing, regulatory reporting, or improving the customer experience. All of those processes depend on having accurate, complete, and timely data. So for example, just think about underwriting. A carrier may be combining policy information, claims history, customer data, property details, and third-risk party data to make a decision. And if one of those data sets is incomplete, delayed, or suddenly changes in an unexpected way, that can directly affect how risk is assessed and how a policy is priced. So Actian Data Observability helps teams keep a closer eye on the data behind those processes and identify issues before they turn into a business problem. So instead of discovering an issue because a premium was calculated incorrectly, or a claim was delayed, or a regulatory report had to be reworked, teams have an earlier indication that something in the underlying data needs attention.

So the value is really about helping the business operate with more confidence. And the data team can catch problems sooner, and the business has greater trust in data supporting critical decisions like, in the insurance case, pricing risk, paying claims, and serving customers. Great. Thank you. Mm-hmm. I have one more for you. Looks like this one's going to be around ERP migrations.

Specifically, can Actian Data Observability help with an ERP migration and potentially detect broken mappings? Yeah. So data observability, and this is true, I would say, of any observability solution, they're set up and designed to monitor data warehouses, databases, object storage, but not necessarily applications, and there's a whole host of reasons as to why that is the case. What I frequently see when there is an ERP migration is we look at generally where the data lands within an unstructured environment, such as object storage. So whether that be S3, whether that be Google Cloud Storage, whether that be Blob or somewhere else. Maybe you're moving it into a cloud warehouse like Databricks or Snowflake. We would start monitoring the data at that point.

And from there, I would say, oftentimes the profiling component of our platform is where a lot of customers that are going through migration efforts find immense value. Being able to do a full profile of structured, semi-structured, or unstructured data and just have a baseline understanding of what the truth is about your data. A lot of times they don't even have those tools put into place. And then from there you can identify what are your critical data elements and then move forward, you're bringing in good data into your new systems itself. So being able to leverage that, take advantage of that full profiling via our Spark processing engine with those efforts to really understand the reality of your data as a first step in a migration is really a key component, I would say, within those types of efforts. That's great. Thank you, Scarlet.

Yeah. And with that, those are the last questions that I currently see in our panel. Just to close out, thank you all for attending. I'll talk slow just in case there are any other questions. Just to let you know, this recording along with other materials will be sent out to both the participants and anybody who had registered. Again, any questions, please feel free to reach out to the team. We're here to support.

And with that, we appreciate the participation. Scarlet, great job today. Al, thanks for your support. Take care, everyone.