> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dataspike.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Working with Results

> Turn a KYT result into action: decision playbooks by industry, exporting and storing AML reports, and the compliance context behind it all.

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](#decision-playbooks)), how to export and keep the [AML reports](#exporting-and-storing-aml-reports), and the [compliance context](#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

| Moment                           | Check                               | Gate                                                |
| -------------------------------- | ----------------------------------- | --------------------------------------------------- |
| Onboarding / wallet registration | Address                             | Activation of the account or the withdrawal address |
| Incoming deposit                 | Transaction, or transfer on Bitcoin | Crediting the balance                               |
| Outgoing withdrawal              | Address of the destination          | Broadcasting the transaction                        |
| Periodic review                  | Address                             | Continuation of the relationship                    |
| Escalation / investigation       | Any, re-run                         | Case disposition and SAR decision                   |

Every grade maps to an action through one shared [decision matrix](/wallet-checks-kyt/how-to-read-a-kyt-report#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.

<Note>
  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.
</Note>

***

## 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.**

```bash theme={null}
curl -X GET "https://api.dataspike.io/api/v4/kyt/checks/address/YOUR_CHECK_ID/report" \
  --header "ds-api-token: YOUR_API_KEY"
```

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

| Section                          | Address report                                                     | Transaction report                  |
| -------------------------------- | ------------------------------------------------------------------ | ----------------------------------- |
| Header — asset, network, subject | Token, network, address                                            | Transaction type, TxID, block, date |
| Attribution                      | Owner and Type of the address                                      | Sender and Receiver, each with Type |
| Volumes                          | Balance, Sent, Received                                            | —                                   |
| Verdict                          | Risk Score, grade, plain-language interpretation, band legend      | Same                                |
| Exposure by tier                 | High / Moderate / Low / Unknown totals with explanations           | Same                                |
| Category breakdown               | *Payments* — every entity category with its share, grouped by tier | Same                                |
| Direct transfers                 | Named 1-hop counterparties with amounts sent and received          | —                                   |
| Footer                           | Generation timestamp (UTC), generating account ID, page numbers    | Same                                |

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.

<Note>
  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.
</Note>

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