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.

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 turns a wallet address into a defensible funding decision.

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 survives an examination.

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

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, not a vendor opinion. The lists are narrow: most addresses used by bad actors are never listed, which is why 'no known match' must never be read as 'clean'.

Lists change; a wallet you accepted last month can be listed today. Re-screening against fresh list snapshots is part of screening, not an optional extra.

IN KYTGATE Daily content-hashed snapshots of OFAC, UK and EU data; exact match; daily re-screening opens a case when a past subject is newly listed. Free tool: /tools/wallet-sanctions-check.

No known match ≠ clean

The honest result of a sanctions check: nothing found on the lists we checked — not a statement that the address is safe.

Vendors like to say 'clean' because it sells. Regulators know sanctions lists cover a tiny fraction of illicit addresses. KYTGate never uses the word: the result is NO_KNOWN_MATCH, and the coverage matrix says which sources were actually consulted.

For a broker this matters at examination time: 'we found no known match on OFAC/UK/EU snapshot X on date Y' is defensible; 'the tool said clean' is not.

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

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.

Freezes are not sanctions: an address can be frozen and unlisted, or listed and unfrozen. Read both. A 'not frozen' result is not clearance.

IN KYTGATE Live contract reads (isBlackListed / isBlacklisted) on Ethereum, Tron and the native USDC chains, at every screening; free tools for USDT and USDC.

Coverage matrix

A per-dimension statement of what was actually checked: sanctions, issuer freeze, transaction integrity, processor evidence, wallet ownership, behaviour, 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

Assurance tier

How 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 makes an honest sales conversation possible: you know exactly what you are paying for when you add a provider.

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

Decision Receipt

A signed, portable record of one decision: inputs hash, list snapshot hashes, coverage, signals, policy version, decision, timestamp — Ed25519-signed.

A screenshot of a dashboard proves nothing. A receipt whose signature anyone can verify against a published public key proves the record is byte-for-byte what was produced at decision time.

It proves integrity, not correctness: the coverage matrix inside it says 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

Evidence pack

Everything 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 download, not a week of reconstruction 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

Decision replay

Re-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.

This is what makes policy changes safe: 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

Policy backtest

Running a candidate policy over stored history to count what would change — new cases, avoided cases, new blocks — before activating it.

Compliance officers tighten rules after an incident and loosen them after complaints, usually blind. A backtest shows the trade-off in numbers first.

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

Related: Decision replay · Policy version

Policy version

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

Rules must be auditable: 'which policy was in force on 12 March' has to have one answer. Versions are never edited in place; a change is 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

TECHNICAL_HOLD

The decision when a mandatory check could not be completed — the system failing closed instead of 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

BLOCK_PENDING_MLRO

Funds frozen pending the Money Laundering Reporting Officer's decision — never automatically returned.

Returning funds to a sanctioned or suspicious counterparty can itself be a breach. A block is a hold on the broker's side with a named human decision to follow; 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.

Four-eyes principle

Two different people must act to close a blocked case: one proposes, another approves.

Single-operator release of frozen funds is the failure mode examiners look for. Enforcing two identities in software — not two text fields — is what makes the control real.

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

Related: BLOCK_PENDING_MLRO

Processor evidence (approved ≠ evidence)

Your payment processor's 'approved' flag is a status. Evidence is what it was based on.

Third-party reliance does not move the obligation. If the processor screened the deposit, you still need to show what it concluded and on what — a reference you can cite. Without it, 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

Transaction integrity

Verifying 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 receipt from the chain — not trusting a screenshot — closes them.

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

Related: Settlement reconciliation

Settlement reconciliation

Comparing what the ledger credited, what the processor says it settled, and what the chain actually moved — per deposit.

Three numbers that should agree and often do not: a fee taken silently, a wrong recipient, a double credit. Reconciling them per transaction turns a monthly 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

Wallet whitelist & ownership

Registering 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. A whitelist with an ownership proof — the customer signs a message with the wallet — makes 'is this really theirs' a cryptographic fact rather than a support ticket.

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

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

Related: Behaviour rules

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 a customer over months, which is where the real signal is: fund, barely trade, withdraw elsewhere; many small deposits under a threshold; a parade of new wallets. None of this is visible on-chain alone.

Rules are stated with their thresholds and never block on their own — they route to a human.

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

Structuring (smurfing)

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

The oldest trick in AML, and easy to miss when each deposit is screened in isolation. Detecting it requires looking at the customer's deposits over a window, not the wallet.

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

Related: Behaviour rules

Re-screening (continuous monitoring)

Checking past subjects again whenever the lists change — a wallet accepted yesterday can be listed today.

Onboarding-time screening is a snapshot. Supervisors expect ongoing monitoring: when a list changes, the customers you already accepted are the ones at risk.

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

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

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 wire-transfer information. A broker receiving funds through a licensed processor is usually not the transmitting VASP — the processor is — but the broker should keep the originator/beneficiary record the processor provides, and know when it is missing.

IN KYTGATE Coverage dimension travelRule: COMPLETE when the processor signal carries originator/beneficiary data, MISSING otherwise. KYTGate does not operate a Travel Rule network.

Related: Processor evidence

Shadow mode

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

Nobody should switch a funding gate on blind. In shadow mode every real event is decided by both systems; the disagreements — and the reasons — are what you tune the policy on.

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

Related: Policy backtest

Missing a term you keep hearing from your regulator or processor? Tell us — we add what brokers actually ask about.