MiCA Market Abuse Surveillance: Detecting Wash Trading and Spoofing on Your Own Order Book

MiCA quietly made every crypto-asset service provider running an order book responsible for policing its own venue for manipulation. Most operators are still treating that as a reporting form to fill in, rather than a detection system to build.

Since Title VI of the Markets in Crypto-Assets Regulation became applicable on 30 December 2024, the market-abuse regime that equities and derivatives venues have lived under for years now reaches crypto-assets admitted to trading. The prohibitions on insider dealing and market manipulation are one thing; the operational obligation is the one that lands on the technology function. Article 92 requires any person professionally arranging or executing transactions in crypto-assets to have effective arrangements, systems and procedures to prevent and detect market abuse, and to report reasonable suspicions to the competent authority without delay. If you run a matching engine, that means you have to watch your own book.

What MiCA actually obliges you to detect

Article 91 defines market manipulation in terms a surveillance engineer can work with. It captures transactions or orders that give, or are likely to give, false or misleading signals as to supply, demand or price, unless carried out for legitimate reasons. It captures orders placed to a trading platform, including their cancellation or modification, that disrupt the functioning of the platform or make it harder for others to identify genuine orders. Wash trading sits in the first limb; spoofing and layering sit squarely in the second. Article 89 handles insider dealing, which is a different detection problem and outside the scope of order-book pattern analysis.

The reporting mechanism is a suspicious transaction and order report, the STOR familiar from the Market Abuse Regulation, adapted by ESMA for crypto under the Article 92 technical standards. Two things about it matter to the build. First, the obligation covers orders, not just executed trades, including cancellations and modifications, so your surveillance cannot only look at the fills. Second, ESMA’s guidelines on prevention and detection of market abuse, finalised in 2025, make clear that a form is not a system. A regulator will ask what your arrangements actually monitor, how alerts are generated, and how a human decides whether to file. This is the same evidential posture that already governs how a CASP is expected to demonstrate its best execution and order handling — the control has to be visible in the data, not asserted in a policy.

Why equities surveillance does not port cleanly

The instinct is to buy an off-the-shelf surveillance platform built for equities and point it at the crypto book. It half-works, and the half that fails is the half that matters. Traditional surveillance assumes a closed venue: identified participants, transactions that settle inside the same regulated perimeter, and a clean mapping from account to legal entity. A crypto order book has none of those luxuries by default.

Manipulation in crypto hides in the seams. A price signal manufactured on your off-chain matching engine can be settled, or reinforced, by on-chain activity your surveillance never sees. The same beneficial owner can operate through several exchange accounts and several self-custodied wallets, so the account-to-entity mapping that equities surveillance takes for granted is precisely the thing you have to reconstruct. And because the same asset trades on dozens of venues simultaneously, a pattern that looks benign on your book alone may be one leg of a cross-venue scheme. MiCA’s own text anticipates this: Article 92 expects the receiving authority to pass a report to the competent authorities of other trading platforms concerned. The regulation assumes fragmentation. Your detection logic has to as well.

Wash trading: the signal and the entity-resolution trap

A wash trade is a transaction that changes no beneficial ownership: the same party, or coordinated parties, sits on both sides. The naive detection is trivial and almost never the real case. Nobody sophisticated matches an order against their own single account. The signal you actually chase is self-matching across accounts that resolve to the same beneficial owner or a linked group, repeated often enough to move a volume figure or paint a tape.

That reframes the problem. The hard part is not the SQL; it is the entity resolution that feeds it. If your onboarding, KYC and wallet-attribution data do not let you cluster accounts into a resolved owner group, no query will find coordinated wash trading. Build the cluster first — from shared beneficial ownership, funding sources, device and network signals, and on-chain wallet linkage — then run detection over the cluster identifier rather than the raw account. The query below assumes that resolution has already happened and each account carries an owner_group_id.

-- Wash-trade candidates: fills where both sides resolve to the same
-- beneficial-owner group, matched within a rolling window on one instrument.
-- owner_group_id is the output of entity resolution, not the raw account.
-- Tune window, min_count and min_notional to your venue's liquidity.

WITH matched AS (
    SELECT
        t.trade_id,
        t.instrument,
        t.matched_at,
        t.price * t.quantity            AS notional,
        buy_acct.owner_group_id         AS buy_owner,
        sell_acct.owner_group_id        AS sell_owner
    FROM trades AS t
    JOIN accounts AS buy_acct  ON buy_acct.account_id  = t.buy_account_id
    JOIN accounts AS sell_acct ON sell_acct.account_id = t.sell_account_id
    WHERE t.matched_at >= now() - INTERVAL '24 hours'
)
SELECT
    instrument,
    buy_owner                           AS owner_group_id,
    count(*)                            AS self_match_count,
    sum(notional)                       AS self_match_notional,
    min(matched_at)                     AS first_seen,
    max(matched_at)                     AS last_seen
FROM matched
WHERE buy_owner = sell_owner            -- same beneficial owner on both legs
  AND buy_owner IS NOT NULL
GROUP BY instrument, buy_owner
HAVING count(*) >= 3                     -- repeated, not a one-off crossing
   AND sum(notional) >= 10000            -- drop de-minimis noise
ORDER BY self_match_notional DESC;

This is a candidate generator, not a verdict. It produces a shortlist a human analyst reviews before deciding whether the pattern is manipulation or, say, an internal treasury transfer with a legitimate reason. The HAVING thresholds are the difference between a usable alert queue and one nobody triages.

Spoofing: reading intent from the order log

Spoofing leaves almost no trace in the trade record, because the manipulative orders are cancelled before they execute. Detecting it means instrumenting the full order lifecycle — every placement, modification and cancellation, timestamped to the engine — not just the fills. The signals are behavioural: large orders resting away from the touch that are pulled the instant price approaches; a heavily skewed order-to-trade ratio on one side; genuine small executions on the opposite side to the displayed pressure; and short-lived layered orders that build a false impression of depth. None of that is visible if your surveillance only ingests executed trades, which is the single most common gap I see when reviewing a CASP’s arrangements.

The engineering consequence is a data-capture decision made early. Your matching engine has to emit an immutable, sequenced event stream for orders as well as trades, retained long enough to reconstruct an episode a supervisor asks about months later. If that stream does not exist, no amount of downstream analytics will recover the intent, and the surveillance obligation is unmet at the foundation.

The evidence a supervisor will actually ask for

When a competent authority tests your Article 92 compliance, the questions are concrete. What patterns do you monitor, and against what parameters? How are alerts generated, and by whom are they reviewed? Show the alert queue, the triage notes, the calibration history of your thresholds, and the decisions not to file as well as the STORs you did submit. A firm that can produce that trail is defensible. A firm with a purchased platform it cannot explain, or a policy with no alert stream behind it, is not. This is the same demonstrable-control standard that runs through the rest of the MiCA technology obligations a CASP has to meet, and it is exactly where firms migrating a grandfathered business onto a full CASP licence tend to find the largest build.

Surveillance is not a module you switch on. It is entity resolution, full order-lifecycle capture and calibrated detection, wired to a human review process that leaves a record. Buy the box before you have built those, and the first time a regulator asks how you would have caught the manipulation, the honest answer is that you would not.