Compliance

OpenSanctions in a decision flow.

A Connection node calls OpenSanctions mid-decision with the credentials your own contract issued. Whatever comes back is data the rest of the flow can read, branch on, and keep in the decision's trace.

Category: Compliance
Type: Integration
Authentication: api_key
Test environment: Production host only

What a flow can call

5 operations, each one a step you can place on the canvas.

POST/match/default
Screen a person
The screening call. Send the identity you hold and get scored candidates back.
POST/match/default
Screen a company
Same call for a business — dealer, employer, or a commercial borrower.
GET/search/default
Free-text search
Full-text lookup for an analyst reviewing a hit, not for automated screening — use Screen a person for that, which scores properly.
GET/entities/$data.opensanctions_entity_id
Fetch one entity
The full record behind a match: every alias, listing, source dataset and relationship.
GET/catalog
List datasets
Which lists the key can screen against, and when each was last updated.

Provider documentation: https://www.opensanctions.org/docs/api/

Where it sits in the decision

A provider call is a node, not a side effect.

The call runs where the policy needs it — after the cheap checks that might make it unnecessary, before the rules that depend on it. Calls that do not depend on each other run together rather than in sequence.

Because it is part of the run, the response is part of the record. When someone asks why an applicant was declined months later, what OpenSanctions returned at the time is in the trace, not re-fetched from a service whose answer has since changed.