Skip to main content
A compliance policy decides what happens to a transaction during screening. You build your policies in the Console, under Policies > Compliance. Through the API, you read the rules you built, configure how screening behaves when a provider is slow or unavailable, and set limits that apply across your workspace. To act on a single transaction after screening, for example, to bypass a rejection or unfreeze funds, see Transaction Screening Operations.

​
How a policy is structured

Each check type has its own policy, made of two parts:
  • The Trigger (Screening Policy) determines which transactions are screened.
  • Outcome (Post-Screening Policy) decides what happens automatically once a result comes back. What counts as a result depends on the check: a risk level for AML/KYT, a message status for Travel Rule, or a group match for Address Registry Screening.
See “Building a Compliance Policy” in the Help Center for instructions on building rules in the Console.

​
What you can do through the API

Rules cannot be built, edited, or deleted through the API. Sumsub and GTR do not yet support Console configuration either: to change their rules, submit a policy template to Fireblocks Support, copying your workspace Owner, whose approval is required for the change.

​
Read your rules

​
What a rule looks like

Each rule is an if-then statement: if a transaction matches the rule’s conditions, Fireblocks applies the rule’s action. For example, a Trigger rule can say “if an outbound ETH transaction is over 10,000 USD, screen it”, and an Outcome rule can say “if the risk level is high, reject it”. Rules come back in the order Fireblocks evaluates them. The first rule whose conditions match a transaction decides its action, so a rule’s position matters as much as its content. The last rule is always a catch-all default.

​
Configure outage and delay behavior

Each check type has settings for when a provider is unreachable or slow. They apply per check type (AML/KYT, Travel Rule), not per provider. Defaults and maximums for the delays vary by check type and provider. Update requests accept an optional Idempotency-Key header, valid for 24 hours.

​
Set workspace-wide limits

Two settings control screening operations across your whole workspace, through PUT /screening/configurations: When an operation is blocked, it requires a Fireblocks Support ticket instead.

​
Disconnecting a provider

Disconnecting a provider also removes the policy tied to it.
  • AML/KYT (Chainalysis, Elliptic, TRM Labs): through Fireblocks Support only. There is no API or Console option.
  • Travel Rule (Sumsub, GTR): through the API, with Disconnect customer integration. This permanently removes the stored credentials.

​
Limitations

  • One policy per connected tool. You configure a policy separately for each connected tool. There is no single policy that applies across every tool at once.
  • Routes that are not screened. Some transaction routes are not screened, whatever the check type: vault account to vault account, vault account to exchange, Gas Station to vault account, 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.