Sanctions screening

Sanctions List Search API: Fuzzy, Typo-Tolerant & Regex

GET /api/v1/search is a free, unauthenticated fuzzy search across every list CompliAPI screens — listed party names, crypto addresses, emails, websites, government IDs and sanctioned countries. Typos still match, a regex mode handles pattern lookups, and every result names the list that produced it.

GET /api/v1/search?q={query}

# No API key required — free and unauthenticated
curl "https://api.compliapi.com/api/v1/search?q=lazarus&limit=5"

Response

[
  {
    "entity_type": "onchain_address",
    "value": "0x098B716B8Aaf21512996dC57EB0615e2383E2f96",
    "match": "partial",
    "similarity": 1.0,
    "list": "ofac",
    "list_name": "US OFAC SDN",
    "list_type": "sanctions",
    "metadata": { "sdn_name": "LAZARUS GROUP", "symbol": "ETH", "programs": "DPRK3" },
    "source_url": "https://sanctionssearch.ofac.treas.gov/Details.aspx?id=27307",
    "removed_at": null
  }
]

Free and unauthenticated

No API key, no signup, no metering — the endpoint is burst-limited per client IP and otherwise open.

Typo-tolerant matching

Word-level trigram similarity means "ivanof" still finds a party listed as Vladimir Ivanov, ranked by how close the match is.

Regex mode

Pass mode=regex to match a case-insensitive POSIX regular expression against identifier values and listed names.

Every match attributed

Each result names its source list and list type (sanctions, crime, or risk), with a link to the official record.

Fuzzy search that survives typos

Sanctions list entries are transliterated names, corporate aliases, and long identifiers — exactly the strings people mistype. The search endpoint matches on substrings, whole-string trigram similarity, and word-level similarity against the listed party's name, so a query only has to come close to one word of an entry to surface it.

That word-level layer is what makes the search typo-tolerant: "ivanof" scores highly against a party listed as VLADIMIR IVANOV even though the exact string appears nowhere. Results are ranked by similarity, exact matches first, and active listings always rank above delisted ones — delisted entities stay findable with their removal date, because a party that used to be sanctioned is still review signal.

The same search powers the free SDN search tool on this site and the dashboard's entity search, so what you see there is exactly what the API returns.

Regex search across sanctions lists

Some lookups are patterns, not names: every address starting with a prefix, government IDs in a particular format, domains under a TLD. With mode=regex the q parameter is treated as a case-insensitive POSIX regular expression and matched against identifier values and listed party names across every list.

On the free SDN search tool and the dashboard, the same capability is one convention away: wrap the query in slashes — /^0x[a-f0-9]+$/ — and it runs as a regex search. Unwrapped queries stay fuzzy, so emails and IDs full of literal dots never lose similarity ranking by accident.

Patterns run under a strict server-side time budget, and an invalid pattern returns a 422 rather than a partial answer. Regex results carry no similarity score — a row either matches the pattern or it doesn't.

ModeHowBest for
Fuzzy (default)GET /search?q=lazarusNames, aliases, and identifiers — typos tolerated, results ranked by similarity.
RegexGET /search?q=^0x098b&mode=regexPattern lookups: address prefixes, ID formats, domain patterns.
Exact screeningGET /screen/crypto/{address}Production compliance checks — metered, audit-logged, with a sanctioned/flagged verdict.

Free by design — and what that means

The search endpoint is deliberately outside the metered API: no token, no quota, and searched values are never stored or logged — the endpoint keeps no record of what anyone looked up. The only gate is a per-IP burst limit, advertised in standard RateLimit response headers with a Retry-After on 429s so clients and agents can pace themselves.

That design makes it ideal for lookup UIs, investigations, and quick checks — and the wrong tool for production compliance decisions. Search returns candidates ranked by similarity; it renders no sanctioned or flagged verdict and writes no audit trail. When a check needs to be defensible, use the screening endpoints, where every request is logged with its result.

One free endpoint for sanctions lookups

Ad-hoc sanctions lookups usually mean juggling half a dozen official search sites — one per jurisdiction, none covering crypto addresses well — or standing up your own copy of the lists just to answer "is this name on anything?".

CompliAPI exposes its continuously refreshed, multi-list dataset as a single free search: fuzzy and typo-tolerant by default, regex when you need patterns, with every match attributed to its source list and linked to the official record.

Search is a lookup and investigation aid, not a compliance verdict. It returns ranked candidates without a sanctioned/flagged determination or an audit trail — production screening belongs on the metered /screen endpoints.

How it works

  1. Send a request

    GET /api/v1/search?q={query} — no API key. Add lists= to narrow the scope, limit= for result count, or mode=regex for pattern matching.

  2. CompliAPI matches across every list

    The query runs against listed names and identifier values on every enabled list — substring, trigram and word similarity in fuzzy mode, or your pattern in regex mode.

  3. Read ranked, attributed results

    Results arrive ranked by similarity with exact matches first, each naming its list, list type, and official source record; delisted entities rank last with their removal date.

What you can screen

  • Listed party and company names, typos included
  • Crypto addresses, full or fragment
  • Email addresses and websites
  • Government ID numbers
  • Sanctioned country and region names
  • Case-insensitive POSIX regular expressions (mode=regex)

Where teams use it

Lookup UIs

Put a sanctions search box in an internal tool or public page without provisioning keys — the free tier of this site's own SDN search tool runs on exactly this endpoint.

Investigations

Chase a name variant or a partial identifier across every list at once, with delisted history included.

Pattern hunting

Use regex mode to find listed addresses by prefix, IDs by format, or domains by pattern.

Agent pre-checks

Let an AI agent look up a name before deciding whether a metered, audited screening call is warranted.

Scope and limitations

Search is built for lookups, and its boundaries are deliberate. Know them before you build on it:

No compliance verdict

Results are ranked candidates, not a sanctioned/flagged determination, and nothing is audit-logged. Defensible checks belong on the /screen endpoints.

Rate limited per IP

The free endpoint carries a per-IP burst limit. Responses advertise the window in RateLimit headers; a 429 carries Retry-After.

Top results only

Queries return up to 25 results with no pagination — refine the query rather than paging through a long tail.

Regex has a time budget

Patterns run under a strict server-side timeout, so a pathological expression returns an error rather than an answer.

Frequently asked questions

Is the sanctions search API free to use?

Yes. GET /api/v1/search is unauthenticated and never metered — no API key or signup. The only gate is a per-IP burst limit, advertised in RateLimit response headers, with a Retry-After header on 429 responses.

How does the typo-tolerant matching work?

Queries are matched with substring and trigram similarity plus word-level similarity against the listed party's name, so a near-miss on one word is enough: "ivanof" finds a party listed as VLADIMIR IVANOV. Results are ranked by how close the match is, exact matches first.

How do I run a regex search against the sanctions lists?

Add mode=regex and the q parameter is treated as a case-insensitive POSIX regular expression, matched against identifier values and listed names. On the free SDN search tool and the dashboard, wrap the query in slashes — /^0x[a-f0-9]+$/ — for the same thing. Invalid patterns return a 422.

Are my search queries stored or logged?

No. The search endpoint is deliberately outside the metered, audit-logged API: searched values are never stored, and no per-request record is kept. That privacy is also why search results carry no audit trail — production screening on /screen is what writes one.

Why do delisted entities appear in search results?

Because a formerly sanctioned party is still useful review signal. Delisted entities rank below every active listing and carry a removed_at date, so they are clearly marked. The screening endpoints, by contrast, never match delisted entities.

When should I use the screening endpoints instead of search?

Whenever the result feeds a compliance decision. Search returns ranked candidates with no verdict and no logging; the /screen endpoints run exact-match checks that are metered, audit-logged, and return an explicit sanctioned/flagged determination per list.

Related

Need more than a lookup?

Get a free API key for exact-match screening with quotas, audit logging, and a sanctioned/flagged verdict on every check.

14-day free trial. No credit card required.

CompliAPI provides data and tools that support compliance workflows. It does not provide legal advice, and organizations should determine their obligations with qualified counsel.