AI Trade Surveillance: What A Trading Firm's Dev Team Must Learn To Detect Spoofing And Layering On Streaming Order Data - With Alerts A Regulator Can Read

89% vs 11% - Banks that want AI-enhanced trade surveillance versus those that have it (1LoD 2026 Surveillance Benchmarking)  ·  ~70% - In proof-of-concept or partial deployment - and not one respondent calls AI surveillance fully embedded  ·  24 / 24 / 23% - The blocker is data: fragmented silos, no standard identifiers, inconsistent quality - almost evenly split  ·  Behaviour, not thresholds - Spoofing, layering, wash trading and momentum ignition are sequences static rules cannot see

Trade surveillance is the function inside every bank and trading firm that watches its own order flow for market abuse - spoofing, layering, wash trading, momentum ignition, quote stuffing, coordinated trading - because regulators require it and because a missed pattern is a fine, a ban and a headline. It is also, in 2026, one of the clearest examples of an industry that knows exactly what it wants from AI and cannot get there: according to 1LoD's 2026 Surveillance Benchmarking Survey, 89% of banks want AI-enhanced trade surveillance but only 11% have it; around 70% are in proof-of-concept or active but partial deployment, not a single respondent described AI as fully embedded, and 22% admitted their current infrastructure does not effectively manage market-abuse risk at all. Ask why and the answer is not the models. Banks split almost evenly across three data problems - fragmentation across silos at 24%, a lack of standardised formats and identifiers at 24%, and inconsistent or poor-quality data at 23% - because surveillance is a data-engineering problem before it is a machine-learning one. And the patterns that matter are behavioural sequences unfolding across thousands of order events per second, which the static thresholds legacy systems rely on simply cannot see. As a team that builds trading technology, we think surveillance is one of the most instructive pain points in financial engineering, and this playbook is a practical, code-side account of what a dev team must learn to build it properly.

Lesson One: Reconstruct The Order Lifecycle Before You Detect Anything

The first thing a dev team learns is that market abuse is visible only in the full life of an order, and most firms cannot see it. Spoofing is placing large orders you intend to cancel to move the price, then trading the other way; layering is the same with multiple price levels; both are patterns of submit, amend, cancel and fill across time - and a system that only sees executed trades, or only sees one venue, or cannot link a cancel to the order it cancels, is structurally blind to them. So the foundation is order-lifecycle reconstruction: ingesting the full stream of order events - new, amend, cancel, partial fill, fill, reject - from every venue and every internal system, and stitching them into one coherent lifecycle per order, with consistent identifiers that link the order to the trader, the account, the desk, the algorithm and the related orders across venues. This is exactly where the survey's three data problems live. Silos mean the events for one order are scattered across systems; missing standard identifiers mean the cancel cannot be joined to the new; poor quality means timestamps disagree and fields are blank. The engineering answer is a surveillance data platform: a canonical event model into which every source is translated, an identity layer that resolves traders, accounts and orders across systems, exchange-timestamp-ordered streaming with out-of-order handling, and quality gates that flag what cannot be trusted. Teams that try to bolt a model onto fragmented data get a proof-of-concept that never embeds - which is precisely the 70% - and teams that build the platform first discover that even rules work better once they can see the whole order.

Lesson Two: Engineer The Behavioural Features That Expose Manipulation

With reconstructed lifecycles, detection becomes a matter of computing the behavioural signals that distinguish manipulation from legitimate trading, and this is where a dev team's domain understanding is built into code. The features that matter are computed per trader, per instrument, per window over the streaming lifecycles: cancel-to-fill ratios and order-to-trade ratios that rise when someone is placing orders they never mean to execute; time-to-cancel distributions that expose orders pulled milliseconds after they moved the book; order-book imbalance contributed by a participant on one side just before they trade on the other, the signature of spoofing; layered resting orders at multiple levels away from the touch; rapid quote updates without trades for quote stuffing; matched or near-simultaneous opposite trades between related accounts for wash trading; and, critically, cross-venue linkage, because sophisticated abuse spreads the legs across venues precisely so that single-venue surveillance misses it. These features are computed incrementally on the stream - the same stateful-reducer discipline that powers a chart indicator engine - and stored with the lifecycle they describe, so that any alert can point back to the exact events and numbers that produced it. The lesson is that models are only as good as the features, and the features are only as good as the lifecycle data beneath them; a team that has done the first two lessons well finds the modelling comparatively straightforward.

• Reconstruct every order's lifecycle - new, amend, cancel, fill - across venues, with identifiers linking trader, account, desk, algorithm and related orders.
• Build the canonical event model and identity layer first - the surveillance data platform is the product; models come after.
• Compute behavioural features incrementally on the stream - cancel ratios, time-to-cancel, imbalance before trading, layering, cross-venue linkage.
• Layer detection - deterministic rules for known patterns, statistical baselines per trader and instrument, sequence models for the subtle cases.
• Attach evidence to every score - the events, features and thresholds behind an alert, so it can be explained and audited.

Lesson Three: Layer The Detection, And Make Every Alert Explainable

Detection in a serious surveillance system is layered rather than replaced by a single model. Deterministic rules encode the known patterns and the regulator's own definitions, and they stay because they are transparent and auditable. Statistical baselines learn what normal looks like for each trader and instrument - normal cancel ratios, normal order sizes, normal time-of-day behaviour - so that anomalies are judged against the participant's own history rather than a global threshold that is either too loose for a market-maker or too tight for a pension fund; this is where machine learning first pays, by cutting the false positives that drown compliance teams under fixed thresholds. Sequence models then handle the subtle cases - the spoofing pattern that never quite trips a rule, the coordination across accounts - by learning from the ordered event sequences themselves. But the layer that decides whether any of it is usable is explainability, and it is non-negotiable: an alert that says 'the model scored this 0.93' is worthless to a compliance analyst and unacceptable to a regulator, while an alert that says 'this trader placed three large bids at these levels at these times, cancelled all within 400 milliseconds of a 2-tick move, and sold 20,000 shares 1.2 seconds later - here are the events' is a case file. So every score must carry its evidence chain: the lifecycle events, the feature values, the baseline it deviated from and by how much, and for model-based scores the attributions that show which signals drove it - an approach the current research on transparent market-integrity scoring formalises. Alerts flow into a triage workflow with feedback: every analyst disposition is captured and used to tune thresholds and retrain baselines, so the system's precision improves rather than its backlog growing. Explainability is not a compliance ornament; it is what makes the difference between AI surveillance that embeds and AI surveillance that stays a proof-of-concept.

The Bottom Line

AI trade surveillance is a pain point the industry has measured precisely - 89% want it, 11% have it, 70% are stuck in pilots, 22% admit their infrastructure cannot manage market-abuse risk - and the cause is data before models: fragmented silos, missing identifiers and poor quality that leave systems blind to the order lifecycles in which spoofing, layering, wash trading and momentum ignition actually appear. What a dev team must learn is a discipline in three layers. Reconstruct every order's full lifecycle from streaming events across venues with consistent identifiers, on a surveillance data platform built before any model. Engineer the behavioural features - cancel and order-to-trade ratios, time-to-cancel, imbalance before trading, layering, cross-venue linkage - incrementally on the stream. And layer detection - transparent rules, per-participant statistical baselines that cut false positives, sequence models for the subtle cases - with every alert carrying an explainable evidence chain a compliance officer and a regulator can read, fed back through triage so precision improves. The work is mostly data engineering, then domain-encoded features, then modelling, judged entirely on explainability - and respecting that order is what moves a firm from the 70% in perpetual proof-of-concept to the 11% whose surveillance actually catches abuse. Building trading systems that are fast, correct and defensible to a regulator is exactly the engineering we specialise in.

References & Further Reading

• FinTech Global - banks want AI surveillance but lack the data to run it (1LoD 2026 Surveillance Benchmarking: 89% vs 11%, data blockers): https://fintech.global/2026/09/21/banks-want-ai-surveillance-but-lack-the-data-to-run-it/
• Global Relay - trade surveillance in financial services (70% in PoC or deployment, 22% infrastructure gap): https://www.globalrelay.com/resources/the-compliance-hub/compliance-insights/trade-surveillance-in-financial-services/
• LSEG - market surveillance in 2026: a Q&A on regulation, data and technology: https://www.lseg.com/en/insights/fx/market-surveillance-in-2026-a-q-and-a-with-lseg-experts-on-regulation-data-and-technology
• arXiv - an explainable market integrity monitoring system with multi-source attention signals and transparent scoring: https://arxiv.org/pdf/2601.15304
• Data Intellect - level up your surveillance: why shallow data isn't enough for spoofing detection: https://dataintellect.com/blog/level-up-your-surveillance-why-shallow-data-isnt-enough-for-spoofing-detection/