Crypto custody transaction policies are the rules a platform checks before any customer asset moves: who may ask, who must approve, where funds may go, how much and how fast, and what happens when something looks wrong. Banks have run equivalent controls over wires and securities for decades. What changes with digital assets is that a transfer is final the moment it is broadcast, so the policy has to be right before signing, not corrected afterward.
This guide describes the five controls every bank custody program needs, how to set each one, and the failure that gets less attention than theft: a policy configured so tightly that it blocks the bank's own operations and invites staff to work around it.
Where transaction policies sit in the control framework
The federal banking agencies' 2025 statement on crypto-asset safekeeping defines control as the ability to demonstrate that no other party, including the customer, has access to information sufficient to unilaterally transfer the asset out of the bank's control. It also says a bank's audit program should address controls related to the transfer and settlement of customer assets. Transaction policies are those controls.
The older guidance still applies. The OCC's Comptroller's Handbook booklet on custody services states that dual control procedures should ensure that one person, acting alone, does not have the ability to complete all phases of a transaction or move custody assets, and that custody systems should produce activity and exception reports that let management identify and monitor risk. A policy engine is the modern form of both requirements.
The five controls and how to set them
| Control | What it prevents | How to set it |
|---|---|---|
| Destination allowlist | Transfers to unknown, mistaken or sanctioned addresses | Formal onboarding of each address with an independent approver, documented ownership, periodic recertification and removal of stale entries |
| Amount and velocity limits | Large losses from one compromised credential or one wrong instruction | Limits per customer, asset and wallet, calibrated to the customer's profile, with a documented exception process and alerts when limits are approached |
| Dual approval | One person or one system moving funds alone | Distinct credentials for initiator and approver, approval bound to the exact transaction, not to a summary, and a signature from the bank's own key |
| Time-boxed hold | Settlement before a review is complete | A defined trigger, a named reviewer, a fixed duration, and automatic expiry unless a person extends it |
| Emergency stop | Continued movement during a suspected key compromise, software defect or attack | An activation path independent of normal operations, defined authority, a tested procedure and a controlled, reconciled restart |
Two details decide whether these controls hold up under examination. First, the approval must bind to the transaction bytes that will be signed. Approving a dashboard summary while the platform signs something else is not dual control. Second, the rules must be enforced where signing happens. A limit checked only in the user interface can be bypassed by anyone who reaches the signing service another way.
Misconfiguration cuts both ways
Most attention goes to policies that are too loose. The other failure is as common and harder to see. A limit set below a customer's normal activity, an allowlist that was never updated after a treasury account changed, or a hold with no owner turn into rejected withdrawals, missed settlements and complaints. Operations teams then ask for exceptions, and a platform that grants them informally has quietly lost its control framework.
Four practices keep policies strict and workable at the same time.
- Change management for rules. Policy changes go through the same path as code: a request, a test against recent transaction history, an independent approval and a record of who changed what and when.
- Fail open for holds, fail closed for stops. A review hold that nobody confirms should expire on its own, so that automation can never lock a customer out indefinitely. An emergency stop should stay in force until a named officer lifts it. Mixing the two produces either silent paralysis or silent leakage.
- Exceptions with a named approver and an end date. A temporary limit increase for a known transaction is a control. An open-ended override is a hole.
- Rejected transactions as a metric. Count how many instructions the policy blocked, why, and how many were later approved. A high rate of later approvals means the policy is miscalibrated. A rate of zero over months is also worth a question.
Who holds the controls
Policies protect customer assets only if the bank operates them. Our rule is that automation may propose and the bank disposes. Risk models and rules engines can annotate a transaction, verify it against the customer's history and place a time-boxed hold. Only a person at the bank, with the bank's own authority, can block, claw back or lift a stop. Every automated proposal and every human decision is written to an append-only log, including the version of the model that made the proposal.
In LedgerBridge Bitcoin Custody this takes four concrete forms. The emergency stop halts fund movement at five points of the flow, from deposit crediting to broadcast. A wallet freeze blocks both withdrawal and signing. Compliance holds route to an officer who approves or rejects in the Compliance Portal. And no withdrawal completes without a signature from the key the bank holds in its own hardware security module, which checks the exact transaction before it signs. The principle behind the design is explained in bank-controlled custody: what boards should require.
A policy checklist for the risk committee
- Every rule is enforced at the signing service, not only in the user interface.
- Approvals bind to the transaction that will be signed.
- Allowlists have an owner, an approver and a recertification date.
- Limits are documented per customer and asset, with an exception process that expires.
- Holds have a trigger, a reviewer, a duration and automatic expiry.
- The emergency stop has a tested procedure and a controlled restart.
- Rule changes are logged with author, approver and time.
- Rejected instructions are counted and reviewed monthly.
- Keys live in FIPS 140-3 Level 3 validated hardware, and the system refuses to sign when that hardware is unavailable.
- The log can reconstruct any transfer from instruction to settlement, including every policy decision.
Use the list when you evaluate a provider alongside our 25 vendor due diligence questions, and keep using it after onboarding: policy drift is one of the signals covered in crypto custodian ongoing monitoring. The security and compliance overview shows how each item is implemented on our platform. To see the policy engine from the operator's chair, request a demo.
Frequently asked questions
What is a transaction policy in crypto custody?
It is the set of rules a custody platform evaluates before a transfer is signed: who may initiate and approve, which destinations are allowed, what amounts and frequencies are permitted, when a transfer is held for review, and when all movement stops. The rules implement the bank's risk appetite and are the controls an audit of transfer and settlement will examine.
Should a review hold expire automatically?
Yes. A hold exists to give a person time to look. If nobody confirms it within a fixed period, it should expire, otherwise automation can lock a customer out indefinitely with no accountable decision. The opposite applies to an emergency stop, which should remain in force until a named officer at the bank lifts it after reconciliation.
Who should be allowed to change an allowlist or a limit?
Nobody acting alone. A change should require a request, a test against recent activity, approval by someone other than the requester, and a log entry recording author, approver and time. The same discipline applies to removing a rule as to adding one, and recertification should remove entries that are no longer in use.
What should happen if the hardware security module is unavailable?
The platform should refuse to sign. Falling back to software signing would move keys outside the control environment the bank has approved and would undo the protection the hardware provides. An outage is an operational event to manage with the provider, not a reason to lower the signing standard for the duration.
How do examiners test transaction policies?
They ask whether the rules are enforceable rather than merely documented, whether anyone can move assets outside them, how changes to rules are controlled, and whether the logs can reconstruct an instruction from intake through approval, signing, broadcast and settlement. Rejected and overridden transactions, and the reasons for them, are a natural place to start.
This article is general information, not legal advice. Control requirements depend on your charter, your regulator and the products you offer. Consult your counsel and your supervisory team.