Your bank asks in writing how you screen crypto deposits
This arrives as a questionnaire or as a paragraph in an e-mail, and the deadline is short. The questions are always the same underneath: which sources, how current, what happens on a match, who decides, and how would you show us.
It is tempting to answer with a description of the process, but a description is only a claim. What ends the exchange is a document about one real decision that the reader can check without taking your word for it.
What happens
- Send one real decision
An Evidence Pack is a PDF about a single screening: what was checked, against which published snapshots by content hash, what was not checked and what that leaves open, which policy version applied, what was decided, by whom, and the signed receipt.
- Send an expiring, revocable link
A share link has an expiry you choose, can be revoked on its own and records every access in the audit log. The shared copy replaces staff names with stable pseudonyms, so four-eyes closure can still be checked without naming your people to a third party. Its last page lists what was withheld, so the recipient does not have to take the redaction on trust.
- Let them verify the signature themselves
The public key is served at a fixed URL, and a browser verifier checks the receipt locally. The reader can confirm the answer without trusting the sender.
- Point to the live sources page
The question "how current is your list data?" is answered by a page that reads the snapshots and their ages, rather than by a sentence in a policy document.
A real response
REAL OUTPUT · The published sample Evidence Pack is a real pack, produced by the same code that produces a customer's, over a screening that never happened. Its receipt is properly signed, by a key whose private half is published alongside it on purpose. Anyone can produce a document like it, so holding one proves nothing. A real pack is signed by a key that never leaves the runtime.
GET /api/public/sample-evidence-pack → the PDF an examiner would read GET /api/public/sample-receipt → the same decision as JSON, with its public key GET /api/v1/receipt-key → the key a REAL pack verifies against
Open the pack and read the section headed "what was not checked, and what that leaves open". That section is what makes the document worth sending, because it records the gaps as well as the checks.
The snapshot hashes are in the receipt. Your bank can ask a second vendor to compare against the same published snapshot and get the same answer.
What this does not do
KYTGate is decision-support software, not a licence, an audit opinion or legal advice. The pack evidences what was decided and on what basis; it does not certify that the decision was correct.
A shared copy withholds internal notes and staff names by design. If your bank requires unredacted internal deliberation, that is a conversation to have before you send a link.
Next
Questions
Yes. Fill the reporting entity in Settings and the pack carries your legal name, registration number and jurisdiction in its header. The decision is yours, and the document should say so.
Nothing stops forwarding, which is why every access is logged, every link expires, and any link can be withdrawn on its own without affecting the others.
One e-mail link gives you an isolated tenant and an API key. The screen that shows the key also shows a first call with a real listed address already in it. The sandbox includes fifty screenings a month on real data and is deleted after seven days.