--- title: Módulo de prevención de fraude slug: modulo-de-prevencion-de-fraude docTags: createdAt: 2026-01-24T18:53:16.633Z --- # 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. ::::hint{type="success"} SUGA desacopla: :::BlockQuote 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. ```mermaid 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
Alto / Medio / Bajo] COM --> C4[Regla por TPV
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
Link / Checkout] %% Dimension Medio de Pago PAY --> P1[BIN] PAY --> P2[Tipo
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. 1. El motor evalúa reglas con lógica AND/OR. 2. Si ninguna regla coincide, la operación se permite. 3. Si una regla coincide, dispara la acción definida: **Permitir**, **Revisar** o **Bloquear**. 4. La decisión se devuelve al Core para continuar o detener el flujo. ```mermaid flowchart TD IN[Inicio evaluacion de fraude
Transaccion entrante] --> D1[Recolectar senales
Comercio + Operacion + Medio de Pago] D1 --> C[Dimension Comercio
MCC / Cantidad TRX / Riesgo / TPV] D1 --> O[Dimension Operacion
Presente / No Presente] D1 --> P[Dimension Medio de Pago
BIN / Tipo / Bandera] C --> RULES[Motor de Reglas
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
Continuar flujo] REV --> OUT BLK --> OUT ``` ## Complemento: 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. ::::hint{type="success"} SUGA desacopla: :::BlockQuote 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: 1. Lista Negra. 2. Lista Gris. 3. Lista Blanca. Es decir, si un dato está presente en más de una lista, **prevalece siempre la lista negra**. :::hint{type="info"} 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: :::BlockQuote 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ó. ```mermaid flowchart LR CH[Canal de Aceptacion
POS / Checkout / Link / QR] --> CORE[Smart Acquiring Core
Inicio evaluacion] CORE --> SIG[Sennales de riesgo
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
Condicionales configurables] RULES --> ML[Motor Automatico ML
Score + umbrales] ML -->|Permitir| OK[Decision: Permitir] ML -->|Bloquear| NOK[Decision: Bloquear] ML -->|Revisar| REV[Decision: Revisión] OK --> TX[Gestion de Transacciones
Actualiza estado + SmartCupon] NOK --> TX REV --> TX TX --> NEXT[Continua flujo
Autorizacion / Post-proceso] ```