Skip to content
The SpawnExplore tools
AML requests

How to Choose and Integrate a Crypto AML API

Choose a crypto AML API by chain coverage, evidence, failure states, and review controls, then wrap provider-specific scores in a stable internal contract.

Choose a crypto AML API by the decision it supports and the evidence it returns when the answer is uncertain. Confirm chain and asset coverage, schemas, provenance, rate and error behavior, retention, and human review before writing an adapter. A vendor's speed, score, or accuracy claim is not a substitute for a contract you have tested.

Start with the actual transfer. Your application should know whether it is screening a public wallet address or a transaction hash, which chain carries the asset, and whether the check is before or after a transfer. USDT on Ethereum and USDT on TRON are different inputs even when a team casually calls both “USDT.” Keep the chain explicit at every boundary.

Ask for the evidence contract

A useful provider conversation starts with a sample schema and failure cases. GetBlock's public Crypto AML page describes dashboard and REST screening with exportable reports. AMLBot's API integration page advertises KYT API reports with a risk score and sources. These pages show marketed interfaces; they do not verify an account, endpoint, price, SLA, coverage, or integration for your business.

Ask the provider to document, for each supported chain:

  • accepted address and transaction formats, token identifiers, and authentication;
  • list sources, attribution method, lookback window, hop limits, and refresh time;
  • score direction, band definitions, category meanings, and cross-chain comparability;
  • request limits, idempotency, retention, export, and deletion behavior;
  • responses for no match, missing data, timeout, rate limit, provider error, and an unavailable chain.

Do not approve an adapter because it returned HTTP 200 once. A valid response still needs the data needed for a reviewer to understand what was checked.

Wrap the provider in your own contract

Use a provider-neutral record internally, while retaining the original response. The following is a hypothetical adapter shape, not a claim about any provider's API:

{
  "request_id": "internal-id",
  "input": {
    "chain": "tron",
    "asset": "USDT",
    "address": "public-address",
    "transaction_hash": null
  },
  "status": "unknown",
  "observed_at": "2026-09-16T00:00:00Z",
  "provider": {"name": "vendor", "version": "documented-version"},
  "score": {"value": null, "scale": null, "direction": null},
  "signals": [],
  "coverage": {"sources": [], "unknowns": ["coverage_not_provided"]},
  "raw_report_ref": "encrypted-reference"
}

The adapter should return completed, unknown, timeout, rate_limited, or provider_error distinctly. Use unknown when coverage or required evidence is missing, as in the example. completed means the query finished with required evidence present; acceptance remains a separate policy decision. Keep transport status separate from review decisions, preserve the provider's score and scale, and store request and raw report references under your retention rules.

The signals array should retain category, direction, explanation, and match status. A sanctions match, a token blacklist, and counterparty exposure are not interchangeable. If the provider cannot explain a flag, the adapter should carry that gap to the reviewer. It should never hide a warning to make an integration look successful.

Test the hard paths before rollout

Run a test matrix with addresses and transactions you are authorized to use. Include each target chain, an invalid address, an unsupported token, an address with no returned attribution, a provider timeout, a rate limit, and a response with a high-risk signal. Check that retries do not create duplicate cases and that a repeated request_id is safe. Do not use private keys or seed phrases in test input; address screening needs public identifiers.

TestExpected adapter behaviorReviewer evidence
Valid address, supported chainComplete with exact input echoedSource, timestamp, categories, raw report reference
Missing or partial coverageReturn unknown statusMissing fields and provider explanation
Timeout or rate limitReturn retryable status without allowingAttempt count and next action
Sanctions or other high-risk flagEscalate under policyMatch category, direction, and explanation
Unsupported chain or assetReject clearlyUnsupported input and provider documentation

Download the AML screening checklist CSV for the base vendor review record. It contains network, subject, check time, source, signals, coverage, and review fields, but no test-case, retry-count, or next-action columns. Add a test sheet or extra columns for this matrix. The checklist is not a compliance certification.

Decide whether the API fits

Compare providers on evidence quality and operational behavior. A consumer flow shows human inputs, but it does not prove API semantics. BestChange's checker asks for an address, asset, analyzer, and email; AMLBot advertises web and messaging checks alongside business API offerings. Treat these as discovery clues, not production acceptance criteria.

For a single counterparty, use Request check, select the job, network, expected volume, and Telegram username. Keep the address and report for follow-up; an operator confirms availability, scope, and price before you share it. The Spawn's current path is manual and has no promised automated execution. Read How to check a USDT address, then How to read a crypto AML risk score. Keep the provider contract, internal policy, and human review record as separate artifacts.

Sources

The Spawn currently takes manual requests. Scope, availability and price are confirmed before any check.

Request check