Setting up a sanction check rule

Rule creation

Create a sanction check configuration for a scenario from the rules page. A given scenario can have at most one sanction check configuration.

Rule configuration

Global organization configuration of sanction checks

similarity matching threshold: the minimum similarity score (as a %) for an entity to be considered a possible match on a sanction list. The default value is 70% similarity score, which we believe is a reasonable base value in most cases. Higher values will result in less hits, at the risk of missing some true positives.
max number of hits to consider: maximum number of hits for a sanction check review. If a sanction check has more possible hits than this, the search must be refined before the sanction check can be marked as "not a hit". See the refine page. The default value is 30.

The organization sanction check settings are configured by an administrator in the settings/scenarios tab.

Specific rule configuration

The body of a sanction check rule is configured a bit differently from a regular scenario rule. It expects the following settings:

configuration	format	effect
forced outcome	review, block_and_review, decline	If the sanction check has at least one possible match, it forces the outcome of the decision. This overrides any outcome determined from the aggregated score of the other rules.
trigger condition	A trigger condition formula, in the same format as the trigger condition defined at the scenario level.	Used to only perform the sanction check on payloads triggering the scenario that pass certain conditions.
field selectors	Select fields from the payload or ingested data to be used for the sanctioned entity search. Similar input to what is used in rules.	See details below.
set of lists to filter on	Consolidated lists from Opensanctions, grouped by geographic region for convenience.	Selects the sanction lists that are taken into account for screening in the scenario.

Details on field selection

Three types of input can be configured to select the actual data that is used for entity search.

transaction label: expects a field from the payload, or a value from ingested data related to the payload
counterparty name: can use one or several (concatenated together) values from the payload, or values from ingested data related to the payload
counterparty unique identifier: not directly used for matching, but allows to define a unique identifier for an entity that is being screened on, in order to whitelist a pair of [counterparty identifier - listed entity] and reduce recurring false positives. Typically, the value would be an account number, IBAN or crypto wallet hash.

One at least of transaction label and counterparty name must be configured for the rule to work. The counterparty unique identifier is optional, but recommended to limit false positives in the long run.

configuration of the trigger condition and counterparty identifier selection

configuration of the matching field selection and sanction lists to be used