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 > 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 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]