Skip to main content
Each check type has its own compliance policy, built in the Console under Policies > Compliance. Outage and delay behavior and workspace-wide limits are settings outside the rules. To act on a single screened transaction, see Transaction Screening Operations.

How a policy works

A policy has two parts, three for Sumsub and GTR, each a list of if-then rules. Fireblocks evaluates rules top to bottom; the first match decides the action, and the last rule is always a catch-all default. Fireblocks sends a transaction to the provider once per screening, per destination, regardless of how many rules match. For an outgoing transaction with several destinations, each destination is screened, and the most restrictive result determines the outcome: freeze takes precedence, then reject, alert, accept. All results are returned in complianceResults.amlList; the deciding one is complianceResults.aml. Sumsub and GTR apply the same rule (reject, wait, alert, accept). Notabene works per transaction. Bring Your Own Screening gives one decision per transaction. TRM Labs returns only the worst result in amlList. Incoming AML/KYT screening supports one destination; transfers with more are bypassed as BYPASSED_FAILURE. A result is a risk level for AML/KYT, a message status for Travel Rule, or a group match for Address Registry Screening. Example: a Trigger rule “if an outbound ETH transaction is over 10,000 USD, screen it”, and an Outcome rule “if the risk level is high, reject it”. To build rules, see Building a Compliance Policy on the Help Center.

What you can do through the API

Rules return in evaluation order. To change Sumsub or GTR rules, submit a policy template to Fireblocks Support, copying your workspace Owner, whose approval is required.

Outage and delay settings

Settings for when a provider is unreachable or slow. They apply per check type, not per provider, with one exception: bypassScreeningDuringServiceOutages does not apply to TRM Labs, whose timeout behavior comes from its own policy rules. Defaults and maximums vary by check type and provider. Updates accept an optional Idempotency-Key header, valid for 24 hours.

Workspace-wide limits

A blocked operation requires a Fireblocks Support ticket instead.

Limitations

  • One policy per connected tool. No single policy applies across every tool.
  • Unscreened routes, AML/KYT and Notabene only: vault-to-vault, vault-to-exchange, vault-to-Gas Station, Gas Station-to-vault, and non-custodial wallet to non-custodial wallet within the same workspace.

On the Help Center

To build rules in the Console, see Building a Compliance Policy.