Trade Surveillance Systems and Alert Tuning
A trade surveillance system's real engineering challenge isn't detecting suspicious patterns — it's tuning the alert thresholds so compliance staff drown in neither false positives nor missed cases, a balance every desk gets wrong in one direction before they get it right.
Prerequisites: What Counts as Market Abuse
Every broker-dealer and trading firm above a certain size runs an automated system that watches every order and every trade for patterns associated with market abuse — spoofing, wash trading, front-running, insider dealing timed suspiciously around news. Building the pattern-detection logic itself is the easy part; the pattern for spoofing (large orders placed and cancelled just before an opposite-side trade) is well documented and not hard to code. The actual, ongoing engineering problem is deciding how sensitive each rule should be, because a threshold set anywhere gets something wrong.
Two ways to get it wrong
| Threshold set | Result | Real cost |
|---|---|---|
| Too sensitive | Thousands of alerts, almost all false positives | Compliance staff burn out reviewing noise; real cases get lost in the pile |
| Too lax | Very few alerts | Genuine market abuse goes undetected; regulatory exams find the gap after the fact |
A surveillance rule that flags any order cancelled within one second of placement, for instance, will catch real spoofing — and also catch a huge fraction of ordinary market-making activity, where cancelling and replacing quotes in under a second is simply how the business works. Set the threshold to catch every spoofing pattern and a market-making desk trips it constantly. Set it to leave market-making alone and it misses a genuine spoofer who's slightly more patient.
There is no threshold that produces zero false positives and zero missed cases simultaneously — tightening one always loosens the other. Alert tuning is the explicit, ongoing act of choosing where on that trade-off a firm sits, not a one-time calibration that gets solved and forgotten.
What a tuning cycle actually looks like
Surveillance teams don't set thresholds once. A typical cycle: a rule fires alerts for a period, compliance analysts review a sample and label each as a genuine concern or a false positive, and the resulting hit rate feeds a decision to loosen or tighten the threshold, refine the rule's logic (adding exceptions for known market-making desks, for instance), or leave it unchanged. This is the same precision/recall trade-off that shows up in any classification problem — see The Confusion Matrix and Classification Metrics — applied to a domain where a missed positive can mean a regulatory finding, not just a bad model score.
| Step | What happens |
|---|---|
| Alert fires | Rule flags an order/trade pattern against its threshold |
| Analyst review | Compliance staff investigate: genuine concern, false positive, or needs escalation |
| Disposition logged | Every alert's outcome is recorded — required for regulators to audit the surveillance program itself |
| Threshold review | Periodically, the hit rate across a rule informs whether to retune it |
Why regulators care about the tuning process, not just the alerts
A firm cannot simply point to having a surveillance system and call the obligation satisfied. Regulators, in examinations, specifically probe whether alert thresholds are reviewed and justified — a system tuned so loosely that it never generates a real hit is treated as close to having no surveillance at all, because an unreviewed, permanently-lax threshold is functionally the same as looking away. The documentation trail showing why a threshold sits where it does, and what changed it over time, is itself part of what an exam checks.
It's tempting to treat "fewer false positives" as an unambiguous improvement to a surveillance system. It isn't, on its own — a rule tuned purely to minimize analyst workload, with no corresponding check on missed cases, is exactly the failure mode regulators look for. Alert volume going down needs to be explained by better rule logic, not just a higher threshold.
Further reading
- FINRA, Guidance on Trade Surveillance Program Effectiveness
- FCA, Market Watch — Surveillance Newsletter