Trade Surveillance in 2026: Detecting Cross-Market Manipulation at Scale

The trades that move a market the wrong way rarely stay inside one market. An order is placed on one venue to nudge a price, the real position is taken on another, and a message on a third platform ties the intent together. Surveillance that watches each market on its own sees three unremarkable events. Surveillance that watches across them sees manipulation.

This is the central problem for trade surveillance in 2026. Activity is fragmented across venues, products, and channels, and the abusive patterns hide in the gaps between them. Regulators know it, and enforcement is increasingly built around exactly these cross-market cases.

The economics make it harder every year. Trading is spread across more venues than ever, much of it automated, and the number of events a surveillance system has to reason over keeps climbing. More venues and more messages mean more places for abusive behaviour to hide, and more noise to hide it in. The teams that keep up are the ones that treat surveillance as a data problem first and a detection problem second.

The blind spot is between markets

Most surveillance estates grew up one market at a time. An equities system here, a derivatives system there, each with its own alerts, its own thresholds, and its own analysts. Each of those systems can be excellent on its own terms and still miss the behaviour that matters, because the behaviour does not live inside any single one of them.

Consider an order placed and cancelled repeatedly on a lit venue to create a false impression of demand, while the trader quietly fills the real position elsewhere. To the equities system, the cancellations look like ordinary order management. To the derivatives system, the fill looks like a normal trade. Only when you line the two up on a single clock does the intent become obvious. That alignment is the whole game.

What cross-market manipulation looks like

Spoofing and layering across venues

The classic pattern, now spread across more than one book. Pressure is applied in one place and the benefit is taken in another. Detecting it means correlating order events and trades that no single venue feed contains on its own.

Wash trades and self-dealing

Trades that create activity without changing economic ownership, often routed to look like arms-length deals between unrelated parties. Catching these means resolving who is really behind each side, across accounts and entities.

Cross-product manipulation

Move the underlying to profit on the derivative, or the other way around. The signal is the relationship between two instruments over a short window, which is invisible if you only ever look at one of them.

Communications next to trading

The message that says what the trade was for. Pulling trade and communications data into the same timeline turns a suspicious pattern into an explainable case, which is what a regulator ultimately asks for. A pattern on its own raises a question. The same pattern next to a chat message that explains it answers one.

Where surveillance programmes go wrong

The failures are predictable, and they are rarely about the detection logic itself.

• They bolt each new market onto a stack of separate single-market systems and quietly expect analysts to join the dots by hand.
• They tune for coverage, drown in false positives, and train their own analysts to treat alerts as noise.
• They treat explainability as a reporting afterthought rather than something designed into the pipeline from the first feed.
• They underinvest in the unglamorous normalisation layer, then wonder why cross-market detection is unreliable.

Every one of those is a design decision made early, and every one of them is expensive to unwind later. The good news is that the reverse is also true. Get the foundation right and the detection layer has something solid to stand on.

Manipulation hides in the gaps between venues, so detection has to span them.

What a modern surveillance stack needs

One clock and one schema

Everything starts with normalisation. Feeds from different markets arrive in different formats, with different timestamps and different identifiers. Before you can detect anything across them, you have to put every event on one clock and one schema, with sequencing you can trust to microseconds where it matters. This is unglamorous data engineering, and it is the foundation the rest of the system stands on. It is the same discipline we bring to any modern data platform.

A correlation and detection engine

With clean, aligned data, the detection layer can look for relationships rather than isolated events: the same actor across venues, the same instrument across products, the same short window where pressure and profit line up. This is where cross-market patterns become visible.

Risk scoring, not just rules

Pure threshold rules generate noise. A scoring layer that weighs how unusual a pattern is, given the actor and the context, is what separates an alert worth an analyst's time from one that is not.

Case management built for the regulator

An alert is the start, not the end. Analysts need a workflow that gathers the evidence, shows the cross-market timeline, and produces an explainable, audit-ready case. Our capital markets surveillance work is built around this end state, because the case file is what the regulator actually reads.

False positives are the real cost

Every surveillance team knows the failure mode. Thresholds are set conservatively, alerts pour in, analysts drown, and the genuinely suspicious case sits in a queue behind a thousand that are not. A system that cries wolf trains its own users to ignore it.

The way out is a feedback loop. When an analyst dispositions an alert, that judgement should feed back and tune the models, so the system gets quieter and sharper over time instead of louder. The measure of a good surveillance stack is not how many alerts it raises. It is how few it raises while still catching what matters.

Getting there is less about one clever algorithm and more about discipline. A tight feedback loop, regular review of which rules and thresholds actually produce good cases, and the willingness to retire the ones that do not. A healthy surveillance stack gets quieter and more precise every quarter. If yours is getting louder, something in that loop is broken, and no amount of additional alerting will fix it.

Build for the regulator's question

Detection gets the attention, but explainability is what gets tested. When a regulator asks why an alert fired, or why one did not, you need to answer with data: the inputs, the logic, the lineage from raw feed to final score. A surveillance system that cannot show its working is a liability no matter how clever its models are. Design for that question from the start, with lineage and an audit trail running through the whole pipeline, and the hard conversations get a lot easier.

This is where a lot of off-the-shelf tooling quietly falls short. A black-box score that flags an account but cannot say why is worse than useless in front of a regulator, because it creates an obligation you have no way to discharge. Explainability is not a feature bolted on at the end. It is a property of a pipeline that carried its evidence and its lineage the whole way through, from the raw venue feed to the case file an analyst hands over.

Latency and scale are a data problem first

Surveillance lives and dies on the data layer. The detection models get the attention, but they can only ever be as good as the events feeding them. If timestamps are inconsistent across venues, if identifiers do not resolve to the same actor, or if a feed is hours late, the cleverest model in the world will miss the case or raise a false one. This is why we start every surveillance conversation with ingestion, normalisation, and sequencing rather than with algorithms.

Scale compounds the point. A serious market generates billions of events a day, and the system has to correlate across them fast enough to matter, while keeping a complete, queryable history for the cases that surface weeks later. That is a hard data engineering problem, and it is the part that determines whether everything above it works.

The scale this runs at

This is not theory for us. We build and operate data platforms at the scale capital markets demand, including more than 35 petabytes in production for one of the largest stock exchanges in the world. Surveillance at that scale is a data engineering problem first and a detection problem second, and the two have to be designed together.

If your surveillance estate is a set of single-market systems that have never been asked to talk to each other, the cross-market cases are getting past you today. Book a call and we will walk through what it would take to correlate across your venues, cut the false-positive load, and stand up to the regulator's question. You can also read more about the approach on our surveillance page and our success stories.