Módulo de prevención de fraude
Definiciones
El módulo de Prevención de Fraude provee las capacidades necesarias para detectar, evaluar y mitigar transacciones fraudulentas desde el rol adquirente, actuando sobre el comercio, el contexto transaccional y el comportamiento del comprador.
Este módulo opera de forma transversal al flujo de autorización, analizando cada operación antes de su envío a los procesadores y/o marcas, con el objetivo de reducir pérdidas económicas, contracargos y exposición al riesgo.
Desde una perspectiva de arquitectura, el módulo implementa el dominio de gestión de riesgo transaccional adquirente, desacoplando la lógica antifraude del core de procesamiento.
SUGA desacopla:
Señales de riesgo → Evaluación → Decisión
permitiendo que el core de procesamiento consuma únicamente una decisión final, sin conocer la complejidad interna del antifraude.
Rol del módulo dentro de la plataforma
El módulo se integra con:
- Smart Acquiring Core.
- Gestión de Transacciones.
- SmartPOS y canales digitales.
- Medios de Pago.
Su función es evaluar el riesgo de una transacción y devolver una decisión que puede ser:
- Permitir continuar el flujo.
- Bloquear la operación.
- Marcar para revisión.
Enfoque dual del módulo
El módulo de Prevención de Fraude de SUGA combina dos enfoques complementarios:
1. Motor Automático (ML-driven)
Un motor automático basado en machine learning, que:
- Analiza patrones históricos.
- Aprende de comportamientos legítimos y fraudulentos.
- Ajusta modelos de riesgo en el tiempo.
Este motor puede:
- Calcular un score de riesgo.
- Tomar decisiones automáticas según umbrales.
No requiere intervención manual para su operación cotidiana.
2. Motor de Reglas (Rule Engine)
Un motor de reglas configurables basado en condicionales, que permite definir políticas explícitas de prevención de fraude.
Las reglas pueden configurarse considerando múltiples dimensiones.
Dimensiones de reglas
A. Contexto del comercio
- Comercio específico.
- Rubro / MCC.
- Riesgo del comercio (alto / medio / bajo).
- Cantidad de transacciones.
- Tipo de transacciones.
B. Contexto del comprador
- Tipo de operación:
- Tarjeta Presente.
- Tarjeta No Presente.
Para Tarjeta Presente
- Ubicación del POS.
- Monto.
Para Tarjeta No Presente
- Email.
- Número de identificación (DNI, cédula, pasaporte, otro).
- Monto total.
- Moneda.
- Cantidad de ítems.
- Canal no presencial:
- Link de pago.
- Checkout.
C. Contexto del medio de pago
- BIN.
- Tipo:
- Débito.
- Crédito.
- Prepago.
- Marca / Bandera.
flowchart TD
RULES[Motor de Reglas de Fraude]
RULES --> COM[Dimension: Comercio]
RULES --> BUY[Dimension: Comprador / Operacion]
RULES --> PAY[Dimension: Medio de Pago]
%% Dimension Comercio
COM --> C1[Rubro / MCC]
COM --> C2[Cantidad de TRX]
COM --> C3[Nivel de riesgo del comercio<br/>Alto / Medio / Bajo]
COM --> C4[Regla por TPV<br/>Terminal / Punto de Venta]
%% Dimension Comprador / Operacion
BUY --> OP{Tipo de Operacion}
OP -->|Tarjeta Presente| CP[Card Present]
OP -->|Tarjeta No Presente| CNP[Card Not Present]
CP --> CP1[Ubicacion del POS]
CP --> CP2[Monto]
CNP --> CNP1[Email]
CNP --> CNP2[Identificacion]
CNP --> CNP3[Monto total]
CNP --> CNP4[Moneda]
CNP --> CNP5[Cantidad de items]
CNP --> CNP6[Canal digital<br/>Link / Checkout]
%% Dimension Medio de Pago
PAY --> P1[BIN]
PAY --> P2[Tipo<br/>Debito / Credito / Prepago]
PAY --> P3[Marca / Bandera]Beneficios
- Reducción de fraude y contracargos.
- Configuración flexible por adquirente.
- Adaptación a distintos perfiles de comercio.
- Combinación de inteligencia automática y reglas.
Evaluación lógica consecutiva y acciones (Permitir / Revisar / Bloquear)
Se recolectan señales desde las tres dimensiones.
- El motor evalúa reglas con lógica AND/OR.
- Si ninguna regla coincide, la operación se permite.
- Si una regla coincide, dispara la acción definida: Permitir, Revisar o Bloquear.
- La decisión se devuelve al Core para continuar o detener el flujo.
flowchart TD
IN[Inicio evaluacion de fraude<br/>Transaccion entrante] --> D1[Recolectar senales<br/>Comercio + Operacion + Medio de Pago]
D1 --> C[Dimension Comercio<br/>MCC / Cantidad TRX / Riesgo / TPV]
D1 --> O[Dimension Operacion<br/>Presente / No Presente]
D1 --> P[Dimension Medio de Pago<br/>BIN / Tipo / Bandera]
C --> RULES[Motor de Reglas<br/>Condicionales AND/OR]
O --> RULES
P --> RULES
RULES --> EVAL{Regla coincide?}
EVAL -->|No| OK[Accion: Permitir]
EVAL -->|Si| ACT{Accion definida por la regla}
ACT -->|Bloquear| BLK[Accion: Bloquear]
ACT -->|Revisar| REV[Accion: Revisar / Validacion adicional]
ACT -->|Permitir| OK
%% Salida comun
OK --> OUT[Resultado a Core<br/>Continuar flujo]
REV --> OUT
BLK --> OUTComplemento: Listas (Blacklists, Greylists y Whitelists)
Como complemento a los motores de ML y reglas, la Plataforma SUGA incorpora el concepto de Listas, que permite gestionar conjuntos de datos específicos que impactan directamente en la evaluación antifraude de las transacciones.
Las Listas constituyen una herramienta adicional de segmentación y control, utilizada dentro de la configuración de prevención de fraude.
SUGA desacopla:
Identidades / patrones conocidos → Listas → Motor antifraude
permitiendo decisiones determinísticas sobre señales explícitas, complementando la inteligencia automática.
Tipos de Listas
SUGA soporta tres tipos de listas:
Lista Negra (Blacklist)
Contiene valores que deben provocar el rechazo directo de la transacción.
Actualmente solo se permiten los siguientes tipos de datos:
- Identificación.
- Email.
- Número de tarjeta.
Lista Gris (Greylist)
Contiene valores que disparan una validación o revisión adicional.
Las transacciones que caen en lista gris pasan a un flujo de revisión configurable, que puede solicitar:
- Video.
- Foto.
- Ninguna validación (solo marcado para revisión).
Lista Blanca (Whitelist)
Contiene valores considerados confiables, que pueden ser exceptuados de determinadas validaciones antifraude.
Tipos de datos soportados en listas
Las listas pueden contener datos del tipo:
- Mail.
- Identificación (CUIT, CUIL, DNI, PASAPORTE, CÉDULAetc.).
- Nombre.
- Teléfono (formato 549... sin + ni espacios).
- Número de tarjeta (completo cuando los emisores lo aportan y el sistema enmascara).
- Otros.
Prioridad de evaluación
El orden de evaluación es:
- Lista Negra.
- Lista Gris.
- Lista Blanca.
Es decir, si un dato está presente en más de una lista, prevalece siempre la lista negra.
Ejemplo: Si un DNI está en lista negra y también existe en lista blanca, la transacción será rechazada.
Relación entre Listas y Prevención de Fraude
Las listas se integran directamente dentro de la configuración de prevención de fraude, actuando como una señal adicional evaluada por el motor.
De esta forma, el flujo conceptual queda:
Señales → Listas → Reglas → ML → Decisión
Trazabilidad
Si una transacción fue impactada por una lista:
- El administrador puede ver desde “Mostrar más información” qué lista la filtró.
- Se visualiza el tipo de lista y quién la cargó.
flowchart LR
CH[Canal de Aceptacion<br/>POS / Checkout / Link / QR] --> CORE[Smart Acquiring Core<br/>Inicio evaluacion]
CORE --> SIG[Sennales de riesgo<br/>Comercio + Comprador + Operacion + Medio de Pago]
SIG --> LST{Evaluacion de Listas}
LST -->|Blacklist| BLK[Decision: Rechazar]
LST -->|Greylist| GRY[Decision: Revisión / Validación]
LST -->|Whitelist o Sin match| RULES[Motor de Reglas<br/>Condicionales configurables]
RULES --> ML[Motor Automatico ML<br/>Score + umbrales]
ML -->|Permitir| OK[Decision: Permitir]
ML -->|Bloquear| NOK[Decision: Bloquear]
ML -->|Revisar| REV[Decision: Revisión]
OK --> TX[Gestion de Transacciones<br/>Actualiza estado + SmartCupon]
NOK --> TX
REV --> TX
TX --> NEXT[Continua flujo<br/>Autorizacion / Post-proceso]