Know Your Transaction (KYT)

KYT is BlockchainAnalysis.io's pre-transaction risk screening engine. It allows exchanges, OTC desks, and payment processors to assess the risk of a blockchain transaction before it is executed — delivering a risk verdict in under 500 milliseconds. KYT is a critical compliance tool for VASPs operating under MiCA, AMLA, and FATF Travel Rule obligations.

Why KYT Matters

Traditional wallet screening evaluates addresses after the fact. KYT shifts compliance to the pre-transaction stage, enabling you to block or flag high-risk transactions before funds leave your platform.

This distinction is significant for several reasons:

• Regulatory expectation — MiCA Article 67 requires CASPs (Crypto-Asset Service Providers) to implement effective systems for detecting suspicious transactions. Pre-transaction screening demonstrates proactive compliance.
• Liability reduction — Once funds are sent to a sanctioned or high-risk address, the damage is done. Clawing back crypto transactions is effectively impossible. KYT prevents the problem entirely.
• Operational efficiency — Blocking a withdrawal before execution is far cheaper than investigating a suspicious transaction after the fact, filing a SAR, and potentially facing regulatory penalties.
• Customer experience — Legitimate customers benefit from instant approvals. Only genuinely risky transactions are held for review, reducing false friction.

How KYT Works

When a KYT check is initiated — either via API call or dashboard — the platform executes a streamlined risk evaluation pipeline optimized for speed:

1. Address Resolution

The destination (and optionally, the source) address is validated and resolved against the BlockchainAnalysis.io entity database. If the address belongs to a known entity, that entity classification is immediately available for risk evaluation.

2. Sanctions Pre-Check

The address is checked against all integrated sanctions lists (OFAC SDN, EU Consolidated, UN Security Council, HM Treasury, SECO, DFAT, and 26+ additional lists). A direct sanctions match triggers an immediate BLOCK verdict — no further analysis is needed.

3. Risk Factor Screening

If no sanctions match is found, the address is evaluated against the following risk factors:

| Risk Factor | Description | Severity | |---|---|---| | Sanctions Exposure | Direct or indirect (1-2 hop) connection to a sanctioned address | Critical | | Darknet Market | Association with known darknet marketplaces | Critical | | Stolen Funds | Address linked to known theft or hack proceeds | Critical | | Terrorist Financing | Connection to addresses flagged for terrorism financing | Critical | | Mixer/Tumbler | Direct interaction with mixing services (Tornado Cash, Wasabi, etc.) | High | | Ransomware | Association with known ransomware campaigns | High | | Scam/Fraud | Address linked to known scam operations, phishing, or rug pulls | High | | Gambling | Interaction with unlicensed gambling platforms | Medium | | High-Risk Jurisdiction | Entity located in a FATF grey-listed or high-risk jurisdiction | Medium | | Privacy Coins | Interaction with privacy-focused tokens or cross-chain swaps to privacy chains | Medium | | Child Exploitation | Any association with CSAM-related addresses | Critical |

4. Verdict Generation

Based on the risk factor evaluation, a verdict is returned:

| Verdict | Meaning | Recommended Action | |---|---|---| | APPROVE | No significant risk factors detected | Process the transaction | | REVIEW | Moderate risk signals detected | Hold for manual compliance review | | BLOCK | Critical risk factors detected or sanctions match | Reject the transaction immediately |

Response Time and SLA

KYT is engineered for real-time transaction flows:

| Metric | Target | Typical | |---|---|---| | Median response time | < 200ms | 120-180ms | | P95 response time | < 500ms | 300-450ms | | P99 response time | < 1000ms | 600-900ms | | Availability | 99.9% uptime | 99.95% observed |

Response times are measured from API request receipt to response dispatch. Network latency between your infrastructure and our API endpoints is additional.

API Integration

KYT is primarily consumed via the REST API for automated, real-time transaction screening.

Endpoint

POST /api/v1/kyt/check

Request Headers

Authorization: Bearer <your-api-key>
Content-Type: application/json

Request Body

{
  "address": "0x1234567890abcdef1234567890abcdef12345678",
  "chain": "ethereum",
  "direction": "withdrawal",
  "amount": "2.5",
  "asset": "ETH",
  "customer_id": "cust_abc123",
  "reference_id": "tx_20260331_001"
}

Request Parameters

| Parameter | Type | Required | Description | |---|---|---|---| | address | string | Yes | The blockchain address to screen | | chain | string | Yes | Blockchain identifier (e.g., ethereum, bitcoin, solana) | | direction | string | Yes | withdrawal (outgoing) or deposit (incoming) | | amount | string | No | Transaction amount (used for threshold-based rules) | | asset | string | No | Token/asset identifier | | customer_id | string | No | Your internal customer ID (for audit trail linkage) | | reference_id | string | No | Your internal transaction reference |

Response

{
  "id": "kyt_8f3a2b1c4d5e6f7a",
  "timestamp": "2026-03-31T14:22:05.123Z",
  "address": "0x1234567890abcdef1234567890abcdef12345678",
  "chain": "ethereum",
  "verdict": "REVIEW",
  "risk_score": 62,
  "risk_level": "MEDIUM",
  "risk_factors": [
    {
      "factor": "MIXER_USAGE",
      "severity": "HIGH",
      "description": "Address received 1.2 ETH from Tornado Cash within the last 30 days",
      "confidence": 0.94
    },
    {
      "factor": "HIGH_RISK_JURISDICTION",
      "severity": "MEDIUM",
      "description": "Entity associated with jurisdiction on FATF grey list",
      "confidence": 0.71
    }
  ],
  "sanctions_match": false,
  "entity": {
    "name": null,
    "category": "UNKNOWN",
    "labels": []
  },
  "recommendations": [
    "Hold transaction for manual compliance review",
    "Request source of funds documentation from customer",
    "Consider initiating a full wallet screening for deeper analysis"
  ],
  "meta": {
    "response_time_ms": 147,
    "api_version": "v1",
    "reference_id": "tx_20260331_001"
  }
}

Response Fields

| Field | Type | Description | |---|---|---| | id | string | Unique KYT check identifier | | verdict | string | APPROVE, REVIEW, or BLOCK | | risk_score | integer | 0-100 risk score | | risk_level | string | LOW, MEDIUM, HIGH, or CRITICAL | | risk_factors | array | List of detected risk factors with severity and confidence | | sanctions_match | boolean | Whether a direct sanctions match was found | | entity | object | Entity identification results (if any) | | recommendations | array | Actionable compliance recommendations |

Dashboard Usage

KYT checks can also be performed manually through the dashboard:

Use Cases

Exchange Withdrawal Screening

The most common KYT use case. When a customer initiates a withdrawal to an external address, the exchange calls the KYT API before broadcasting the transaction:

1. Customer requests withdrawal to address 0xABC...
2. Exchange backend calls POST /api/v1/kyt/check with the destination address
3. If verdict is APPROVE — broadcast the transaction
4. If verdict is REVIEW — hold the withdrawal and notify the compliance team
5. If verdict is BLOCK — reject the withdrawal and log the event

OTC Desk Compliance

OTC desks handle large, off-exchange trades where counterparty risk is elevated. KYT screening on the counterparty's receiving address before settlement provides a compliance checkpoint:

• Screen the buyer's deposit address before sending assets
• Screen the seller's receiving address before releasing fiat
• Maintain an audit trail of all pre-trade KYT checks

Payment Processor Gateway

Crypto payment processors can integrate KYT to screen incoming payments from customers, flagging deposits from high-risk addresses for manual review before crediting the merchant account.

DeFi Protocol Front-End Compliance

DeFi front-ends (not the smart contracts themselves, but the web interfaces) can integrate KYT to screen wallet addresses at the point of connection, blocking sanctioned addresses from interacting with the UI.

KYT and Transaction Monitoring

KYT and Transaction Monitoring serve complementary roles:

| Aspect | KYT | Transaction Monitoring | |---|---|---| | Timing | Pre-transaction (before execution) | Post-transaction (after execution) | | Speed | < 500ms | Near real-time (seconds to minutes) | | Depth | Focused risk check on a single address | Behavioral pattern analysis across all transactions | | Scope | One address, one transaction | Full customer transaction history | | Output | APPROVE / REVIEW / BLOCK verdict | Alerts based on rule triggers | | Use case | Gate individual transactions | Detect suspicious patterns over time |

Automatic Fund Trace Escalation

When a KYT check returns a BLOCK or REVIEW verdict, you can configure the platform to automatically initiate a Fund Trace investigation on the flagged address. This provides your compliance team with a detailed origin-of-funds analysis and visualization, ready for review without manual intervention.

To enable automatic escalation:

1. Go to Settings > KYT Configuration
2. Enable Auto Fund Trace on BLOCK
3. Optionally enable Auto Fund Trace on REVIEW
4. Set the trace depth (default: 3 hops)

Pricing

KYT checks are priced per individual check:

| Volume (Monthly) | Price per Check | |---|---| | 1 - 1,000 | $0.25 | | 1,001 - 10,000 | $0.22 | | 10,001 - 50,000 | $0.20 | | 50,001+ | Contact sales |

MiCA Compliance

The Markets in Crypto-Assets Regulation (MiCA) imposes specific obligations on CASPs operating in the EU. KYT directly supports compliance with several MiCA requirements:

• Article 67 — Obligation to detect and prevent suspicious transactions — KYT provides the technical mechanism to screen transactions before execution, demonstrating proactive compliance.
• Article 68 — Record-keeping obligations — Every KYT check is logged with a unique ID, timestamp, and full results, providing the audit trail required under MiCA.
• Article 76 — Measures to prevent money laundering — Pre-transaction screening is a core anti-money-laundering control that regulators expect CASPs to implement.

Error Handling

The KYT API uses standard HTTP status codes:

| Status Code | Meaning | |---|---| | 200 | Check completed successfully | | 400 | Invalid request (malformed address, unsupported chain) | | 401 | Authentication failed (invalid or expired API key) | | 429 | Rate limit exceeded (max 100 requests/second) | | 500 | Internal server error (retry with exponential backoff) | | 503 | Service temporarily unavailable (maintenance window) |

For 429 and 5xx errors, implement retry logic with exponential backoff. A suggested retry schedule: 1s, 2s, 4s, 8s, then fail.

Best Practices

1. Screen both directions — Screen the destination address on withdrawals AND the source address on deposits. Inbound exposure to sanctioned funds is just as problematic as outbound.

2. Log every check — Store the KYT id alongside your internal transaction record. This provides a complete audit trail for regulators.

3. Act on BLOCK verdicts immediately — Do not queue BLOCK verdicts for batch review. A sanctions match requires immediate action.

4. Set up automatic escalation — Configure auto fund trace on BLOCK and REVIEW verdicts to give your compliance team ready-made investigation packages.

5. Monitor your approval rate — A consistently high approval rate (> 98%) is normal. A sudden drop may indicate that your customer base has shifted or that you are onboarding higher-risk customers.

6. Combine with Transaction Monitoring — KYT catches individual risky transactions. Transaction Monitoring catches patterns across many transactions. Use both.