Best Bitcoin Sanctions Screening API for Fintech Compliance Teams

Every vendor in this category sells you the same thing at the top of the funnel: an address goes in, a risk verdict comes out. Chainalysis, Elliptic, TRM Labs and a dozen smaller shops all pitch coverage, accuracy and speed. Those are hard to compare from the outside, which is why buying committees end up choosing on brand and on who the examiner has heard of.

There is a cheaper test, and you can run it before you take a single sales call. Ask how the vendor ingests the underlying sanctions list, and what it does when the source is wrong. We spent a morning measuring the source itself, and the results say more about screening quality than any accuracy claim we have seen published.

How many Bitcoin addresses are on the OFAC SDN list?

532, as of the SDN file published 4 September 2026, record count 19,329. We pulled it, extracted every identifier typed Digital Currency Address - XBT, deduplicated, and validated each one with real arithmetic: base58check double-SHA256 for legacy and P2SH addresses, bech32 and bech32m polynomial checksums for the rest. All 532 validate. Zero malformed.

That number is not what you get if you use the file most people reach for first.

The CSV drops half the Bitcoin addresses

OFAC publishes the SDN list in several formats. The CSV is the one that turns up in tutorials and sample code because it opens in a spreadsheet and parses in four lines. It is also lossy in a way the file never announces.

Crypto addresses do not have their own column in the CSV. They are appended into a free-text remarks field, and that field is hard-capped at exactly 1,000 characters. When an SDN entry has a long list of addresses, the list is simply cut off at the cap, sometimes in the middle of an address. We found 35 rows sitting at exactly 1,000 characters, and 8 Bitcoin addresses truncated mid-string into fragments like 1B11Ezqg3AXj and bc1qtnr3t28l.

The damage is concentrated on exactly the entries you would most want to catch, because the entries with the most addresses are the ones that overflow first.

Hydra Market is the clearest case. It is one of the largest darknet market designations OFAC has ever made, it carries 117 Bitcoin addresses in the structured feed, and a CSV-based pipeline sees 12 of them. The other 105 are not flagged as missing. They are just absent, and the file parses cleanly.

The fix is not clever engineering. Use the structured feed, where each address is its own <idNumber> element with an explicit <idType>, and never regex a free-text field for something a schema already models. Teams that instead key their screening off published notices and PDFs are doing document data extraction on a compliance-critical input, which is a harder problem than it looks and an odd one to take on when a machine-readable feed exists.

One entry on the list is not a Bitcoin address at all

While validating, one identifier typed as XBT failed to look like anything on Bitcoin: TUCsTq7TofTCJRRoHk6RvhMoS2mJLm5Yzq. It is not malformed. It is a perfectly valid base58check string whose version byte is 0x41, which is the Tron mainnet prefix. Bitcoin uses 0x00 for P2PKH and 0x05 for P2SH. The address is real and it is sanctioned; it is simply filed under the wrong currency.

This is a small thing that tells you something big about how to build the ingest. A screening system that trusts the currency label will try to look this address up on Bitcoin, find nothing, and move on. A system that validates the version byte and routes on what the address actually is will screen it on the right chain. Ask your vendor which one they do.

The list looks nothing like the live Bitcoin chain

We classified all 532 addresses by script type and put them next to a full-block census we ran on block 963,670, and next to the money that is actually sitting on the sanctioned addresses today.

Two things jump out. There is not a single Taproot address on the SDN list, while Taproot is 12.54 percent of outputs in a live block. And the legacy-heavy shape of the list is a historical artifact: legacy and P2SH are 72 percent of the entries and hold half of one percent of the remaining money, while native SegWit is a quarter of the entries and holds 99.46 percent of it.

If you are sizing an address database or writing parsing code, that distribution matters, and it is the opposite of what the live chain looks like. Our full breakdown of the formats and their lengths is on the Bitcoin address types page.

Do sanctioned Bitcoin addresses still hold money?

Mostly not, and the exceptions are extremely concentrated. We queried the current on-chain state of all 532 addresses, and 531 returned cleanly.

Across all of them, 249,771.22 BTC has passed through at some point, spread over 167,424 transactions. What remains is 9,305.64 BTC, and three addresses hold 7,230.10 of it, or 77.7 percent. Two SDN entries, Zhi Chen and Yunhe Wang, account for 99.46 percent of every satoshi still sitting on a sanctioned Bitcoin address.

There is a tell in the balances worth knowing about. Ten addresses hold exactly 100.00000330 BTC, another ten hold exactly 99.99998030 BTC, and twelve hold exactly 0.00001000 BTC. Identical balances to the satoshi across many addresses are the signature of a scripted distribution, not of hand-managed wallets, and that pattern is visible from balances alone.

What to actually ask a screening vendor

The measurements above turn into four questions that are hard to answer with marketing copy:

• Which OFAC file do you ingest, and how often? If the answer is the CSV, they are working from roughly half the Bitcoin addresses. If they cannot tell you, that is the answer.
• Do you validate address checksums and version bytes on ingest? The Tron address filed as XBT is a live test case sitting in the current file.
• Can you show me the evidence behind a verdict months later? An examiner will ask. A score alone does not reconstruct.
• What happens when OFAC delists? Removal is as operationally real as addition, and it is where stale caches show up.

None of that requires you to distrust the big vendors. Chainalysis, Elliptic and TRM Labs all maintain their own attribution work that goes far beyond the published list, and for a regulated VASP or bank there is real value in a third party that will stand behind a verdict. We wrote up where each of them fits on our Elliptic alternative page, and Chainalysis and TRM Labs are compared on our crypto AML API page, including the parts where they are clearly the better buy.

Where a raw chain index fits

Screening vendors answer "is this address risky". They are not built to answer "show me every transaction this address made, in order, with the UTXOs, so I can reconstruct the alert". Those are different products, and most compliance teams eventually need both.

The work in this article is the second kind. Validating an ingested list, checking the on-chain status of listed addresses, backtesting a rule change against history, and reproducing an alert for an examiner are all chain-data questions. BitcoinDatabase indexes the full Bitcoin chain and exposes it over REST, SQL and dashboards, so a team can run exactly these checks against data it holds rather than re-asking a vendor. The Bitcoin address screening API and crypto AML API pages cover the endpoints and the query shape for a single address or a whole customer list. Everything is on-chain data and analytics to support your own review, not a compliance verdict and not legal advice.

What we did not measure

Being clear about the edges, because the numbers above are only as good as their scope:

• This is the OFAC SDN list only. It is not the EU, UN or HM Treasury lists, and it is not the OFAC Non-SDN lists. A real screening stack ingests several.
• We measured direct listing only. We did not trace exposure, so an address that received funds from a sanctioned address is not counted here. Indirect exposure is most of what screening vendors actually sell.
• Balances are a single reading at Bitcoin block 965,562. They move.
• We did not evaluate any vendor's proprietary attribution, which is the part of their dataset that is not derivable from the public list and is genuinely hard to reproduce.
• One of the 532 addresses did not return a clean on-chain response and is excluded from the status table, which is why that table totals 531.

The verdict

If you are a regulated fintech, buy a screening vendor. You need someone to stand behind the verdict, and Chainalysis, Elliptic and TRM Labs all do that credibly. Do not choose between them on claimed accuracy, which you cannot verify, and do not choose on list coverage either, since they all start from the same public source.

Choose on ingest quality and evidence. Ask the four questions above, ask them to screen the Tron-labelled address in front of you, and ask what their pipeline does when a source file silently loses half its Bitcoin entries. Then keep a raw chain index alongside it, because the day an examiner asks you to show your work, a risk score is not going to be enough.

Bitcoin ATM and kiosk operators face a sharper version of this problem, because several states now write the wallet-blocking duty into statute. Our guide to crypto ATM regulations and wallet screening software compares the state rules and what a blocklist can and cannot catch at the machine.

Banks that now hold bitcoin in custody carry the same screening duty with an examiner watching. Our guide to crypto AML compliance for banks re-reads this list on 7 October 2026 (87 funded addresses, 9,305.64204431 BTC, almost unchanged) and maps each bank activity to what it needs to screen. If you are weighing a multichain suite against a Bitcoin-only screen, the Scorechain alternative comparison sets the prices and coverage side by side.

Exchanges and licensed money transmitters screening every deposit should also look past the list itself. Our comparison of crypto KYT software for exchanges and money transmitters measures how much bitcoin sits one hop from the listed addresses and compares six vendors on price and evidence.

Method: OFAC SDN file published 4 September 2026, record count 19,329, in both CSV and XML. Addresses extracted from typed identifier elements, deduplicated, and validated with base58check and bech32 checksum arithmetic. On-chain state read at block 965,562. Live block comparison from our own census of block 963,670. Anyone can reproduce this from the same two public files.