Trade Surveillance Software Development

We build trade surveillance and control room software for firms under MAR: detection models, insider lists and MNPI controls that work as one system.

Book a surveillance review View case studies

Control rooms and surveillance engines don’t talk to each other

Most firms run market abuse controls in two halves.

Control room

Manages who knows what: watch lists, restricted lists, insider lists, wall crossings.

Surveillance platform

Watches what gets traded: spoofing, layering, wash trades, insider dealing.

The two rarely share data.

So when surveillance flags a trade in a name on the control room watchlist, that alert looks like everything else. Analysts then spend valuable time rebuilding context that already exists in another system.

Book a surveillance review

What MAR Actually Asks of Your Systems

MAR covers three offences: insider dealing, unlawful disclosure of inside information, and market manipulation. Your systems have to handle prevention and detection, because the regulation asks for both.

Article 16: Detect and Report

You need effective systems and procedures to detect and report suspicious orders and transactions. Orders, amendments and cancellations all count, not only executed trades, and that is where a good deal of manipulation lives.

Article 18: Insider Lists

Insider lists have to be kept in a prescribed format, with timestamps recording when each person gained access to inside information, and handed to your national competent authority on request.

Article 17: Disclosure

Controls around the point at which inside information becomes public, plus an audit trail for any decision to delay disclosure.

STOR Filing

When an alert turns into a reasonable suspicion, you file a Suspicious Transaction and Order Report. That means assembling the evidence behind it and recording the decision, including the decision not to file.

Regulators usually want to know why a model is calibrated the way it is, whether you can produce the audit trail, and what you did with the alerts you closed.

What off-the-shelf surveillance platforms don’t cover

Most firms have tried buying one, and it may cover the basics for a while. But there are several places where it gets harder.

Asset class coverage

Vendor models are strongest in equities and listed derivatives. Fixed income, OTC derivatives, commodities and digital assets are thinner. If that is where you trade, you are either living with the gap or building around it.

Calibration you cannot reach

Generic models produce generic alerts. Bringing the false positive rate down means tuning to your order flow, your client base and your venues, and vendor tuning only goes so far before you need to work on the model yourself.

Data that does not arrive clean

Most of the effort in a surveillance programme goes into getting order lifecycle data, executions, market data and reference data into one normalised, timestamped view. A vendor takes your feed. Fixing the feed is your job.

The split down the middle

Very few vendors cover prevention and detection well. You buy one platform for each, and the integration between them is yours to build.

We don’t sell a surveillance platform. Most of our work sits around the one you already have: the data layer feeding it, the control room beside it, and the connections that make the two useful together.

Firm trade surveillance

Detection models for spoofing, layering, wash trading, marking the close, ramping and front running

Insider dealing detection that reads control room context, so a trade in a restricted name is flagged for what it is

Cross-product and cross-venue correlation, so activity spread across instruments doesn’t fall between models

Alert scoring and suppression, to bring the queue down to something an analyst can work through properly

Replay and backtesting, so you can change a model and see what it would have caught over the past two years before it goes live

Case management and STOR workflow, with the evidence pack assembled as you go

Control room software

The control room is where information control actually happens, and a surprising amount of it still runs on spreadsheets and email.

  • Watch list, restricted list and grey list management, with the rules that govern movement between them
  • Enforcement that reaches into other systems, so a restricted name blocks research publication, personal account dealing and client trading where it should
  • Information barriers configured around your real desk structure rather than a policy document
  • Approval workflows with a full audit trail
  • Reporting for the regulator and for your own committee packs
Compliance analyst reviewing a tablet in front of a wall of trading screens

MNPI and insider list management

Article 18 is specific about what a list has to contain, and manual lists usually fail on timestamps.

  • Insider lists in the prescribed format, with minute-level timestamps
  • Deal and project lists, including permanent insider sections
  • Capture from the systems where wall crossings actually happen, rather than asking people to remember to update a list
  • Acknowledgement workflows, so you have evidence that each person was told what they were being given
  • Export on demand, in the format your competent authority asks for
Two colleagues reviewing deal data on a laptop

Deal governance and wall crossing

  • Wall crossing requests, approvals and records, with the justification captured at the time rather than reconstructed later
  • Deal team tracking across the lifecycle, from pitch to announcement
  • Conflicts clearance, checked against existing mandates and positions
  • Project code name management, with the mapping back to real names visible only inside the control room
  • Handover into the insider list and the watch list, without anyone retyping anything

Who we build for

  • Investment banks and broker-dealers carrying both control room and surveillance obligations
  • Asset managers and hedge funds running surveillance across strategies and venues
  • Trading firms in asset classes that vendor models cover poorly
  • Crypto-asset service providers now inside the market abuse perimeter
  • RegTech vendors building or extending surveillance capability in their own products

How we work with you

Surveillance review

A short engagement looking at your current models, alert volumes and data quality, ending with a clear view of what is actually wrong. Usually a few weeks.

Specialist pods

A small team working alongside yours on a defined piece: a data layer, a set of models, a control room integration.

Product partnership

For RegTech vendors, a longer engagement building surveillance capability into your platform.

Dedicated teams

Embedded teams for firms running a multi-year modernisation.

Talk to our surveillance engineers

Our success stories

dreamix home image scaled e1718004077682 - Trade Surveillance Software Development Services
our success stories bg mobile - Trade Surveillance Software Development Services

  • Building an AI Platform for the Compliance Industry

    Our client is a leader in compliance technology solutions for regulated financial firms. As the volume of data compliance teams must monitor keeps growing, they saw an opportunity to use AI to get ahead of it. They partnered with Dreamix to build Encore: a production-grade AI platform that today gives compliance teams access to 100+ […]

    Case study

  • Streamlining compliance with a comprehensive ARL management tool 

    Navigating regulation has always been a core challenge for companies. For nearly two decades, MCO has been at the forefront of creating solutions to help overcome this hurdle. In the currently growing complexity of the regulatory landscape, the US-based platform recognized a rare opportunity to make compliance more straightforward for their clients.  After joining forces […]

    Case study

Why firms choose Dreamix for surveillance engineering

  • More than 20 years building software for regulated industries, with financial services making up a large share of it
  • 300+ engineers, and the wider Synechron group behind us
  • EU nearshore delivery, in your time zone and inside your regulatory perimeter
  • 95% client retention
  • We have built compliance systems before, so we design for the audit trail from the first sprint rather than adding it later

The technology we build on

Surveillance is a data problem before it is a detection problem, so that is where we start.

Java and .NET for core services, Python for models and analytics

Kafka and event streaming for real-time order and execution flow

Time-series and columnar stores, for the historical depth that replay and backtesting need

FIX and proprietary order lifecycle formats, normalised into a single model

Market data integration for benchmarking and trade reconstruction

Cloud or on-premise, depending on where your data is allowed to sit

How a build comes together

01

Discovery

We sit with your compliance and technology teams to map what you have, what it misses, and what the regulator has already asked about.

02

Data assessment

We look hard at your order, execution and reference data, because everything downstream depends on it.

03

Design

Target architecture, model approach and integration points, agreed before anyone writes code.

04

Incremental build

Working software every couple of weeks, so you can see it and steer it.

05

Parallel run

New models run alongside the old ones until the alert quality is provably better.

06

Handover

Documentation, runbooks and training, or we stay on and run it with you.

Frequently asked questions about trade surveillance software development

Trade surveillance is the monitoring of orders and trades to spot market abuse: insider dealing, market manipulation and related behaviour. Firms in scope of MAR have to run it, detect suspicious activity and report it to their regulator.

The control room is the function that controls inside information inside a firm. It runs the watch list, the restricted list and the grey list, approves wall crossings, maintains insider lists and manages the information barriers between desks.

Material non-public information: information that is not public and that a reasonable investor would use when deciding whether to trade. Under MAR it is called inside information. Controlling who has it, and evidencing that control, is what the control room exists to do.

Trade surveillance looks at orders and executions. Communications surveillance looks at email, chat and voice. They answer different halves of the same question, and the strongest cases are usually built by putting the two together.

A Suspicious Transaction and Order Report. When a firm has reasonable suspicion that an order or trade amounts to market abuse, it files a STOR with its national competent authority, along with the reasoning and evidence behind it.

Buy for the core if you trade mainstream asset classes through mainstream venues. Build where your asset classes are covered poorly, where your data needs serious work before any platform can use it, or where the connection between your control room and your surveillance engine is the real problem. Most firms end up doing some of both.

An insider dealing alert is only meaningful with context: who knew what, and when. That lives in the insider list and the watch list. When the two systems share data, surveillance can rank an alert on a restricted name far above an alert on a name nobody was crossed on. When they don’t, an analyst does that work by hand.

Full order lifecycle data including amendments and cancellations, executions, market data for benchmarking and reconstruction, instrument and client reference data, and the control room lists. Missing or badly timestamped order data is the most common reason a surveillance programme underperforms.

Yes. Crypto-asset service providers sit inside the market abuse perimeter under MiCA, with detection and reporting obligations that mirror MAR. Vendor coverage for digital assets is still developing, which is one reason more crypto firms build.

Talk to our surveillance engineers

Book a surveillance review