Screen a name against global sanctions and watchlists.

FREE TIER: 3 screens per day without an API key. PAID: Unlimited screens with an API key.

Checks the name against 300+ sanctions, designation and watchlists worldwide, including US OFAC (SDN and non-SDN), EU, UK OFSI, Canada, Switzerland, Australia, New Zealand, Japan, Israel and national lists. Returns matching entities with similarity scores. The response says how many lists were actually searched (lists_searched); report THAT, and do not present a fixed per-jurisdiction table of "clear" rows, which asserts a per-list result the screen does not return and understates the coverage.

For a company or an individual the screen covers every list, including adverse media, PEP and debarment registers. For a BANK or other financial institution it returns sanctions DESIGNATIONS only: a warning-list entry naming a bank is usually a clone-firm alert about fraudsters impersonating it, and the feed carries nothing that tells the two apart.

When the name resolves in our bank directory, each designation is also cross-referenced against that institution's record (country, entity type, and the name or ALIAS that earned the fuzzy score) and contradicted rows are removed. ALWAYS read the verification block, which is on every response: applied: false means nothing was cross-referenced and the rows are raw feed output — either the name is not in our bank directory, or the subject is a company or individual, which has no directory record to check against. Never report an applied: false result as verified, and never report an empty one as verified-clear. Screening a bank by BIC, or calling swift_lookup, gets a verified answer.

On an unverified response every row also carries query_match, listing which of the screened words appear in that row's own name or aliases and which do not. Nothing is removed on account of it. Weigh it against the score: a row sharing one word out of four with the query is usually a different entity, and its action is that entity's action, not a verdict on the party screened. Absence is not proof — non-Latin aliases contribute no words, and a transliterated designation of the right party can show words missing — but where every query word is present, take the row at face value.

On a COMPANY or INDIVIDUAL screen the response also carries coverage_gate. It is the same question asked once for the whole payload: how much of the name you screened actually appears on the rows that are blocking. When applied is true the payload-level recommended_action has been lowered from BLOCK to REVIEW, because no blocking row carries more than half of the distinctive words you screened — report a possible match that needs identity confirmation, NOT a designation, and do not reinstate BLOCK from the row-level action fields. Nothing was removed: every row the feed returned is still in matches, with its own score and action intact. When applied is false the verdict is exactly what the feed set.

Args: name: The person or entity name to screen. api_key: Your Ohmyfin API key (prod-...). Can also be passed via KEY header or Authorization: Bearer header. Optional — free tier allows 3 screens/day without a key. threshold: Minimum match score 0-100 (default 85). subject_type: What is being screened: "bank" for a financial institution, "party" for a company or individual, or "auto" (default). A name the bank directory resolves is treated as a financial institution whatever you pass here.

Examples: sanctions_screen("Acme Trading Ltd") sanctions_screen("John Smith", threshold=90) sanctions_screen("First Abu Dhabi Bank", subject_type="bank") sanctions_screen("Acme Trading Ltd", api_key="prod-abc123...")