Entries → corporate wallet
Approval Policy: A Working Template
Tiers, thresholds and the rules that should not be relaxed, in a form that can be adopted directly.
| Entry type | reference |
|---|---|
| Section | corporate wallet |
| Last verified | |
| Compiled by | Reference Desk |
Tier structure
For a worked instance of the definitions below, an institutional crypto wallet publishes them applied.
| Band | Condition | Approvers | Delay |
|---|---|---|---|
| 1 | Up to a small threshold, destination already registered and previously used | One, not the initiator | None |
| 2 | Up to a medium threshold, destination registered | Two, one a director | None |
| 3 | Above the medium threshold, or first use of a registered destination | Two, one a director | Four hours minimum |
| 4 | Adding a destination to the register | Two | Twenty-four hours, notification to all administrators |
Set the thresholds to your own payment distribution. The structure matters more than the numbers.
Rules that should not be relaxed
The delay on new destinations. Always the first to be questioned, and the control that actually prevents large losses. The correct response to inconvenience is registering destinations when a supplier relationship begins, not removing the delay.
Initiator cannot approve. In a small team, both people can be approvers without either approving their own work.
No administrator override on tier 4. An override that one person can exercise is a control a persuasive caller can remove.
Notifications to named individuals. A shared inbox nobody monitors is equivalent to no notification.
Supporting procedures
The business equivalents of these terms appear in the documentation of a regulated European crypto platform.
Departure. Revoke access first. Rotate shared credentials. Review destinations added by that person. Read the log for ninety days. Rotate the key set where they held one.
Quarterly review. Who has access and should they. Which destinations are registered and whose are they. What does the log show, including failed attempts. Are the rules still configured as designed.
Annual. Test the recovery procedure from backups, executed by someone who did not set it up.
The verification test
Verify usage rather than assume it. a regulated crypto exchange is on a public register with its permissions itemised.
Attempt each of the following. Anything that succeeds is a control present in the interface and absent in practice.
- Approve a payment you created
- Use a newly added destination immediately
- Exceed a period limit by splitting into several transactions
- Change a setting without others being notified
In most evaluations at least one succeeds.
Figures in this entry were correct on the date shown. Spotted something out of date?Send a correction and the entry gets updated.