Back to blog
Compliance

MiCAR Article 72: What on-chain monitoring looks like in practice

TO
Team Opsion
Opsion
·April 28, 2026·7 min read
MiCAREU RegulationMarket AbuseESMA

In December 2024, ESMA published its final guidelines on detecting and reporting suspected market manipulation under MiCAR Article 72. For crypto-asset service providers operating in the EU, this is a live obligation. It requires concrete technical infrastructure, not a compliance document filed away somewhere.

What Article 72 requires

Article 72 places an affirmative duty on CASPs to detect and report any transaction or order that could constitute market manipulation. The language is broad by design. It covers wash trading, spoofing, layering, and coordinated schemes, but also any behaviour that gives a false impression of supply, demand, or price.

The ESMA guidelines tighten this further. CASPs must implement systems that flag suspicious activity in near real-time, maintain audit logs for at least five years, and submit Suspicious Transaction and Order Reports (STORs) without delay. Manual review alone is not sufficient. Automated detection is expected.

Where most compliance teams fall short

The gap between having a compliance programme and meeting Article 72 requirements is larger than most teams realise. The failure modes we see most often:

  • Monitoring only assets held on your own platform. Article 72 requires understanding the broader context, including on-chain activity that precedes or follows activity on your platform.
  • Batch-processing transaction data overnight. Near-real-time monitoring means minutes, not hours. A 24-hour detection lag is not compliant.
  • Treating monitoring as a checkbox. A system that flags everything is as useless as one that flags nothing. Precision matters.
  • No documented escalation procedure. ESMA expects a clear workflow from detection to STOR submission, with timestamps at every step.

What technical monitoring actually looks like

Effective Article 72 compliance requires monitoring at three layers at once:

Layer 1: Transaction velocity and pattern detection

Flag transactions that deviate from the historical baseline for a given wallet, asset, or trading pair. Sudden volume spikes, rapid reversal of large positions, and repeated small-to-large consolidation patterns are all worth investigating.

Layer 2: Counterparty graph analysis

Every on-chain transaction has a counterparty. Monitoring the network of addresses interacting with your customers' wallets, and flagging interactions with sanctioned entities, mixer outputs, or previously flagged addresses, is not optional under Article 72. It is the difference between reactive and proactive compliance.

Layer 3: Cross-asset and cross-chain correlation

Sophisticated manipulation schemes operate across multiple assets or chains simultaneously. A coordinated pump on a low-liquidity token on one chain, paired with short positions elsewhere, is only visible if you are watching both. Single-chain monitoring leaves systematic gaps.

MiCAR Article 72 compliance is an engineering problem as much as a legal one. The regulation expects automated, near-real-time detection across the full on-chain surface area relevant to your customers, not just your internal ledger.

The STOR workflow

When your monitoring system flags a suspicious transaction, the clock starts. ESMA expects CASPs to assess the flag promptly and, where suspicion is confirmed, submit a STOR to their national regulator without undue delay. For serious findings, this means hours, not days. The STOR must include the suspicious behaviour, the addresses involved, amounts, timestamps, and any supporting on-chain evidence.

Your monitoring infrastructure needs to output evidence packages: structured data that can be exported directly into a STOR template without manual reconstruction. If your compliance team is spending hours piecing together a timeline from raw block explorer data, your tooling is working against you.

What Opsion provides

Every Opsion alert includes a full transaction graph, counterparty risk score, and an exportable evidence pack formatted for STOR submission. Detection latency is under three seconds from block confirmation across all supported chains. Alert rules can be scoped to specific assets, counterparty types, or transaction patterns, so your team sees signals rather than noise.

If you are building or reviewing your MiCAR Article 72 compliance programme, we are happy to walk through how Opsion maps to the ESMA guidelines.

TO
Team Opsion
Opsion
More posts
Engineering
Building a sub-3-second alert pipeline across 14 chains
April 14, 2026 · 9 min
Security
The four types of on-chain risk every custodian needs to monitor
March 31, 2026 · 6 min