← GUIDES
GUIDE · CHECKLIST

Crypto deposit compliance checklist for MLROs

Published 2026-09-09 · Updated

Twelve controls for a broker MLRO, each paired with the record that shows an examiner the control ran.

This crypto deposit compliance checklist 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.

Start free sandboxTalk to us50 screenings a month free, no card.

On this page

The twelve points

Sanctions · freeze · integrity · ownership · behaviour · case · four-eyes · receipt · retention · SAR draft · fiat signals · shadow first.

  1. Sanctions screening against fresh official data, per deposit

    Every crypto-origin deposit is screened against OFAC, UK Sanctions List and EU digital-currency addresses, exact-match, with the list snapshot's hash recorded on the decision. Screening only at onboarding does not meet this point. Evidence: the snapshot hash and its fetch time on each Decision Receipt, and the re-screen when the list changes.

  2. 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 results in a hold. Evidence: the issuerFreeze coverage status and the contract read on the receipt.

  3. Transaction integrity checked on-chain

    The deposit hash exists, succeeded and is confirmed. The token is the canonical contract, the recipient is yours. Reconciliation then compares the amount with the claim. The screened party is the sender in the token log, not the transaction signer. Evidence: the transactionIntegrity dimension and the resolved sender on each transfer screening.

  4. Wallet ownership proven before any payout

    Withdrawal destinations are registered, screened and proven by 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.

  5. 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 signals never block on their own. They send the deposit to a person for review. Evidence: the signal summaries on the screening and the rule ids that fired.

  6. 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. No case is held silently or approved by timeout. Evidence: the case timeline and the monthly figures on cases opened, closed and breached.

  7. 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.

  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. Shadow mode before enforcement

    The controls run on real traffic in shadow, with decisions recorded and 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.

A practical test for each point is to pick a random deposit from last quarter. Can you produce, within minutes, the record showing the control ran on that deposit, what data it used and what was decided? A policy document saying the control exists does not pass. A screenshot from a vendor dashboard passes only if the vendor still exists and still lets you log in.

KYTGate's evidence pack for a screening is built to be that record. It holds the decision, the 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 the records 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.

Read more

Start free sandbox Talk to us

Decision-support software, not legal advice. Which obligations apply to you depends on your licence and jurisdiction; confirm with counsel. Content reflects the product as of September 2026.