Business Crypto Wallet: Designing an Approval Flow That Works

Most companies configure approval rules once, find them irritating, and loosen them until they no longer do anything. The fix is not weaker rules, it is rules that scale with the amount at risk. It helps to read this with the terms of an institutional crypto wallet open, because the difference is in the details rather than the principle.

The principle: friction proportional to consequence

A fifty euro payment and a fifty thousand euro payment should not require the same ceremony. If they do, either the small payment is painful or the large one is unprotected.

Tiered rules solve this. Three tiers is usually enough.

A configuration that works for a small company

Tier one, up to 1,000 euros, to an allowlisted address. One approver, who must not be the initiator. No delay. This covers routine operational payments and stays out of the way.

Tier two, 1,000 to 25,000 euros. Two approvers, one of whom must be a director. No delay if the address is allowlisted and has been used before. This is the tier most vendor payments fall into.

Tier three, above 25,000 euros, or any first use of an address. Two approvers including a director, plus a mandatory delay of at least four hours. The delay exists so that a compromise discovered during the working day can still be stopped.

Any address addition. Two approvers, twenty-four hour delay before the address is usable, and a notification to every administrator. This rule is the one that actually prevents the large loss.

Why the notification matters more than the approval

An approval can be socially engineered. A notification to five people cannot be suppressed. The attacker who has compromised one account can approve from that account, but they cannot stop four other people receiving an email saying a new withdrawal address was added. Where client money is involved the requirements change entirely, which is what a regulated crypto custody provider is built to satisfy.

Configure notifications to go to people, not to a shared inbox that nobody reads.

The rules that get loosened and should not be

The delay on new addresses. Always the first casualty, because someone needs to pay a new vendor urgently. The correct response is to add the address a day ahead, not to remove the delay. Build the habit of registering vendors when the contract is signed rather than when the invoice is due.

Initiator cannot approve. Loosened when the team is small and there are only two people. If there are genuinely only two people, both should be approvers and neither should be able to self-approve. It is more annoying and it is the entire point.

Director requirement on the top tier. Loosened when a director is travelling. The fix is a second director or a documented deputy, not removing the requirement.

Testing the flow before you need it

Run a deliberate test: have someone initiate a payment to a new address at the top tier and see what actually happens. How long does the delay take, who gets notified, can it be cancelled, and by whom.

Doing this once tells you more than reading the documentation. It also reveals the common misconfiguration where notifications are enabled but going to an address nobody monitors.

The departing employee procedure

Write it down before you need it. When someone with wallet access leaves: revoke their access first, before the exit conversation if the departure is not amicable. Then review the allowlist for addresses they added. Then check the log for the previous thirty days.

This takes fifteen minutes and it is the single highest value control a small company can operate.

When a provider makes this easier

Running these rules on a self-managed multi-signature setup means the rules live in your process rather than in software, which means they are only as good as the discipline of the people involved.

A business crypto wallet with enforced approval rules puts the enforcement in the system, where it cannot be skipped because someone is in a hurry. That is the main practical argument for using one.