Trade Surveillance System Development
We build the systems that turn raw order flow into market abuse alerts a compliance officer can defend: drop copy capture, order lifecycle reconstruction in venue time, detection scenarios with versioned parameters, and an audit record that reproduces a decision made eighteen months ago. The hard part is rarely the models. It is proving that every order which should have been scored was scored.
Trusted by engineering teams.
Teamvoy has delivered engineering work for Nasdaq, Panasonic, Afriland First Bank, and 50+ other companies since 2013.
Trade Surveillance Services We Offer
Six offerings, each scoped separately and each built against your own order data rather than a demo set.
Order and Trade Data Capture
We take order and execution events from FIX drop copy, venue order-entry logs and OMS extracts, and land every intermediate state rather than the final one. Gap detection runs on sequence numbers per session, so a drop copy that resumes after a disconnect is replayed and de-duplicated instead of arriving as a second order.
– FIX drop copy sessions
– Venue and OMS ingestion
– Sequence gap detection and replay
– Instrument and reference data resolution
– Daily reconciliation to the book of record
Order Lifecycle Reconstruction
We stitch parent orders, child orders, amendments, cancels, partial fills and allocations back into one chain, ordered in venue time rather than arrival time. This is what keeps a layering pattern intact when an algo has split a single parent across three venues with three different clock sources.
– Parent and child order stitching
– Cancel-replace chain rebuilding
– Multi-venue algo orders
– Clock alignment against RTS 25
– Allocation and give-up mapping
Market Abuse Scenario Development
We write detection scenarios against your asset classes: spoofing, layering, wash trades, marking the close, ramping, insider dealing around news windows and cross-product patterns. Each scenario ships with the query that produced it, so an analyst can see which orders were in scope and which were filtered out.
– Spoofing and layering
– Wash and improper matched trades
– Marking the close and ramping
– Insider dealing news windows
– Cross-product and cross-venue patterns
Threshold Calibration and Tuning
Parameter sets are built per asset class and per liquidity band, then backtested against your own order history before they go live. Alert volume is modelled ahead of the change, so the team knows what a threshold move does to the queue before it does it.
– Liquidity-banded parameter sets
– Backtesting on historical orders
– Alert volume modelling
– Tuning evidence packs
– Model change control
Alert Triage and Case Management
Alerts are de-duplicated, grouped by trader, desk, instrument and day, and enriched with restricted lists, trader profile and linked communications before anyone opens them. Trader identity resolves through a mapping table with effective dates, so a person who moved desk keeps their history instead of starting again.
– Alert de-duplication and grouping
– Trader and desk enrichment
– Communications and voice linking
– Case workflow and escalation
– STOR preparation and filing exports
Surveillance Platform Migration and Integration
We integrate with or migrate away from Nasdaq SMARTS, NICE Actimize, Eventus, Steeleye and in-house engines, starting with a parallel run rather than a cutover. Both systems score the same days, and the alert-by-alert difference report is what lets compliance sign the switch off.
– Vendor engine integration
– Parallel run and alert reconciliation
– Historical alert backfill
– Data lineage and retention
– Regulator and audit evidence exports
What Our Clients Say
Trade Surveillance Success Stories
Check out our product and experience design case studies. Learn how we’ve helped businesses like yours launch stunning solutions and succeed in target markets.
One market abuse alert, seven layers
On screen it is one alert on one trader. Underneath it is seven handovers between systems, and each one can drop an order without telling anyone.
01. Capture and ingest
Order and execution events arrive from FIX drop copy sessions, venue order-entry logs, OMS extracts and the market data feed, each with its own sequence and its own idea of time. Breaks when a drop copy session reconnects after a gap and replays sequence numbers, so one cancel-replace chain lands twice and reconstructs as two separate orders.
02. Normalisation and instrument resolution
Venue symbols, ISINs, RICs and internal instrument codes resolve to one identifier, with corporate actions applied to the history as well as to today. Breaks when an OTC instrument has no ISIN until the DSB assigns one, so a week of orders sits under a placeholder code and never joins the market data it should be scored against.
03. Order lifecycle reconstruction
Parent orders, child orders, amends, cancels, partial fills and allocations are stitched into a single chain and sorted in venue time. Breaks when an algo splits a parent across venues whose clocks differ by more than the RTS 25 tolerance, so the sequence re-sorts and a layering pattern that existed in the market does not exist in the reconstruction.
04. Market context and time alignment
The order book is rebuilt around each event so every order carries the best bid and offer, the depth and the spread that stood when it was sent. Breaks when the book is rebuilt from a consolidated feed published at a coarser timestamp than the order log, so the model scores against a price the trader never saw.
05. Detection
Scenarios run over the reconstructed chain with parameter sets bound to asset class and liquidity band, and every alert records the scenario version and the input snapshot. Breaks when one threshold set is applied across liquid and illiquid names, so the illiquid book generates most of the queue and analysts learn to close alerts without reading them.
06. Triage, enrichment and case
Alerts are de-duplicated, grouped and enriched with trader profile, desk, restricted list and linked communications, then routed into a case with an owner and a clock. Breaks when enrichment joins on a trader identifier that changed when the person moved desk, so prior behaviour drops out of the profile at the point it matters most.
07. Evidence, disposition and reporting
The disposition, the data the analyst saw and the parameters in force are written to an immutable record, and STOR or regulator exports are generated from that record. Breaks when a tuning change re-scores historical alerts, so the file no longer reproduces the decision that was actually made and an audit cannot follow it.
Can you prove your alerts cover every order you booked?
Why choose Teamvoy for trade surveillance system development?
Four commitments, each with the thing it costs us to hold to it. Surveillance work is bought on trust and audited on evidence, so the trade-offs matter more than a capability list.
The engineers who scope the work build the work.
No handover from a pre-sales team to a delivery team. The person who tells you what the work will cost is the person who then has to make that estimate true.
You own the source code from the first commit.
The repository is yours, in your organisation, from day one. Not transferred at the end, not held until the final invoice clears.
We reconcile the order data before we score it.
Every engagement opens by proving that the orders reaching the surveillance store match the book of record, day by day and instrument by instrument. Until that reconciliation is clean, a detection model is scoring some subset of your trading and nobody can say which subset.
Every alert replays against the parameters and data that produced it.
Thresholds, scenario version and the input snapshot are stored with the alert, so a disposition reached eighteen months ago can be reproduced exactly for internal audit or a supervisor.
Three ways to start
Pick the one that matches how much you already know about your own order data.
Surveillance data and coverage review
We reconcile a sample period of your order and execution data against the book of record, map current scenario coverage to your market abuse risk assessment, and write up the gaps with the queries behind them. You keep the report whether or not we build anything.
One scenario live on your own data
One detection scenario, usually layering or marking the close in a single asset class, running in your environment against your reconstructed order chain, with triage and an audit trail. Built so your team can extend it without us.
A call with the engineer who would scope it
Bring your venues, your asset classes, the OMS the data comes from and the engine you run today. You get an honest read on what is reconstructable and what is not, and no follow-up sequence.
The rows that separate two surveillance quotes are rarely the ones in the demo.
Take this table into your next vendor call and ask for their answer in the middle column.
What our trade surveillance engineers work in.
Ingest and streaming
Storage and replay
Detection and analytics
Services and interfaces
Systems we integrate with
Run, evidence and controls
We engineer for:
Find out what your surveillance data actually covers.
Talk to a Chief Technology Officer on the first call.