Logo GH

Tesorería: liquidez y reservas

TL; DR

El Tesoro en iGaming es una red gestionada de «bolsillos» de liquidez (bancos, PSP, monederos, crypto castodies, cuentas merchant) con diferentes SLA para la entrada/salida. Objetivo: cero brechas de caja a un costo mínimo: pronóstico exacto de flujos, límites por contraparte y moneda, política de reservas (buffers operativos + safeguarding regulatorio + reserva de estrés), disciplina de prefundación y reglas de sweep, SLO por Tiempo-a-PO ayout y Time-to-Fund.

1) Mapa de liquidez: niveles, bolsillos, flujos

1. 1 Niveles de liquidez (por disponibilidad)

L0 (T0) - liquidez instantánea: saldos operativos en cuentas de merchant, A2A/RTP instant, carteras, reservas de stable, amortiguadores de efectivo para payout T0.
L1 (T + 1... T + 3) - liquidez de corto horizonte: cuentas de liquidación PSP/ecuador, cuentas corrientes bancarias con límites intradía.
L2 (T + 5... T + 10) es la liquidez del horizonte medio: cuentas de depósito/ahorro, barridos a instrumentos de tesorería (T-bills, MMF), 'parking' de stables en castodies con rápido off-ramp.
L3 (T + 10 +) - liquidez estratégica/capital: depósitos largos, bonos, capital reservado.

1. 2 Bolsillos de liquidez (ejemplo)

Bank_OPS (banco de operaciones): entrada/salida fiat, nómina, impuestos.
PSP_MERCHANT: cuentas de merchant por métodos (Card, A2A, Wallet).
PSP_SETTLEMENT: cuentas de liquidación/batería (T + N).
CRYPTO_CUSTODY: on-chain/castodi, stables y activos subyacentes.
PAYOUT_POOLS: grupos separados para pagos instantáneos.
SAFEGUARD_ACCOUNTS: cuentas segregadas según los requisitos del regulador/licencia.

1. 3 Hilos principales

`Deposits → PSP_MERCHANT → Settlement → Bank_OPS`

`Bank_OPS → Payout_Pools/PSP → Withdrawals`

`On/Off-ramp ↔ Crypto_Custody`

'Sweeps: L0↔L1↔L2' en horario y desencadenantes.

2) Política de liquidez y reservas

2. 1 Objetivos

Roturas de caja cero en raíles de pago críticos.
Coste mínimo de propiedad de liquidez (comisiones, FX, ingresos perdidos).
Cumplimiento de la normativa: safeguarding, segregación de los fondos de los clientes (si procede).
Transparencia: conciliación diaria de SLO y dashboards.

2. 2 Clase de reservas

1. Reserva operativa (OpRes): cubre el pico de pago y la variabilidad de settlement (por ejemplo, p99 salida neta diaria + búfer 20-30%).
2. La reserva reguladora (RegRes) es la cantidad requerida por la licencia (segregated, safeguarding, ring-fencing).
3. Reserva de estrés (StressRes): cobertura de choques raros: salida máxima «doble», retardo T + N en PSP clave, choque FX.
4. Reserva técnica (TechRes) - en Faklover/incidentes (congelación del sitio/intercambio/banco).

2. 3 Fórmula del residuo de destino en el bolsillo


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

El horizonte H y la ventana T_window dependen del raíl (por ejemplo, RTP H = 1d, Card H = 3d).

3) Predicción de los flujos de caja

3. 1 Filas de entrada

Depósitos por método/proveedor (estacionalidad p7/p30, días de la semana, promociones).
Withdrawals & Payouts (velocidad y participación en los depósitos, VIP/botes).
Schedules settlement (T + N según PSP/ecuador).
Calendario FX (revalorizaciones, grandes conversiones).
Pagos operativos (impuestos, comisiones, salarios).

3. 2 Modelo (mínimo)

Local-ponderado o SARIMA/Prophet para depósitos/pines.
Coeficientes de aplicación: 'Cash-out Rate', 'Jackpot Probability', 'Promo Lift'.
Posición neta por bolsillo: 'Inflow _ psp _ settlement − Outflow_payouts ± Sweeps'.

3. 3 Métricas de calidad de predicción

MAPE/WAPE por diario neto.
Coverage: la proporción de días en que el pico real ≤ el OpRes planeado.
Stockout Incidents: veces cuando L0 ha dejado <umbral mínimo.

4) Prefundación, sweeps y reglas de recarga

4. 1 Prefundación (prepago de rieles)

Los rieles instant payout y algunos APM requieren equilibrio.
Regla: mantener el umbral de desplazamiento (por ejemplo, los pagos por días p95 de la última semana) + buffer 20%.
Los desencadenantes de la autocomplacencia son: 'Balance <LowWatermark' → 'TopUp to Target_Balance'.

4. 2 Sweeps (traducciones de swip)

Diario: PSP_MERCHANT → Bank_OPS después de settlement de la ventana.
Intraday: L0↔L1 con desviaciones de los corredores de destino.
Hacia L2: barrido nocturno de residuos excedentes en MMF/T-Bills/stables (política de retorno en L0 ≤ T + 1).

4. 3 Prioridades de gasto (waterfall)

1. Payout_Pools (T0 obligaciones)

2. Pagos de tesorería de línea fija (impuestos/nómina)

3. Conversiones/rebalance FX

4. Inversión L2/L3

5) Monedas, FX y entorno de interés

Exposición FX: balance de divisas entrantes/salientes; hedge natural (mantener los pagos en la misma moneda).
Política de conversión: TWAP/POV-algo para grandes sumas, límites en slippage bps, idempotent exec-id.
Rendimiento porcentual de L2: MMF/facturas cortas de T; restricciones por contraparte y liquidez mínima (T + 0/T + 1).
SLO de conversión FX: tiempo desde la solución hasta la ejecución (p95 ≤ X minutos), registro de cotizaciones.

6) Riesgos y límites de contrapartida

Límites de contraparte: banco, PSP, cripto castodi, intercambio/OTS.
Matriz de calificación: capital/licencias/incidencias/disponibilidad/Proof-of-Reserves (para crypto).
Diversificación: mínimo de 2-3 proveedores por riel crítico, distribución de residuos por cluster.
Política de custodia: Multicig/HSM, límites de salida, listas de direcciones allow, conciliaciones diarias.

7) Aspectos regulatorios y de cumplimiento

Safeguarding/segregation: cuentas separadas para fondos del cliente (donde se requiere), balances de seguimiento, prohibición de mezcla.
Informes: informes diarios al regulador/auditoría de saldos y reservas.
KYC/AML: contrapartes on/off-ramp, cribado de sanciones, SoF/SoW para transferencias importantes.
DSAR/retention: almacenamiento de huellas de pago y registros de transferencia.

8) Métricas, SLO y alertas

8. 1 KPI

Time-to-Payout (TtP) p95 por métodos.
Tiempo-a-Fondo (TtF) p95 para reposiciones de grupos.
Stockout Rate L0 (incidentes de falta de liquidez instantánea).
Cash Utilization = Pagos de L0/ Target_Balance.
Idle Cash% = (Balance − Target_Balance )/Balance.
Counterparty Concentration = max (participación por proveedor).
FX Slippage bps, FX Cost/GGR.
Safeguard Coverage = min (balance de cuentas segregadas/cantidad requerida).

8. 2 Alertas

'Balance <LowWatermark' → P1 (ejecución automática).
'Stockout Incident' → P0 (bloque de pago instantáneo/inclusión de alternativa).
'Conterparty Concentration> limites' → P2 (rebalance).
`Safeguard Coverage < 100%` → P0.
'TtF p95> SLO' → P1 (incidente del banco/PSP).

9) Modelo de datos («capa» 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"
}
Capa de hecho plana (para BI):

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

10. 1 Movimiento de residuos y entrada en los pasillos

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 Concentración por contrapartida

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 Cobertura de 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 mínimos)

1. Heatmap bolsillos: 'balance vs target vs low_watermark'.
2. Embudo de caja: 'inflows/outflows/settlements' por día.
3. TtP/TtF p50/p95 por métodos/proveedores.
4. Conterparty concentración y alertas.
5. Safeguard coverage: 100% línea, infracciones.
6. Panel FX: slippage/costo, grandes conversiones.

12) Playbucks

Ráfaga de pines (onda cash-out)

Acciones: aumentar la Target_Balance en Payout_Pools, acelerar el barrido de PSP→Bank_OPS, reducir temporalmente los límites de salida para el alto riesgo, habilitar un segundo proveedor de pago instantáneo.

Retraso en la configuración de PSP

Acciones: activar StressRes, abrir una línea de crédito/sobregiro, reasignar temporalmente los pagos a un carril alternativo, escalar en PSP.

Congelación de bancos/intercambios/castodis

Acciones: transferencias de kill-switch, transferencia de saldos a contrapartes alternativas, lanzamiento de un plan de DR, retirada de claves/accesos, comunicación con el regulador.

FX-shock/demanda superada en divisas

Acciones: Incluir natural-hedge (pagos en la misma moneda), acelerado por TWAP, redistribuir promociones/bonos en la moneda «home».

Falta de cobertura safeguard

Acciones: transferencia inmediata de fondos a una cuenta segregada, bloqueo de pagos opcionales, informe y confirmación al regulador.

13) Casos de prueba (UAT/Prod-preparación)

1. Stockout drill: simular el pico de pago p99 → el grupo L0 permanece ≥ low_watermark.
2. PSP settlement delay: + 2 días a T + N → StressRes cubre, TtP no sale por SLO.
3. FX TWAP idempotencia: repetición de cotización webhook → 1 ejecución.
4. Safeguard breach: giro automático y bloqueo de pagos no críticos.
5. Counterparty cap: superando el límite del proveedor → alert + auto-rebalance.
6. Intraday sweep: balance> Target_Balance + δ → el barrido en L2 y el retorno en el umbral.

14) Errores frecuentes y cómo evitarlos

Un proveedor en un carril crítico → sin Feilover. Mantenga un mínimo de dos.
Falta de p-level en OpRes → reservas «a la vista» y stockout frecuente. Aplique p95/p99.
Cuentas safeguard sin etiquetar → mezcla de fondos. Introduzca una estricta segregación e informes.
Ignorar el calendario settlement → los residuos de destino incorrectos. Automatice la ingestión de las programaciones PSP.
Una simple caché en L0/L1 → un alto costo de rendimiento perdido. Configure los barridos en L2.
No hay un único «registro de bolsillos» → el caos de los remanentes. Escriba Pocket Registry.

15) Registro de bolsillos (Registro de bolsillos, boceto de 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
}
}

Resumen

Tesorería sostenible es un sistema, no un conjunto de cuentas: niveles de liquidez estratificados (L0-L3), reservas gestionadas (OpRes/RegRes/StressRes), límites rígidos y SLO, predicción de flujo y prefundación/sweep automáticos Los mecánicos. Así que le das al negocio un mínimo de TtP, evita las brechas de caja, reduce el costo del capital y al mismo tiempo cumple con los requisitos regulatorios y de auditoría.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Telegram
@Gamble_GC
Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.