Tradicionalmente, la lucha contra el fraude en productos digitales se basaba en rígidas reglas basadas en reglas o moderación manual, lo que conducía a una alta carga operativa y rigidez del sistema. Con el desarrollo del aprendizaje automático, las empresas comenzaron a implementar SDK de Detección de Fraude en Tiempo Real, que puntúan cada transacción en función de la probabilidad de fraude. La dificultad clave radica en que cualquier clasificador comete errores de dos tipos: Falsos Positivos (bloqueo de un usuario legítimo) reduce directamente los ingresos, mientras que Falsos Negativos (omisión de fraude) incrementa las devoluciones de cargo. Para el negocio, es crítico medir la compensación entre estos errores para optimizar los umbrales de puntuación.
El A/B testing estándar no es posible, ya que la omisión intencionada de transacciones fraudulentas en el grupo de control es inaceptable desde el punto de vista de la reputación y los requisitos de FinCEN/PCI-DSS. La simple comparación de métricas antes y después de la implementación se ve distorsionada por la estacionalidad de los ataques fraudulentos y la auto-selección de usuarios (los más leales descargan la aplicación). Los usuarios con alto riesgo de fraude tienen una conversión inicial diferente a la de los de bajo riesgo, por lo que la comparación ingenua entre aprobados y rechazados proporciona una estimación sesgada debido a confusión por indicación.
El método óptimo es el Diseño de Discontinuidad de Regresión (RDD) alrededor del umbral de puntuación de fraude (por ejemplo, 0.7), donde ocurre un cambio abrupto en la probabilidad de aprobación de 1 a 0. Comparamos transacciones con puntuación 0.69 (tratamiento, aprobado) y 0.71 (control, rechazado), asumiendo aleatoriedad local en el intervalo de banda (±0.05). Utilizamos Regresión Lineal Local con un núcleo triangular para estimar el LATE (Efecto de Tratamiento Promedio Local). Para aumentar la precisión, aplicamos RDD Ajustado por Covariables, añadiendo predictores (historia del dispositivo, geolocalización) como variables de control. Para estimar los ingresos netos, calculamos los Ingresos Incrementales: la diferencia entre el fraude prevenido (cargo esperado) y los ingresos perdidos debido a falsos positivos, identificados a través de RDD.
En una aplicación móvil de un mercado, después de integrar el SDK de Detección de Fraude de un proveedor externo, la tasa de conversión total a compra disminuyó del 4.2% al 3.5%, mientras que la tasa de fraude cayó del 2.8% al 0.4%. El equipo de producto sospechaba que el sistema era demasiado agresivo y bloqueaba a usuarios legítimos viables, pero no podía evaluar cuantitativamente la magnitud del problema debido a la falta de un grupo de control.
Opción A: Comparación simple de la conversión antes y después de la implementación (análisis pre-post). Pros: esfuerzo mínimo, no requiere infraestructura especial. Contras: ignora completamente la estacionalidad (el periodo tras la implementación coincidió con el inicio de una temporada baja), auto-selección al actualizar la aplicación y cambios en el mix de marketing (se lanzó un nuevo canal con baja conversión).
Opción B: Segmentación geográfica (ciudades Grupo A con sistema activado, Grupo B sin). Pros: crea un grupo de control limpio. Contras: técnicamente imposible debido a la única base de código y a la caché de CDN; los usuarios migran entre ciudades; el perfil de fraude varía significativamente entre regiones (heterogeneidad horizontal).
Opción C: Diseño de Discontinuidad de Regresión basándose en la puntuación de fraude continua alrededor del umbral de corte 0.65. Pros: utiliza un experimento natural, garantiza la aleatoriedad local, permite aislar el efecto causal para transacciones "marginales". Contras: requiere un gran volumen de datos en la ventana del umbral; estima LATE, que puede diferir de ATE para toda la población; sensible a manipulaciones de puntuaciones (los defraudadores pueden aprender a evitar el umbral).
Opción D: Método de Control Sintético, creación de una combinación ponderada de cohortes históricas para simular un grupo de control. Pros: funciona sin un grupo de control físico, tiene en cuenta las tendencias temporales. Contras: supone que los factores de influencia son estables en el tiempo; sensible a los outliers en el preprocesamiento; difícil de validar excepto a través de pruebas de placebo.
Se eligió la Opción C (RDD) con un ancho de banda de 0.08 y un polinomio de primer grado. El análisis mostró que para transacciones con un monto >15,000 ₽, la tasa de falsos positivos era el doble que para compras pequeñas. Basado en esto, se ajustaron los umbrales dinámicamente por categoría de producto.
Resultado: Se logró evaluar cuantitativamente que 0.6 puntos porcentuales de la pérdida de conversión de 0.7 se debían a falsos positivos. Después de calibrar los umbrales, se recuperó el 45% de los ingresos perdidos (≈18 millones ₽ al mes) manteniendo el 90% de efectividad contra el fraude.
¿Cómo distinguir el efecto causal del sesgo de selección, cuando los usuarios con alta puntuación de fraude tienen inicialmente una menor propensión a comprar, incluso si no existieran sistemas de fraude?
Respuesta: Este es un problema clásico de confusión por indicación, cuando la indicación del tratamiento (alto riesgo) está correlacionada con el resultado. En RDD, es crítico verificar el balance de covariables en la ventana de ancho de banda: comparar la distribución de la antigüedad del dispositivo, el historial de compras, la geolocalización entre grupos ligeramente por debajo y ligeramente por encima del umbral. Si se observa un desbalance, es necesario aplicar el RDD corregido por sesgo incluyendo covariables en la regresión o utilizar el enfoque de Aleatorización Local, testeando formalmente la hipótesis sobre la aleatoriedad de la distribución. Sin esta verificación, la evaluación del efecto se confundirá con diferencias preexistentes entre usuarios de alto y bajo riesgo.
¿Por qué la comparación simple de la tasa de aprobación entre usuarios que han pasado por diferentes versiones del modelo (v1 y v2) no permite evaluar correctamente el efecto de la mejora del algoritmo?
Respuesta: Esta comparación sufre de sesgo de selección por variables no observables y deriva composicional. El nuevo modelo v2 puede aplicarse selectivamente (por ejemplo, solo a nuevos usuarios o en regiones piloto), creando grupos no comparables. Además, la mejora en la calidad de la puntuación cambia la composición de los usuarios aprobados: v2 puede aprobar "zonas grises" que v1 rechazaba, pero estos usuarios tienen una conversión diferente. Para una evaluación correcta, es necesario utilizar Evaluación de Políticas Offline con Ponderación de Propensión Inversa (IPW) o Estimación Doble Robusta sobre logs históricos, evaluando el contrafactual de qué ingresos habría generado v1 en las mismas transacciones que v2.
¿Cómo abordar el problema de retroalimentación retrasada, cuando el fraude se confirma después de 30 días (devolución), y los analistas necesitan una evaluación del efecto en 7 días para decisiones operativas?
Respuesta: Esto crea un problema de datos censurados (censored data) y asimetría en la evaluación. Para transacciones de los últimos 30 días, no conocemos la etiqueta verdadera (fraude/no fraude). La solución es utilizar Análisis de Supervivencia (modelo de riesgos proporcionales de Cox) para evaluar el tiempo hasta el fraude, permitiendo trabajar con datos incompletos. Alternativamente, se pueden usar Métricas Sustitutas (por ejemplo, características de velocidad, cambios en el dispositivo durante la sesión) que correlacionen con el futuro fraude, como proxy. Es importante entender que los falsos positivos son visibles de inmediato (rechazo instantáneo), mientras que los falsos negativos se revelan con retraso, lo que distorsiona la precisión hacia arriba en un horizonte corto. Para RDD, se recomienda usar datos "congelados" con un retraso de 30+ días, aceptando la pérdida de frescura a favor de la corrección de la inferencia causal.