Sanctions Checking¶

Send Workbench includes an automated sanctions screening capability that checks the insured and reinsured parties on a risk against the Dow Jones World-Check database (and optionally LexisNexis). This page explains how sanctions checking works, how it integrates with the risk action workflow, and what a configurator needs to set up.

Architecture overview¶

Sanctions checking involves three platform components working together:

Risk Action → Pipeline → Workflow Flowable (BPMN) → Dow Jones API
                                                        ↓
                                            Sanctions Check Service
                                                        ↓
                                            Result stored on Risk Record
                                                        ↓
                                            Completion Pipeline fires

Workflow Flowable — orchestrates the screening process using a BPMN workflow. It retrieves the risk's party details, calls the Dow Jones API, and routes results back to the platform.
Sanctions Check Service — stores screening results and exposes them to the UI and downstream pipelines.
Pipeline components — trigger the screening process and handle results within the action workflow.

Note

Workflow Flowable is currently used for sanctions checking. The platform roadmap plans to move this logic into the Sanctions Check Service directly, eliminating the Flowable dependency.

Enabling sanctions checking¶

Sanctions checking is enabled via be_config.json (S3 business config). Note that featureSwitches in be_config.json is a JSON-encoded string, so the switch is toggled inside the embedded JSON:

"featureSwitches": "{\"SANCTIONS_CHECK\": true}"

Provider-specific connection details (URL, API key, threshold) are typically held in the environment profile (DynamoDB data.json) rather than in be_config.json, since they vary per environment and include secrets. Exact key names vary by platform version — confirm the current shape with your delivery lead. Illustrative structure:

{
  "sanctionsConfig": {
    "provider": "DOW_JONES",
    "dowJones": {
      "apiUrl": "https://api.dowjones.com",
      "apiKey": "${DOW_JONES_API_KEY}",
      "threshold": 80
    }
  }
}

Field	Description
`provider`	Screening provider: `DOW_JONES` or `LEXIS_NEXIS`
`apiUrl`	API endpoint for the provider
`apiKey`	Secret API key — inject via environment variable, never hardcode
`threshold`	Match confidence threshold (0–100). Matches below this score are not flagged

Warning

The sanctions API key is a sensitive credential. It must be stored in AWS Secrets Manager and injected at runtime. Contact your DevOps team to set this up.

Screening pipelines¶

The core config repository ships three sanctions pipeline definitions that you reference from your action config:

Pipeline	When to use
`sanctions_check_insured_and_reinsured_party`	Risk has both insured and reinsured parties
`sanctions_check_single_party_for_additional_entity`	Checking an additional entity only
`sanctions_check_foreign_company_lookup`	Lookup for a foreign (non-UK) company

These are defined in config/core/pipelines/ and do not need to be redefined in your client config. Reference them by name from your action's initialPipeline field.

Wiring sanctions into a risk action¶

Sanctions screening is typically a prerequisite step before binding. Add it as an action with an initialPipeline pointing to the appropriate screening pipeline:

{
  "code": "sanctions_check",
  "label": "Sanctions Check",
  "actionGroupCode": "compliance",
  "placingType": "OPEN_MARKET",
  "initialPipeline": "sanctions_check_insured_and_reinsured_party",
  "actionPrerequisites": ["appetite_check"]
}

Then reference the sanctions check as a prerequisite on your bind action:

{
  "code": "bind",
  "label": "Bind",
  "actionPrerequisites": ["sanctions_check", "structured_quote"]
}

This ensures binding cannot proceed until screening has been completed.

Outcome status codes¶

After screening, the platform populates the risk record with a sanctions outcome code. This is used in display expressions and action prerequisites to route the risk appropriately.

The core business constants define the standard outcome codes at:

config/core/business-constants/sanctions_check_referral_outcome_first_line.json

Common outcomes:

Code	Meaning
`CLEAR`	No matches found — risk can proceed
`MATCH`	One or more potential matches — requires manual review
`REFERRED`	Referred to compliance team
`CLOSED_WITH_WARNING`	Reviewed and approved with a noted warning
`REJECTED`	Rejected following sanctions match

Handling matches in the UI¶

When a match is returned, the risk action transitions to a manual review state. Compliance users review the match details and choose an outcome. Two sub-pipelines in the core config handle common review outcomes:

Close_Sanction_With_Warning.json — closes the sanctions check with a warning note
The REFERRED outcome triggers a task assignment to the compliance team

You can control which review options are displayed to which roles using displayCriteriaExpression on the action's operation definitions.

Sanctions check for additional entities¶

Additional entities (e.g. a co-insured or a subsidiary) can be screened individually using the sanctions_check_single_party_for_additional_entity pipeline. This is typically triggered by a sub-risk action on the Additional Entities section of the submission form.

Display criteria for sanctions outcomes¶

You can conditionally display fields or actions based on the current sanctions outcome using JSONPath expressions:

{
  "displayCriteriaExpression": "$[?(@.riskData.sanctionsCheckOutcome == 'CLEAR')]"
}

This is useful for showing the bind action only once sanctions are clear, or for showing a "Refer to Compliance" button only when the outcome is MATCH.

Financial crime referrals¶

Alongside sanctions checking, the platform supports financial crime referral tracking. The outcome codes for this are defined separately in:

config/core/business-constants/financial_crime_referral_outcome_first_line.json

Configuration follows the same pattern as sanctions outcomes.

Local development¶

Sanctions check pipelines require the Workflow Flowable service (port 4839) to be running. In local development, you can either:

Run Flowable and configure a sandbox API key for Dow Jones (if available)
Stub the pipeline response by temporarily replacing the initialPipeline with a pipeline that returns a hardcoded CLEAR outcome

The second approach is useful when working on downstream actions that depend on sanctions clearance but you do not need to test the screening itself.