Trade surveillance, also referred to as market surveillance or trade monitoring, is the systematic monitoring of order and execution activity across a firm’s trading flow to detect patterns associated with market abuse — such as spoofing, layering, wash trading, front running and insider dealing — and to escalate confirmed or suspected instances for investigation.
Executive Summary
What: Trade surveillance programs combine order and execution capture, data normalization, pattern detection and case management to identify conduct that regulators classify as market abuse, most commonly under the EU Market Abuse Regulation (MAR, Regulation (EU) No 596/2014) and, in the United States, under FINRA Rule 3110 and related anti-manipulation provisions extended to derivatives markets by the Dodd-Frank Act.
How: a surveillance system ingests order and execution data across venues and asset classes, normalizes it into a common timeline, runs detection logic against known abuse typologies, and routes anomalies to compliance analysts for review.
Who: sell-side broker-dealers, buy-side asset managers and hedge funds, and trading venues each carry some form of surveillance obligation, though the legal basis, scope and detection depth differ by participant type and jurisdiction.
Understanding Trade Surveillance: The Market Abuse Patterns It Targets
Trade surveillance is defined by the conduct it is built to catch. Regulators group that conduct into a handful of recurring patterns, and a surveillance program’s detection library is typically organized around them.
Spoofing and Layering
Spoofing is the practice of placing one or more orders with no genuine intention of letting them execute, to create a false impression of supply or demand and induce other participants to trade at a more favorable price, before canceling the orders. Layering is a related pattern where multiple orders are placed at different price levels on one side of the book to create a misleading picture of depth, while the trader executes on the opposite side. Both fall within the market manipulation limb of MAR and within the anti-spoofing provisions applied to derivatives markets in the United States.
Wash Trading
Wash trading occurs when a party trades with itself, directly or through related accounts, without any genuine change in beneficial ownership or market risk. The purpose is typically to inflate reported volume or create a misleading impression of price and liquidity to other market participants.
Front Running
Front running is trading ahead of a client order, a firm’s own pending order, or other market-moving information not yet available to the market, to benefit from the price movement that the subsequent order or information release is expected to cause.
Insider Dealing
Insider dealing is trading, or recommending or inducing another party to trade, on the basis of inside information — meaning precise information not yet made public that would be likely to have a significant effect on the price of a financial instrument if it were. MAR defines the concept in detail and prohibits both the dealing itself and the unlawful disclosure of the underlying information.
Who Is Required to Run Trade Surveillance?
Sell-side broker-dealers, trading venues and, increasingly, buy-side asset managers and hedge funds are all expected to maintain some form of trade surveillance, though the legal basis differs. In the European Union, MAR requires operators of trading venues and firms that arrange or execute transactions to have arrangements in place to detect and report suspicious orders and transactions, typically through a Suspicious Transaction and Order Report (STOR). The MiFID II/MiFIR framework adds a record-keeping layer: investment firms must retain order data and make it available to competent authorities under Article 25 of MiFIR and Commission Delegated Regulation (EU) 2017/565, with trading venue operators subject to the parallel requirement detailed in Commission Delegated Regulation (EU) 2017/580 (RTS 24), while transaction reports to regulators follow the format set out in Commission Delegated Regulation (EU) 2017/590 (RTS 22), adopted under Article 26 of MiFIR. In the United States, FINRA Rule 3110 requires member firms to maintain a supervisory system that includes surveillance of trading activity, and Dodd-Frank Act provisions extended anti-manipulation and anti-spoofing authority to derivatives markets regulated by the CFTC. Buy-side firms without a direct venue-facing obligation are increasingly building or buying surveillance capability regardless, both as a governance expectation from institutional clients and as a defense against being implicated in a counterparty’s misconduct.
How Does a Trade Surveillance System Work?
A trade surveillance system is built around four functional stages: it captures order and execution data, normalizes that data into a consistent structure, applies detection logic against known abuse typologies, and routes the resulting alerts into a case management workflow for human review.
Order and Execution Data Capture
The first stage captures the full order lifecycle: new orders, amendments, cancellations and fills, along with parent-to-child order relationships, routing decisions and precise timestamps, across every venue and asset class the firm trades. Gaps here are the most common reason a surveillance program misses a pattern, since a spoofing or layering scenario is only visible if the cancellations and the opposite-side fills are both captured and linked.
Data Normalization
Because venues and asset classes report activity in different formats, timestamp conventions and identifiers, raw order and execution data has to be normalized into a common event model before detection logic can run reliably across the full trading book. This normalization layer is the part of the surveillance stack most exposed to data-quality risk, and it is covered in more depth in our article on upstream data normalization for trade surveillance.
Pattern Detection and Alert Generation
Detection logic compares normalized activity against known abuse typologies using a mix of static thresholds (for example, a cancellation rate above a set percentage within a time window), statistical baselines that flag deviation from a trader’s or instrument’s normal behavior, and, in more mature deployments, machine-learning models trained to score sequences of orders for spoofing- or layering-like patterns. Each method has a different false-positive profile, and most production systems combine more than one.
Alert Triage and Case Management
Alerts generated by the detection layer are routed to compliance analysts through a case management workflow, where each alert is reviewed, annotated, escalated for filing (such as a STOR) or dismissed as a false positive, and archived with a full audit trail of the decision. This stage is where most of the analyst workload sits, and where alert volume, not detection sophistication, tends to be the binding constraint on a surveillance program.
Trade Surveillance vs Best Execution Monitoring vs Pre-Trade Risk Controls: Comparison Table
| Dimension | Trade Surveillance | Best Execution Monitoring | Pre-Trade Risk Controls |
|---|---|---|---|
| Objective | Detect market abuse patterns (spoofing, layering, wash trading, front running, insider dealing) | Evidence that execution quality met the firm’s best-execution obligation | Prevent an order from entering the market if it breaches a defined risk limit |
| Timing | Primarily post-trade, over minutes to months, sometimes with near-real-time alerting | Post-trade, typically on a periodic (daily, monthly) review cycle | Pre-trade, before the order reaches the market, in milliseconds |
| Primary regulatory basis | MAR (Regulation (EU) No 596/2014); FINRA Rule 3110; Dodd-Frank anti-manipulation provisions | MiFID II best-execution requirements; FINRA Rule 5310 in the US | Regulatory expectations for algorithmic trading controls under MiFID II, SEC Rule 15c3-5 (Market Access Rule) and CFTC risk-control rules |
| Data used | Full order and execution history across venues, including cancellations and amendments | Execution prices and timestamps benchmarked against a reference (VWAP, Arrival Price, quoted spread) | Order size, price, notional exposure and account/position limits, evaluated at order entry |
| Typical output | Alerts, investigation cases, Suspicious Transaction and Order Reports | Execution quality reports and Transaction Cost Analysis (TCA) benchmarks | Order rejection, throttling or a hard block before submission |
| Primary owner | Compliance / market abuse surveillance team | Trading desk and best-execution committee | Trading desk and risk management |
How Does Trade Surveillance Differ from Best Execution Monitoring?
Trade surveillance asks whether a pattern of order and trade activity looks like market abuse; best execution monitoring asks whether a client’s or the firm’s own order was executed on terms consistent with the firm’s execution policy. The two draw on overlapping data (order and execution records) but answer different questions and sit under different regulatory frameworks; our article on best execution requirements in institutional trading covers that obligation in detail. A single order can pass best-execution review and still trigger a surveillance alert, for example if it was executed at a good price but as part of a layering sequence; conversely, an order can be flagged as a poor execution outcome with no surveillance implication at all.
When Does Trade Surveillance Fall Short?
Trade surveillance is not a guarantee that abuse will be caught, and every deployment has known limitations:
- Data fragmentation: if order and execution data from a venue, asset class or affiliated entity does not reach the surveillance system, or arrives with inconsistent timestamps or identifiers, the pattern built on that data will be incomplete.
- Alert volume and false positives: threshold-based detection tends to generate a high rate of false positives, which can bury genuine alerts under review backlog if case management capacity has not scaled with alert volume.
- Cross-venue and cross-instrument blind spots: a manipulative sequence spread across correlated instruments or multiple venues can evade detection logic built around a single instrument or a single venue’s data.
- Model drift: statistical and machine-learning detection models trained on historical behavior can lose accuracy as market structure, participant behavior or instrument liquidity changes, and require periodic retraining and validation.
- Detection lag: post-trade surveillance, by design, identifies patterns after execution; it is a detective control, not a preventive one, and is complementary to, not a substitute for, pre-trade risk controls.
Important: None of this constitutes compliance advice or a promise of outcome; the design, calibration and operation of a surveillance program remain the responsibility of the firm and its compliance function, and results depend on the completeness of the underlying data and the specific detection logic deployed.
How Quod Supports Trade Surveillance Programs
Quod Financial is not a dedicated trade surveillance vendor, and this article should not be read as a description of a Quod surveillance detection product. What Quod’s platform does provide is the upstream layer that surveillance and record-keeping obligations depend on: a complete, timestamped and normalized audit trail of every order decision made inside the trading workflow.
Because algorithm selection, parent-to-child order splits, routing decisions and risk checks all run inside the same environment across Quod’s Order Management System (OMS), Execution Management System (EMS), Smart Order Routing (SOR) and Algorithmic Trading modules, the resulting order and execution history is captured in one auditable workflow rather than reconstructed after the fact from disconnected systems. That structure supports order record-keeping obligations under Article 25 of MiFIR, detailed for investment firms in Commission Delegated Regulation (EU) 2017/565 and for trading venue operators in RTS 24, and gives downstream surveillance systems — whether run in-house or by a third-party vendor — cleaner, better-linked input data to work with.
The Quod Unity architecture extends the same principle across a firm’s existing systems, integrating with legacy infrastructure without a rip-and-replace migration, so surveillance-relevant data does not depend on every desk having moved onto a single platform. For a closer look at how data quality upstream of detection logic affects surveillance outcomes, see our article on upstream data normalization for trade surveillance.
Feed Your Surveillance Program a Unified OMS/EMS Audit Trail
To see how a unified OMS/EMS audit trail can feed your firm’s trade surveillance and record-keeping obligations, request a demo, download the product brochure, or contact the Quod Financial team directly.
Frequently Asked Questions
What is the difference between trade surveillance and market surveillance?
Trade surveillance typically refers to a firm’s own internal monitoring of its order and execution activity. Market surveillance is a broader term that also covers monitoring performed by trading venues and regulators across all participants in a market, not just one firm’s flow.
What is a Suspicious Transaction and Order Report (STOR)?
A Suspicious Transaction and Order Report is the mechanism under MAR through which firms and trading venues notify their national competent authority of an order or transaction they reasonably suspect may constitute market abuse, including attempted manipulation that was never executed.
Does trade surveillance apply to buy-side firms?
Buy-side firms do not always carry the same venue-facing surveillance obligations as sell-side broker-dealers or trading venues, but many run surveillance programs regardless, driven by client governance expectations, internal risk management, and the exposure created if a counterparty’s misconduct implicates the firm’s own order flow.
What data does a trade surveillance system need?
At minimum, a surveillance system needs the full order lifecycle (new, amend, cancel, fill), parent-to-child order relationships, routing and venue information, and precise timestamps across every venue and asset class in scope, normalized into a consistent format so cross-venue and cross-instrument patterns can be detected.
Is trade surveillance mandatory under MiFID II?
MiFID II and MAR together create the obligation in the European Union: MAR requires arrangements to detect and report suspicious orders and transactions, while the MiFID II/MiFIR framework’s order record-keeping requirements (Article 25 of MiFIR, with RTS 24 covering trading venue operators) and transaction reporting requirements under RTS 22 supply the data trail that surveillance and regulatory oversight depend on.
What is the difference between rules-based and machine-learning-based surveillance?
Rules-based surveillance flags activity that breaches a defined, static threshold, such as a cancellation rate above a set percentage. Machine-learning-based surveillance scores activity against patterns learned from historical data and can adapt to more subtle or evolving typologies, at the cost of requiring ongoing model validation and being harder to explain to a regulator than a fixed rule.
Can a trading platform replace a dedicated trade surveillance system?
No. A trading platform such as an OMS or EMS captures and structures the order and execution data that a surveillance system needs, but detection logic, alert triage and case management for market abuse are a distinct function, typically run on a purpose-built surveillance system or by a specialized vendor.
How long must order and trade records be kept for surveillance purposes?
Under MiFIR, investment firms and trading venue operators are required to keep records of orders available to competent authorities for five years. Retention requirements can vary by jurisdiction and instrument type, so firms should confirm the applicable period with their compliance function rather than assume a single global standard.