Go Back
On-demand

Data You Can Defend: Operationalizing Trust at the Point of Ingestion

A webinar to watch—why defensible, transparent data ingestion is now a compliance priority for every regulated firm. 

Regulators and auditors are demanding proof that ingestion is complete and accurate. This webinar goes beyond theory into the real-world challenges of capturing and reconciling data across channels and vendors.  

You’ll see what good controls look like, how to build defensible pipelines, and where to start if you had to audit ingestion tomorrow. 

What you’ll learn: 

  • Why ingestion completeness has moved from a “day two” task to a top-tier compliance priority. 
  • The real-world challenges of capturing data across APIs, file-based feeds, and dynamic chat tools—and where most gaps emerge. 
  • What good ingestion controls look like: from baselines and manifests to dashboards, reconciliation, and remediation workflows. 
  • How to build stronger vendor partnerships and demand transparency without slowing down the business. 
  • Where to start if you had to audit your ingestion tomorrow—and what controls regulators expect to see.

“Completeness and reconciliation controls can’t be a day-two activity anymore. They’re as critical to compliance as detection itself.”—Daniel Ihrig, eDiscovery and Surveillance Architect, Macquarie

To see how defensible ingestion can strengthen your compliance program, schedule a conversation with our team. 

 

Speakers

Daniel Ihrig

Daniel Ihring

eDiscovery and Surveillance Architect, Macquarie

Therese Craparo

Partner, Reed Smith

Alex de Lucena

Head of Surveillance and Governance Strategy, Shield

Tom Rimmer

Tom Rimmer

Shield

  • Transcript

    Data You Can Defend: Operationalizing Trust at the Point of Ingestion

    Shield Insiders In-Focus
    Speakers

    • Alex de Lucena, Director of Product Strategy, Shield (Moderator)
    • Therese Craparo, Partner, Emerging Technologies & Data Group, Reed Smith
    • Tom Rimmer, Shield
    • Daniel Ihrig, eDiscovery & Surveillance Architect, Query

     

    Introduction

    Alex: Hello. Good afternoon, good morning, good day — wherever you are in the world, welcome to Data You Can Defend: Operationalizing Trust at the Point of Ingestion. My name is Alex DeLucena, Shield’s Director of Product Strategy. I always talk about how excited I am for these topics, but I’m particularly excited today because this is something I’ve been talking about so much for a while. Today we’ll cover why ingestion is the priority it is, the challenges, what good looks like, and partnership. We may have time for questions at the end, so put them in the chat. First, let’s have the panel introduce themselves — Therese, Tom, then Dan.
    Therese: Hi, everyone. I’m Therese Craparo. I’m a partner at Reed Smith in our emerging technologies, fintech, and data groups, and my focus is data risk management — everything from technology implementations to record keeping to data minimization, and everything in between.
    Tom: Hi, everyone. My name is Tom Rimmer. I’m part of the Shield team, really grateful to be here. I have the pleasure of working with a lot of our clients and prospects, and I’ve been involved in projects like this since the early 2000s, when it was slightly easier — it’s gotten harder and more complex over time.
    Daniel: Dan Ihrig. I’m an eDiscovery and surveillance architect at Query, and I’ve worked in this space since it became a space over twenty years ago. Since then, I’ve worked on projects at about forty different companies.

    Why Ingestion Rose to the Top

    Alex: We live in a curious moment. What I keep seeing and hearing is that the ability to foster accountability and transparency and build processes around ingestion has become equal in importance to the core capabilities financial institutions seek from archive and surveillance vendors. With surveillance, they care about detection, expanded risk coverage, fewer false alerts — but show me the numbers first. Let me know I can account for everything coming into the platform in order to trust those detections. They’re curious about AI, but again, let me get a hold of these numbers so I can be comfortable these modern tools are performing the way they should. My analogy: it’s as if in home buying, the inspection became equal to, and happened at the same time as, actually seeing the house. “I love the closet space, but can we talk about the foundation? We have enough rooms, but does the roof leak?” One driver is the fines over the last few years around off-channel comms and data integrity, but if we’re honest, those only serve to emphasize concerns people have been developing controls around for a while. Therese, from your seat advising firms, what’s changed that puts ingestion completeness at the top of the agenda?
    Therese: What’s changed is really technology and the way people communicate. The off-channel fines put a renewed focus on this area, but the reality is we’re not where we were twenty years ago. There are a huge number of ways people communicate — it’s not just the WhatsApp someone downloaded to their phone. There’s a communication feature in almost every application our clients use today, driven by collaboration — having communications within the tool you’re using to drive efficiency. So you’re seeing a huge increase in the types and channels of communication, and with that, a huge increase in complexity. This isn’t “I’ve got email and I know how that gets ingested, and Teams or chat or Skype, and I know how that’s ingested.” This is customization for every new type of chat that pops up in every application. So you have many more channels that need to be monitored for completeness and accuracy, and complexity in how they’re ingested, where one small thing can change and suddenly the pipeline breaks and you may not be ingesting everything. People realize they can’t monitor all the channels manually the way they could twenty years ago — there are too many points of failure, which requires more controls and scrutiny to make sure the ingestion pipelines aren’t breaking down.
    Alex: Not even twenty years ago — even five years ago there was a different level. Tom, what are you hearing in the field? What’s the balance between how these concerns are prioritized versus talked about?
    Tom: To add to Therese’s point, the variety. Different asset classes or departments use different tools, and they’re expanding. In fixed income and equities, maybe it’s Bloomberg; in commodities, it might be WhatsApp. We’re seeing tools like Salesforce being used, and emails that came from Salesforce seen as a record — how do you capture those? So the variety is expanding, and one of the major concerns straight away is how you’re going to capture them, and how you get assurances through the life cycle if there are changes to those data sources. It’s also about the outcomes. It used to be “how much data have you got, report on it.” Now it’s making sure that data got through to my surveillance suite — can I search on it? So there are more steps and more detail: can we show more visibility, where the data is in the life cycle, whether it’s had challenges, where it is in its remediation cycle? Clients want the assurance that their books and records aren’t missing, so downstream they can do their work.
    Alex: Dan, you’ve watched this shift. Therese and Tom touched on it — what else would you add?
    Daniel: Completeness and reconciliation controls are no longer considered a day-two activity. In the early days, we were just so happy to get journaling and Bloomberg data coming in, and we’d deal with issues later. Now there’s much more of a proactive expectation that this is watched closely, and that whatever process ensures completeness and reconciliation is part of the implementation of that channel onboarding. Archive and surveillance vendors are also expected — or preferred — to have more native connectors, so this is built into the process rather than tacked on: fewer hops, fewer points of failure, a single point of control and reporting, and more detail and granularity in the reconciliation.
    Therese: To build on Daniel’s point — from a legal and compliance perspective, there’s historically been a view that “it’s technology, so it works.” We battle that even with AI today, with users saying “just because it’s a computer doesn’t make it right.” There’s greater recognition, not just among the professionals but among the regulators, that it’s not enough to say “I have a technology and I assume it works.” There need to be controls to make sure it continues to work as expected, and an expectation of partnership between the technology professionals and the legal and compliance professionals to manage the technology properly, rather than just relying on the fact that it’s an automated process.
    Alex: One more I’d add: the starting point has changed. We see people trying to reconcile the numbers between when messages made it into an archive and when they made it into surveillance, even though they might be in completely different formats with different counts. So there’s complexity within the institution, not just the channels — what’s the source of truth, given the channel complexity and the way the tech has changed?

    The Messy Reality: Channel-by-Channel Challenges

    Alex: Let’s explore the messy real-world gaps. War stories welcome — no names needed. Dan, what makes it so hard for firms to know what’s what?
    Dan: One of the biggest challenges is there’s no standard across delivery methods and across all the vendors we need to capture communications from. Each channel has its own challenges. A channel may support reconciliation, but how far back in the process are you going, especially with multiple vendors involved? Take SMTP as an example — a lot of channels come in via SMTP, and that protocol doesn’t guarantee delivery; it’s highly reliable but not guaranteed. Even if a manifest of SMTP counts is passed through, you can verify you received x messages that day, but depending on the communication type, message counts don’t add up to interaction counts.
    Alex: What about channels that come in via an API?
    Daniel: That’s generally better, but vendors can make changes to APIs. Teams is an example — Microsoft can make a change, and now something is no longer captured, or you’re waiting on the vendor to update their code.
    Alex: Or the flip side: something new becomes available, and as a vendor we have to figure out whether to bring it in and whether it’s useful to customers. It can cut both ways. I remember when the ability to delete messages became available within Teams — do people actually want to see that, and how do we capture that something existed and was then deleted? Is it a record? What about our favorite, file-based channels — Bloomberg, Refinitiv, all our fin chats? What are the challenges there?
    Daniel: File delivery is pretty easy to track and alert on if something goes wrong. But you’ve got to trust that the source communication platform is delivering what it should — you have no visibility further back than that file. That file is the authoritative source you can check against.
    Alex: Tom, from your seat, how have you seen this break down?
    Tom: It’s that visibility. Some data sources don’t even give manifest files, so have you got all the data? I was recently speaking to someone on voice recordings — they were getting recordings from the supplier, but one of their regions had an issue and stopped. All they saw was the volume drop, so the only way they could tell there was an issue was looking at metrics and trends, which isn’t something people traditionally did. The legacy approach is “is the channel working, because I’m receiving something?” — and people understand that’s not good enough.
    Alex: Often when you have older controls, you have a de facto tracking that’s some SME — a person or team just watching, who knows you get roughly this many Bloomberg messages a day, that Sunday is less than Tuesday. You’ve backed yourself into a human control that relies on someone sticking their finger in the air to check where the wind’s coming from when they see a drop, which creates a reactive process where you’re constantly looking back.

    Balancing Risk and Business

    Alex: Therese, anything else from the challenges perspective — what makes this hard?
    Therese: One of the hardest things is balancing the risks. We’d all like to think there’s 100% absolute compliance and no risk decisions, but the reality is there are so many. Our clients are analyzing every new channel and saying, “If this has to be captured, what does that mean? Is the vendor willing to work with me on a capture mechanism?” Some are — “I serve financial services, you tell me it needs to be captured, we’ll do the development.” Some say, “I’m not going to invest in that unless I have a critical mass.” Legal and compliance don’t want to say no to a business-critical application, so you’re trying to find a way to make it work: is there a side method that isn’t great, but at least it goes to the archive and someone can surveil it? Or can I argue these communications are outside the regulations? Broker-dealers have a very broad definition of communications; CFTC, MiFID, or investment advisers are a bit more circumscribed. And what if usage changes — how am I monitoring that? So there’s more focus on what’s “good enough” to get it into the archive, where I can make defensible risk decisions.
    Alex: A quick side comment: on upstream providers not wanting to provide capture, it can sound malicious — why wouldn’t they? But take Meta, with two or three billion WhatsApp users; their core use case isn’t banking compliance, so it doesn’t matter as much to their bottom line as it might for a different channel. That’s what makes these gaps so hard to bridge. Now — are there any rules of thumb for risk-based decisions? Say three traders use a tool only to communicate with one counterparty, and the volume is impossible to baseline. What’s the rule of thumb for those edge cases?
    Therese: I wish it were that easy, but it’s not, because any risk-based decision has too many variables — it depends on the institution and the level of risk. If you have three traders engaging in communications required to be retained under the regulations, you have to capture and retain them. A company could choose not to because the odds of getting caught are low — but that is not what we’re advocating for. Where you often end up, instead of saying “I’m not going to comply” or “you can’t use it,” is asking, “What can I do that’s close enough?” Maybe I can’t build an API to ingest those three people’s messages, but I get a report every week emailed into the archive and designated for surveillance. It’s not perfect, but the most important thing is making a reasoned, intelligent decision with input from legal, the business, and compliance — one that says this isn’t a perfect methodology, but it’s reasonable and compliant, and I can explain why. It’s less about being compliant or not, and more about the best option that’s good enough for compliance.
    Alex: And for something like Outlook or Bloomberg, there’s very little wiggle room?
    Therese: Absolutely, because mechanisms already exist for capturing that and the volume is so high. When you’re risk-balancing, you’re not going to accept a manual mechanism for email — the volume is too high and there’s more risk than for something smaller-volume or lower-risk.

    What Good Looks Like

    Alex: Tom, Dan, and I were teasing out a framework for what good looks like that covers: did we get the data, did it make it into the archive, and did we get the data we should have? Tom, are those all the steps?
    Tom: From the onboarding process, it’s also looking at the end game — what do you want to achieve for discovery? One example we talked about is population: if I’m searching for everything for Tom Rimmer, am I going to identify everything? Or do I need naming conventions? Some data sources might list me as “Trimmer” rather than “Tom Rimmer,” so if I search “Tom Rimmer,” “Trimmer” won’t come up and I’ll miss a whole chunk of data. So understanding users, who they’re associated with, departments — a key focus is going through and testing the use cases as you onboard channels, knowing that end game.
    Alex: I’d add more steps to “can we search for it”: did we transform it, did we alert on it, and if it’s missing, can we find it? Dan, what does good look like — the starting point?
    Daniel: We have three basic levels of checks. The first is: did we get data for the channel? A baseline verification that a process ran, data was processed from an upstream system, and it was received — preferably with automation, alerts from ingestion or data-transfer systems, though some may require manual checks.
    Alex: How do you manage the differentiation across detail — an SMTP provider that gives a detailed manifest versus one that gives barely any?
    Daniel: It’s a question of whether the upstream provider has such a thing, in what format, and whether the ingesting system knows what to do with it. If it’s just a message count, that’s a good first step, but there’s more expectation of granularity — something with actual message IDs that can be tracked within the receiving system. After that, the next level: did the data get into the archive? Ideally an automated search of the actual repository, ensuring it made it through the pipeline, is indexed, and is available for eDiscovery and surveillance. The challenge is potential processing the pipeline does — for example, dedupe. Instead of 400 messages from a channel that day, you’ll show 385 — is that a problem, or did it do what it should?
    Alex: We want it to dedupe — someone sends a message to five hundred people, it’s the same message, so we bring down storage and have a single source of truth. But we also have failed messages and failed attachments. So how do we balance that initial number the upstream vendor gives — “here’s 500” — against the next number, 423? How do we get comfortable with that delta?
    Daniel: We’d all love statistical analysis and automation around this, but depending on the channel, there’s a human monitoring factor — those admins who get a sense for trends and raise something. A next generation of more automated statistical analysis would be really helpful.
    Tom: There’s maturing here. It used to be a black box — did it make it or not? Now you’re seeing where, as messages come through, you can identify what the issue may be, bucket it for remediation, and see whether it can be repaired and put back through. You can see where the counts are: I had 500, 423 went into the archive, where are the other objects, can I tie them to where they failed, can I replay the ones we couldn’t process back to the client? So you’re following that life cycle, rather than “I’ve got 423, don’t know where the others are” and a cycle of going back and forth.
    Therese: Thank you for saying “help the clients through that process.” When my clients are asking, “How can I be comfortable I have reasonable processes to make sure ingestion is complete and accurate?” — part of it is you only know what you know. Volume counts are one way; trends over time are another; if you can get reporting on errors, you should. From a Shield or any vendor perspective, you see more than our clients see, and I expect my vendors to act as a partner — a service provider, not just a technology provider. If you see something happening with a common channel or know of an error, surface it so it can be handled. That may seem obvious, but it’s not. I once had a vendor who, after a client found a material error in ingestion that the vendor knew about, said, “Why would I ever tell you if I knew there was a problem with my system?” We almost had a fit, because that’s your obligation. Things will go wrong; we want to find and fix them. If there’s an industry issue across a common channel, raise it — you don’t have to name clients, but say “this is an issue with this type of data, you may want to look at it.” That partnership helps with compliance and helps the client get comfortable that we’re working together toward it.
    Tom: Another example is orphaned objects — a client gives us an HR file of monitored users, that process breaks down, and suddenly we’re seeing volumes of orphaned objects. It’s a partnership to say, “Look, guys, this is where it’s growing, these are the orphaned ones, let’s get the HR file correct, then re-ingest and remediate.”
    Alex: Stepping back — as banks moved into the cloud, they’ve gone from having a tech team they know, where they can pick up the phone and work something out, to a vendor managing that data with them. But it’s still their data they’re responsible for. So the onus is on vendors — and I think vendors have been slow to appreciate this, because they’re not the ones getting fined — to have the same level of attention and know-how across those flows. What we try to do is visualize and make transparent all the errors, failed messages, everything that came in, what we deduped, what we replayed, and monitor on the back end for trends. The financial institution typically has its own validated controls on top of that. So we’re getting to a better place where vendors are more transparent and provide more tooling, and customers are more mature about their needs.

    The Hardest Channels to Monitor

    Alex: A question came in: what comms channels are hardest to monitor for completeness and accuracy?
    Daniel: Some of the most challenging are the ones that require end users to register or enroll, because it requires action on the user’s part — and the intermittent ones, where you might have twenty or thirty messages on a chat channel Friday and none until the next Wednesday. There’s no technical challenge reconciling Office 365 — you’ve got the tracking logs — or systems that deliver via file. Those should be the baseline. The ones still more of a challenge are social media and SMS-type channels that are more consumer-based.
    Therese: I’d add channels requiring transformation — whiteboarding, real-time whiteboards. The way you manipulate that to get it into the archive, there’s not a one-to-one. Or an internal chat that sends comments by email, where the capture mechanism is email but there’s not a one-to-one from the original communication. So there isn’t a great mechanism to automatically reconcile those — you can make sure it’s coming in, but the one-to-one correlation is much more challenging than an email out of Microsoft.
    Alex: And not everyone wants to capture whiteboards the same way — because it’s a live thing, someone might decide their internal disposition is whatever’s left at the end, and someone else might want to see how it progressed, or even want it as a video. These are edge cases, but they come up all the time.

    Reports, Dashboards, and Know Your Channels

    Alex: Anything else on what good controls look like before we move on?
    Therese: This can feel overwhelming given the volume of channels, but from a compliance and legal perspective: one, know your channels. That sounds silly, but it’s not just email, Teams, and Bloomberg — know all the channels going into your archive, and know your controls for them. Work with your tech teams: what are we doing, are we monitoring volumes, trends, do we sample periodically to make sure nothing’s changed? It may not be the same for every channel — it’s about the reasonable process you can do. Know what it is so you can explain it if questioned. I tell every client: I can defend a process. Mistakes will happen, but I can defend “we had a procedure, we followed it, this happened, and when we caught it, we fixed it.” That’s much easier to defend to a regulator than “I assumed IT would do it, and their controls failed.” The one-offs and the lack of a process are much harder to explain than “I had a process and an error occurred.”
    Alex: We’re also talking about a world of reports and dashboards that account for all this — we’ve built them into our platform, and firms build their own, with assumptions baked in about how the data comes in, the differences across modalities, what details are needed for an appropriate count, and how to reconcile. And it doesn’t end with the report — how do we reconcile the data, what’s the process to automatically replay, and to automate searches that look for that data to make sure it’s appropriately indexed even if it doesn’t match an individual on an HR file?
    Tom: To add to that, one of the big questions from prospects is flexibility in those reports. Long gone is the day of one style of report. Management and execs are asking for much more detail, so flexibility matters — can they query with APIs, build their own dashboards, can we deliver more flexible dashboards? A lot of standard reports are aged and don’t have the level of detail they want.
    Daniel: At a minimum, there should be a daily report across all channels, or a live dashboard, showing daily archive volumes per channel with some historical volumes graphed. That’s the baseline; building automation and historical analysis on top would be great. When you need to replay something, it’s a lot easier to do it that same day than three months later.

    AI and an Agentic Future

    Alex: Let’s talk about AI — because we can’t have a webinar without it, but also because there’s unexplored potential here. How far are we from an agentic approach that takes in and understands flows and anomalies across channels, can go fetch a missing message, and sees these processes through, notifying us if something’s off? Dan, Therese — how far away are we?
    Daniel: I’d put that question to the vendors.
    Alex: I’ll take it — and put it back to you, because at least Shield as a vendor is ready. The tools are there, and it’s not just the tools; it’s the controls we build around them to help end users become comfortable with the conclusions those agents make on your behalf. What I haven’t seen yet, given the amount of heat around ingestion and reconciliation, is someone saying, “Let’s let AI figure it out” — even though it might do a better day-to-day job than the process in place. That’s my hot take.
    Therese: We’re seeing, even in the financial industry, a huge uptake in agentic AI and the deployment of digital workers for certain tasks, so I don’t think the industry is opposed. But I don’t know that the first place an organization is going to invest in agentic AI is monitoring archive ingestion — they’re using it in other places where they might see more bang for their buck. One challenge with AI generally is someone saying, “Here’s this AI tool, it does stuff, just don’t ask me how” — which legal and compliance will always be concerned about: how does it work, why can I rely on it, what’s the process ensuring it’s being trained properly? So my clients would be interested if there were a tool they could get their hands around, but I don’t know how willing they are to invest in developing that specific agentic AI right now.
    Daniel: A lot of customers moving to SaaS like the idea of the vendor handling more of the daily nuts and bolts of basic channel monitoring, but they want a trust-but-verify approach. If something didn’t go right, the vendor fixes it and notifies the customer, but unless it’s something they need to act on, the vendor just handles it. They still want visibility, because ultimately they’re the ones accountable to the regulators for archiving and surveilling their data.

    Closing Takeaways

    Alex: We’re almost at time. Tom, any last points?
    Tom: There’s always been focus on making sure we’ve got the books and records, but the level of detail, the level of controls, and the level of trust in your vendor to deliver that information and partner has never been higher. Creating that partnership and trust is number one for us. We recognize the variety and complexity, and we’re learning all the time. Nothing’s ever going to be perfect, but as long as we work together with reasonableness across the whole process, there’s a lot more vendors can do to improve it.
    Alex: Dan, any last thoughts?
    Daniel: No, I’m good — you summed it up right before.
    Alex: Therese, over to you.
    Therese: The regulators have been focused on the changing technology space and its impact on compliance. These things usually have a long tail before we see enforcement actions, but don’t bury your head in the sand about the challenges the variety of communication and collaboration tools create for monitoring and ingestion. Get ahead of it now, understand it, and be ready — because while we might not see active enforcement in the next few years, you will see it. Off-channel communications percolated for many years before we saw enforcement actions like we hadn’t seen before. So stay on top of it, understand it now, and start putting your compliance mechanisms in place so you’re not playing catch-up later.
    Alex: And the last thing I’d add: the possible is possible. The tools are there, vendors are building them for their customers, and there are institutions that have put together great controls. Awesome discussion — this has been Data You Can Defend: Operationalizing Trust at the Point of Ingestion. Thank you, Therese, Dan, Tom, and everyone out there. Have a great day.

Q&A

Why does data ingestion suddenly matter as much as detection?

Because you can’t trust your surveillance until you can prove what went into it. Firms still want better detection, wider risk coverage, and fewer false alerts — but they now ask to see the numbers first, so they can account for everything reaching the platform. The off-channel fines of recent years didn’t create this concern so much as expose it: ingestion controls have become equal in importance to the core capabilities.

Isn’t data arriving proof that our capture is working?

No — “something is coming in” is the legacy test, and it’s not good enough. SMTP delivery isn’t guaranteed, APIs can silently break when a vendor like Microsoft changes something, and message counts don’t equal interaction counts. In one case, a firm only noticed a whole region’s voice recordings had stopped because the volume dropped. Completeness has to be monitored through metrics and trends, not the mere presence of data.

Which communication channels are the hardest to capture completely?

The toughest are channels that require users to enroll or register (capture depends on a human action), intermittent channels that might go quiet for days, and consumer-style social media and SMS. Anything needing transformation — real-time whiteboards, or internal chats captured as emails — rarely reconciles one-to-one. By contrast, Office 365, with its tracking logs, and file-based feeds like Bloomberg should be your reliable baseline.

What does “good” ingestion control actually look like?

The panel framed it as three checks: did we get data for the channel, did it land in the archive, and did we get the data we should have — extended by “did we transform it, alert on it, and can we find what’s missing.” At a minimum, you want a daily report or live dashboard of archive volumes per channel, with historical volumes graphed so anomalies stand out.

The counts don’t match between the source and the archive — is that a problem?

Not necessarily. Some of the delta is intentional: deduplication collapses a message sent to five hundred people into one source of truth. The rest may be failed messages or attachments. What matters is visibility — reporting on errors and what they are, the deduplication rate, and a remediation path to identify, repair, and replay whatever failed, ideally the same day rather than months later.

What should we expect from our archiving or surveillance vendor?

Treat them as a service partner, not just a technology provider. Because vendors see across many clients, they should proactively surface known errors — including industry-wide channel issues — rather than wait to be caught out. Expect transparency into failures, deduped items, and replays, plus a trust-but-verify model. As banks move to the cloud, the vendor manages the data, but you remain accountable to the regulators for it.

A channel is required, but the vendor won’t build capture — what do we do?

Make a reasoned, defensible risk-based decision rather than banning the tool or ignoring the rule. If you can’t get a real-time API, a “good enough” mechanism — say, a weekly report emailed into the archive and flagged for surveillance — can be reasonable and compliant. The key is documenting an intelligent process you can explain to a regulator, because a defensible process beats an unexplained one-off every time.

Can AI just handle ingestion monitoring for us?

The tools for an agentic approach largely exist — understanding flows, spotting anomalies, fetching missing messages — but adoption is early, and firms tend to invest their first agentic AI elsewhere. Expect a trust-but-verify model with strong controls around the conclusions an agent reaches on your behalf. And remember: however it’s automated, you stay accountable to regulators for the completeness of your records.