Ask the finance lead at most crypto-native B2B businesses how they manage treasury and you get two answers. There is the banking side: accounts with a startup-friendly bank, payables and receivables in fiat, FX handled through the bank or a payment provider, cash positions tracked in a CFO dashboard. And then there is the onchain side: stablecoin balances in multisig wallets or institutional custody, exchange accounts for conversion, onchain flows for cross-border payments, a separate set of logins and exports and processes. Two systems. Two ledgers. Two sets of workflows. One business.
This is the norm, not the exception. Most crypto-native businesses at the $1 million to $50 million annual payment volume range maintain separate tooling for each side; traditional banking platforms for fiat, and custody or wallet infrastructure such as Gnosis Safe, Fireblocks, or Coinbase Prime for onchain positions. Crypto treasury management guidance from Fireblocks describes the typical setup: bank accounts and CFO dashboards on the fiat side, multisig wallets and custodians on the onchain side, with the two rarely integrated in any meaningful way. Some tools have begun to bridge the gap, but most teams still treat banking and wallets as separate systems with separate logins, separate exports, and separate processes.
The cost of running this way is not a line item on any budget. It is an aggregate of operational overhead, poor decision quality, avoidable FX exposure, and a financial picture that is permanently incomplete. It accumulates quietly and compounds as the business grows.
The Operational Cost
The most visible cost of running two separate treasury systems is the reconciliation overhead. Fiat transactions flow through bank statements. Onchain transactions live on the blockchain. Neither talks to the other automatically. Matching them requires exporting data from both systems, normalising incompatible formats, reconciling balances against payment instructions, and producing a consolidated view that neither system can generate on its own. Research on crypto reconciliation for finance teams documents the result: without dedicated tooling, high-volume teams can spend roughly 40 hours per month on this reconciliation work alone — the equivalent of a full-time role consumed by bridging a gap that should not exist.
The overhead extends beyond reconciliation. Controls and approval workflows are different on each side: dual-signature requirements in the banking system, multisig thresholds in the wallet infrastructure, incident management processes that were built for one system and do not cover the other. Reporting is produced separately for each side and then manually combined for management, investors, and auditors. Slash’s analysis of crypto treasury management describes this as two parallel operating environments that happen to serve the same business — and the cost of maintaining both is higher than either side alone would suggest.
The tooling cost compounds the operational cost. Crypto treasury software for mid-market organisations runs to tens or hundreds of thousands of dollars annually, on top of custody fees, banking platform subscriptions, and the ERP and accounting infrastructure already in place for the fiat side. These are not duplicated purchases of the same thing. They are two separate categories of spend for two systems that are managing what should be a single treasury function.
The Liquidity Visibility Problem
The deeper cost is what the separation does to decision-making. A business that manages fiat and onchain treasury separately has no single view of its total liquidity at any point in time. The fiat side knows what is in the bank accounts. The onchain side knows what is in the wallets and on exchanges. Neither knows what is on the other side, and combining the two requires manual work that is typically done weekly or monthly, not in real time. Plasma’s overview of stablecoin treasury management identifies this as a structural gap: onchain treasuries can provide near-real-time visibility on their own side, but that still has to be combined manually with fiat positions to produce a true liquidity picture.
The consequences cascade through every treasury decision. Working capital management requires knowing total available liquidity, but the team cannot see the full picture without running a manual consolidation. FX hedging decisions are made on partial data, leading to over- or under-hedging depending on which side of the ledger is visible at the time. Payroll and supplier payments are timed conservatively because the finance team cannot see in real time when cash that is sitting onchain will be available as usable fiat in the right account. Corridor pre-funding decisions are made with buffers that are larger than they need to be, because the cost of getting it wrong — a failed payment — is higher than the cost of idle capital.
A business cannot make good treasury decisions on an incomplete balance sheet. When fiat and onchain positions are managed separately, the balance sheet is always incomplete.
The FX Exposure You Did Not Plan For
Separate fiat and onchain treasuries often hold currency positions on both sides that look neutral in aggregate but create real foreign exchange exposure in practice because the two sides are not coordinated. The fiat treasury might hold local currency balances against known fiat obligations. The onchain treasury might hold USDC as a quasi-dollar asset against expected stablecoin flows. Neither side knows what the other holds, so the positions are managed independently rather than as a net exposure. Fipto’s crypto treasury management guidance identifies this coordination failure as a primary source of unmanaged FX basis risk for businesses running dual-rail operations: natural hedges that exist on paper are missed in practice because the two sides of the treasury are not talking to each other.
The problem is compounded by timing. Onchain balances are funded and defunded on a schedule that reflects the operational logic of the onchain side — when payments need to go out, when receipts come in. That schedule does not automatically align with the FX windows, cut-off times, and liquidity conditions that govern conversion on the fiat side. Conversions happen at suboptimal times not because the treasury team made a bad decision but because the two systems do not share a unified view of when the best time to convert actually is.
The Forecasting Problem
Accurate cash flow forecasting requires a forward view of all inflows and outflows across both rails simultaneously. When fiat and onchain are managed separately, the forecasting process splits along the same lines. Onchain flows are modelled in one place; fiat obligations are modelled in another. The two models are combined manually, usually at the end of the week or month, by which point the consolidated picture is already out of date. Stripe’s analysis of crypto treasury management notes that CFOs at crypto-native businesses routinely delay or undercommit to investment decisions because they cannot see consolidated runway across onchain and fiat positions, not because the capital is not there, but because the picture that would let them act confidently is not available in real time.
This is not primarily a volatility problem. Stablecoins are not volatile. The forecasting problem is a structural opacity problem: two systems producing data in incompatible formats, on incompatible timelines, that have to be manually reconciled before anyone can answer the question of how much money the business actually has and where it is.
What Unified Actually Means
A treasury function that treats fiat and onchain positions as a single financial picture requires more than a dashboard that shows both sides. It requires a unified data layer that pulls balances and transactions from banks, wallets, custodians, and exchanges into a single ledger in real time. It requires consolidated policy and controls that apply consistently across both rails — one set of approval flows, one risk framework, one reporting structure. And it requires decision-making infrastructure that can net fiat and onchain exposures, schedule conversions at the right time, and produce a cash flow forecast that includes both sides as interchangeable inputs. Cryptoworth’s multi-entity accounting platform describes the emerging category of tools that connect ERPs to wallets, custodians, and banking providers, but notes that coverage remains uneven and the full integration that a mature treasury function requires is still being assembled from components rather than available as a single layer.
The businesses that have come closest to solving this have typically built significant custom infrastructure: internal dashboards that pull from both rails, reconciliation tooling that handles the format translation, treasury policies that explicitly cover both fiat and onchain positions under a single governance framework. They built it because they ran into the costs of not having it: the missed hedges, the delayed decisions, the month-end close that took weeks, the audit that surfaced undocumented onchain flows.
The cost of running two treasuries is not a technology problem that will be solved when better APIs become available. It is a design problem. The financial infrastructure most crypto-native businesses are running was not designed for a business that operates across two financial systems simultaneously. It was assembled from components that were each designed for one. Closing the gap requires infrastructure that starts from the unified case — one treasury, two rails — rather than trying to bolt two separate systems together after the fact.