Treasury: Liquidity and reserves
TL; DR
Treasury in iGaming is a managed network of liquidity "pockets" (banks, PSPs, wallets, crypto-custom, merchant accounts) with different I/O SLAs. Target - zero cash gaps at minimum cost: accurate forecast of flows, limits on counterparties and currencies, reserve policy (operating buffers + regulatory safeguards + stress reserve), discipline of prefunding and sweep rules, SLO for Time-to-Payout and Time-to-Fund.
1) Liquidity map: levels, pockets, flows
1. 1 Liquidity levels (by availability)
L0 (T0) - instant liquidity: operating balances on merchant accounts, instant A2A/RTP, wallets, stable reserves, cash buffers for payout T0.
L1 (T + 1... T + 3) - short-term liquidity: settlement accounts of PSP/acquirers, bank current accounts with intraday limits.
L2 (T + 5... T + 10) - liquidity of the middle horizon: deposit/savings accounts, sweeps into treasury instruments (T-bills, MMF), "parking" of stables on a custom with a quick off-ramp.
L3 (T + 10 +) - strategic liquidity/capital: long deposits, bonds, reserved capital.
1. 2 Liquidity pockets (example)
Bank_OPS (operating bank): entry/exit fiat, salary, taxes.
PSP_MERCHANT: merchant accounts by methods (Card, A2A, Wallet).
PSP_SETTLEMENT: Settlement/accumulation accounts (T + N)
CRYPTO_CUSTODY: on-chain/custom, stables and underlying assets.
PAYOUT_POOLS: separate pools for instant payments.
SAFEGUARD_ACCOUNTS: segregated accounts according to regulator/license requirements.
1. 3 Main flows
`Deposits → PSP_MERCHANT → Settlement → Bank_OPS`
`Bank_OPS → Payout_Pools/PSP → Withdrawals`
`On/Off-ramp ↔ Crypto_Custody`
'Sweeps: L0↔L1↔L2 'by schedule and triggers.
2) Liquidity and reserves policy
2. 1 Objectives
Zero cash gaps on critical payment rails.
Minimum cost of ownership of liquidity (fees, FX, lost revenue).
Regulatory compliance: safeguarding, segregation of client funds (where applicable).
Transparency: daily reconciliation and dashboards by SLO.
2. 2 Reserve class
1. Operating reserve (OpRes) - coverage of payout peak and settlement variability (for example, p99 daily net output + 20-30% buffer).
2. Regulatory reserve (RegRes) - the amounts required by the license (segregated, safeguarding, ring-fencing).
3. Stress reserve (StressRes) - covering rare shocks: "double" peak output, T + N delay in key PSP, FX shock.
4. Technical reserve (TechRes) - for a feiler/incidents (freezing of a site/exchange/bank).
2. 3 Target Balance Pocket Formula
Target_Balance = OpRes(p99 horizon H) + RegRes + StressRes - Incoming_Settlement(T_window)Horizon H and window T_window depend on the rail (e.g. RTP H = 1d, Card H = 3d).
3) Cash flow forecasting
3. 1 Entrance rows
Deposits by method/provider (p7/p30 seasonality, days of the week, promotions).
Withdrawals & Payouts (speed and share to deposits, VIP/jackpots).
Settlement schedules (T + N by PSP/acquirers).
FX calendar (revaluations, large conversions).
Operating payments (taxes, commissions, salaries).
3. 2 Model (minimum)
Locally weighted or SARIMA/Prophet for depot/leads.
Applied coefficients: 'Cash-out Rate', 'Jackpot Probability', 'Promo Lift'.
Net pocket position: 'Inflow _ psp _ settlement − Outflow_payouts ± Sweeps'.
3. 3 Forecast Quality Metrics
MAPE/WAPE by daily net.
Coverage: proportion of days when the actual peak ≤ the planned OpRes.
Stockout Incidents: times when L0 is gone <minimum threshold.
4) Prefunding, sweeps and replenishment rules
4. 1 Prefunding (rail prepayment)
For instant payout rails and some APMs, balance is required.
Rule: maintain a rolling threshold (for example, p95 daily payments of the last week) + 20% buffer.
Auto-completion triggers are'Balance <LowWatermark '→' TopUp to Target_Balance'.
4. 2 Sweeps
Daily: PSP_MERCHANT → Bank_OPS after the settlement window.
Intraday: L0↔L1 for deviations from target corridors.
Towards L2: night sweep of excess residues in MMF/T-Bills/stables (return policy in L0 ≤ T + 1).
4. 3 Spending priorities (waterfall)
1. Payout_Pools (T0 commitment)
2. Fixed Deadline Treasury Payments (Tax/Salary)
3. FX conversions/rebalances
4. Investments L2/L3
5) Currencies, FX and interest rate environment
FX exposure: balance of incoming/outgoing by currencies; natural hedge (maintain payouts in the same currency).
Conversion policy: TWAP/POV alert for large amounts, limits on slippage bps, idempotent exec-id.
L2 interest yield: MMF/short T-bills; restrictions on counterparties and minimum liquidity (T + 0/T + 1).
SLO FX conversions: time from decision to execution (p95 ≤ X minutes), journalization of quotes.
6) Counterparty risk and limits
Limits on the counterparty: bank, PSP, crypto-custom, exchange/UTS.
Rating matrix: capital/licenses/incidents/availability/Proof-of-Reserves (for crypto).
Diversification: at least 2-3 providers per critical rail, distribution of residues across clusters.
Custody policy: multisig/HSM, output limits, address allow lists, daily reconciliations.
7) Regulatory and compliance aspects
Safeguarding/segregation: separate accounts for client funds (where required), balance tracking, no mixing.
Reporting: daily reports to the regulator/audit on balances and reserves.
KYC/AML: on/off-ramp counterparties, sanction screening, SoF/SoW for large transfers.
DSAR/retention: storage of payment traces and transfer logs.
8) Metrics, SLOs and alerts
8. 1 KPI
Time-to-Payout (TtP) p95 by method.
Time-to-Fund (TtF) p95 for pool replenishment.
Stockout Rate L0 (instantaneous liquidity shortage incidents).
Cash Utilization = Payouts from L0/ Target_Balance.
Idle Cash% = (Balance − Target_Balance )/Balance.
Counterparty Concentration = max (share by provider).
FX Slippage bps, FX Cost/GGR.
Safeguard Coverage = min (segregated account balance/required amount).
8. 2 Alerts
'Balance <LowWatermark '→ P1 (auto-completion).
'Stockout Incident '→ P0.
'Counterparty Concentration> limit '→ P2 (rebalance).
`Safeguard Coverage < 100%` → P0.
'TtF p95> SLO '→ P1 (bank/PSP incident).
9) Data model (treasury "layer")
json
{
"as_of": "2025-11-03T12:00:00Z",
"pocket_id": "PSP_MERCHANT_CARD_A",
"currency": "EUR",
"balance": 425000. 00,
"target_balance": 380000. 00,
"low_watermark": 300000. 00,
"inflows_t0": 52000. 00,
"outflows_t0": 61000. 00,
"expected_settlement_t1": 210000. 00,
"safeguard_required": 150000. 00,
"safeguard_balance": 160000. 00,
"counterparty": "Acquirer_A",
"limits": {
"counterparty_limit": 1200000. 00,
"fx_slippage_bps_limit": 5
},
"alerts": ["BALANCE_BELOW_TARGET"],
"notes": "Expect promo cash-out spike tonight"
}
date, pocket_id, counterparty, currency,
balance, target_balance, low_watermark,
inflows_t0, outflows_t0, expected_settlement_t1,
safeguard_required, safeguard_balance,
payout_slo_p95_sec, fund_slo_p95_sec10) SQL slices
10. 1 Movement of residues and entry into corridors
sql
SELECT date,
pocket_id,
currency,
balance,
target_balance,
low_watermark,
CASE WHEN balance < low_watermark THEN 1 ELSE 0 END AS stockout_flag,
GREATEST(0, balance - target_balance) AS idle_cash
FROM treasury_balances_daily
ORDER BY date DESC, pocket_id;10. 2 Concentration by counterparties
sql
SELECT date,
counterparty,
SUM(balance) AS bal,
SUM(SUM(balance)) OVER (PARTITION BY date) AS bal_total,
(SUM(balance) / NULLIF(SUM(SUM(balance)) OVER (PARTITION BY date),0)) AS share
FROM treasury_balances_daily
GROUP BY 1,2
ORDER BY date DESC, share DESC;10. 3 Safeguarding coverage
sql
SELECT date, pocket_id, currency,
safeguard_balance, safeguard_required,
safeguard_balance / NULLIF(safeguard_required,0) AS coverage_ratio
FROM treasury_balances_daily
WHERE safeguard_required > 0;11) Dashboard (minimal widgets)
1. Heatmap pockets: 'balance vs target vs low_watermark'.
2. Cash funnel: 'inflows/outflows/settlements' by day.
3. TtP/TtF p50/p95 by method/provider.
4. Counterparty concentration and alerts.
5. Safeguard coverage: 100% line, violations.
6. FX panel: slippage/cost, large conversions.
12) Playbooks
Cash-out wave
Actions: increase the Target_Balance in the Payout_Pools, speed up the sweep of the PSP→Bank_OPS, temporarily reduce the withdrawal limits for high-risk, include a second instant payout provider.
PSP settlement delay
Actions: activate StressRes, open a credit line/overdraft, temporarily redistribute payments to an alternative rail, escalation to PSP.
Bank/Exchange/Custom Freeze
Actions: kill-switch transfers, transfer of balances to alternative counterparties, launch of a DR plan, revocation of keys/accesses, communication with the regulator.
FX shock/overfulfilled demand in currency
Actions: include a straight hedge (payouts in the same currency), accelerated TWAP, redistribute shares/bonuses in the "home" currency.
Lack of safeguard coverage
Actions: immediate sweep of funds to a segregated account, blocking of optional payments, report and confirmation to the regulator.
13) Test cases (UAT/Prod-ready)
1. Stockout drill: simulate a peak payout of p99 → pool L0 remains ≥ low_watermark.
2. PSP settlement delay: + 2 days to T + N → StressRes covers, TtP does not go beyond SLO.
3. FX TWAP idempotency: repeat webhook quotes → 1 performance.
4. Safeguard breach: automatic sweep and blocking of non-critical payments.
5. Counterparty cap: exceeding the limit on the provider → alert + auto-rebalance.
6. Intraday sweep: balance> Target_Balance + δ → sweep in L2 and threshold return.
14) Frequent mistakes and how to avoid them
One provider on a critical rail → the absence of a feilover. Keep at least two.
Lack of p-level in OpRes → reserves "by eye" and frequent stockout. Use p95/p99.
Unmarked safeguard accounts → mixing funds. Enter strict segregation and reporting.
Ignoring settlement calendar → incorrect target balances. Automate the ingestion of PSP schedules.
A simple cache in the L0/L1 → a high cost of lost revenue. Set up sweeps in L2.
There is no single "register of pockets" → chaos of remnants. Type Pocket Registry.
15) Pocket Registry (API sketch)
json
{
"pocket_id": "PAYOUT_POOL_EUR",
"type": "L0",
"counterparty": "Bank_X",
"currency": "EUR",
"segregated": false,
"prefund_required": true,
"slo": { "ttp_p95_sec": 60, "ttf_p95_min": 30 },
"limits": {
"low_watermark": 200000,
"target_balance": 350000,
"counterparty_limit": 1000000
},
"sweep_policy": {
"to_l2_when_idle_cash_over": 100000,
"intraday": true
}
}Summary
Sustainable Treasury is a system, not a set of accounts: stratified liquidity levels (L0-L3), managed reserves (OpRes/RegRes/StressRes), tight limits and SLOs, flow forecasting, and automatic prefunding/sweep mechanics. So you give the business a minimum TtP, avoid cash gaps, reduce the cost of capital and at the same time comply with regulatory and audit requirements.