Stripe Radar es excelente en lo suyo: puntuar una transacción en el instante en que el dinero se mueve. Pero el momento en que el dinero no se mueve es justo donde vivía nuestro problema.
Ofrecemos una prueba gratuita de 7 días. Para iniciarla, el usuario guarda una tarjeta pero nunca se le cobra: por debajo, eso es un SetupIntent de Stripe, no un pago. Sin cobro no hay evento en el momento del cobro, lo que significa que las reglas más potentes de Radar no tienen nada que evaluar en el instante que más importa: cuando se está creando una cuenta fraudulenta y empieza a consumir créditos de la prueba.
Esta es la historia de cómo pasamos de apagar incendios de fraude en conversaciones aisladas a operar una capa antifraude automatizada, minuto a minuto, construida sobre nuestro propio producto, Zero.
Radar es genial. "Genial" no es "perfecto."
Stripe Radar es realmente bueno en lo que hace. Entrenados con más de $1 trillion en volumen de pagos anual, sus modelos reconocen una tarjeta que ya han visto antes el 92% de las veces, y Stripe informa que Radar reduce el fraude un 32% en promedio para los negocios que lo usan.
Vuelva a leer ese número, eso sí: reduce, no elimina. Una mella promedio del 32% es enorme, pero significa que una gran parte de la presión de fraude sigue llegando a su puerta, y Stripe es refrescantemente honesto sobre el porqué. En sus propias palabras: "reducir el número de falsos positivos a menudo aumenta la probabilidad de que más fraude real se cuele por las rendijas." La fuga no es un defecto del modelo; es el costo deliberado de no bloquear a sus clientes reales. Cada equipo antifraude decide, a propósito, cuánto dejar pasar.
Para un producto basado en pruebas gratuitas, esa fuga es más amplia de lo que sugiere la cifra del titular, porque la parte más potente de Radar ni siquiera llega a ejecutarse.
Por qué una barrera solo puede reducir
Hay una razón más profunda por la que un motor que actúa en el momento del cobro puede reducir el fraude pero nunca acabar con él, y no tiene que ver con los modelos de Stripe: tiene que ver con el momento y la información. En el instante en que se añade una tarjeta, el cliente todavía no ha hecho nada. No hay historial de inicio de sesión, ni comportamiento dentro del producto, ni patrón de uso del que aprender: solo una tarjeta y un puñado de señales de red. Radar toma su mejor decisión con la porción de evidencia más delgada posible, en el único momento en que menos información tiene.
Ese es el verdadero techo. Puede ajustar una barrera, pero no puede darle datos que aún no existen. La información que de verdad distingue a un abusador de un cliente se genera, en su mayoría, después de que la barrera ya tuvo que decidir.
Etapa 1: Apagar incendios en la ventana de chat
Nuestra primera respuesta fue totalmente manual. Cuando llegaba una ola de abuso, alguien abría una conversación con nuestro agente y trabajaba el incidente en vivo: extraer los registros recientes, mirar las tarjetas, encontrar el patrón y cerrar las cuentas a mano.
Funcionaba, pero no escalaba. Cada incidente empezaba desde cero. El conocimiento (cómo luce esta red, qué señales son confiables) vivía en la cabeza de una persona y en un hilo de chat, y se evaporaba en cuanto se cerraba la ventana.
También aprendimos una lección cara en el buen lado del embudo: cuando quisimos recuperar a usuarios genuinos que abandonaron el checkout, un correo de seguimiento descuidado a una dirección fraudulenta causa un daño real, porque confirma que la dirección está activa. Cualquier automatización que construyéramos tendría que distinguir entre un prospecto real y uno plantado.
Etapa 2: Reforzar la puerta de entrada con Radar
Nuestro siguiente movimiento fue empujar todo lo posible aguas arriba, hacia Radar: listas de bloqueo y reglas de velocidad en el paso de añadir la tarjeta, ajustadas a la presión que veíamos. Es el primer movimiento correcto, y detuvo los ataques más burdos.
Pero dos techos aparecieron rápido. El primero es el que el propio Stripe nombra: un motor que actúa en el momento del cobro es un dial de compensación, no un muro: súbalo y bloquea clientes reales, bájelo y se cuela más fraude. El segundo es estructural y específico de las pruebas gratuitas: ese 32% se gana en el momento del cobro, y una prueba con SetupIntent no tiene cobro que puntuar. A menos que habilite explícitamente Radar sobre métodos de pago guardados, el motor no se ejecuta en absoluto, e incluso cuando lo hace, solo las reglas Block, Allow y 3DS aplican sobre un SetupIntent. La acción "Review", la que le da a una persona una segunda mirada, nunca se dispara.
Así que la capa de mejor rendimiento de toda la pila está, por defecto, ausente justo en el momento en que más la necesitábamos. Radar es una barrera en la puerta de entrada. Nosotros necesitábamos una patrulla detrás de ella.
Etapa 3: Una segunda capa, construida sobre Zero
Después del registro, el panorama de información se invierte. La cuenta empieza a dejar un rastro, y la parte más rica de ese rastro vive en un sistema que el procesador de pagos nunca ve: nuestro proveedor de identidad, Clerk.
Así que le dimos acceso a Zero. Clerk sabe cosas que Stripe no puede saber: cómo se creó la cuenta, el método de registro y el correo, la sesión y el dispositivo detrás de ella, y el momento exacto en relación con cada otro registro de ese día. Stripe conoce la tarjeta. Ninguno de los dos sistemas, por sí solo, cuenta la historia completa, pero el agente puede leer ambos y correlacionarlos entre sí. El abuso que es invisible en la barrera se vuelve obvio cuando se ponen lado a lado: una cuenta recién creada cuya identidad de inicio de sesión no concuerda con su identidad de facturación, creada con segundos de diferencia respecto a un grupo de cuentas casi idénticas. Ese cruce entre sistemas es exactamente lo que una barrera del momento del cobro no puede hacer, y exactamente lo que sí puede un agente situado sobre ambos sistemas.
Sobre esa base de evidencia más rica, ejecutamos un conjunto de tareas programadas de Zero cada pocos minutos contra datos de registro y facturación en vivo. Tres principios les dan forma:
1. Patrulla, no solo bloquees. En lugar de evaluar un solo momento, el agente recorre cada registro reciente en un ciclo corto, correlacionando datos de cuenta y metadatos de pago para sacar a la luz cuentas que se colaron por la puerta de entrada.
2. Escalona la respuesta según la confianza. No toda señal merece la misma acción. Los patrones de alta confianza se manejan de forma automática: la cuenta se suspende y su prueba se cancela en el acto, porque la acción es reversible y el costo de esperar es real. Las señales de menor confianza nunca se accionan de forma automática; se recopilan en un informe para que una persona las revise. Decididos donde es seguro, conservadores donde no lo es.
3. Mantén un rastro de auditoría humano. Cada acción automatizada registra la señal exacta que la disparó, para que pueda revisarse, y revertirse, en segundos. Una automatización que no puede auditar es una automatización en la que no puede confiar.
Aplicamos el mismo rigor al lado amable del embudo. Una tarea aparte encuentra a usuarios genuinos que abandonaron el checkout y redacta un correo de recuperación para que una persona lo apruebe, detrás de un filtro antifraude deliberadamente exigente, para nunca validar una dirección maliciosa. El mismo motor, el objetivo opuesto.
Lo que hizo con la economía
Una vez que la patrulla estuvo activa, los números se movieron de inmediato. Fíjese en el registro en el percentil 90: las cuentas pesadas que causaban el daño real. El cómputo de prueba que una de ellas consumía en sus primeras horas cayó de unos $4 a unos $0.25: una caída del 94%. Promediado entre cada nuevo registro en la misma ventana, la pérdida por cuenta bajó alrededor de un 85%.
La forma del cambio es lo revelador. La mayoría de los registros nunca nos costaron nada; la pérdida siempre estuvo concentrada en una cola larga y pesada de cuentas que existían únicamente para drenar créditos de la prueba. La patrulla no encogió el embudo: cortó esa cola. No menos registros. Registros más limpios.
Por qué un agente, y no un script
Podríamos haber escrito un cron job. No lo hicimos, por una razón: la amenaza cambia más rápido que un ciclo de lanzamiento. Cuando un atacante cambia de táctica, actualizamos las instrucciones de una tarea en lenguaje natural y la nueva lógica está activa en la siguiente ejecución: sin despliegue, sin migración de esquema, sin ticket. Las "reglas" son un prompt, y el prompt se cambia tan rápido como cambia el atacante.
Esa es la verdadera lección. Radar es la herramienta correcta para el riesgo en el momento del cobro, y nos apoyamos mucho en ella. Pero un negocio basado en pruebas gratuitas tiene un punto ciego estructural que ninguna herramienta del momento del cobro puede cubrir, y la solución no es un motor de reglas más grande. Es una segunda capa rápida, auditable y siempre activa que puede reprogramar a la velocidad de la amenaza.
Conclusiones para equipos basados en pruebas gratuitas
- Mapee sus momentos sin cobro. Cualquier punto donde un usuario obtiene valor antes de que un pago sea puntuado es una brecha que una herramienta del momento del cobro no puede ver.
- Sume capas, no reemplace. Mantenga Radar en la puerta de entrada. Añada detrás una patrulla continua posterior al registro.
- Cruce entre sistemas. Su procesador de pagos y su proveedor de identidad guardan, cada uno, la mitad del cuadro. El fraude se hace visible en la superposición.
- Escalone sus acciones según la confianza, y registre cada una. Accione de forma automática solo donde la acción es reversible y la señal es fuerte; derive el resto a una persona.
- Optimice para la velocidad de adaptación. En el fraude, gana el equipo que puede cambiar sus reglas más rápido.
¿Tiene curiosidad por lo que un agente siempre activo podría automatizar en su propio stack? Descubre Zero.
Notas: las cifras de Radar son los números publicados por el propio Stripe (stripe.com/radar; "A primer on machine learning for fraud detection"). Las cifras de pérdida reflejan el costo de cómputo por nuevo registro en las primeras horas tras el alta, medido en ventanas equivalentes antes y después del lanzamiento, con las cuentas internas excluidas; la muestra posterior al lanzamiento todavía es temprana y se consolidará con el tiempo.
