Trésorerie : liquidités et réserves

TL; DR

Le Trésor d'iGaming est un réseau géré de « poches » de liquidités (banques, PSP, portefeuilles, crypto-castodi, comptes merchants) avec différents SLA d'entrée/sortie. L'objectif est de réduire les écarts de trésorerie à un coût minimum : prévision précise des flux, limites des contreparties et des monnaies, politique de réserve (tampons opérationnels + safeguarding réglementaire + réserve de stress), discipline du prefunding et des règles de sweep, SLO sur Time-to-Payout et Time-to-Fund.

1) Carte de liquidité : niveaux, poches, flux

1. 1 Niveaux de liquidité (par disponibilité)

L0 (T0) - liquidités instantanées : soldes d'exploitation sur les comptes merchant, instant A2A/RTP, portefeuilles, réserves de stable, tampons de trésorerie pour payout T0.
L1 (T + 1... T + 3) - liquidité à horizon court : comptes de règlement PSP/acquéreurs, comptes courants bancaires avec des limites intrajournalières.
La L2 (T + 5... T + 10) est la liquidité de l'horizon moyen : comptes de dépôt/épargne, sweeps en instruments de trésorerie (T-bills, MMF), « parking » des stebls en castodi avec une rapide off-ramp.
L3 (T + 10 +) - liquidité/capital stratégique : dépôts longs, obligations, capital réservé.

1. 2 Poches de liquidité (exemple)

Bank_OPS (banque d'exploitation) : entrée/sortie fiat, salaire, impôts.
PSP_MERCHANT : comptes merchant par méthode (Card, A2A, Wallet).
PSP_SETTLEMENT : comptes de règlement/accumulateurs (T + N).
CRYPTO_CUSTODY : Il-chaine/castodi, stables et actifs sous-jacents.
PAYOUT_POOLS : pools distincts pour les paiements instantanés.
SAFEGUARD_ACCOUNTS : Comptes séparés selon les exigences du régulateur/permis.

1. 3 Principaux flux

`Deposits → PSP_MERCHANT → Settlement → Bank_OPS`

`Bank_OPS → Payout_Pools/PSP → Withdrawals`

`On/Off-ramp ↔ Crypto_Custody`

« Sweeps : L0↔L1↔L2 » programmé et déclencheur.

2) Politique de liquidités et de réserves

2. 1 Objectifs

Zéro rupture de trésorerie sur les rails de paiement critiques.
Coût minimum de possession de liquidités (commissions, FX, manque à gagner).
Conformité à la réglementation : safeguarding, ségrégation des fonds clients (le cas échéant).
Transparence : rapprochement quotidien et dashboards par SLO.

2. 2 Classe de réserves

1. La réserve opérationnelle (OpRes) est la couverture du pic de payout et de la variabilité du settlement (par exemple, p99 sortie nette journalière + tampon 20-30 %).
2. Réserve réglementaire (RegRes) - montants requis par la licence (segregated, safeguarding, ring-fencing).
3. La réserve de stress (StressRes) est une couverture de chocs rares : sortie de pointe « double », retard T + N pour le PSP clé, choc FX.
4. Réserve technique (TechRes) - pour les faussaires/incidents (gel du site/bourse/banque).

2. 3 La formule du résidu cible est abordable

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

L'horizon H et la fenêtre de T_window dépendent du rail (par exemple RTP H = 1d, Card H = 3d).

3) Prévision des flux de trésorerie

3. 1 Rangées d'entrée

Deposits by method/provider (saison p7/p30, jours de la semaine, promotions).
Withdrawals & Payouts (vitesse et part aux dépôts, VIP/jackpots).
Settlement schedules (T + N par PSP/Équaiers).
Calendrier FX (réévaluations, grandes conversions).
Paiements opérationnels (impôts, commissions, salaires).

3. 2 Modèle (minimum)

Pondéré localement ou SARIMA/Prophet pour les dépôts/retraits.
Coefficients d'application : 'Cash-out Rate', 'Jackpot Probability', 'Promo Lift'.
Position nette par poche : 'Inflow _ psp _ settlement − Outflow_payouts ± Sweeps'.

3. 3 Mesures de la qualité des prévisions

MAPE/WAPE daily net.
Coverage : proportion des jours où le pic réel est ≤ à l'OpRes planifié.
Stockout Incidents : fois que L0 est parti <seuil minimum.

4) Prefunding, sweeps et règles de recharge

4. 1 Prefunding (prépaiement des rails)

Pour les rails de paiement instantané et certains APM, un équilibre est nécessaire.
Règle : maintenir le seuil de roulement (par exemple, p95 paiements journaliers de la dernière semaine) + tampon de 20 %.
Déclencheurs de remplissage automatique : 'Balance <LowWatermark' → 'TopUp to Target_Balance'.

4. 2 Sweeps (traductions swip)

Quotidien : PSP_MERCHANT → Bank_OPS après le settlement de la fenêtre.
Intraday : L0↔L1 en cas de déviation par rapport aux couloirs cibles.
Vers L2 : balayage nocturne des résidus excédentaires en MMF/T-Bills/stebls (politique de retour en L0 ≤ T + 1).

4. 3 Priorités de dépenses (waterfall)

1. Payout_Pools (engagements T0)

2. Paiements au Trésor à échéance fixe (impôts/salaires)

3. Conversions/rebalance FX

4. Investissement L2/L3

5) Devises, FX et environnement de pourcentage

Exposition FX : solde des devises entrantes/sortantes ; hedge naturel (maintenir les paiements dans la même monnaie).
Politique de conversion : TWAP/POV-algo pour les sommes importantes, limites sur le slippage bps, idempotent exec-id.
Pourcentage de rendement L2 : MMF/T-bills courts ; restrictions sur les contreparties et liquidité minimale (T + 0/T + 1).
Conversions SLO FX : temps de la décision à l'exécution (p95 ≤ X minutes), journalisation des cotations.

6) Risque de contrepartie et limites

Limites par contrepartie : banque, PSP, crypto-castodi, bourse/OTS.
Matrice de notation : capital/licences/incidents/disponibilité/Proof-of-Reserves (pour crypto).
Diversification : minimum 2-3 fournisseurs par rail critique, répartition des résidus par grappe.
Custody-policy : multisig/HSM, limites de sortie, listes d'adresses, rapprochements quotidiens.

7) Aspects réglementaires et de conformité

Safeguarding/segmentation : comptes séparés pour les fonds clients (si nécessaire), suivi des bilans, interdiction de mélange.
Rapports : rapports quotidiens à l'organisme de réglementation/vérification des soldes et des réserves.
KYC/AML : contreparties sur/off-ramp, contrôle des sanctions, SoF/SoW pour les transferts importants.
DSAR/retraite : stockage des traces de paiement et des journaux de transfert.

8) Métriques, SLO et alertes

8. 1 KPI

Time-to-Payout (TtP) p95 par méthodes.
Time-to-Fund (TtF) p95 pour les recharges de pools.
Stockout Rate L0 (incidents de manque de liquidités instantanées).
Utilisation de Cash = Paiements de L0/ Target_Balance.
Idle Cash % = (Solde − Target_Balance )/Solde.
Concentration de counterparty = max (part du fournisseur).
FX Slippage bps, FX Cost/GGR.
Safeguard Coverage = min (solde des comptes ségrégés/montant requis).

8. 2 Alert

Balance <LowWatermark '→ P1 (auto-remplissage).
« Stockout Incident » → P0 (bloc de paiement instantané/activation de l'alternative).
'Counterparty Concentration> limite' → P2 (rebalance).
`Safeguard Coverage < 100%` → P0.
'TtF p95> SLO '→ P1 (incident de la banque/PSP).

9) Modèle de données (« couche » du Trésor)

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) tranches SQL

10. 1 Mouvement des résidus et pénétration dans les couloirs

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 par contrepartie

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 Couverture 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 (widgets minimaux)

1. Poches Heatmap : 'balance vs target vs low_watermark'.
2. Vortex de caisse : 'inflows/outflows/settlements' par jour.
3. TtP/TtF p50/p95 sur les méthodes/fournisseurs.
4. Counterparty concentration et alertes.
5. Safeguard coverage : 100 % -linium, irrégularités.
6. Panneau FX : slippage/coût, grandes conversions.

12) Pleybooks

Sursaut de conclusions (cash-out wave)

Actions : augmenter le Target_Balance en Payout_Pools, accélérer le balayage des PSP→Bank_OPS, abaisser temporairement les limites de sortie pour le risque élevé, activer le deuxième fournisseur de paiement instantané.

Retard d'installation chez PSP

Actions : activer StressRes, ouvrir une ligne de crédit/découverte, réaffecter temporairement les paiements sur un rail alternatif, escalade dans le PSP.

Gel de la banque/bourse/castodi

Actions : transferts de kill-switch, transfert des soldes vers des contreparties alternatives, lancement d'un plan DR, retrait des clés/accès, communication avec le régulateur.

Choc FX/demande dépassée en devises

Actions : inclure le hedge hétéro (paiements dans la même monnaie) accéléré par le TWAP, redistribuer les actions/bonus dans la monnaie « maison ».

Manque de revêtement safeguard

Actions : balayage immédiat des fonds sur un compte séparé, blocage des paiements facultatifs, rapport et confirmation au régulateur.

13) Cas de test (UAT/Prod)

1. Stockout drill : simuler le pic de paiement p99 → le pool L0 reste ≥ low_watermark.
2. PSP settlement delay : + 2 jours à T + N → StressRes couvre, TtP ne dépasse pas SLO.
3. FX TWAP idempotence : répétition du webhook de cotation → 1 exécution.
4. Safeguard breach : balayage automatique et blocage des paiements non critiques.
5. Counterparty cap : dépassement de la limite du fournisseur → alert + auto-rebalance.
6. Intraday sweep : équilibre> Target_Balance + δ → sweep en L2 et retour au seuil.

14) Erreurs fréquentes et comment les éviter

Un fournisseur par rail critique → l'absence de faussaire. Gardez au moins deux.
L'absence de niveau p dans OpRes → des réserves par œil et des stocks fréquents. Appliquer p95/p99.
Comptes safeguard non marqués → mélange de fonds. Entrez la ségrégation stricte et la déclaration.
Ignorer le calendrier settlement → les résidus cibles incorrects. Automatisez l'ingestion des horaires PSP.
Cache simple L0/L1 → coût élevé du manque à gagner. Réglez les sweeps en L2.
Il n'y a pas de « registre des poches » → le chaos des résidus. Entrez le registre Pocket.

15) Registre des poches (Pocket Registry, croquis API)

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
}
}

Résumé

La trésorerie durable est un système et non un ensemble de comptes : niveaux de liquidité stratifiés (L0-L3), réserves gérées (OpRes/RegRes/StressRes), limites strictes et SLO, prévision des flux et prefunding/sweep-mechanics automatiques. C'est ainsi que vous donnez aux entreprises un minimum de TtP, évitez les coupures de trésorerie, réduisez le coût du capital et répondez en même temps aux exigences des régulateurs et de l'audit.