Approval policy
The approval policy is the layer that decides, for each operation, whether it simply goes through, needs another person’s approval, or is denied. Your role says what you are allowed to attempt; the approval policy says what actually happens.
You do not have to create it: it comes with your organization, and it starts with the bare minimum — it allows editing the approval policy and nothing else.
How it works
It is an ordered list of rules. Each operation is checked against them from top to bottom, and the first matching rule wins. That rule decides one of three things:
What rules you can create
The button is Add rule, and the form has three steps: what operation it covers, when to apply, and what to do. At the end there is a review screen —Review your rule— where you confirm the trigger, the conditions, the action, and the approvers before saving.
What operation it covers
Each rule covers a single type, or all operations at once:
It is the only operation the wildcard leaves out, on purpose: if you want to control who changes the rules, you have to write a rule whose type is Policy management. No broad rule covers it by accident.
When to apply
First come the two amount thresholds, and below them the Apply to section with the rest of the filters. Everything is optional: anything you leave as “Any…” does not narrow anything.
Amounts only make sense for operations that move money. For passkey enrollment, user invites, and policy management they are ignored: those rules always apply.
What to do
The three actions from above, which appear on screen as Allow, Require Approval, and Deny. If you choose to require approval, you also set the Approval mode, the Approvers, and, when it applies, the Required approvals:
Where it lands in the list
You do not choose it when you create the rule: new rules are added at the end, right before the default deny rule, and you reorder them afterward by dragging them in the table. Since the first matching rule wins, the order is the policy: a broad rule at the top takes the operations you meant to send to a stricter one below.
Before saving, you can add a Note (optional), which is the text you later recognize it by in the table.
No rules, no operations
This is the step everyone skips and the one behind almost every block. Before the first real withdrawal, someone with permission to manage the approval policy has to go to Settings → Transactional Policy and write the rules one by one with Add rule.
Cover at least these four cases:
You cannot list three names as the initiator of one rule: if three people need the same permission, that is three rules. Approvers, on the other hand, can be several. It is very common to build the rule for one person, assume it covers the team, and then see everything denied for the rest.
Every change to the approval policy is also signed with your passkey. If you close the signing dialog, the change is not lost: it stays pending your own signature. Go back and sign it.
Next steps
- Troubleshooting — denied operations, rules that do not apply, and what to do in each case.
- Transactional Policy — the technical detail: conditions, amount thresholds, and approval schemes.
- Quick recap of this page: How it works and No rules, no operations.