Clearlist sanctions and risk screening
- Generated
- 09 Oct 2026 07:17 UTC
- Operator
- Clearlist (legal entity to be stated on incorporation)
- Contact
- support@clearlist.xyz
- Live status
- https://clearlist.xyz/status (JSON: https://clearlist.xyz/api/v1/status)
1. Service description
Clearlist is a screening API and dashboard for applications that move money. A customer submits a subject (a blockchain address, a personal or organisational name, a country or an on-chain transaction) and receives a decision of allow, review or block with the reasons and the evidence behind each reason, evaluated against the customer’s own policy. Customers can enrol subjects for continuous rescreening after every list change, maintain an allowlist of cleared false positives, work a review queue, receive webhooks, export evidence and publish an attestation of the controls in operation. Clearlist is non-custodial, holds no customer funds, and does not perform identity verification.
2. Data sources and licences
| List | Publisher and endpoint | Licence | Publisher changed | Entries |
|---|---|---|---|---|
| OFAC SDN | US Department of the Treasury, Office of Foreign Assets Control https://www.treasury.gov/ofac/downloads/sdn.xml | US Government work, public domain | 08 Oct 2026 | 19,416 |
| OFAC Consolidated | US Department of the Treasury, Office of Foreign Assets Control https://www.treasury.gov/ofac/downloads/consolidated/consolidated.xml | US Government work, public domain | 14 Sept 2026 | 481 |
| EU Financial Sanctions | European Commission, DG FISMA https://webgate.ec.europa.eu/fsd/fsf/public/files/xmlFullSanctionsList_1_1/content?token=dG9rZW4tMjAxNw | EU open data, attribution | 22 Sept 2026 | 6,241 |
| UK OFSI | HM Treasury, Office of Financial Sanctions Implementation https://ofsistorage.blob.core.windows.net/publishlive/2022format/ConList.csv | Open Government Licence v3 | 03 Jun 2026 | 5,135 |
| UN Security Council | United Nations Security Council https://scsanctions.un.org/resources/xml/en/consolidated.xml | UN public data | 08 Oct 2026 | 1,010 |
Public chain-risk labels (mixers, hacks, scams, darknet markets, ransomware): 132,910 addresses from 10 sources, each row carrying its source URL, each feed used under a licence permitting commercial use and listed with that licence on the status page. No data is used from OpenSanctions, Chainalysis, Elliptic or TRM, and no explorer labels are scraped.
3. Refresh cadence and change control
Lists are downloaded daily from the publishers’ endpoints (40 6 * * * UTC). Each download is hashed (SHA-256), parsed and swapped in as a new versioned batch in one transaction; a parse yielding fewer than half the previous batch’s entries is rejected and the previous batch stays live. Every decision records the batch identifiers of every list it was evaluated against. A list is reported as fresh when it was fetched successfully within 36 hours. Monitored subjects are rescreened daily after the refresh; webhooks are retried 5 times over 15 hours.
- Download and swap in every government list: 40 6 * * * UTC
- Refresh public label feeds and incidents: 55 6 * * * UTC
- Rescreen every monitored subject: 15 7 * * * UTC
- Push new sanctioned addresses to the on-chain oracle: 0 7 * * * UTC
- Deliver webhooks (with retries): 25 7 * * * UTC
- Delete decisions past their plan's retention window: 20 3 * * * UTC
- Run the public verifications (OFAC crosscheck, name benchmark): 30 7 * * * UTC
- Send the weekly list-change digest: 0 8 * * 1 UTC
4. Matching method
Addresses are matched exactly after normalisation (EVM and bech32 lowercased; base58 preserved), with every EVM chain treated as one family. Names are normalised (Unicode NFKD, diacritics removed, case and punctuation folded), retrieved by trigram similarity, and scored by aligned-token similarity with Jaro-Winkler, an initial rule and a transliteration-tolerant phonetic key. Default thresholds: not reported below 0.80, review at 0.85, strong at 0.93. A name match never blocks on its own: blocking requires a corroborating date of birth, nationality or identifier published on the list. Thresholds, outcomes per category and jurisdiction lists are per-customer policy. The full method is published at https://clearlist.xyz/methodology.
5. Verification of correctness
Two checks run daily and their results are public with their run date. (a) OFAC crypto-address crosscheck against an independently maintained extract of the SDN file: latest run 09 Oct 2026 05:07 UTC, no drift. (b) Name-matching benchmark on a deterministic sample of listed names with realistic perturbations: latest run 09 Oct 2026 05:18 UTC, recall 99.7% over 939 queries, 4 of 60 ordinary names reaching review. Both are reproducible from the repository.
6. Data handling and retention
- Stored per screen: the normalised subject as submitted, the decision, reasons, matches, list batch versions, policy version, optional customer metadata, timestamps.
- Not stored: end-user documents, payment credentials, private keys. Clearlist never has custody of funds.
- Retention: decisions are kept for the life of the account on paid plans and 30 days on the Free plan (deleted by a daily job). Reviews are separate records; decisions are append-only and never edited.
- The public address checker stores nothing and does not log the query.
- Exposure lookups fetch public on-chain data for the subject address; results are cached for six hours.
- Customers can export the full evidence bundle of any decision from the dashboard or API at any time.
7. Security
- API keys are shown once and stored as SHA-256 hashes with a display prefix; keys can be revoked instantly; separate live and test modes.
- All traffic over TLS. Webhooks are signed with a per-endpoint HMAC-SHA256 secret and carry a timestamp for replay protection.
- Per-key rate limits; the public checker is rate-limited per IP.
- Dashboard sessions via better-auth with hashed passwords; organisation-scoped access on every query.
- Cron and internal endpoints require a shared secret header.
- Formal certifications (SOC 2) are not yet held; this is stated rather than implied.
8. Availability and hosting
Application hosted on Vercel (serverless, United States region) with a managed PostgreSQL database. Address screening is served from an in-process set refreshed every 60 seconds, so a direct check does not depend on a database round-trip. Exposure and chain data are best-effort within a time budget and degrade to “unavailable” rather than failing a screen. Live health: https://clearlist.xyz/api/v1/health. Service-level agreements are available on the Foundation and Enterprise plan.
9. Subprocessors
- Vercel, Inc. (application hosting, cron scheduling)
- Managed PostgreSQL provider (database)
- Resend (transactional email: weekly digest), when enabled
- Public blockchain RPC providers and, where configured, Helius and Etherscan (exposure data for the subject address only)
- DB-IP (IP geolocation, DB-IP Lite, attribution given)
10. Limitations and non-claims
- Sanctions lists and public chain labels only: no politically exposed person lists, no adverse media, no identity verification.
- Counterparty exposure is not attribution: it does not claim who controls an address.
- The attestation describes controls in operation; it is not a legal opinion or a determination of regulatory compliance.
- Publishers’ lists are taken as published; Clearlist verifies its parsing of them, not their completeness.
- No screening-vendor licence exists in the United States, the United Kingdom or the European Union; none is claimed.
11. For your own questionnaire
When a partner asks “describe your sanctions screening”, this paragraph answers it. Replace the parts in brackets with what you actually screen; the attestation link is in your dashboard.
[Company] screens every [sign-up, send, deposit and withdrawal] against the OFAC SDN and Consolidated lists, the EU Financial Sanctions list, the UK OFSI list and the UN Security Council list, plus public records of mixer, hack, scam, darknet-market and ransomware addresses, using Clearlist (https://clearlist.xyz). Wallet addresses are screened on [Solana and all EVM chains], with counterparty exposure to one hop. Names are screened with corroborating identifiers; a name match alone is routed to manual review, never auto-cleared. Every decision is recorded with the list versions used and is exportable. Monitored subjects are rescreened daily as lists change. The program is described at [attestation link]; list freshness and verification results are published at https://clearlist.xyz/status.