Dashboards de cumplimiento de UX
1) Nombramiento y principios
El dashboard de cumplimiento es una «capa superior» de control de riesgos regulatorios (KYC/AML, juego responsable, sanciones/RER, RTP/certificación, protección de datos) que:- da señales y prioriza los riesgos;
- proporciona una explicación («por qué funcionó»);
- acelera la reacción (botones de acción, rutas de escalamiento);
- conserva las huellas de auditoría (quién y cuándo hizo qué).
- Signals over raw: primero estados/anomalías, luego detalles.
- Time-to-decision <60 segundos: preajustes de filtro, resúmenes cortos del caso, acciones rápidas.
- Explain & Next: junto a la señal - «qué es» y «qué sigue».
- Escala de criticidad única: Info/Low/Medium/High/Critical con consistencia de color.
- Tiempo fijo y ventana de análisis, fecha explícita de generación del informe.
- Cero fugas de PDn: mínimo PII; por defecto, alias/hashes.
2) Roles y escenarios clave
Head of Compliance: revisión de riesgos, cargas, SLA de investigación, progreso de remediación.
Analista de cumplimiento (L1/L2): triaje de alertas, gestión de casos, preparación de la base de pruebas.
AML Officer: transacciones sospechosas, preparación SAR/AMB, listas de sanciones/RR.
RG (Juego responsable): patrones de riesgo conductual, límites/autoexclusión, intervenciones.
Data Protection Officer (DPO): DSAR, fugas, anonimato, accesos.
Tech/QA: estabilidad de las integraciones de los proveedores de cribado, errores/retrocesos, latencia.
Legal: deduplines de informes regulatorios, estados de archivos de auditoría.
1. «Alertas críticas para hoy» → distribuirse entre los artistas.
2. «Casos caducados» → escalar.
3. «RTP salió por el pasillo» → bloquear el juego/operador, iniciar una investigación.
4. «Coincidencia con la lista de sanciones» → KYC hold, solicitud de documentos.
5. «Alto riesgo de RG» → intervención suave/dura, congelación de depósitos.
3) Arquitectura de la información
1. Panel global: período, geo/jurisdicción, marca/operador, producto, criticidad, estado del caso, ejecutante.
2. Inicio («Hoy»): resumen de KRI/KCI, alertas, burn-down SLA, «top movers».
3. Riesgos (Risk Hub): matriz de categorías (KYC/AML/RG/Privacy/Certification/Payments).
4. Casos: cola, Kanban/tabla, plantillas de decisión, historial de acción.
5. Informes: informes regulatorios, deduplines, estado de archivos y validaciones.
6. Integraciones: salud de los proveedores (sanciones, PEP, documento de verificación, puntuación conductual).
7. Políticas y control: versiones de reglas, chanjlog, experimentos/sandbox.
4) Métricas: KRI, KCI y SLA
4. 1 KRI (Key Risk Indicators)
Sanctions/PEP Hit Rate = hits/chequeos.
False Positive Rate = coincidencias falsas/todas las coincidencias.
Unverified Users% = inconcluso KYC/todos los nuevos.
SAR/NAT per 1k Users = número de usuarios SAR/AMB/1000.
RG High-Risk% = flagelado por reglas de comportamiento/jugadores activos.
4. 2 KCI (Key Control Indicators)
KYC Turnaround (p50/p95) es la mediana/cuantil del tiempo de verificación.
Alert → Case Conversion% es la proporción de señales que se han convertido en un caso.
Case Resolution Time (p50/p95).
Investigación Reopen% es la proporción de casos reabiertos.
Data Access Violations - Intentos de ver PD no autorizados.
4. 3 SLA/SLO (operativos)
Triage SLA: alerta crítica tomada en el trabajo ≤ 15 min.
Resolution SLA: por tipos (KYC - 24h, AML - 72h, RG - 24h, incidente de privacidad - 72h).
Provider Uptime/Latency: detección de endpoints p95.
ETL Freshness: vitrina de datos ≤ X minutos.
5) Widgets y patrones
Inicio («Hoy»)
Heatmap de riesgos: categorías × criticidad; clicabile hasta la lista de casos.
SLA Burn-down: cuántos casos hay en la zona verde/amarilla/roja por día.
Top Movers: métricas que han cambiado> umbral (FPR, RG High-Risk%, RTP Dev).
Provider Health: aptime, retrasos, errores de integración.
Risk Hub
Una matriz de «categoría × jurisdicción» con pistas de políticas y requisitos locales.
Anomaly Explainers: la contribución de los mercados/juegos/proveedores a la desviación de la métrica.
Drill-through: del agregado → a la lista de eventos → a la tarjeta del usuario (sin PII, sólo pseudo-ID).
Tarjeta de caso: estado, criticidad, lista de verificación, última actividad, propietario, temporizador SLA, «Por qué funcionó la regla».
Barra de acción: «Solicitar documento», «Poner límite», «Hold/Unhold», «Escalar», «Cerrar con resultado».
Audit Trail: registro inmutable, archivos adjuntos, enlaces a reglas/eventos.
Plantillas de solución (playbooks): pasos y textos de notificación prellenados.
Informes
Calendario de Deadline: informes regulatorios, firmas, confirmaciones.
Validador: estados de comprobación de archivos/esquemas, errores y correcciones.
Exportación: versiones de archivos con hash, firma de tiempo y responsables.
6) Reglas, explicabilidad y versiones
Catálogo de reglas: lista de reglas (ID, versión, propietario, jurisdicciones, descripción de lógica).
Explosividad: junto al desencadenante - «qué hechos han dado lugar a la activación» (por ejemplo, «coincidencia por alias sancionadora, fuente: lista de la UE»).
Versioning: la regla especifica la versión exacta del modelo/lista; el caso almacena la lógica del francotirador.
Prueba Scenario: «corriendo a las historias» para una versión fresca antes de ser incluida.
Change Log: quién cambió lo que cambió, por qué (link to ticket).
7) Datos y contratos
Contrato mínimo de eventos:- `kyc_check` (user_pid, provider, result, reason_codes, ts).
- `sanctions_screen` (user_pid, list_name, match_score, match_fields, ts).
- `rg_signal` (user_pid, risk_level, features_snapshot, ts).
- `rtp_sample` (game_id, market, spins, rtp_observed, window, ts).
- `case_event` (case_id, action, actor, ts, payload_ref).
- `privacy_incident` (type, scope, status, ts).
- Daily_Risk (categoría × día × jurisdicción).
- Case_Flow (SLA/hitos/resultados).
- Provider_Health (aptime/latency/errores de integración).
- Rule_Versions (activo/revocado).
- campos obligatorios, rangos permitidos, idempotencia de eventos, deduplicación, monitoreo de lagunas.
8) Privacidad, RBAC y minimización PII
Modelo de rol: Legal/Head ve unidades y casos, L1 - tarjetas impersonales, acceso a PII - sólo por un botón justify con registro.
Modo PII predeterminado: FIO/direcciones ocultas; sólo se muestran pseudo-ID/máscaras.
Just-in-Time Access: acceso temporal a PII por caso; retroalimentación automática.
Enlace de datos: ruta de campo desde la fuente hasta el escaparate; Comprobar rápidamente la legalidad del procesamiento.
Protección de la exportación: marcas de exportación (PII/No-PII), para advertir de la violación de la política.
9) Procesos de investigación (Casos Ops)
Этапы: Detect → Triage → Investigate → Decide → Remediate → Report → Learn.
Consejos de UX:- listas de cheques por tipo de caso;
- el temporizador SLA y los «próximos pasos previstos»;
- «casos/soluciones similares»;
- «justificación del cierre» y plantillas de reportes.
- la imposibilidad de cerrar el caso sin campos de justificación completos;
- advertencia cuando no se realizan los pasos del playbook;
- seguimiento automático (después de N días) para comprobar la eficacia de la medida.
10) Alertas y escaladas
Reglas modelo:- Critical: sanction true match; desviación masiva de KYC por el proveedor; RTP Dev> δ en N giros; fuga de PDn.
- High: RG High-Risk surge > Xσ; FPR de cribado de sanciones ↑ por encima del umbral; SLA atrasado.
- Medium: retraso del proveedor> p95 SLO; crecimiento del reopen%; una anomalía en el mercado.
- tarjeta compacta (tipo, fuente, confianza, consecuencias), 2 botones: «Tomar trabajo», «Rechazar con causa».
- acciones masivas para los batch alert.
- «Por qué lo veo» es el dueño de la política/regla.
- matriz «tipo de riesgo × nivel» → legal, exec, soporte técnico;
- una escalada automática en una violación de SLA.
11) Juego responsable (RG) - UX-especificidad
Marcadores tempranos: actividad nocturna, aumento de depósitos, cancelaciones frecuentes de retiros, comportamiento chase.
Widgets: RG Risk Funnel (marcador → contacto → límite/pausa → outcome), mapa de intervenciones y su eficacia.
Intervenciones: blandas (notificaciones, reality-check), rígidas (límites, tiempo de espera, auto-exclusión).
Validez: junto al mapa de medidas - «por qué se elige este nivel de impacto».
12) Disponibilidad y localización
contraste y fuentes por WCAG, enfoque predecible, teclas de acceso rápido;
localización de los términos de cumplimiento (glosario en IU);
formatos únicos de fecha/número, moneda explícita y zona horaria;
«modo de presentación»: pantallas sin PII para demostraciones a la junta directiva/auditoría.
13) Antipatternas
«Pared de tablas» sin señales ni explicaciones.
Mezcla de roles: los datos legales están disponibles para L1 sin justify.
Ventanas emergentes en cada clic (fatiga de interfaz).
Diferentes fórmulas para las mismas métricas en diferentes widgets.
Alertas sin rostro sin acción de «lo que sigue».
Exportar con PDn sin previo aviso ni lógica.
14) Lista de comprobación de la implementación (por sprints)
Sprint 1: escaparates básicos (Daily_Risk, Case_Flow), principal «Hoy», matriz de riesgos.
Sprint 2: tarjeta de caso + playbooks, temporizadores SLA, audit trail.
Sprint 3: integración de proveedores (sanciones, KYC, RG), Provider Health, retraídas.
Sprint 4: reporting y validador, calendario de deadline, exportación con guardrails.
Sprint 5: explainers, «casos similares», reglas de cambio-registro, prueba scenario.
Sprint 6: localización, disponibilidad, modo de presentación, acceso JIT a PII.
15) Glosario
KRI/KCI - Indicadores de riesgo/control.
SLA/SLO - Tiempo de respuesta/solución objetivo/contractual.
PEP/Sanctions son personas políticamente relevantes/listas de sanciones.
SAR/NAT - Informes de actividad sospechosa.
RG es un juego responsable.
FPR/TPR es un lóbulo falso positivo/verdadero positivo.
PII - datos personales.
Playbook es una plantilla de acción de caso.
16) Resultado
Un buen tablero de cumplimiento UX es:1. señales con explicabilidad,
2. acciones rápidas y seguras,
3. controles estrictos de acceso y rastros de auditoría,
4. métricas consistentes en todas las pantallas,
5. apoyo a los procesos de investigación y presentación de informes.
Comience con «Hoy» (señales, SLA, salud de las integraciones), agregue las Ops de caso y la Explainability, y luego amplíe a la información y la política de versionamiento, de modo que el dashboard se convierta en una verdadera herramienta de reducción de riesgos en lugar de un mero escaparate de números.