Reduzca los falsos positivos por fraude sin aumentar las pérdidas

Última actualización: Septiembre de 2026

La mayoría de los equipos de fraude asumen que la elección está grabada en piedra: si endurecen las reglas, rechazan a buenos clientes; si las relajan, asumen pérdidas. Ese dilema es real cuando la decisión depende de una sola señal débil, pero se vuelve artificial en el momento en que la decisión cuenta con más datos. Añadir contexto cambia la forma de la curva. Mover un umbral solo cambia el punto en el que te ubicas en ella. Y el equipo que se niega a ajustar sus reglas porque siente que es arriesgado, por lo general ya está dejando pasar fraudes: una cola de revisión que casi siempre se equivoca entrena silenciosamente a sus analistas para que dejen de prestar atención.

Resumen rápido

• Un falso positivo es la alerta. Un falso rechazo es lo que experimenta el cliente. Se miden en lugares distintos y se pagan con presupuestos diferentes.

• El dilema entre pérdidas y alertas es una característica de decidir con un solo número, no una propiedad del fraude en sí.

• El coste de un falso rechazo queda fuera del informe de pérdidas por fraude, razón por la cual una regla de control puede parecer exitosa pero resultar muy costosa.

• Una cola de revisión que genera casi exclusivamente falsos positivos no es solo una pérdida de tiempo. Es un fallo de detección con mecha retardada, porque los analistas dejan de tomarse en serio ese canal.

• Los falsos rechazos se dividen en dos causas: por señales débiles y por riesgo genuino, y cada una necesita soluciones distintas. Ninguna se soluciona moviendo un umbral.

• Puedes calcular la tasa de falsos positivos sin necesidad de ver qué habría pasado con las transacciones rechazadas, utilizando las reclamaciones, los intentos de reintento y analizando una muestra deliberada de los rechazos.

• Relajar las reglas no tiene por qué ser un acto de fe: compáralo con alertas históricas en un análisis retrospectivo, ejecútalo en modo pasivo (shadow) y luego lánzalo a producción.

Qué es un falso rechazo y en qué se diferencia de un falso positivo

Un falso rechazo ocurre cuando un control diseñado para detener el fraude bloquea una transacción o a un cliente legítimo. El pago era válido, el solicitante era real, el inicio de sesión correspondía al verdadero titular de la cuenta... y el sistema dijo que no. En el mundo de los pagos, esto a veces se denomina transacción rechazada por error; los equipos de riesgo dentro de una entidad suelen llamarlo falso positivo.

Ambos términos describen dos caras de la misma moneda. El falso positivo es la alerta que emitió el sistema. El falso rechazo es la consecuencia que sufrió el cliente. Vale la pena mantener esta distinción porque ambos se miden en lugares distintos y afectan a presupuestos diferentes: la alerta aparece en tu cola de revisión, mientras que el rechazo aparece en el informe de conversión de otra persona.

En el fondo, representan el mismo fallo. Se tomó una decisión con muy poca información para distinguir lo inusual de lo fraudulento, por lo que lo inusual se trató como fraude.

Por qué el dilema parece inevitable

Los equipos de riesgo experimentan el control del fraude como un conjunto de mandos interconectados (pérdidas por fraude, costes de revisión, tasa de aprobación) donde mover uno afecta al otro. Si endureces la regla, la cola de revisión crece y las aprobaciones caen. Si la relajas, las pérdidas aumentan. Cualquiera que haya gestionado un programa de fraude ha sentido esto, y no hay nada irracional en esa sensación.

Esta conexión es totalmente real cuando la decisión depende de una sola señal débil. Si lo único que sabe el control es una puntuación o score, la única palanca disponible es decidir dónde cortar esa puntuación, y cada ajuste cambia un tipo de error por el otro. Esa es la geometría de una decisión unidimensional, y no hay forma de evitarlo por muy bien que se elija el punto de corte.

Pero esto no es una propiedad del fraude. Es una propiedad de decidir con un solo número. Cambia la información en la que se basa la decisión y la curva misma se moverá.

El coste que nunca llega al informe de fraude

Bloquear a un buen cliente significa perder ingresos inmediatos y, si se supera el límite de fricción repetida, perder al cliente para siempre. El segundo coste es mucho mayor que el primero y llega mucho más tarde, por lo que rara vez se atribuye a la regla de control que lo provocó.

Además, ese coste va a parar a una línea de la cuenta de resultados distinta de la pérdida por fraude que se evitó. Las pérdidas por fraude se cargan al programa de fraude, mientras que los ingresos rechazados y la pérdida de clientes se contabilizan en otro lugar. Por lo tanto, una regla de control puede parecer exitosa en el único informe que la evalúa, siendo al mismo tiempo muy costosa para la entidad en su conjunto. Reducir los falsos positivos suele presentarse como un proyecto de eficiencia operativa, cuando en realidad se trata de un proyecto de generación de ingresos. Si quieres calcular ese coste antes de decidir qué cambiar, nuestra guía para evaluar software de detección de fraude detalla qué exigirle a un sistema.

En la práctica, sin embargo, la carga operativa suele ser lo primero que obliga a actuar. Una cooperativa de crédito estadounidense describió de forma muy sencilla su proceso de revisión de alertas: un volumen enorme de falsos positivos y un proceso que se había vuelto sencillamente insoportable. Fue esa carga, y no la cifra de pérdidas, lo que les impulsó a buscar alternativas. La mayoría de los equipos se identifican más con esa situación que con un argumento de ingresos.

El coste oculto: una cola de revisión que siempre se equivoca enseña a los analistas a dejar de buscar

Aquí está la parte que cambia el análisis de riesgo. El equipo de fraude de una firma de inversión estadounidense nos describió uno de sus canales de alerta: producía casi exclusivamente falsos positivos y admitieron con franqueza el efecto que tenía: el equipo se había vuelto descuidado con esas alertas. Al mismo tiempo, reconocían que el fraude real seguía llegando a través de ese mismo canal.

Esto no es una queja sobre eficiencia operativa. Es un fallo de detección con mecha retardada. Cuando una cola de revisión casi siempre se equivoca, la respuesta racional de un analista experimentado es dedicar menos atención a cada caso, y la atención humana es precisamente el mecanismo mediante el cual se detecta un caso de fraude real. Las alertas siguen saltando, el panel de control sigue mostrando que todo está cubierto, pero la tasa de detección real cae de todos modos.

Por lo tanto, mantener el statu quo no es la opción conservadora, aunque sea la hipótesis en la que se basan la mayoría de los programas de optimización estancados. Negarse a ajustar las reglas no mantiene el riesgo bajo control. Convierte un problema medible de falsos positivos en un problema invisible de fraude no detectado, y este último es peor precisamente porque no aparece en ningún informe.

Esto responde directamente al miedo habitual. El temor es que reducir las alertas signifique dejar pasar el fraude. Pero el sistema sin optimizar ya está dejando pasar el fraude; simplemente no genera ningún número que lo demuestre.

De dónde provienen realmente los falsos rechazos

Las causas se dividen en dos categorías, y definir cuál estás observando determina la solución adecuada.

Causas por señales débiles. El control tenía un solo dato débil para decidir y juzgó mal. El filtrado de sanciones y personas expuestas políticamente (PEP) es el ejemplo más claro: un banco digital europeo nos describió un sistema de filtrado donde muchas alertas no eran dudosas, sino completamente irrelevantes, porque la lógica de coincidencia trataba un primer nombre compartido como una coincidencia positiva a pesar de tener un apellido diferente. Esa alerta no es un caso dudoso que se resolvería con un mejor umbral. Es una decisión tomada sin contexto de identidad (sin fecha de nacimiento, sin jurisdicción, sin historial) y relajar la tolerancia de coincidencia solo cambiaría esos falsos positivos por fraude real no detectado.

Los fallos por señales débiles aparecen siempre que se toma una decisión basándose en un solo atributo, lo que en la práctica se traduce tanto en la toma de decisiones en transacciones como en el flujo de apertura de cuentas, que es donde la entidad sabe menos sobre la persona que tiene enfrente.

Causas por riesgo genuino. El comportamiento era realmente inusual, pero el cliente era legítimo. Un cliente que viaja por primera vez en dos años, una primera compra de gran valor o un dispositivo nuevo tras cambiar de teléfono. La señal no era errónea; la situación era inusual pero legítima.

La tabla resume todo el diagnóstico: identifica la categoría antes de elegir la solución.

Ten en cuenta que ninguna de las dos categorías se soluciona moviendo el umbral, que suele ser la primera medida que toman la mayoría de los equipos. Una pregunta relacionada (si una decisión concreta debe gestionarse con una regla manual o con un modelo) merece un análisis aparte y no se resuelve aquí. Tampoco la cuestión más amplia de gestionar las decisiones de fraude y prevención de blanqueo de capitales (AML) con un contexto compartido en lugar de en dos sistemas separados, que es donde encaja perfectamente el ejemplo de filtrado anterior.

Cómo medir la tasa de falsos positivos cuando nunca ves qué habría pasado con un rechazo

Esta es la pregunta que hace que el resto del artículo sea aplicable a la práctica, y casi nadie la responde.

El problema es estructural, no una falta de datos en tus informes. Una transacción rechazada no tiene un resultado observable. Nunca sabrás si ese cliente habría pagado correctamente, porque no le dejaste hacerlo. El denominador que necesitas no existe por diseño, por lo que no puedes limitarte a medir una tasa exacta de falsos positivos de forma directa.

Lo que hacen los equipos en la práctica es trabajar con una estimación razonable. Un banco comercial de EE. UU. que evaluaba una prueba de concepto hizo exactamente eso: estimó su volumen de alertas en aproximadamente un 85% de falsos positivos y utilizó esa cifra para predecir cómo se dividiría una muestra de 20 alertas entre falsos positivos y escalaciones reales. Esa cifra es la lectura de esa entidad sobre su propio entorno, no una tasa de referencia del sector ni nuestra medición de nada, pero el método es el correcto. Una estimación explícita con la que puedas debatir es mejor que una implícita que no puedas cuestionar.

Tres fuentes de información aportan datos reales a esa estimación:

1. Contacto con el cliente y reclamaciones. Cada llamada, disputa de cargo o reclamación por un rechazo es un cliente que te dice que la decisión fue incorrecta. El volumen de reclamaciones por cada mil rechazos es el límite mínimo de tu tasa de falsos rechazos; si es inusualmente bajo, suele significar que el canal de reclamación es difícil de encontrar, no que los rechazos fueran correctos.

2. Comportamiento de reintento exitoso. Un cliente rechazado en un canal que completa la misma acción minutos después en otro ha demostrado que es legítimo. Identificar y asociar estos casos convierte una suposición en un dato real.

3. Una muestra deliberada de rechazos. Analiza una pequeña muestra aleatoria de rechazos cada semana de la misma manera que analizarías una alerta. Requiere horas de analistas, pero es el único método que ofrece un resultado real sobre el grupo de transacciones que de otro modo no podrías evaluar.

A continuación, mide por regla, no de forma global. Analizar los resultados de una sola regla te aportará información que un ajuste de sensibilidad global nunca te dará: la pregunta útil es qué regla está fallando, no si el sistema en su conjunto es demasiado estricto. La mayoría de las colas de revisión están dominadas por unas pocas reglas, y la justificación para cambiar una de ellas debe basarse en su propio historial.

Qué mueve la curva en lugar de desplazarse por ella

Disponer de más contexto por decisión cambia la forma de la curva de compensación. Un umbral más flexible solo cambia tu posición en ella. Esa frase marca la diferencia entre un programa de fraude que mejora y uno que oscila constantemente de un extremo a otro.

Por contexto nos referimos a datos concretos disponibles en el mismo momento de la decisión, no en un informe de la semana siguiente: el historial del cliente con tu entidad, señales del dispositivo y de comportamiento, y lo que esa misma identidad está haciendo en otras áreas de la institución. Una transacción que parece inusual en comparación con un patrón global a menudo parece completamente normal si se compara con el historial del propio cliente, y un solicitante que parece legítimo de forma aislada puede ser la cuarta solicitud enviada desde el mismo dispositivo esta mañana.

Llevar ese contexto a la decisión a tiempo es una cuestión de arquitectura, no de ajuste de parámetros. Oscilar es una plataforma unificada: infraestructura de datos en tiempo real, inteligencia de dispositivos y comportamiento, reglas y gestión de casos en un solo sistema, con agentes nativos integrados. La ventaja de este diseño es que la señal que necesita una decisión ya está en el lugar donde ocurre la decisión, en lugar de estar almacenada en un almacén de datos esperando a ser consultada. Los agente de riesgo que gestionan la cola de revisión utilizan el mismo contexto en lugar de una copia separada.

Veamos un ejemplo real. MoneyGram, una empresa de pagos que utiliza los agentes de Oscilar en producción, redujo el tiempo de revisión de sus alertas AML de nivel 1 de más de 30 minutos a menos de 2 minutos con el mismo equipo y con cerca de un 45% menos de falsos positivos. El mismo equipo, menos falsos positivos y revisiones más rápidas: la combinación que el modelo tradicional de mandos interconectados dice que es imposible conseguir. Tu entidad y tu tipo de alertas serán distintos, pero la dirección del resultado es lo que cuenta.

Cómo probar una relajación de reglas antes de que llegue a producción

El temor a que un cambio deje pasar el fraude es razonable y debe tratarse como tal. La respuesta no es la valentía, sino las pruebas acumuladas en una secuencia que permita observar el impacto del cambio antes de que tenga consecuencias reales.

Lo primero es un análisis retrospectivo (backtest) con tus alertas históricas. Vuelve a aplicar la lógica propuesta sobre decisiones de las que ya conoces el resultado final y verás qué habría hecho el cambio: qué alertas habría evitado, qué casos de fraude confirmado habría dejado pasar y cómo varía el volumen de la cola de revisión. Aquí es donde un cambio que parece temerario en una reunión se aprueba o se descarta, sin asumir ningún riesgo.

El siguiente paso es el modo pasivo (shadow). La nueva lógica se ejecuta en paralelo a la cola activa sin aplicar ninguna acción, evaluando el tráfico actual mientras los controles existentes siguen vigentes. Esto detecta lo que un análisis retrospectivo no puede, porque el comportamiento de los usuarios cambia constantemente (nuevos patrones de ataque, un nuevo producto o cambios estacionales).

Solo entonces el cambio llega a producción, y la decisión de lanzarlo se basa en los resultados de las dos fases anteriores. En pocas palabras, toda la secuencia consiste en un análisis retrospectivo con alertas históricas seguido de un modo pasivo en la cola real, con una evaluación final. Por eso relajar una regla no tiene que ser un acto de fe, y por eso el argumento de "no podemos arriesgarnos" deja de tener sentido cuando se dispone de este proceso.

Quién es el propietario de la decisión y cómo se mantiene ese control

Un cambio de umbral es una decisión sobre el nivel de tolerancia al riesgo. Corresponde al responsable de riesgos, no a cualquiera que tenga acceso de edición a la regla. Con frecuencia se trata de personas distintas, y en esa brecha es donde se acumulan los ajustes manuales sin documentar.

La decisión se puede defender cuando se registra el razonamiento que la motivó. Lo que hace que esto sea posible es contar con un registro de auditoría completo por decisión con el razonamiento guardado, diseñado con intervención humana por definición y adaptado a la directiva SR 11-7 (una expectativa que la plataforma está diseñada para cumplir, no un certificado que alguien posea). Cuando un regulador o un equipo de control interno pregunte por qué se cerró esta alerta y por qué se movió ese umbral, la respuesta debe poder recuperarse en el sistema en lugar de depender de la memoria de alguien.

Trata la optimización como un proceso continuo y no como un proyecto puntual. Los usuarios cambian, los defraudadores se adaptan y un umbral fijado una sola vez va perdiendo eficacia silenciosamente. La revisión que realmente importa es la programada para el próximo trimestre, no la que dio origen a este cambio.

Por último, este proceso continuo solo funciona si el equipo de riesgos puede cambiar la política sin tener que esperar a un desarrollo de ingeniería. Si cada ajuste requiere una solicitud técnica, el ritmo de revisión dependerá del calendario de desarrollo de los programadores y perderás la batalla contra el fraude.

Preguntas frecuentes

¿Qué es un falso rechazo?

Un falso rechazo ocurre cuando un control diseñado para detener el fraude bloquea una transacción, solicitud o inicio de sesión legítimo. El cliente era real y la actividad era válida, pero el sistema consideró que era riesgosa. Es la consecuencia que experimenta el cliente debido a un falso positivo: el mismo fallo, visto desde el otro lado de la decisión.

¿Cuál es la diferencia entre un falso positivo y un falso rechazo?

Un falso positivo es la alerta que el sistema emite ante una actividad legítima. Un falso rechazo es lo que le ocurre al cliente cuando esa alerta provoca un bloqueo. Uno se mide dentro del departamento de fraude (en volumen de colas de revisión y tiempo de los analistas); el otro se mide fuera de él (en tasas de aprobación e ingresos perdidos). El mismo error subyacente, reflejado en dos balances distintos.

¿Cómo pueden los equipos reducir los falsos positivos sin aumentar las pérdidas por fraude?

Añadiendo contexto a la decisión en lugar de relajar el umbral. Un cambio de umbral simplemente intercambia un tipo de error por otro. Disponer de más datos por decisión (historial del cliente, datos del dispositivo y de comportamiento, actividad de la identidad en otros productos) permite separar lo inusual de lo fraudulento y mejora ambas métricas a la vez. Después, reduce el riesgo del cambio: compáralo con alertas históricas, pruébalo en modo pasivo con tráfico real y solo entonces impleméntalo.

¿Cómo se mide la tasa de falsos positivos si nunca se sabe el resultado de una transacción rechazada?

Se calcula mediante una estimación, ya que una transacción rechazada no tiene un resultado que se pueda observar y no se dispone del denominador real. Tres fuentes de información sustentan esta estimación: las reclamaciones y llamadas de los clientes tras un rechazo, los clientes que vuelven a intentar la operación con éxito por otro canal y el análisis manual de una muestra representativa de los rechazos. Mide por regla en lugar de hacerlo de forma global: la pregunta útil es qué regla concreta está fallando.

¿Reducir los falsos positivos significa aceptar más fraude?

No, siempre y cuando cambies la información en la que se basa la decisión en lugar de modificar el punto de corte. Además, no hacer nada oculta un coste: una cola de revisión que casi siempre se equivoca enseña a los analistas a no prestarle atención, por lo que un control sin optimizar ya está dejando pasar el fraude sin generar un número que lo demuestre. Mantener el statu quo no es la opción conservadora, sino la opción sin evaluar.