Your finance team has a wallet, a spreadsheet, and a standing rule that two people must approve every payment. It feels controlled until someone notices an outbound transaction nobody recognizes. The requester used a stale beneficiary record, one approver was unavailable, and the second approval happened through a workflow that never verified the exact transaction being signed.
That incident doesn't begin with a bad person or a broken blockchain. It begins with an operating model designed for bank transfers, then placed on rails where settlement is fast, public, and difficult to reverse. Crypto treasury management is an infrastructure and control discipline, not a custody add-on.
Table of Contents
- The Problem With Legacy Thinking About Crypto Treasuries
- Why This Is a Different Operational Problem Now
- The Infrastructure Stack Behind Professional Treasury Operations
- Designing Controls That Actually Prevent Failures
- How Operational Control Works in Practice
- What Most Teams Get Wrong About Crypto Treasury
- Next Steps for Building Your Treasury Infrastructure
- Frequently Asked Questions
The Problem With Legacy Thinking About Crypto Treasuries
Traditional treasury teams are trained to protect cash through bank controls, periodic reconciliations, relationship managers, and approval chains that can tolerate delays. Those habits make sense when a payment can be recalled, a bank can freeze an account, or a reconciliation team can correct a posting before the funds leave the institution.
Onchain operations remove much of that forgiveness. A signer can authorize a transaction that settles while the finance team is still checking a spreadsheet. A shared wallet can hide which employee, service, or agent initiated a request. A webhook can retry after a timeout, and a poorly designed payment service can commit the same business operation twice.
Practical lesson: A wallet address is not an operating model. The operating model must identify the requester, enforce policy, produce an auditable signature, and reconcile the result.
The familiar workflow that fails
A startup often begins with a single treasury wallet, a shared password manager entry, and a spreadsheet containing addresses and balances. Finance updates the file daily. Engineering submits payment requests through chat. An executive gives a verbal approval, and a technical operator broadcasts the transaction.
That approach fails in several ways:
- Identity is unclear: The wallet proves that a key signed, not which business role requested the payment.
- Authorization is weak: A policy may require two approvals, but the signing system may not prevent the requester from approving their own request.
- Verification is incomplete: A transaction hash confirms blockchain activity, but it doesn't prove that the amount, beneficiary, chain, and internal invoice matched the approved intent.
- Reconciliation arrives late: Finance discovers missing metadata after settlement, when correcting the books is harder and incident investigation is already underway.
The enemy is uncontrolled operational ambiguity. It appears as shared credentials, unscoped API access, manual address entry, missing event history, and approvals that exist in documents rather than in the execution path.
Crypto treasury isn't finance with a blockchain wrapper. It requires infrastructure for irreversible, high-velocity, multi-party asset movement. Teams that start with custody alone eventually add controls under pressure. Teams that start with workflow, policy, and observability can make custody one layer of a system that people can operate.
Why This Is a Different Operational Problem Now
Corporate crypto treasury has moved from an isolated custody concern to a balance-sheet and operations problem. Reporting in 2025 said 61 publicly listed companies had adopted Bitcoin treasury strategies, holding 848,100 BTC in the first half of 2025, about 4% of total Bitcoin supply. Q2 2025 added roughly 131,000 BTC, an 18% increase in one quarter, according to Fintech Weekly's coverage of corporate crypto treasuries.
Broader tracking in 2026 placed public-company Bitcoin holdings above 1.09 million BTC, or about 5.2% of circulating supply. CoinGecko's tracker valued corporate treasuries across digital assets at around $102 billion as of August 2026. These figures show why treasury teams need repeatable controls for requests, approvals, settlement, and reconciliation, not only secure key storage.
The balance sheet is only one side
Deloitte's Q2 2025 survey of 200 North American CFOs at companies with at least $1 billion in revenue found that 23% expected treasury departments to accept cryptocurrency as payment or buy it as an investment within two years. That share reached 39% among companies with $10 billion or more in revenue. Deloitte also reported that only 1% did not envision cryptocurrency supporting business functions over the long term, while 15% expected treasury teams to purchase non-stable cryptocurrencies as part of investment strategies in the next 24 months. See Deloitte's Q2 2025 CFO Signals survey.
Each added entity, chain, wallet, and payment purpose creates another control boundary. Treasury may separate customer funds, AI agents, players, operating balances, and reserves. Finance needs transaction attribution, compliance needs sanctions and AML checks, engineering needs idempotent payout APIs, and security needs signing rules that still work when an approver is unavailable.
The old model versus the onchain model
| Legacy assumption | Institutional onchain requirement |
|---|---|
| One account and one daily report | Wallet segmentation and continuous event visibility |
| A general-purpose approval inbox | Policy-bound, role-aware signing |
| Manual address maintenance | Verified beneficiaries and transaction intent |
| Periodic reconciliation | Sub-ledger mapping and exception management |
| Custody as the primary control | Custody, authorization, settlement, and audit as one system |
The operating change is structural. Programmable networks move balance-sheet-grade value through irreversible execution paths, so controls must be present before launch. Requests, signing, broadcasting, monitoring, and reconciliation need one connected workflow that records intent and exposes exceptions. That design determines whether a breach becomes a contained incident or an accounting and operational failure.
The Infrastructure Stack Behind Professional Treasury Operations
Professional crypto treasury management is an operational control stack, not a wallet purchase. The wallet distributes signing authority, the ledger explains every movement, policy limits what can happen, and event monitoring exposes failures before they become accounting problems.
Custody architecture
Use non-custodial MPC when the client must retain meaningful control while distributing signing authority. BroSettlement uses DKG/MPC 2-of-3 signing with a client-controlled Co-Signer, so execution does not depend on one centralized custody key. Document which party holds each signing role, how recovery works, and which operations require a higher quorum.
Teams managing several networks and wallet types also need clear wallet boundaries. The multichain wallet architecture guide provides a useful reference. Chain coverage is only one design question. The wallet layer must express ownership, purpose, and policy for each wallet, so a payout wallet cannot become a reserve wallet.
The operating ledger
Treat the ledger as an operational system, not an accounting export. Record addresses, transactions, lot-level cost basis, realized and unrealized P&L, fees, internal requests, approvals, and destinations. Every blockchain event should map to a business operation or enter an exception queue.
Reconciliation should compare three records:
- Onchain data, including transaction status and token movements.
- Custodian or exchange statements, including balances and activity.
- Internal books, including invoices, payouts, fees, and journal entries.
Each break needs a root-cause note, an owner, and a resolution state. Otherwise, auditors and incident responders see unexplained differences instead of a controlled exception process.
Events, liquidity, and developer access
Polling block explorers is a weak substitute for operational observability. WebSocket events for deposits, confirmations, withdrawals, and policy outcomes let finance and operations respond as state changes occur. The event stream should also preserve transaction identifiers and policy results for later investigation.
Stablecoin balances serve different operating purposes. A practical treasury playbook recommends keeping roughly 60–80% of stablecoin holdings in liquid operational assets such as USDC or USDT for 24–48 hour cash needs, with the remaining 20–40% allocated to yield-bearing instruments for reserves that are not needed immediately. The ranges and related controls appear in Spark's stablecoin treasury management playbook.
The developer control surface closes the workflow. Use scoped API keys, RBAC, IP allowlists, replay protection, sandbox environments, and complete audit trails. Product teams should initiate an approved business operation without gaining unrestricted access to treasury balances or signing authority. That separation keeps application defects from becoming treasury transfers.
Designing Controls That Actually Prevent Failures
A policy document can say that payments require multiple approvals. It doesn't enforce the rule. The signing workflow, API, and ledger must make the unsafe path unavailable or immediately visible.
Identity comes first
Every transaction should identify a real requester and an approved role. Treasury, Security, and Finance shouldn't appear as informal labels in a chat message. They should be authenticated principals with permissions that determine which operations they can request, approve, or execute.
For high-risk treasury activity, distribute key material across multiple parties through MPC or threshold signatures. Recommended patterns include 3-of-5 or 5-of-9, with quorum size scaled to the assets at risk. SEAL's guidance also describes thresholds such as 3/5 or 4/7, depending on operation size and urgency, in its enhanced treasury controls framework.
Authorization must be structural
Enforce segregation of duties at the protocol level. The person who requests a payment cannot approve it. Require at least three distinct approvers across roles such as Treasury, Security, and Finance for high-risk transactions, then apply tighter limits to hot wallets, new beneficiaries, unusual chains, and emergency operations.
A useful policy record contains:
- The business operation ID.
- The requester and role.
- Asset, amount, chain, and destination.
- Approval requirements and completed approvals.
- The signed payload and broadcast result.
- Confirmation state and reconciliation outcome.
Teams also need an explicit compliance path. Screening, audit trails, and role-based permissions should be part of the payment lifecycle, not a manual review added after settlement. BroLabel's crypto AML compliance overview covers the relationship between transaction controls and compliance operations.
Verification must survive retries and outages
Idempotency belongs to the exact business operation. A payment service should define the operation identity, verify that a retry represents the same intent, store in-progress or terminal results, and prevent concurrent commits. A generic request ID isn't enough if two different payout attempts can share it.
Webhook consumers need equivalent discipline. Scope event IDs by provider or source, verify authenticity before recording success, and make each side effect independently recoverable and idempotent. Production guidance also recommends storing API keys in a secrets manager, rotating them, attaching idempotency keys to every write request, verifying webhook signatures, tolerating retries, and running reconciliation jobs at least daily with drift alerts. These practices are detailed in production payment automation guidance and idempotency patterns for payments and webhooks.
Control test: If an operator can bypass the ledger, approval rule, or event verification step during a stressful incident, that control isn't complete.
How Operational Control Works in Practice
Consider a supplier payment initiated by a product service. In a fragile setup, the service receives an address from a database, sends it to a shared wallet operator, and waits for someone to confirm the transaction hash. Finance later matches the hash against an invoice. Each handoff creates room for an incorrect destination, duplicate submission, or missing context.
A controlled workflow keeps the business intent intact from request through reconciliation:
- Request: The product service submits a payment operation with a scoped API key. The request contains the invoice reference, asset, amount, chain, destination, and idempotency key.
- Policy evaluation: The treasury system checks wallet purpose, approved chain, beneficiary status, amount limits, sanctions and AML requirements, and whether the operation needs additional approvals.
- Approval and signing: Treasury, Security, and Finance approve according to policy. The Co-Signer participates in the MPC ceremony, while no single operator reconstructs the full signing key.
- Broadcast and confirmation: The settlement layer broadcasts the transaction and sends WebSocket events for submission, confirmation, withdrawal status, or policy failure.
- Reconciliation: The operating ledger maps the final transaction and fee movements to the original request, then compares onchain records, provider statements, and internal books.
Where AI agents fit
An AI agent shouldn't receive a shared treasury key. Give it a per-agent non-custodial wallet, a narrowly scoped API key, and a policy that limits what it can request. The agent can create an approved operation or prepare a payout batch, while human or service roles retain authority over signing.
That separation makes the agent observable without making it sovereign. If the agent retries after a network timeout, the idempotency record returns the existing operation instead of creating another payment. Finance sees the same event stream as engineering, with status changes tied to a stable internal operation ID.
Teams evaluating MPC can also compare this workflow with the signing model described in the MPC wallet guide. The key question is operational, not fashionable: can the chosen design enforce who may request, approve, sign, broadcast, and reconcile?
What Most Teams Get Wrong About Crypto Treasury
The most expensive mistakes usually come from reasonable assumptions applied in the wrong environment.
Treating crypto like fiat
Daily spreadsheets and monthly audits don't provide enough operational control for irreversible settlement. A spreadsheet can report an address, but it can't enforce that the address belongs to the intended beneficiary at the moment of signing. Manual reconciliation also encourages teams to treat missing metadata as an accounting nuisance rather than a control failure.
Outsourcing the decision to one custodian
A single custodian may simplify onboarding, but it concentrates access, availability, counterparty, and operational risk. Internal policy can't fully compensate for a provider that becomes unavailable, changes withdrawal rules, or suffers a security incident. Diversifying custody and separating operational balances from reserves can reduce the consequences of one failure, but only if the treasury knows which funds sit where and why.
Building reconciliation after launch
Teams often prioritize deposits, withdrawals, and user-facing balances, then promise to add ledgering later. That creates a historical gap that becomes difficult to reconstruct once volume, chains, entities, fees, and internal transfers multiply.
The stablecoin layer deserves its own caution. Neutral industry and policy guidance identifies liquidity risk, counterparty exposure, sanctions and AML controls, and concentration risk as major failure modes. The U.S. Treasury has also warned that stablecoin runs can occur and that the collapse of a major stablecoin could create wider market stress, as summarized in this digital-asset treasury controls guide.
Set exposure caps before stress arrives. Define approved stablecoins, chains, custodians, redemption routes, settlement windows, and emergency escalation rules. The cost of designing those controls upfront is lower than reconstructing records after a breach or explaining an unapproved payment during an audit.
Next Steps for Building Your Treasury Infrastructure
Start with a diagnostic of the workflows that can fail. Shared wallets, manual reconciliation, and a single signer are operational risks, even if they have not caused an incident yet. Document who can request, approve, sign, broadcast, and reconcile each payment.
Choose the first infrastructure layer according to the failure you need to prevent:
- Custody fragmentation: Deploy MPC wallets with a client-controlled Co-Signer and explicit signing policies.
- Reconciliation gaps: Add an immutable operating ledger, transaction attribution, and WebSocket event feeds.
- Developer access: Use scoped API keys, RBAC, replay protection, and separate credentials for each service or agent.
- Settlement complexity: Connect policy evaluation, broadcast, confirmation, and ledger updates in one workflow.
BroSettlement combines those settlement functions through an API. BroWallet supports wallet and fiat workflows for teams that need an operational interface alongside embedded infrastructure. Use the BroLabel documentation to compare modules with your custody, ledger, event, card, and fiat requirements.
Migrate one payment flow first. Trace it from request through approval, signing, broadcast, confirmation, and reconciliation. Test rejected requests, retries, delayed confirmations, and partial failures before extending the workflow to more entities, chains, or wallet purposes. This sequence exposes control gaps without making a company-wide migration the first test of the system.
Frequently Asked Questions
When does crypto treasury infrastructure become worth the integration effort?
The practical threshold is approximately $5 million in monthly stablecoin throughput, where flat-fee SaaS and treasury operations tooling can become more economical than percentage-based payment rails. That threshold is discussed in AlphaPoint's guide to stablecoin adoption for business treasuries. Below that level, simpler workflows may be adequate, but teams should still establish ownership, approvals, and reconciliation before volume grows.
How do you choose between MPC and traditional multisignature wallets?
Traditional multisignature wallets distribute approval across multiple keys, but they still depend on a signing ceremony and the surrounding operational process. MPC solutions generate signatures through a distributed computation without reconstructing the complete private key, which can support per-agent and per-operation policies. The right choice depends on chain support, recovery design, signer independence, audit requirements, and how precisely the system can enforce authorization.
What reporting changes should treasury teams expect?
SEC-reporting entities had to adapt to SAB 122 after January 2025, which removed the old automatic balance-sheet penalty for custodial crypto and returned firms to ordinary loss-contingency accounting. The change increases the importance of accurate reconciliation, custody disclosures, control ownership, and audit-ready records. XBTO's corporate balance-sheet controls guide addresses the control implications for treasury teams.
What should a startup implement before Series A?
Implement wallet segmentation, MPC or threshold signing, role separation, scoped credentials, idempotent writes, verified webhooks, an append-only ledger, and a reconciliation process before payment volume becomes difficult to reconstruct. The first production workflow should be narrow enough to test fully, but complete enough to include request, approval, signing, broadcast, confirmation, and accounting.
BroLabel provides API-first infrastructure for embedded MPC wallets, BroSettlement transaction signing and broadcast, BroWallet interfaces, AI Agent Wallets, real-time WebSocket events, and an immutable operating ledger with reconciliation support. Visit BroLabel to assess the stack, start in the sandbox, and design a controlled crypto payment flow before your treasury becomes too complex to fix safely.