Tesoro: liquidità e riserve

TL; DR

Il Tesoro nel iGaming è una rete gestita di «tasche» di liquidità (banche, PSP, portafogli, cripto-castodi, account merchant) con diversi SLA per l'input/output. Obiettivo: rotture di cassa zero a costi minimi: previsione dei flussi esatta, limiti per le controparti e le valute, politica di riserva (buffer operativi + safeguarding regolatori + riserva di stress), disciplina di prefering e regole sweep, SLO per Time-to-Payout e Time-to-Fund.

1) Scheda di liquidità: livelli, tasche, flussi

1. 1 Livelli di liquidità (disponibilità)

L0 (T0) - Liquidità immediata: saldi operativi sui conti merchant, instant A2A/RTP, portafogli, riserve stable, buffer in contanti per payout T0.
L1 (T + 1... T + 3) è la liquidità di un breve orizzonte: conti PSP/Equayer, conti correnti bancari con limiti intraday.
L2 (T + 5... T + 10) è la liquidità dell'orizzonte medio-alto: conti di deposito/risparmio, sweep in attrezzi del Tesoro (T-bills, MMF), «parcheggio» delle pile a castodi con veloce off-ramp.
L3 (T + 10 +) - liquidità strategica/capitale: depositi lunghi, obbligazioni, capitale riservato.

1. 2 Tasche di liquidità (esempio)

Banca _ OPS: ingresso/uscita della fiat, stipendi, tasse.
IP _ MERCHANT - Account merchant per metodi (Card, A2A, Wallet).
PSP _ SETTLEMENT - Conti di calcolo/accumulo (T + N).
CRYPTO _ CUSTODY: È-chain/castody, pile e beni di base.
PAYOUT _ POOLS - Pool separati per pagamenti immediati.
SAFEGUARD _ ACCOUNTS - Conti segregati in base ai requisiti di regolazione/licenza.

1. 3 Flussi principali

`Deposits → PSP_MERCHANT → Settlement → Bank_OPS`

`Bank_OPS → Payout_Pools/PSP → Withdrawals`

`On/Off-ramp ↔ Crypto_Custody`

«Sweeps: L0↔L1↔L2» pianificato e trigger.

2) Politica di liquidità e riserve

2. 1 Obiettivi

Rotture di cassa zero sui binari di pagamento critici.
Costo minimo di gestione della liquidità (commissione, FX, mancato guadagno).
Conformità regolatoria: safeguarding, segregazione dei prodotti client (se applicabile).
Trasparenza: incrociatura giornaliera e dashboard SLO.

2. Classe di riserva 2

1. La riserva operativa (OpRes) è la copertura del picco payout e della variabilità settlement (ad esempio p99 output netto diurno + buffer 20-30%).
2. Riserva di regolazione (RegRes) - gli importi richiesti dalla licenza (segregated, safeguarding, ring-fencing).
3. La riserva di stress (StressRes) è la copertura di shock rari: «doppio» output, ritardo T + N su PSP chiave, shock FX.
4. Riserva tecnica (TechRes) - su faulover/incidenti (congelamento sito/borsa/banca).

2. 3 Formula residuo target disponibile

Target_Balance = OpRes(p99 horizon H) + RegRes + StressRes - Incoming_Settlement(T_window)

L'orizzonte H e la finestra T _ window dipendono dal binario (ad esempio, RTP H = 1d, Card H = 3d).

3) Previsione dei flussi di cassa

3. 1 Righe di ingresso

Deposits by method/provider (p7/p30 stagionalità, giorni della settimana, promozioni).
Withdrawals & Payouts (velocità e quota di depositi, VIP/jackpot).
Settlement schedule (T + N per PSP/Equayers).
calendario FX (rivalutazioni, grandi conversioni).
Pagamenti operativi (tasse, commissioni, stipendi).

3. 2 Modello (minimo)

Locale ponderato o SARIMA/Prophet per deposito/conclusione.
Coefficienti applicativi: «Cash-out Rate», «Jackpot Probability», «Promo Lift».
La posizione netta è «Inflow _ psp _ settement - Outflow _ payouts © Sweeps».

3. 3 Metriche di qualità di previsione

MAPE/WAPE per daily netto.
Coverage è la percentuale di giorni in cui il picco effettivo è .
Stockout Incidents: una volta che L0 ha lasciato <soglia minima.

4) Prefering, sweeps e regole di rifornimento

4. 1 Prefering (pagamento anticipato dei binari)

I binari instant payout e alcuni APM richiedono un equilibrio.
Regola: mantenere la soglia rolling (ad esempio p95 pagamenti giornalieri dell'ultima settimana) + buffer 20%.
I trigger di completamento automatico sono Bilanciamento <LowWatermark '→' to Target _ TopUp.

4. 2 Sweeps (traduzioni swip)

Quotidiano: PSP _ MERCHANT → Bank _ OPS dopo il settement della finestra.
Intraday, L0↔L1 per le deviazioni dai corridoi di destinazione.
Verso L2: sweep notturno di residui in eccesso in MMF/T-Bills/bile (politica di ritorno a L0-T + 1).

4. 3 Priorità di spesa (waterfall)

1. Payout _ Pools (T0 obblighi)

2. Pagamenti del Tesoro con deadline fisso (tasse/stipendio)

3. Conversioni/ribalance FX

4. Investimento L2/L3

5) Valute, FX e ambiente di interesse

Esposizione FX: bilanciamento in entrata/uscita per valuta; hedge naturale (mantenere i pagamenti nella stessa valuta).
Criteri di conversione: TWAP/POV-algo per importi ingenti, limiti per slippage bps, idempotent exec-id.
Rendimento percentuale L2: MMF/brevi T-bills; restrizioni e liquidità minima (T + 0/T + 1).
Conversioni SLO FX: tempo dalla decisione all'esecuzione (p95 ≤ X minuti), registrazione della quotazione.

6) Rischio di contrattazione e limiti

I limiti per contractor sono banca, PSP, cripto-castodi, borsa/OTS.
Matrice di rating: capitale/licenze/incidenti/disponibilità/Proof-of-Reserves (per cripto).
Diversificazione: almeno 2-3 provider per binari critici, distribuzione dei residui per cluster.
Custody Policy: multisig/HSM, limiti di output, fogli di indirizzo, compressioni giornaliere.

7) Aspetti regolatori e complessi

Safeguarding/segregation: conti separati per i fondi client (dove richiesto), tracking dei bilanci, divieto di miscelazione.
Report: report giornalieri al regolatore/controllo dei saldi e delle riserve.
KYC/AML: on/off-ramp contractor, screening delle sanzioni, SoF/SoW per grandi traduzioni.
DSAR/retention - Memorizzazione delle tracce di pagamento e dei registri dei trasferimenti.

8) Metriche, SLO e alert

8. 1 KPI

Time-to-Payout (TtP) p95 per metodi.
Time-to-Fund (TtF) p95 per la sostituzione dei pool.
Stockout Rate L0 (incidenti di liquidità immediata).
Cash Utilization = Pagamenti da L0/Target _ Fortune.
Idle Cash% = (Saldo - Target _ Bilancia )/Saldo.
Counterparty Concertation = max (parte del provider).
FX Slippage bps, FX Cost/GGR.
Safeguard Coverage = min (saldo dei conti segregati/importo richiesto).

8. 2 Alert

LowWatermark <→ P1 (completamento automatico).
"Stockout Incident's P0 (Blocco pagamenti immediati/attivazione alternativa).
«Counterparty Concertation> limiti» → P2 (rebalance).
`Safeguard Coverage < 100%` → P0.
« p95> SLO» P1 (incidente alla banca/PSP).

9) Modello di dati (livello del Tesoro)

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_sec

10) Tagli SQL

10. 1 Movimento dei residui e ingresso nei corridoi

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 Concentrazione per controparti

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 Copertura safeguarding

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 (widget minimi)

1. Tasche Heatmap: 'balance vs target vs low _ watermark'.
2. Vortice di cassa: 'Inflows/outflows/settlements'.
3. TtP/TtF p50/p95 per metodi/provider.
4. Counterparty concertation e alert.
5. Safeguard coverage: 100% linea, violazioni.
6. Pannello FX: slippage/costo, grandi conversioni.

12) Playbook

Output (cash-out wave)

Azioni: aumenta Target _ Balance in Payout _ Pools, accelera il swip di PSP→Bank_OPS, riduce temporaneamente i limiti di output per l'high-risk, abilita il secondo provider di pagamenti instant.

Ritardo settlement su PSP

Azioni attivare il sistema, aprire una linea di credito/overdraft, riallocare temporaneamente i pagamenti su binari alternativi, escalation in PSP.

Congelamento banca/borsa/castodi

Azioni: kill-switch traduzioni, trasferimento dei saldi a controparti alternativi, avvio del piano DR, ritiro delle chiavi/disponibilità, comunicazione con il regolatore.

Shock FX/Richiesta valuta superata

Azioni: includere gli hedge etero (pagamenti nella stessa valuta) accelerati da TWAP, ridistribuire azioni/bonus in valuta «domestica».

Scarsa copertura safeguard

Azioni: versamento immediato di fondi per conto segregato, blocco dei pagamenti facoltativi, rapporto e conferma al regolatore.

13) Valigette di prova (UAT/Prod-pronto)

1. Stockout drill - Simulare il picco di pagamento p99 del pool L0 rimane low _ watermark.
2. PSP settlement delay: + 2 giorni a T + N copre, non SLO.
3. FX TWAP idimpotenza: ripetizione webhook quotato 1 esecuzione.
4. Safeguard breach: swip automatico e blocco dei pagamenti non critici.
5. Counterparty cap - Superamento del limite di fornitore di → + auto-ricalance.
6. Intraday sweep: bilanciamento> Target _ + lo swip in L2 e il ritorno alla soglia.

14) Errori frequenti e come evitarli

Un provider per un binario critico, senza un feelover. Tenetene almeno due.
L'assenza di un livello P nel OpRes → le riserve «a occhio» e i frequenti stockout. Applica p95/p99.
Conti safeguard immatricolati, miscelazione di fondi. Immettere segregazione e report rigorosi.
Ignorare il calendario settlement → i saldi di destinazione non validi. Automatizzare le pianificazioni PSP.
Una semplice cache in L0/L1 offre un costo elevato per la perdita di rendimento. Regolare i sweep in L2.
Non c'è un solo registro delle tasche per il caos dei residui. Immettere Pocket Registry.

15) Registro delle tasche (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
}
}

Riepilogo

Il Tesoro sostenibile è un sistema, non un insieme di fatture: livelli di liquidità stratificati (L0-L3), riserve gestite (OpRes/RegRes/StressRes), limiti rigidi e SLO, previsione dei flussi e preconfunding automatico/sweep-meccanica. In questo modo si dà alle imprese un minimo di tempo, si evitano le rotture di cassa, si riducono i costi di capitale e si soddisfano al contempo i requisiti dei regolatori e delle verifiche.