Policy best practices

Policies are an important security tool

Thoroughly think through and examine your Policies before submitting them for approval.

Remember the first-match principle

The Policy Engine will apply the first rule in a Policy that matches a submitted transaction. Learn more here.

Keep your Policies as simple as possible

Simplicity ensures clarity and control. Only use rules that you truly need for good governance.

Remember that rules are one-way

A rule for transactions from a specific source to a specific destination doesn’t apply the opposite way.

List more specific rules above more general rules

Example: To allow transfers between all vaults except vault X, first list a rule blocking vault X as a source or destination. Then below it, list a general rule allowing transfers between all vaults.

Put accumulation rules first (if applicable)

Accumulation rules sum up the value of multiple transactions. If rules based on single transactions are listed above accumulation rules, your accumulation rules won't be applied due to the first-match principle. 

However, all transactions are included in accumulation calculations regardless of which rule they match. Each rule evaluates independently by calculating totals for its time period; the amount threshold triggers the rule, but doesn't filter which transactions are counted. Accumulation calculations operate independently of rule matching, so a transaction can match one rule while simultaneously contributing to another rule's accumulation total.

List amount-based rules for the same parameter from high to low

This ensures stricter rules for higher-value transactions are enforced. At the bottom of the group of rules, always list a rule that uses an amount range with a $0 minimum amount and no maximum amount.

Use accumulation to control transaction volume

You can set a maximum accumulated volume over a certain time across a combination of initiators, sources, or destinations. Example: All transfers over a 12-hour period can’t surpass $15 million.

Using volume accumulation helps you prevent users from being able to create multiple small transactions over time as a workaround to your Policy.

Best practices for user groups

Create and implement user groups for simplicity and time savings when making Policy rules. Learn more about User Group Management.

• When you assign a user group as Initiator, all its users must have roles that can either initiate or sign transactions.
• If you list a user group under Approved By, all its users must have roles that are authorized to approve transactions.
• Avoid placing users with and without signing privileges in the same group, such as Editors and Signers. If you list a group with both Editors and Signers as an Initiator for a rule, you must assign a designated signer to the rule. If you only include Signers in the group, you can assign the Initiator as the rule’s designated signer.
• Create separate groups for Console users and API users, as they may function differently.
• When creating or updating a group, check how it affects your Policy rules. Are there enough approvers remaining to meet any approval thresholds after you edit the group? Is the Policy logic kept intact?
• If you list two or more groups as approvers, first ensure that no user is in both groups. Otherwise, that user’s approval will count twice towards your approval threshold.

Creating rules for an API user as an approver

In your Policies, you can assign API users as approvers and enable them to approve certain transactions using an API Co-Signer. They must be assigned access to be able to initiate or sign transactions.

Creating rules for a semi-automated transaction flow

• In a semi-automated transaction flow, an API user initiates transactions and a Fireblocks Console user signs them from their mobile device.
• In a semi-automated transaction flow, you assign Editor or Non-Signing Admin role users as API users and assign the Console user as the rule’s Designated Signer.

Creating rules for a fully automated transaction flow

• In this flow, there are usually two API users: one initiates transactions while the other approves and/or signs them through your API Co-Signer machine.
• In this flow, you assign Editor or Non-Signing Admin role users as API users to initiate transactions and assign Admin or Signer role users as API users who are approvers or the Designated Signer.

You can apply Policy rules to API users too

You can apply Policy rules to API users just like any other user. Make sure to create the API user in your workspace before applying rules to it.

Select Initiator can sign if you don't want a Designated Signer

You can enable this setting as long as the Initiator has a role that is authorized to sign.

Select Transaction initiator counts as approver or they won’t count towards your threshold

This makes their approval automatic and counts it if there is an approval threshold in the rule.

There's no wildcard shortcut or pattern matching for selecting sub-groups of vaults

When selecting multiple sources or destinations, there's no shortcut to select sub-groups of similar vaults. Either choose All Vaults or individually select all vaults for which the rule should apply.