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

# How KYT Works

> The KYT analysis pipeline step by step, plus the core vocabulary: the three check types, direct and indirect exposure, and entity attribution.

Every KYT check runs the same pipeline, whether you start it from the dashboard or the API. The result is an explainable risk score backed by a category-level breakdown — not a black-box verdict. This page covers how that pipeline works, then the vocabulary you need to read a result.

***

## The pipeline

<Steps>
  <Step title="You submit an address or transaction">
    Enter a wallet address or a transaction TxID, select the blockchain network (Bitcoin, Ethereum, or TRON) and the token — or send the same parameters in an API request. The system detects the request type and starts the appropriate analysis.
  </Step>

  <Step title="KYT aggregates on-chain data">
    The system extracts and aggregates data directly from the blockchain: transaction history, inbound and outbound fund flows, balances, volumes, fees, timing parameters, participants, and linked addresses. Only **public on-chain data** is analyzed — KYT does not process or store personal data. See [Data handling](/wallet-checks-kyt/working-with-results#data-handling).
  </Step>

  <Step title="Counterparties are attributed and clustered">
    Addresses in the fund flow are matched against Dataspike's entity database — exchanges, payment systems, DeFi protocols, mixers, darknet services, sanctioned addresses, hacked wallets, fraudulent projects, and more. Related addresses are automatically grouped into clusters and analyzed as a single entity, which improves attribution accuracy. Each identified entity carries a category from the [entity taxonomy](/wallet-checks-kyt/risk-scoring-entity-types#entity-types).
  </Step>

  <Step title="Direct and indirect exposure is measured">
    KYT analyzes **direct interactions** (one hop — entities that transacted directly with the address) and **indirect interactions** (n-hop — entities further along the fund trail). For each entity category, it computes the share of funds associated with it. This is how hidden connections to high-risk sources are surfaced even when there was no direct contact.
  </Step>

  <Step title="The risk score is calculated">
    The exposure shares are combined into a weighted 0–100% **Risk Score**, with high-risk categories weighted more heavily, and classified as **Low**, **Moderate**, or **High**. The full methodology is described in [Risk scoring](/wallet-checks-kyt/risk-scoring-entity-types).
  </Step>

  <Step title="You get the result — in three forms">
    The dashboard shows the score, risk flags, the per-category breakdown, and the direct transfers list. The API returns the same data as JSON. And every check can be exported as an audit-ready AML PDF report.
  </Step>
</Steps>

### Speed and freshness

* Checks typically complete in **seconds** — most in under 5 seconds via the API.
* Dataspike's entity database and risk assessments are **updated continuously** as new transactions appear and entity classifications change. A wallet that scored Low last quarter may score differently today, so re-screen addresses periodically for customers with ongoing activity.

### What's next in the pipeline

Continuous **address monitoring**, **real-time alerts**, and **custom risk profiles** (your own entity weights, thresholds, and trigger rules) are coming soon — see [Feature availability](/wallet-checks-kyt/result-fields-coverage#feature-availability). Today, the pipeline above runs on demand: you submit a check and get a point-in-time assessment.

***

## The three check types

### Address check

Scans the **full history of a wallet**: all inbound and outbound funds, entity connections, and behavioral patterns. Returns a risk score, an entity-category breakdown, and a list of direct counterparties.

### Transaction check

Scores a **specific transaction by its TxID**. Analyzes the sender, the recipient, and the chain of funds behind the transaction.

### Transfer check

Isolates **one specific sender → recipient pair inside a transaction**. Unlike the transaction check (which analyzes the entire TX), the transfer check verifies one particular flow of funds. This matters on UTXO-based chains like Bitcoin, where a single transaction can have many senders and recipients, and in multi-party transactions generally.

<Note>
  The transfer check is currently **API only** — it is not yet exposed in the dashboard UI. Transfer results return an exposure breakdown for that specific flow; the top-level `risk_score` field is `null`, so there is no single verdict for one leg. See [Feature availability](/wallet-checks-kyt/result-fields-coverage#feature-availability).
</Note>

### Which one do I run?

| Situation                                             | Check       | Why                                                            |
| ----------------------------------------------------- | ----------- | -------------------------------------------------------------- |
| A customer registers a withdrawal wallet              | Address     | You care about the wallet's whole history, not one payment.    |
| An incoming deposit needs a decision now              | Transaction | Scores the specific movement of funds you are about to credit. |
| A Bitcoin transaction has 29 outputs and one is yours | Transfer    | Scores only the leg that reached your address.                 |
| Periodic re-screening of an existing customer         | Address     | Picks up new activity and newly classified counterparties.     |

***

## Direct vs indirect exposure

* **Direct exposure (1 hop)** — entities that transacted directly with the address. These appear by name in the **Direct transfers** table, with amounts sent and received.
* **Indirect exposure (n-hop)** — entities further along the fund trail, reached through intermediate addresses. Indirect analysis is what reveals that funds passed through a mixer two hops before reaching the wallet you are screening.

By default, address checks analyze indirect payments; set `"directs": true` in the API to restrict the analysis to direct interactions only. That usually surfaces less exposure, so keep the parameter consistent when comparing two results for the same address.

***

## Entity attribution: Owner and Type

When Dataspike's database recognizes the entity behind an address, results show:

* **Owner** — the entity name (an exchange, protocol, or service).
* **Type** — its category from the [entity taxonomy](/wallet-checks-kyt/risk-scoring-entity-types#entity-types), e.g. *Licensed exchange service* or *Mixing service*.

In the API, attribution appears as `name`, `type` (machine-readable, e.g. `EXCHANGE_LICENSED`), and `type_label` (human-readable). **Undefined is normal** for individual, non-service wallets — it means the address is not attributed to any recognized entity, not that it is risky.

***

## Score and grade

Every address and transaction check produces a **score** (0–100% in the dashboard and PDF, a 0–1 coefficient in the API) and a **grade** (`low`, `moderate`, `high`, `undefined`). Use the grade as your decision gate.

The methodology is in [Risk scoring](/wallet-checks-kyt/risk-scoring-entity-types); every field including balances and volumes is documented in [Result fields](/wallet-checks-kyt/result-fields-coverage); reading them together on a real case is [How to read a KYT report](/wallet-checks-kyt/how-to-read-a-kyt-report).