Building a compliance policy happens in two stages. First, you define a Trigger and an Outcome: the Trigger decides when and how a transaction is screened, and the Outcome decides what happens automatically based on the result. Once that policy is live, Fireblocks applies it to every matching transaction without further action from you.

This article covers that first stage: building the policy itself. Once a result comes in, you can also act on it manually, for example unfreezing or rescreening a transaction. That is covered separately, in Transaction Screening Operations.

Trigger (screening policy)

A Trigger rule defines which transactions are checked, and what Fireblocks does on a match:

Rules are built from conditions such as source, destination, asset, and amount, and are evaluated from top to bottom: the first matching rule wins, and a catch-all default rule is required as the last entry, so every transaction always has a defined path through the policy.

Trigger fields are broadly consistent across providers. Some Travel Rule providers use an expanded rule field set, including options to target a specific legal entity or address. See Compliance Policy rule parameters for the exact fields each provider supports.

Outcome (post-screening policy)

An Outcome rule maps a screening result to an automatic action. Every provider supports the baseline:

See each provider's own article for exactly which of the provider-dependent actions it supports.

What counts as a "result" also differs by provider: a risk score band from an Anti-Money Laundering (AML) and Know Your Transaction (KYT) provider, a Travel Rule message status from a Travel Rule provider, or a group match from Address Registry Screening. See Compliance Policy rule parameters for the exact fields, values, and actions each provider supports.

An Outcome is applied automatically, the moment a result comes back. It is not the same as manually intervening on a transaction afterward. If you need to bypass, unfreeze, or rescreen a transaction that has already been actioned, see Transaction Screening Operations.

Compliance policy settings

Once a policy exists, you can:

• Edit it, via Console or API. Trigger fields are broadly consistent across providers; Outcome fields differ by provider, so the fields you see when editing depend on which provider's policy you are editing. Some Travel Rule providers do not yet support Console configuration; for these, submit a request to Fireblocks Support, copying your workspace Owner, whose approval is required for the change.
• Delete it.
• Disconnect a provider. Disconnecting removes the policy tied to that provider along with it.

Advanced configuration

Beyond Trigger and Outcome, each check type has workspace-level settings that control how screening behaves at the edges: outages and timeouts.

• Bypass on failure. On by default. If your provider is unreachable or does not return a result before your configured delay elapses, the transaction bypasses screening rather than failing: outgoing transactions are sent, and incoming funds are released. Turning this off means a missed result fails the transaction instead: outgoing transactions are not sent, and incoming funds are frozen.
• Inbound and outbound transaction delay. How long Fireblocks waits for a result before the bypass-on-failure behavior above kicks in. Defaults and maximums vary by check type and provider.

These settings are workspace-level and apply per check type (AML, Travel Rule, and so on), not per provider. For who can unfreeze or bypass a transaction without a support ticket, see Transaction Screening Operations.

Limitations

• Today, you configure a policy separately for each connected tool. There is no single policy that applies across every tool at once.
• Some transaction routes never reach the Trigger at all, regardless of check type: vault-to-vault, vault-to-exchange, Gas Station-to-vault, and non-custodial-wallet-to-non-custodial-wallet within the same workspace. This is confirmed for AML; other check types built on the same screening pipeline likely behave the same way, though that has not been independently confirmed for each one.

FAQ

The questions below are the ones readers ask most often.

What happens if a transaction does not match any rule?

The required catch-all default rule applies. Every transaction always has a defined outcome, even if nothing more specific matches.

Can I set different rules for different providers?

Yes. Each connected tool has its own Trigger and Outcome today, configured independently. See Limitations above.

Why can I not edit some of my Travel Rule policies in the Console?

Some Travel Rule providers do not yet support Console-based policy configuration. For these, contact Fireblocks Support to make the change.

When do I need to set up a Customer Reference ID?

Only if you want it. Customer Reference ID is an optional field you attach when creating a transaction, most commonly used to send an internal tag, such as a customer code or note, to your AML/KYT provider, so you can identify the transaction in their own system.

It is not part of your compliance policy and has no effect on Trigger or Outcome. It is available via API only, not the Fireblocks Console. See Create a new transaction for the customerRefId field.

Developer portal

See AML policies for the screening policy and post-screening policy, Travel Rule policies for Travel Rule policy, and Address Registry for address registry screening.