ERRNA expert insight
Crypto Exchange Market Surveillance: A Compliance Head's Go/No-Go Validation Guide
Crypto exchange market surveillance is the combination of systems, people, and procedures that detect, investigate, and escalate abusive trading on a venue you operate: wash trading, spoofing and layering, coordinated price ramping, and misuse of confidential listing information. It is a different control from AML transaction monitoring. A platform can pass an AML review and still have no credible way to notice that two linked accounts are trading with each other to fake volume.
This guide is written for one reader: the compliance head who has to show a regulator, an auditor, or a board that market abuse detection actually works, not merely that a tool was purchased. It does not give legal advice, and your obligations depend on your license, jurisdiction, and the assets you list. What it gives you is a way to think about the problem, a proposed control map, and a set of all-required go/no-go controls you can test before you sign off.
- Scope: centralized and hybrid venues that match orders or arrange transactions in digital assets.
- Outcome: a defensible answer to the question, "How do we know our surveillance would catch it, and how do we know it is still running?"
- Method: regulatory anchors from IOSCO's final policy recommendations for crypto and digital asset markets and Article 92 of MiCA as published by ESMA, translated into engineering and workflow checks.
Key Takeaways
- Surveillance is not AML. AML monitoring watches funds and customers. Market surveillance watches orders, cancellations, and behavior across accounts. You need both, with separate data and separate owners.
- Silence is not evidence. Zero alerts means "clean" only if you can prove the data feed was complete. Treat missing or unverifiable input as an unknown, never as a pass.
- Order lifecycle data decides everything. Placements, modifications, cancellations, and rejections matter as much as executed trades. Internal ledger transfers matter as much as on-chain ones.
- Workflow integrity is part of the control. Alerts, case decisions, and regulator reports must be deduplicated, tenant-scoped, tamper-evident, and reconciled after timeouts, not blindly retried.
- Use all-required controls, not a score. A summed readiness number can hide one fatal gap. The go/no-go table in this guide treats every control as mandatory.
- Ownership must be explicit. On white-label and SaaS exchanges, the contract and runbook must say who detects, who decides, who reports, and who owns the personal data involved.
What Exchange Market Surveillance Covers, and What It Does Not
Key takeaway: Market surveillance answers "is someone distorting this market?" AML answers "is someone moving illicit funds?" Fraud and security monitoring answer "is someone attacking our customers or systems?" Merging the three into one dashboard usually weakens all of them.
Traditional securities markets have long separated these disciplines. Crypto venues often collapse them because the same small team owns everything and the same vendor sells "compliance." The result is a program that is strong on onboarding and sanctions screening and thin on the behavior that regulators associate with market integrity.
IOSCO's final report is useful here because it is explicit about what surveillance should include. Its market surveillance recommendation points to timely surveillance of transactions and orders, controls for prompt remedial action such as suspending trading, systems to detect and report suspicious transactions and orders, information sharing between relevant markets, and identification of malicious actors from cyber, financial crime, and market integrity standpoints. It also stresses oversight of both on-chain and off-chain activity, including internal recordkeeping changes in omnibus accounts.
| Control domain | Question it answers | Primary data | Does not replace |
|---|---|---|---|
| Market surveillance | Is trading behavior manipulative or abusive? | Order lifecycle events, trades, account linkages, reference prices | AML monitoring, fraud controls |
| AML transaction monitoring | Do deposits, withdrawals, and counterparties indicate illicit finance? | On-chain transfers, fiat rails, KYC risk data, Travel Rule data | Order-level abuse detection |
| Fraud and account takeover monitoring | Is an account or session being abused? | Device, session, authentication, and payment signals | Market abuse reporting |
| Security monitoring | Is infrastructure or custody under attack? | Logs, key operations, network telemetry | Behavioral surveillance |
| Material non-public information (MNPI) controls | Can insiders misuse listing or order-flow knowledge? | Access logs, information barriers, restricted lists | Detection after the fact |
The boundary matters legally as well as operationally. In its final report on draft technical standards under MiCA, ESMA noted that suspicious transaction and order reports should concern market abuse, and should not cover other fraud without an identifiable connection to market abuse, such as scams, payment fraud, or account takeover. If your case management mixes these categories, you will either over-report or under-report. Confirm how your own authority treats the distinction.
If your AML side is mature, link it to this work rather than rebuilding it. Our guide on real-time AML transaction monitoring for digital asset exchanges covers the funds-flow side. This article covers the order-flow side.
Why Most Surveillance Programs Look Fine Until Someone Tests Them
Key takeaway: Programs fail because they were designed to be installed, not to be proven. The common pattern is a purchased rule pack, tuned until alert volume feels manageable, with no independent evidence that real abuse would surface.
Three approaches recur across digital asset platforms. Each is understandable. Each leaves a gap that a competent examiner or internal auditor can find in an afternoon.
| Typical approach | Why teams choose it | Where it breaks |
|---|---|---|
| Extend the AML tool to "cover" trading | One vendor, one contract, one dashboard | AML tools see transfers and customers, not order placement and cancellation sequences |
| Buy a rule pack and tune down noise | Fast to deploy, familiar alert format | Thresholds are tuned to reduce workload, not to prove detection; there is no seeded test of whether known patterns fire |
| Rely on price and volume anomaly dashboards | Cheap, visible to product and risk teams | Shows that something moved, not who acted, how accounts relate, or what the order lifecycle looked like |
The underlying reason is structural. Manipulation on a venue is mostly visible in what was attempted, not only what settled. A spoofing pattern lives in orders that were placed and cancelled. A wash-trading ring lives in relationships between accounts that look unrelated on the surface. MiCA's Article 92 reflects this by referring to reasonable suspicion regarding an order or transaction, including any cancellation or modification thereof. A system built only on settled trades cannot see the behavior the rule describes.
Five questions to ask in the first week
- Can we reconstruct, for any account and any minute, every order placed, modified, cancelled, and rejected?
- Do internal transfers between customer accounts and omnibus structures appear in the surveillance data, or only on-chain movements?
- When did we last replay a known manipulative pattern and confirm that an alert fired?
- Who can close an alert without a second reviewer, and is that decision recorded with a reason?
- If the data feed stopped for six hours last Tuesday, would anyone have known?
If more than one answer is "we assume so," the program has not yet been validated. That is a normal starting point, not a disgrace, but it is not a position to sign a readiness statement from.
A Proposed Five-Layer Control Map for Exchange Surveillance
Key takeaway: Think in layers: data capture, detection, triage, escalation and reporting, and governance. A weakness in any lower layer silently invalidates every layer above it.
The map below is a proposed design for structuring a surveillance program. It is not an established Errna methodology or a regulatory standard. It is a way to assign ownership and to decide where to test.
| Layer | Purpose | Required evidence | Typical owner |
|---|---|---|---|
| 1. Data capture | Complete, timestamped, tamper-evident record of orders, trades, internal transfers, and reference data | Coverage reconciliation against the matching engine and ledger | Engineering with compliance sign-off |
| 2. Detection | Scenarios and statistical models that surface suspicious behavior | Scenario inventory, versioned rules, seeded test results | Compliance analytics |
| 3. Triage and investigation | Human analysis of alerts with documented rationale | Case records, reviewer identity, decision reasons, aging report | Surveillance analysts |
| 4. Escalation and reporting | Remedial action and regulator reporting where required | Approved payload, verified acknowledgment, deadline tracking | Compliance head or MLRO-equivalent |
| 5. Governance | Periodic review, change control, training, independent testing | Review minutes, change log, test reports | Compliance head, internal audit |
Scenario inventory: start with behaviors, not vendor features
A scenario inventory forces you to say which abusive behaviors you are trying to detect, what data each needs, and where your blind spots are. The list below is a starting set, not an exhaustive catalog.
| Scenario | Minimum data | Common blind spot | Reviewer's first question |
|---|---|---|---|
| Wash trading and self-matching | Trades with account, beneficial-owner links, device and funding relationships | Rings that use funding paths or devices, not only shared KYC identity | Is economic ownership of both sides the same? |
| Spoofing and layering | Full order lifecycle with microsecond-level ordering, cancel and modify events | Cancellation events not retained in the surveillance store | Was the cancelled liquidity placed with intent to trade on the other side? |
| Coordinated price ramping | Cross-account order flow, new-account clusters, off-platform signals | Looking at one account at a time | Do these accounts share timing, funding, or onboarding traits? |
| Manipulation of reference prices | Last-trade and index inputs, thin-book periods | Index feeds treated as trusted without monitoring | Did activity target the price used for margin or settlement? |
| Insider misuse of listing or order-flow information | Access logs for listing pipeline, restricted lists, staff-linked accounts | Staff and affiliate accounts not mapped to trading accounts | Did someone with access trade ahead of an announcement? |
| Abuse around market-maker programs | Program terms, designated account lists, quote obligations versus behavior | Permanent exemptions that nobody revisits | Is this activity within the program's intent and still approved? |
| Distributed-ledger behavior relevant to your platform | On-chain data for assets you list, deposit and withdrawal patterns | Assuming on-chain behavior is out of scope | Does this affect transactions that reach us? |
That last row deserves a note. MiCA's Article 92 refers to aspects of the functioning of distributed ledger technology, such as the consensus mechanism, where circumstances might indicate market abuse. ESMA's report is careful to say the expectation is not ongoing monitoring of the consensus mechanism as a whole, but monitoring in relation to transactions that reach the person with the obligation. Read the final adopted text for your jurisdiction and scope accordingly.
Your execution quality evidence also feeds this layer. A venue that can prove fair trading and execution quality already captures much of the order-level data that surveillance needs. Reuse it deliberately, but keep an independent copy for investigators.
Data, Identity, and Privacy: The Inputs That Decide Everything
Key takeaway: Detection quality is capped by input quality. Model every input as covered, gap, or unknown. An unknown input must block sign-off for the affected market, never be treated as a pass.
What the surveillance store must contain
- Order lifecycle events: new, amend, cancel, reject, partial fill, full fill, with a sequence number from the matching engine and a timestamp from a source you can describe and test.
- Trades: both counterparties' accounts, order identifiers, fees, and any maker-taker flags.
- Internal ledger movements: account-to-account transfers, omnibus allocations, and adjustments. IOSCO specifically highlights transactions settled on a platform's internal books that never appear on a public ledger.
- Reference and market data: index inputs, external venue prices used for risk or settlement, and the listing and market-maker program register.
- Identity and relationship data: KYC identity, beneficial owners, device and session links, funding source links, and staff or affiliate flags.
- Access logs for sensitive information: who could see unannounced listings, delistings, or large client orders, and when.
Coverage reconciliation: the control that makes silence meaningful
A coverage reconciliation compares what the matching engine and ledger say happened with what surveillance ingested, per market and per time window. The numbers below are illustrative only and are not drawn from any real platform.
| Illustrative window | Engine order events | Surveillance ingested | Difference | Status |
|---|---|---|---|---|
| Market A, hour 1 | 1,000,000 | 1,000,000 | 0 | COVERED |
| Market B, hour 1 | 240,000 | 239,412 | 588 | GAP, unexplained until a root cause is recorded |
| Market C, hour 1 | 180,000 | No count received | Unmeasurable | UNKNOWN, treated as no-go for this market |
Notice what is not here: a tolerance percentage. A small gap can hide the very cancellations that matter. The rule is that every difference gets an explanation, a resolution, or a documented, owner-approved exception with an expiry date. A missing count is its own state, not a zero.
Privacy ownership and sensitive identifiers
Identifiers are themselves sensitive. Account IDs, device fingerprints, and wallet addresses, once linked to a verified person, can be personal data in many jurisdictions. A surveillance program concentrates exactly those links. Decide, in writing and with counsel:
- Who owns the data in the legal sense: the licensed operator, the platform vendor, or both under defined roles.
- What leaves your boundary. If an external analytics vendor processes alerts, prefer pseudonymous keys and keep the re-identification map in-house.
- How long records are retained given both regulatory record-keeping expectations and data subject rights, and who resolves conflicts between them.
- Who can search the store. Investigators need broad access. Everyone else should not have it. Log every query.
For the identity side of this problem, see how a fail-closed design treats unknown KYC outcomes. The same principle applies here: an unverifiable relationship between accounts is a finding to record, not a reason to assume independence.
On multi-tenant white-label or SaaS exchanges, add one more rule: alerts, evidence, and case notes must be tenant-scoped. Cross-tenant pattern detection by a platform vendor is a privacy and contractual question, not a free feature. Settle it before launch.
From Alert to Regulator Report: Keeping the Workflow Honest
Key takeaway: An alert is a durable record, not a message. Create it once, decide it with a reason, and treat a regulator submission as a consequential mutation: claim it atomically, record verified acknowledgment, and reconcile before any retry after a timeout.
A state model that separates unknown from failed
| State | Meaning | Allowed next | Terminal? |
|---|---|---|---|
| OPEN | Alert created, awaiting review | UNDER_REVIEW | No |
| UNDER_REVIEW | Assigned to an analyst | CLOSED_NO_ACTION, ESCALATED | No |
| CLOSED_NO_ACTION | Closed with reviewer, reason, and second-review rule applied | Reopened only with new evidence | Yes, unless new evidence |
| ESCALATED | Referred for report decision or remedial action | REPORT_APPROVED, CLOSED_NO_ACTION | No |
| REPORT_APPROVED | Payload frozen and hashed | SUBMITTING | No |
| SUBMITTING | One worker holds the claim | ACKNOWLEDGED, REJECTED_BY_AUTHORITY, SUBMISSION_UNKNOWN | No |
| SUBMISSION_UNKNOWN | Outcome could not be confirmed | ACKNOWLEDGED or REJECTED_BY_AUTHORITY after reconciliation | No |
| ACKNOWLEDGED | Authority receipt verified and stored | None | Yes |
| REJECTED_BY_AUTHORITY | Authority refused the payload | New approved payload version | Yes for that payload |
Two states carry most of the risk. SUBMISSION_UNKNOWN means completion could not be confirmed. It is not success and it is not verified failure. ACKNOWLEDGED must mean you hold a verifiable receipt from the authority's channel, not merely that your HTTP call returned without an exception.
Illustrative sketch: atomic alert creation and report claiming
The sketch below is illustrative PostgreSQL-style SQL. It is not an official regulator or vendor API contract, and real reporting channels differ in whether they support idempotency references or status lookups. The design points are what matter: deduplication, the outbox record, and the alert row are written in one transaction; the claim is a conditional update, not a read followed by a write; and the report is bound to an approved payload hash.
-- Illustrative only. Not an official regulator or vendor API contract. -- 1) Create the alert once per tenant and detection window, and record the -- outbox event in the same transaction. BEGIN; WITH new_alert AS ( INSERT INTO surveillance_alert (tenant_id, alert_key, rule_id, rule_version, window_start, window_end, evidence_hash, state) VALUES ($1, $2, $3, $4, $5, $6, $7, 'OPEN') ON CONFLICT (tenant_id, alert_key) DO NOTHING RETURNING alert_id, tenant_id ) INSERT INTO outbox (tenant_id, topic, aggregate_id, payload) SELECT tenant_id, 'alert.opened', alert_id, $8 FROM new_alert; COMMIT; -- alert_key is derived from tenant, rule, rule version, entity set, and -- detection window. A later, genuinely different window produces a new key. -- If the same key arrives with a different evidence_hash, append an evidence -- revision for review; never overwrite silently. -- 2) Claim an approved report for submission with a conditional update. UPDATE regulatory_report SET state = 'SUBMITTING', claimed_by = $worker_id, claim_expires_at = now() + interval '10 minutes' WHERE tenant_id = $1 AND report_id = $2 AND state = 'APPROVED' AND approved_payload_hash = $3; -- One affected row: this worker owns the claim. Zero rows: do nothing. -- 3) If the claim expires or the call times out, move to SUBMISSION_UNKNOWN, -- not back to APPROVED. Reconcile against the authority's own -- status or receipt before any resend.Rules that keep this safe
- Tenant-scoped identity: every key includes the tenant. One tenant's alert must never collide with, or be visible to, another's.
- Immutable approved payload: once approved, the report body is hashed. Any change creates a new version and a new approval. Reusing the same operation identity with a different payload is rejected.
- Atomic claim: concurrent workers cannot both submit. Use a conditional update or a lease on the target row, not a read-compare-then-write in application code.
- No blind retry after a timeout: reconcile first. If the channel offers a status query or receipt lookup, use it. If it does not, escalate to a human with the evidence and the deadline, and record what was done.
- Terminal failure is explicit: an authority rejection is a terminal state for that payload. It triggers correction and re-approval, not an automatic resend loop.
- Deadline awareness: MiCA refers to reporting without delay. Track the clock from the point of reasonable suspicion as your policy defines it, so that an unknown submission state is escalated while time remains.
- Remedial actions are mutations too: suspending an account or a market, as IOSCO's recommendation contemplates, needs the same identity, authorization, and reconciliation discipline as a report.
If you are reviewing how your teams handle ambiguous outcomes elsewhere, our pieces on unknown withdrawal outcomes and order entry timeouts apply the same reconcile-before-retry principle to funds and orders.
Why This Fails in the Real World: Common Failure Patterns
Key takeaway: Capable teams fail here because of governance and plumbing gaps, not carelessness. The scenarios below are composite and illustrative, not reports about any specific client.
Pattern 1: The feed that quietly lost a new order type
An exchange ships a new conditional order type. The matching engine emits the events to its internal log, but the surveillance connector was never updated to understand them. For weeks, alert volume on that market is low, and the weekly dashboard looks calm. Nobody is negligent. Product owned the release, engineering owned the connector, compliance owned the rules, and no one owned the question "did anything we ship change what surveillance can see?"
Why intelligent teams still fail: release processes check functional correctness, not downstream observability. Without a coverage reconciliation that runs continuously and a change-control gate that includes compliance, silence looks like safety.
Pattern 2: The permanent market-maker exemption
To launch liquidity on a new pair, the venue suppresses self-match and quote-cancel alerts for two designated accounts. The exemption is sensible at launch. A year later the program terms have changed, one account is controlled by a different entity after a corporate restructuring, and the exemption is still in the rules engine with no owner and no review date.
Why intelligent teams still fail: exemptions are treated as configuration, not as risk acceptances. A control register that requires an owner, a rationale, and an expiry for every suppression closes this gap.
Pattern 3: The alert queue that learned to age out
Analysts are told to keep the queue under a target size. Over time, low-severity alerts are bulk-closed after a set number of days, with a generic reason. The records exist, but they do not show that a human evaluated anything. An examiner sampling closed alerts finds identical rationales across hundreds of cases.
Why intelligent teams still fail: workload pressure and a queue-size metric create the incentive. The fix is to staff to the volume, tune scenarios with documented before-and-after evidence, and measure decision quality, not just closure speed.
Pattern 4: The listing pipeline nobody mapped to trading accounts
The listing committee tracks who has access to unannounced listings, but the list of staff-linked and affiliate trading accounts was never joined to the surveillance store. A suspicious pre-announcement position is invisible because no one can see that the account belongs to someone with access. IOSCO's guidance on material non-public information calls for identifying and classifying such information, restricting access on a need-to-know basis, and periodically reviewing the access list. Our token listing go/no-go framework covers the listing decision itself. Surveillance must cover what happens before it is public.
What these patterns share
- The control existed on paper, but nobody could prove it was still operating.
- Ownership crossed team boundaries without a named owner at the seam.
- The metric that was easy to see (alert count, queue size) was mistaken for the metric that mattered (detection capability).
Go/No-Go Validation Controls, Build-Buy-Hybrid, and What to Do Next
Key takeaway: Every control in the table below is mandatory for the markets and tenants in scope. Failing any one is a no-go for that scope until fixed or formally accepted by the accountable executive with an expiry. There is no summed score, because an average can hide one fatal gap.
Mandatory go/no-go controls
| # | Control | Evidence to produce | No-go if |
|---|---|---|---|
| 1 | Complete order lifecycle capture | Reconciliation of engine events to surveillance store per market, including cancels, amends, and rejects | Any market has an unexplained gap or an unmeasurable (unknown) count |
| 2 | Internal ledger coverage | Evidence that account-to-account and omnibus movements are ingested | Only on-chain movements are visible |
| 3 | Scenario inventory mapped to data | Documented scenarios, each with required data and a named owner | A scenario has no data source, or no owner |
| 4 | Seeded detection test | Replay of synthetic or historical patterns for each scenario, with alert results retained | A known pattern did not produce an alert and was not explained |
| 5 | Feed-health alerting | Proof that a stopped or degraded feed raises an incident | Feed failure can occur without a human being notified |
| 6 | Exemption register | Every suppression has an owner, rationale, and expiry | Any suppression is undocumented or expired |
| 7 | Alert and case integrity | Deduplication keys, reviewer identity, reasons, and second-review rules, with tamper-evident history | Alerts can be closed without a recorded, individual reason |
| 8 | Report workflow reconciliation | Tested handling of timeouts, authority rejection, and verified acknowledgment storage | A timeout can trigger an automatic resend, or acknowledgment is not independently verifiable |
| 9 | Remedial action authority | Documented, tested ability to restrict accounts or suspend a market, with approvals | No tested path exists, or it depends on one unavailable person |
| 10 | Information barriers for MNPI | Access list, periodic review record, and staff-account mapping | Staff and affiliate accounts are not linked to the surveillance store |
| 11 | Privacy and tenancy ownership | Data ownership, vendor sharing limits, retention rules, and tenant isolation tests | Cross-tenant visibility or unclear data ownership exists |
| 12 | Governance cadence | Scheduled review, change control involving compliance, and staff training records | No review date, or releases bypass compliance review |
Not sure which of the twelve controls would fail today?
A short, structured review of your data capture, alert workflow, and reporting path usually reveals the answer faster than a new tool.
Talk to Errna about scoping a surveillance and compliance review for your platform.
Contact UsBuild, buy, or hybrid: decide after the controls are defined
Teams often start with the vendor question. Reverse the order. Once the twelve controls are written down, you can judge any option against them.
| Option | Where it fits | Hidden failure modes | Questions to settle |
|---|---|---|---|
| Build in-house | Unusual order types or products, strong engineering and data science capacity | Scenario coverage gaps, key-person dependency, no independent test | Who tests it independently? Who maintains scenarios as markets change? |
| Buy a specialized surveillance product | Faster path to a mature scenario library and case tooling | Connector blind spots, opaque model logic, vendor access to personal data | Can the vendor show coverage reconciliation, rule versioning, and exportable evidence? |
| Hybrid: vendor detection, in-house data and governance | Most licensed operators with moderate engineering capacity | Unclear seams between vendor alerts and in-house cases | Who owns the data pipeline, the exemption register, and the reporting workflow? |
| Platform-provided tooling on a white-label or SaaS exchange | New operators who inherit a vendor's venue stack | Assuming the vendor carries the regulatory obligation; tenant data sharing | What does the contract say about detection scope, reporting responsibility, and data ownership? |
Verify any vendor's product capabilities and certification claims against its primary documentation, and distinguish what a vendor states from what your own testing shows. A vendor's certification typically describes the vendor's own controls, not your regulatory compliance. If you are choosing a venue platform at the same time, review how crypto exchange development choices affect which data you can capture, and what crypto analytics and compliance dashboards and KYC and AML compliance work you can connect to it.
2027 Update: What to Re-Check as Rules Mature
Rules for market abuse in digital assets are still being implemented and interpreted. In the EU, MiCA's market abuse provisions sit alongside technical standards and supervisory guidance, and ESMA's published report on the draft standards is a useful indicator of supervisory thinking: it discusses analyzing every order and transaction, automated alerts followed by human analysis, written and regularly assessed systems and procedures, and proportionality to scale. Treat that report as context and check the adopted text and your national authority's guidance. Outside the EU, requirements depend on your regime and license. The evergreen discipline is the same in any year: re-confirm scope, re-run your seeded tests after material change, and keep the control register current.
Where Errna can help, and its limits
Errna's crypto compliance services are a natural place to scope a coverage review, scenario inventory, and workflow design like the one proposed here. Specific deliverables, tooling, and fit depend on your platform and jurisdiction and are confirmed during discovery. Legal interpretation of your obligations remains with your counsel and your regulator.
Conclusion: Five Actions Before You Sign Off on Surveillance Readiness
Market surveillance is credible only when you can prove that data was complete, that known patterns would fire, and that every decision is recorded. The following actions turn this guide into a plan.
- Write the scenario inventory. List the abusive behaviors relevant to your products, the data each needs, and a named owner. Mark any scenario without a data source as a gap.
- Run the coverage reconciliation per market. Resolve every unexplained difference. Treat any unmeasurable feed as a no-go for that market.
- Replay seeded patterns. Confirm an alert fires for each scenario, and keep the results as evidence. Repeat after material releases.
- Test the report path under failure. Simulate a timeout and a rejection. Confirm that the team reconciles before resending and that acknowledgments are verifiable.
- Assign ownership in writing. Confirm who owns detection, case decisions, regulator reporting, remedial action, and personal data, including on any white-label or vendor-supplied component.
None of these actions require a new product purchase. All of them make a later purchase safer.
About Errna
Errna is a blockchain and cryptocurrency technology company founded in 2003, with teams in several countries and a focus on regulation-aware platforms for exchanges, enterprise blockchain, and digital asset infrastructure. Errna states that it maintains ISO 27001 and CMMI Level 5 process credentials and SOC 2 accreditation; these describe Errna's own delivery and security processes and do not certify any client platform's regulatory compliance. This article is not legal advice. Reviewed by Errna Expert Team.
Frequently Asked Questions
What is crypto exchange market surveillance?
It is the set of systems, procedures, and human review that detect and escalate abusive trading on a venue, including wash trading, spoofing and layering, coordinated price manipulation, and insider misuse of non-public information. It relies on order lifecycle data and account relationships, not only on completed transfers.
How is market surveillance different from AML transaction monitoring?
AML monitoring focuses on customers and funds flows, such as deposits, withdrawals, and counterparties. Market surveillance focuses on orders, cancellations, and trading behavior across accounts. They use different data, different scenarios, and often different reporting channels, so one does not substitute for the other.
Does MiCA require market abuse detection systems?
Article 92 of MiCA 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 suspicion without delay to the competent authority. Whether and how it applies to you depends on your authorization and activities, so confirm scope with counsel and your authority.
What data does a surveillance program need at minimum?
At minimum, plan for:
- Order lifecycle events: placements, amendments, cancellations, rejections, and fills
- Trades with both counterparty accounts
- Internal ledger movements, including omnibus allocations
- Reference and index price inputs
- Identity and relationship data such as beneficial owners, devices, and funding links
- Access logs for listing and other sensitive information
Can a white-label or SaaS exchange outsource surveillance to the vendor?
A vendor can supply tooling, but the contract must state detection scope, who reviews alerts, who files reports, and who owns the personal data. In many regimes the licensed operator carries the regulatory obligation. Confirm this with counsel, and require tenant-scoped data isolation and exportable evidence.
How do you test that surveillance would catch abuse without waiting for real abuse?
Replay synthetic or historical patterns for each scenario through the production detection path in a controlled environment, then confirm that an alert fires and is recorded. Keep the results, and repeat after material changes to matching, order types, or rules.
What should happen if a report submission to the regulator times out?
Do not resend automatically. Mark the outcome as unknown, meaning completion could not be confirmed, then reconcile against the authority's status or receipt channel. If none exists, escalate to a human with the approved payload and the deadline. Resend only when reconciliation shows the first submission was not received, or when the authority's process explicitly permits it.
Should scams and account takeovers be reported as suspicious orders or transactions?
Not automatically. In its report on draft MiCA technical standards, ESMA noted that market abuse reports should not cover other types of fraud without an identifiable connection to market abuse, such as scams, payment fraud, or account takeover. Those events may still trigger other obligations, so classify cases carefully and check your authority's guidance.
Would your surveillance survive a seeded test tomorrow?
If you cannot show complete data, a tested alert path, and a reconciled reporting workflow, now is the time to find out, not during an examination.