Private keys answer one question: does the holder have the cryptographic authority to move these funds? They say nothing about whether the transaction should happen. A valid signature looks identical whether it pays an approved supplier or drains the treasury to an attacker's address. A policy engine exists to close that gap. It is the layer where an institution's written rules about who may move what, where, and under whose approval become machine-enforced behavior, applied before a signature is ever produced.
What a Policy Engine Does
In custody, a policy engine sits between the people who request actions and the keys that execute them. Every request, a withdrawal, a new user, a change to the allowlist, is evaluated against an ordered set of rules, and each rule resolves to one of three outcomes:
- Allow. The request matches a rule that permits it outright, for example a small payment to an address already on the allowlist. It proceeds without human intervention.
- Deny. The request matches a prohibition, for example any transfer to a destination outside the allowlist, and is rejected automatically.
- Review. The request is legitimate in form but significant enough to need human judgment, so it pauses and routes to designated approvers.
The result is that routine operations stay fast while exceptional ones get exactly the scrutiny the institution decided they deserve, decided in advance, in policy, rather than improvised at the moment of the request.
The Core Controls
Spending Limits and Velocity Rules
Limits cap how much can move in a single transaction, and velocity rules cap how much can move over a time window, such as a daily or monthly total per account. Velocity rules matter because they bound the damage of a compromise: an attacker who gains the ability to push transactions through still cannot exceed the window's ceiling without triggering review.
Allowlists and Destination Controls
An allowlist restricts withdrawals to pre-approved destinations, with additions to the list themselves subject to approval. This converts the highest-impact attack, redirecting funds to an attacker's address, into a two-stage problem: the attacker must first get an address through the list-change approval process, then get a payment approved to it. Blocklists work in the opposite direction, refusing specific destinations regardless of other rules.
Multi-Step Approvals
Approval requirements can demand sign-off from multiple people, and from multiple groups, before a request proceeds. A rule might require one member of the security team and one member of the compliance team, so no single department can approve its own request. Combined with separation of duties between the person who drafts a transaction and the people who approve it, this is the digital form of dual control that institutions already apply to wire transfers.
Role-Based Access Control
Role-based access control (RBAC) determines who can do what at all: who can create transactions, who can approve them, who can change policies, who can only view. Sound implementations follow least privilege, granting each user the minimum access their job requires, and enforce separation of duties so that the authority to propose, the authority to approve, and the authority to sign sit with different people.
Audit Trails
Every action, request, approval, rejection, configuration change, gets recorded with the user, role, and time attached. For compliance teams the audit trail is the deliverable: it is what demonstrates to auditors and regulators that the controls operated as designed, and it is what reconstructs events after an incident.
How Policies Are Evaluated
Policy engines typically evaluate rules in priority order: each incoming request is tested against the highest-priority rule first, and the first rule that matches determines the outcome. Later rules are never consulted. This makes the rule set predictable and auditable, since exactly one rule decides each request, but it also means ordering is part of the policy. A broad allow rule placed above a narrow deny rule silently disables the deny. Institutions usually anchor the set with a catch-all rule at the lowest priority, so that anything no specific rule anticipated still gets a deliberate default, commonly requiring review.
Mature systems apply the same machinery beyond payments. Creating users, changing roles, modifying allowlists, and reconfiguring accounts are all state changes that can trigger approval requirements, which closes an otherwise easy loophole: an attacker who cannot get a withdrawal approved should not be able to quietly grant themselves the role that approves withdrawals.
Why Bitcoin Lets the Policy Layer Live Off-Chain
Where authorization logic runs is an architectural choice, and the underlying blockchain shapes it. On account-based chains, institutional custody at scale typically coordinates signing authority through on-chain smart contracts: the rules about who can move funds are deployed as executable code on the blockchain itself, where they are publicly visible and where their execution is part of consensus.
Bitcoin takes a different shape. Funds are held in UTXOs, each locked by a script that enforces the cryptographic spending conditions, most commonly a multisig threshold. The script is deliberately minimal. Everything above the threshold, the limits, the allowlists, the approval routing, the role model, can live off-chain in the custodian's policy layer, with the UTXO set enforcing only the final signature requirements. Bitcoin Script does support on-chain conditions where they earn their place, such as timelocks for recovery paths, Miniscript for composing structured spending conditions, and proposed vault constructions for covenant-style withdrawal delays. The institution chooses how much logic to anchor on-chain and how much to keep in the policy layer.
What Off-Chain Policy Removes From the Attack Surface
Keeping authorization logic out of on-chain code removes a specific class of risk: smart contract execution exploits against the custody logic itself. When the rules are not a deployed program on a public blockchain, an attacker has no contract bytecode to study and exploit, and the institution's approval routing, limits, and role model are never published on-chain for anyone to read; the on-chain script reveals at most the final signature threshold once an output is spent, and a Taproot key-path spend hides even that. There is also no on-chain upgrade mechanism whose compromise rewrites the rules for everyone at once. Policy changes also stay operational rather than monetary: tightening a limit or restructuring approvals is a configuration change inside the custody platform, with funds staying exactly where they are on-chain.
What Every Custody System Must Still Defend
Off-chain policy eliminates one attack class, and every custody system, on any architecture, still has to defend the rest:
- Key material. Keys must be generated and stored without exposure, and they must stay unexposed at signing time. The largest Bitcoin custody losses in the industry's history came from key management and operational failure, and no policy layer compensates for a stolen quorum of keys.
- Operational compromise. The policy engine is software running on infrastructure. Compromised administrator workstations, malicious software updates, and interfaces that display one transaction while signing another are all attacks on the operation rather than the chain, which is why signing devices that independently verify transaction details matter.
- Insider risk. Policies are configured by people and approvals are granted by people. Enough colluding insiders holding the right roles can satisfy any review requirement, so the collusion threshold, how many independent people an attack requires, is itself a design parameter, set by quorum size and role distribution as discussed in Multisig Governance for Businesses.
An honest evaluation weighs both sides: what the architecture removes, and what remains for the custodian's controls, processes, and people to carry.
Policy Engines in Blockstream Enterprise
Blockstream Enterprise implements this layer at two scopes. Spend Policies govern transactions: each policy resolves to automatically allow, automatically deny, or require review, policies are evaluated in priority order with the first match deciding, limits can apply per transaction or over a time period, and review requirements support multi-party group approval such as one member of the security team plus one of the compliance team. Workspace Policies govern the organization itself: user creation, role changes, account configuration, asset restrictions, and changes to Recipients & Lists can each require an approved proposal, surfaced in Workspace Updates, before taking effect.
Transactions then move through named roles with enforced separation of duties: a Drafter creates the transaction, an Approver reviews it, an Authorizer signs it, with hardware signing devices supported at the authorization step, and a Viewer holds read-only access. Access across the workspace and its accounts is governed by seven predefined roles, and every action is traceable to a user and role in the audit trail. The result, for a compliance officer, is that the treasury policy document is enforced directly as the system's behavior.
Questions to Ask About Any Policy Engine
Evaluating a custody platform's policy layer comes down to a short list of falsifiable questions:
- Does the engine evaluate every action type, including user, role, and allowlist changes, or only payments?
- Does it support multi-group approval, so one department cannot approve its own requests?
- Does it enforce separation between drafting, approving, and signing?
- Does it apply velocity limits over time windows, in addition to per-transaction caps?
- Does it produce an exportable audit trail attributing every action to a user and role?
- Does a policy change itself require approval, so controls cannot be quietly weakened?
How that layer combines with custodial structure and on-chain verification is covered in How Do Businesses and Institutions Take Custody of Bitcoin?, What Is a Qualified Custodian?, and What Is Proof of Reserves?
Frequently Asked Questions
What does a policy engine do in Bitcoin custody?
A policy engine evaluates every requested action in a custody system against rules the institution defines: spending limits, destination allowlists, time-based velocity limits, and approval requirements. Each request is automatically allowed, automatically denied, or routed for human review before any key signs, turning written treasury policy into enforced behavior.
Is a policy engine the same as a smart contract?
A policy engine and a smart contract solve a similar governance problem in different places. A smart contract encodes authorization logic on-chain, where it is publicly visible and executes on the blockchain. A custody policy engine runs the logic off-chain, inside the custodian's infrastructure, with the blockchain enforcing only the final signature requirements. Bitcoin's design makes the off-chain approach natural.
Can a policy engine stop insider theft?
A policy engine raises the bar substantially: separation of duties means no single insider can draft, approve, and sign a withdrawal, and audit trails attribute every action. It cannot eliminate insider risk entirely, since enough colluding insiders with the right roles could satisfy review requirements. Quorum design and role distribution set that collusion threshold.
What happens when a transaction requires review?
The request pauses before signing and a review item is created for the designated approvers, which may require sign-off from multiple groups, for example one member of the security team and one of the compliance team. Only after the required approvals are collected does the transaction proceed to its authorizers for signing.
Where do policy rules run if they are not on the blockchain?
They run inside the custody platform's own infrastructure, between the user interface and the signing keys. The Bitcoin network never sees the rules; it sees only the final transaction and verifies its signatures. This keeps an institution's control structure private and changeable without touching on-chain code or moving funds.