
9 min read
Crypto Custody 101: How to Secure Your Treasury Like an Institution
Most treasury teams hit the custody question the same way: they have added crypto or stablecoins to the balance sheet, and someone in finance asks who can move those funds, under what authority, and how that would look to an auditor. A standard wallet has no answer. Whoever holds the private key controls the assets — there is no approval policy, no authorization trail, no role separation built in. At small scale and low transaction frequency, that is manageable. At institutional scale, it is a governance gap.
EY's 2025 Institutional Investor Digital Assets Survey found that 86% of institutional investors already have digital asset exposure or plan allocations in 2025. For most of them, the infrastructure question — how to custody those assets in a way that satisfies internal audit and regulatory review — is where the operational work actually begins.
This article covers what institutional-grade crypto custody requires: the models available, the governance standard a treasury function should apply, and what to look for in the infrastructure that supports it.
What custody means for a treasury function
In traditional finance, custody means a regulated entity holds your assets and provides the safekeeping, reporting, and segregation a regulator can verify. The structure is familiar. The crypto equivalent has the same functional requirements but a different technical foundation.
Ownership of digital assets is determined by control of the private key, a cryptographic credential that authorizes all transactions from a given address. Whoever controls the key controls the assets, directly and irrevocably. There is no bank to call if a key is lost or compromised, no reversal mechanism, no central authority to dispute a transaction with.
For a treasury team, this creates a custody question that is fundamentally about governance: who holds key access, who can authorize a transfer, and how can you demonstrate to internal stakeholders and external regulators that every movement of funds followed a defined policy? The custody model you choose determines your answers to all three.
The three models and their operational trade-offs
Self-custody gives a treasury team direct control over its private keys, managed through hardware wallets or secure software infrastructure. Full control means the governance layer is entirely on you, where you define who has key access, how transfers are authorized, and what the audit trail looks like. At low volume and small team size, this is workable. As the operation scales, the governance requirements grow faster than the infrastructure can support. Multi-party authorization, role-based access, and tamper-proof audit logs are difficult to implement and maintain without significant engineering work sitting alongside the treasury function.
Third-party custodians are regulated institutions that hold digital assets on your behalf. You’d be solving the governance problem by offloading it. The custodian manages key security, provides regulatory compliance documentation, and often carries insurance against certain categories of loss. The trade-off is direct key control: your assets move on the custodian's authorization infrastructure and their timelines.
For balance sheet positions that do not need frequent movement, this is often a clean fit. For treasury operations requiring high-frequency transactions, automated disbursements, or real-time settlement, the bottlenecks compound with volume.
MPC and WaaS infrastructure distributes the private key across multiple parties using cryptographic techniques, so no single entity or device holds a complete key. This eliminates the single point of compromise that makes self-custody risky at scale, while preserving the operational speed that a third-party custodian cannot provide. You retain key ownership; the infrastructure provides the authorization and governance layer on top of it.
For treasury operations that need both governance and throughput — exchanges, payment providers, corporates running daily disbursements — this is the architecture that institutional practice has converged on.
What institutional custody actually requires
The custody model sets the foundation. The governance requirements define what that foundation needs to support.
Multi-party authorization is the baseline. No single person should have unilateral authority to move funds. Treasury operations running on a single key, a single approver, or a single device have a structural control weakness that internal audit will flag and that attackers actively target. The authorization structure — who can initiate, who must approve, and at what thresholds — should reflect the same risk policy that governs the rest of the treasury function.
Role-based access follows from that. Finance managers reviewing transactions need different permissions than operations staff processing routine payments. The custody infrastructure should enforce those distinctions by design, not rely on team discipline to maintain them.
Cold and hot wallet separation is standard institutional practice. Operating funds for daily transactions live in hot wallets, replenished automatically based on defined rules. Bulk reserves route to cold storage — ideally without a manual step between collection and secure storage, since manual steps introduce both delay and human error. The threshold at which funds move between wallets should be set by policy, not decided in the moment.
An audit-ready authorization trail is what separates institutional custody from operational improvisation. The standard a finance team requires is not just a log — it is a record that demonstrates, with cryptographic certainty, that a specific transfer was authorized by specific people at a specific time, and that the record cannot be altered after the fact.
The stakes are concrete. Chainalysis's 2025 Crypto Crime Report found $3.4 billion stolen across hacking incidents in 2025 alone, with compromised approval processes and private key exposure among the leading attack vectors. An institutional treasury function should be asking not whether these risks exist, but whether its controls can survive scrutiny of how a transfer was authorized.
How CoinsDo's infrastructure supports institutional custody
CoinsDo's approach starts with a structural decision that has downstream implications for everything else: you retain your private keys. CoinsDo never holds them. The assets remain under your direct control, and the wallet addresses remain usable even if the partnership ends. For treasury teams that have watched what happens when a centralized custodian freezes withdrawals or fails, key ownership is not a secondary consideration.
The operational layer runs on top of that key architecture.
- CoinGet automates cold storage routing, Funds collected from deposit addresses move to cold storage based on configurable thresholds, without a manual step between collection and secure storage.
- CoinSend handles the withdrawal side with configurable approval flows: routine transactions below a defined threshold execute automatically, while high-value transfers route through designated reviewers before execution.
- CoinSign applies cryptographic signatures to every manual approval, producing an authorization record that is tamper-proof and attributable to a specific person, device, and timestamp.
That maps directly to the requirements above: multi-party authorization, role-based access controls, automated cold storage routing, and an audit trail that holds up under scrutiny.
For a full breakdown of how each component works and how they integrate, see How CoinsDo Simplifies Crypto Treasury Management with CoinGet, CoinSend, and CoinSign.
The custody model a treasury function chooses shapes its governance structure, its audit readiness, and its exposure if something goes wrong. For teams moving beyond early-stage holdings into high-volume digital asset operations, the question is not whether institutional-grade custody is necessary — it is which architecture supports the controls your finance function actually requires.
For more on building a crypto treasury function with institutional-grade controls, see the Crypto Treasury Management guide.

