Si querés bajar fraude sin depender de miles de casos etiquetados, un autoencoder puede servirte para marcar compras raras según su error de reconstrucción.
Yo lo resumiría así: el modelo aprende cómo se ve una compra normal, puntúa cada orden con un score de riesgo y me deja decidir si aprobar, pedir verificación, mandar a revisión o bloquear. En un problema donde el fraude puede rondar apenas el 0,172% del total, eso cambia la forma de detectar desvíos.
Antes de meterme en el modelo, me quedo con estas ideas:
También hay un punto muy de Argentina: un monto de $ 250.000 no dice mucho por sí solo. Yo necesito leerlo en contexto, por ejemplo contra el ticket medio del cliente, y además parsear bien formatos locales como coma decimal y punto de miles para no meter ruido desde el arranque.
La idea central es simple: enseñarle al sistema qué es normal en mi tienda y tratar como sospechoso lo que se sale de ese patrón. Con esa base, después ajusto el corte según el costo de falsos positivos, contracargos y revisión manual.
Sigo con un resumen corto del enfoque completo:
En otras palabras: yo arrancaría simple, con buen preprocesamiento, un modelo chico, umbrales claros y un circuito de feedback desde contracargos y revisiones humanas.
Cómo Detectar Fraude en E-commerce con Autoencoders
La calidad del modelo arranca mucho antes del entrenamiento. Si el preprocesamiento está mal hecho, el autoencoder aprende ruido y después marca cualquier cosa. La idea no es solo limpiar datos: hay que armar entradas que ayuden a detectar anomalías de verdad. Con esas variables definidas, el paso siguiente es llevarlas a un formato que el autoencoder pueda usar.
Las variables base son: monto, fecha/hora, método de pago, cupones, cantidad de ítems, dispositivo y navegador, ubicación de la IP, provincia de envío, historial de compras y contracargos.
En Argentina, conviene normalizar el monto o expresarlo como ratio contra el ticket promedio del cliente. Eso ayuda a que una compra de $ 250.000 no se lea igual para todos. Para un cliente que suele comprar por $ 240.000, puede ser normal. Para otro que suele gastar $ 18.000, ya no tanto.
Convertí los timestamps en hora del día y día de la semana, porque suelen mostrar patrones de conducta muy útiles para detectar fraude nocturno.
Después, aplicá StandardScaler para dejar las variables numéricas con media 0 y desviación estándar 1. Esto importa mucho porque el error de reconstrucción cambia según la escala de entrada. Si una variable domina por tamaño, el modelo puede prestar más atención a eso que al patrón raro que querés encontrar.
Las variables categóricas tienen que pasar por one-hot o por label encoding antes del entrenamiento. Y hay un detalle que en datos de Argentina pesa bastante: primero parseá los valores con formato local - coma decimal y punto de miles - antes de convertirlos a número. Si no hacés eso, un monto puede quedar mal leído y arruinar toda la tanda.
También suma agregar variables derivadas, como:
Estas señales agregadas suelen dar mucho contexto y ayudan a separar una compra común de una que hace ruido.
Con las variables ya normalizadas y codificadas, queda el paso que parte la cancha: entrenar casi solo con transacciones legítimas.
El autoencoder tiene que entrenarse casi solo con transacciones legítimas. La lógica es simple: cuando entra una operación fraudulenta que el modelo no vio durante el entrenamiento, le cuesta reconstruirla. Ese error alto pasa a ser una señal de alerta.
Para eso, usá contracargos y revisiones manuales como filtro para sacar fraude confirmado. El fraude puede representar apenas el 0,172% del volumen total, así que el conjunto de entrenamiento debería quedar compuesto casi por completo por transacciones limpias. En la práctica, esto implica entrenar con históricos depurados y dejar afuera los casos ya confirmados como fraude.
Con los datos listos, ya podés pasar a definir la arquitectura y entrenar el modelo.
Con los datos normalizados, definí una red que aprenda cómo se ve una transacción normal y que deje en evidencia los desvíos.
La idea es usar un cuello de botella con menos neuronas que la entrada; por ejemplo, 30 variables → 14 → 7 → 30. Esa compresión obliga a la red a quedarse con lo importante. En la práctica, aprende a reconstruir compras normales y tiende a fallar cuando aparece una transacción rara.
En las capas ocultas, usá ReLU. Para la función de pérdida, lo más usado en datos tabulares es el Error Cuadrático Medio (MSE). Si querés sumar regularización, L1/L2 o Dropout pueden servir para que el modelo no memorice transacciones puntuales y, en cambio, aprenda patrones más generales.
En pruebas recientes, una arquitectura densa profunda rindió mejor que variantes Sparse o Variational, que a veces vuelven demasiado genérico el patrón aprendido y pierden sensibilidad frente a señales de fraude sutiles.
Con esa base definida, ya podés pasar al entrenamiento y a la validación.
Entrená el modelo solo con transacciones legítimas. El punto es simple: querés que aprenda normalidad, no fraude. El flujo básico consiste en separar los datos en entrenamiento y validación, entrenar únicamente con operaciones legítimas y dejar los casos de fraude confirmados para prueba.
Mientras entrena, seguí de cerca el error de entrenamiento y el de validación. Si el error de validación empieza a subir mientras el de entrenamiento sigue bajando, el modelo se está sobreajustando. Cuando pasa eso, conviene tocar la regularización o achicar la capacidad de la red.
Una vez entrenado, el error de reconstrucción de cada transacción pasa a ser su score de riesgo. Ese score decide qué órdenes pasan sin fricción y cuáles necesitan control extra.
El umbral suele fijarse con el percentil 95 o 99,5 de la distribución de errores del conjunto de validación. Para elegirlo bien, mirá curvas de Precisión-Recall. En datasets tan desbalanceados, la curva ROC puede dar una idea demasiado optimista del desempeño.
Las tres bandas operativas suelen quedar así:
Ese umbral no conviene dejarlo quieto. Recalibralo de manera periódica.
Con el score ya armado, el siguiente paso es llevarlo al checkout y a los flujos de revisión.
Con el umbral ya definido, el paso que sigue es llevar ese score al trabajo de todos los días: el checkout y los canales de atención. Acá hay una idea simple que pesa mucho: la inferencia tiene que ser rápida y con la menor fricción posible.
La decisión clave al desplegar el modelo es cuándo correr el scoring. Las dos opciones principales cambian tanto la latencia como el momento en que se toma la decisión:
| Característica | Scoring en tiempo real | Revisión en lote |
|---|---|---|
| Latencia | Menos de 100 ms (durante el checkout) | Minutos a horas (después de la compra) |
| Momento de detección | Bloquea antes de autorizar el pago | Identifica fraude después de autorizada la transacción |
En la práctica, muchas veces conviene combinar scoring en tiempo real para el checkout con revisión en lote para auditorías de casos intermedios. Dicho de otro modo: una parte de la decisión se toma al instante, y otra queda para revisar con más calma. Con ese esquema, el score pasa a activar reglas de negocio tanto en checkout como en atención.
El error de reconstrucción del autoencoder se usa como el score que dispara las reglas del checkout. A partir de ahí, conviene trabajar con bandas de score para definir qué pasa con cada orden:
Hay un punto que no conviene pasar por alto: los cortes no deberían salir de números fijos. Tienen que venir de la validación del modelo.
También suma ajustar la operación según señales que ya mostraron peso en fraude. Por ejemplo, se pueden aplicar umbrales más estrictos de forma automática para cuentas creadas hace menos de 52 días, ya que representan más del 50 % de los casos de fraude. Lo mismo para transacciones entre las 00:00 y las 05:00 horas, donde la incidencia de fraude es significativamente mayor.
Y hay algo más: cada decisión del equipo importa. Si una orden retenida se aprueba o se rechaza, ese resultado tiene que volver al sistema como etiqueta. Ese loop de feedback sirve para recalibrar el modelo y ajustar las reglas con datos del negocio, no con suposiciones.
Cuando una orden queda en revisión, la comunicación con el cliente pasa a ser parte del proceso. No alcanza con detectar riesgo; también hay que gestionar bien ese contacto.
Burbuxa automatiza la verificación por WhatsApp e Instagram y deriva los casos más complejos al equipo con todo el contexto, integrándose de forma directa al flujo de respuesta al fraude.
Cuando el modelo ya está en producción, empieza a trabajar con datos que no son iguales a los que vio durante el entrenamiento. Y ahí aparece un problema muy común: el autoencoder aprendió qué era “normal” en un momento puntual, pero ese “normal” cambia. Puede cambiar por inflación en ARS, por nuevos hábitos de compra o por temas estacionales. Cuando eso pasa, el drift mueve el score y puede dejar viejos los cortes que habías definido.
Por eso conviene seguir el error a lo largo del tiempo. No alcanza con mirar si el modelo sigue corriendo: hay que ver cómo está respondiendo. En la práctica, sirve monitorear la media, el desvío estándar, los mínimos y máximos de los montos, además de los horarios de compra. Si esos valores se corren respecto del set de entrenamiento, el modelo puede empezar a perder lectura sobre el comportamiento legítimo actual.
Dicho simple: si la realidad cambió y el modelo no cambió con ella, las alertas empiezan a degradarse.
Cuando esos cambios aparecen, hay que reentrenar. El fraude cambia todo el tiempo, y el modelo tiene que volver a aprender patrones nuevos.
Este proceso suele tener tres frentes:
Acá hay un punto que pesa bastante. AUPRC suele ser una mejor métrica en datasets muy desbalanceados, porque el ROC puede mostrar una imagen más optimista de la que después se ve en operación.
Después de cada reentrenamiento, recalibrá el umbral usando la nueva distribución de errores. Así, el ajuste deja de hacerse “a ojo” y pasa a apoyarse en indicadores concretos.
Los autoencoders sirven porque aprenden patrones normales sin pedir ejemplos etiquetados de fraude. Pero esa ventaja no se sostiene sola. Depende de entrenar con datos legítimos de buena calidad y de mantener un ciclo claro de mejora: datos nuevos → drift → reentrenamiento → umbral nuevo.
La idea, al menos al principio, es ir por algo simple y útil: monitorear drift, reentrenar con datos recientes y recalibrar umbrales según el costo del error. Eso implica mirar de frente los falsos positivos, los falsos negativos y también lo que surge de las revisiones manuales.
Implementado de esa manera, un sistema de detección de fraude con autoencoders puede reducir las pérdidas por fraude hasta un 25%.
No necesitás un volumen masivo de datos etiquetados. Un autoencoder aprende, ante todo, de los datos normales: se entrena con la estructura de las transacciones legítimas y, por contraste, detecta anomalías.
Aunque muchos estudios usan cientos de miles de registros para validar resultados, su punto fuerte está en trabajar con muestras representativas del comportamiento estándar.
Para bajar los falsos positivos, entrená el autoencoder solo con transacciones legítimas. Así aprende a reconstruir con precisión el patrón normal y no marca como sospechoso todo lo que apenas se sale de lo esperado.
Además, conviene ajustar el umbral de detección. Por ejemplo, podés usar el percentil 99 del error de reconstrucción para separar mejor las anomalías reales de las variaciones legítimas.
No hay una frecuencia fija que sirva para todos los casos. Un modelo de fraude necesita reentrenarse porque el fraude cambia con el tiempo y, además, intenta parecerse cada vez más a un comportamiento legítimo.
Si el modelo no se actualiza con datos transaccionales nuevos, pierde eficacia. Por eso, en e-commerce conviene hacer reentrenamientos periódicos.
La frecuencia ideal no sale de una regla general. Depende, sobre todo, de dos cosas:
Dicho simple: cuanto más movimiento tenga la operación y cuanto más cambie el comportamiento de usuarios y estafadores, más seguido conviene revisar y reentrenar el modelo.
