$1,000,000 in security audit grants are live now, Apply here →

← Resource Hub

Crypto Market Monitoring: FCA Onchain Rules for Exchanges

By the Guardian team Updated 5 min read

Crypto Market Monitoring: FCA Onchain Rules for Exchanges

Quick answer. From October 25, 2027, UK crypto platform operators with £10m or more average revenue must monitor relevant wallets onchain. These are trading wallets flagged as an abuse risk and wallets reasonably identifiable as controlled by the same people.

Watch: Crypto Market Monitoring: FCA Onchain Rules for Exchanges 1:39
Video transcript

From October 25, 2027, large UK crypto platforms must look onchain, at the wallets behind suspicious trading.

Large means at least ten million pounds average annual revenue over three years. The FCA says that covers about ninety five percent of the market by revenue.

The final rules are narrower than the draft. Large platforms watch flagged trading wallets, plus wallets controlled by the same people. Monitoring starts from an alert.

Detections should cover wash trading, pump and dump, and pre-listing buying. Known code vulnerabilities can be inside information, and abuse can run through other venues.

A flagged wallet is the seed. Link and cluster related wallets, then watch and score their activity. An analyst decides on reasonable grounds, and the platform acts.

Every UK platform, large or small, must also detect material and persistent price gaps against venues that matter for price formation.

Large platforms share information on suspected abuse over a secure channel. Systems need an annual audit, and records, including decisions not to share, are kept five years.

Guardian's monitoring watches contracts, not order books. Managed Security monitors your contracts on every block, Risk Monitoring tracks who can change them, token audits map admin powers, and readiness assessments test each provision.

This is not legal advice, so confirm with counsel. Read the article for the full readiness checklist, or talk to Guardian at guardian.security.

The FCA's Market Abuse Regime for Cryptoassets (MARC) applies from October 25, 2027. PS26/9 published the final rules on June 30, 2026.

Every UK trading platform needs systems to prevent, detect and disrupt market abuse. Large platforms must also look onchain, at the wallets behind suspicious trading (CRYPTO 4.7.20R to 4.7.23G).

The final duty is narrower than the consultation draft: large platforms need not monitor the entire chain all of the time. But every platform gains a price dislocation duty.

This article explains the technical and security side of the market abuse rules in the FCA's PS26/9. It is not legal advice; confirm how it applies to you with counsel.

The Rule Text

ProvisionWhat it says
CRYPTO 4.7.20ROngoing monitoring of relevant wallets' onchain activity, plus CRYPTO 4.9 sharing
CRYPTO 4.7.21RDefines relevant wallets
CRYPTO 4.7.22RAbility to monitor onchain activity and link it to abuse
CRYPTO 4.7.23GGuidance: what to watch, and methods that may be used

Under 4.7.22R, a large platform must identify whether onchain activity could be linked to abuse on its platform, or is abuse in itself.

The guidance says monitoring may cover wallet interactions, token flows and transaction patterns. Methods may include blockchain analytics, wallet clustering and anomaly detection.

Who counts as large

A large CATP operator runs a UK QCATP and has average revenue of at least £10m a year over the previous 3 years, calculated at 12-month intervals.

Revenue covers all its activities, not just the platform, including any predecessor business. The FCA says £10m captures about 95% of the current market by revenue.

It kept the threshold despite pushback, and will keep it under review.

Which Wallets to Watch

Respondents said watching the entire chain was disproportionate. The FCA agreed and narrowed the rule. Relevant wallets are (4.7.21R):

  • wallets used to trade on the platform that its systems flag as an abuse risk; and
  • other wallets reasonably identifiable as controlled by the same person or group.

The FCA's example: a wallet holding tokens bought or sold on the platform, and that wallet's onchain buying and selling before or after.

Linked wallets can come from clustering analysis, or from intermediaries and other platforms. They need watching only once a risk has been identified, not continuously.

So the onchain layer starts from an alert, not from the chain.

Detection and Triage

Patterns to cover

The FCA names wash trading, pump-and-dump schemes and insider dealing as abuse that can happen onchain, bypassing offchain surveillance.

  • Wash trading: trades with no change in beneficial ownership, an indicator in 4.6.2R(3).
  • Pump and dump: linked wallets that accumulate onchain, then sell into a rally.
  • Pre-listing buying: admission news can be inside information (4.3.9G(1)).
  • Known vulnerabilities: a code flaw the team found testing before admission can be too (4.3.9G(4)).
  • Other venues: manipulation can run through DeFi or overseas platforms (4.6.8G).

The pipeline

  1. Seed: platform surveillance flags a trading wallet.
  2. Link: map deposit and withdrawal addresses, then cluster related wallets.
  3. Watch: wallet interactions, token flows and transaction patterns.
  4. Score: anomaly detection against normal behavior for the wallet and token.
  5. Decide: an analyst judges on reasonable grounds, not speculation (4.7.6R).
  6. Act: warn, restrict, offboard or suspend, then share or report.

The rules require software plus an appropriate level of human analysis (4.7.7R). Alerts must follow predefined parameters (4.7.11R(3)).

The FCA believes the firms likely to be large platforms already run blockchain analytics for commercial or AML purposes. That data can feed this pipeline; document how.

Outsourcing is allowed under SYSC 8 (4.7.30G). The FCA notes RegTech firms are building MARC products, but it will not endorse one.

Price Dislocation for Every Platform

The final rules added a duty for all UK QCATPs, large or small (4.7.11R(5)).

Systems must detect material and persistent dislocations between the platform's price and the public price on other venues it reasonably considers material for price formation.

The FCA says this is not specifically onchain monitoring, though it may involve it. Dislocations should trigger further investigation, alongside other controls.

  • Name the reference venues for each token, and why each matters.
  • Define "material" and "persistent" per liquidity tier.
  • Include DEX prices where they drive price formation.
  • Send alerts to the same case queue as trade surveillance.

Sharing, Audit and Records

Sharing under CRYPTO 4.9

A large platform must share information with another large platform when it suspects abuse on reasonable grounds and disclosure is necessary to detect, prevent or disrupt it.

It must share without unnecessary delay, over a secure channel. Shared details may include wallet addresses and whether the behavior was on or off chain (4.9.10G).

Good-faith disclosures that meet the conditions are shielded from civil liability, except under data protection law. There is no transition period and no prescribed data format.

Audit and records

  • An annual audit and internal review, or sooner if risk changes (4.7.31R).
  • Written documentation of the arrangements and every change.
  • Analyses, intermediary notifications and documentation kept 5 years (4.7.32R).
  • Each sharing decision, including not to share, kept 5 years (4.9.16R).

Intermediaries send suspicious order reports to platforms, not the FCA. Principle 11 still applies: platforms must tell the FCA about abuse they cannot handle themselves.

The FCA says that duty is not limited to such cases; it would still expect notice of serious or repeated abuse.

Readiness Checklist

  1. Test average revenue across all activities against the £10m threshold.
  2. Write down which surveillance alerts make a wallet relevant.
  3. Map deposit and withdrawal addresses to accounts.
  4. Choose analytics and clustering sources, and record their limits.
  5. Write detections for wash trades, accumulation and linked selling.
  6. Build price dislocation alerts for every admitted token.
  7. Stand up a secure CRYPTO 4.9 channel and a decision log.
  8. Book the first annual audit and set 5-year retention.
  9. Confirm the data protection basis for monitoring and sharing (4.7.28G).

What Guardian Does

Guardian's monitoring watches contracts, not order books. Security monitoring is a different job from market surveillance; our onchain monitoring guide covers it.

Guardian's Managed Security monitors your contracts on every block, with detections built from your estate. When something fires, a Guardian engineer responds.

Guardian's Risk Monitoring tracks what is deployed, who can change it and what drifted since review.

For listings, Guardian audits token contracts and maps admin powers; see our admission due diligence checklist. Its regulatory readiness assessment tests where you stand on each provision that applies.

Frequently Asked Questions

Which UK crypto platforms must run onchain monitoring?

Large CATP operators: firms running a UK QCATP with average revenue of at least £10m a year over the previous 3 years. Smaller platforms still need baseline surveillance and price dislocation alerts.

Do large platforms have to monitor the whole blockchain?

No. The final rules cover relevant wallets: trading wallets the platform flags as an abuse risk, and wallets reasonably identifiable as controlled by the same people.

Is wallet clustering required?

Not by name. CRYPTO 4.7.23G says methods may include blockchain analytics, wallet clustering and anomaly detection. But the rule reaches wallets controlled by the same people, so the method must find them.

How often must MARC systems be audited?

At least annually, through an audit and internal review, or sooner if the business, rules or abuse risk change (CRYPTO 4.7.31R). Records must be kept for 5 years.

Sources

Get ready for October 25, 2027

Guardian tests your controls against the UK provisions that reach your platform, and monitors your contracts' configuration and deployments as they change.