Fraud Prevention Platform (FPP)
La Fraud Prevention Platform (FPP) es el módulo de prevención de fraudes y lavado de dinero de la Suite Guardline. Opera bajo el concepto FRAML (Fraud Prevention + Anti-Money Laundering), reuniendo fraude y AML en la misma plataforma, en el mismo motor de decisión y en la misma interfaz. Esto significa que la institución configura reglas, políticas y umbrales en un único lugar, tanto para escenarios de fraude transaccional como para patrones de lavado de dinero.
La FPP evalúa transacciones en tiempo real, monitorea el comportamiento de los clientes de forma continua, gestiona listas restrictivas y ofrece backtest con retroalimentación antes de cada modificación de regla.
Tipos de evento soportados
Sección titulada «Tipos de evento soportados»La FPP procesa dos tipos de evento:
- Transacciones monetarias: Pix, TED, DOC, boleto, tarjeta, cambio de divisas y cualquier otra operación financiera
- Eventos de cliente: cambio de contraseña, nuevo dispositivo, modificación de datos de registro y otros eventos no monetarios que pueden indicar riesgo
Ambos tipos pasan por el mismo motor de decisión y pueden combinarse en reglas compuestas.
Funcionalidades
Sección titulada «Funcionalidades»Motor de Decisión
Sección titulada «Motor de Decisión»El motor de decisión lo configura el equipo de compliance mediante la interfaz gráfica del panel, sin necesidad de código. La institución define:
- Workflows multietapa: secuencias de evaluación con múltiples etapas, cada una con sus propias reglas y acciones
- Reglas con condiciones: lógica determinista que define cuándo una transacción se aprueba, se rechaza o se deriva a análisis
- Políticas de riesgo: agrupaciones de reglas por tipo de transacción, canal, segmento de cliente o producto
- Umbrales: límites de score que disparan acciones automáticas (aprobar, bloquear, alertar, escalar)
- Scores: definición de cómo se calcula el riesgo, qué variables alimentan el score y qué pesos aplicar
- Disparadores: condiciones que activan acciones específicas (notificaciones, bloqueos, creación de casos)
- Integraciones con fuentes externas: conexión con proveedores de datos para enriquecer la evaluación
- Ventanas temporales: reglas que consideran acumulados en períodos configurables (ej.: “más de 5 transacciones en las últimas 2 horas”)
Respuesta de evaluación: cada evaluación devuelve, además del resultado (aprobar, bloquear, alertar), el desglose del motor, detallando cada ítem que puntuó y su contribución al score final. Esto permite que el analista y la institución entiendan exactamente por qué una transacción fue marcada.
El tiempo de respuesta opera con un SLA contractual de P95 en 300ms, lo que permite la evaluación en tiempo real sin impacto perceptible en la experiencia del cliente final.
Backtest
Sección titulada «Backtest»Toda modificación de regla en el motor puede pasar por backtest antes de entrar en vigor. El sistema ejecuta la nueva regla contra hasta 1 millón de transacciones históricas y presenta:
- Cuántas transacciones se verían afectadas
- Cuántas alertas adicionales se generarían (o se reducirían)
- Impacto en el volumen de falsos positivos y falsos negativos
- Comparación entre la política actual y la propuesta
El backtest es parte del flujo de edición de reglas, no una herramienta separada. El equipo visualiza el impacto antes de enviar la regla a aprobación.
Gobernanza de tres niveles
Sección titulada «Gobernanza de tres niveles»Toda modificación en el motor de decisión sigue un flujo de gobernanza obligatorio:
| Nivel | Rol | Acción |
|---|---|---|
| 1 | Analista | Crea o edita la regla |
| 2 | Supervisor | Revisa y valida la modificación |
| 3 | Administrador | Aprueba y activa en producción |
Ninguna regla entra en vigor sin pasar por los tres niveles. El historial de cada modificación (quién editó, quién revisó, quién aprobó, resultado del backtest) queda asentado en el registro de auditoría.
Reglas preconfiguradas
Sección titulada «Reglas preconfiguradas»La FPP se entrega con un conjunto de reglas de prevención de fraude y AML ya configuradas, basadas en buenas prácticas regulatorias y escenarios comunes. La institución puede:
- Usar las reglas tal como están para comenzar a operar
- Ajustar umbrales y condiciones según su política interna
- Crear reglas adicionales desde la interfaz
UBA (User Behavior Analytics)
Sección titulada «UBA (User Behavior Analytics)»La UBA monitorea el comportamiento de cada cliente a lo largo del tiempo y construye líneas base (baselines) individuales que sirven como referencia para la detección de anomalías. El enfoque es estadístico y determinista, basado en desviaciones estándar y percentiles calculados sobre el historial individual de cada cliente.
Cómo funciona
Sección titulada «Cómo funciona»1. Construcción de líneas base. El sistema observa el patrón de uso de cada cliente: montos típicos de transacción, frecuencia, horarios, ubicaciones, dispositivos, contrapartes habituales. Estos datos forman un perfil de comportamiento individual.
2. Detección de anomalías. Cuando una transacción se desvía de la línea base del cliente más allá de los umbrales estadísticos configurados (desviaciones estándar, percentiles), el sistema identifica la anomalía. La desviación se cuantifica y alimenta el score de riesgo.
3. Segmentación por comportamiento. Los clientes se agrupan en segmentos con base en patrones de comportamiento similares. Esto permite que las reglas y los umbrales se calibren por segmento, lo que reduce los falsos positivos.
4. Alertas automáticas. Las anomalías generan alertas que pueden derivarse a la Case Management Platform (CMP) o tratarse mediante reglas adicionales del motor.
Ejemplos de desviaciones detectadas
Sección titulada «Ejemplos de desviaciones detectadas»| Tipo de desviación | Descripción |
|---|---|
| Monto atípico | Transacción por encima del patrón habitual del cliente |
| Frecuencia inusual | Volumen de transacciones fuera del patrón en un período corto |
| Horario inusitado | Operación en un horario que el cliente nunca utilizó |
| Geolocalización divergente | Transacción originada en una ubicación incompatible con el perfil |
| Contraparte nueva de alto monto | Transferencia de monto elevado a una contraparte sin historial de relación |
| Cambio de dispositivo | Operación desde un dispositivo desconocido |
UBA y monitoreo continuo
Sección titulada «UBA y monitoreo continuo»La UBA no opera solo en el momento de la transacción. La línea base se actualiza continuamente, lo que permite:
- Permanent KYC: el perfil de riesgo del cliente evoluciona con su comportamiento, sin depender de revisiones periódicas manuales
- Detección de degradación gradual: se identifican patrones que cambian lentamente a lo largo de semanas o meses
- Contexto para la investigación: cuando un caso llega al analista en la CMP, el historial de comportamiento ya está disponible como parte del expediente
Gestión de listas
Sección titulada «Gestión de listas»La FPP utiliza la gestión centralizada de listas del Core:
| Tipo de lista | Función |
|---|---|
| Blocklist | Las entidades listadas disparan las reglas de bloqueo configuradas por la institución |
| Watchlist | Monitoreo reforzado sin bloqueo |
| Greylist | Observación temporal con reglas específicas |
Las listas son de la institución: cargadas manualmente por el panel o por API, con importación, exportación e historial de toda modificación. La condición de PEP y la presencia en listas de sanciones llegan a la FPP como atributos del cliente, con procedencia, verificados por la Onboarding Platform en el registro.
Prevención de lavado de dinero (AML)
Sección titulada «Prevención de lavado de dinero (AML)»La AML es un dominio del mismo motor, con workflow, reglas y umbrales propios, y agrega lo que el lavado de dinero exige: un catálogo de escenarios por jurisdicción (Brasil y Argentina), alertas por transacción y por entidad con evidencia y severidad, consolidación por sujeto y escenario, despacho a la Mesa de Decisión y el veredicto de vuelta al historial del cliente. El Compliance parametriza los escenarios en vista de matriz, sin redeploy y con aprobación.
La descripción completa está en la sección AML.
Versión 18, actualizada el