A treasury policy for small teams: who can move the money

When a company first holds crypto, it's usually in one person's wallet. The founder set it up, the founder holds the recovery phrase, and the founder sends payments. It works — until that person is travelling, ill, leaves, gets phished or simply makes a mistake with nobody to catch it.

A treasury policy is the fix. It doesn't need to be long or formal. It needs to answer a few questions clearly enough that everyone knows the rules before money moves, not after.

Question 1: who can spend?

Start by separating three roles that often get blurred:

• Proposers — people who can prepare a payment.
• Approvers — people whose signature is required to send it.
• Viewers — people who need to see balances and history but should never touch funds, such as an accountant.

The core control is that no single person can move funds alone. In crypto that's enforced with multisig: a treasury address that needs M approvals out of N signers. For a team of three to five, 2-of-3 or 3-of-5 are common starting points. Higher thresholds add safety and friction in equal measure.

Question 2: what about keys leaving with people?

Every signer is a person who might leave, lose a device or stop responding. Plan for it:

• Threshold below the total. With 2-of-3, losing one signer doesn't freeze funds.
• No two signers sharing a single point of failure — not the same office safe, not the same laptop, ideally not the same household.
• An offboarding step. When someone leaves, remove them as a signer and, if needed, move funds to a vault without their key. Don't wait until something goes wrong.
• A documented recovery path that doesn't depend on one person remembering how things work.

Question 3: which actions need extra care?

Some decisions are more dangerous than a normal payment: changing who the signers are, transferring ownership, removing people, deleting the organisation. These should require more than a click from one logged-in account. Write down which actions are "critical" and what confirmation they need.

Question 4: how are payments checked?

The approval step is only valuable if approvers actually check something. A short checklist works:

• Does it match a request — an invoice, a payroll run, an agreed transfer?
• Is the address verified — saved and confirmed earlier, not pasted from an email?
• Is the amount right, including the asset and the network?
• For contract interactions, does the simulation match the intent?

The most common treasury loss isn't a hacked key; it's a convincing invoice with a changed address. A rule that new payee addresses must be confirmed through a second channel — a call, an existing contact — stops a lot of it.

Question 5: what's the record?

Every payment should leave a trail: who proposed it, who approved it, when, and why. That's what makes a policy auditable, and what lets the team reconstruct events if something goes wrong.

A starting template

For a small team, something like this is enough to begin:

1. Treasury held in a multisig vault with a 2-of-3 (or 3-of-5) threshold.
2. Signers are named people; no shared accounts, no shared devices.
3. Anyone on the finance team can propose; only signers approve.
4. New payee addresses are verified out-of-band before first use.
5. Signer changes and ownership transfers are critical actions with re-confirmation.
6. Each payment's proposal, approvals and purpose are kept on record.
7. Offboarding includes signer removal on the person's last day.
8. The policy is reviewed every six months, or after any incident.

How SSP Enterprise maps to this

SSP Enterprise was built around these questions:

• Roles. Organisations have owners, admins, members and viewers, so proposing, approving and viewing are separate. Roles and permissions covers what each can do.
• M-of-N vaults. Each vault has its own threshold and signer set, and an organisation can run several vaults — say, an operating account and a reserve with a higher threshold. In the default mode, each signer approves with both SSP Wallet and SSP Key, so even one signer's approval is itself a 2-of-2. Because a vault's address is built from its signers' keys, changing who can sign means moving funds to a new vault — worth planning into offboarding.
• Critical actions. Transferring ownership, removing members, deleting the organisation and changing the enterprise email require re-signing with the identity keys, not just a logged-in session.
• Checks before signing. Proposals show recipients and amounts, and contract interactions get simulation and risk warnings before signers approve.
• A record of every payment. Proposals keep who proposed, who has signed and who is still pending, and exports are available for accounting.

If you're starting from scratch, setting up your first enterprise vault walks through it step by step.

The honest summary

A treasury policy answers five questions: who can spend, what happens when people leave, which actions are critical, how payments are checked and what record is kept. Write the answers down before you need them.

Multisig enforces the most important rule — no single person can move funds alone. The rest is habit: verified addresses, real checks before approving, and offboarding that happens on time.