Evaluate · one alert, end to end

Trade surveillance software: one alert traced from order to close

Trade surveillance software has two halves: the engine that raises alerts, and the work that turns each alert into a decision a regulator will accept. This guide follows one trading-before-news alert through Botminds' Trade Surveillance, from the engine's batch to a checked close, and sets out what to ask any provider.

Updated · 13 min read

Trade surveillance software monitors a firm's orders and trades for market abuse and helps its analysts decide each alert. Most products are judged on the first half, the engine: which scenarios it runs, across which asset classes, with what calibration. The rules and the regulators judge the second half as well: whether each alert was examined by a person, on enough evidence, with a reason kept for five years. That second half is where analysts' time goes, because the alert never says why the order existed. Botminds' Trade Surveillance works on that half. It takes the alerts an existing engine raises, and its agents build each one into a case with every statement cited to the order record, the news, the messages and the lists, so an analyst decides, a second person checks, and the Head of Surveillance approves any report. This guide follows one alert from the engine to a signed close.

The alert, the firm and the people are fictional: Quillfield Capital and its sample data, run through the solution. The rules and findings quoted are real.

What surveillance software is measured against

3+ yrs

an insider-dealing model produced no alerts because the news feed it needed was never switched on

½

roughly, of nine banks the FCA reviewed focused their model testing mainly on parameter calibration

5 yrs

how long the analysis and reason behind every examined alert must be kept

FCA, Market Watch 79 (May 2024): a firm's failure example and a 2023 peer review of front-running model testing at nine investment banks; Delegated Regulation (EU) 2016/957, Article 3(8).Source: FCA Market Watch 79; Delegated Regulation 2016/957, Article 3

What should trade surveillance software do?

It should let a firm meet the rule, which has three parts. The system must let the firm analyse every order placed, changed, cancelled or rejected and every trade executed, alone and against the others; it must raise alerts on activity that needs a closer look; and it must cover every kind of trading the firm does (Delegated Regulation 2016/957, Article 3(1)). The same article then requires "an appropriate level of human analysis" in deciding what the alerts mean.

Engines do the first three. They take order and execution data, run scenarios, score hits and queue alerts. The fourth, human analysis, is where most teams' cost and most regulators' criticism sits, and it is a different kind of work: gathering the instruction behind an order, the news around it and the messages before it (which have to be captured and searchable in the archive first), and writing down a reason. Software that stops at the alert leaves that work to spreadsheets, archive searches and free text. Software that continues past it must do so without taking the decision away from a person.

One alert, minute by minute

On Thursday 15 October 2026, the Asia batch of Quillfield Capital's surveillance engine raised a trading-before-news alert at 08:00 in London. Earlier that day in Tokyo, the firm's Asia Equity desk had bought 180,000 shares of Hoshida Precision, a fictional chip-equipment supplier, 22 minutes before the company raised its full-year forecast. The shares closed up 7.6%. On its face, the pattern is exactly what the scenario exists to catch.

What the alert saw: the Tokyo afternoon, in sequence

Tokyo, 15 October, 13:30–15:302 hours
Quiet trading13:30
Sector note; broker asks about volume; trader: "model trade today"13:42
Batch 3 released, 64 fills14:10
Forecast upgrade at 14:32, shares rise14:28
  • Quiet trading13:30
  • Sector note; broker asks about volume; trader: "model trade today"13:42
  • Batch 3 released, 64 fills14:10
  • Forecast upgrade at 14:32, shares rise14:28
Fictional sample case TS-26-104417 in Trade Surveillance, times as shown in the product's replay. In London, the agents had assembled the case by 08:06; the analyst opened it at 9:40, asked one question, answered the challenge and closed it at 9:44, and the close then waited for a second person to check it.

Read only that sequence and the trade looks bad: a broker asking about volume, a fast reply, a buy, then good news. Read the case file and it does not. The order came from a model rebalance ticket that a portfolio manager in Singapore created the evening before, approved by the risk team the same evening, with the release time fixed at 14:10 Tokyo time, batch 3 of 4. The order was staged in the order management system at 08:20 that morning and nothing about it changed afterwards. The firm bought pro rata across three accounts by model weight. Neither the trader nor the portfolio manager declared a personal holding, and the stock was on no list.

The trade replay: orders, fills, the broker chat and the disclosure on one price line

Trade Surveillance case for alert TS-26-104417, Hoshida Precision: bought 180,000 shares 22 minutes before a guidance upgrade, trading before news, score 84, Asia Equity Singapore. An intraday price chart in Tokyo time from 13:30 to 15:30 shows the sector note at 13:42, the broker's Japanese chat at 14:05 and the trader's reply at 14:07, the order released at 14:10:06 as batch 3 with 64 fills averaging 2,431.50 yen, and the forecast upgrade at 14:32 followed by a rise. Below, the What happened narrative cites each sentence to a source. On the right, agents' messages: the Peer agent on the batch release and pro rata split, the Skeptic agent's question which must be answered, and the Case writer's draft to close with R01 at 93% confidence.
Trade Surveillance on the fictional Quillfield Capital sample data. The narrative under the chart is written by the Case writer agent, every sentence tagged to one of ten sources.

What the agents did before the analyst arrived

Seven of the solution's eight agents worked the alert before 08:06. Each has one job and a list of things it may never do, and the analyst can open any agent's sources. The flow below is the order in which they ran.

Trade Surveillance: how one alert became a case before anyone opened it

  1. Agent

    Intake agent

    Takes the alert from the engine, links related alerts and routes it to an analyst who has not sat on the Asia Equity desk in the last 12 months.

    Never: Drops an alert

  2. Agent

    Order agent

    Pulls the order, the 64 fills, the allocations, the order audit log, the algorithm log and the rebalance ticket.

    Never: Infers intent; it reports what the record shows

  3. Agent

    News agent

    Finds the 13:42 sector note and the 14:32 disclosure in Japanese, with English beside each, timed to the second.

    Never: Paraphrases a source without showing the original

  4. Agent

    Comms agent

    Reads the trader's and the PM's chats and calls in the case window, including the broker's Japanese message.

    Never: Reads outside the case window without a logged reason

  5. Agent

    Peer agent

    Shows the batch released 12 orders at once and that Hoshida was split 62.2% / 22.8% / 15.0% by model weight.

    Never: Treats "others did it too" as proof

  6. Agent

    Skeptic agent

    Argues the other side: the broker asked 27 minutes before the headline, and participation rose. Did anyone speed the order up?

    Never: Decides; its challenge must be answered

  7. Agent

    Case writer

    Writes the cited narrative and drafts a close with reason R01, at 93% confidence.

    Never: Closes, escalates or files anything

  8. A person decides

    Analyst

    Reads the case, asks the agents a question, answers the Skeptic from the algorithm log, and closes with R01.

  9. A person decides

    Checker

    Checks the rationale against the sources and approves and signs; the maker can never check her own close.

Agents and limits as configured in Trade Surveillance; case details from the fictional sample alert. The eighth agent, the Tuning agent, works on the alert models rather than on single alerts.

The question an analyst asks, answered from the record

The analyst's real question was not in the alert. A trade released on a fixed schedule cannot be trading on news unless someone moved the schedule, so she asked: "Did anyone change the release time?" The Order agent answered at 98% confidence, citing the order audit log and the algorithm log: "No. The release time was set when the order was staged at 08:20:14 JST and the scheduler released it at 14:10:06. The audit log shows no amendment to quantity, price, time or strategy."

Asking the agents about the case, with the source behind each answer

Trade Surveillance case for Hoshida Precision with the agents' panel open. The analyst has asked whether anyone changed the release time. The Order agent answers at 98% confidence that the release time was set when the order was staged at 08:20:14 JST and the scheduler released it at 14:10:06, that the audit log shows no amendment to quantity, price, time or strategy, and that the algorithm log shows no manual intervention, citing sources S4 and S5. Above it, the Case writer's draft to close with R01 at 93% confidence. Suggested questions below include showing the other orders in batch 3 and translating the broker chat.
Trade Surveillance on the fictional Quillfield Capital sample data. Each answer names the sources it read; the analyst can open them before deciding.

Then the Skeptic agent's challenge had to be answered before the decision buttons would open. Participation had risen from 9% to 14% between 14:20 and 14:27, close to the headline. The answer was in the algorithm log: the algorithm's standard catch-up had engaged automatically because the batch was 6.4% behind schedule, with no manual change, and 14% stayed under the 15% cap. The analyst wrote that answer, it stayed in the file, and she closed with reason code R01, "scheduled or systematic order: release fixed before the information existed".

Can AI reduce trade surveillance false positives?

It can make them cheaper and fewer, but it should not make them disappear unseen. There are three honest levers, and one dishonest one. The first lever is faster decisions: an alert whose evidence arrives assembled takes minutes, not most of an hour, and in the sample firm all 214 open alerts had been assembled as cases by 9:40 a.m. The second is grouping: 96 look-alike alerts from scheduled rebalances, each checked one by one by the agents, were offered to the analyst to close as a set, with a checker sampling 10. The third is tuning: a threshold change proposed with a six-month backtest that shows past real cases still alert.

The dishonest lever is to raise thresholds until the queue is quiet. The FCA has warned against calibrating to "average peer alert volumes" or "'out of the box' and 'industry standard' settings" (Market Watch 56), and against generic thresholds across instruments as different as AIM stocks and government bonds, which either miss abuse or produce "a high amount of 'noise'" (Market Watch 69). A provider who promises a percentage cut in alerts without saying how past true positives were tested is selling the dishonest lever. A marking-the-close threshold change shows the difference with numbers.

Trade surveillance artificial intelligence: what regulators expect

Regulators have not written new rules for AI in surveillance; they have said the existing ones apply. The SEC's Division of Examinations, in its priorities for fiscal year 2027, counts surveillance among the jobs firms now hand to what it calls "super intelligence (SI)", and examines that work against the same duties as before, which it describes as technology-neutral (SEC, Examination Priorities FY2027). ESMA's 2024 statement on AI in investment services likewise expects firms using it to keep meeting their MiFID II obligations (ESMA, May 2024).

The FCA has been most specific about surveillance. In its review of surveillance failures it wrote that "Developments such as the use of artificial intelligence will need to be accompanied by governance that keeps pace and remains effective" (FCA, Market Watch 79). For a buyer, that means three testable things: the firm can see which sources an agent used, a person makes every decision the rules reserve to people, and changes to agents and models are approved, versioned and tested before they go live. In Trade Surveillance, agent prompts and models must match or beat the previous version on a golden set of 420 past alerts, and the Head of Surveillance approves every change.

The second person on every close

Trade Surveillance approve-close dialog for TS-26-104417, opened by the checker, a senior surveillance analyst. It shows the maker, the reason code R01 scheduled or systematic order with release fixed before the information existed, Skeptic answered yes and kept in the file, and the agents' check of the rationale: every statement matches a cited source. A checkbox reads I checked the rationale against the sources and agree with the close, with buttons to cancel or approve and sign. Behind the dialog, the case status reads Closed, waiting for checker, and a note says the checker must be someone else under rule C1.
Trade Surveillance on the fictional Quillfield Capital sample data. The agents check that every statement in the rationale matches a cited source; the checker signs with her own statement, and rule C1 refuses a checker who made the close.

Trade surveillance system features that matter on the buy side

Feature lists for surveillance systems are long and similar. Five features separate a system that will survive a regulator's review at an asset manager from one that will not. The first is order completeness: amendments, cancellations and rejections, not only fills, because Article 3(1) names them. The second is the order's origin: the rebalance ticket, model or instruction that created it, because most buy-side alerts are closed or escalated on that fact. The third is news in the original language with exact timestamps, because a trading-before-news alert is a question about sequence. The fourth is communications in the case window, because intent lives there. The fifth is the written reason, kept with its evidence for five years.

Most engines cover the first well and the others partly, and that is not a criticism of engines: they detect, and these features serve the decision. It is why many firms run two layers, an engine and a case tool, and why the buying question is how the two connect. Comparing the options on cost per closed alert takes that further.

Trade surveillance software providers: questions to ask any vendor

Ask questions whose answers can be checked on your own data. The FCA's reviews of surveillance failures give most of them, because each failure it describes is a question a vendor should be able to answer before go-live.

Ten questions for trade surveillance software providers

  1. How will we know all our order data arrived?

    The FCA found a firm whose private order feed was never ingested "For several years". Ask for daily completeness reconciliation by source and venue.

  2. Can we see each scenario's logic and parameters?

    The FCA expects firms using vendor systems to "understand how alert scenarios work". Black-box scoring fails that.

  3. Do you monitor cancelled and amended orders?

    Required by Article 3(1)(a) and flagged by the FCA as a gap at some firms.

  4. How are thresholds set per instrument and asset class?

    Generic thresholds across very different instruments either miss abuse or produce noise.

  5. What lookback does the insider-dealing scenario use?

    A 24-hour lookback before news was criticised; inside information exists before it is published.

  6. How do you test a model after a change elsewhere?

    The FCA asks whether regression testing is done "when changes are made to other systems".

  7. What evidence does the analyst see without leaving the alert?

    Order origin, news in the original language, communications, lists and personal trading.

  8. What can the AI do, and what can it never do?

    Ask for the limits in writing: may it close, escalate or file? Which sources did it use for each statement?

  9. How is a threshold change proved?

    By a backtest showing past true positives still alert, approved by a named person, not by the fall in volume.

  10. Can we export every decision with its evidence for a regulator?

    Five years under Article 3(8), in a form an examiner can test.

Our questions, drawn from Delegated Regulation 2016/957 Article 3 and FCA Market Watch 56, 69 and 79.Source: Market Watch 79; Market Watch 69

Where Botminds' Trade Surveillance fits, and where it does not

Trade Surveillance is the case layer, not the engine. It takes the alerts the firm's surveillance engine already raises and the exceptions from its order management system; the alert models keep running in the engine. A firm without an engine, or with large gaps in its order data, should fix those first: no case tool can assemble evidence for an alert that never fired, and the FCA's 2026 priorities still list "incomplete or inaccurate data feeds" among the gaps it finds (FCA, Wholesale Markets priorities).

Where it fits is everything after the alert: the evidence, the challenge, the decision, the check, the report and the record. Every action by people and agents is on an audit trail that cannot be edited, records stay in each entity's region for seven years, and the agents measure each model's productive rate so tuning starts from evidence. Implementation starts with connecting the systems and a dry run on last month's alerts. To see it on your own alerts, start at Trade Surveillance.

Questions people ask

What is the difference between trade surveillance and transaction monitoring?

Trade surveillance looks for market abuse, such as insider dealing and manipulation, in orders and trades. Transaction monitoring usually means anti-money-laundering monitoring of payments and account activity. They use similar alert mechanics, but they report to different authorities: STORs go to the FCA, suspicious activity reports to the National Crime Agency.

Does trade surveillance software replace the analyst?

No. Delegated Regulation 2016/957 requires "an appropriate level of human analysis", and the decision to report is the firm's. Software can gather evidence, draft the narrative and argue the other side; in Trade Surveillance the agents never close, escalate or file anything.

How do you evaluate trade surveillance software on your own data?

Replay a past month: load last month's orders and alerts, plant or identify known true positives, and compare what each system finds and how long a decision takes. Check data completeness by source and venue before comparing anything else.

Can trade surveillance software read chats in other languages?

Some can. In Trade Surveillance the News agent keeps disclosures in their original language with English beside them, and the Comms agent reads chats, emails and recorded calls in any language; the sample firm's cases include Japanese disclosures and German chats.

Is trade surveillance software required for asset managers?

The rules require effective systems, not a particular product. Delegated Regulation 2016/957 says arrangements must be "appropriate and proportionate" to the firm's business and asks firms to show regulators "the level of automation put in place". A small manager may meet that with simple tools; most firms with many orders use an engine.

Trade Surveillance.
See it on your own files.

An agentic solution from Botminds. Reviews market abuse alerts and builds each case from orders, news and chats for compliance Book a demo, or explore how it works.