
A finance team signs a treasury management agreement expecting its bank to invest idle cash and handle routine movements. Then a funding squeeze hits. The agreement doesn't say who controls the digital wallet, who can approve exposure to a protocol, or how quickly the company can retrieve assets if a provider or network falters. The document granted authority, but it never established a dependable operating framework.
A useful treasury management agreement does more than authorize services. It sets limits, assigns decision rights, and spells out what happens when routine processes fail. Treat this guide as a clause-by-clause reference: use it to identify omissions, challenge vague drafting, and extend bank-focused templates to stablecoin and on-chain activity. For background on the broader operating risks, see this practical overview on CEF treasury risks. The aim is enforceable controls, not a legal formality that disappears into onboarding paperwork.
What a Treasury Management Agreement Is Really For
The agreement should make clear who may do what with company funds, under which conditions, and with what evidence. That means naming authorized people and entities, defining permitted transactions, setting limits, and requiring records that let the company verify what happened. A clause saying the provider may “manage cash” doesn't answer whether it can move money between accounts, invest it, delegate activity, or hold assets in its own name.
Start by separating permission from control. Permission describes the services a provider may perform. Control defines the boundaries: which assets and venues are allowed, who approves activity, how liquidity is protected, and what the provider must report. Then test the agreement against a disrupted day, not just a normal one. If an approver is unavailable, a bank is offline, or a digital asset can't be redeemed as expected, the contract should point to an authorized fallback rather than leave the team improvising.
A practical review follows the document in operating order. Confirm the parties and scope first, then inspect authority and approvals, liquidity requirements, custody and reporting, and finally breach and exit procedures. This makes it easier to find gaps that a polished service description can hide.
Practical rule: If a clause doesn't identify an owner, a limit, a deadline, or an evidence trail, it may describe intent without controlling behavior.
By the end of a disciplined review, you should be able to mark missing protections, propose tighter language, and tell whether a standard bank-oriented form reaches far enough to govern stablecoins, wallets, and smart-contract exposure.
Origins and Why the Modern Document Exists
Corporate treasury became more formal as companies faced more complex cash and risk decisions. In the United States, automated bank processing began emerging in the early 1970s, supporting services such as lockbox processing, controlled disbursements, account reconciliation, and cash concentration. Money-market funds also emerged in 1971, giving institutions another way to manage short-term liquidity. These changes made centralized visibility and clear operating responsibilities more important, not less. (Association of Corporate Treasurers history of U.S. treasury)
High inflation made the cost of weak cash management harder to ignore. The yield on 10-year U.S. Treasury securities reached approximately 15% in 1980, raising the opportunity cost of idle balances and increasing the risk of poorly structured funding. The Monetary Control Act of 1980 changed the economics of U.S. banking transaction services and helped shape the modern treasury-services market. Those pressures help explain why today's agreements need provisions for cash forecasting, liquidity, payment execution, investment limits, and bank-relationship controls. For a wider executive perspective on investment governance, see this guide to professional asset management for executives.
A separate historical lesson came from the 1951 Treasury–Federal Reserve Accord. From 1942 through 1951, the Federal Reserve maintained a peg of 2.5% on long-term Treasury securities to support government financing. As inflation rose above 8% year over year during the Korean War period, the arrangement became harder to sustain. On March 4, 1951, the Treasury and Federal Reserve announced an accord on debt management and monetary policy. Though the relationship wasn't fully severed in practice until 1953, the accord clarified authority and allowed the Federal Reserve to set interest rates according to broader economic conditions. (Brookings explanation of the 1951 Accord)
The practical connection is direct: define mandates, decision rights, and risk boundaries between parties. Historical pressures shaped the clause categories that still matter, from investment authority to liquidity limits and escalation.
Core Clause Categories Every Agreement Should Cover
A treasury management agreement needs a clear structure before anyone assesses the finer controls. The parties, service scope, authority, performance expectations, costs, reporting, confidentiality, duration, and dispute terms each answer a distinct operational question. A contract clause reference from Coto & Waddington Attorneys at Law can help readers recognize common drafting components, but treasury terms must be adapted to the actual flow of funds.

Work through the core categories as operating instructions:
Parties and defined terms: Identify the company, provider, affiliates, custodians, and any other parties with access or responsibilities. Define terms such as “client assets,” “authorized approver,” and “business day” so that operational teams don't rely on informal interpretations.
Scope of services: List the actual activities covered, such as cash concentration, payment execution, forecasting, investment, custody, or collateral administration. Exclude activities the provider isn't authorized to perform.
Authority and delegation: State who can initiate, approve, delegate, or change instructions. A useful starting point is: “Provider shall act solely as agent and shall not take possession of Client funds except as expressly authorized.” Then define approval limits and named roles.
Service levels and reporting cadence: Set response, processing, outage-notification, and statement-delivery expectations. A defined cadence and format let the company see changes before they affect a funding decision.
Fees and payment terms: Specify charges, calculation methods, timing, and how third-party costs are treated. Don't leave deductions from client assets open-ended.
Term, termination, governing law, and disputes: Explain how the relationship ends, how assets and records transfer, which law governs, and how disagreements are handled. Governing law matters when accounts, providers, or counterparties operate across borders.
The omissions to catch early are usually practical: authority limits, named approvers, and a reporting schedule. A detailed service description won't replace any of them.
The Control Framework Inside the Agreement
Controls work as a system. Permitted assets and venues define what may be held; counterparty and concentration limits restrict exposure; liquidity and maturity rules protect the funding plan. Valuation and reporting let the company detect a change, while approval authorities, segregation of duties, escalation, and audit rights determine who can act and how the company verifies that action. Termination mechanics and governing law provide the route out when the arrangement no longer works.
A broad commitment to “act in the client's best interests” doesn't establish any of those boundaries. Draft for observable outcomes instead. PwC's treasury maturity framework evaluates procedures, controls, liquidity, and benchmarking through 89 questions and five maturity levels, a useful reminder to replace vague “best efforts” wording with measurable control KPIs. (PwC treasury cash-management maturity assessment)
A sample provision can combine the pieces:
Permitted assets and limits: “Provider may invest Client funds only in the instruments, venues, and counterparties listed in Schedule A. Exposure to any single issuer must remain within the concentration limit in Schedule B. Transactions exceeding the applicable pre-trade approval threshold require written approval from a named Client approver. Provider shall notify Client promptly of any actual or expected breach, preserve relevant records, and follow the documented escalation procedure. Client may review supporting records and terminate the affected mandate under the stated termination mechanics.”
The example is useful because it ties eligibility to limits, approval, evidence, escalation, and exit. The schedules should contain actual approved instruments, thresholds, and contacts, not placeholder phrases. Review the document as a working control map: if a team can't tell whether a transaction is allowed or what to do when a limit is breached, the language isn't finished.
Liquidity Policy as an Enforceable Clause
A liquidity policy is only operational if the agreement turns it into measurable obligations. A separate policy memo can guide staff, but it won't bind the provider unless the contract incorporates its requirements and sets a remedy for failure.
Build the clause around four elements:
Rolling cash-flow forecast: Require the provider or treasury team to maintain and update a forecast on an agreed cadence, using expected receipts, payments, debt service, and other obligations. The agreement should identify who supplies inputs and who reviews material changes.
Minimum immediately available liquidity: Define a floor as a specified operating buffer or an agreed number of days of operating expenses. State which assets count as immediately available and which don't.
Maximum weighted-average maturity: Set a cap for surplus cash that reflects the company's funding horizon. An investment that matures after the cash is needed isn't liquid for that obligation.
Named stress scenarios: Specify how the arrangement should be tested against redemption spikes, settlement delays, banking outages, and market-value declines. Define who runs the test, what gets reported, and what action follows a shortfall.
For example, a clause could require the provider to maintain enough accessible liquidity to meet forecast obligations under an agreed redemption stress, while limiting maturity in line with the client's expected cash needs. The company must set the actual thresholds based on its flows; the contract shouldn't imply a universal buffer.
Public-sector treasury practices emphasize maintaining adequate, but not excessive, cash resources, producing regular cash-flow projections, and using liability benchmarks to identify future borrowing needs. Those principles translate well to corporate agreements: forecast obligations, preserve a defensible liquidity floor, and document the link between cash needs and investment maturity. The useful test is simple: can the company identify the threshold, verify it, and enforce it?
Collateral, Custody and Account Control Provisions
Collateral terms often sit across multiple documents, so the treasury management agreement should identify how they fit together. ISDA guidance recommends pairing an ISDA Master Agreement with the applicable Credit Support Annex, Credit Support Deed, or Credit Support Document to establish collateral terms. It also recommends executing an Account Control Agreement, or equivalent, at the start of the counterparty relationship and obtaining signatures from relevant parties, including a third-party custodian, before collateralized trades begin. (ISDA collateral management guidance)
The agreement should say what collateral is eligible, which valuation sources apply, what haircuts are used, when margin calls are due, and how minimum transfer amounts and disputes are handled. It should also establish substitution rights, custody location, account-control mechanics, perfection requirements, and rights following default. Without those terms, teams may agree on exposure but lack a reliable process for moving or enforcing collateral.
Operational clauses matter just as much. Require reconciliations, settlement cutoffs, notification procedures, and documented authorization for collateral movements. Name the party responsible for each step and define what happens when an instruction misses a cutoff or a balance doesn't reconcile.
Digitally managed programs need technical requirements alongside legal ones. Specify system-readable identifiers, timestamped approvals, immutable activity logs, and API- or file-based reporting. Workflow failures can create operational, liquidity, and counterparty risk even when the underlying strategy is sound. For a focused framework on that exposure, use this guide to managing counterparty risk. The contract should make reconciliation and escalation possible without relying on screenshots or informal messages.
Extending the Agreement to Stablecoins and On-Chain Activity
A bank-oriented template doesn't define an on-chain control perimeter. If the agreement allows stablecoin activity, it should name permitted assets, issuers, networks, protocols, and counterparties, then set concentration limits and approval rules. It should also explain how valuation works, which oracle or pricing sources apply, who can initiate emergency withdrawals, and how quickly the provider must report an incident, depeg, or network disruption.
The agreement should prohibit rehypothecation, lending, staking, or liquidity-pool placement unless the company has expressly approved a defined activity. It should also require segregation of client assets, audit rights, and a clear allocation of responsibility for third-party smart-contract failure. BitGo's guide to crypto treasury management for CFOs makes the operational gap clear: a general promise to manage assets doesn't identify who may initiate or approve transactions, how much counterparty exposure is acceptable, or what happens when a key, wallet, issuer, or service provider is compromised.
A higher quoted yield can indicate weaker governance rather than better treasury management. The agreement should optimize risk-adjusted liquidity, not headline APY. “Approved DeFi strategies” is not enough; the contract needs an approved list, change controls, and a clear path to stop activity when conditions change.
Use language that settles ownership of the economics:
“Yield attributable to Client assets belongs to Client, net of disclosed gas, bridge, custody, performance, and slippage costs. Provider shall not deduct any other charge or retain yield unless Client has expressly approved the fee and calculation method in writing.”
That clause still needs a reconciliation cadence and reporting requirements, but it prevents a common ambiguity: the provider reports a gross yield while the client bears costs that were never clearly allocated.
Custody, Segregation and Reserve Roles
Custody terms should describe legal ownership and operational access, not repeat a provider's marketing language. Under the U.S. statutory custody framework described in 12 U.S.C. §5909, reserve assets and customer assets must be separately accounted for and segregated from the custodian's own assets. The relevant custodian or covered person must also provide regulators with information about its operations and processes for protecting customer assets. (12 U.S.C. §5909)
Translate that floor into contract duties: identify the legal owner of each asset, the segregation arrangement, the party responsible for record-keeping and reconciliation, and who can access or move assets. Require recurring reporting and a defined package of information after an incident, including relevant transaction records and the status of affected assets. When a fintech, exchange, wallet, or other platform holds stablecoins for customers, businesses considering whether to partner with a stablecoin yield provider should document custody and asset-protection duties separately from any yield strategy. Yields vary, and crypto carries risk.
Don't conflate the reserve custodian with the reserve manager. The custodian holds backing assets; the manager makes investment decisions and maintains assets that can be invested or redeemed almost instantaneously, alongside a liquidity buffer intended to reduce run risk. Congressional testimony gave a straightforward example: $1 billion in stablecoins in circulation would generally require at least $1 billion in reserve assets. (Congressional testimony on stablecoin reserve management)
The Financial Stability Board's international guidance also emphasizes intermediary safeguards over customer assets and private keys, risk disclosures, ownership rights, segregation, and records. (FSB recommendations on global stablecoin arrangements) Put those responsibilities into the agreement through wallet and key-management standards, multi-approval workflows, transaction logs, and contingency and recovery procedures. For related compliance considerations, see this guide to understanding regulatory compliance.
Yield Allocation, Costs and Reporting Discipline
A headline APY doesn't tell a treasury team what it will receive or what risks it is taking. The agreement should require a net calculation that accounts for gas, bridge fees, custody, performance fees, and slippage, then state which party bears each cost and how the result is reconciled. A high quoted figure can reflect a strategy that adds operational or counterparty exposure without improving usable liquidity.

An agreement should also tie on-chain balances back to the client's accounting records. Specify the reporting cadence, the format of transaction-level detail, how discrepancies are investigated, and how quickly they must be escalated. Where relevant, preserve the right to request proof of reserves or proof of control. The report should let finance reconcile assets and costs, rather than provide an attractive summary number without supporting evidence.
Corporate treasury analysis identifies fragmented regulation, inconsistent interoperability, custody and private-key risks, and smart-contract failure as continuing barriers. That makes reporting a risk-detection control, not a performance presentation. Use this overview of treasury management software as a starting point for evaluating what data your systems need to ingest.
A sample clause can state: “Provider shall calculate Client's net yield after all approved costs, report gross yield and each deduction separately, and reconcile the resulting balances to Client's accounting records on the agreed reporting cadence.” Include a right to inspect supporting records and challenge a calculation. If the provider can't show how a net figure was produced, the company can't verify its economics or its exposure.
Exit Rights and Wind-Down Under Stress
A contract that says “no lockup” hasn't necessarily made funds accessible. Nominal liquidity describes an asset that has no stated lockup. Access-under-stress asks whether the company can retrieve or settle it when a protocol pauses withdrawals, a bridge fails, an issuer delays redemption, or a network becomes congested.
Integration also affects the exit plan. EY survey data reported that 41% of organizations could integrate stablecoins with moderate effort, while 36% would need major system changes; roughly 70% said ERP integration would make adoption more attractive. (EY stablecoin survey) Those findings make integration duties part of the service relationship, not an implementation detail to leave outside the agreement.
Write a wind-down plan that specifies the maximum withdrawal time, supported networks, fallback settlement rails, treatment of pending transactions, reconciliation standards, data portability, and provider assistance during termination. Prohibit unilateral changes to eligible assets or networks without notice. Require scenario testing and set clear triggers for suspension or termination when access, regulatory conditions, or asset eligibility changes.
A termination-for-convenience clause could say: “Client may terminate on written notice. Provider shall stop initiating new transactions, return or transfer Client assets through the agreed settlement route, deliver complete records, and assist with reconciliation within the stated wind-down period.” The agreement should define that period and schedule tests of the exit process. For perspective on cash products that may feature in a liquidity plan, see this analysis of whether treasury money-market funds are safe.
Quick Reference Checklist for Reviewing Any Draft
Use the table to identify what each clause is meant to prevent and what evidence should exist before approval. A reviewer working through complex supporting documents can also use this guide to risk management documentation as a prompt for the records and approvals to request.
Clause Category | Default Risk It Addresses | Required Evidence |
|---|---|---|
Parties and scope | Unclear responsibility or unauthorized services | Named parties, defined terms, service schedule |
Control framework | Unbounded investment or payment discretion | Approved assets, limits, authorities, escalation path |
Liquidity policy | Funds unavailable when obligations fall due | Forecast, liquidity threshold, maturity limit, stress results |
Collateral and custody | Disputed or delayed collateral movement | Executed support documents, account control, reconciliations |
Stablecoin provisions | Unapproved protocols, wallets, or counterparties | Approved lists, valuation method, incident process |
Custody and segregation | Unclear ownership or commingling | Segregation records, access rights, reconciliation evidence |
Yield allocation | Hidden costs or disputed net economics | Cost schedule, calculation, reporting, supporting records |
Exit rights | Delayed access or incomplete handover | Tested withdrawal route, transfer records, wind-down plan |
Walk the draft in this order:
Parties and scope: Are all providers, custodians, affiliates, and covered services identified?
Control framework: Are limits, named approvers, segregation of duties, audit rights, and escalation documented?
Liquidity policy: Are forecasts, immediately available liquidity, maturity limits, and stress tests measurable?
Collateral and custody: Do the relevant documents align, and is account control operationally ready?
Stablecoin provisions: Are assets, issuers, networks, protocols, valuation, and permitted uses explicit?
Custody and segregation: Are ownership, access, records, and incident reporting defined?
Yield allocation: Can finance reproduce the net calculation and reconcile it to the ledger?
Exit rights: Can the company retrieve assets and obtain usable records under stress?
Treat “best efforts,” “as appropriate,” “from time to time,” and “sole discretion” as review flags. If the clause doesn't say who decides, when action is due, and what record proves it happened, ask for specific language.
Stress-Focused Questions to Ask Before Signing
What happens during a stablecoin depeg? The agreement should state the redemption route, expected decision and notification process, available fallback providers, and the deadline for reporting a depeg or impaired redemption. The stablecoin and on-chain section should also establish who can pause activity or authorize an emergency withdrawal. Yields vary, and crypto carries risk; a redemption promise should be tested against the actual issuer and settlement path.
What will ERP and systems integration require? Ask which systems the provider supports, what data must move, who owns implementation work, and how changes affect service levels and termination assistance. The wind-down section should cover portability and handover so integration doesn't become a reason the company can't exit. EY survey findings on integration effort are discussed above; the contract should translate that operational uncertainty into assigned responsibilities.
Can the provider rehypothecate, lend, stake, or place client assets in liquidity pools? The default should be a clear prohibition, with any permitted exception narrowly defined and approved in writing. The stablecoin control provisions should cover the activity, exposure limit, custody arrangement, and liability allocation. Don't treat higher yield as evidence of better governance: returns vary, and crypto assets carry risk.
Yield Seeker offers an AI-powered workflow that monitors and allocates USDC across DeFi opportunities on Base, with balances and earnings visible in one interface. If you're assessing automated stablecoin allocation alongside the controls in this guide, visit Yield Seeker to review how its workflow operates.