Thirty percent.
That is the number the Boston Consulting Group attached to institutional custody in a research note published on October 22, commissioned and paid for by Ripple. The claim reads: 30% of digital assets are now held through institutional custody models. The note has circulated for weeks. In that window I have collected eleven secondary summaries of it. Nine of them dropped a qualifier that the original editor was careful to include. The 30% refers only to assets held outside centralized exchanges. It also bundles enterprise self-custody and Wallet-as-a-Service deployments into the same bucket as third-party custodians. Remove the qualifier and you have a different claim. Restore it and the number is defensible, but far narrower than the headline traveling through my feed.
I ran a custody key management engagement in 2024 for a Mexican fintech firm. A 5-of-9 threshold signature scheme, the parameters specified to satisfy regulatory scrutiny while staying usable for operations staff, then verified against 100,000 generated random seed inputs to check for derivation bias. The report BCG published describes the surface of that work accurately. It does not describe where the work actually breaks. That gap is what I want to open.
What the report actually says, stripped of marketing cadence
The research is a commercial document, not an academic one. BCG is a Tier 1 consultancy whose business model depends on enterprise commissions. Ripple sells custody infrastructure. The party paying for the research is the party selling the product the research evaluates. That does not make the analysis false. It makes it directional, and direction has to be priced in.
The substantive claims are these. First, banks are increasingly licensing self-custody technology and building client-facing products on top of it, rather than outsourcing the whole stack. Second, Wallet-as-a-Service is gaining traction among payments and retail fintech firms as a lighter integration path. Third, custody is simultaneously a security decision and a product design decision, and the same key management technology can support two distinct workflows — long-duration holding and payment settlement or collateral movement — but the approval policies and operational processes around those workflows differ. Fourth, the hard part is not cryptography. It is governance, integration, and the ability to coordinate across multiple custody providers. Fifth, a bank in the $200 billion to $300 billion asset band, running a five-use-case combination, could see $80 million to $100 million in P&L upside.
That fifth claim is modeled. It is not reported revenue. It is not a forecast. The editor flagged it, and the flagging is the single most valuable editorial act in the entire document.
The regulatory backdrop cited is a July 2025 joint statement from U.S. banking regulators. The statement holds that crypto asset custody must satisfy existing safety, soundness, and legal requirements. Crucially, it states that no new regulatory expectations are being created. That phrasing is load-bearing. It means banks are not being handed a sandbox or a special exemption. They are being told the existing rulebook applies, in full, to a new asset class.
The signature operation is identical. The policy is not.
Here is the technical core, and it is the part most summaries flatten into a slogan.
When a threshold signing scheme produces a signature over a transaction, the arithmetic does not care what the transaction is for. A 5-of-9 MPC-TSS quorum signing a cold-storage rebalancing sweep and the same quorum signing a stablecoin payment settlement instruction execute the same finite-field computations. The additive nonce masking, the share combination, the final signature assembly — identical byte for byte. Anyone who claims the cryptography distinguishes a "custody" transaction from a "payment" transaction has not read the code.
What differs is the authorization envelope wrapped around the signing call. Consider a policy object, expressed in the pseudo-configuration a bank's operations team would actually author:
Policy: TRANSFER
require: {
quorum: 3,
roles: [OPERATIONS, RISK, TREASURY],
per_tx_limit_usd: 250000,
daily_aggregate_limit_usd: 2000000,
counterparty_allowlist: ACTIVE,
timelock_seconds: 3600,
conflict_resolution: LAST_WRITER_WINS
}Now change three fields and you have a treasury holding workflow with an entirely different risk profile:
Policy: COLD_HOLD
require: {
quorum: 5,
roles: [OPERATIONS, RISK, TREASURY, LEGAL, EXEC],
per_tx_limit_usd: UNLIMITED,
daily_aggregate_limit_usd: UNLIMITED,
counterparty_allowlist: DISABLED,
timelock_seconds: 172800,
conflict_resolution: FAIL_CLOSED
}Same key material. Same quorum shares. Different universe of failure.
This is what BCG means when it says custody is both a security decision and a product decision, and it is correct. But the report states the conclusion without walking the reader to the machine-level reality, and the machine-level reality is where the money is lost. The conflict_resolution field alone is worth a risk committee meeting. LAST_WRITER_WINS on a payment policy means a compromised operations credential can overwrite a pending transaction below the timelock horizon. FAIL_CLOSED on a hold policy means a deadlocked quorum freezes assets indefinitely, which is its own regulatory event.
Code doesn't lie; audits do. And almost nobody audits the policy engine, because the policy engine is a configuration file, and configuration files are treated as documentation rather than code.
The custody registry problem: control versus outsourcing is not binary
The report identifies multiple custody modes and notes that a bank may need to combine several. Stated that way it sounds like a menu. It is closer to a legal lattice.
There are at least three independent axes that the "30%" figure collapses into one:
- Who holds the key shares. The bank itself, a third-party custodian, or a WaaS vendor operating under the bank's brand.
- Who holds the authorization authority. The policy engine may be self-hosted, vendor-hosted, or federated across providers.
- Who carries the legal liability. Fiduciary duty, asset segregation, and bankruptcy remoteness attach differently to each combination.
A bank running self-custody key shares with a vendor-hosted policy engine has a cryptographic posture that is strong and an operational posture that is weak. A bank outsourcing key shares to a custodian but retaining the policy engine has the reverse. The 30% figure counts both as "institutional custody." Both are. But they are not equivalent risks, and the market is currently treating them as interchangeable.
My 2024 engagement lived in precisely this lattice. The threshold was specified as 5-of-9 to satisfy a regulatory requirement that no single party or pair of parties could unilaterally move assets, while keeping the quorum small enough that operations staff could assemble it during a business day. Five of nine is a governance number before it is a cryptographic number. It encodes the assumption that at most four of the nine share-holders will be simultaneously unavailable, compromised, or colluding. That assumption is not cryptographic. It is corporate.
Where the key management actually breaks
We generated 100,000 random seed inputs and ran them through the derivation and signing implementation. The purpose was not functional testing. It was bias detection. In a threshold scheme, the nonce generation is the sharpest edge in the entire system. A nonce with even a handful of bits of predictable structure across enough signatures leaks the private key through lattice reduction. The mathematics is unforgiving and it does not care about your compliance documentation.
The failure modes we hunted were not exotic:
- Share derivation bias. If the field elements used to derive shares are drawn from a distribution that is not uniform over the scalar field, the reconstruction threshold degrades in a way that no functional test will catch.
- Pre-signature reuse. In pre-processing MPC variants, a reused pre-signature component across two message signatures is catastrophic. It is the threshold analogue of nonce reuse in ECDSA, and it is silent.
- Session binding holes. If the protocol does not cryptographically bind a signing session to the specific policy object that authorized it, then a valid signature can be produced over a transaction the policy engine never approved. This is the custody-layer equivalent of a confused deputy.
That third one is the one that keeps me awake. The signature is valid. The quorum was legitimate. The policy engine logged an approval. And the transaction the money moved on is not the transaction that was approved. Zero knowledge, maximum proof — but only if the proof statement includes the authorization context. Most implementations do not include it, because the authorization context is a database row, and the proof system does not see databases.
The orchestration layer is the real product
Here is the inference the report invites but does not state. When a document emphasizes "governance, integration, and cross-provider coordination" three separate times, and the sponsor of the document happens to sell custody infrastructure, the emphasis is a product positioning.
The valuable asset in institutional custody is not the key management library. MPC-TSS implementations are commodity. HSM clusters are commodity. What is scarce is the unified control plane that sits above multiple custodians and presents the bank with a single authorization surface.
Think about how traditional custody actually works. A custodian bank does not hold every asset in its own vault. It maintains a network of sub-custodians across jurisdictions and asset classes, and it presents clients with one statement, one instruction interface, and one liability. Institutional digital asset custody is reinventing that structure in real time, and the reinvention has no standardized instruction protocol.
The bank that operates three custodians — one for cold holdings, one for payment settlement, one for tokenized assets — currently manages three separate policy engines, three separate audit logs, and three separate incident response procedures. The aggregator that unifies them owns the bank's switching cost. Once the bank's approval workflows, reporting systems, and internal controls are customized around a specific orchestration layer, migration cost becomes prohibitive.
This is where the ecosystem lock-in will form. Not at the cryptography layer, which is interchangeable, but at the orchestration layer, which is not.
Reverse-engineering the $80 million to $100 million
The modeled P&L upside deserves a hard look, because models are auditable artifacts and this one has stated inputs.
A bank in the $200 billion to $300 billion asset band. Five use cases. The upside is $80 million to $100 million. Work backward from the top of that range. If the blended margin on digital asset services is generous, say 40 basis points of assets served, then $100 million implies roughly $25 billion in digital asset balances under service. For a $300 billion balance sheet institution, that is 8% of total assets migrating into a new product line. That is not a pilot. That is a strategic pivot, executed inside a regulated entity with an existing capital planning cycle.
Now apply the timeline. Banks do not ship product lines in a quarter. Vendor selection, integration, internal audit, regulatory notification, and control testing for a custody offering realistically consume 18 to 36 months. The model is not wrong. Models are never wrong; they answer the question they were asked. The question was "what is the opportunity size," not "what is the probability-weighted value net of execution risk."
The report is a demand-generation asset for Ripple, and the $80 million to $100 million is a sales number wearing a consulting jacket. That is not cynicism. It is line-item accounting.
The blind spot nobody put in the document
Here is what the report does not discuss, and its absence is the most important signal in the entire analysis.
It does not discuss bankruptcy remoteness.
If a third-party custodian fails, what is the legal status of the client assets? In traditional custody, the answer is established by decades of case law, segregation rules, and resolution planning. In digital asset custody, the answer depends on whether the custodian held assets on balance sheet or off, whether the applicable jurisdiction recognizes digital assets as property capable of being held in trust for customers, and whether the custody agreement survives the custodian's insolvency proceeding.
The report discusses who authorizes payments, how limits apply, and how conflicting instructions are handled. These are operational governance questions. They are the right questions. But they are downstream of a legal question that determines whether any of the operational governance matters. A perfectly configured policy engine does not help a bank whose client assets were commingled in a custodian's estate.
This omission is not an oversight. Bankruptcy remoteness is the single most expensive thing to solve in institutional custody, because it requires legal structure and jurisdictional work rather than software, and software is what the sponsor sells.
Trust is a bug, not a feature. Every custody architecture that substitutes a policy engine for a legal structure is deferring the failure, not preventing it.
The DAO parallel nobody wants to hear
In 2017 I spent six months disassembling the Ethereum Virtual Machine's opcode execution flow, chasing the root cause of The DAO. Twelve thousand lines of assembly, line by line. What the work confirmed was that the Solidity abstraction — the thing that made the contract readable — was the mechanism that hid the reentrancy. Developers reasoned at the level of the source. The failure lived at the level of the memory model. The gap between those two levels was the exploit.
Institutional custody has the same structure. The product abstraction — "the bank offers digital asset services" — hides the policy engine, which hides the signing session, which hides the nonce generation. Every layer of abstraction is a place where the reasoning and the execution can diverge.
The DAO was a warning we ignored. We did not ignore it because it was unclear. We ignored it because the abstraction was comfortable and the machine layer was tedious.
There is a second parallel, and it runs to DeFi. On-chain money markets price risk through interest rate curves whose parameters were chosen by the protocol authors, not discovered by a market. The utilization curves that Aave and Compound run are administrative decisions dressed as economics. Banks entering custody are about to make the same category of choice — not with interest curves, but with authorization thresholds — and they will present those choices as engineering defaults rather than governance commitments.
The difference is that a mispriced curve drains a pool slowly and visibly. A misconfigured policy object drains a bank's client assets once, completely, and in a way that clears every functional test the bank ran.
Where this breaks next
The institutional custody narrative is real. The regulatory direction is real. The commercial demand is real. What is not yet real is the audit infrastructure that would make the narrative safe to build on.
My forward view, stated as a vulnerability forecast rather than a market call: the first material institutional custody incident will not be a broken cryptographic primitive. MPC-TSS and HSM implementations are mature. It will be a policy engine authorization error — a signature session not bound to its approved instruction, a limit that was evaluated against the wrong entity, a timelock that was bypassed by a policy update the bank's own change management process permitted. The post-mortem will state that the cryptography was sound and the governance failed, and everyone will nod, because that is the conclusion the report BCG published already prepared us to accept.
The question banks should be asking is narrower and harder. When your orchestration layer authenticates an instruction to sign, what exactly is it proving — and to whom, under what field arithmetic, bound to which authorization context?
If the answer is "the query returned true," you do not have custody. You have a database with expensive keys attached.