One call screens a name against the OFAC SDN, EU and UN consolidated lists — with an audit trail a regulator can follow. Not a lookup a developer remembers to call: a gate that sits inside signup, key issuance and payment.
Screening gaps at self-serve signup and at payment are the two places post-incident reviews keep landing on. Every one of them is a point where your system already pauses and waits for a yes — that is where the check belongs.
Screen the person or company the moment they create an account — before a key exists and before anything is provisioned.
One call before the credential is minted. A blocked party never receives a key, so nothing downstream has to be revoked.
Screen at the payment step, including the beneficiary. This is the gap most post-incident reviews point at.
A key is required. The response shape below is abridged — the full schema is in the reference.
curl -sS https://sanc.mooocopy.com/screen \ -H "X-API-Key: $SCREENING_KEY" \ -H "Content-Type: application/json" \ -d '{{"query_name": "AERO-CARIBBEAN"}}'
{"total_matches": 1,
"data_version": "2026-10-02",
"candidates": [{
"entity_name": "AERO-CARIBBEAN",
"list_name": "OFAC-SDN",
"confidence_score": 0.9,
"explanation": { "match_type": "alias" }
}]} match_type is one of
exact ·
alias ·
fuzzy ·
fuzzy_alias.
List lookup plus fuzzy name matching is a commodity. These are the parts that survive a compliance review.
Every hit reports how it matched — exact, alias, fuzzy or fuzzy_alias — with a configurable threshold. The dangerous direction for screening is a false negative, so matching is built to over-report rather than miss.
Every screen is recorded. Compliance teams need to show what was checked, when, and against which data version — not just get a yes/no today.
Matches at or above 0.9 confidence are flagged for human review alongside the automatic result, so the high end of the range never decides itself.
Each response carries data_version and sources, so a decision can be tied to a specific list snapshot later.
Multi-tenant API keys, per-tenant watchlists and per-tenant rate limits — one account cannot see or exhaust another.
An optional LLM cascade exists and is off by default. Screening data does not leave the box unless you deliberately enable it.
All operational endpoints are open; /screen requires a key.
| Method | Path | Purpose |
|---|---|---|
POST | /screen | Screen an entity against the sanctions lists |
GET | /watchlists | List tenant watchlists and versions |
POST | /watchlists/{list_name} | Upload a tenant watchlist (CSV, new version) |
GET | /cases | List review-queue cases |
GET | /cases/{id} | Read one review case |
POST | /cases/{id} | Decide a pending review case |
GET | /audit | Query the append-only audit trail |
GET | /ready | Record count, data version and active sources |
GET | /openapi.json | OpenAPI specification |
GET | /health | Liveness probe |
Active sources: OFAC-SDNEU-ConsolidatedUN-Consolidated
Listed here because they are the difference between a list lookup and a gate an AI platform can rely on. They are not implemented yet.