En otras palabras: no gana la variable “más linda”, sino la que sigue sirviendo cuando el fraude cambia y el negocio la necesita en producción.

Detección de Fraude Financiero con Machine Learning | Conceptos Clave y Ejemplos

Fuentes de datos y variables candidatas para modelos de fraude

Antes de elegir variables, conviene mapear qué datos tenés a mano: pedido, cliente, dispositivo e interacciones por WhatsApp e Instagram. El punto de partida es simple: ver qué fuentes aportan señal de fraude desde el día uno y cuáles meten ruido. Recién ahí tiene sentido pasar de “datos sueltos” a señales que se puedan medir.

Variables de transacción, cliente y dispositivo

En los datos transaccionales, suelen rendir bien señales como el monto en AR$, la moneda y el BIN. En el perfil del cliente, sirven la antigüedad de la cuenta, el historial de pedidos, la tasa de devoluciones, el ticket promedio, el dominio del email y el prefijo del teléfono. Del lado del dispositivo y la red, la IP, el ISP, el uso de proxy y el identificador del dispositivo ayudan a armar contexto.

Un ticket alto, por sí solo, dice poco. Pero si aparece junto con una cuenta recién creada y una IP fuera de lo común, empieza a contar otra historia.

Cuando el comportamiento no alcanza, el canal de atención suma una capa más de contexto.

Señales de WhatsApp e Instagram

Las conversaciones con clientes pueden aportar contexto si ese historial queda unido al pedido y al cliente. Si las interacciones de WhatsApp e Instagram se conectan al pedido en tiempo real, ese contexto puede entrar en las variables candidatas sin perder trazabilidad.

Cómo convertir datos crudos en variables candidatas

Los datos crudos tienen que pasar por una transformación antes de entrar al modelo. La idea es llevarlos a variables comparables y estables. Un esquema simple puede verse así:

Más del 50 % de las transacciones fraudulentas en algunos datasets de e-commerce provienen de cuentas creadas hace menos de 52 días. Por eso, la antigüedad de la cuenta suele ser una de las variables más simples y efectivas para arrancar. La pregunta que ordena el trabajo es esta: ¿qué patrón de fraude busca detectar esta variable?

Una vez armadas, estas variables ya pueden pasar a filtros de calidad y selección.

Controles de calidad de variables antes de la selección

Después de armar las variables candidatas, el error más común es rankearlas sin un control previo. Antes de hacer eso, hay que sacar del camino las que no sirven en producción. Una variable con fuga de información, muchos faltantes o una definición distinta entre sistemas puede tirar abajo el modelo, aunque el algoritmo esté impecable.

Con las variables candidatas ya definidas, el filtro arranca por descartar las que contaminan el entrenamiento.

Fuga de datos, valores faltantes y variables inestables

La fuga de datos es uno de esos problemas que no hacen ruido al principio, pero pegan fuerte después. En fraude, aparece cuando una variable usa información que todavía no existiría en el momento de tomar la decisión. Y la regla acá es simple: si esa variable no está disponible al decidir, no puede entrar al modelo.

También conviene dejar una ventana de maduración de 90 días. Muchos fraudes recientes todavía no fueron reportados, así que no sirven como etiquetas finales.

El segundo riesgo no siempre es una fuga directa. A veces es un sesgo de observación. Si el modelo rechaza pedidos de forma automática, esos casos dejan de verse después y eso sesga la selección de variables. Dicho de otro modo: el modelo empieza a aprender de una foto recortada.

Con los valores imposibles, como edades negativas, no hay mucho misterio. Reemplazalos por la mediana o marcálos como nulos. Y ojo con otro punto que suele pasarse por alto: la estabilidad en el tiempo. El Population Stability Index (PSI) sirve para medir si la distribución de una variable cambió entre entrenamiento y producción. Si el PSI da más de 0,2, esa variable deja de ser confiable y hay que revisarla.

Categorías de alta cardinalidad y baja frecuencia

Variables como el SKU, el dominio del email o la dirección IP comparten el mismo problema: tienen demasiadas categorías únicas. Cuando una categoría aparece muy pocas veces, el modelo le puede dar una importancia que después no se sostiene en producción.

El problema de fondo es simple. Las categorías raras empujan al modelo a memorizar casos puntuales, en lugar de aprender patrones. Por eso conviene agrupar las categorías poco frecuentes o codificarlas por frecuencia. Eso ayuda a bajar importancias inestables y evita que el modelo se enganche con ruido.

Si una variable no se sostiene en el tiempo, no entra en la selección.

Métodos de selección de características para datos de fraude

Con las variables ya limpias, el paso siguiente es quedarse con las que de verdad aportan señal, sin inflar los falsos positivos. La idea es simple: primero sacar ruido en datos de transacciones, dispositivo, comportamiento y categorías de alto riesgo. Después, afinar la selección con ayuda del modelo.

Métodos de filtro para un primer filtrado

Los métodos de filtro miran cada variable por separado. Sirven para hacer una primera poda antes del modelado y achicar el espacio de trabajo.

El umbral de varianza elimina variables casi constantes. La correlación de Pearson ayuda a encontrar redundancia entre variables numéricas. Chi-cuadrado mide la asociación entre variables categóricas y fraude. Y la información mutua detecta relaciones no lineales.

Ojo con un punto: este enfoque puede dejar pasar variables muy correlacionadas entre sí. En ese caso, sumás redundancia, pero no señal predictiva extra. Por eso, el filtro funciona más como una limpieza inicial que como decisión final.

Métodos wrapper y embedded para selección guiada por el modelo

Cuando el filtro ya achicó el problema, entran los métodos guiados por el modelo. Acá ya no se evalúa cada variable sola, sino cómo funciona dentro del conjunto.

RFE reentrena el modelo en cada vuelta y va descartando variables de forma iterativa. Suele dar buenos resultados, pero paga ese resultado con más costo de cómputo. Los métodos embedded, como XGBoost, calculan importancia durante el entrenamiento, sin tener que reentrenar una y otra vez. Y SHAP ayuda a revisar el efecto de cada variable en casos puntuales, algo muy útil cuando querés conectar lo que dice el modelo con decisiones de negocio.

Ese ranking, por sí solo, no alcanza. Hace falta validarlo en orden temporal.

Validación temporal para evitar fuga

En fraude, conviene evitar la validación cruzada aleatoria. Mezcla pasado y futuro, y eso suele inflar el rendimiento de forma engañosa. Dicho de otro modo: no alcanza con elegir las “mejores” variables si esa elección se probó con una evaluación poco realista.

El corte temporal fijo separa entrenamiento y evaluación sin mezclar períodos. Es una opción directa y útil cuando querés replicar mejor un escenario de producción. La validación rolling mueve la ventana de entrenamiento y evalúa sobre datos nuevos en cada paso. Eso permite seguir mejor los cambios en las tácticas de fraude, aunque exige más cómputo.

Cómo comparar subconjuntos de variables con métricas de negocio

Para comparar subconjuntos, mirá métricas que peguen en el negocio: PR-AUC, recall de fraude, precisión en el top de riesgo, exposición a contracargos y tasa de falsos rechazos.

Acá el equilibrio importa mucho. Un recall alto con baja precisión puede frenar ventas válidas y meter fricción donde no hacía falta. En el otro extremo, un umbral demasiado permisivo sube la exposición a contracargos, sobre todo en pedidos de mayor valor en AR$. El subconjunto que sirve no es el que gana en una sola métrica, sino el que sostiene el recall sin disparar falsos rechazos.

Con ese criterio, ya podés decidir qué variables siguen en juego según el impacto comercial y el riesgo operativo.

Estrategias de selección específicas para fraude en e-commerce

Las señales más fuertes: pagos, comportamiento y geolocalización

Con los subconjuntos ya filtrados, el paso que sigue es simple: dar prioridad a las familias de señales que suman riesgo nuevo y ayudan a bajar falsos positivos.

Una vez limpio el subconjunto, conviene ordenar las señales por aporte incremental: pagos, dispositivo, comportamiento y geolocalización. En fraude de e-commerce, suelen funcionar mejor las señales de velocidad - como card_txn_count_1h o ip_txn_count_5m - , la huella del dispositivo y las señales de comportamiento cuando el caso apunta a bots o robo de credenciales.

En operaciones sin tarjeta presente, donde se concentra entre el 60 % y el 70 % de las pérdidas globales por fraude con tarjeta, las diferencias entre IP, facturación y envío siguen siendo una señal clave.

Evaluar grupos de variables, no variables sueltas

No mires cada variable por separado. Mirá la importancia por familias - pagos, dispositivo, logística y comportamiento - y medí cuánto suma cada grupo sobre el modelo base.

Si un grupo no mejora la precisión cuando ya tenés cubiertas las señales de velocidad y la huella del dispositivo, podés recortarlo sin perder cobertura. Eso también ayuda a bajar falsos rechazos. Y acá el costo es alto: el 33 % de los clientes legítimos no vuelve a comprar después de un rechazo erróneo.

Señales conversacionales como dato complementario

Después podés sumar señales conversacionales, pero solo si mejoran la decisión en tiempo real. Si usás Burbuxa, estas señales se pueden unificar con pedidos y clientes en tiempo real para agregar contexto sin romper la trazabilidad.

Tomalas como señales auxiliares. No reemplazan pagos ni dispositivo, pero sí pueden inclinar la balanza cuando el caso es ambiguo.

Límites legales y de privacidad en Argentina y LATAM

Cada variable tiene que poder justificarse. En Argentina y en la UE, la latencia, la precisión y la explicabilidad forman parte del cumplimiento, no solo del modelo.

Si operás con PSD2, la Strong Customer Authentication (SCA) puede omitirse en transacciones de bajo riesgo de hasta € 500 siempre que la tasa de fraude se mantenga por debajo de 0,01 %. La regla práctica es clara: si no podés auditar una variable, explicarla y defenderla, no debería entrar.

Ejemplos prácticos de selección de características en fraude e-commerce

Con los criterios de selección ya definidos, toca ver algo clave: las variables no pesan igual en todos los fraudes. Cambian según el problema que querés detectar.

Caso hipotético: fraude sin tarjeta presente en el checkout

Imaginá una tienda de electrónica que necesita puntuar cada pedido en tiempo real. El objetivo del modelo es detectar credenciales de pago robadas antes de confirmar la compra.

En este caso, las variables que suelen pasar el filtro son el monto de la transacción, el país del BIN de la tarjeta, la distancia entre la IP y la dirección de envío, y las señales de velocidad, como el conteo de transacciones en una ventana corta. ¿Por qué estas y no otras? Porque suelen estar listas en tiempo real y dan una señal directa justo en el checkout. Conviene dejar afuera variables sin señal directa o que después fallen en producción.

También pueden entrar señales de comportamiento, como compras en ráfaga o actividad en horarios atípicos, pero solo si se calculan sobre una ventana temporal bien definida. Acá manda la señal que existe en el momento de decidir, no la que aparece más tarde.

En este tipo de fraude, la prioridad está en detectar señales inmediatas de pago y ubicación.

Caso hipotético: abuso de cuentas y mal uso de promociones

Cuando el fraude apunta a la identidad, la selección pone el foco en la consistencia de la cuenta y en señales de uso automatizado.

Acá las variables cambian bastante. La combinación más útil suele incluir la antigüedad de la cuenta, la calidad del dominio de email, la frecuencia de uso de códigos promocionales y la cantidad de cuentas que comparten el mismo dispositivo o la misma dirección de envío. Una señal muy útil es el tiempo entre la creación de la cuenta y el primer checkout: si ese intervalo es muy corto y la navegación fue directa a un ítem con descuento, suele ser un buen indicio de abuso. Las cuentas sintéticas también tienden a mostrar patrones demasiado regulares, como movimientos de mouse lineales o formularios completados al instante.

La diferencia entre los dos casos se ve más clara cuando los comparás por objetivo y por criterio de descarte.

Un error muy común es usar el mismo set de variables para los dos problemas. Y ahí es donde todo se mezcla. Cada caso pide revisar las variables por separado y validarlas con un corte temporal claro.

Flujo de implementación y conclusión

Paso a paso para un proyecto de fraude en producción

Con el subconjunto de variables ya definido, entra la parte más delicada: ponerlo a funcionar sin perder señal ni sumar demora. El primer paso es dejar bien claro qué fraude querés detectar: fraude sin tarjeta presente o abuso de cuentas. Si esa base no está clara, después se complica priorizar variables y fijar umbrales.

Armá una base histórica de al menos 12 meses para captar estacionalidad. Además, trabajá solo con casos cuyo resultado ya se conoce: pagos válidos y contracargos confirmados.

Antes de salir a producción, medí la latencia de decisión. En CNP, debería quedar por debajo de 250 ms. Si pasa los 300 ms, cada 100 ms extra puede costar 1,5% de conversión. En fraude, esos milisegundos pesan más de lo que parece.

Después, corré el modelo en modo sombra, sin tocar decisiones reales. Cuando eso esté estable, probalo con un esquema campeón/desafiante sobre entre 5% y 10% del tráfico antes de escalar.

Monitoreo de variables después del lanzamiento

La selección no termina cuando el modelo entra en producción. En fraude, el rendimiento cambia con el tiempo, a veces de forma bastante brusca. Por eso, en producción conviene seguir de cerca el PSI, la tasa de rechazos automáticos y los contracargos tardíos.

Un PSI mayor a 0,2 marca deriva y pide recalibración. Si el volumen de rechazos automáticos sube sin una causa clara, puede ser una señal de que el set de variables está empujando demasiados falsos positivos. También hace falta reentrenar con una ventana que respete el desfase real de los contracargos.

Errores frecuentes al seleccionar variables de fraude

Cuando el monitoreo muestra deriva, muchas veces el problema nace en la selección de variables o en la ventana de validación. Los errores que más cuestan suelen aparecer cuando se rompe una regla simple: usar solo señales disponibles en el momento de decidir.

El leakage infla métricas y después se derrumba en producción. La validación aleatoria tampoco sirve en fraude; usá cortes temporales. Y para alinear el umbral con la capacidad diaria de revisión, usá Precision@k.

Conclusión: por dónde empezar

Conviene arrancar con un problema bien definido, etiquetas confiables y validación temporal. También ayuda separar la ingeniería de características de la selección y medir impacto en métricas de negocio reales, no en accuracy. Eso es lo que sostiene el modelo cuando cambian los patrones de fraude.

La selección de características no se hace una sola vez. Es un proceso continuo. Empezá por variables disponibles en tiempo real, medilas con corte temporal y revisalas en producción.

FAQs

¿Cómo sé si una variable tiene fuga?

Una variable tiene fuga (data leakage) cuando mete información sobre el resultado que el modelo no debería tener al momento de predecir. ¿El problema? El rendimiento parece mejor de lo que es.

Para evitar eso, definí un tiempo de corte que deje afuera cualquier dato posterior. Y hacé la selección de variables solo con los datos de entrenamiento.

Si usás el conjunto de validación para elegir características, las métricas quedan invalidadas. Es como mirar las respuestas antes del examen: el resultado mejora, pero no refleja lo que va a pasar en uso real.

¿Cada cuánto conviene revisar el set de variables?

Revisar el set de variables tiene que ser un trabajo continuo. El fraude es un problema adversarial: los atacantes cambian de táctica rápido, prueban caminos nuevos y buscan grietas todo el tiempo.

Por eso, no existe una sola periodicidad que sirva para todos los casos. Aun así, hacer análisis batch diario o post-liquidación suele ayudar mucho para detectar patrones, calibrar reglas y ajustar modelos.

De esa forma, el sistema puede responder a nuevos esquemas de fraude y evitar que los modelos queden viejos. Además, técnicas como RFE sirven para volver a evaluar las variables y sacar las que pierden peso o pasan a ser redundantes.

¿Qué variables priorizo según el tipo de fraude?

Depende del tipo de fraude que quieras frenar. Conviene poner el foco en variables de transacción, del usuario y del contexto técnico y geográfico.

En transacción, mirá el monto, el medio de pago, la frecuencia y la velocidad de compra. Ahí suelen aparecer señales claras: compras muy seguidas, importes fuera de lo normal o patrones que no cierran.

Del lado del usuario, sirven la antigüedad de la cuenta, la biometría conductual y el historial de pedidos. No es lo mismo una cuenta nueva con movimientos raros que un cliente con meses de actividad pareja.

También pesa el contexto técnico y geográfico: IP, geolocalización y huella del dispositivo. A veces el problema no está en una sola señal, sino en el cruce de varias. Por ejemplo, una compra desde un dispositivo nuevo, en otra ubicación y a una hora poco habitual.

Además, procesá esas variables con hora local, ART (UTC-3), para detectar horarios inusuales. Ese ajuste parece menor, pero cambia mucho la lectura de los datos.

Para limpiar ruido y quedarte con lo que más aporta, técnicas como RFE o Chi-cuadrado suelen funcionar bien.