Las reglas son el punto de partida de todo equipo antifraude, y con razón. Son rápidas de crear, intuitivas de entender y responden directamente a lo que estás viendo.
Sin embargo, cuando tu negocio crece, sus limitaciones se vuelven rápidamente evidentes. Esto genera complejidad operativa y hace que escalar la estrategia sea mucho más difícil.
Con cada región, método de pago, plataforma y segmento de clientes surge un perfil de riesgo único. Los equipos ven esos distintos perfiles de riesgo y hacen lo que saben: añadir más reglas, a menudo como una solución rápida ante la creciente complejidad. Una nueva regla para los pagos europeos. Un umbral actualizado para dispositivos móviles. Una nueva verificación de velocidad para clientes B2B.
Y durante un tiempo, esto funciona. Hasta que deja de hacerlo.
Los perfiles de riesgo no son lo único que cambia a lo largo de esas dimensiones. Cambian los proveedores relevantes. Cambian los flujos de autenticación adecuados. Cambian incluso los datos subyacentes que están disponibles.
Puedes establecer una regla para distintos niveles de riesgo, pero no puedes escribir una regla que diga: "llama a este proveedor de KYB para clientes B2B en Alemania, activa 3DS para transacciones de alto valor desde dispositivos nuevos y omite el enriquecimiento para usuarios recurrentes verificados".
Ahí es donde las reglas llegan a su límite. Y ahí es donde entra en juego la capa de flujo de trabajo.
Reglas contra el fraude frente a flujos de trabajo
Permíteme definir claramente estos dos términos, porque la confusión entre ellos es lo que causa la mayoría de los problemas que estoy a punto de describir.
Una regla implementa una táctica. Evalúa señales específicas para marcar o bloquear un comportamiento concreto dentro de ese contexto.
Un flujo de trabajo, por otro lado, implementa tu estrategia de prevención de fraude. Determina a qué población pertenece una transacción o un usuario, qué verificaciones se les aplican, qué proveedores se consultan y qué acciones están disponibles como resultados.
En resumen, crea el contexto operativo para una mejor segmentación, un mejor enrutamiento y mejores decisiones.
Así es como se ve en la práctica:
Una regla dice: "Marca esta transacción si el dispositivo es nuevo y la IP está en un país de alto riesgo."
Un flujo de trabajo dice: "Los usuarios nuevos que realizan pagos superiores a 500 $ pasan por una revisión reforzada: llama al proveedor de enriquecimiento de identidad, ejecuta la inteligencia de dispositivos y luego evalúa las señales de fraude."
El flujo de trabajo prepara el escenario y la regla actúa en él: ninguna funciona por sí sola.
Un flujo de trabajo sin reglas claras en su interior es solo una ruta sofisticada, con usuarios moviéndose por carriles sin llegar a tocar realmente nada.
Una regla sin contexto de flujo de trabajo se aplica a toda la población de forma indiscriminada, detectando fraude en algunos segmentos y generando ruido en otros.
Si quieres una guía detallada sobre cómo redactar e iterar una regla de detección en la práctica, esta publicación recorre un ejemplo real de principio a fin.
Reglas | Flujos de trabajo | |
Implementa | Una táctica | Una estrategia |
Evalúa | Señales presentes en el momento del incendio | Población, contexto, necesidades del proveedor |
Interactúa con | Señales y umbrales | Proveedores, sistemas de autenticación, acciones posteriores |
Alcance del cambio | Lógica de detección (propiedad del equipo de fraude) | Costo, experiencia de usuario y postura frente al fraude (interfuncional) |
Los flujos de trabajo contra el fraude hacen mucho más que enrutar
Esta es la parte que la mayoría de los equipos pasa por alto, incluso aquellos que entienden la distinción básica.
Los flujos de trabajo no solo clasifican poblaciones y las envían por diferentes caminos. También orquestan el proceso invocando pasos externos, recopilando datos adicionales y continuando la evaluación, todo sin terminar la sesión.
Cuando llega una transacción, un flujo de trabajo puede llamar a un proveedor de enriquecimiento de identidad, esperar la respuesta y luego llamar a un proveedor de inteligencia de dispositivos. Después, en función de lo que haya aprendido, puede decidir si activar un desafío 3DS, invocar una autenticación biométrica reforzada o pasar directamente a la evaluación de las reglas de fraude.
Todo esto ocurre en pleno flujo, de forma dinámica, antes de que se tome cualquier decisión final.
Las reglas no pueden hacer esto. Una regla evalúa las señales que ya están presentes en el momento en que se activa. No sale a buscar más datos, no mantiene la sesión abierta y no desencadena la autenticación de forma condicional en función de lo que haya encontrado.
Esto es lo que convierte el flujo de trabajo en la capa de estrategia. Decide no solo quién es evaluado, sino también cómo, incluyendo qué herramientas se activan, en qué orden y para qué población.
Las reglas luego realizan la detección sobre el evento enriquecido y completamente caracterizado.
Esto también significa que las dos capas tienen superficies de integración completamente diferentes. Las reglas interactúan con las señales y los flujos de trabajo interactúan con los proveedores, los sistemas de autenticación y las acciones posteriores.
Confundir los flujos de trabajo y las reglas (o intentar hacerlo todo a través de uno solo) es donde la complejidad operativa empieza a multiplicarse.
¿Por qué no puedes adaptar uno para sustituir al otro?
A veces los equipos intentan hacerlo. Pero esto es lo que suele pasar:
Reglas que sustituyen flujos de trabajo: Técnicamente, es posible. Codificas el contexto de la población directamente en las condiciones de las reglas:
SI new_user Y payment > $500 Y region = EU Y segment = consumer, ENTONCES...
El problema de encadenar todas estas reglas es que cada una tiene su propio contexto. Puede funcionar, hasta que tengas tres segmentos de clientes, seis regiones y dieciséis métodos de pago.
La explosión combinatoria es lo que genera el problema del conjunto de reglas inflado.
Pero, más importante aún, nada de eso resuelve el desafío de la orquestación de proveedores. Las reglas siguen sin poder llamar a un proveedor de KYB a mitad de sesión, activar un flujo 3DS o mantener un evento abierto mientras se espera una respuesta de enriquecimiento.
Lograste “hackear” el problema de enrutamiento, pero dejaste el problema de orquestación completamente sin resolver.
Flujos de trabajo que sustituyen reglas: Esto falla de forma diferente. En teoría, puedes crear una rama de flujo de trabajo formada por nodos secuenciales, cada uno con una única lógica de detección.
Aunque esto puede funcionar, se vuelve muy difícil de gestionar rápidamente. Las simulaciones pueden resultar engañosas, ya que las lógicas se ejecutan de forma secuencial en lugar de en paralelo, lo que dificulta detectar solapamientos entre las distintas “reglas”.
Esto también significa que tus flujos de trabajo se vuelven increíblemente abultados, lo que dificulta supervisar y orquestar tu estrategia.
Pero, lo más crítico, es que introduce un grave riesgo operativo. Cada vez que pruebas una nueva regla o una actualización de versión (lo cual puede ocurrir con frecuencia), pones en riesgo todo el flujo de trabajo.
Si configuras un valor incorrecto en una regla, no solo dejarás pasar fraudes, sino que también podrías interrumpir por completo el proceso que tu flujo de trabajo representa.
¿Realmente necesitas flujos de trabajo para la detección de fraude en tiempo real?
Esto es lo que me preguntan a menudo: "Somos un procesador de pagos. No tenemos flujos de incorporación complejos y todo es en tiempo real. ¿Realmente necesitamos la capa de workflows?"
Sí. He aquí por qué.
Es cierto que dirigir eventos en tiempo real a distintos segmentos suele ser un caso de uso más sencillo. Uno que puedes gestionar solo con reglas, aunque sea de forma algo torpe. Todos lo hemos visto antes.
Pero lo que sí echamos en falta es la parte de orquestación.
Piénsalo así: cuanto más arriesgado es un evento, mayor es mi exposición financiera. Y cuanto mayor sea mi exposición, más dispuesto estaré a invertir en una decisión más precisa.
Este principio puede manifestarse de diferentes maneras. Por ejemplo:
- Un pago superior a 500 dólares se enviaría a través de una canalización de enriquecimiento de datos más costosa.
- Un pago con una alta puntuación del modelo se enviaría a un modelo de segunda línea. Un modelo que podría estar ralentizando nuestro SLA para una pequeña parte de la población, pero que es mucho más preciso.
- Un inicio de sesión en una cuenta con un saldo alto se dirigiría a un flujo de 2FA sólido.
Como puedes ver, estos casos de uso no tratan ni de la lógica de detección ni de qué umbrales aplicar. Se trata de por qué canal pasaría este evento y con qué costo.
Sin una capa de flujo de trabajo, estás ejecutando el mismo pipeline para todos ellos. Lo que significa que o bien estás gastando de más en tu prevención de fraude o estás revisando insuficientemente tus eventos de mayor riesgo.
Normalmente ambas cosas, en distintos lugares.
En tiempo real no significa uniforme. La capa de flujo de trabajo gestiona esa complejidad de población a la velocidad que requiere el evento, como enrutar a los proveedores adecuados, activar la autenticación correcta y aplicar el conjunto de reglas apropiado, todo dentro de la misma sesión.
El instinto de omitir los flujos de trabajo en un contexto en tiempo real suele venir de pensar en ellos como un concepto de procesamiento por lotes o de incorporación.
No lo son. Son el contexto operativo de cada evento, sin importar qué tan rápido ocurra.
Quién debe estar presente para tomar decisiones sobre flujos de trabajo de fraude
Por mucho que los flujos de trabajo estén diseñados para gestionar la complejidad, también introducen un cierto nivel de complejidad en tu organización.
Para explicar eso, primero analicemos las reglas.
Una nueva regla contra el fraude cambia tu lógica de detección. El responsable es el equipo de fraude: detectan un nuevo patrón de ataque, redactan una regla, la prueban y la ponen en producción. Ciclo rápido, alcance acotado y control total de principio a fin. He escrito sobre todo el proceso de publicación de reglas, incluyendo backtesting, validación en modo sombra y monitorización en vivo, en este artículo del blog.
Los cambios en el flujo de trabajo son una conversación diferente, y a menudo requieren múltiples conversaciones al mismo tiempo.
Cambia qué proveedores se llaman en una rama del flujo de trabajo, y habrás tomado una decisión de costos. Las llamadas a proveedores tienen tarifas por transacción y, a cualquier volumen significativo, se acumulan rápidamente. Esa es una conversación de operaciones y finanzas.
Cambia si un flujo de trabajo activa un desafío 3DS o una autenticación biométrica adicional para un segmento de clientes, y habrás cambiado la experiencia de usuario para esa población. Esa es una conversación de producto.
Cambia la propia lógica de enrutamiento sobre qué clientes pasan por cada rama y habrás cambiado tu postura frente al fraude para ese segmento. Esa es una decisión del equipo de fraude, pero con implicaciones de negocio que van más allá del fraude.
La cuestión es esta: los cambios en los flujos de trabajo se sitúan en la intersección entre fraude, producto, operaciones y, a veces, incluso finanzas. Implementarlos sin que todos los equipos estén alineados es la forma en que cambios bien intencionados generan costos inesperados con proveedores, fricción para los clientes o brechas de cobertura; a veces, las tres cosas a la vez.
Pero, por otro lado, la complejidad organizativa no es precisamente evitable al escalar.
Dos capas, una pila
Las reglas llevaron a todos los equipos de fraude hasta donde están hoy. No van a desaparecer, ni deberían hacerlo. Sin embargo, las reglas por sí solas tienen un límite.
Y ese límite tiene menos que ver con la precisión de la detección que con la complejidad. En el momento en que tu negocio abarca múltiples regiones, métodos de pago, plataformas o segmentos de clientes, estás operando en un contexto que las reglas no fueron diseñadas para gestionar por sí solas.
La asignación de proveedores, la orquestación de la autenticación y la segmentación de la población pertenecen a la capa de flujo de trabajo. Las dos capas no son rivales. Funcionan como una pila en la que los flujos de trabajo implementan la estrategia y las reglas implementan las tácticas. Cada una hace un trabajo que la otra no puede.
Las reglas detectan el riesgo. Los flujos de trabajo definen la respuesta.
En pocas palabras, las reglas son la forma en que los equipos de fraude detectan actividad sospechosa, y los flujos de trabajo son la forma en que operacionalizan la respuesta. Las reglas evalúan señales y umbrales. Los flujos de trabajo deciden qué hacer con esa información, ya sea escalarla para revisión, activar autenticación, llamar a un proveedor, aprobar o bloquear. Así que la pregunta que vale la pena hacerle a tu equipo no es "¿deberíamos usar reglas o flujos de trabajo?" sino si tu capa de flujos de trabajo realmente refleja la complejidad de tu negocio. ¿Y si las reglas dentro de cada rama están calibradas para esa población específica?
Si todavía gestionas las variaciones regionales, la segmentación de clientes y la asignación de proveedores mediante condiciones de reglas y lógica de excepciones, ya has tocado techo.
Puede que simplemente aún no le hayas puesto nombre.
