Fragmented positions
Each bank, provider and wallet reports its own balance. A consolidated view is rebuilt manually, and is already stale.
Treasury & Stablecoins In Development
Liquidity is only useful if it is in the right place when a payment needs it.
Payment businesses hold value across bank accounts, providers, currencies and, increasingly, stablecoins. Orangepill gives treasury one ledger-backed view of those positions and governs the movements between them under explicit policy. Stablecoins are one execution rail among several, not the point.
The problem
Money sits idle in one place while payouts fail in another.
A payout provider runs short of local currency on a busy day. Another account holds more than it needs. Moving value between them means an FX decision, a choice of rail and a wait for finality, usually coordinated by someone watching balances in several portals. The faster payment volume grows, the less that scales.
Typical architecture today
Positions in portals, decisions in spreadsheets.
Manual movements
Rebalancing and FX are initiated by hand, outside the systems that know which payouts are waiting.
Rails bolted on
A stablecoin rail is added as a separate project with its own balances and reconciliation, beside the fiat stack.
Where it breaks
Treasury errors look like payment failures.
- Payouts are rejected for insufficient funds while the business holds enough value elsewhere.
- A transfer between accounts is in flight and counted in neither, or in both.
- An FX conversion is executed twice because the first confirmation was late.
- A stablecoin transfer is confirmed on-chain, but the off-ramp has not credited the fiat side.
- Month-end positions do not match what treasury believed during the month.
Orangepill model
Treasury decides where value should be. The runtime governs how it gets there.
Positions
Treasury balances and settlement assets per account, provider and currency, derived from the ledger.
Policy
Thresholds, limits and approvals that decide when value moves and which movements need a person.
Rails
Bank transfers, local rails and stablecoin transfers as interchangeable ways to fulfil a movement.
Reconciliation
Expected positions compared with bank, provider and on-chain records after every movement.
The choice of settlement asset follows cost, speed and availability under your policy. It also informs payout optimisation: a payout can be fulfilled from wherever liquidity already sits, instead of waiting for a transfer.
Example workflow
Rebalancing a payout account before it runs dry.
- Position below threshold Derived from the ledger
- Policy check Limits, approvals, source account
- FX / settlement asset Fiat or stablecoin, chosen under policy
- Transfer executed Finality tracked per rail
- Positions verified Ledger vs. bank and provider records
While the transfer is in flight, the value is recorded as in transit, not available at either end. If the receiving side never confirms, the movement becomes a Resolve case instead of a balance someone adjusts by hand.
Capabilities used
The runtime pieces behind treasury movements.
Wallet & Ledger
Treasury balances per asset, provider and account derived from ledger events, including value in transit between them.
Explore Wallet & Ledger →Multi-Rail Orchestration
Treats bank transfers, local rails and stablecoin transfers as alternative ways to fulfil the same movement, chosen under policy.
Explore Multi-Rail Orchestration →Execution
Each rebalancing or settlement movement runs as a governed lifecycle with finality tracked per rail.
Explore Execution →Resolve
Handles movements whose finality is unclear or whose result does not match the expected position.
Explore Resolve →Outcome
Treasury that keeps pace with payment volume.
- A current view of positions across accounts, providers and assets.
- Rebalancing triggered by policy rather than someone watching balances.
- Add a stablecoin or local rail without building a second treasury stack.
- In-transit value accounted for explicitly, at every point of a movement.
- Reconciliation of fiat and on-chain movements against one ledger.
Maturity: In Development. Designed and being built. Not yet available. Cross-border payouts through liquidity providers are live; stablecoin settlement rails are being built. Supported assets, rails and providers are confirmed per engagement.
Show us where your liquidity sits today.
List your accounts, providers and settlement assets. We will map which movements could run under policy and which need to stay with your treasury team.