METHODOLOGY
KYT methodology: what each check does
For every check: where the data comes from, how it is compared, how often it is refreshed, what it cannot tell you, and what happens when it fails. Every screening records in its coverage matrix which of these ran and with what result. This page is the legend for that matrix. Live freshness is on the status page.
On this page
Sanctions listsOFAC / UK / EU address lists · re-synced at least every 6 h · stale snapshot → TECHNICAL_HOLD
SourcesOFAC SDN (US Treasury), the UK Sanctions List (FCDO) and the EU consolidated financial sanctions list (European Commission). Digital-currency address identifiers only.
LicencesOFAC: a work of the US Government, no copyright asserted in the US. UK: public sector information licensed under the Open Government Licence v3.0, © Crown copyright. EU: © European Union, reused under Commission Decision 2011/833/EU. We extract the address identifiers and do not alter what the publishers say. Where a list and KYTGate disagree, the publisher is right. No authority endorses KYTGate. Full source and licence review: /sanctions-data.
MethodExact match of the normalised address (EVM lowercase; Tron/Bitcoin/Solana case-sensitive) against the latest stored snapshot. No fuzzy matching, no clustering.
RefreshAt least every 6 hours (live figure on the status page). Each snapshot is stored with its address count and a SHA-256 content hash, and decisions record the hash they used. Live counts per source and chain: /sanctions-data.
LimitsLists are not exhaustive (OFAC says so itself). A designated person's unpublished addresses are not caught. NO_KNOWN_MATCH is never "clean".
On failureA source that cannot be fetched keeps its last snapshot; if the newest OFAC snapshot is older than the tenant's limit (default 48h) coverage is STALE and the decision is TECHNICAL_HOLD.
Stablecoin issuer freezesOfficial USDT / USDC contracts · live at every screening, no cache · RPC down → PARTIAL, falls to review
SourcesThe official USDT and USDC contracts: isBlackListed(address) (Tether on Ethereum and Tron), isBlocked(address) (Tether's newer contract on Avalanche) and isBlacklisted(address) (Circle), read live at every screening: USDT via JSON-RPC on Ethereum and Avalanche and via TronGrid on Tron; USDC via JSON-RPC on Ethereum, Base, Arbitrum, Polygon, Avalanche and Optimism. No freeze read exists on BNB Chain, Bitcoin or Solana, so the dimension reads NOT_AVAILABLE there.
RefreshLive at every screening, with no cache.
LimitsBinance-pegged and other bridged tokens expose no blacklist function and are not checked (hence no BNB Chain read). A freeze says the issuer acted; it does not say why.
On failureRPC unreachable → UNAVAILABLE for that token. The dimension is PARTIAL and the decision falls to review. The free tool shows UNAVAILABLE explicitly.
Transaction integrityEVM JSON-RPC receipt · read at screening time · missing, reverted or non-canonical → REVIEW
SourcesThe transaction receipt from the network's JSON-RPC (EVM chains).
MethodExists, succeeded, ≥ 12 confirmations, carries a canonical Transfer log from the official token contract; the sender is resolved from the token log, not the transaction signer, and that sender is what gets screened.
LimitsEVM only today; Tron/Bitcoin/Solana transfers are screened by address, integrity NOT_AVAILABLE. Amount comparison against the ledger is a separate step (reconciliation).
On failureHash not found, reverted or non-canonical token → tx-integrity-failure signal → REVIEW.
Wallet ownershipEIP-191 signature by the customer · once per registered wallet · proves key control at signing time only
MethodEIP-191 personal_sign of a KYTGate-generated message (tenant, customer, nonce); the recovered signer must equal the registered address. Non-EVM chains: reviewer attestation in the console.
LimitsProves control of the key at signing time, not identity, and not that the key is unshared.
Processor verdictsYour processor's posted assessment · as it arrives (30-day sweep) · approval without evidence stays MISSING; disagreements flagged as PROVIDER CONFLICT
SourcesWhat your payment processor posts to /api/v1/processor-signals: its assessment and, when it has one, an evidence reference.
MethodMatched to the screening by explicit reference or by transaction hash; the assessment enters the policy (HIGH_RISK / REJECTED block); the evidence dimension is COMPLETE only with an evidence reference; an approval alone is MISSING.
ConflictsProcessor cleared but public sources matched, or processor flagged but public sources found nothing → a labelled PROVIDER CONFLICT signal and webhook. The label never changes the decision, which the underlying facts have already set.
Behaviour rulesYour own funding events, wallets and cases · evaluated at every screening · ≥ 60 → REVIEW, never blocks alone
SourcesYour own funding events (deposits, withdrawal requests, trading summaries), your registered wallets, your open cases, never the blockchain and never other tenants.
MethodDeterministic rules with per-tenant thresholds; each fired rule states the numbers it saw. Pass-through, foreign withdrawal wallet, withdrawal with open case, structuring, wallet churn, large first deposit, dormant reactivation, rejected wallet returning, shared wallet, device/IP/bank links.
LimitsBehaviour signals reach REVIEW at severity ≥ 60 under the baseline policy and never block alone. Rules needing customer profile data (country, expected volume) are not yet implemented.
Wallet profile and funds trace (GateDNA, GateTrace)Blockscout / TronGrid / public RPC · on request · bounded by explorer page caps; never a risk score
SourcesBlockscout public explorer API instances (eth, base, arbitrum, polygon, optimism.blockscout.com) on EVM networks; TronGrid on Tron; public JSON-RPC for transaction receipts.
MethodObserved facts only: age, activity, counterparties, stablecoin share, transfers around one transaction (1–3 hops). Your registered wallets are labelled; nothing else is. Every result states its coverage and caveats.
LimitsBounded by explorer page caps; no entity attribution, no risk score. A profile or trace never labels an address good or bad.
Second opinions and attributionChainalysis on-chain oracle · read at screening · no entity attribution or taint, so those dimensions stay NOT_AVAILABLE
Chainalysis oracleThe public on-chain sanctions oracle contract is read as an additional sanctions source (exact match).
Not doneNo entity attribution, no mixer/darknet exposure, no multi-hop taint, no source-of-funds percentage. Those dimensions stay NOT_AVAILABLE until a commercial provider is connected, and the coverage matrix says so rather than implying a check that never ran.
The risk score, and its published weightsArithmetic over the signals that fired · derived on read, never stored · decides nothing
The score is a summary of findings, not a claim about a wallet. It is a pure function of the signals and the coverage matrix a Decision Receipt already stores, which is why anyone holding a receipt can recompute the number it had on the day. The weights below are the whole formula.
Formula1 − Π(1 − wᵢ·sᵢ) over every signal, where s is the severity the provider reported and w the published weight for its category, then rounded and capped at 99. Saturating rather than additive, so more findings always raise the number and never overflow it.
Weights rw-v1sanctions 1 · issuer_blacklist 1 · transaction_integrity 0.9 · processor_kyt 0.8 · commercial_risk 0.7 · behaviour 0.6 · exchange_attribution 0.3 · scam_report 0.25 · unknown 0.2
100Reserved. Only a sanctions or issuer-freeze signal at severity 90 or above reaches it, and the response says so as scoreBasis: "listing". An exact match on an official list is a fact. Shown as 94, it would invite somebody to set a threshold at 95.
ConfidenceA separate figure: the share of applicable coverage dimensions that answered. COMPLETE counts 1, PARTIAL 0.5, STALE and PROVIDER_CONFLICT 0.25, MISSING 0. UNSUPPORTED and NOT_AVAILABLE leave the denominator, because a chain with no freeze contract marks a boundary of the product rather than a failed check. When nothing is applicable, confidence is 0, never 100.
VersioningWeights are versioned like policies and old versions are kept verbatim, so changing them cannot restate history. A score recomputed from an old receipt must be asked for under that receipt's version; an unknown version returns an error rather than falling back to today's.
Not doneThe score borrows nothing from address attribution, clustering or exposure percentages, because we hold none of that data. It also has no authority. The policy engine cannot read it, there is no rule condition for it, and no threshold on it can hold a deposit. Decisions are made by the rules over the signals.
Decisions and evidencePure-function policy over stored inputs · versions immutable · Ed25519 receipts; four-eyes on BLOCK closures
PolicyPlain-JSON rules evaluated by a pure function. Every version is immutable, and built-in baselines are frozen by version, so any past decision replays under its own rules.
ReceiptEd25519 signature over canonical JSON of inputs, snapshot hashes, coverage, signals, policy version, decision; public key at /api/v1/receipt-key; browser verifier at /tools/receipt-verifier.
Human actionsAppend-only case timeline; BLOCK closures need two different accounts; a RELEASE on a BLOCK is labelled an MLRO override everywhere it appears.