Crypto deposits without turning your compliance file into a liability.
You are a broker, not a crypto exchange — but the moment a client funds in USDT, your regulator treats the deposit as yours to explain.
Why broker funding is a different problem
Exchanges see a wallet once and can afford to think in terms of the wallet. A broker sees a customer over months: a KYC profile, a declared income, an expected trading pattern, a set of funding wallets, a ledger, an MT5 account, and eventually a withdrawal request — often to a wallet the customer never used to deposit. The risk is rarely in the first deposit. It is in the shape of the whole lifecycle: fund, barely trade, withdraw elsewhere.
Most screening products were written for the exchange picture. They return a wallet score and stop. That leaves you assembling, by hand, the part a supervisor actually asks about: was this deposit consistent with the customer, was the tx real, did the processor's 'approved' come with any evidence, and what did you decide — under which policy — on that day.
What supervision actually asks for
The questions converge across Mauritius, Seychelles, Cyprus, the UAE and the BVI: did you screen the counterparty against current sanctions data; can you prove the on-chain transaction existed and matched what you credited; did you re-screen when lists changed; and can you reproduce the decision later. None of these is exotic. The failure mode is not doing them — it is doing them without a record that survives an examiner's follow-up question.
Third-party reliance does not move the obligation. If your payment processor screened the deposit, you still need to show what they concluded and on what evidence. An approval flag with nothing behind it is a status, not a control.
How KYTGate fits a broker stack
One API call per funding event — deposit, withdrawal request, wallet whitelist application. KYTGate verifies the transaction on-chain, screens the resolved sender against OFAC, UK and EU list data and live issuer freeze status, records what your processor asserted (and whether it brought evidence), applies your versioned policy, and returns ALLOW, REVIEW, BLOCK_PENDING_MLRO or TECHNICAL_HOLD together with a signed Decision Receipt.
Everything that is not ALLOW opens a case in a queue your compliance officer can work from — assignment, document requests, escalation, and four-eyes closure for blocks — or you can deep-link the same case from your own back office. Your data stays tenant-private; nothing about your customers is pooled.
Three situations, handled
Deposit → no trading → withdrawal to a new wallet
The classic pass-through. On-chain data alone looks fine; only the lifecycle exposes it. KYTGate records the deposit decision and the withdrawal request as linked screenings on the same customer, so the pattern is visible in the case, not reconstructed after the fact.
Processor says 'approved'
Recorded as processorAssessment APPROVED with processorEvidence MISSING when no evidence reference arrives. Your coverage matrix shows the gap honestly instead of inheriting someone else's confidence.
Wallet listed after you accepted the deposit
Daily re-screening against fresh list snapshots reopens the question automatically and creates a case — with the original receipt still intact for the day you decided.
Best fit: licensed FX/CFD brokers funding through crypto payment processors in Mauritius, Seychelles, Cyprus, UAE, BVI, Labuan or Vanuatu, with an MLRO who needs defensible records more than another risk score.
Decision-support software, not legal advice. Which obligations apply to you depends on your licence and structure — confirm with counsel.