En la Parte 1 de nuestra serie de blogs sobre falsos positivos, aceptamos la realidad de que tu sistema no está diseñado para informar de sus propios errores. Hablamos sobre usar la triangulación para sortear esa limitación y generar una imagen útil de tus falsos positivos.
Ahora viene el siguiente problema.
Cuantificar los falsos positivos es solo una observación. No es un plan.
Para reducir los falsos positivos de manera significativa, hay que ir un nivel más profundo y plantear un conjunto diferente de preguntas:
- ¿De dónde vienen?
- ¿Cuáles están impulsados por socios?
- ¿Cuáles son en realidad problemas de calidad de datos que se hacen pasar por riesgos de fraude?
- Y, lo más importante: ¿por dónde deberíamos empezar?
De eso trata esta segunda parte de la serie: desglosar tus falsos positivos en grupos que puedas priorizar y abordar.
¿Cómo se hace eso? Todo se reduce a un proceso de 7 pasos.
Flujo A: Agrupar los falsos positivos por actor y solución
Paso 1: ¿Quién rechazó realmente el evento?
El primer y más importante paso es vincular cada falso positivo con el actor que tomó la decisión.
Cuando se rechaza una transacción o se bloquea un intento de incorporación, alguien o algo dijo "no".
Esa persona podría ser:
- Una regla en tu sistema
- Un umbral de modelo de aprendizaje automático
- Un agente de IA
- Un analista humano en revisión manual
- Un socio externo: un banco, emisor, adquirente o proveedor de servicios contra el fraude
Sin esta categorización, tenderás a optimizar las cosas que puedes ver, normalmente tus reglas y tus modelos.
Así es como los equipos pasan meses ajustando minuciosamente las reglas, solo para descubrir después que la mayoría de sus rechazos provenían de un emisor con el que nunca habían hablado.
La primera tarea es esencialmente contable: para cada rechazo, registra qué actor tomó la decisión.
A veces será una única regla. A veces será una decisión basada en un determinado umbral de puntuación de un modelo. A veces será una anulación manual. A veces será una respuesta binaria que venga de un socio de pagos.
No tienes que hacer esto a la perfección desde el primer día; incluso una división aproximada marca una enorme diferencia.
Paso 2: ¿Qué parte del problema se origina aguas arriba?
Una vez que tengas ese mapa básico, puedes hacerte una pregunta que la mayoría de la gente pasa por alto: ¿cuánto de esto está realmente bajo tu control?
Esto es especialmente importante en los pagos con tarjeta, donde una sola transacción puede pasar por media docena de manos antes de que el emisor finalmente diga que sí o que no.
Entre el titular de la tarjeta y el banco emisor, a menudo se encuentran:
- El propio comerciante o la plataforma
- Un proveedor de servicios de pago
- Un adquirente
- Un procesador adquirente
- Una red de tarjetas
- Un procesador de emisores
- Y, por último, el banco emisor
Y eso sin contar a los proveedores externos de prevención de fraude que algunos de estos actores integran en sus propias plataformas.
Cada uno de estos actores puede rechazar una transacción. Cada uno tiene su propia lógica de riesgo. Cada uno aporta sus propios falsos positivos.
Si el 60% de tus falsos positivos son generados por socios upstream, entonces tu esfera máxima de influencia se limita al 40%.
Eso no significa que debas rendirte y marcharte. Sí significa que deberías replantearte tus objetivos, cómo los comunicas internamente y en qué inviertes tu energía.
No puedes ajustar reglas que no te pertenecen. No puedes modificar modelos que nunca ves. No puedes volver a entrenar el motor de riesgo de un emisor.
Sin embargo, puedes cuantificar el impacto, hacerlo visible y asegurarte de que todos en la organización entiendan dónde están realmente los límites de tu influencia. Solo ese paso evita mucha frustración más adelante.
Desde un punto de vista estratégico, si no estás satisfecho con el desempeño de un socio y consideras que es inferior al estándar, siempre puedes trabajar para reemplazarlo. Pero a menudo seguirás teniendo actores que no controlas y que afectan tus falsos positivos.
Paso 3: Identificar a los peores infractores
Una vez que tengas tus decisiones organizadas en categorías de alto nivel, es momento de ir un nivel más profundo. Toma cada uno de tus vehículos de decisión y descríbelos de forma individual: cada regla, flujo de trabajo, investigador y agente de IA. Aquí es donde necesitas ser muy detallado.
En la práctica, una ejecución perfecta es difícil y requiere mucho tiempo.
Concéntrate primero en las soluciones que generan la mayoría de tus rechazos. Incluso si una regla es relativamente precisa, un alto volumen suele significar que es una fuente principal de falsos positivos.
Cuéntalos por separado e identifica los responsables de la mayor cantidad de falsos positivos en términos absolutos. Estos son tus "quick wins" porque tendrás suficientes datos con los que trabajar.
Al mismo tiempo, tu intuición puede decirte que algunos infractores están pasando desapercibidos: reglas heredadas, políticas obsoletas o soluciones que nunca se validaron adecuadamente.
Si sospechas que una regla de bajo volumen está causando problemas, utiliza una revisión manual para validar tu corazonada. No necesitas un conjunto de datos masivo para identificar una política defectuosa.
Flujo B: Agrupa los falsos positivos por flujo y calidad de los datos
Paso 4: ¿Quién está siendo bloqueado?
Ahora sabemos qué está bloqueando a tus usuarios, pero todavía necesitamos saber de dónde vienen.
Incluso dentro de la parte de la pila que controlas, los falsos positivos rara vez se distribuyen de manera uniforme. Tienden a concentrarse en flujos específicos, como:
- Móvil frente a web
- iOS frente a Android
- Producto
- Método de pago
- Usuarios nuevos vs. establecidos
Si solo miras al actor que rechazó el evento, verás una regla o un modelo comportándose de forma incorrecta. Pero si observas por qué flujo pasó el usuario, podrías encontrar un problema más profundo: un flujo específico que produce datos corruptos o faltantes, lo que hace que toda tu pila falle.
Imagina un error de integración en tu SDK móvil que envía datos de IP incorrectos para los registros en iOS. Al principio no ves ese error. Lo que ves es que varias reglas basadas en geolocalización de repente tienen tasas de falsos positivos más altas en esa plataforma. Un modelo que utiliza características basadas en IP también parece desviarse. Los analistas se quejan de que los eventos que vienen del móvil se ven extraños.
Si solo miras el nivel de las reglas, perderás semanas recalibrando modelos. Al desglosarlo por flujo, te das cuenta rápidamente de que la lógica funciona bien en la web y que el problema está aislado a la ruta de registro en iOS.
No siempre se trata de un error en los datos. Puede que un flujo específico concentre a muchos buenos usuarios que se comportan de manera diferente a tu población general, lo que por sí solo puede aumentar los falsos positivos.
Así que, una vez que hayas agrupado tus falsos positivos por actor, haz lo mismo por recorrido de usuario:
- ¿En qué superficie del producto? (por ejemplo, app vs. escritorio)
- ¿Qué plataforma? (p. ej., iOS vs. Android)
- ¿Qué método de pago? (por ejemplo, Apple Pay vs. tarjeta de crédito)
- ¿Qué región geográfica? (p. ej., mercados de nivel 1 vs. mercados emergentes)
- ¿Qué embudo específico? (por ejemplo, compra como invitado vs. usuario registrado)
Los patrones surgirán muy rápidamente.
Paso 5: Busque explícitamente problemas de calidad de los datos
En el momento en que empieces a ver patrones por flujo, casi siempre te encontrarás con el mismo culpable: la calidad de los datos.
A veces, la lógica de fraude subyacente en realidad está bien. Las reglas son razonables. El modelo está bien calibrado. Los analistas tienen experiencia. Y, aun así, en un segmento concreto del tráfico, tu rendimiento se desploma.
A menudo se debe a que el sistema funciona con datos corruptos o faltantes:
- Direcciones IP predeterminadas cuando no se pudo capturar la IP real
- Correos electrónicos de relleno o valores basura
- ID de dispositivo que se restablecen a null en algunas versiones del sistema operativo
- Metadatos de pago que nunca se transmiten para un determinado método
- Tiempos de espera agotados o errores de integración con fuentes de inteligencia de terceros
Un buen método para detectar rápidamente este tipo de problemas es agrupar los puntos de datos por su valor y buscar aquellos que tengan una cantidad sospechosamente alta.
Paso 6: Asociar los problemas de datos con las soluciones que se comportan de forma incorrecta
Una vez que identifiques problemas de calidad de datos, tendrás que hacer un poco de trabajo de investigación.
Debes rastrear cada punto de datos corrupto hasta las características que influye (por ejemplo, correo electrónico a velocidad de correo electrónico) y luego vincular esas características con tus reglas o modelos que se están comportando de forma incorrecta.
Para la mayoría de las organizaciones, este ejercicio puede resultar increíblemente difícil, pero tienes un atajo: tu lista de principales soluciones problemáticas del Paso 3.
Cruza tus puntos de datos corruptos con las entradas utilizadas por tus reglas de peor rendimiento. Podrías encontrar una conexión oculta sin pasar días analizando esquemas de datos.
Al asociar los problemas de datos con soluciones, podrás completar el último eslabón de la cadena: atribuir un valor a cada uno de estos problemas, tal como lo has hecho con tus peores infractores.
Ahora es momento de reunirlo todo.
Uniendo ambos flujos
Paso 7: Identifica y prioriza los grupos que quieres corregir
Con este mapa establecido, la priorización se vuelve mucho más sencilla.
Empiezas con categorías que son:
- Lo suficientemente grandes como para que importen
- Bajo tu control
- Que no se deba de forma evidente a problemas de origen o de calidad de datos que correspondan a otro lugar
En muchas organizaciones, esto significa:
- Un pequeño número de reglas de alto volumen y alto impacto
- Uno o dos umbrales del modelo que se establecieron de forma conservadora
- Políticas específicas de gestión de casos que fomentan el bloqueo excesivo
- Un par de flujos en los que tu sistema genera problemas de datos
Estas son exactamente las áreas en las que nos centraremos en la Parte 3, donde entraremos en la mecánica de podar las reglas que se comportan mal, ajustar los umbrales y rediseñar partes de la lógica de decisión para que sea menos propensa a activarse en exceso.
Ese trabajo solo es efectivo porque primero has realizado el análisis de la causa raíz y sabes cómo invertir de forma inteligente.
Del mapa a la hoja de ruta
Al final de este proceso, deberías contar con tres recursos:
- Un mapa del panorama de falsos positivos desglosado por actor, flujo y estado de los datos
- Una comprensión clara de qué partes del problema te pertenecen y cuáles se heredan de socios o de restricciones arquitectónicas
- Una lista breve de áreas de alto impacto y solucionables donde puedas empezar a hacer cambios con una expectativa razonable de mover la aguja
Esto es lo que convierte los "falsos positivos" de una queja amorfa en un flujo de trabajo concreto.
En la Parte 3 de esta serie, profundizaremos en esos grupos de alto impacto y analizaremos las tácticas específicas para su resolución:
- Cómo decidir si una regla que se comporta de forma incorrecta debe desactivarse, suavizarse o enviarse a revisión manual en lugar de rechazarse automáticamente
- Cómo utilizar la "imagen en espejo" de tu proceso de detección de fraude para diseñar exclusiones que eliminen los falsos positivos sin abrir la puerta a más fraude
- Cómo abordar los problemas de calidad de los datos que están degradando el rendimiento de su sistema de prevención de fraude
Por último, en la Parte 4 construiremos una red de seguridad global: heurísticas de alto nivel que se sitúan por encima de todo tu sistema y detectan a los buenos usuarios antes de que cualquier solución subyacente (regla, modelo, agente o humano) pueda bloquearlos por error.
Por ahora, si has pasado de "tenemos falsos positivos" a "sabemos de dónde vienen la mayoría y qué partes podemos realmente corregir", ya estás muy por delante de la mayoría de los equipos.
Es un buen lugar en el que estar.
