Cómo armar un flujo antifraude en el motor de decisiones
El motor no detecta el deepfake: orquesta a tus proveedores de identidad, antifraude y buró, cruza sus señales con tus reglas y decide aprobar, rechazar o derivar a revisión.
Actualizado en julio de 2026 · 8 min de lectura
En resumen
Un motor de decisiones no reemplaza a tu proveedor de identidad o antifraude: los orquesta. Conecta cada proveedor (nodo de buró o REST), los consulta en paralelo (nodo concurrente), cruza sus señales con tus reglas, geolocalización y modelos, y decide en milisegundos aprobar, rechazar o derivar a revisión manual, con un camino de contingencia si un proveedor se cae y la traza completa de cada decisión.
El fraude no se resuelve con una sola herramienta ni con un solo proveedor. Se resuelve coordinando varios —identidad, antifraude, buró, señales de dispositivo— en el momento de decidir, y transformando todas esas señales en una acción: aprobar, rechazar o mandar a revisión. Ese es exactamente el trabajo de un motor de decisiones.
Qué hace el motor en el fraude, y qué no
Conviene ser preciso, porque es donde se confunde a un motor de decisiones con un proveedor antifraude. El motor no verifica una biometría facial, no detecta un deepfake ni valida un documento por sí mismo: eso lo hacen los especialistas de identidad y antifraude.
Lo que hace el motor es la capa que falta entre esos proveedores y la aprobación: los coordina, cruza sus señales con tus reglas y modelos, y decide qué hacer con cada solicitud. Sin esa capa, cada institución termina cableando proveedores a mano y resolviendo los conflictos entre ellos con código.
- El proveedor de identidad detecta; el motor decide qué hacer con esa señal.
- El motor combina varias fuentes en una sola decisión, en milisegundos.
- Cada decisión queda trazada: qué señales entraron y por qué se resolvió así.
Paso 1 — Conectar los proveedores
Cada proveedor externo entra al flujo como un nodo. Los preintegrados (burós y webservices homologados) se conectan con el nodo de buró, que administra credenciales, tokens y API keys, cachea consultas para no pagar dos veces por el mismo dato y maneja timeouts. Cualquier proveedor de identidad, antifraude, device intelligence o listas que no esté preintegrado se conecta con un nodo REST a su API.
El resultado: identidad, antifraude, buró y señales de dispositivo quedan disponibles como variables dentro de la misma política, sin integraciones separadas por fuera del motor.
- Nodo de buró: proveedores homologados, con credenciales, caché y timeout.
- Nodo REST: cualquier API de identidad/antifraude/dispositivo/listas.
- Todas las señales quedan como variables de la política.
Paso 2 — Consultarlos en paralelo
En fraude, la latencia importa: encadenar cinco consultas de a una hace esperar al cliente. El nodo concurrente ejecuta varios nodos de datos a la vez, así identidad, antifraude y buró se consultan en paralelo y el flujo avanza con el tiempo del más lento, no con la suma de todos.
Ese patrón —consultar varias fuentes en paralelo y quedarse con lo que llega— es lo que en la industria se llama un waterfall de datos.
- El nodo concurrente reduce el tiempo total a la fuente más lenta.
- Permite armar un waterfall: consultar, y escalar a otra fuente si hace falta.
- Baja fricción sin resignar cantidad de validaciones.
Paso 3 — Cruzar señales, geolocalización y reglas
Con las señales adentro, se aplican las reglas. El nodo de matriz permite armar scorecards y matrices de reglas de fraude. La sintaxis de expresiones incluye operaciones geográficas: comparar la ubicación declarada contra la del dispositivo, medir distancias o validar zonas. Y si tenés un modelo de fraude propio, el nodo de modelo o el de Python lo ejecutan dentro del mismo flujo.
Acá es donde tus criterios se vuelven decisión: no es lo que dice un proveedor aislado, sino cómo se combinan todas las señales según tu política.
- Matriz: scorecards y reglas de fraude.
- Operaciones geográficas: geolocalización declarada vs. dispositivo.
- Nodo de modelo / Python: tu score de fraude, sin migrar tu entorno.
Paso 4 — Decidir: los tres carriles
El fraude rara vez es binario. La mayoría de las solicitudes son claramente legítimas o claramente fraudulentas, pero hay una franja gris que no conviene ni aprobar ni rechazar en automático. Los nodos de decisión, switch y binario rutean cada caso a uno de tres carriles: aprobación automática, rechazo automático y revisión manual.
Definir bien qué cae en la franja gris es la diferencia entre un equipo de riesgo desbordado de casos y uno que solo mira los que de verdad lo ameritan.
- Aprobación automática: señales limpias.
- Rechazo automático: fraude claro según tus reglas.
- Revisión manual: la franja gris, con toda la evidencia lista para el analista.
Paso 5 — Contingencia, trazabilidad y prueba
Un proveedor de identidad se cae, y la pregunta es qué pasa con la solicitud. El nodo de buró expone una variable de error de consulta que habilita un camino de contingencia: si el proveedor no responde, el flujo puede derivar a revisión, reintentar con otra fuente o aplicar una regla más conservadora, en vez de frenarse o aprobar a ciegas.
Cada decisión queda trazada con las señales que entraron y las reglas que se aplicaron —la evidencia que un caso de fraude siempre termina necesitando—. Y antes de tocar producción, con champion/challenger probás una regla antifraude nueva sobre tráfico real, en paralelo a la vigente, para ver si mejora sin arriesgar la operación.
- Camino de contingencia si un proveedor falla (no se aprueba a ciegas).
- Cada decisión trazada: señales, reglas y resultado.
- Champion/challenger: probar reglas de fraude sin riesgo.
Documentación técnica
Cómo se implementa esto en el motor, paso a paso.
Dudas habituales
¿uFlow detecta fraude por sí mismo?+
No en el sentido de verificar una biometría o detectar un deepfake: eso lo hacen tus proveedores de identidad y antifraude. uFlow es la capa que los orquesta —los consulta, cruza sus señales con tus reglas y modelos— y decide aprobar, rechazar o derivar a revisión. Detecta el especialista; decide el motor.
¿Puedo conectar el proveedor antifraude que ya uso?+
Sí. Si está homologado, se conecta con el nodo de buró (credenciales, caché, timeout); si no, con un nodo REST a su API. Vale para identidad, antifraude, device intelligence o listas. Todas las señales quedan como variables dentro de la misma política.
¿Qué pasa si un proveedor de identidad se cae en medio de la decisión?+
El nodo de buró expone una variable de error que habilita un camino de contingencia: derivar a revisión, reintentar con otra fuente o aplicar una regla más conservadora. La decisión no se frena ni aprueba a ciegas cuando falta una señal.
Temas relacionados
Champion / Challenger: probar una política nueva sin arriesgar la cartera
Cómo evaluar una política de crédito nueva contra la que ya está en producción, midiendo su impacto real sobre una porción del tráfico antes de adoptarla. La técnica de champion/challenger aplicada a decisiones.
Model riskModel risk: gobernar los modelos de scoring y ML en decisiones de crédito
Los modelos de scoring y machine learning mejoran la decisión, pero introducen riesgo de modelo: sesgo, degradación y falta de explicabilidad. Cómo gobernarlos dentro de un motor de decisiones con validación, monitoreo y trazabilidad.
ProductoCómo lo hace el motor de decisiones de uFlow
Gobierno, versionado y trazabilidad aplicados en el motor, sin frenar al negocio.
Explora todas las guías o lee el blog de uFlow.
¿Te sirve para tu proceso de decisión?
Transforma tu proceso de evaluación crediticia con el motor de decisiones.