Time-to-Wallet: métrica clave

1) Definición y variantes de TTW

• TTW₍deposit ₎: 'clic «Pagar» → el dinero está disponible para el juego'.
• Incluye UX/3DS, autorización de PSP/banco, confirmación y registro de balance.

TTW₍payout ₎: 'clic «Retirar» → dinero en la cartera/banco externo'.
Incluye verificación risk/KYC/SoF, same-method/ND-gates, orquestación de pasillo, confirmación con PSP/diagrama y posting con banco/billetera.

2) ¿Por qué TTW es P & L-métrica

Conversión y AR: depósito rápido ↑ probabilidad de primera apuesta/sesión.
Retención y confianza: conclusiones rápidas ↓ churn y tickets de sapport.
Costo: instant-rails es a menudo más caro ⇒ necesita un equilibrio «velocidad ↔ precio».
Riesgo operativo: las largas «colas» de TTW crean clústeres de incidentes y tensión de chargeback.

3) Descomposición de TTW por etapas

3. 1. Depósitos

1. UI/Checkout (render, validación, 3DS)

2. PSP Auth (authorize)

3. Capture/Booking (confirmación, actualización del balance)

4. Fallback/Retry (при soft-decline)

`TTW₍deposit₎ = t_UI + t_3DS + t_auth + t_capture + t_write_balance`

3. 2. Conclusiones

1. Pre-cheques (KYC/SoF, ND/same-method, límites RG/AML)

2. Risk decision (auto/manual)

3. Orden de pago (selección del corredor: SEPA Instant/PIX/Faster Payments/RTP/push-to-card/A2A/e-wallet)

4. PSP API (initiate → accepted)

5. Network/Banks (clearing/posting)

6. Reconcile & Notify (confirmación al usuario)

`TTW₍payout₎ = t_precheck + t_risk + t_initiation + t_network + t_posting + t_notify`

4) Niveles de SLA y objetivos

Depósito p95: ≤ 10-20 segundos (monederos/one-tap), ≤ 30-60 segundos (tarjetas con 3DS).

• Instant rails (SEPA Instant/PIX/FPS/RTP, push-to-wallet/card): ≤ 15–30 мин.
• A2A/SEPA Credit estándar: T + 0/T + 1 banca (horas/día).
• SWIFT internacional: 1-3 días bancarios.
• p99 es importante mantenerse en las comunicaciones (bandas ETA) para gestionar las expectativas.

5) Medición: unidades, ventanas, sampling

Unidad de medida: transacción (depósito/pago).
Agregación: p50/p90/p95/p99, SLA-hit% (participación en ETA), colas (tail> 2 × p95).
Cortes: método/corredor/PSP/MID/GEO/clústeres BIN/hora del día/canal.
Excluimos: cancelados/duplicados (idempotencia), pausas manuales a petición del jugador.

6) Modelo de datos (mínimo)

sql payments. timeline (
tx_id PK, kind -- DEPOSIT    PAYOUT,
user_id, method, corridor, provider, mid, iso2, currency, amount_minor BIGINT,
t_ui_start TIMESTAMP, t_3ds_start TIMESTAMP, t_3ds_end TIMESTAMP,
t_auth_req TIMESTAMP, t_auth_ok TIMESTAMP,
t_capture_ok TIMESTAMP,     -- депозиты t_precheck_start TIMESTAMP, t_precheck_ok TIMESTAMP, -- выводы t_risk_start TIMESTAMP, t_risk_ok TIMESTAMP,
t_payout_initiated TIMESTAMP, t_network_posted TIMESTAMP,
t_wallet_available TIMESTAMP, -- final availability status TEXT, decline_code TEXT, meta JSONB
);

sla. catalog (
kind, method, corridor, geo, p95_target_seconds INT, p99_target_seconds INT, eta_text TEXT
);

7) Plantillas de cálculo SQL

7. 1. TTW por depósitos (general y por métodos)

sql
SELECT method,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_wallet_available - t_ui_start))) AS p95_ttw_sec,
PERCENTILE_CONT(0. 99) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_wallet_available - t_ui_start))) AS p99_ttw_sec,
COUNT() AS attempts,
100. 0 AVG((EXTRACT(EPOCH FROM (t_wallet_available - t_ui_start)) <= s. p95_target_seconds)::int) AS sla_hit_p95_pct
FROM payments. timeline t
JOIN sla. catalog s ON s. kind='DEPOSIT' AND s. method=t. method
WHERE t. kind='DEPOSIT'
AND t. status='SUCCESS'
AND t. t_ui_start BETWEEN:from AND:to
GROUP BY 1;

7. 2. TTW por conclusiones (corredores)

sql
SELECT corridor,
PERCENTILE_CONT(0. 50) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_wallet_available - t_precheck_start))) AS p50_sec,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_wallet_available - t_precheck_start))) AS p95_sec,
PERCENTILE_CONT(0. 99) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_wallet_available - t_precheck_start))) AS p99_sec,
100. 0 AVG((EXTRACT(EPOCH FROM (t_wallet_available - t_precheck_start)) <= s. p95_target_seconds)::int) AS sla_hit_p95_pct,
COUNT() AS payouts
FROM payments. timeline t
JOIN sla. catalog s ON s. kind='PAYOUT' AND s. corridor=t. corridor
WHERE t. kind='PAYOUT' AND t. status='SUCCESS'
AND t. t_precheck_start BETWEEN:from AND:to
GROUP BY 1;

7. 3. Descomposición de «cuellos de botella» (conclusiones)

sql
SELECT corridor,
AVG(EXTRACT(EPOCH FROM (t_precheck_ok - t_precheck_start))) AS precheck_sec,
AVG(EXTRACT(EPOCH FROM (t_risk_ok - t_risk_start)))     AS risk_sec,
AVG(EXTRACT(EPOCH FROM (t_network_posted - t_payout_initiated))) AS network_sec,
AVG(EXTRACT(EPOCH FROM (t_wallet_available - t_network_posted))) AS posting_sec
FROM payments. timeline
WHERE kind='PAYOUT' AND status='SUCCESS'
AND t_precheck_start BETWEEN:from AND:to
GROUP BY 1
ORDER BY network_sec DESC;

7. 4. SLA-brichi y «colas largas»

sql
SELECT method, corridor,
COUNT() FILTER (WHERE EXTRACT(EPOCH FROM (t_wallet_available - COALESCE(t_ui_start, t_precheck_start))) > s. p95_target_seconds) AS breaches,
COUNT() AS total,
100. 0 COUNT() FILTER (WHERE EXTRACT(EPOCH FROM (t_wallet_available - COALESCE(t_ui_start, t_precheck_start))) > s. p95_target_seconds)
/ NULLIF(COUNT(),0) AS breach_pct
FROM payments. timeline t
JOIN sla. catalog s ON s. kind=t. kind AND COALESCE(s. method, t. method)=t. method AND COALESCE(s. corridor, t. corridor)=t. corridor
WHERE t. status='SUCCESS' AND (t. t_ui_start BETWEEN:from AND:to OR t. t_precheck_start BETWEEN:from AND:to)
GROUP BY 1,2
ORDER BY breach_pct DESC;

8) Dashboards y KPI

TTW p50/p95/p99 por métodos/corredores/PSP/GEO/BIN-cluster.
SLA-hit%, tail share (> 2 × p95), incidentes (anotaciones).
Embudo de salida: Requested → Pre-check OK → Risk OK → Initiated → Posted → Available.
Correlaciones: TTW vs AR/conversión de depósito, TTW vs tickets sapport/CSAT, TTW vs churn.
Costo: 'cost _ per _ payout' y 'take-rate' por el pasillo vs ganar por TTW.

9) Alertas

p95 breach: p95 TTW en el corredor/PSP> SLA X minutos.
Tail spike: share> 2 × p95 creció> Y% en horas Z.
Pre-check stall: t_precheck_start hay t_precheck_ok no> 15 min (auto-escalada).
Risk backlog: t_risk_start hay t_risk_ok no> umbral (cola manual).
Network/posting anomaly: el fuerte crecimiento de 'network _ sec' por GEO/banco.
Policy drift: eventos sin las etiquetas de tiempo necesarias.

10) Cómo acelerar el TTW (prácticas)

Depósitos

Monederos One-tap/Apple Pay/Google Pay, tokens de red.
Frictionless 3DS por riesgo, incrustando 3DS en el modal.
Cascada PSP por BIN/GEO/salud, retrés sólo en soft-decline.
Prefetch 3DS/ACS canales, tiempos de espera agresivos en la degradación.

Conclusiones

Pre-KYC/pre-SoF para jugadores frecuentes; pre-approval por las cantidades de ≤ umbral.
Corredores de instantes: SEPA Instant/Faster Payments/RTP/PIX/push-to-card/wallet.
Cascada de corredores: instant → fast A2A → estándar SEPA/SWIFT (con ETA).
Same-method & ND-lógica automatizada, sin controles manuales.
Ventanas temporales: evite el cut-off y los relojes bancarios «estrechos».
Provider health-feed y auto-failover cuando 'network _ sec' crece.

Comunicaciones

ETA al inicio + progreso-estados («Verificación», «Iniciado», «Acreditado»).
Alertas proactivas en retrasos> SLA, causas honestas y tiempo esperado.

11) La economía y los compromisos

Instant cuesta más: compara uplift CSAT/churn/retention vs bps/fixed.
Las colas son más caras que las p50: las optimizaciones en p95 producen un efecto P&L mayor.
Diferencias locales: en algunos GEO, el canal «rápido pero caro» paga mejor.

12) Incidente de playbucks

1. Crecimiento p95 por PSP/corredor específico

Auto-reroute en el corredor de reserva, reducción del límite en el degradante.
Comunicación a jugadores con ETA actualizada, ticket al proveedor.

2. Risk backlog (controles manuales)

Habilitar pre-approval en sumas ≤ X, redistribuir la cola, elevar temporalmente los umbrales auto-pass.

3. Banco posting retrasos en GEO

Eludir con otro banco/billetera correspondiente, desconectar temporalmente el pasillo «lento» para nuevas solicitudes.

4. Degradación 3DS/ACS (depósitos)

Forzar frictionless/alternate DS donde la política de riesgo lo permita o una cascada a otro PSP.

13) Pruebas A/B alrededor de TTW

Corredor Instant vs Standard en parte del tráfico (guardrails: CBR bps, costo/pago, CSAT).
Pre-KYC copyright/flow, redacción de ETA, orden de métodos.
Métricas: TTW p95, SLA-hit%, tickets/1000 trx, AR/conversión, churn 7/30.

14) Mejores prácticas (corto)

1. Mida por etapas y mantenga las marcas de tiempo en un solo esquema.
2. Optimice p95/p99, no solo la mediana.
3. Incrustar instant-rails donde converge la economía.
4. Haga pre-KYC/SoF/approval para secuencias de comandos repetitivas.
5. Auto en cascada corredores y PSP, responder a la salud.
6. Hablar de ETA honesto y de los estados, alertar de los retrasos.
7. SLA almacenar en el directorio y comprobar SLA-hit% por cada corte.
8. Vincule TTW a CSAT/tickets/churn en los dashboards.
9. Incidentes posteriores: captura las causas, cambia las reglas/umbrales de tiempo.
10. Versione el esquema de eventos, valide la totalidad de las etiquetas de tiempo.

15) Lista de verificación de implementación

• Definiciones de TTW para depósitos/retiros acordadas con el producto/finanzas.
• Marcas de tiempo por etapas en 'payments. timeline`; Catálogo SLA.
• Dashboards p50/p95/p99, SLA-hit%, colas; alertas p95/tails/backlogs.
• Cascadas PSP/corredores, health-feed y auto-failover.
• Políticas pre-KYC/SoF y pre-approval; ND/same-method están automatizados.
• Comunicación de ETA y rastreador de estado para el usuario.
• Modelo económico «velocidad ↔ precio» en los corredores.
• Playbucks de incidentes y proceso post-mortem.
• Pruebas A/B de mejora de TTW con guardrails.
• Auditoría periódica de la integridad de los datos y la corrección de los cálculos.

Resumen

Time-to-Wallet no es sólo «velocidad de salida». Se trata de una métrica de experiencia de pago de extremo a extremo que afecta a la conversión, retención y P & L. Mida el TTW por hitos, optimice el p95/p99, conecte el instant-rails y las cascadas, retire la fricción a través del pre-KYC/approval y automatice la verificación ND/same-method. Una telemetría fuerte, ETA honesta y listas de reproducción harán que los pagos sean rápidos, previsibles y económicamente justificados.