Detección de anomalías en las operaciones

1) Por qué

Las anomalías son marcadores tempranos de incidentes y pérdidas financieras. En iGaming, estas son las caídas en las autorizaciones exitosas, las subidas de tiempo, el aumento de las colas, las fallas en la conversión de KYC, las subidas en las desviaciones de apuestas, los errores de los proveedores de juegos. El objetivo es detectar antes que el usuario, localizar la causa y ejecutar reacciones automáticas/operativas.

2) Señales y dominios de observación

Pagos/finanzas: tasa de éxito de las autorizaciones PSP/bancos/GEO, soft/hard declines, tiempo de compensación, indicadores iniciales de chargeback.
Núcleo de juego: p95/p99 apuestas y settles, error-rate, balances divergentes, outliers en coeficientes/líneas.
Infraestructura: latency/5xx API, saturation (CPU/RAM/IO), replication lag DB, consumer-lag colas, cache-hit/eviction.
KYC/AML: colas de verificación, TAT (turnaround time), fracción de verificación manual.
Frente/RUM: TTFB/LCP, errores JS, degradación geo-específica.
Seguridad/fraude: ráfagas de entradas/registros/pines, anomalías velocity, patrones atípicos.

3) Tipos de anomalías

Punto (point): una sola vez (por ejemplo, una caída del 20% en el éxito automático en la UE).
Contextual (contextual): «anormal para esta hora/día/evento» (pico nocturno - aprox., diurno - no).
Colectivo (collective): secuencia de pequeñas desviaciones que forman un incidente (crecimiento de arrastre p99).
Cambio de modo (change-point): nuevo nivel de serie (después de la versión/configuración/proveedor).

4) Técnicas de detección (de lo simple a lo complejo)

1. Reglas de umbral: estático o dinámico (percentil por ventana deslizante, mediana ± k· MAD).
2. Descomposición estacional (STL): tendencia/estacionalidad → análisis de residuos (residual) e IQR/MAD.
3. Mapas de control (CUSUM/EWMA): sensibles a pequeños cambios de media/varianza.
4. Detección de cambios (Change Point Detection): BOCPD, rupturas/PELT; registramos los momentos de cambio de modo.
5. Anomalías multidimensionales: Mahalanobis, Bosque de Isolación/LOF por conjuntos de fichas (latency, error-rate, lag, hit-ratio).
6. Métodos de streaming (stream): ADWIN, SSD, estadísticas de sketch; baja latencia y con memoria limitada.
7. Pronóstico + delta: ARIMA/ETS/Prophet/GBM → comparación del hecho con el intervalo de confianza (especialmente para las series de negocios).
8. ML semi-controlados: aprendizaje en «normal» (Uno-clase SVM/Autoencoder), útil en marcas escasas.

Práctica: combinamos 2-3 métodos y agregamos por votación o por prioridad (rule-of-thumb: estacional STL + CUSUM + cinta predictiva).

5) Anomalías de pipeline: de los datos a la acción

1. Recolección → normalización: series unificadas (OTel/métricas), granularidad única (10-60 segundos).
2. Fichi y contexto: GEO/PSP/banco/canal, "¿hora de trabajo? «, «¿partido/torneo? ", lanzamientos/fichflags, trabajos programados.
3. Estacionalidad y calendario: modelos de aware sobre fines de semana/prime time/partidos/vacaciones.
4. Detector: métodos seleccionados (umbral/estadísticas/ML/stream) con parámetros por segmento.
5. Supresión de ruido: histéresis y confirmación por varias ventanas (N-of-M), dedoop de incidentes.
6. Resumen y priorización: evaluación del impacto (SLO, dinero/min, proporción de audiencia), asignación de P1-P4.
7. Reacción: Auto-acción (Feilover PSP, degradación de fich, autoscaling por lag), creación de incidente y war-room, actualización de la página de estado.
8. Lógica y auditoría: qué funcionó/por qué, umbrales/versiones de modelos, comunicación.

6) Calibración de umbrales y calidad

Precision/Recall/F1 por «anomalía ↔ incidente».
Time-to-Nat (TTD): el objetivo es antes MTTA usuarios/sapport.
False Alarm Nota: ≤ objetivo 5-10% para P1/P2.
Lead Time: una ventana entre el niño y la violación de SLO - da la oportunidad de acciones automáticas.
Monitoreo Drift: readiestramiento/recalibración en el horario y en el cambio de temporada/arquitectura.

7) Catálogo de anomalías (ejemplos de iGaming)

7. 1 Pagos

Fracaso del éxito automático en PSP-X en TR/EU: contexto - banco BIN específico, ventana 5-10 min.
Crecimiento de soft-decline con tráfico normal: posible problema 3DS/issuer.
Retrasos en la compensación: riesgo de roturas de caja.
Reacciones: routing a PSP alternativo (health × fee × conversion), retrés con jitter, inclusión de 3DS simplificado, paquete de comm a partners.

7. 2 Apuestas/Juegos

Salto de p99 de la red de apuestas: réplica/caché/cola.
Separación de la GGR esperada de la norma: anomalías contextuales por torneos/eventos deportivos.
Reacciones: cache-warmup, redistribución de carga, retención de una parte de un fich no crítico.

7. 3 Infra/datos

Replication lag↑ y lock-waits: sobremesa.
El registro de consumo salta: no marca los lotes o la llave caliente.
Reacciones: autoscaling, re-partición, límites a producer's.

7. 4 KYC/AML

Tiempo de verifikatsii↑: el proveedor se degrada.
Reacciones: proveedor de fallback/cola manual, notificación Compliance.

7. 5 Frente/RUM

Errores LCP/JS en un navegador/versión específica: retroceso de la versión.
Reacciones: rollback canarios, feature-flag off, mensaje en la página de estado.

8) Alerting SLO-aware

La señal de anomalía se convierte en alerta si afecta al presupuesto de errores o predice su burn-rate (burn-rate).
Dos ventanas: rápida (1 h) y lenta (6-24 h); «Pager inmediato» sólo para P1 de alto impacto.
Cualquier alerta está enlazada al runbook y al rol propietario.

9) Arquitectura de soluciones

Ingesto: OTel/métricas → Kafka/streaming → framework de procesamiento (Flink/Spark/Kafka Streams).
Ingeniería de fichas: unidades, indicadores de temporada, uno-hot por PSP/bancos/GEO.
Detectores: bibliotecas de estadísticas + modelos (on-line/mini-batch) con versificación.
Repositorio de resultados: «anoma-línea» (eventos) con contexto, conjunto con gestión de incidentes.
Servicio de toma de decisiones: priorización, auto-reacción, publicación en la página de estado/en los canales.
Observabilidad: gráficos de la calidad de los modelos, alarmas sobre el drift, coste del engesto.

10) Costo y privacidad

Coste-aware: sampling de las filas de entrada, downsampling de la historia, agregaciones; clases de QoS separadas.
PII: no lógica userId en métricas; para el análisis - tokenización/máscaras y acceso por SoD; exportación: a través de flujo de trabajo con cifrado/TTL.

11) Procesos y roles

Responsible: SRE/Observability/Payments Risk en sus dominios.
Accountable: Head of Ops/SRE.
Consulted: Data Science, Product, Compliance, Security.
Informed: Support, Partner Management, Finance.
Rituales: calibración semanal de umbrales/reglas, retro mensual por señales falsas/omitidas.

12) Dashboards

Exec: mapa de anomalías por dominio, tendencias false/true alarms, TTD y lead time, impacto en ingresos/SLO.
Ops/SRE: cintas de niños con contexto (lanzamientos/banderas/trabajos programados), distribución de residuos STL, tarjetas de cambio de puntos.
Payments/Risk: tarjetas PSP × banco × GEO, embudos de fallas, enrutamiento automático y medidas de efecto.
Front/RUM: navegador × versión × GEO, regresión de lanzamientos, experiencia VIP.

13) KPI/KRI función

TTD (min) y Lead Time (min) antes de la violación de SLO.
Precision/Recall/F1 de referencia a incidentes.
Tasa de alarma de False y cuota de buscapersonas (fatiga on-call).
Proporción de reacciones automáticas que cerraron el problema sin intervención manual.
Reducción de MTTR después de la implementación.
Costo/valor: $/alerta y ahorros en pérdidas evitadas.

14) Hoja de ruta para la implementación (8-12 semanas)

Ned. 1-2: inventario de SLI/KPI, selección de series prioritarias (pagos/apuestas/colas/DB), umbrales básicos y STL.
Ned. 3-4: flujo de procesamiento (Kafka + Flink/Streams), contexto (GEO/PSP/releases), histéresis y dedoup.
Ned. 5-6: change-point + CUSUM, cintas predictivas para las filas de negocios, comunicación con la plataforma de incidentes, runbooks.
Ned. 7-8: auto-reacción (PSP Feilover, degradación de fich, autoscaling por lag), dashboards y métricas de calidad.
Ned. 9-10: modelos multivariantes (Isolation Forest/IForest/AE) en dominios piloto, monitoreo de drift.
Ned. 11-12: optimización de costes, calibración de umbrales A/B, normativa de revisión mensual y formación de equipos.

15) Patrones de artefactos

Anomaly Spec: señal, segmentación (GEO/PSP/banco), método, umbrales, ventanas, histéresis, propietario, runbook, reacción automática.
Change-Point Report: tiempo, componente, niveles anteriores/posteriores, correlaciones (versiones/fichas/trabajos).
Quality Dashboard Definition: métricas de calidad, límites objetivo, período de revisión.
Política de Auto-Acción: términos y límites de auto-acción, criterios de devolución, auditoría.

16) Antipattern

Umbrales estáticos universales sin estacionalidad y segmentación.
Falta de histéresis → flapping y «pager fatigue».
Alertas fuera del contexto de SLO/dinero → mucho ruido, poco uso.
La «caja negra» del ML sin explicación ni registro.
No hay conexión con lanzamientos/fichflags/trabajos programados.
Ignore el costo del higo/almacenamiento para las series auxiliares.

Resultado

La detección de anomalías es un proceso y una plataforma, no solo un modelo: señales y contexto correctos → métodos sostenibles (STL/CUSUM/CPD/pronóstico) → supresión de ruido y priorización de SLO/ingresos → respuesta automática y runbooks comprensibles → un ciclo cerrado de calidad y costo. Este circuito atrapa los problemas antes que los usuarios, reduce el MTTR y protege los flujos de negocio de las plataformas iGaming.