How your compliance data is protected

Every table carries a tenant id, and every query is scoped by the API key that made the request. The key resolves to exactly one tenant and cannot be pointed elsewhere. Idempotency keys, processor signals, wallets, cases, reports and replays are all tenant-scoped. We test this instead of relying on code review. The console runs an isolation audit against the live API with two sandbox tenants, one of them seeded. Every endpoint is called with the second tenant's key against the first tenant's identifiers, and there are no-key and garbage-key probes as well. The latest run is recorded in the audit log and shown in the console. Any customer can ask for its output.

Every screening produces a Decision Receipt signed with Ed25519 over a canonical JSON of its inputs, list snapshot hashes, coverage, signals, policy version and decision. Anyone can verify a receipt in their browser at /tools/receipt-verifier without an account and without trusting us. For an adversarial audit it is better to verify on your own machine, with no page of ours involved: npx kytgate-verify receipt.json. This is an MIT-licensed package with no dependencies whose published files are its source. There is no build step, so the code an auditor runs is the code they can read. Policies are immutable versions. Built-in baselines are frozen by version, so a decision from March can be replayed under March's rules in December. Webhooks are HMAC-SHA256 signed with a per-tenant secret and a timestamp.

A signature proves KYTGate said something. On its own it cannot prove when, because the signing key is ours. So once a day every receipt written so far is hashed into an RFC 6962 Merkle tree and the root is published at /attestations and never rewritten. A number published before a deposit was taken cannot be recomputed later to cover a receipt written after it, and the holder of a receipt can fold their own inclusion proof back to that published root without asking us for anything. The claim is narrow, and the attestations page says so. The anchor proves a receipt existed, in the form you hold, before the root was published, and that it has not changed since. It does not prove the decision was right, and it says nothing about receipts that are not in the batch. A root we publish ourselves is a tamper-evident log, not third-party proof, which is why the page asks an auditor to record the day's root somewhere we do not control.

Examiners ask the same question about every configurable control: what stops the customer turning it off? Tenants write their own policies and can make them as strict as they like. Four things are refused outright. The check runs the real decision engine against synthetic inputs before the policy can be stored, instead of reading the rules. A policy that would ALLOW a direct sanctions match on full coverage is refused. A policy that would ALLOW with nothing adverse found but processor evidence MISSING is refused, because free public sources alone never prove “clean”. A default decision of ALLOW is refused, so an unmatched case can never pass silently. And a behaviour rule that would act at or below the wallet observation's severity is refused, so the signal we publish as informational cannot be quietly promoted into a blocker. Activating a new version is a single statement, so there is no moment at which a tenant has no active policy and silently falls back to our baseline.

The anchor conflicts with erasure in one place, and we resolved it in favour of the other customers. When a tenant leaves, the pointers from its receipts into the Merkle leaves are removed, but the leaf hashes stay. Deleting one would break the published root for every other receipt in that day's batch, so one tenant's retention schedule would destroy another's evidence. A leaf hash on its own identifies nobody. It is the hash of a receipt whose contents have been deleted.

The public site sets no cookies and runs no analytics. The console sets one httpOnly session cookie. Free tool queries leave no permanent record, and nothing links a query to the person who made it. What is kept is a short-lived rate-limit counter keyed to a pseudonymised IP (truncated SHA-256) and purged after 7 days. Separately, there is the cache of public chain data described above, which is keyed by chain and address and holds no identifier of the person asking. Sandbox requests store an e-mail, an optional company name and the same truncated IP hash, and a copy goes to our own inbox. Sandbox tenant data is deleted after 7 days. Wallet watch stores an address and an e-mail only after a confirmation click, and deletes the record 30 days after the person stops it. Tenant data is deleted on the tenant's retention schedule (default 7 years, legal hold available) and 30 days after a tenant closes. A full JSON export is available before that. See the privacy policy.

KYTGate fails closed. If a mandatory source (sanctions snapshot older than the tenant's limit, transaction verification) cannot answer, the decision is TECHNICAL_HOLD, never ALLOW. Sanctions lists are re-synced at least every 6 hours (the live figure is on the status page). Every scheduled job reports each step, and the console shows a red banner when lists are stale. Webhook deliveries are retried every 10 minutes with backoff. Security incidents affecting a tenant's data are notified to that tenant without undue delay and within 48 hours of confirmation, with what happened, what data, and what we did.

We spend the most effort on silent failures. A job that reports its own errors cannot report that it has stopped running, and a retired list usually keeps downloading. Three checks therefore look for silence rather than errors. A source that still fetches but whose content has not changed in a long time raises an alert. A sanctions list that its publisher had closed once sat here looking healthy in exactly this way. A separate watchdog checks that the scheduled jobs have run at all and that the database has every table the deployed code expects. Finally, we count failures of the providers that are allowed to fail. They are non-mandatory so that a slow third party never holds a deposit. If one of them fails on more than half of a day's screenings, that raises an alert too, because otherwise we would still be claiming a check that had quietly stopped working. None of this can detect our own host going down, because nothing would be left running to raise the alarm. For that, /api/health is there to be polled from outside. It returns 503 rather than 200 when the product cannot do its job.

A compliance officer needs to know whether the evidence still holds up if a vendor goes away for good. A decision you have to defend in three years was made on our platform, and by then we may not exist.

Everything needed to check a receipt is inside the export. Until recently the export said receipts were “verifiable at our verifier tool with the public key from our key endpoint”. Both of those are our URLs, so the export could only be checked while we were still answering, which is when nobody needs to check it. The export now carries the Ed25519 public key, the Merkle root of every batch your receipts sit in, and one inclusion proof per receipt. npx kytgate-verify is a single dependency-free file you can read end to end, and with those three it makes no network call at all.

Content and date. The signature proves a receipt is byte-for-byte what we produced. It cannot prove the receipt existed on the date it claims. We hold the signing key, so nothing would stop us signing something later and dating it earlier. The Merkle root and the inclusion proof answer that. Until now the proof existed only inside our database, so nobody holding an export could check the anchor. Now they can. Where a batch carries an RFC 3161 timestamp, the date does not rest on our word either.

What the export leaves out. The export lists every table it carries, every table it leaves out and why, and every receipt it could not produce a proof for, with the reason. A gap in that list is a defect in our export rather than data you do not have. Before the list existed, two tables had silently dropped out of the export.

Two things are not solved. The file bytes of documents your customers uploaded are downloaded separately rather than inlined. And the roots are worth most if you recorded them from /attestations while you were a customer, rather than taking ours at the moment you need the answer. The export itself states both.

No SOC 2 or ISO 27001 certification. No third-party penetration test yet (planned before commercial launch; the isolation audit is our own). No SSO/SAML (planned for the enterprise tier). Single-region database.

No rehearsed database restore, and no recovery time. Point-in-time restore comes with the database plan. We have not performed one, so we claim no number: no RTO, no RPO, no "typically minutes". Treat restore as untested until we have rehearsed one and can tell you how long it took. What has been rehearsed is the other half of the question, the half that protects you if KYTGate itself does not come back. See if KYTGate disappears.

A root's independent timestamp is a Bitcoin anchor, not a qualified one. Every day's Merkle root is submitted to four independent OpenTimestamps calendar servers, which aggregate it into a Bitcoin transaction; the proof is a path from the root to a block header, checkable with the reference client and your own node, trusting neither us nor any certificate authority. There are two limits. A proof takes an hour or two to confirm, and until it does that batch's row reads “not yet in a block” and evidences nothing about time. And a Bitcoin anchor carries no legal presumption of time under eIDAS, which only an accredited trust service can give; we do not ask one, because no Time-Stamping Authority publishes terms permitting a commercial product to use it for free, and we would rather tell you that than rely on a service nobody granted us. If your auditor requires a qualified timestamp, tell us and we will contract one. The code asks any RFC 3161 authority you name alongside the calendars. /attestations shows the state per batch, and the proof files are downloadable there.

If you have found something, send it to hello@kytgate.com. The machine-readable version of this is at /.well-known/security.txt (RFC 9116).

What we will do. We acknowledge a report to hello@kytgate.com within 3 working days, tell you within 10 working days whether we consider it a vulnerability and what we intend to do, and tell you when it is fixed. If you want credit on this page you will get it; if you would rather not be named, say so.

What we will not do. We will not pursue legal action, or ask anyone else to, over research that stays inside this policy — and that holds even if the report turns out to be wrong or is something we already knew. We do not require you to sign anything before reporting, and we will not ask you to keep quiet indefinitely: if we have not fixed something in 90 days, publishing is reasonable.

There is no bug bounty. We do not pay for reports, and saying so plainly is fairer than implying otherwise. If that changes it will be stated here first.

In scope. kytgate.com and its subdomains, the API, the console, and the free public tools. The published receipt verifier and the evidence-pack format are explicitly in scope: if you can make a receipt verify that should not, or read a tenant's data through any endpoint, that is the report we most want.

Out of scope, and please do not. Denial of service, load or stress testing, and anything that degrades the service for other tenants. Social engineering of our people or our suppliers. Physical attacks. Automated scanner output with no demonstrated impact. Reports about a third party's infrastructure — send those to the third party. Never use another tenant's real data to prove a point: tell us how, and we will reproduce it ourselves.

Known already, so not a finding. What we have not done yet is listed on this page, above, and each item there is a known gap rather than a discovery: no SOC 2 or ISO 27001, no third-party penetration test, no SSO, a single-region database. A report that restates one of those is welcome but will be closed as known.

Data Processing Addendum (template) · Terms · Privacy · API documentation · security.txt.