Operaciones y Cumplimiento → Cribado Sancionador y Filtrado PEP

Cribado de sanciones y filtrado PEP

1) Objetivo y área

Reducir los riesgos legales/financieros y garantizar el cumplimiento de las licencias: eliminar a las personas/entidades sancionadas, identificar a los PEP y personas relacionadas, tomar en cuenta los medios negativos y tomar medidas proporcionales. Se aplica a jugadores (KYC), socios (KYB), proveedores y empleados con acceso a PDn/finanzas.

2) Términos y cobertura

Sanctions (las sanciones): las prohibiciones/restricciones a la interacción con litsami/organizatsiyami/sudami/sudami.
PEP (Politically Exposed Person): funcionarios públicos y sus asociados más cercanos (RCA).
Medios avanzados: publicaciones sustancialmente negativas (delitos financieros, corrupción, etc.).
Match: coincidencia de la entrada de perfil con el elemento de lista (preciso/probabilístico).
RCA (Relatives & Close Associates): cónyuge (a), hijos, socios comerciales, etc.

3) Principios

1. Risk-Based Approach (RBA): la profundidad de la verificación y la frecuencia dependen del perfil de riesgo (país, método de pago, cantidades, función).
2. Explainable Matching: las reglas de comparación son transparentes; Se mantiene la justificación de la decisión.
3. Evidence-by-Design: cada «golpe/no caída» va acompañado de artefactos.
4. Privacy-first: mínimo de PDn, accesos estrictos, retiro por ley.
5. Continuous Screening: eventos → retroalimentación inmediata; revisiones periódicas de batch.
6. One Source of Truth: un único registro de resultados y soluciones de cribado (audit trail).

4) Fuentes y actualizaciones

Listas de sanciones y de control: mundiales/regionales/nacionales; sectorial/territorial; Listas de transportistas/buques (si es necesario).
PEP/RCA: multinivel (nacional/regional/internacional).
Medios avanzados: fuentes agregadas con categorización de riesgos.
Actualizaciones: diarias/semanales; almacene la versión de referencia y el tiempo de descarga.

5) Política de cribado (marco)

Cuando verificamos: registro, antes del primer depósito/retiro, cuando se cambian los datos de pago, se alcanzan los umbrales de facturación, cuando se cambia el perfil/dirección/documento, cuando se actualizan las listas.
A quién estamos revisando: jugadores (KYC), socios/proveedores (KYB), empleados con accesos (HR/KC).
Lo que hacemos en las coincidencias: triaje → confirmación/exclusión/escalamiento de la medida →: fallo/hold/EDD/cierre.

yaml policy_id: SANC-PEP-POL-001 scope: players, partners, employees triggers:
- on_event: signup, pre_deposit, pre_payout, kyc_update, payout_destination_change
- on_list_update: sanctions    pep    adverse_media risk_bands:
low: [EU_ trusted methods]
high: [high_risk_geo, multiple_payment_methods, turnover>threshold]
actions_by_match:
sanctions_confirmed: block_all & report & freeze_payouts pep_confirmed: edd & enhanced_monitoring adverse_media_high: manual_review & edd review_sla_days: 180 owner: head_of_compliance

6) Algoritmos de asignación (matching)

Comparación exacta: FIO + RD/documento/país.
Fuzzy-mapping: tokenización, normalización, transliteración/alias, distancias de cadena; fonética (por ejemplo, Soundex/Metaphone-similar).
Peso contextual: fecha de nacimiento> nacionalidad> dirección> alias "país.
Reducción de las falsas coincidencias: «must-have» del campo, los umbrales son similares en tipos de nombres, ignora las palabras frecuentes.
Sensibilidad por geo: para geo de alto riesgo - por debajo del umbral en el score fuzzy.
Listas blancas con vencimiento: excepciones temporales (whitelist) con causa y fecha límite.

7) Disparadores de Rescribido

Actualización de la versión de listas.
Eventos de perfil: cambio de FIO/dirección/documento, nuevo método de salida.
Umbrales/volumen de negocios, aumento de límites, estado VIP.
Señales AML/Risk: velocity, no coincidencia source-to-source, anomalías de dispositivo/IP.

8) Integraciones y datos

KYC/KYB: proveedores de IDV/inspecciones/registros; UBO/Director con socios.
Pagos: bloque «pre-payout» y negociación hold/revers.
Gestión de casos: tarjetas de partido, estado y registro de decisiones.
DWH/BI: escaparates de calidad hit-rate/precision/deriva.

9) Controls-as-Code (fragmentos)

yaml control_id: SANC-PEP-SIGNUP scope: player_profile trigger:
expr: event in {signup, pre_deposit, pre_payout}
actions:
- screen: sanctions    pep    adverse_media
- block: payout if match_score>=0. 85 until triage_done evidence:
fields: [list_version, query_payload, top_matches]
owner: compliance_ops

yaml control_id: SANC-PEP-RESCREEN scope: population trigger:
expr: sanctions_list. version_changed==true OR pep_list. version_changed==true actions:
- enqueue: rescreen_batch(population_segments=[high_risk, active_payouts])
- notify: compliance_channel

yaml control_id: PEP-MONITOR-01 scope: players trigger:
expr: pep_status==confirmed actions:
- require: edd & source_of_funds
- monitor: payouts frequency>=weekly
- set: limits=pep_limits_schema

yaml control_id: ADV-MEDIA-HI scope: players    partners trigger:
expr: adverse_media. severity in {high, severe}
actions:
- flag: manual_review
- limit: payouts "hold_24h"
- collect: additional_evidence

10) SOP (fragmentos)

SOP: Triaje de superposición de sanciones/RR

1. Verificar contexto: FIO/RD/ciudadanía/aliases/documento.
2. Conciliar fuentes (id de registro, fecha de actualización, estado legal).
3. Solución: 'confirmed/ false_positive/inconclusive'.
4. Para 'confirmed': aplicar medidas (block/EDD/report), fijar la justificación.
5. Para 'inconclusive': solicitar datos adicionales (documento/confirmación de dirección).
6. Cerrar caso, actualizar whitelist/blacklist (si corresponde), adjuntar evidence.

SOP: Resonancia cuando se actualizan las listas

1. Inicio automático de batch, segmentos: pagos activos, alto riesgo.
2. Informe de nuevos partidos, distribución de casos SLA.
3. Cuentas indirectamente vinculadas (RCA) - en una cola separada.

SOP: Comunicación con el jugador/compañero

1. Redacción neutral, sin revelar criterios internos.
2. Plazos y lista de documentos solicitados (si se necesita EDD).
3. Fijación de comunicaciones en el caso, recordatorios y deduplines.

11) Privacidad, seguridad, auditoría

RBAC/ABAC: acceso a los detalles de los partidos y documentos - sólo con Compliance/MLRO.
Retencion: almacenar los resultados y la evidencia según los plazos jurisdiccionales; limpieza automática.
Cifrado: in transit/at nat; claves en HSM/Vault.
Auditoría: registro de lecturas/decisiones, versiones de reglas/umbrales, resultados de autotestas.

12) Dashboards y métricas

Revisiones de pantalla: volumen de comprobaciones, tasa de éxito por segmentos, fracción de fuzzy.
Calidad: Precision/Recall casos confirmados, False Positive Rate, Time-to-Triage (P50/P95).
Latency: tiempo de respuesta de los proveedores, cola de recuperación.
Drift: cambio de distribución de nombres/geo, aumento de la proporción de coincidencias inseguras.
Compliance: cumplimiento de SLA sobre informes y escaladas.

• Precision por sanciones ≥ 95%, por PEP ≥ 90%.
• Time-to-Triage (P95) ≤ 24 h (sanciones), ≤ 48 h (PEP/adverse).
• False Positive Rate ↓ QoQ sin pérdida de Recall.
• El SLA de recuperación cuando se actualizan las listas ≥ 98% a tiempo.
• Evidence Completeness ≥ 98%.

13) Hojas de cheques

• Las fuentes de las listas están conectadas, las versiones están lógicas.
• Política de RBA aprobada, umbrales de fuzzy acordados.
• Se han asignado procesos y roles de triaje (Compliance/MLRO).
• Integraciones: KYC/KYB/Payments/Case-tool.
• Los dashboards y alertas están desplegados.

• Se han comparado campos clave (FIO/RD/ciudadanía/alias).
• Se verificaron las fuentes y la fecha de registro.
• Se fijan la decisión y las medidas; notificaciones enviadas.
• Seguimiento aplicado, whitelist/blacklist actualizado (si es necesario).

• Las pruebas automáticas de reglas/umbrales han pasado.
• Auditoría trimestral de soluciones (muestreo).
• El monitoreo de drift es normal; Se han revisado los umbrales.

14) Anti-patrones

«Un umbral para todos» sin tener en cuenta el geo y la calidad de los datos.
Falta de registro de la versión de las listas y de los motivos de la decisión.
Permanente permanent whitelist sin caducidad y razón.
Dos versiones de la verdad: Soluciones Excel y registros separados en venta.
Retrasos injustificados en los pagos sin ETA y en las comunicaciones.
Recuperación desactivada cuando se actualizan las listas.

15) 30/60/90 - plan

• Aprobar la política SANC-PEP, los umbrales de matching, roles y SLA.
• Conectar proveedores de listas; la lógica 'list _ version'.
• Incluye tres controles básicos: 'SIGNUP', 'PRE _ PAYOUT', 'RECREEN'.
• Implementar la gestión de casos, dashboards y almacenamiento de información.

• Añadir medios RCA/advers, segmentos de alto riesgo y VIP.
• Optimizar fuzzy (transliteraciones/alias), reducir el FPR ≥ un 20%.
• Automatizar la recuperación de eventos y actualizaciones de listas.
• Incluya sampling de calidad y auditorías trimestrales.

• Alcanzar los KPI de precisión/Recall y Tiempo-a-Triage objetivo.
• Integre con AML (EDD/SoF) y payout-gates (source-to-source).
• Incluir KPI en los comandos OKR, realizar una auditoría externa/interna.

16) FAQ

P: ¿Cómo distinguir un monofamilio de una coincidencia real?
R: Utilice los campos de confirmación (RD/documento/ciudadanía), contexto geo y aliasa; para los fronterizos - triaje manual con umbral de confianza.

P: ¿Es necesario capturar a los afiliados y su UBO?
R: Sí. KYB es obligatorio: UBO/directores + sanciones/RR + medios negativos; cuando se cambia la UBO es re-vera y rescribido.

P: ¿Qué hacer con la sanción confirmada?
R: Bloque inmediato, pagos libres, notificaciones a los reguladores/bancos sobre los requisitos de la jurisdicción, mantener el paquete completo de evidence.

P: ¿Por qué los medios de comunicación avanzados si hay sanciones?
R: A menudo es una señal temprana de riesgo (antes de las sanciones). Utilice para EDD/monitoreo y restricciones preventivas.