Compliance

Crypto Exchange Compliance Requirements — Mapped to Real Controls

Every serious jurisdiction asks for the same four things: verified identities, monitored transactions, Travel Rule data-sharing, and provable governance. This page lists the requirements — FATF, MiCA, FinCEN, MAS, VARA — and shows the exact platform control that enforces each one, with the thresholds, checklists, and evidence trails examiners ask for.

Global coverage and support illustration

Global coverage

Configure policy once and adapt per jurisdiction

European Union
MiCA-ready

VASP registration support and product gating

United Kingdom
FCA-aligned

Financial promotions, TR requirements

United States
State-by-state

KYC/KYT, sanctions screening, reporting workflows

Singapore
MAS-aligned

Travel Rule and segregation controls

Hong Kong
SFC-aligned

Product suitability gating

UAE
VARA-aligned

Marketing and disclosure controls

Australia
AUSTRAC-aligned

KYC/KYT, STR workflows

Canada
CSA guidance

Leverage compliance modules and disclosures

KYC & AML

Onboarding flows with PII verification, sanctions screening, case management, and configurable risk tiers.

  • Dynamic flows: lite, standard, enhanced due diligence
  • Sanctions/PEP screening and ongoing monitoring
  • Case management with audit trails and reviewer roles
  • Data retention windows and export tooling

KYT / Chain monitoring

Connect chain‑analytics providers to score deposits/withdrawals and apply automated policies.

  • Real‑time address/entity risk scoring
  • Velocity limits and auto‑holds for risky flows
  • Reviewer queues with notes and dispositions
  • Evidence logging for audits

Travel Rule interoperability

Exchange counterparty information when required and keep evidence automatically

Policy engine

Detect applicability based on flow, jurisdiction, and thresholds.

Interoperability

Integrates with leading Travel Rule providers for secure messaging.

Evidence & audit

Signed receipts, reconciliation, and immutable logs for examiners.

Reporting

  • Suspicious activity reports drafting and approval
  • Threshold and transaction reports (configurable)
  • CSV/Parquet exports and secure data rooms
  • Programmatic access for regulators on request

Audit logs

  • Immutable event timelines with tamper‑evident hashing
  • Reviewer actions, approvals, and dispositions
  • Access reviews and certification workflows
  • Time‑boxed privileged access with full traceability

Privacy & policy templates

Jump‑start your documentation and keep versions in sync

Privacy & GDPR

Data minimization, rights workflows, encryption in transit and at rest.

AML Program

Governance, risk assessment, procedures, and testing cadence.

Terms & Disclosures

Jurisdiction‑specific risk statements and product disclosures.

TL;DR: Regulators worldwide converge on four pillars — identity, monitoring, data-sharing, and governance. The thresholds and filings differ per jurisdiction (table below), but every pillar maps to a concrete software control. If your platform can't demonstrate the control, your license application inherits a build project; if it can, the technology audit becomes a walkthrough.

The Four Pillars Every Regulator Asks About

Frameworks differ on thresholds and filings, but underneath they ask for the same four things. Get these right and every jurisdiction becomes a variation on a theme you already know.

Identity

Tiered KYC and KYB with document and liveness checks, plus sanctions and PEP screening at onboarding and continuously after. Verification tier gates what a user may do — deposit, trade, withdraw, and how much.

Monitoring

Transaction monitoring across fiat and crypto legs, blockchain analytics (KYT) on deposits and withdrawals, velocity rules, and a case path from alert to disposition to suspicious-activity report.

Data-sharing

The FATF Travel Rule: transmitting originator and beneficiary data alongside qualifying transfers, verifying counterparty VASPs, and keeping evidence of every exchange.

Governance

A written AML program, a named compliance officer, role-separated administration, immutable audit trails, independent review, and records regulators can actually inspect.

Every framework below — MiCA, FinCEN's MSB regime, MAS PSA, VARA — is a jurisdiction-specific expression of these four pillars.

Requirements and Travel Rule Thresholds by Jurisdiction

JurisdictionFrameworkTravel Rule thresholdNotable requirementsDeep dive
FATF baselineRecommendation 16USD/EUR 1,000 (guidance)VASP registration, originator/beneficiary data, counterparty due diligenceLicense guide
European UnionMiCA + Transfer of Funds Reg.No minimum between CASPsCASP authorization, prudential safeguards, white-paper dutiesMiCA guide
United StatesFinCEN MSB + state MTLs$3,000MSB registration (Form 107, biennial), four-pillar AML program, SAR/CTR filing, OFAC screeningAudit guide
United KingdomFCA registration + MLRsNo de-minimisFinancial-promotions regime, MLR registrationLicense guide
SingaporeMAS Payment Services ActSGD 1,500PSN02 AML notices, segregation of customer assetsMAS guide
UAE (Dubai)VARA rulebooksAED 3,500Activity-specific rulebooks, marketing controlsVARA guide
JapanPSA / JVCEANo thresholdExchange registration, cold-storage ratiosLicense guide
Latin AmericaCountry-specificVariesRapidly evolving; several FATF-aligned regimesLatAm guide

Figures as commonly cited in mid-2026; verify with counsel, as several are under revision. Note that outside the US, most listed figures set the point above which a fuller data set must travel — not a value below which the rule is switched off (the EU, UK, and Japan apply it to transfers of any size).

The 2025 shift worth planning around: FATF's supervisory best-practices guidance now tells authorities they may treat Travel Rule capability as a licensing prerequisite, and jurisdictions including Singapore and Hong Kong already require applicants to demonstrate it before approval. Data-sharing has moved from "post-launch obligation" to "application exhibit" — which is why it ships in the platform rather than on the roadmap.

Requirement → Control: What Actually Enforces Each Rule

This is the part most compliance guides skip, because most are written by firms that sell advice rather than infrastructure. Each row names the regulatory requirement and the specific, inspectable control in Codono's platform that enforces it:

RequirementEnforcing control
Tiered customer due diligenceKYC tiers with pluggable providers; limits and product access bound to verification level
Sanctions / PEP screeningScreening at onboarding + rescreening; blocked-jurisdiction gating at registration and per-action
Transaction monitoringVelocity rules, risk scoring, KYT connectors on deposits/withdrawals, reviewer queues with dispositions
Travel Rule data-sharingOriginator/beneficiary data fields, applicability engine per jurisdiction threshold, evidence logging
Custody safeguardsThreshold MPC signing, hot/cold segregation, withdrawal allowlists and kill-switches
Four-eyes principleMaker-checker approval queues — the initiating admin can never be the approver
Records & auditImmutable admin audit logs, double-entry ledger behind every balance change, exportable evidence
Product suitability gatingPer-jurisdiction module switches (margin, perpetuals, staking) tied to user country and tier
Solvency demonstrationStandard on-chain addresses compatible with proof-of-reserves attestations; continuous ledger-vs-chain reconciliation
Market integritySurveillance-ready trade data, per-account rate limits, and manipulation-pattern reporting
Codono admin panel: jurisdiction rule-packs with per-regime Travel Rule thresholds, IVMS101 messaging, reporting regimes, and KYC gates
Jurisdiction rule-packs in the admin panel — per-regime Travel Rule thresholds, IVMS101 data-sharing, reporting formats (goAML, AUSTRAC, FINTRAC), retention windows, and KYC gates, editable per market.
Codono admin panel: manual KYC review queue with per-tier verification statuses and document review
The KYC review queue — tiered verification statuses (L2/L3), document review, and provider-pluggable onboarding.
Codono admin panel: immutable admin audit log with per-action success and failure records, filters, and CSV export
The admin audit log — every administrative action recorded with actor, target, result, and timing; filterable and exportable for examiners.

The Operator Readiness Checklist

Before an application (or an examiner) arrives, you should be able to tick every line:

  1. Target jurisdictions chosen and the licensing path per market identified (start with the license guide)
  2. Named compliance officer with genuine authority and board access
  3. Written AML program: risk assessment, procedures, training, independent testing
  4. KYC tiers defined per jurisdiction, with limits bound to each tier
  5. Sanctions/PEP screening live at onboarding and on a rescreening cadence
  6. KYT/blockchain analytics connected on deposit and withdrawal flows
  7. Alert-to-SAR case flow rehearsed: who reviews, who files, in what timeframe
  8. Travel Rule thresholds configured per market; counterparty VASP due-diligence process documented
  9. Custody model documented: key management, hot/cold split, who approves what
  10. Maker-checker enabled on withdrawals, balance adjustments, and config changes
  11. Audit logs verified immutable and exportable; retention windows set
  12. Jurisdiction gating tested: blocked countries actually blocked, product gates enforced
  13. Policy documents versioned and consistent with what the platform actually does
  14. Incident playbook: kill-switches tested, regulator notification thresholds known

Counterparty VASP Due Diligence

The Travel Rule's least-understood obligation isn't sending data — it's knowing who you're sending it to. Before transmitting originator information, an exchange must establish that the receiving VASP is a real, regulated entity capable of protecting the data: is it licensed somewhere credible, is it sanctioned, has it demonstrated Travel Rule capability, does it actually control the address you're sending to? FATF calls this counterparty VASP due diligence, and examiners increasingly ask to see the process, not just the policy.

Operationally this means maintaining a counterparty register with jurisdiction, licensing status, and messaging capability per VASP; a risk tier per counterparty that decides whether transfers flow automatically, with additional data, or not at all; and periodic refresh, because a counterparty that was licensed last year may be sanctioned this year. The platform's jurisdiction rule-packs and evidence logging carry the enforcement side; the register discipline is an operator practice worth building before an examiner asks for it.

Proof of Reserves and Solvency Demonstration

Since 2022, "are client assets actually there?" moved from a Twitter question to an examination item. Several regimes now expect exchanges to demonstrate solvency on request: client-asset segregation, reserve attestations, and increasingly Merkle-tree proof-of-reserves that lets individual users verify inclusion of their balances.

Architecture decides how painful this is. Because the platform's MPC-custodied addresses are standard on-chain addresses, reserve attestations work with ordinary block-explorer verification and third-party auditor sampling — no exotic scripts to explain. Internally, the double-entry ledger records every balance mutation, and continuous ledger-versus-chain reconciliation means the number you attest to is a number the system checks against reality all day, not a quarter-end scramble. Liability-side proofs (the harder half of PoR) come down to exportable, complete balance snapshots — which is a query, not a project, when the ledger is the source of truth.

The Failure Modes Examiners Actually Find

Enforcement actions and examination reports repeat the same handful of findings — worth knowing because they're all preventable with configuration and staffing rather than heroics:

Unstaffed queues

Monitoring generates alerts; nobody disposes them. A backlog of unreviewed alerts is treated as no monitoring at all — worse, it's discoverable evidence that risk was flagged and ignored. Size the review team to alert volume, and tune rules so volume stays reviewable.

Policy-platform drift

The AML program says withdrawals above a threshold need enhanced review; the platform's limits were never updated to match. Examiners diff documents against configuration — keeping them synchronized is the single cheapest finding to avoid, and why versioned policy templates that mirror actual settings matter.

Thresholds set once, forgotten

Travel Rule thresholds, KYC tier limits, and velocity rules configured at launch and never revisited as regulations moved. The jurisdiction rule-pack model exists precisely so per-market updates are edits, not releases.

Admin accounts without separation

One superuser who configures limits, approves withdrawals, and edits the audit trail. Role separation and maker-checker aren't bureaucracy — they're the control examiners test first, because insider risk outranks hackers in the loss statistics.

Logs that can be edited

An audit trail the admin can modify is not an audit trail. Immutability and export capability turn "trust us" into "verify it" — the difference between a finding and a passed exam.

Market Integrity and Surveillance

Licensing regimes are converging on a fourth-and-a-half pillar that most compliance guides skim: the exchange must police its own market. MiCA imports market-abuse prohibitions directly into crypto; mature regimes everywhere expect operators to detect wash trading, spoofing and layering, self-matching, and pump-and-dump coordination — and to be able to show an examiner the detection, not just describe it.

The platform side of that obligation: complete, timestamped, exportable trade and order data (surveillance is impossible over lossy records); self-match prevention at the matching layer; per-account and per-IP rate limits that make manipulation expensive; anomaly flags for wash-trading patterns and coordinated account clusters; and circuit breakers for disorderly markets. The operator side: someone actually reviews the flags, dispositions are recorded, and repeat patterns become account restrictions and, where thresholds are met, suspicious-activity reports.

Two details win examinations here. First, surveillance must cover all venues in the platform — spot, derivatives, and P2P each manipulate differently (P2P adds off-platform payment fraud and triangulation, which is why its escrow and dispute records matter to compliance, not just support). Second, the liquidity operation itself must be clean: if the operator runs market-making accounts, they need documented mandates, separated books, and the same surveillance everyone else gets — internal accounts being exempt from monitoring is a finding waiting to happen.

What Non-Compliance Actually Costs

The enforcement record sets the stakes: Binance settled with US authorities in 2023 for over $4 billion across BSA and sanctions violations; Coinbase paid $100 million in its 2023 NYDFS settlement, half of it earmarked for compliance-program investment; BitMEX's founders paid criminal penalties on top of the exchange's $100 million resolution for operating without an AML program. The consistent pattern in every action: the failures were programmatic — missing controls, unstaffed review queues, absent records — not exotic. Which is precisely what the checklist above exists to prevent.

The Honest Part: Software Does Not Make You Compliant

No platform purchase substitutes for a license, an accountable officer, or judgment. What the platform does is change what kind of problem compliance is: from an engineering project bolted onto your launch plan, to configuration and operation of controls that already exist. Operators who have gone through licensing with Codono consistently report the same thing — the technology-audit portion stopped being the hard part. The hard part is the paperwork, as it should be.

For the regulatory landscape per market, continue with the country guides: MiCA, Dubai VARA, Singapore MAS, Latin America — or the operational guides on KYC program design and how regulators audit exchanges.

Compliance FAQ

Do you provide KYC and KYT integrations?

Yes. The platform ships with KYC providers and KYT/chain‑monitoring connectors. You can choose providers and configure policies per jurisdiction.

How does the Travel Rule work?

We interoperate with leading Travel Rule providers. The policy engine checks when the rule applies, requests/validates counterparty data, and logs evidence.

Can features be gated by jurisdiction?

Yes. A rules engine enables or disables modules (e.g., margin, perpetuals, staking) based on user country, verification level, and your risk policy.

What reporting is available?

Suspicious activity reports (drafting + review), exportable audit logs, and configurable data retention with time‑boxed access for auditors.

What are the compliance requirements for a crypto exchange?

Four pillars recur across every serious jurisdiction: identity (tiered KYC/KYB with sanctions and PEP screening), monitoring (transaction monitoring with blockchain analytics and suspicious-activity reporting), data-sharing (FATF Travel Rule originator/beneficiary exchange), and governance (a written AML program, a named compliance officer, audit trails, and periodic independent review). Licensing frameworks such as MiCA, FinCEN MSB registration, MAS PSA, and VARA each express these pillars with different thresholds and filings.

What are the Travel Rule thresholds by jurisdiction?

They differ in kind, not just amount — and conflating the two is a common compliance error. The US applies a genuine $3,000 trigger under FinCEN's BSA rule: below it, the Travel Rule does not attach. Most other regimes apply the rule to transfers of any size and use a figure only to set how much data must travel — the EU (Transfer of Funds Regulation) and UK require information on every CASP transfer, with a reduced data set permitted below roughly €1,000; Singapore's SGD 1,500 and Dubai VARA's AED 3,500 likewise mark where the fuller data set is required, not an exemption below it; Japan applies the rule with no threshold at all. An exchange serving multiple markets needs per-jurisdiction logic that distinguishes “rule does not apply” from “reduced data applies” — not a single global setting.

Can Travel Rule capability affect my license application?

Yes — FATF's 2025 supervisory best-practices guidance notes that authorities may make Travel Rule compliance a prerequisite for VASP licensing, and jurisdictions including Singapore and Hong Kong already ask applicants to demonstrate the capability before approval. Having the messaging fields, counterparty checks, and evidence logging built into your platform turns that portion of the technology audit into a demonstration rather than a build project.

What is the difference between a VASP and a CASP?

VASP (virtual asset service provider) is FATF's umbrella term used by most national frameworks; CASP (crypto-asset service provider) is the EU's MiCA equivalent. In practice an exchange is both: FATF-derived rules (Travel Rule, AML program) apply globally, while CASP authorization adds MiCA-specific requirements such as prudential safeguards and white-paper obligations for listed assets.

Does compliance software make my exchange compliant?

No — and treat any vendor who says otherwise with suspicion. Software supplies the enforcement infrastructure: KYC tiers, screening, monitoring, Travel Rule messaging, reporting, and audit evidence. Compliance itself is an operator obligation — licensing, a named responsible officer, written policies, and day-to-day judgment. The realistic goal is that your technology stops being the hard part of the application.

Ready to review our compliance controls?

Request the compliance pack with policy templates, mappings, and architecture docs.