A trade surveillance system implementation connects a firm's order, execution and reference data to scenarios that detect market abuse, calibrates those scenarios to the firm's own business, and proves, before go-live, that known abuse patterns would alert and that every order source arrives. The order of work matters more than the vendor. Regulators' published failures are mostly data failures: a news feed never switched on, a private order feed never ingested, an alert condition coded wrongly, each unnoticed for years because the alert queue looked normal. So the safe plan is data first, then models, then a parallel run against the old system, and only then the switch. Botminds' Trade Surveillance is implemented beside the firm's engine rather than instead of it: it connects to the engine's alerts, the order systems, the news, the communications archive and the lists, maps desks, roles and reason codes, and runs a dry run on last month's alerts before any analyst relies on it.
Product details come from Trade Surveillance's setup on a fictional asset manager, Quillfield Capital, with sample data. The timings in the plan below are an illustration, not a benchmark.
What silent surveillance failures cost in time
3+ yrs
an insider-dealing model could not alert, because its news feed was never activated at go-live
Years
a private order feed went unmonitored while the firm believed it was covered
2026
the year the FCA still listed incomplete or inaccurate data feeds among surveillance gaps it finds
Trade surveillance system definition, and what an implementation covers
A trade surveillance system is the set of "arrangements, systems and procedures" a firm uses to detect, investigate and report possible market abuse in its own orders and transactions. In the language of Delegated Regulation 2016/957, it must allow analysis "of each and every transaction executed and order placed, modified, cancelled or rejected", "produce alerts indicating activities requiring further analysis", and "cover the full range of trading activities" (Article 3(1)). Software is one part; data, procedures, people and records are the rest.
Implementation therefore covers more than installing an engine. It covers the risk assessment that decides which scenarios are needed, the feeds that bring every order to them, the calibration of each scenario to the firm's instruments, the alert review procedure and its record, the training the rules require, and the testing that proves it all works. A project plan that lists only the engine's configuration has left out most of what a regulator will examine.
Trade surveillance system requirements: what the rule says the system must do
The requirements come from the Delegated Regulation, and they are more specific than a vendor's functional list. The duty applies "to orders and transactions relating to any financial instrument" and "irrespective of" the capacity in which the firm acts, the type of client, and "whether the orders were placed or transactions executed on or outside a trading venue" (Article 2(2)). The arrangements must be "appropriate and proportionate", "regularly assessed, at least through an annually conducted audit and internal review", and "clearly documented in writing, including any changes or updates" (Article 2(5)).
Three further requirements shape the design. On request, a firm must show the regulator "the information on the level of automation put in place" (Article 3(2)), so the design should record which steps are automated and why. It must ensure "an appropriate level of human analysis" (Article 3(4)). And it must train the people who monitor and the people who process orders (Article 4). If any of the work is delegated to a provider, the firm keeps the expertise to judge it and "direct access" to the alert data (Article 3(7)).
A trade surveillance system implementation plan, data first
Sequence the plan so that nothing is calibrated on data that has not been proved complete. The illustration below assumes a mid-sized manager adding or replacing an engine and a case layer; real durations depend on the number of order systems, venues and asset classes.
An implementation plan that proves the data before it tunes the models
- Risk assessment and scenario map3 wks
- Order and execution feeds, reconciled daily6 wks
- News, reference data, lists3 wks
- Calibration on own data3 wks
- Seeded tests and parallel run5 wks
- Wait for proven feeds
- Connect archive, tickets, lists3 wks
- Desks, roles, reason codes, procedures2 wks
- Dry run on last month, training4 wks
The longest bar is the order feeds, on purpose. Every order source, every venue, every private or direct-access feed, and every amendment and cancellation must arrive, and the proof is a daily reconciliation of counts against the order management system, by desk and venue, that runs for weeks before go-live and never stops after it. Calibration waits for it, because a threshold tuned on incomplete data is tuned to the wrong market.
What data feeds does trade surveillance need?
More than orders and fills. The engine needs order events to detect; the analyst needs context to decide; and the regulator's template needs identifiers to report. Each feed below has a reason in a rule or a regulator's finding.
The data a buy-side trade surveillance system needs, and why
| Feed | What it must include | Why |
|---|---|---|
| Order events | Every order placed, modified, cancelled or rejected, with times to the second, author and channel. | Article 3(1)(a) names all four; the FCA has found firms that left cancelled and amended orders unmonitored. |
| Executions and allocations | Fills by venue, including off-venue and direct-access flow, and allocations to accounts and funds. | The FCA's Firm C missed a private order feed "For several years". |
| Algorithm and scheduler logs | Release times, participation settings, manual interventions. | Explains most timing alerts on scheduled or algorithmic orders. |
| Order origin | Rebalance tickets, model changes, PM instructions, client flows. | On the buy side the reason an order existed decides most alerts. |
| News and issuer disclosures | Original language, timestamps to the second, source. | The FCA's Firm A had no news feed active; its insider-dealing model could not alert for over three years. |
| Reference and market data | Instrument identifiers and classification codes, prices, volumes; yield for bonds. | The STOR template asks for the identifier and "ISO 10962 CFI code"; the FCA warned against price-only bond surveillance. |
| Communications | Chats, emails and recorded calls of traders and PMs, by case window. | Intent and information paths live there; a missing mailbox is an evidence gap. |
| Lists and personal trading | Watch, restricted and insider lists, wall-crossings, personal-trading declarations and pre-clearance. | Information barrier and front-running alerts depend on them. |
The last three rows are where buy-side implementations most often stop short, because they belong to other teams: communications to the archive owner, lists to compliance, personal trading to the code-of-ethics function. They are not detection data, so an engine project can go live without them. They are decision data, so the analysts cannot close alerts properly without them, and the case file will show the gap every day.
How long does it take to implement trade surveillance?
As long as it takes to prove the data, which no vendor can promise in advance. No regulator or independent study publishes implementation times. The honest planning unit is evidence, not weeks: the plan is done when every feed reconciles, every scenario on the risk map has passed a seeded test, the parallel run's differences are explained, and the procedures and training are in place.
Two things lengthen projects predictably. The first is the number of order sources: each additional order system, broker connection or direct-access route is another feed to reconcile. The second is calibration done before the data is complete, which has to be redone. The FCA's examples show the cost of skipping steps: Firm A's insider-dealing model went into production without "the necessary testing", and the missing news feed was found more than three years later, after an FCA enquiry (Market Watch 79).
How to run a parallel test of surveillance
Run old and new side by side on the same weeks of data, and explain every difference. A parallel run is the only test that compares what the new system finds with what the firm already knows. It has four parts.
First, replay a past period through the new system, ideally including the dates of past true positives, and confirm each of those still alerts. Second, seed synthetic cases for every scenario on the risk map into a test copy of current data, including the awkward ones: an illiquid bond, an order split across accounts, an amendment just before news. Third, run both systems live for several weeks and reconcile the alert sets: alerts only the old system raised, alerts only the new one raised, and alerts both raised with different scores. Every difference gets a written explanation. Fourth, have analysts decide a sample of new-system alerts end to end, so the procedure and the record are tested too.
Calibrate during the parallel run, not before it, and calibrate to the firm. The FCA has warned that "out of the box" settings and "average peer output volumes" will not necessarily satisfy MAR (Market Watch 56), and that a single price threshold across an AIM stock, a FTSE 100 stock and a bond will be too high for some and too low for others (Market Watch 69). It also criticised insider-dealing lookbacks as short as 24 hours. Set those parameters with the data in front of you.
Go-live checks to sign before switching over
Go-live should be a decision with evidence, signed by the head of surveillance. The checklist below is the evidence; each item is something a regulator could ask to see in the first annual review.
Trade surveillance go-live: the evidence to have on file
- Feed reconciliation
Daily counts by source, venue and desk match the order system for at least several weeks, including cancellations and amendments.
- Scenario coverage map
Every risk in the market abuse risk assessment maps to a scenario, or to a written reason why none is needed.
- Seeded test results
Each scenario fired on its planted cases; failures fixed and re-tested.
- Past true positives
All replayed real cases alert at go-live thresholds.
- Parallel-run differences explained
Every alert raised by one system and not the other has a written explanation.
- Procedures and records
Review procedures per alert type; close notes with reasons kept five years; documentation of the arrangements as required by Article 2(5).
- Training delivered
For surveillance staff and for the staff who process orders, as Article 4 requires.
- Regression plan
Who re-tests which scenarios when an order system, feed or vendor release changes.
Trade surveillance monitoring after go-live
Go-live is the start of monitoring the monitor. The FCA asks firms to consider whether "regression testing" is done when changes are made to other systems that might affect surveillance, and whether, with third-party systems, firms can "independently gain comfort that models are operating as intended" (Market Watch 79). It reminds firms of the "regulatory obligation, to periodically review their arrangements to ensure they remain effective", including alert parameters and logic and "work undertaken on the analysis and escalation of alert output" (Market Watch 69).
Three signals deserve a daily look: feed counts against the order system, alert counts per scenario against their normal range, and missing context in open cases. The last one is easy to overlook and easy to show. In the sample firm, one case could not be closed because two mailboxes were delayed at the communications archive; the agents held it until they arrived rather than letting a close rest on incomplete evidence.
The analyst's morning, including a case held for missing evidence
Implementing Trade Surveillance beside an existing engine
Botminds' Trade Surveillance is the case layer, so its implementation is the second lane of the plan above. First-time setup connects the systems the evidence lives in: the surveillance engine's alerts and the order management system's exceptions, the order and execution systems with their audit and algorithm logs, the model portfolio system's tickets, market data and disclosure feeds, the communications archive and voice recording, and the lists, pre-clearance and HR directory. It then maps desks, sets roles and the conflict rules that keep a maker from checking their own close, loads the firm's reason codes and service levels, and runs a dry run on last month's alerts.
Used well, the dry run is the case layer's parallel test: analysts decide a sample of last month's alerts with the case files beside their original notes, and the differences show where evidence was missing before and where the agents' drafts need correcting. Records stay in each entity's region, and every change to agents or models needs the Head of Surveillance's approval. If the engine's feeds are not yet proven, fix them first: surveillance that fails silently starts there. For the cost side, see the trade surveillance system comparison, and for the solution, Trade Surveillance.
Questions people ask
What is trade surveillance monitoring?
It is the ongoing review of a firm's orders and transactions for market abuse: scenarios run over the data, alerts are reviewed and decided, and suspicious activity is reported. Delegated Regulation 2016/957 requires the monitoring to be "effective and ongoing" and to cover all orders received and transmitted and all transactions executed.
Who should own a trade surveillance implementation?
The head of surveillance should own the outcome and sign go-live; IT owns the feeds and their reconciliation; the order system owners own completeness of order events. A vendor can run the project, but under Delegated Regulation 2016/957 the firm stays fully responsible for its surveillance.
Can you implement trade surveillance in phases?
Yes, by asset class or desk, provided each phase goes live only with proven data and tested scenarios, and the gaps in the meantime are documented in the risk assessment with interim controls. The rule's requirement to "cover the full range of trading activities" applies to the arrangements as a whole.
What is the most common trade surveillance implementation mistake?
Trusting the alert queue as proof that the data is complete. In the FCA's published examples, models kept producing alerts, even true positives, while a news feed, a coding condition or a private order feed silently removed whole categories of activity from view.
Does a new surveillance system need regulator approval?
No prior approval is required. The firm must be able to show the regulator, on request, that its arrangements are appropriate and proportionate, including "the level of automation put in place", and must review them at least yearly.