Rebalancing recommendations
Holdings compared against target bands per wallet and asset, with a transfer or conversion proposed when a weight drifts.
TREASURY OPERATIONS AUTOMATION
Treasury Work That Prepares Itself — and Still Waits for Your Approval
Crypto treasury operations automation proposes rebalancing, settlement pre-funding and liquidity actions, prices their impact, and executes only after a named person releases them. It reads what your payment and treasury rails produce. Nothing moves on its own.
Approval-gatedevery action
Impact-pricedbefore deciding
Audit-readyproposal to result
HOW AN ACTION TRAVELS
Recommendation, Impact, Approver, Execution, Audit
Five stages, in this order, every time. The third one is a person — and the sequence does not continue without them.
1
1. Recommendation
The engine reads balances, obligations due, transfer conditions and the policy you configured. When holdings drift outside a band or an obligation is short of cover, it writes a specific action and the rule that triggered it.
2
2. Impact estimate
No action reaches an approver unpriced. Each carries the allocation the treasury would hold afterwards, the cost split into fees, spread and venue charges, and the limits it resolves. Approve an outcome, not a transfer.
3
3. Approver
The action enters the queue and stops. Routing is by action type and value band: an internal rebalance may need one approval, an external movement two. The proposer cannot approve, and anything waiting escalates on your timer.
4
4. Execution
Only an approved action runs, under the identity of the approver who released it, to allowlisted destinations. Progress is visible while it happens, and an action an approver trimmed executes at the trimmed size, not the proposed one.
5
5. Audit
Recommendation, reason, estimate, decision, person, edit, execution and actual result stay on one record. Rejections are kept with the same weight as approvals, and the record exports for finance review and internal control.
Positions and Policy In. Approved, Recorded Actions Out.
The engine never touches an asset directly. It reads, it proposes, it prices — and then it waits at the approval gate for a person.
THE WORKFLOW ON SCREENFour Screens,
Four Screens,
One Controlled Decision
Settlement preparation
Obligations due are read ahead and shortfalls turned into pre-funding actions, so a settlement is covered before its window.
Liquidity actions
Funding, payout and venue balances watched against your cover minimums, with top-ups proposed as the ratio approaches its floor.
Impact preview on every action
Resulting allocation, transfer fees, conversion spread and venue charges attached before the action ever reaches a person.
Human approval before execution
Every action stops in the queue until a named approver releases it. No autonomous mode and no bypass for small values.
Approver routing and quorums
Routing by action type and value band, escalation timers per rule, and a separate path outside the treasury perimeter.
Separation of duties
A proposer cannot approve their own action, and roles carry explicit propose, approve and policy-change rights.
Exportable audit trail
Proposal, reason, estimate, decision, approver, edits, execution and outcome on one record, exported for finance review.
Reads your treasury wallets
Balances and movements come from the wallet and custody infrastructure already deployed. This layer never holds keys of its own.
Sits on the payment and treasury rails
Acceptance, settlement, payouts and reporting stay with the stablecoin rails; this layer prepares what happens next.
Feeds the accounting export
One reference travels from proposal through approval to execution, so the treasury action and the ledger entry match.
Shares the platform's controls
The same role model, approval mechanics and audit logging used across the operations and compliance consoles.
What the System Does, and What a Person Still Decides
The dividing line is the product. Coiny automates the preparation — the watching, the working out, the pricing, the recording. A named person makes every decision that moves value.
| # | Treasury task | What the system does automatically | What a person approves |
|---|---|---|---|
| 1 | Rebalancing | Detects the drift and proposes the transferMeasured against your bands, not a default | Whether the move happens, and at what size |
| 2 | Settlement preparation | Reads obligations due and prices the pre-fundingShortfall identified before the window | Which obligations are funded, and from where |
| 3 | Liquidity actions | Watches cover ratios against their minimumsTop-up proposed as the floor is approached | Whether to top up, hold, or accept the position |
| 4 | Cash and stablecoin allocation | Tracks weights across currencies and walletsDrift from price and from activity separated | The target allocation and the tolerance bands |
| 5 | Cost and impact | Estimates the outcome before the decisionCompared against the real result afterwards | Whether the estimated cost is worth the correction |
| 6 | Execution | Runs only what was released, to allowlisted destinationsUnder the approver's identity, with live status | The release itself — nothing runs unapproved |
| 7 | Policy and thresholds | Applies the rules and records every changeRule changes are approval-gated too | Who approves what, at which value, with what quorum |
THE APPROVAL QUEUEBook a Demo
One Queue Where Every Treasury Action Waits for a Named Approver
This is the screen the product is built around. Each row carries the recommendation, the estimated impact, the approver the policy named and the current status — and no row leaves it without a decision. Approve, edit the size, or reject with a reason; all three outcomes are recorded the same way.
Every action, one queueRebalancing, settlement pre-funding, liquidity top-ups and allocation changes arrive in one place, reviewed as one list.
The impact is on the rowResulting allocation, estimated cost and the limit each action resolves are visible before the row is opened.
Routing by value and action typeOne approval below a band, two above it, a separate path outside the treasury perimeter, and escalation on a timer you configure.
Edit before approvingAn approver can trim an amount or change the destination before releasing; the edit, the reason and the person are recorded.
Rejections carry the same weightA rejected action closes with a recorded reason and stays in the history, because the decision not to act is part of the record.
Held when a limit breaksIf a limit is breached mid-cycle the queue holds, and held actions are re-priced against the new position before they are shown again.
BUILT FOR
Teams Accountable for a Digital Asset Balance Sheet
Treasury leads and finance operations teams who carry the consequences of a missed settlement, a drifted allocation or an action nobody can explain afterwards.
Exchange treasury teams
Hot, warm and settlement wallets watched against policy around the clock, with pre-funding prepared before obligations fall due.
Funds and asset managers
Cash and stablecoin allocation held inside mandate bands, with the reasoning for each proposed correction written down beforehand.
Fintechs and payment businesses
Funding, payout and venue balances kept above their cover minimums, so customer-facing flows do not stall at end of day.
Finance control and internal audit
A record that answers what is actually asked: who proposed it, what was estimated, who approved it, and what the outcome was.
CONNECTED STACK
What This Layer Sits On Top Of
Treasury Operations Automation does not hold assets or move money by itself. It reads the wallets and rails Coiny already deploys, works out what should happen next, and hands each action to a person to release.
COMMON QUESTIONS
Treasury Automation, Answered
Crypto treasury automation is software that watches a business's digital asset holdings against its treasury policy and prepares the actions needed to keep them in line. Coiny Exchange's Treasury Operations Automation proposes rebalancing, settlement preparation and liquidity actions, prices each one before anyone sees it, routes it to a named approver, and executes only what that person releases. Every proposal, decision and result is kept in an audit trail.
No. In Coiny Exchange's Treasury Operations Automation nothing executes autonomously. Every action is proposed with its reason and an impact estimate, then held in an approval queue until a named approver releases, edits or rejects it. Approver identity, value bands and quorums are set by the operator, separation of duties is enforced so a proposer cannot approve their own action, and rejections are recorded alongside approvals.
Coiny Exchange's Treasury Operations Automation prepares four families of action: rebalancing between wallets and accounts to hold target allocations, settlement preparation that pre-funds obligations already due, liquidity actions that keep funding and payout wallets above their cover minimums, and cash and stablecoin allocation adjustments when a weight drifts outside its band. Each is proposed for approval rather than executed on its own.
A treasury action queue is the single list where every proposed treasury action waits for a decision. In Coiny Exchange deployments each row carries the recommendation, the reason and policy rule behind it, the estimated impact and cost, the named approver it is routed to, and its current status. Approving from the queue releases the action for execution; rejecting it closes the row with a recorded reason.
An audit trail for treasury operations records who or what proposed an action, why it was proposed, what was estimated, who approved or rejected it, what actually executed and how the outcome compared with the estimate. Coiny Exchange keeps all of that on one record per action, including changes an approver made before signing, and exports it for finance review and internal control.
Treasury permissions are configured per role and per action type. In Coiny Exchange's Treasury Operations Automation the operator decides which roles may propose, which may approve, which value bands need two approvals instead of one, how long an action waits before it escalates, and which destination addresses are allowlisted. Changing any of those rules is itself an approval-gated action and is written to the audit trail.
Stablecoin payment rails move value: they accept payments, settle merchants, send payouts and hold balances. Treasury operations automation sits on top of those rails and decides what should happen next — which wallet is short, which obligation needs funding, which allocation has drifted — then proposes the action for approval. Coiny Exchange deploys both, and the automation layer reads the balances the rails produce.
SEE THE QUEUE
Bring Your Treasury Policy. Leave With an Action Queue.
Walk through a live recommendation, read the reasoning and the impact estimate behind it, set the approver rules the way your finance function actually works, and see what the audit record looks like at the end of it.
Book a Demo