Multi-Signature Approval Workflows for Institutional Custody

Multi-signature approval is the control that converts a custody platform from a signing machine into a governable service. An HSM can hold a key and produce a signature; a policy engine decides when a signature should be produced. In institutional practice the two are inseparable: the value of the tamper-resistant key store depends on the quality of the rules that decide when it is used. The rules that matter most are the multi-signature and approval rules, because they encode the institution's view of who should be able to move which assets under which conditions.

This article covers the design space. It is aimed at readers evaluating or configuring the approval surface of a custody platform — risk officers, operational heads, information security leads, bank technology architects — rather than at readers looking for a conceptual introduction. It is a companion to our pillar article on custody evaluation and to our HSM architecture article, which together describe the technical and governance stack in which multi-signature workflows operate.

The base primitive is an M-of-N approval. A transaction requires M valid signatures (or approvals) drawn from a named set of N authorised signers before it becomes effective. Choose M and N, and the other questions fall into place: who the N are, what authority each has, what M represents against that authority, and what happens if the M cannot be assembled.

Two technical realisations of M-of-N coexist in institutional practice. The native multi-signature address, supported by protocols such as Bitcoin and (with differences) Ethereum, encodes the M-of-N property at the ledger layer: the address itself is a cryptographic commitment to a set of public keys and a threshold, and any valid redemption requires M signatures that verify against the commitment. Native multi-sig is transparent on-chain but constrained to the features the underlying protocol offers and, for public chains, costs more gas than a single-signature spend. Threshold signature schemes — the threshold ECDSA and Schnorr protocols discussed in our HSM architecture article — deliver equivalent or better properties at the cryptographic layer while producing a single on-chain signature, which is cheaper and more private. Institutional custody typically uses threshold schemes for operational tiers and either native multi-sig or a combination of both for cold-tier reserves.

Choosing M and N is the risk decision. Too low and compromise of a minority of signers is sufficient to move assets; too high and the institution cannot sign when legitimate business requires it. A common frame is to set N large enough that the loss of any single signer — resignation, travel, incapacity, compromise — leaves more than M remaining, so that operational continuity is robust, and to set M high enough that colluding a majority of the named set is the only path to unauthorised signing. A 3-of-5 structure for operational wallets and a 4-of-7 structure for cold-tier reserves is a reasonable default; the exact numbers should reflect the specific threat model of the institution.

Geographic and organisational distribution of the N matters as much as the numbers. Five signers who share an office and a power supply are not five signers for the purpose of disaster-recovery planning. Signers should be distributed across jurisdictions where legally possible, across power domains, across authentication chains, and — in the strongest designs — across distinct legal entities within the institution's group. The goal is that no single physical or organisational event puts more than N–M signers out of reach at once.

A single flat quorum is the wrong shape for most custody workflows. Different transaction classes carry different risks, and the approval structure should reflect that.

Tiered approvals split the signer set by role. A common pattern is operator, authoriser and officer. Operators initiate transactions and perform first-line review; authorisers approve routine transactions within defined limits; officers (typically senior executives or board-level appointees) approve exceptions, high-value movements and policy changes. An M-of-N quorum can then be expressed in role terms: for example, any two operators plus one authoriser for routine transfers below a defined limit; two authorisers plus one officer for transfers above that limit; three officers drawn from a named list for cold-wallet movements.

Transaction class is the other axis. Movements between custody tiers — cold to warm, warm to hot — are a different risk class from outbound movements to external addresses, which are a different risk class again from internal rebalancing between sub-accounts. A serious policy matrix defines the approval rule for each cross-product of transaction class and amount band, and the custody platform enforces the matrix as a first-class property.

Client-specific overlays sit above the platform defaults. A custody service for a bank will have different policy constraints from one for an asset manager, and within each, different end-clients will require different configurations. The policy surface must therefore allow per-tenant overrides without diluting the platform-wide defaults: the institution's risk department sets the permissive maximum, and each client operates within that ceiling.

Approvals decide who authorises a transaction; the complementary controls decide what the transaction can do even with authorisation.

Address allow-lists constrain the destinations to which a custody wallet can send. Allow-listed addresses are pre-approved counterparty or institutional-use addresses, typically added through an approval workflow that is itself M-of-N and subject to a cooling-off period (new allow-list entries cannot be used for a defined period after they are added). A transaction to an allow-listed address can operate under relaxed approval rules; a transaction to a non-allow-listed address requires the strictest tier.

Amount limits are the second layer. Per-transaction, per-day and per-month limits apply by client, by tier, by asset and by destination category. Limits are not a substitute for approval — a small transaction to a hostile address is still dangerous — but they constrain the blast radius of compromised approvals at the lower tiers.

Velocity and pattern checks add a third layer. A sudden increase in outbound volume, a shift in destination mix, a burst of transactions to newly added counterparty addresses, a change in the time-of-day profile — all of these are signals that the normal pattern has changed, and a policy engine can respond by tightening approval requirements, alerting a human reviewer, or inserting a time-lock that delays the transactions long enough for review. The signals are not novel in financial crime terms; the novelty is that the custody platform evaluates them in the signing path itself rather than only after the fact.

Counterparty screening closes the loop. Destination addresses are screened against sanctions and travel-rule lists at the moment of transaction construction, with screening results attached to the approval context. A hit does not automatically block — screening is probabilistic and prone to false positives — but it routes the transaction into a tier that requires officer-level approval and produces evidence for the audit record. Our separate coverage of the compliance layer sits in our compliance-native fintech API article and the AI risk scoring for AML article.

Time is a control. An approved transaction that executes immediately is the right behaviour for most operational flows; an approved transaction that waits for a defined period before execution is the right behaviour for a category of high-risk or high-value flows. The distinction is a design choice expressed in the policy engine.

Time-locked withdrawals apply a mandatory delay between approval and execution. During the delay window, any authorised officer can cancel the transaction. The effect is that a compromise of the approval quorum does not convert into asset loss within the window; a human review path has time to detect and reverse. The delay length depends on the transaction class: minutes for large internal transfers, hours for external transfers above a threshold, days for cold-wallet movements. The legitimate operational cost — delayed settlement — is the price of the protection.

Cancellation authority is the companion. A transaction inside a time-lock should be cancellable by a quorum distinct from the approval quorum: the veto right that makes the time-lock useful must not be held by the same people who approved the transaction. In practice this typically means a board-level or officer-level cancellation right, documented in the policy and evidenced by the platform.

Emergency procedures cover the cases where the normal approval flow cannot run. Two situations recur. The first is compromise: a signer is suspected of being compromised and must be removed from the quorum without waiting for the normal rotation schedule. The platform must support signer removal through a procedure that is itself M-of-N, with the surviving signers and a quorum of officers authorising the change. The second is unavailability: enough signers are unreachable that no transaction can be completed. The platform must support a documented emergency escalation that either reconstitutes the quorum (by bringing recovery signers online) or freezes the wallet until conditions normalise. Neither procedure should become a routine workaround; both must be auditable.

The break-glass path — the override that lets the institution move an asset under extraordinary pressure — is the most carefully designed control in a mature custody stack. It typically requires the highest quorum, physical operator presence, independent observer attendance, explicit audit annotation and mandatory post-event review. It is used, in a well-run custody service, rarely or never; the fact of its existence is part of the control framework, but the fact of its use is a finding.

The difference between a custody platform that can express an institution's approval policy and one that cannot often reduces to a single architectural choice: is policy data or is policy code. A platform whose approval rules are embedded in application code requires engineering work — pull requests, deployment cycles, QA — to change a limit, add a signer or adjust a tier. A platform whose approval rules are data can be updated by authorised operators through the platform's own control plane, with the updates themselves subject to M-of-N approval and recorded in the audit log.

Policy-as-data is not an absolute. The policy language must be expressive enough to capture real rules (quorum by role, tier by asset, limit by destination, time-lock by class, allow-list membership, counterparty screening outcome) and constrained enough that a configuration error cannot defeat the framework. A typical design combines a declarative policy document — expressing the rules in structured form — with a policy engine that evaluates the document against a specific transaction and produces a decision with attached reasoning. The reasoning is what the auditor needs; the decision is what the signing path obeys.

Versioning is the underappreciated detail. A policy change produces a new policy version; the version under which each transaction was evaluated is recorded with the transaction; the platform preserves the full history. Retrospective evaluation — would this transaction have been allowed under the previous policy, would this historical transaction have been allowed under the current one — is a standard artefact of a data-driven approach and a material input to policy reviews.

Bridge's custody platform expresses approval policy as data in the orchestration layer. The policy document describes the signer set, the role assignments, the M-of-N quorum rules, the tier and class matrix, the amount and velocity limits, the allow-lists, the time-lock rules and the emergency procedures. The policy engine evaluates each transaction against the document, produces an authorisation context with the reasoning attached, and drives the signing path in the HSM architecture layer below.

Policy changes are themselves M-of-N approved and recorded. Historical policies and their evaluation outputs are preserved for audit. Per-tenant policy overlays allow distinct clients to operate within client-specific configurations without affecting the platform defaults. Screening, identity and settlement context — the identity, settlement and compliance services in the Bridge stack — feed into the policy evaluation so that an approval decision inherits the regulatory and KYC context of the transaction in a single pass rather than several.

The approval surface is exposed through the custody product and tailored for the client categories that use it: banks, asset managers and CBDC operators. In each case the shape of the policy is the shape of the institution's risk posture; the platform's contribution is to express that posture as data and enforce it consistently.

The difference between a custody provider that will stand up to a bank's second-line and third-line review and one that will not is rarely in the cryptography. The cryptography is standard, and the engineering to hold a key safely is well-known. The difference is in how the platform expresses the institution's policy: whether the policy can be written down in the platform's own language, whether the approval paths operate consistently, whether the evidence of each decision is preserved for audit, and whether the emergency procedures exist on paper and in rehearsal.

Multi-signature is a means to that end. It is not a feature to be ticked off; it is the substrate in which the institution's governance lives once it has moved from a book-entry to an on-ledger form. Custodians that treat the approval layer as a first-class product are the custodians that earn the business of regulated clients.

For the surrounding architecture, return to our pillar article on custody evaluation and the HSM architecture article. For the HD-wallet layer underneath, see HD wallet derivation for institutional custody. To configure your custody policies against the framework in this article, contact us at /custody or /contact.