Crypto Address Risk & AML Screener — OFAC Sanctions + On-Chain

Screen crypto addresses before you transact. Give one or more addresses and each is checked against the OFAC-published list of sanctioned digital-currency addresses (13 chains) and, for Bitcoin, against the public blockchain to see whether it has transacted directly with a sanctioned address (one-hop exposure) plus on-chain risk indicators — returned as a risk score, band, findings and a human-review signal. Keyless, read-only, public data only — agent-callable.

For compliance / KYC / AML teams, fintech & exchange ops, OTC desks, and AI agents doing pre-transaction screening at scale.

What it does

• Sanctions screening — checks each address against OFAC's published sanctioned digital-currency addresses across BTC, ETH, USDT, USDC, TRX, LTC, BCH, XMR, ZEC, DASH and more (~1,000+ addresses, sourced from a public OFAC-derived list, refreshed each run).
• On-chain exposure (Bitcoin) — reads the public ledger (keyless) and flags if any direct counterparty of the address is itself sanctioned.
• On-chain risk indicators (Bitcoin) — mixing-like fan-out, peeling chains, sweeping/consolidation, high-velocity bursts, large throughput.
• Your own watchlist — pass extraSanctionedAddresses to screen against your internal list too.

Output field	Meaning
riskScore / riskBand	0–100 and low / medium / elevated / high / critical
signal	sanctioned-match / sanctioned-exposure / elevated-risk / some-risk / no-indicators
findings[]	each risk indicator with severity + detail
sanctionedCounterparties[]	(BTC) direct counterparties that are sanctioned
balanceBtc, totalReceivedBtc, txCount, uniqueCounterparties	(BTC) on-chain context
chain	detected chain

Why not just ask an AI agent?

An agent can be told "is this address sanctioned?" and might check one list. It can't cheaply pull the latest OFAC list across 13 chains, read an address's recent transactions, intersect every counterparty against that list, and compute the mixing/peeling/velocity indicators — consistently and the same way each time. That cross-referenced, multi-source computation is what this actor delivers.

Input

Field	Type	Required	Description
addresses	array of strings	✅	Crypto addresses to screen.
extraSanctionedAddresses	array of strings		Your own watchlist to flag in addition to OFAC.
webhookUrl	string		POST the finished screenings here as JSON.

Example input

{
  "addresses": [
    "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa",
    "0x0000000000000000000000000000000000000000"
  ]
}

Output

One record per address. Example output (clean address, real run):

{
  "address": "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa",
  "chain": "BTC",
  "signal": "no-risk-indicators-found",
  "riskBand": "low",
  "riskScore": 0,
  "balanceBtc": 57.66512665,
  "txCount": 66959,
  "uniqueCounterparties": 18,
  "sanctionedCounterparties": [],
  "findings": [],
  "disclaimer": "Signals for human review from public data ... NOT a verdict ... absence of a match is NOT proof an address is clean."
}

When an address is on the sanctioned list, signal is sanctioned-match--do-not-transact, riskBand is critical, and findings[] names the chain. When a Bitcoin address has paid or been paid by a sanctioned address, signal is sanctioned-exposure--review-required and sanctionedCounterparties[] lists them.

Use cases

• Pre-transaction / onboarding checks — screen a counterparty address before sending or accepting funds.
• Exchange / fintech AML ops — batch-screen deposit or withdrawal addresses.
• OTC & treasury — confirm an address isn't sanctioned or exposed before a large transfer.
• AI compliance agents — one call returns a structured risk screening to gate an action.

For AI agents / MCP

https://mcp.apify.com/?tools=actors,docs,centorprat/crypto-address-risk-aml-screener

Loads as the tool centorprat--crypto-address-risk-aml-screener. Claude Code:

claude mcp add apify -- npx -y @apify/actors-mcp-server --actors centorprat/crypto-address-risk-aml-screener

Alerts / scheduling

Set webhookUrl and schedule a re-screen of watched addresses — the OFAC list changes, and a previously-clean address can gain sanctioned exposure; the fresh result is POSTed to Make/Zapier/your endpoint.

FAQ

Where does the sanctions data come from? OFAC publishes sanctioned digital-currency addresses in its SDN program. This actor loads them from a public OFAC-derived list covering 13 chains, fetched fresh on every run.

Which chains get on-chain analysis? Bitcoin, via keyless public explorers. For other chains the result is the sanctions-list screening (self-match) plus format detection — no key required, no partial/unreliable data.

Does a "critical" result mean the owner is a criminal? No. These are signals for human review. A sanctions-list match means do not transact and escalate to compliance; on-chain indicators are context to review — never an accusation about a person.

Does "no-risk-indicators-found" mean the address is safe? No. Absence of a match is not proof an address is clean — it only means nothing was found in the public data checked.

Is this legal / allowed? It reads only public data: the US-government-published sanctions list and the public blockchain. No keys, no private data, no deanonymisation.

How current is the list? Fetched on each run, so it reflects the latest published list.

How fast / how much? A couple of seconds per batch. Pay-per-event, one charge per address screened.

Data & attribution

Sanctions data originates from the U.S. Treasury OFAC SDN program (public domain), loaded via a public OFAC-derived address list; Bitcoin on-chain data via the keyless Blockstream Esplora API (mempool.space fallback). No keys, no personal data. Results are computed signals, not legal or compliance advice — always confirm with your own compliance process.

Related actors

• Bitcoin Wallet & Transaction Tracer
• Sanctions & Watchlist Screening