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.

A row surviving that cross-reference is NOT the same as a row the cross-reference supported. Each verified row carries adjudication: corroborated means the check backed it and it is a designation against this institution; not_corroborated means it survived the false-positive floor but nothing tied it to this institution — typically country_conflict: true, the designated entity being domiciled elsewhere. is_false_positive: false is only that floor test and is never a finding; read adjudication instead. When NOTHING is corroborated the response carries verification_gate.applied: true and recommended_action has been lowered from BLOCK to REVIEW: report a possible match needing identity confirmation, do not reinstate BLOCK from the row-level action fields, and do not report the institution as clear either — every row is still in matches and the open question is which legal entity the counterparty is.

verification_gate is on every bank response whose verdict asserts a finding (BLOCK, REVIEW, MONITOR or INFORM), and it asks one question: does that verdict survive the evidence this payload actually publishes. A REVIEW, MONITOR or INFORM over an EMPTY matches list is not a weaker BLOCK. This screen publishes designations only for a financial institution, so the rows that carried such a verdict are the non-designation ones (warning lists, adverse media, PEP, debarment) it withholds — counted in non_designation_rows_withheld and never listed. Those responses come back recommended_action: CLEAR with verification_gate.applied: true, meaning no DESIGNATION matched. Say exactly that, and keep the scope with it: it is never a clean bill across every list. The gate stands down, and the verdict stays, when our own verification removed a designation as a false positive (designations_filtered_as_false_positives), when the directory record is not clean, or when the row that set the verdict was off-page.

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.

The response also carries coverage_gate, set by the screening engine: how much of the name you screened actually appears on the rows that are blocking. When applied is true the payload-level recommended_action was 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 stands and reason says why. A reason of identifier_query means the name screened was a registration or tax number that matched a designation's own identifier: that is a match on identity, not on wording, so report the BLOCK as it stands.

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...")