Crypto KYT glossary

The vocabulary of crypto funding compliance, explained for people who run a brokerage rather than a blockchain. Each entry says what the term means, why it matters to you, and where it shows up in KYTGate.

On this page

Assurance tierHow much evidence backs a decision: PUBLIC_BASELINE, PROCESSOR_ATTESTED, COMMERCIAL_ENRICHED, DUAL_SOURCE_ASSURED.

Public sources alone (lists, issuer contracts, the chain itself) are the baseline. A processor's KYT result with evidence lifts a decision to processor-attested. A commercial attribution provider adds enrichment; two independent sources agreeing is the top tier.

The tier shows what each added provider contributes, so you know what you are paying for.

IN KYTGATE Computed from the coverage matrix; shown on every screening and in evidence packs.

Behaviour rules (funding lifecycle)Deterministic, explainable rules over the broker's own data: deposit → trading → withdrawal patterns.

Exchanges see a wallet once. A broker sees the same customer over months, and that history carries the useful signal: funding, barely trading and withdrawing elsewhere, many small deposits under a threshold, or a steady stream of new wallets. None of this is visible from on-chain data alone.

Each rule states its threshold. Rules never block on their own. They route the case to a person.

IN KYTGATE Pass-through, structuring, wallet churn, foreign-wallet withdrawal, large first deposit, shared wallet; fed by /api/v1/events.

BLOCK_PENDING_MLROFunds held until the Money Laundering Reporting Officer decides. They are never returned automatically.

Returning funds to a sanctioned or suspicious counterparty can itself be a breach. A block is a hold on the broker's side, followed by a decision from a named person. Closing such a case requires two different people (four-eyes).

IN KYTGATE Automatic case with four-eyes closure; STR/SAR is the officer's call, documented in the timeline.

Coverage matrixA per-dimension statement of what was actually checked: sanctions, issuer freeze, transaction integrity, processor evidence, wallet ownership, behaviour and the Travel Rule.

Most tools compress everything into one score. A coverage matrix keeps the dimensions apart and gives each a status (COMPLETE, PARTIAL, MISSING, STALE, NOT_AVAILABLE) so 'we checked' means something specific.

It is also how a policy fails closed: if a mandatory dimension is MISSING (the RPC was down, the list is stale), the decision is a TECHNICAL_HOLD, never a silent pass.

IN KYTGATE Returned on every screening and stored in the Decision Receipt; drives the policy's mandatory-coverage rule.

Related: TECHNICAL_HOLD · Assurance tier

Decision ReceiptA signed, portable record of one decision. It holds the inputs hash, list snapshot hashes, coverage, signals, policy version, decision and timestamp, signed with Ed25519.

A dashboard screenshot proves nothing. Anyone can check a receipt's signature against the published public key, which shows the record is byte-for-byte what was produced at decision time.

The signature shows the record has not changed. It does not show the decision was right. For that, the coverage matrix inside the receipt states what was and was not checked.

IN KYTGATE Every decision. Public key at /api/v1/receipt-key; in-browser verifier at /tools/receipt-verifier; PDF and JSON evidence packs.

Related: Evidence pack · Decision replay

Decision replayRe-deriving a past decision from the inputs stored at the time, under the policy version that governed, without asking any provider again.

If your policy engine is a pure function of stored inputs, any past decision can be reproduced exactly, and 'what would policy X have decided' becomes answerable. Providers are never re-queried, so the answer cannot drift with today's data.

It also makes policy changes safer, because you can backtest a candidate against months of real decisions before activating it.

IN KYTGATE POST /api/v1/replay; backtest panel on the policy page; built-in rule sets are versioned and frozen so old decisions stay reproducible.

Related: Policy version · Policy backtest

Evidence packEverything an examiner needs about one decision in one file: the case, the screening, signals, the append-only timeline and the signed receipt.

Regulators and banks ask 'show me why you accepted this deposit'. The answer should be a file you can download, rather than a week spent reconstructing events from logs and emails.

Two formats: a human-readable PDF and a machine-readable JSON with verification instructions.

IN KYTGATE Per case in the console; per screening via the API.

Related: Decision Receipt

Four-eyes principleTwo different people must act to close a blocked case: one proposes, another approves.

Examiners look specifically for frozen funds released by a single operator. The control only works if the software enforces two separate user accounts, rather than two names typed into text fields.

IN KYTGATE Console user accounts; the same account cannot propose and approve.

Related: BLOCK_PENDING_MLRO

Issuer freeze / blacklist (USDT, USDC)Tether and Circle can freeze any address on their contracts; a frozen address cannot move that stablecoin.

Both issuers maintain an on-chain blacklist and act on law-enforcement requests. A frozen address is the strongest public signal short of a sanctions listing, and it is readable live from the contract, with no vendor in between.

A freeze is not a sanctions listing. An address can be frozen and unlisted, or listed and not frozen, so check both. A 'not frozen' result does not clear the address.

IN KYTGATE Live contract reads (isBlackListed / isBlacklisted) on Ethereum, Tron and Avalanche (USDT) and Ethereum, Base, Arbitrum, Polygon, Avalanche and Optimism (USDC), at every screening; free tools for USDT and USDC.

KYT (Know Your Transaction)Screening and monitoring the crypto transactions and wallets a customer funds with: the transaction-side complement to KYC.

KYC answers 'who is this person'. KYT answers 'where did this money come from, where is it going, and does the pattern make sense for this person'. For a broker accepting USDT deposits, KYT is the control that lets you justify accepting or refusing funds from a given wallet.

In practice it has four parts: screen the counterparty (sanctions, issuer freezes, attribution), verify the transaction on-chain, decide under a written policy, and keep evidence that stands up in an examination.

IN KYTGATE The whole product. Every screening returns assessment, coverage and decision, and produces a signed Decision Receipt.

List snapshot (content hash)A dated, hashed copy of a sanctions list as it was when a decision was made.

To prove 'this address was not listed when we checked', you need the list as it was, not as it is. Hashing each snapshot and recording the hash in the receipt makes the claim verifiable.

IN KYTGATE Every sync writes a content-hashed snapshot; receipts reference it; the free tool shows it.

Related: Decision Receipt · Re-screening

No known matchThe result of a sanctions check that finds nothing. It means the address is not on the lists checked. It does not mean the address is safe.

Some vendors report 'clean' because it reassures buyers. Regulators know that sanctions lists cover a tiny fraction of illicit addresses. KYTGate does not use the word. The result is NO_KNOWN_MATCH, and the coverage matrix shows which sources were consulted.

For a broker this matters in an examination. 'We found no known match on OFAC/UK/EU snapshot X on date Y' can be backed by records. 'The tool said clean' cannot.

IN KYTGATE Assessment values are NO_ADVERSE_SIGNAL / ADVERSE_SIGNAL / PROVIDER_ERROR; the free tool prints the exact list snapshots used.

Policy backtestRunning a candidate policy over stored history to count what would change (new cases, avoided cases, new blocks) before activating it.

Compliance teams tend to tighten rules after an incident and loosen them after complaints, usually without knowing the effect. A backtest shows the trade-off in numbers before the change goes live.

IN KYTGATE Policy page → backtest; results list every decision that would change, with the rule that fired.

Related: Decision replay · Policy version

Policy versionAn immutable, named rule set. Every decision records which version governed it.

Rules must be auditable, so 'which policy was in force on 12 March' must have a single answer. Versions are never edited in place. A change creates a new version, and the old one stays available for replay.

IN KYTGATE Versioned rules in the console with server-side guardrails (a policy that would allow a sanctioned address is refused).

Related: Decision replay · Policy backtest

Processor evidenceWhat a payment processor's decision was based on. The processor's 'approved' flag on its own is only a status.

Relying on a third party does not transfer the obligation. If the processor screened the deposit, you still need to show what it concluded and on what basis, with a reference you can cite. Without one, coverage for processor evidence is MISSING and the assurance tier stays at baseline.

IN KYTGATE POST /api/v1/processor-signals with an evidenceRef; without one, processorEvidence = MISSING.

Related: Assurance tier · Coverage matrix

Re-screening (continuous monitoring)Checking past subjects again whenever the lists change: a wallet accepted yesterday can be listed today.

Screening at onboarding is a point-in-time check. Supervisors expect ongoing monitoring, because when a list changes, the risk sits with customers you have already accepted.

IN KYTGATE Every 6 hours: fresh list snapshots, then every subject screened in the last 90 days is checked; a new match opens a case.

Sanctions screening (crypto)Checking a wallet address against addresses published by sanctions authorities: OFAC, the UK's OFSI, the EU.

Authorities publish specific cryptocurrency addresses tied to designated persons and entities. A match is a legal fact rather than a vendor's opinion. The lists are narrow. Most addresses used by bad actors are never listed, so 'no known match' must never be read as 'clean'.

Lists change, and a wallet you accepted last month can be listed today. Re-screening against fresh list snapshots is part of the control.

IN KYTGATE Content-hashed snapshots of OFAC, UK and EU data refreshed at least every 6 hours; exact match; re-screening every 6 hours opens a case when a past subject is newly listed. Free tool: /tools/wallet-sanctions-check.

Related: No known match · Re-screening · List snapshot

Settlement reconciliationComparing what the ledger credited, what the processor says it settled, and what moved on-chain, per deposit.

The three numbers should agree, and often do not because of a silent fee, a wrong recipient or a double credit. Reconciling them per transaction turns a month-end accounting surprise into a same-day case.

IN KYTGATE POST /api/v1/reconcile; mismatches annotate the deposit's case and fire a webhook.

Related: Transaction integrity

Shadow modeRunning a new control alongside the existing process without enforcing it, to measure agreement and false positives first.

A funding gate should not be switched on without evidence of how it will behave. In shadow mode, every real event is decided by both systems. You tune the policy on the disagreements and their reasons.

IN KYTGATE Send your own decision with each screening; the console shows the agreement matrix, potential false positives and misses.

Related: Policy backtest

Structuring (smurfing)Splitting an amount into several smaller transactions to stay under a reporting or review threshold.

One of the oldest laundering techniques, and easy to miss when each deposit is screened in isolation. Detecting it means looking at all of a customer's deposits over a time window, rather than at one wallet.

IN KYTGATE Behaviour rule: several sub-threshold deposits within 24h whose total crosses the threshold → REVIEW.

Related: Behaviour rules

TECHNICAL_HOLDThe decision returned when a mandatory check could not be completed. The system fails closed rather than guessing.

A sanctions list older than the policy allows, a node that did not answer, a provider error on a mandatory dimension: none of these should become an ALLOW by accident. The hold says 'we do not know yet', and a human decides.

IN KYTGATE One of four decisions: ALLOW, REVIEW, BLOCK_PENDING_MLRO, TECHNICAL_HOLD. There is no automatic reject; funds are never returned by software.

Related: Coverage matrix

Transaction integrityVerifying that the deposit transaction exists, succeeded, is confirmed, touched the real token contract and matches the amount credited.

Fake or reused transaction hashes, counterfeit 'USDT' contracts and amount mismatches are everyday fraud in funding flows. Reading the transaction receipt from the chain, instead of relying on a screenshot, stops them.

IN KYTGATE Mandatory for transfer subjects; settlement reconciliation compares ledger, processor and on-chain amounts.

Related: Settlement reconciliation

Travel Rule (FATF Recommendation 16)The obligation on virtual-asset service providers to transmit originator and beneficiary information with transfers above a threshold.

The crypto equivalent of the payer and payee details on a wire transfer. A broker receiving funds through a licensed processor is usually not the transmitting VASP, because the processor is. The broker should still keep the originator and beneficiary record the processor provides, and know when it is missing.

IN KYTGATE Coverage dimension travelRule: COMPLETE when the processor signal carries both originator and beneficiary data, PARTIAL when it carries one, MISSING otherwise. Recorded as received, not verified. KYTGate does not operate a Travel Rule network.

Related: Processor evidence

Wallet whitelist & ownershipRegistering a customer's wallets in advance, proving they control them, and paying out only to approved ones.

Payouts to a wallet the customer typed into a form are the riskiest leg of a broker's flow. With a whitelist and an ownership proof, where the customer signs a message with the wallet, the question of whether the wallet is really theirs is settled cryptographically instead of through a support ticket.

A wallet shared by several customers of the same broker is a classic mule pattern and should be flagged immediately.

IN KYTGATE POST /api/v1/wallets, EIP-191 ownership proof, pre-withdrawal check; the shared-wallet behaviour signal.

Related: Behaviour rules

Missing a term you keep hearing from your regulator or processor? Tell us. We add the terms brokers ask about.