Operaciones y Cumplimiento → Política AML y Control de Transacciones

Política de AML y control de transacciones

1) Objetivo y alcance

El objetivo de la política AML es prevenir el uso de la plataforma para el lavado de fondos y la financiación del terrorismo, minimizando los falsos positivos y la carga operativa. La política se aplica a todo el ciclo de vida del jugador: registro → depósitos → juego/transferencias → retiros; así como en afiliados, proveedores y socios de pago.

2) Principios (risk-based y evidence-by-design)

1. Risk-Based Approach (RBA): las verificaciones y los umbrales dependen del perfil de riesgo (país, método de pago, comportamiento, cantidades).
2. Controles Layered: una combinación de CUS/sanciones/RR, análisis de comportamiento e investigaciones manuales.
3. Evidence-by-Design: cada solución tiene artefactos: fuentes de datos, capturas de pantalla, registros, informes exportables.
4. Privacy-first: minimización de PDs, enmascaramiento, acceso por roles, política de retén controlada.
5. Explainability: las reglas y los modelos son interpretables; para ML - fichas/importancia/casos de ejemplo.
6. Impulso continuo: ajuste de umbrales, retroalimentación de MLRO y retro por caso.

3) Funciones y responsabilidad

MLRO (Money Laundering Reporting Officer): propietario del proceso AML, soluciones finales sobre SAR/AMB, comunicación con reguladores/bancos.
AML Ops: investigaciones, comunicaciones con jugadores/bancos, control de casos SLA.
Data/BI & Risk Analytics: soporte para reglas/modelos, monitoreo de calidad de detección.
Payments/Ops: cumplimiento de los límites y procedimientos de hold/revers, seguimiento de transacciones.
Seguridad/DPO: protección de datos, accesos, incidentes de privacidad.

4) Modelo de riesgo del jugador y segmentos

• Geo/IP/residencia, documento y método KYC.
• Métodos de depósito/retiro, multiplicidad de instrumentos de pago.
• Actividad: sumas, frecuencia, tornillo/lossrate, sesiones nocturnas, correlación con otras cuentas.
• Dispositivos/huellas electrónicas, intersecciones IP/dispositivos/datos de pago.

Segmentos: Bajo/Medio/Alto/Prohibido.
Motor de enrutamiento: Bajo - comprobaciones simplificadas; High - EDD/hold/limites.

5) KYC, sanciones y PEP

Tiered KYC: 'KYC1 (identidad) → KYC2 (dirección) → EDD (documentos/SoF)'.
Sanciones/RR: verificación en el registro, en umbrales significativos de depósitos/retiros y en cambios de datos.
SoF/SoW: por desencadenantes (altas revoluciones, no coincidencia de perfil, VIP).
Retiro: custodia de documentos de acuerdo con los requisitos de la jurisdicción; acceso a través de vault/control de dispensación.

6) Control de transacciones (reglas y señales)

• Velocity: espinas rápidas de depósitos/retiros; una serie de pequeños depósitos → grandes retiros.
• Multi-instrument: muchas tarjetas/billeteras diferentes en un período corto.
• Fuente/Destino mismatch: depositar de un instrumento, retirar a otro.
• Circularity: reposición → apuestas mínimas/lavado de bonos → retiro.
• Split/Structuring: trituración de sumas bajo umbrales.
• Affiliate abuse: afluencia anormal desde el canal + patrones de abuso tipo.
• Risk de dispositivo/IP: cambios de dispositivo/proxy/ASN de alto riesgo.

• Un tornillo poco realista en la baja varianza, apuesta por un «socio de contenido» con quejas, juegos con un riesgo mínimo en aras de la rotación.

7) Controls-as-Code (fragmentos)

yaml control_id: AML-VELOCITY-DEP-01 scope: deposits risk_weight: 0. 8 trigger:
expr: rolling_sum(amount, 1h) > baseline_30d3
OR count_unique(payment_method, 1h) >= 3
OR count(amount < threshold_structuring, 24h) >= 5 actions:
- flag: aml_review
- limit: withdrawals "hold_24h"
- request: "KYC2_or_EDD"
evidence:
store: s3://evidence/aml/velocity/{player_id}/{ts}
fields: [amounts_1h, methods_1h, ip, device, kyc_level]
owner: mlro review_sla_days: 180

yaml control_id: AML-SRC-DST-02 scope: withdrawals trigger:
expr: payout_method!= last_successful_deposit_method actions:
- limit: withdrawals "require_same_source"
- notify: payments_team
- flag: aml_review exceptions:
- condition: method_type=="bank_transfer" AND policy. allow_bank_payouts==true evidence:
fields: [payout_method, last_deposit_method, policy_ref]

yaml control_id: AML-GAMING-PATTERN-03 scope: gameplay trigger:
expr: turnover_24h / deposits_24h > 10
AND avg_bet_risk_index < 0. 2
AND session_count_24h > 8 actions:
- flag: aml_review
- limit: bonuses "freeze"
- request: "source_of_funds"

yaml control_id: AML-RISK-SCORE inputs: [AML-VELOCITY-DEP-01, AML-SRC-DST-02, AML-GAMING-PATTERN-03, sanctions, pep]
score:
expr: w1velocity + w2srcdst + w3gaming + w4sanctions + w5pep thresholds:
- high: score>=0. 8 -> EDD + hold
- medium: score>=0. 5 -> review
- low: score<0. 5 -> auto_clear

8) Modelos y reglas: compartir

Rules-first al inicio (rápido, explicable) + ML para priorizar (boosting/logreg/fiches recuperables).
Champion/Challenger: compara los umbrales actuales con los nuevos modelos en la sombra.
Drift-monitoreo: control de cizallamiento de fichas, fracciones de banderas/hold, FPR/TPR.
Explainability: SHAP/feature importance, casos de referencia.

9) SOP (fragmentos)

SOP: Triaje de activación AML

1. Comprobar la tarjeta del jugador (geo, KYC, riesgo-scores, historial).
2. Verifique las fuentes de datos (registros de pagos/juegos, comunicaciones por dispositivo).
3. Adoptar una decisión: 'clear/ request_info/hold/EDD/SAR'.
4. Confirme las acciones en el sistema de casos y actualice el estado.
5. Comunicación con el jugador (plantilla, plazos de respuesta).
6. Revisión del umbral/regla (si hay muchos FPs).

SOP: consulta EDD/SoF

1. Solicitud de documentos (extractos/nómina/impuestos).
2. Correlacionar cantidades/frecuencias/fuentes con el comportamiento de la plataforma.
3. Actualizar perfil de riesgo, eliminar/confirmar restricciones.
4. Mantener la alerta y la solución (firma MLRO).

SOP: Alimentación SAR/NAT

1. Recopilar factología (timeline, sumas, conexiones, scripts).
2. Compruebe los formatos deduplines y de jurisdicción/banco.
3. Presentar SAR/NAT, fijar el ID/hora/canal.
4. Actualizar los estados internos y las restricciones de la cuenta.
5. Follow-up hasta el cierre/instrucciones del regulador/del banco.

10) Comunicaciones con jugadores y socios

Tono: neutral y factual, sin revelar reglas/modelos internos.
Plazos: ETA clara a la respuesta, recordatorios, fijación en el ticket.
Socios de pago: sincronización hold/revers, intercambio de ID de caso, canal único AML.

11) Integraciones y datos

Payments Gateway: estados de transacción, método y datos, devoluciones, chargeback.
Plataforma de juego: rotación/tornillo/sesión/dispersión, anomalías.
Device Graph: huella digital/comunicaciones de dispositivos/sesiones/IP.
KYC/PEP/Sanctions: proveedor de cribado de eventos y horarios.
Gestión de casos: estados, SLA, registro de soluciones, embalaje SAR/AMB.

12) Indicadores de calidad (KPI/OKR)

• TPR/Recall por casos confirmados, FPR (banderas falsas) ↓ QoQ.
• Precision по High-risk > X%; Auto-clear Rate для Low-risk > Y%.
• Case Prioritation Accuracy (N% superior da M% de los hallazgos).

• Time-to-Triage (P95), EDD Turnaround, Hold Duration (mediana).
• SAR/AMB SLA (presentación de plazos ≤), devoluciones/chargeback después de las medidas AML ↓.
• Model/Rule Drift - dentro de los corredores permitidos.

• Pérdidas por Frod/lavado de ↓, reloj operativo/caso de ↓.
• Player Experience: quejas sobre procesos AML, NPS sobre jugadores honestos.

13) Gobierno y seguridad

Políticas de acceso: sólo AML/MLRO ven campos sensibles; auditorías de lectura.
Retiro: períodos de retención de casos/documentos; limpieza automática.
Registro: todas las acciones en casos y revisiones de reglas/modelos.
Control dual: los cambios críticos de reglas/umbrales requieren 2 confirmaciones.
Pruebas en CI: sintaxis de reglas, conflicto de umbrales, escenarios de regresión.

14) Hojas de cheques

• Se verificaron los datos de transacción/juego/dispositivo.
• Métodos de depósito/retiro comparados.
• Se verificaron las sanciones/RR/geo.
• Se ha seleccionado el tipo correcto de solución ('clear/hold/EDD/SAR').
• Fijada por ETA y comunicación al jugador.

• Tiempo completo y sumas, conexiones con otras cuentas.
• Artefactos de confirmación (screens/logs/extractos).
• El formato y el canal cumplen con el requisito.
• Los estados y restricciones internos se han actualizado.
• Control de las instrucciones de seguimiento.

• El umbral/ventana de tiempo está justificado.
• Hay una evaluación de FP/TP, un efecto de negocio.
• Se ha configurado el monitoreo de deriva y autotesta.
• Se ha actualizado el libro de reproducción del trío.
• Realizado por el rugido MLRO/Compliance.

15) Anti-patrones

Umbrales universales «para todos los países» sin RBA.
Hold sin AETA/comunicación, casos «colgantes».
Modelos ML sin explicación y registro de versiones.
Descarga manual/SAR sin plantillas de evidencia y control de tiempo.
Falta de comunicación depozit↔vyvod, escasa integración con los pagos.
No hay retro regular por falsos positivos.

16) 30/60/90 - Plan de implementación

• Aprobar la política AML, roles (MLRO/AML Ops) y la matriz RBA.
• Ejecutar Controls-as-Code básico (velocity, src/dst mismatch, gaming pattern).
• Incluir KYC tiers + sanciones/RER, crear plantillas SOP (triage/EDD/SAR).
• Introduzca el almacenamiento de información y la política de retiro.

• Conecte el agregador de riesgo, el enrutamiento automático de casos y los informes de SLA.
• Ejecutar Champion/Challenger para umbrales y Asistente de prioridad ML.
• Integrar payments/game/device gráfico en un único perfil de jugador.
• Capacitar a los comandos, depurar las plantillas de comunicación, habilitar autotestas de reglas.

• Reducir el FPR ≥ 20% sin pérdida de Recall; Reducir Time-to-Triage en ≥ un 30%.
• Lograr SLA SAR/AMB = 100% a tiempo; Cerrar todos los casos «almacenados».
• Realizar una auditoría interna del diseño y la eficacia de los controles; fijar OKR para el próximo trimestre.

17) FAQ

P: ¿Cómo equilibrar seguridad y UX?
R: Enrutamiento RBA: para bajo riesgo - auto-limpieza, para medio - consultas fáciles, para alto - EDD/hold. Las ETA transparentes y las comunicaciones.

P: ¿Qué hacer con los límites VIP y altos?
R: EDD obligatorio, revisión periódica de SoF/comportamiento, salida vinculada rígida (source-to-source), límites adicionales.

P: ¿Cuándo escalar en el banco/regulador?
R: En las banderas rojas/sospechas confirmadas según los plazos jurisdiccionales; tras la consulta de la MLRO y la fijación de la videncia.