Crypto deposit compliance checklist — 12 points for a broker MLRO
Twelve controls, each stated as something you can show an examiner rather than describe. Print it, tick it, keep the evidence.
This list is not a legal requirement in any jurisdiction; it is the set of controls KYTGate enforces or records, written as questions an MLRO can put to their own operation. Each point says what the control is, why it is on the list, and what evidence would satisfy it. Where your regulator expects more or less, your policy governs — check with counsel.
On this page
The twelve points
Sanctions · freeze · integrity · ownership · behaviour · case · four-eyes · receipt · retention · SAR draft · fiat signals · shadow first.
- Sanctions screening against fresh official data, per deposit
Every crypto-origin deposit is screened against OFAC, UK OFSI and EU digital-currency addresses, exact-match, with the list snapshot's hash recorded on the decision. "Screened at onboarding" is not this control. Evidence: the snapshot hash and its fetch time on each Decision Receipt, and the re-screen when the list changes.
- Issuer freeze read live from the official contract
USDT and USDC deposits are checked against Tether's and Circle's on-chain blacklist at the moment of the decision, not from a cached label. A failed read is a hold, not a pass. Evidence: the issuerFreeze coverage status and the contract read on the receipt.
- Transaction integrity: the chain is the truth, not the webhook
The deposit hash exists, succeeded, is confirmed, the token is the canonical contract, the recipient is yours and the amount matches the claim. The token-log sender, not the signer, is the screened party. Evidence: the transactionIntegrity dimension and the resolved sender on each transfer screening.
- Wallet ownership proven before any payout
Withdrawal destinations are registered, screened and proven — EIP-191 signature or micro-transfer — before funds leave. A declaration is recorded as a declaration. Evidence: the wallet's ownership state and method, and the gate response stored with the pre-withdrawal screening.
- Behaviour rules that name their thresholds
Pass-through, structuring, wallet churn, round-tripping, third-party funding and velocity are evaluated per customer with explainable signals, each stating the threshold it used. Behaviour alone never blocks; it sends a human to look. Evidence: the signal summaries on the screening and the rule ids that fired.
- A case for every non-ALLOW decision
REVIEW, BLOCK_PENDING_MLRO and TECHNICAL_HOLD each open a case that must be closed with a recorded outcome — RELEASE, REJECT or NO_ACTION — and an SLA. Nothing is held silently and nothing times out into approval. Evidence: the case timeline and the monthly figures on cases opened, closed and breached.
- Four-eyes on releases, overrides labelled
Releasing funds on a BLOCK decision is an MLRO override: a second person confirms, and the receipt, evidence pack and webhook say so. Evidence: the override flag and both names on the closure event.
- A signed receipt for every decision
Each decision is an Ed25519-signed record of the subject, the coverage matrix, the signals, the policy version and the decision, verifiable by anyone with the public key and stored append-only. Evidence: the receipt itself, and a verification run in the free in-browser verifier.
- Retention set, legal hold available, deletion logged
Evidence is kept for the period your regulator expects (default seven years), can be placed under legal hold, and its eventual deletion is itself audited. Evidence: the tenant's retention setting and the deletion entries in the audit log.
- A factual STR/SAR draft, reasons left to the MLRO
When a case must go to the FIU, the factual bundle — addresses, hashes, amounts, timeline, coverage, list hashes, receipt — is generated from stored rows, and the reasons-for-suspicion section is empty for the MLRO to write. Evidence: the draft export and its audit entry. Filing obligations are yours; check with counsel.
- Fiat signals in the same timeline
Card and bank events — chargebacks, declines, name mismatches, new instruments — sit next to crypto events for the same customer, so crypto-in / fiat-out patterns and shared instruments are visible. No card numbers or payer names are stored, only tokens and booleans. Evidence: the customer's event timeline and the fiat rules that fired.
- Shadow mode first, enforce second
The controls run on real traffic in shadow — decisions recorded, your process still deciding — and the agreement report shows where they were stricter or looser than you before anything is enforced. Evidence: the shadow agreement report and the audited switch to enforce.
Using the list
Tick a point only when you can produce the evidence named for it, for a deposit picked at random.
The honest test for each point is a random deposit from last quarter: can you produce, within minutes, the record that shows the control ran on that deposit, with what data, and what was decided? A policy document that says the control exists does not pass. A screenshot from a vendor dashboard passes only if the vendor still exists and still lets you in.
KYTGate's evidence pack for a screening is designed to be that record — decision, coverage matrix, every signal, the timeline including four-eyes closure, and the signed receipt with verification instructions. The monthly report summarises the same points across the tenant. Neither replaces your policy or your judgement; they are what you attach to it.
Questions
Is this checklist a regulatory requirement?
No. It is the set of controls KYTGate enforces or records, phrased as questions an MLRO can put to their own operation. Which obligations apply to you depends on your licence and jurisdiction; check with counsel and let your own policy govern.
What counts as evidence for each point?
A record you can produce for a specific deposit: which data was checked, at what time, under which policy version, and what was decided by whom. Each point on the list names the record that would satisfy it — a receipt, a coverage status, a case timeline, an audit entry.
Do we need all twelve on day one?
The list is ordered roughly by how often examiners ask, but it is not a sequence. Running in shadow mode first lets you see which points already hold in your existing process and which do not, on real traffic, before anything is enforced.