Skip to main content
A KYT result is only useful once it drives a decision, produces evidence, and stands up to an audit. This page covers all three: when to run each check and what policy to attach (playbooks), how to export and keep the AML reports, and the compliance context that frames both.

​
Decision playbooks

The three checks — address, transaction, and transfer — cover most screening workflows. What differs by business is when you run them and what policy you attach to the result.

​
Where checks sit in a customer lifecycle

Every grade maps to an action through one shared decision matrix. Keep a single version of it in your internal policy rather than one per product line.

​
Crypto exchanges

Screen deposits, withdrawals, and users’ external wallets.
  • When you run it. An address check on any wallet a user registers for withdrawals, gated on the grade. A transaction check on every incoming deposit TxID before crediting — on Bitcoin, a transfer check to isolate the flow that actually reached your deposit address inside a multi-output transaction. An address check on the destination before broadcasting a withdrawal.
  • What to read first. The Direct transfers table: it names the service behind a deposit, which is your input for counterparty due diligence and Travel Rule information gathering.
  • Typical policy. Low — auto-credit. Moderate — hold for enhanced due diligence. High — freeze, escalate, archive the report in the case file.

​
Neobanks and fintechs

Verify the source of crypto funds before they touch fiat rails.
  • When you run it. When a customer sells crypto or funds an account from a crypto source, run an address check on the originating wallet before crediting fiat.
  • What to read first. The tier composition. A banking partner reviewing your file will look at how much of the inflow is licensed-exchange exposure and whether any high-risk categories are present at all.
  • Typical policy. Combine KYT with Dataspike KYC and AML Screening so identity and fund-source screening live in one audit trail, and re-screen active customers’ wallets on a schedule.
  • Why it matters. Documented, explainable screening of crypto inflows is what protects the banking relationship when correspondent banks or auditors ask.

​
Payment gateways and PSPs

Check the origin of funds before accepting a payment.
  • When you run it. A transaction check on each incoming payment — or a transfer check for the specific payer → merchant flow — before confirming the payment to the merchant. Batch address checks on merchant settlement wallets on a schedule, respecting the rate limits.
  • What to read first. The High tier. For a payment you are about to confirm irreversibly, presence beats percentage.
  • Typical policy. Keep the PDF per accepted payment as evidence of screening; decline or hold before acceptance rather than clawing back afterwards.

​
OTC desks and brokers

De-risk large trades before execution.
  • When you run it. Before quoting or settling a block trade, an address check on the counterparty wallet: attribution, lifetime volumes, and the full exposure breakdown.
  • What to read first. The category breakdown, manually. On a large ticket a small percentage still represents significant absolute value — 1% of a 10M trade is 100k.
  • Typical policy. Archive the report with the trade record, and re-screen recurring counterparties before each significant trade rather than relying on a past result.
  • Why it matters. One tainted settlement can freeze funds at the receiving exchange and trigger inquiries. A pre-trade check takes seconds and produces evidence you can show.

​
What every playbook shares

  • One policy, written down. Grades are only useful if the action per grade is agreed in advance, not decided per case.
  • Any High-tier exposure is a trigger, independent of the overall grade.
  • Archive the report and the decision. The PDF evidences the assessment; your file evidences the judgment.
  • Re-screen. A stored result describes the chain at the moment it was run, nothing more.
All of these workflows run over the same REST API — every check available in the dashboard is available programmatically, so manual review tooling and automated screening share one source of truth.

​
Exporting and storing AML reports

Every KYT check can be exported as a self-contained, timestamped AML PDF report — suitable for compliance files, internal audit, banking partners, and as supporting evidence attached to SAR/STR filings.

​
Downloading a report

Dashboard. Open the check history and click the download icon at the end of any row. The report reflects the check as of the moment it was run. API.
Transaction reports are available at the equivalent /kyt/checks/transaction/{id}/report path. You need the check id returned when the check was submitted, which is why storing that id alongside your own records is worth doing at integration time.

​
What is in a report

Reports are generated for the selected asset only. A USDT (TRC-20) report does not describe the native TRX activity of the same address.

​
Sharing reports outside your team

Reports are written to stand on their own: the band legend and the meaning of each tier are printed on the document, so a banking partner or auditor can read it without access to the dashboard. Two things to keep in mind:
  • The footer is the provenance. Do not crop it — the timestamp and generating account are what make the report evidential.
  • A report is point-in-time. When sharing an older report, state the date of assessment; if the relationship is ongoing, run a fresh check instead.

​
Retention

  • Archive the PDF for every check that supports a business decision — onboarding approval, deposit acceptance, withdrawal release, escalation.
  • Keep reports for at least 5 years, in line with common AML/CFT record-keeping requirements, or longer where your jurisdiction requires it.
  • Store the check id with the file so the result can be re-fetched and cross-referenced.
  • Record the decision, not just the report. The PDF evidences the assessment; your case file should evidence who decided what, and on what basis.

​
Compliance context

Wallet and transaction screening is a core control expected of virtual asset service providers (VASPs), crypto-asset service providers (CASPs), and financial institutions handling crypto flows. KYT gives you the operational tooling for that control: automated risk assessment, explainable results, and audit-ready evidence.
This section describes how KYT supports compliance workflows. It is product documentation, not legal advice — your obligations depend on your license, jurisdiction, and business model, so align your screening policy with your compliance counsel.

​
Regulatory frameworks KYT supports

  • FATF Recommendations. FATF’s risk-based approach expects VASPs to identify and assess the ML/TF risk of transactions and counterparties. KYT operationalizes this with per-check risk scores, category-level exposure analysis, and named counterparty identification.
  • EU AMLD5/6 and MiCA-era supervision. EU-regulated CASPs are expected to run transaction monitoring, apply enhanced due diligence to higher-risk situations, and keep records that evidence their decisions. KYT’s grades map naturally onto EDD triggers, and every check can be archived as a PDF report.
  • Travel Rule workflows. The Direct Transfers table names the services one hop away from a screened address — supporting counterparty identification and the information gathering that Travel Rule processes require. KYT is a screening tool, not a Travel Rule messaging protocol; it complements, rather than replaces, your Travel Rule solution.
  • Record-keeping. Reports are timestamped, attributable, and self-contained. Store them for at least 5 years (or longer where required) as evidence of your screening control.

​
Where KYT fits in an AML program

  • Onboarding — screen customer wallets as part of initial due diligence, alongside identity verification (Dataspike KYC) and sanctions/PEP screening (Dataspike AML Screening).
  • Ongoing monitoring — screen deposits and withdrawals as they happen; re-screen stored addresses periodically since scores change over time.
  • Escalation and investigation — use the category breakdown and Direct Transfers to substantiate escalations; attach the PDF report to SAR/STR filings as supporting evidence.
  • Audit and regulator interactions — the check history plus archived reports give examiners a transparent, reproducible trail of automated decisions.

​
Data handling

KYT is designed to be privacy-clean by construction: What is analyzed — exclusively public blockchain data: addresses, transaction history, fund flows, balances, volumes, timing, cluster and entity affiliations, and connections to tagged categories. KYT does not process users’ personal data as part of the on-chain analysis. What is stored — analysis results, calculated risk scores and risk factors, aggregated on-chain analytics, reports, and audit logs (within the established retention policy). Audit history is available in the platform interface, reports in PDF, and all data via API. What is not stored — user personal data, and any data unrelated to on-chain analytics. Access is protected with secure API keys, access control, and role separation, in line with standard security measures for corporate and institutional clients.

​
Explainability for regulators

Because every score is backed by a per-category exposure breakdown and a named counterparty list, you can always answer the examiner’s question: why did this address get this score, and what did you do about it? That combination — automated assessment plus documented human response — is the substance of a defensible screening control.