Trade Surveillance and Market Abuse Detection Software: How Do You Stop Real Cases Being Buried Under Alerts Nobody Reviews?

Why surveillance stacks fail quietly rather than loudly

Monday morning, the market abuse queue holds 1,840 alerts from Friday. Two analysts have the day. They will sort by score, work the top hundred, and mass close the rest with a reason code that says no further action. Nobody chose that outcome. It is what happens when a threshold based scenario fires on every large order near the close in a thin name, when the same event generates alerts in four scenarios, and when the queue has no memory of the fact that this trader was reviewed for the same pattern three times this quarter and cleared each time for the same reason.

The failure mode is not that the system missed a case. It is that the case was in the queue and was closed in eleven seconds alongside four hundred others. When that is later reconstructed by a regulator or by your own internal audit, the fact that an alert existed and was dismissed without meaningful review is worse than never having generated it. Surveillance programmes fail on review quality far more often than on detection coverage.

Nasdaq SMARTS, NICE Actimize, Eventus Validus, SteelEye and Behavox are all real platforms with real detection libraries, and the scenario coverage they ship represents years of regulatory pattern work you should not attempt to recreate. Where they run out of road is specificity. A vendor scenario sees orders and executions. It does not see that your desk runs a particular algorithm whose child order behaviour looks exactly like layering when the parent is being repriced, or that two of your legal entities route to the same venue through different memberships so the same beneficial owner appears as two participants. Those are the facts that separate a real case from a false positive, and they live inside your order management system, not in the market data.

Problem 1: the alert is not a case, and the tuning is not calibration

Threshold tuning as most firms practise it means raising a number until the queue is survivable. That is not calibration, it is capacity management, and it silently removes coverage in exactly the range where manipulation is economical. The reason firms do it is that they have no better lever, because the scenario ships as a black box with a handful of parameters.

What a custom layer adds is context that changes the meaning of the same event. The same aggressive order near the close is unremarkable from a client facilitation desk closing a hedge and highly interesting from a proprietary account that has been accumulating the underlying all week. Encoding your own account taxonomy, desk mandates, algorithm identifiers and parent to child order relationships lets you suppress structurally explainable behaviour without lowering coverage. In the surveillance builds we have delivered, this is where alert volume drops by a large multiple while the number of cases that reach a genuine investigation goes up, which is the only pair of numbers that matters.

Problem 2: you cannot replay the order book, so you cannot prove intent

Spoofing, layering and momentum ignition are all arguments about intent, and intent is only visible in sequence: what was displayed, what was cancelled, how quickly, what the trader did on the other side, and what the book looked like at each moment. Most firms hold executions well and order lifecycle poorly. Amendments and cancels are stored as separate records with no reliable parent linkage, timestamps come from three clocks with different granularity, and the venue's own message sequence was never retained.

A build that is worth the money starts here rather than with detection. Capture every order lifecycle message with venue timestamps preserved at their native precision, reconstruct the parent and child hierarchy including any algorithmic wrapping, and store it so that an analyst can replay a five minute window and watch what happened. Once replay exists, two things change. Investigations that took three days take an hour, because the evidence assembles itself. And detection improves, because scenarios can look at cancel to fill ratios and order duration distributions rather than at executions alone.

Problem 3: manipulation crosses venues and products, your monitoring does not

A trader who is careful does not do everything in one place. The pattern is set up in the equity, monetised in the option, or built through a related instrument in another currency, or worked across two venues where each individual footprint is unremarkable. Vendor deployments are commonly configured per asset class per venue because that is how firms bought them, so each silo sees a fragment and none sees the shape.

Fixing this is not primarily a detection problem, it is an identity and instrument problem. You need a single trader and beneficial owner identity that survives multiple entity memberships, and an instrument relationship graph that knows this option references that underlying, this depositary receipt references that foreign line, this future references that basket. Once those two things exist, cross product scenarios become straightforward to express. Without them, no amount of scenario sophistication helps, and this is exactly the layer that packaged tools expect you to supply.

Problem 4: the review record is the thing you will actually be examined on

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

A build should make the case the centre of the system rather than an afterthought. Every case carries the evidence snapshot as it was at review time, the analyst's reasoning against structured factors, 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 case narrative from the structured evidence the system already assembled, and flagging where a proposed disposition is inconsistent with how similar cases were closed. It suggests, a human decides, and the model never closes anything.

What this costs and how long it takes

A focused first release, meaning normalised capture of order and execution data from your order management systems and venues, full lifecycle reconstruction with replay, two or three firm specific scenarios and a proper case workflow, runs $110,000 to $240,000 and ships in 16 to 22 weeks. A full platform adding cross venue and cross product detection, identity resolution across entities, trader behaviour baselining, alert scoring, linkage to communications surveillance and regulator ready case export runs $300,000 to $850,000 phased across 10 to 18 months.

What drives price up specifically in surveillance: the number of order management systems and their message formats, since a firm running three OMS platforms plus a vendor algo container has four dialects of the same event; venue coverage, because each venue's drop copy or market data feed is its own ingestion project; asset class breadth, as fixed income and over the counter derivatives lack the clean order lifecycle equities have; historical replay depth, since holding several years of full order lifecycle data at native precision is a genuine storage and query engineering problem; and regulatory reporting obligations such as consolidated audit trail linkage, which is adjacent work with its own timeline.

What holds it down: picking the two or three scenarios where your business actually carries risk and building those properly, rather than reproducing a vendor library you already own.

Build versus buy, and when the vendor is the right answer

Buy 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. Eventus Validus and SteelEye in particular are pragmatic for firms of that size, deploy quickly, and carry scenario maintenance as regulations shift, which is real ongoing value.

Build, and in most cases build alongside rather than instead of, when two or more of these are true. Your analysts close more alerts than they can meaningfully review. You run in house algorithms whose normal behaviour is indistinguishable from manipulation patterns to a generic scenario. You operate multiple legal entities or memberships and the same person appears as several participants. Your investigations require manual data assembly from more than two systems. Or a regulator, an exchange or internal audit has questioned the quality of your alert dispositions.

Our position is that the detection library is the least differentiated part of a surveillance programme and the parts that decide outcomes are order lineage, identity resolution and case quality. Those three are firm specific by definition. Most firms should keep the vendor for coverage breadth and build the layer that makes the alerts mean something.

How to choose a developer for trade surveillance software

Ask them to model the order lifecycle on a whiteboard. You want to hear about new order, replace, cancel, partial fill, parent and child linkage, venue timestamp precision and clock reconciliation, unprompted. If the conversation starts at trades rather than orders, they have built a reporting system and cannot build surveillance.

Ask how they handle timestamp precision and sequencing across sources. Multi source event ordering at microsecond granularity is not an implementation detail here, it is the difference between a provable case and an anecdote.

Ask what they will do about historical replay volume. Storing years of full lifecycle messages so that an analyst can query a five minute window in seconds is an engineering decision that has to be made at the start, and retrofitting it is close to a rebuild.

Ask who owns the code, the scenario definitions and the cloud accounts, and get it in writing before kickoff. At Digital Heroes the client owns all of it from the first commit. Scenario logic is compliance policy expressed in code, and policy you cannot read, explain to a regulator or change without a vendor change request is not policy you control.