Why Asset Managers Suddenly Need More Data

Trade surveillance is a clear case in point. The typical approach involves an automated system that flags trades when a counterparty or security appears on a restricted list, or when a trade pattern triggers a threshold rule. Every flag lands in a queue for a compliance analyst to clear or escalate.

Most rules-based automations flag false positives by design because they require human judgment from an analyst. You want someone to review the flag because missing a real violation has regulatory implications, and unnecessarily escalating a violation creates friction. Over time, that entire audit trail from trail to flag to final outcome generates data.

A naive view of applying AI to this workflow would entail feeding the entire alert history into a model. In theory, that approach would allow an AI agent to reason by example and quickly clear or escalate trades. It could either act on its own or queue up a batch of decisions for an analyst to validate. The more examples you have, the better the reasoning would become.

However, the raw volume of surveillance events is the wrong kind of “more.” To triage the queue, the agent has to know why an analyst cleared alert #4,812 last March. Having more examples doesn’t matter if the data show that they cleared it without capturing the full context for their decision.

What a governed dataset leaves out

Data governance and lineage establish the context. Alert queues and case histories live in a system built for audit trail and reporting. From intake to disposition, every action leaves a trail that an auditor can review and a regulator can inspect. You can clearly see who cleared what, when, and with what disposition code. On those criteria, these data pass cleanly.

Even with all of that, the record only takes you so far. Let’s say an alert connected Trade X to Restricted Entity Y through a shared parent company. Lineage might explain the parent-company link, but it won’t include the reasoning behind the disposition. It won’t show you that the analyst also received an email showing the trade was pre-cleared under an information barrier exception. Those additional checks happen outside the case management system, but they’re exactly what an agent needs to know to add value to the process.

This gap shows the kind of more that would be needed for the data to teach a model what to do. But the design of the case data also presents a challenge. They’re set up for analysts, auditors, and regulatory reports. And a warehouse tuned for access control and reporting accuracy means a different design target from one built for an agent to act on.

Factoring in implicit judgment

Analysts work by pattern recognition, not rote memorization of thresholds and restrictions. Drawing an analogy between an existing flag and a past event is central to managing cases. An alert fires because a trader's order pattern crosses a size or frequency threshold that looks like layering. An analyst clears it because they recognize this desk’s habitual quoting behavior around index-rebalancing days, a read on intent, not identity. This is judgment no lineage table could ever hold, because there’s no “link” to trace; it’s a pattern the analyst has seen enough times to trust.

That pattern sense, built across thousands of cases, is the judgment the whole workflow runs on, but no one ever wrote it down as a rule, so agents can’t access it.

A firm can provide that judgment to an agent in one of two ways. Developers can sit with the analyst and extract reasoning as explicit rules that the agent can apply. This approach is typically slow and never quite finished, as additional exceptions keep surfacing. Or the firm can train a model on years of disposition history and let it learn the pattern the analyst learned. While it’s faster, it’s also opaque and may include blind spots.

Then comes the input that no model can learn at any speed, the one that never entered the data at all. In the Acme case, the fact that would have cleared the alert, that the trade was pre-cleared under an information-barrier exception, sat in an email thread with legal. What an agent needs includes judgment stranded outside every system it can see.

Crossing team boundaries

Analysts don’t work in isolation. You often run into boundaries that have nothing to do with data quality. For example, the restricted list the surveillance team uses for triage usually belongs to another group, legal or risk. That group builds and maintains it elsewhere. The team clearing alerts against it doesn’t own it and might not even know the full rationale why a given name sits on it.

Such a list often reaches the workflow as a file someone refreshes by hand and emails over. Analysts might follow up by email or Slack to gather supplemental information. But those are precisely the source and context that AI would need to reason over. Making a workflow agent-ready layers an ownership question on top of the data question. If the trade surveillance team wants to build an agent connected to restriction lists, their success depends on who owns the feed and whether they’ll stand up a maintained pipeline instead of sending a monthly attachment.

First easy, then durable

No firm can make all its data context-rich and accessible to an agent at once. Where we typically start is where the return is largest, looking for workflows that burn the most analyst time on repetitive, low-judgment cases. Getting there means ensuring each record carries provenance, resolved identity, and the disposition logic an agent would need to clear a flagged trade.

Over time, this contextual data work becomes a durable advantage. The agent starts accumulating context that previous automation rules didn’t have, learning which entity matches across your systems are genuine hits and which are recurring false positives.

Realistically, however, it always remains a work in progress. Some of what your best analysts know stays in their heads and their inboxes, so agent-readiness data is a standard you keep raising rather than a box you clear.

The boundary between what you encode and what a model infers keeps shifting. Models continually get better at inferring context that you used to capture by hand. In that sense, the context worth encoding yourself narrows toward the cases that are genuinely yours, the ones turning on your entities, your history, and your analysts’ read on calls that were never obvious. You need more of that. Which judgment to encode now and which to leave for the models to reach is a call the tools can’t make for you.