Screen Exposure For OFAC

Runs a sanctions screening for one exposure and saves the result to it, in one call: the values you send are submitted to the sanctions provider, the normalized answer is written to the exposure’s screening field, and that answer is returned.

Screening is advisory. It never blocks a save, a quote, a bind, an issue, or an import. A potential match is a similarity hit for a human to review, never a determination that the party is sanctioned.

The carrier turns screening on by configuration. A screening runs through a placed screening field: an exposure field of type Object: OfacScreening, single-cardinality, placed on a card with the OFAC Screening input modality. fieldReferenceId names that field. A field that is not placed that way returns 400 (ofac-screening-field-not-placed) and no provider call is made.

You cannot choose the sanctions lists, the match threshold, or the provider. They are fixed platform settings, recorded on each result so a reader knows what it covered. Sending sources or minScore is a 400, not a silently ignored key.

requestValues replaces the request values wholesale. Send the whole set you want screened, not a patch — any request value you leave out is cleared, because the saved record has to say what was actually submitted. Omit requestValues entirely to re-screen the values already stored on the exposure.

Retries and repeat calls

Every call is a fresh screening, and every call is billable. There is no idempotency key and no reuse of a recent result: a repeat request re-submits to the provider and the new answer replaces the stored one, along with any review decisions recorded against the previous run.

That makes retrying safe — a call that times out can simply be sent again, and screening blocks nothing in the meantime — but it means a retry loop costs a provider call each time. Retry a failed screening deliberately, not automatically on a tight interval.

Re-screening is also how a sanctions-list update is picked up: a saved result describes the list as of screenedAt, so a party cleared last month is not cleared today.

Reading the result

A result carries three independent axes — status (did the call happen), screeningOutcome (what the provider returned), and reviewOutcome (what a human concluded) — plus screenedRequest, the snapshot of what was submitted. Compare the exposure’s current screening values against that snapshot to decide whether a saved result is still current; there is no staleness flag.

A provider failure is a 200 with status: failed, not an HTTP error: the failure is durably recorded on the exposure so it is visible rather than lost. Reserve HTTP errors for requests that were refused.

Importing exposures does not screen

Creating or updating an exposure through the entities API stores screening request values like any other field data and runs no screening — no provider call, no result. Screening happens only through this endpoint (and the application UI). Automatic screening on import is deliberately deferred.

Required permission: exposure.edit