"Why did you accept this deposit?" — answered, months later

Every audit of a crypto funding flow eventually reaches the same question: a specific deposit, a specific date, and a request to explain the decision. Most firms answer with a screenshot and a shrug. KYTGate answers with a Decision Receipt — and the ability to replay it.

What a Decision Receipt contains

The receipt is a single, immutable record created the moment a decision is made: a hash of the exact request; the content-hash of every sanctions list snapshot in force at that moment; the full coverage matrix (which checks ran, which were partial, which weren't available); the policy version and rule that fired; every human action with actor and reason; and the final decision. It is stored append-only — there is no code path that edits a receipt.

Signed, so it can't be quietly rewritten

Each receipt is signed with Ed25519 over its canonical content. Change one character — the decision, a signal, a timestamp — and the signature no longer verifies. The public verification key is published at /api/v1/receipt-key, so an auditor can verify receipts independently, without trusting us or you. A record that could have been edited proves little; a record that provably wasn't is evidence.

Replay: the decision, reproduced

Because our policy engine is deterministic — same inputs, same rules, same outcome, no hidden state — a decision can be re-derived from its stored evidence at any time. Replay never re-queries data providers (their answers change; that would prove nothing). It re-runs the recorded inputs through the recorded policy version and shows the outcome matches the receipt. That is what turns "we checked" into "here is the check, reproduced in front of you".

Signed receipts are on by default for every screening. Request early access or read our broker compliance guide first.

General information, not legal or compliance advice.