Understanding how the Policy Engine evaluates and applies rules is essential for creating effective Policies.

Policy rules

Policy rules have two components that you can define:

• Parameters: Define which characteristics a transaction must "match" for the rule to apply. Scope: Who can initiate it? Where can it go to or from? Which asset is the rule for?
• Actions: Define what will happen next:
  • Allow: The Policy Engine automatically approves and forwards to a designated signer.
  • Approved by: Other users or user groups must approve or deny the allowed transaction. All of the associated user roles must be authorized approver user roles.
  • Block: The Policy Engine automatically blocks the transaction.

The first-match principle

Policies operate according to the first-match principle. For each submitted transaction, the Policy Engine scans the appropriate Policy from top to bottom and applies the first rule that it matches. The scan stops after a successful match. The top rule is checked first. If it is a match, it performs the rule's action. If not, rule two is checked, and so on.

Due to the first-match principle, the order of your rules is important for receiving the intended outcomes. For example, you may not want to place a rule that allows any transfer in any amount at the top of your Transfer Policy since most transactions would be allowed without needing to meet the stricter requirements in the other rules. Rules with overlapping parameters should be ordered so that higher priority rules are scanned first.

For security, the default block-all rule is always the last rule at the bottom of each Policy. If no other rule matches a transaction, the block-all rule blocks it.

Example: Policy Engine applies the first-match principle to a transaction

John Smith, a trader at company XYZ, submits a transaction. In his company's workspace, he is assigned the following workspace role and user group:

• Role: Signer, authorized to sign transactions.
• User group: Traders, a custom group that John's company created in their workspace. The group has all traders with Signer roles.

John submits a transfer request for $500,000 of Bitcoin from his vault account to one of his whitelisted counterparties. His company's Transfer Policy has four rules.

After John submits the transfer request, the Policy Engine:

1. Skips rule one, which only applies when a Management group user is Initiator.
2. Skips rule two, which only applies to transactions greater than $1 million.
3. Applies rule three because the transaction matches each of its parameters. Sends the request to the approver defined under Action — for this rule, it is the Head of Trading.
4. After the Head of Trading approves the transaction, a signing request is sent to the Designated Signer. Since rule three sets Initiator as Designated Signer, John can then sign the transaction himself.

Ordering your rules

It's important to put rules in order from the most restrictive rules to the least restrictive rules to correctly apply the first-match principle. The order of rules can affect whether or not the Policy Engine properly enforces your Policy rules.

• Put time period-based rules before single-transaction rules. Doing this ensures that time-based restrictions get enforced.
• Place more restrictive rules first to ensure proper enforcement.

Example: You have two rules, both applying to the same transaction Initiator:

• Rule one has an amount range with a $1 million minimum, no maximum, and needs one approval.
• Rule two has an amount range with a $10 million minimum, no maximum, and needs two approvals.

List the more restrictive rule (rule two) first so the Policy Engine enforces its stricter threshold and approval flow. If rule one is listed first, a $20 million transaction would match it and only need one approval. However, the intent of rule two is that a transaction that big needs two approvers. If you list rule two first, you don't have this issue.

Using user groups in Policy rules

User groups enable you to apply rules to sets of multiple users without needing to add new rules when the users change. This allows you to simplify your Policies and use groups for key actions like initiating and approving transactions.

You can also define approval quorums within a group as part of the Approved by action for a rule. For example, you can make a rule that requires any two members of a user group called Management to approve if a transaction matches that rule's parameters.

Two more ways you can use user groups in rules:

• The workspace Owner can initiate a certain type of transfer, but at least one other member of the Admins user group must approve.
• Any member of the Admins user group can initiate a certain type of transfer.

Learn more about User group management and best practices for detailed guidelines and steps to create and manage user groups.

Next steps

• Create, edit, and publish a Policy — Start building your first Policy rule
• Policy best practices — Follow recommendations for effective Policy management
• Policy rule parameters — Reference guide for all available parameters
• Policy examples — Review common use cases