Trade Surveillance Software Problems: The 6 That Bury Real Cases, and How to Avoid Them

Why does the project get scoped as more scenarios rather than better context?

Because scenarios are countable and context is not. A compliance committee can approve a plan that lists twelve detection patterns. It cannot easily approve a plan whose main deliverable is that the same event means something different depending on which desk generated it. So the scope lands on detection breadth, which is the least differentiated part of a surveillance programme and the part your vendor already covers.

The failure is specific to this industry because the signals that separate a real case from noise are internal facts rather than market facts. A vendor scenario sees orders and executions. It does not see that your desk runs an algorithm whose child order behaviour looks exactly like layering when the parent is being repriced, that a client facilitation desk closing a hedge near the close is unremarkable while a proprietary account doing the same thing after accumulating all week is not, or that two of your legal entities route to the same venue through different memberships so one beneficial owner appears as two participants.

Scope the build around encoding those facts instead. Account taxonomy, desk mandates, algorithm identifiers and parent to child order lineage let you suppress structurally explainable behaviour with a recorded reason rather than by raising a threshold. Watch two numbers together: total alert volume and the count of cases reaching genuine investigation. Volume falling while investigations rise is the only pattern that means the programme improved. Volume falling alone means you removed coverage.

What goes wrong when you reconstruct historical order lifecycle data?

Most firms hold executions well and order lifecycle badly, and the discovery lands in week four rather than week one. Amendments and cancels sit as separate records with no reliable parent linkage. Timestamps come from three clocks with different granularity. The venue's own message sequence was never retained because nobody needed it for settlement.

This matters because spoofing, layering and momentum ignition are arguments about intent, and intent only appears in sequence: what was displayed, how quickly it was cancelled, what the trader did on the other side, and how the book looked at each moment. A history without lifecycle is a history you cannot investigate, only summarise.

Two things follow. First, audit what you actually hold before scoping detection. Pull one active trading day from each source and try to rebuild a single parent order with all its children, amendments and cancels. Whatever you cannot rebuild for that day, you cannot rebuild for any day. Second, accept that history may start at the build rather than reaching backwards. Firms that spend six months trying to reconstruct three years of lineage from settlement records usually produce something that looks complete and is not, which is more dangerous than an honest gap. Capture forward properly from day one, keep native venue timestamp precision, and treat the historic period as executions only with that limitation documented.

Why do the order management and venue feeds break after launch?

A firm running three order management platforms plus a vendor algorithm container has four dialects of the same event, and each dialect has its own release cycle. What breaks after launch is a message format change nobody told compliance about, because the change was made for the trading desk and the surveillance consumer was not on the distribution list. The symptom is not an error. It is a scenario that quietly stops firing for one desk.

Venue feeds fail differently. Each venue's drop copy or market data feed is its own ingestion project, and gaps appear during venue maintenance windows, connectivity events and reference data changes such as a symbol reassignment. A gap that goes unnoticed is worse than no data, because a cancel to fill ratio computed across a gap looks like a genuine result and gets reviewed as one.

Build completeness monitoring as a first class feature rather than an operational afterthought. Expected message counts per source per hour with alerting on deviation, sequence gap detection where the venue provides sequence numbers, and a daily reconciliation of orders captured against executions booked. Then put the surveillance team on the change notification list for every order management platform in the firm, which is a governance fix rather than an engineering one and is usually the one nobody does.

What happens when the case record and disposition consistency are not covered?

Whatever the detection quality, the artefact that gets examined is the case file. What fired, what the analyst looked at, what they concluded, who approved it, and whether similar dispositions were consistent across analysts and over time. In many firms that record is an alert status plus free text, and consistency is simply unmeasured.

The gap opens when the build treats the case as an output of detection rather than as the product. Detection improves, the queue gets shorter, and the review record is exactly as thin as it was, which means the examination that follows lands in the same place. Analysts also carry no memory: the same trader reviewed for the same pattern three times this quarter and cleared each time for the same reason looks like a first occurrence on the fourth alert.

Make the case central. Every case should carry the evidence snapshot as it stood at review time, structured reasoning factors rather than only prose, the escalation path, the approval, and links to prior cases involving the same trader or pattern. Disposition consistency then becomes something you can measure and challenge internally before someone else does. This is also the honest place for a language model: drafting the narrative from evidence the system already assembled and flagging a proposed disposition that is inconsistent with how similar cases were closed. It suggests, a person decides, and it never closes anything.

Should you build custom or configure what you already own?

Configure if you trade one asset class on one or two venues at moderate volume with a small number of desks, and your alert queue is genuinely reviewed rather than triaged. Nasdaq SMARTS, NICE Actimize, Eventus Validus, SteelEye and Behavox carry detection libraries representing years of regulatory pattern work you should not try to recreate, and scenario maintenance as rules shift is real ongoing value you would otherwise own yourself.

Configure first even when you intend to build, because a large share of the queues we are asked to look at have never had the parameters properly calibrated against the firm's own trading profile, and have no suppression rules for structurally explainable behaviour. That work costs a fraction of a build and sometimes ends the conversation.

Build alongside, rather than instead of, when analysts close more alerts than they can meaningfully review, when in house algorithms are indistinguishable from manipulation patterns to a generic scenario, when multiple entities or memberships make one person look like several participants, when investigations require manual assembly from more than two systems, or when a regulator, an exchange or internal audit has questioned your disposition quality. Our position is that the detection library is the commodity and order lineage, identity resolution and case quality are the parts that decide outcomes. Those three are firm specific by definition.

How do hidden costs get into the quote?

Historical replay volume is the line that hides the most. Storing years of full lifecycle messages so an analyst can query a five minute window from two years ago in seconds is an architectural decision made at the start, and retrofitting it is close to a rebuild. A quote that treats storage as a hosting line has not priced the query engineering.

The second is source count. Each order management platform, each venue drop copy and each algorithm container is its own ingestion with its own dialect, tests and monitoring. Ask for a per source figure and the assumed count, then check that count against a list your head of trading confirms rather than the one compliance currently believes.

The third is identity and instrument reference data. A single trader and beneficial owner identity surviving multiple entity memberships, plus an instrument relationship graph knowing which option references which underlying, is unglamorous work that cross product detection is impossible without. It is regularly absorbed into an integration line and regularly overruns.

The fourth is asset class breadth. Fixed income and over the counter derivatives lack the clean order lifecycle equities have, so a scope that says all asset classes is hiding a materially different problem behind the same phrase.

What separates a build that works from one that fails here?

Builds that work start at the order, not at the trade. If the first design conversation is about executions and profit and loss, you are getting a reporting system with alerts attached. Capture, lifecycle reconstruction and replay come before any scenario work, because once an analyst can replay a five minute window the investigations that took three days take an hour and the detection you write afterwards is better informed.

The second differentiator is that scenarios are treated as compliance policy expressed in code, which means they are readable, versioned, testable against known cases, and changeable by your team. A scenario nobody in compliance can read is a control you cannot evidence, and that is a governance failure regardless of how well it performs.

The third is measurement discipline from the first week live. Track alert volume, cases reaching investigation, median review time and disposition consistency together. A programme that only reports alert counts will optimise for a shorter queue, which is the failure mode you started with.

Finally, settle ownership before kickoff. You should own the repository, the scenario definitions and the cloud accounts. At Digital Heroes the client owns all of it from the first commit. Scenario logic is supervisory policy, and policy you cannot read, explain to a regulator or change without raising a vendor request is not policy you control.