Treasury: Liquidität und Reserven
TL; DR
Treasury in iGaming ist ein verwaltetes Netzwerk von Liquiditätstaschen (Banken, PSPs, Wallets, Krypto-Depots, Merchant-Konten) mit unterschiedlichen SLAs pro Input/Output. Das Ziel sind Null-Bargeldlücken bei minimalen Kosten: eine genaue Prognose der Ströme, Grenzen für Kontrahenten und Währungen, Reservepolitik (operative Puffer + regulatorisches Safeguarding + Stressreserve), die Disziplin der Präfundierung und Sweep-Regeln, SLO nach Time-to-Payout und Time-to-Fund.
1) Liquiditätskarte: Ebenen, Taschen, Ströme
1. 1 Liquiditätsniveaus (nach Verfügbarkeit)
L0 (T0) - sofortige Liquidität: Betriebsguthaben auf Merchant-Konten, Instant A2A/RTP, Wallets, Stable-Reserven, Cash-Puffer für Payout T0.
L1 (T + 1... T + 3) - Liquidität des kurzen Horizonts: PSP/Acquirer Girokonten, Bankgirokonten mit Intraday-Limits.
L2 (T + 5... T + 10) - Midhorizont-Liquidität: Einlagen-/Sparkonten, Swips in Treasury-Instrumente (T-Bills, MMF), „Parken“ von Stables auf einem Depot mit schnellem Off-Ramp.
L3 (T + 10 +) - strategische Liquidität/Kapital: lange Einlagen, Anleihen, reserviertes Kapital.
1. 2 Liquiditätstaschen (Beispiel)
Bank_OPS (Betriebsbank): Ein-/Ausgang Fiat, Gehalt, Steuern.
PSP_MERCHANT: Merchant-Konten nach Methoden (Card, A2A, Wallet).
PSP_SETTLEMENT: Abrechnungs-/Akkumulationskonten (T + N).
CRYPTO_CUSTODY: On-Chain/Depots, Stables und Basiswerte.
PAYOUT_POOLS: separate Pools für sofortige Auszahlungen.
SAFEGUARD_ACCOUNTS: getrennte Konten gemäß den Anforderungen der Regulierungsbehörde/Lizenz.
1. 3 Hauptströme
`Deposits → PSP_MERCHANT → Settlement → Bank_OPS`
`Bank_OPS → Payout_Pools/PSP → Withdrawals`
`On/Off-ramp ↔ Crypto_Custody`
'Sweeps: L0↔L1↔L2' nach Zeitplan und Triggern.
2) Liquiditäts- und Reservepolitik
2. 1 Ziele
Null Kassenbrüche auf kritischen Auszahlungsschienen.
Mindestkosten für den Besitz von Liquidität (Provisionen, FX, entgangene Einnahmen).
Compliance: Safeguarding, Segregation von Kundengeldern (falls zutreffend).
Transparenz: täglicher Abgleich und Dashboards nach SLO.
2. 2 Reserveklasse
1. Operational Reserve (OpRes) - Abdeckung des Payout-Peaks und der Settlement-Variabilität (z.B. p99 täglicher Netto-Output + 20-30% Puffer).
2. Regulatorische Reserve (RegRes) - die von der Lizenz geforderten Beträge (segregated, safeguarding, ring-fencing).
3. Stress-Reserve (StressRes) - Abdeckung seltener Schocks: „doppelter“ Peak-Output, T + N-Latenz bei Schlüssel-PSP, FX-Schock.
4. Technische Reserve (TechRes) - für Failover/Vorfälle (Einfrieren des Standorts/der Börse/der Bank).
2. 3 Die Formel für den Zielsaldo ist erschwinglich
Target_Balance = OpRes(p99 horizon H) + RegRes + StressRes - Incoming_Settlement(T_window)Horizont H und Fenster sind T_window schienenabhängig (z.B. RTP H = 1d, Card H = 3d).
3) Prognose der Geldflüsse
3. 1 Eingangsreihen
Deposits nach Methode/Anbieter (p7/p30 Saisonalität, Wochentage, Aktionen).
Withdrawals & Payouts (Geschwindigkeit und Anteil an Einzahlungen, VIP/Jackpots).
Settlement Schedules (T + N durch PSP/Acquirer).
FX-Kalender (Neubewertungen, große Umrechnungen).
Betriebszahlungen (Steuern, Provisionen, Gehälter).
3. 2 Modell (Minimum)
Lokal gewichtet oder SARIMA/Prophet für Depot/Pins.
Angewandte Koeffizienten: „Cash-out Rate“, „Jackpot Probability“, „Promo Lift“.
Nettoposition in der Tasche: "Inflow _ psp _ settlement − Outflow_payouts ± Sweeps'.
3. 3 Prognosequalitätsmetriken
MAPE/WAPE auf Tagesnettobasis.
Coverage: Der Anteil der Tage, an denen der tatsächliche Peak den geplanten OpRes ≤.
Stockout Incidents: Zeiten, in denen L0 <Mindestschwelle verlassen hat.
4) Vorbereitung, Sweeps und Nachschubregeln
4. 1 Vorbereitung (Vorauszahlung der Schienen)
Für Instant-Payout-Schienen und einige APMs ist eine Balance erforderlich.
Regel: Beibehaltung der Rolling-Schwelle (z. B. p95-Tagesauszahlungen der letzten Woche) + 20% Puffer.
Auslöser für die automatische Vervollständigung: "Balance <LowWatermark" → "TopUp to Target_Balance'.
4. 2 Sweeps (Swip-Übersetzungen)
Täglich: PSP_MERCHANT → Bank_OPS nach settlement Fenster.
Intradey: L0↔L1 bei Abweichungen von den Zielkorridoren.
In Richtung L2: nächtlicher Überschuss in MMF/T-Bills/Stables (Rückgaberecht in L0 ≤ T + 1).
4. 3 Ausgabenprioritäten (Wasserfall)
1. Payout_Pools (T0-Verpflichtungen)
2. Treasury Zahlungen mit fester Frist (Steuern/Gehalt)
3. Umrechnungen/Rebalance FX
4. Die Investition L2/L3
5) Währungen, FX und Zinsumfeld
FX-Exposition: Saldo der eingehenden/ausgehenden Währungen; Natural Hedge (Unterstützung von Auszahlungen in der gleichen Währung).
Konvertierungsrichtlinie: TWAP/POV-Algo für große Beträge, Limits für Slippage bps, idempotent exec-id.
L2 Zinserträge: MMF/Short T-Bills; Kontrahentenobergrenzen und Mindestliquidität (T + 0/T + 1).
SLO FX-Konvertierungen: Zeit von der Entscheidung bis zur Ausführung (p95 ≤ X Minuten), Notierungsjournalisierung.
6) Kontrahentenrisiko und -limits
Gegenparteilimits: Bank, PSP, Krypto-Depot, Börse/ÜNB.
Bewertungsmatrix: Kapital/Lizenzen/Vorfälle/Verfügbarkeit/Proof-of-Reserves (für Krypto).
Diversifikation: mindestens 2-3 Anbieter pro kritischer Schiene, Verteilung der Residuen auf Cluster.
Custody-Politik: multisig/HSM, Ausgabelimits, Adressenallow-Listen, tägliche Abstimmungen.
7) Regulatorische und Compliance-Aspekte
Safeguarding/Segregation: separate Konten für Kundengelder (falls erforderlich), Balance-Tracking, Mischverbot.
Berichterstattung: Tägliche Berichte an die Regulierungsbehörde/Prüfung von Salden und Reserven.
KYC/AML: On/Off-Ramp-Kontrahenten, Sanktionsscreening, SoF/SoW für große Transfers.
DSAR/retention: Speicherung von Zahlungsspuren und Überweisungsprotokollen.
8) Metriken, SLOs und Alerts
8. 1 KPI
Time-to-Payout (TtP) p95 nach Methoden.
Time-to-Fund (TtF) p95 für Poolauffüllungen.
Stockout Rate L0 (Vorfälle von Mangel an sofortiger Liquidität).
Cash Utilization = Auszahlung von L0/ Target_Balance.
Idle Cash% = (Gleichgewicht − Target_Balance )/Gleichgewicht.
Counterparty Concentration = max (Anteil nach Anbieter).
FX Slippage bps, FX Cost/GGR.
Safeguard Coverage = min (Saldo der getrennten Konten/erforderlicher Betrag).
8. 2 Alerts
„Balance <LowWatermark“ → P1 (automatische Vervollständigung).
' Stockout Incident ' → P0 (der Block der augenblicklichen Auszahlungen/Einschlüsse der Alternative).
„Counterparty Concentration“ → P2 (Rebalance).
`Safeguard Coverage < 100%` → P0.
„TtF p95> SLO“ → P1 (Zwischenfall bei der Bank/PSP).
9) Datenmodell (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-Schnitte
10. 1 Bewegung der Rückstände und Betreten der Flure
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 Konzentration nach Gegenparteien
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 Abdeckung
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 (minimale Widgets)
1. Heatmap Taschen: 'balance vs target vs low_watermark'.
2. Kassentrichter: 'inflows/outflows/settlements' am Tag.
3. TtP/TtF p50/p95 nach Methoden/Anbietern.
4. Counterparty-Konzentration und Alerts.
5. Safeguard Abdeckung: 100% -Linie, Verstöße.
6. FX-Panel: Slippage/Kosten, große Konvertierungen.
12) Playbooks
Lead-Burst (Cash-Out-Welle)
Aktionen: Erhöhen Sie die Target_Balance im Payout_Pools, beschleunigen Sie den PSP→Bank_OPS, senken Sie vorübergehend die Auszahlungslimits für High-Risk, aktivieren Sie den zweiten Instant-Payment-Anbieter.
Settlement-Verzögerung bei PSP
Aktionen: Aktivieren Sie StressRes, eröffnen Sie eine Kreditlinie/Überziehung, verteilen Sie Zahlungen vorübergehend auf eine alternative Schiene, eskalieren Sie in der PSP.
Einfrieren von Bank/Börse/Depot
Maßnahmen: Kill-Switch-Überweisungen, Übertragung von Salden auf alternative Gegenparteien, Einführung eines DR-Plans, Rückruf von Schlüsseln/Zugriffen, Kommunikation mit der Regulierungsbehörde.
FX-Schock/Übererfüllung der Nachfrage in Währungen
Aktionen: Einbeziehung von Hetero-Hedge (Auszahlungen in der gleichen Währung), beschleunigt durch TWAP, Umverteilung von Aktien/Boni in der „heimischen“ Währung.
Mangel an Safeguard-Abdeckung
Aktionen: Sofortüberweisung von Geldern auf ein segregiertes Konto, Sperrung optionaler Auszahlungen, Bericht und Bestätigung an die Regulierungsbehörde.
13) Testfälle (UAT/Prod-ready)
1. Stockout-Drill: Die Simulation des Auszahlungspeaks p99 → der L0-Pool bleibt ≥ low_watermark.
2. PSP settlement delay: + 2 Tage zu T + N → StressRes deckt, TtP geht nicht über SLO hinaus.
3. FX TWAP Idempotenz: Wiederholung des Webhook-Zitats → 1 Ausführung.
4. Safeguard breach: Automatischer Sweep und Blockierung von nicht-kritischen Zahlungen.
5. Counterparty Cap: Überschreitung der Grenze für den Anbieter → Alert + Auto-Rebalance.
6. Intraday Sweep: Balance> Target_Balance + δ → Sweep in L2 und Rückkehr an der Schwelle.
14) Häufige Fehler und wie man sie vermeidet
Ein Anbieter auf der kritischen Schiene → das Fehlen eines Failovers. Halten Sie mindestens zwei.
Das Fehlen eines p-Levels in OpRes → Reserven „pro Auge“ und häufiges Stockout. Verwenden Sie p95/p99.
Unmarkierte Safeguard-Konten → eine Mischung von Mitteln. Geben Sie strikte Segregation und Berichterstattung ein.
Settlement-Kalender ignorieren → falsche Ziel-Salden. Automatisieren Sie ingestion PSP-Zeitpläne.
Ein einfacher Cache im L0/L1 → hohe Kosten für verlorene Renditen. Richten Sie die Swips in L2 ein.
Es gibt kein einziges „Taschenregister“ → das Chaos der Reste. Geben Sie Pocket Registry ein.
15) Taschenregister (Pocket Registry, API-Skizze)
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
}
}Zusammenfassung
Nachhaltiges Treasury ist ein System, kein Kontenmix: geschichtete Liquiditätsniveaus (L0-L3), verwaltete Reserven (OpRes/RegRes/StressRes), enge Limits und SLOs, Flow Forecasting und automatische Prefunding/Sweep-Mechaniken. So geben Sie Ihrem Unternehmen ein Minimum an TtP, vermeiden Bargeldlücken, senken die Kapitalkosten und erfüllen gleichzeitig die Anforderungen von Aufsichtsbehörden und Audits.