For most of crypto's history, market surveillance was something an exchange did if it wanted to look serious. Under MiCA it is a condition of operating. Title VI, Articles 86 to 92, imports a market abuse regime into crypto-asset markets, and Article 92 puts the detection duty on any person professionally arranging or executing transactions in crypto-assets. If that is you, the question is no longer whether to run surveillance. It is whether what you run would survive a supervisor reading it.
This is a practical read of what the text expects the system to see.
The duty sits on activity, not on a label
Article 92 attaches to "persons professionally arranging or executing transactions in crypto-assets", a category the industry has shortened to PPAET. It is deliberately wider than "licensed exchange". Arranging counts. Executing counts. Running an order book is the obvious case, but a firm that routes client orders, or that executes against its own book, is inside the perimeter too.
The obligation is threefold: maintain effective arrangements, systems and procedures to prevent and detect market abuse, and report suspicion to your home competent authority without delay. Prevention and detection are not the same duty discharged twice. Prevention is design, the controls that make an abusive pattern hard to execute. Detection is what catches what got through anyway.
The RTS is where the real scope lives
The detail that matters is in Commission Delegated Regulation (EU) 2025/885, the regulatory technical standards on arrangements, systems and procedures for preventing, detecting and reporting market abuse under MiCA. It was published in the Official Journal on 20 August 2025 and entered into force on 9 September 2025.
Three things in it reset what a surveillance system has to cover.
Every order state, not just fills. The RTS requires analysis of each order and transaction, whether it was placed, modified, cancelled or rejected. A system that only looks at executed trades is blind to layering and spoofing by construction, because both are strategies made of orders that were never meant to fill. If your pipeline discards cancellations, you do not have a surveillance system, you have a trade reporting system.
On and off the platform, and on the ledger. The scope covers activity whether it happens on a trading platform or off it, and whether it happens on the distributed ledger. That is the sentence that breaks most existing setups. An order book surveillance product sees the venue. A chain analytics product sees the ledger. The regulation expects one view of both, and the two are not the same kind of evidence: one records intentions inside your own system, the other records settlement on a public network.
The network itself. The duty extends to other aspects of the functioning of the distributed ledger technology, including consensus events. Surveillance is no longer only about prints and quotes. Protocol behaviour and chain state are in scope.
What that means for the patterns you have to detect
The classic market abuse typologies carry over, but each one acquires an on-chain half that a venue-only system cannot see.
Wash trading. On a venue, self-trading is detectable through account linkage. On-chain, the same economic activity runs between addresses that look unrelated until you cluster them. Detecting it means resolving wallets and account identifiers to the same actor, which is an entity resolution problem before it is a surveillance problem.
Spoofing and layering. Purely order-book phenomena, and purely invisible unless you retain modifications and cancellations with enough timestamp resolution to reconstruct the book. This is the pattern most often lost to a pipeline that only ingests fills.
Insider dealing. The crypto version usually leaves a trace before the announcement rather than after it. Accumulation in an address that later turns out to be connected to a listing, a treasury decision or a protocol change. Catching it requires history you can query backwards from the event, not an alert queue you only read forwards.
Pump and dump. Coordinated accumulation, promotion, distribution. The distribution leg is on-chain and often cross-venue, so a single venue sees one third of the story and concludes nothing happened.
The report is part of the system
The RTS also specifies the templates for reporting suspected market abuse. The crypto STOR fields now include the Digital Token Identifier and, where relevant, the transaction hash. That is a small detail with a large implication: the regulator expects the report to point at a specific on-chain object, not at a narrative. If your surveillance produces an alert your analyst cannot tie to a hash, you have work to do between detection and filing.
ESMA has also published guidelines on the prevention and detection of market abuse under MiCA, which are worth reading alongside the RTS because they describe the supervisory expectation rather than only the technical minimum.
Delegation is allowed, responsibility is not
The RTS explicitly contemplates delegating prevention and detection within a group, or delegating the data analysis and alert generation, subject to conditions. This is useful, and it is how most firms will actually operate. What does not move is the reporting duty and the accountability for the arrangements being effective. Buying a system is not the same as having a system that works, and the supervisor will ask about the second.
A short checklist
If you want one pass over your current setup, these are the questions that tend to expose the gaps:
- Does the pipeline retain modified, cancelled and rejected orders, or only fills?
- Can a single alert show both the order-book activity and the on-chain flow behind it?
- Can you resolve a wallet address and a client account to the same identity when they belong to the same actor?
- Can an analyst move from an alert to a transaction hash without leaving the tool?
- If a supervisor asked why an alert was closed, is the reasoning recorded?
- Where detection is delegated, is there a written basis for it and do you still see the evidence?
None of this is exotic. It is the same discipline traditional venues built under MAR, applied to a market where half the evidence lives on a public ledger. The firms that struggle are usually not the ones with weak analytics. They are the ones running two systems that never see each other, one watching the venue and one watching the chain.
That split is the problem Seqlense Monitoring was built around, but the point stands whichever tooling you use: if the order book and the ledger are not in the same view, the patterns that cross between them are the ones you will miss.