BitcoinDatabase.com
How it works
Bitcoin API Block explorer API Address lookup Historical data API Transaction API Bitcoin data API On-chain metrics Rich list Query with SQL Crypto AML API UTXO data Node API Webhook API Price API Transaction monitoring xpub balance API See all →
Glassnode alternative Blockchair alternative BlockCypher alternative Mempool.space alternative Xverse alternative BigQuery alternative Bitquery alternative TimechainIndex alternative CryptoQuant alternative Alchemy alternative QuickNode alternative Hiro alternative Amberdata alternative Elliptic alternative Merkle Science alternative Coin Metrics alternative CoinGlass alternative Crypto APIs alternative Tatum alternative NOWNodes alternative GetBlock alternative Arkham Intelligence alternative Santiment alternative Nansen alternative Allium alternative Flipside alternative SonarX alternative GoldRush alternative Scorechain alternative AMLBot alternative
Docs Pricing Blog Contact Sign in

Query the chain · Address screening

Bitcoin address screening API for risk scores and sanctions exposure

Screening a Bitcoin address means checking, before you onboard a wallet or clear a transaction, whether it matches a sanctions list or has moved coins to and from entities your team treats as high risk. The Bitcoin address screening API answers that from the fully-indexed chain: BitcoinDatabase matches the address against published sanctions designations, then traces its direct and near counterparties across labeled exchanges, mixers, and services to surface exposure, and returns a risk signal your compliance team can act on.

or try it below ↓

REST API · SQL · dashboards · address history from genesis

Query Console
btc
try:

Hit Run to query the Bitcoin blockchain.

Live from the chain for .

BTC

Balance trail

informational on-chain data · not financial advice

REST API · SQL · dashboards, one indexed dataset. Reading the chain ...

Call it over REST at onboarding and per transaction, or run SQL to rescreen a whole book of addresses when a list updates. Every score traces back to the labeled transactions behind it, so an analyst can open the evidence rather than trust a number. This is informational on-chain data and compliance tooling: it surfaces matches and exposure as signals to support your team's own review and decisions. It is not an accusation, a legal determination, or a claim about any individual, and it is not legal advice.

REST API SQL DASHBOARDS WEBHOOKS CSV EXPORT

History from genesis queryable in seconds

On-chain data not financial advice

Why it works

What you get with Address screening

Sanctions-list matching

Check an address against published sanctions designations at onboarding and before you clear a transaction, the two points where screening matters most, and rescreen your whole book automatically when a list changes.

Exposure, not just direct hits

A clean address can still receive coins one hop from a sanctioned or high-risk cluster. The API traces direct and near counterparties across labeled exchanges, mixers and services so indirect exposure surfaces, not only exact matches.

Evidence your analyst can open

Every risk signal traces back to the labeled transactions that produced it. Because labels and raw transactions share one schema, an analyst can drill from the score to the exact flows and document the review.

What it handles

The indexed Bitcoin chain, queryable your way

Look up an address, a transaction, a UTXO, the rich list or an on-chain metric, by REST API, SQL or dashboard. The same authoritative data, reconciled block-by-block against the canonical chain, without running a node.

  • Screen an address against sanctions designations
  • Return a risk signal at onboarding and per transaction
  • Surface exposure to labeled high-risk entities
  • Rescreen a full book of addresses when a list updates
  • Trace any risk signal to the transactions behind it
GET /v1/address/{addr} query result
200 · JSON 
{
  "address": "bc1qxy2k…l0wdv8",
  "balance_btc": 68432.10,
  "balance_usd": 4612165420,
  "tx_count": 1284,
  "unspent_outputs": 37,
  "first_seen": "2014-02-09"
}
indexed from genesis · to the satoshi ✓ reconciled block-by-block

Why BitcoinDatabase

One platform, queryable three ways

Not a raw node to sync, not an indexer to build, and not five vendors to stitch together. The fully-indexed Bitcoin blockchain, available as a REST API, as SQL, and as dashboards, on one authoritative dataset.

REST API

Typed JSON for addresses, transactions, balances, UTXOs and metrics. Drop it into apps, wallets, explorers and agents with curl, Python or any HTTP client.

SQL access

Run SQL directly against the indexed Bitcoin dataset for ad-hoc analysis, cohorts and exports, the same data the API and dashboards read from.

Compliance-first

Informational on-chain data and analytics only. Entity labels and flow tracing are framed as tooling to support a regulated team's own review, not accusations.

Good questions

Questions about Address screening

Screening checks an address against published sanctions lists, then traces its counterparties across labeled exchanges, mixers and services to measure exposure to high-risk entities, returning a risk signal. BitcoinDatabase computes this from the fully-indexed chain and traces every signal back to the underlying transactions.
GET /v1/screen/{address} on the Enterprise plan returns a risk level of low, medium, high or severe, the reasons, and each finding with its txid, hop and direction. It names the SDN list version and block it screened against, and a coverage block says how many transactions it read out of how many exist, so a partial trace is labeled partial. One call costs 10 credits.
Add them to the screening book with POST /v1/screening/book, up to 1,000 addresses per call. We fetch the OFAC SDN XML twice a day, keep every list version, and rescreen every book entry when a new version is published. GET /v1/screening/book?changed=1 returns only the entries whose risk changed, and risk=high,severe filters to the ones to review first.
No. A risk signal describes on-chain exposure and list matches as context for a compliance team's own review. BitcoinDatabase provides informational data and analytics only, not an accusation, a legal determination, or a claim about any individual, and not legal advice.
532 unique addresses typed as Bitcoin, from 534 XBT identifiers in the SDN XML published 8 October 2026 with record count 19,416. We validated each one with base58check and bech32 checksum arithmetic: 531 are valid Bitcoin mainnet addresses and one is a Tron address carrying the XBT label. The count moves whenever OFAC updates the list, so re-pull it rather than caching a number.
Because the CSV has no column for crypto addresses. They are appended into a free-text remarks field that is hard-capped at exactly 1,000 characters, so long address lists are cut off, sometimes mid-string. On 4 September 2026 the XML carried 532 Bitcoin addresses and the CSV yielded 252, a gap of 280. The Hydra Market entry alone has 117 addresses in the XML and 12 recoverable from the CSV. Ingest the structured feed, where each address is its own typed element.
Rarely, and the money is very concentrated. Of the 531 valid listed addresses we read at block 970,336 on 7 October 2026, 440 had been used and emptied, 4 had never received anything, and 87 still held 9,305.64204431 BTC. A second read near block 970,519 on 8 October gave the same figure to the satoshi. Three addresses under one SDN entry hold 77.7 percent of that, and the total moved only 0.00203104 BTC since block 965,562. Roughly 249,771 BTC has passed through the full set.
On the 4 September 2026 list: 39.17 percent legacy P2PKH, 33.33 percent P2SH, 25.61 percent native SegWit P2WPKH, 1.88 percent P2WSH, and no Taproot addresses at all. That shape is nothing like a live block, where Taproot is 12.54 percent of outputs and legacy is 4.60 percent. The listed set skews to older formats because listings accumulate over years, but the balances do not: native SegWit addresses hold 99.46 percent of the remaining BTC.
Yes, and there is a live example. One identifier on the current list is typed as a Bitcoin address but is TUCsTq7TofTCJRRoHk6RvhMoS2mJLm5Yzq, a valid base58check string whose version byte is 0x41, the Tron mainnet prefix. Bitcoin uses 0x00 and 0x05. A pipeline that trusts the currency label will look it up on the wrong chain and find nothing. Validate the version byte and route on what the address actually is.
About 4.6 times more than on the list itself. On 8 October 2026 we followed every output the 531 valid listed addresses had paid to unlisted ones in their recent history: 12,640 unlisted addresses received 218,149.37 BTC directly, and 650 of them still held 42,992.34 BTC, against 9,305.64 BTC on the listed addresses. Some are the blocked person's own change, others are exchange hot wallets, which is why exposure needs review rather than an automatic block.
No, and the difference is most of the work. A direct list match is a string comparison against a few hundred addresses. Exposure means following the transaction graph outward to see whether funds reached a listed address through intermediaries, and deciding how many hops still count. The first is cheap and nearly free of judgment. The second is where vendors differ, and where your policy has to state a threshold.
OFAC updates without a fixed schedule, so poll rather than assume a cadence, and treat delisting as seriously as listing because that is where stale caches cause real harm. Record the file publish date and record count with every ingest, so you can prove which version of the list a past decision was made against. That audit trail is usually what an examiner asks for.
Only if you kept the inputs. A risk score on its own does not reconstruct, because the vendor model and the list have both moved on. Storing the address, the block height you screened at, the list version and the transactions you relied on lets you rebuild the decision from chain data you hold. BitcoinDatabase serves that layer over REST and SQL, which is a different job from issuing a verdict.
Yes. In the SDN XML published 23 September 2026, address 1H939dom7i4WDLCKyGbXUp3fs9CSTNRzgL is listed under two separate individuals, SDN uids 38419 and 38420, and 3F6bbvS1krsc1qR8FsbTDfYQyvkMm3QvmR appears twice under one entity. So 534 identifiers resolve to 532 unique addresses. A screening table keyed on the address alone will keep one match and drop the other, so store every SDN entry that names an address and return all of them on a hit.
Request sdn.xml from the Sanctions List Service at sanctionslistservice.ofac.treas.gov/api/download/sdn.xml and follow redirects. On 29 September 2026 that URL answered with a redirect to a signed download link valid for one hour, so a client that does not follow redirects saves a zero byte file and raises no error. Check the file size and the Publish_Date and Record_Count fields on every ingest; the file we read was dated 09/23/2026 with 19,391 records.
At three points at a minimum: at onboarding, before each transaction, and again whenever the sanctions list or your risk data changes. A wallet that was clean at signup can receive tainted coins later, and a new designation can implicate an address you already cleared, so a one-time check is not a screening program.
It should inform the decision, not make it alone. An address can receive high-risk coins with no connection to wrongdoing, and a low score proves nothing either. Route elevated scores to a trained reviewer who examines the underlying transactions and documents the rationale. A hard block on a raw number produces false positives and misses context.
Read every Bitcoin API question

Explore more

More ways to query Bitcoin with BitcoinDatabase

Bitcoin dust attack detection

Dust limits per script type, dust transaction data, and the spray patterns behind address poisoning.

Learn more

Crypto AML API

Risk signals, exposure and entity labels to support your compliance review.

Learn more

Bitcoin exchange reserves

Exchange balance and reserve totals per address, with dated snapshots and the transactions behind every move.

Learn more

Bitcoin historical data API

Full-depth history: every block, transaction and metric back to 2009.

Learn more

Bitcoin webhook API

Real-time notifications on address activity, incoming payments and confirmations.

Learn more

xpub balance API

Derive an HD wallet's addresses from its xpub and total the balance to the satoshi.

Learn more

Buyer guides and measurements on this topic

Best Bitcoin Sanctions Screening API for Fintech Compliance Teams We parsed the OFAC SDN list ourselves on 4 September 2026 and checksum-validated every Bitcoin address in it. The authoritative XML carries 532. The C... Crypto AML Compliance for Banks and Bitcoin Screening Software Crypto AML compliance for banks means screening every bitcoin address that touches a customer account, at onboarding, on each transfer and on every OF... Crypto ATM Regulations by State and Wallet Screening Software Crypto ATM regulations now cap daily amounts, fees and refunds in most kiosk states, and six statutes require operators to block wallets linked to fra...
See every use case See pricing Back to the Bitcoin API

Stop running a node. Just query Bitcoin.

Run your first query now and get on-chain data back by REST API, SQL or dashboard, with address history back to the genesis block over REST. Informational on-chain data only, not financial advice.

See pricing

History from genesis over REST · SQL · dashboards · addresses, transactions, UTXOs, metrics