Detección de fraude con IA en bancos y fintechs: qué hace el modelo y dónde se decide

La pregunta llega casi siempre con la misma forma: si un modelo de inteligencia artificial puede detectar fraude, ¿por qué no dejar que decida? La respuesta corta es que el modelo y la decisión son dos cosas distintas, y confundirlas es lo que más caro sale en un banco o una fintech.

Un modelo puntúa: mira una operación y dice cuánto se parece a un fraude. La decisión de aprobar, frenar o mandar a revisión se toma en otro lado, con reglas que tu área de riesgo controla y con evidencia que después puedas mostrar. Este artículo separa las dos capas y explica dónde se ubica cada una.

Qué es la detección de fraude en crédito

Es el conjunto de controles que intentan frenar una operación antes de que el dinero salga, cuando la persona no es quien dice ser, cuando la identidad fue armada con datos reales y falsos, o cuando quien pide sí es real pero no piensa pagar. En originación digital los casos más frecuentes son estos:

• Suplantación de identidad. Alguien usa documentos y datos de otra persona, cada vez más con imágenes generadas o deepfakes en el onboarding.
• Identidad sintética. Un perfil construido mezclando datos verdaderos con inventados, que suele pasar un control aislado y cae al cruzar fuentes.
• Fraude de primera parte. El solicitante es real, la información es real, y la intención es no pagar desde el primer día.
• Cuentas mula y velocidad. Muchas solicitudes desde el mismo dispositivo, la misma dirección o el mismo patrón en poco tiempo.

Ninguno de esos casos se resuelve con una sola señal. Se resuelven cruzando varias, y ahí es donde entra la IA, aunque no como suele venderse.

Qué hace bien un modelo de IA, y qué no

Lo que hace bien es encontrar patrones que una regla escrita a mano no ve: combinaciones raras de dispositivo, horario, geolocalización, historial y comportamiento que en conjunto se parecen a fraudes anteriores. Lo hace en milisegundos y sobre miles de operaciones, que es exactamente lo que un equipo humano no puede hacer.

Lo que no hace es decidir por tu política. Un modelo devuelve una probabilidad, no un criterio de negocio. No sabe cuánto riesgo aceptas en un producto nuevo, no sabe que en un país el documento de identidad se valida distinto, y no puede ser el registro al que acudes cuando un cliente reclama o un supervisor pregunta. Es probabilístico por diseño: dos corridas parecidas pueden dar puntajes distintos, y eso está bien para detectar, pero no para explicar.

Por eso el error más común es poner el modelo como decisor. Funciona un tiempo, hasta que hay que responder por qué se rechazó a alguien en marzo, o hasta que el proveedor cambia la versión y nadie puede reconstruir qué pasó.

Dónde se toma la decisión

En un motor de decisiones. No porque el motor detecte el deepfake, sino porque es el lugar donde las señales se juntan y se convierten en una decisión gobernada. El motor conecta a tus proveedores de identidad, antifraude y buró, los consulta en paralelo, cruza lo que devuelven con tus reglas y resuelve por uno de tres carriles: aprobar, rechazar o derivar a revisión humana.

Eso cambia dos cosas. La primera es que el modelo antifraude deja de ser una caja que dice sí o no y pasa a ser una variable más de la política, con un umbral que tu equipo de riesgo mueve cuando el negocio lo pide, sin esperar un desarrollo. La segunda es que cada decisión queda con su evidencia: qué se consultó, qué devolvió cada fuente, qué regla aplicó y qué versión de la política estaba vigente.

Proveedores de identidad y KYC como Truora o Become Digital entran justamente por ahí, como aliados integrados al flujo, no como una decisión aparte. El paso a paso de cómo se arma ese flujo está en la guía para construir un flujo antifraude en el motor.

Las señales valen más combinadas

Una señal aislada casi nunca alcanza. Un dispositivo nuevo no es fraude. Una dirección repetida tampoco. Un documento con una inconsistencia menor, tampoco. Las tres juntas, en la misma solicitud, son otra historia. La detección efectiva está en el cruce, y ese cruce es trabajo del motor, no del modelo.

• Identidad y documento. Validación biométrica y del documento, más lo que un agente lee del comprobante o el extracto: si los ingresos declarados no cierran con lo que dice el papel, esa inconsistencia es una variable de la política.
• Dispositivo y contexto. Geolocalización, huella del dispositivo, horario, cantidad de intentos y velocidad entre solicitudes.
• Historial. Lo que devuelven los burós y las fuentes de datos conectadas, cruzado con lo que la persona declara.
• Comportamiento previo. Si ya es cliente, cómo pagó, cómo operó, y si el patrón de hoy se parece al de siempre.

Cuando esas señales se combinan y se calculan valores derivados, un puntaje que solo era sospechoso pasa a tener contexto. Y la política puede decir algo más fino que rechazar: puede mandar a revisión solo los casos donde de verdad hace falta una persona.

Qué evaluar al elegir cómo hacerlo

Si estás comparando alternativas, estas cinco preguntas separan una solución que detecta de una que además te deja gobernar:

1. ¿Los proveedores se consultan en paralelo, o uno después del otro sumando latencia en cada paso?
2. ¿Qué pasa si un proveedor de identidad se cae en medio de la decisión? ¿Hay contingencia definida o la operación se pierde?
3. ¿El umbral del modelo lo cambia riesgo en horas, o hay que pedirlo a sistemas y esperar un release?
4. ¿Cada decisión deja evidencia reconstruible: fuentes consultadas, respuestas, regla aplicada, versión vigente?
5. ¿Existe el carril de revisión humana, o el único resultado posible es aprobar o rechazar?

Para un banco, además, pesa la segregación de funciones y el control de cambios: quién puede mover un umbral, quién aprueba y qué queda registrado. Eso está desarrollado en uFlow para bancos.

Lo que cambia en la operación

El efecto más visible no es atrapar más fraude, es dejar de rechazar clientes buenos por sospechas débiles. Cuando el modelo es el único decisor, la forma de bajar el fraude es subir el umbral, y con eso se van también solicitudes legítimas. Con tres carriles, lo dudoso va a revisión y lo claro se resuelve solo, en los dos sentidos.

El segundo efecto es la trazabilidad. Ante un reclamo, una auditoría o un cambio de proveedor, la pregunta ya no es qué habrá pensado el modelo, sino qué dice el registro. Y el registro existe porque la decisión se tomó en un lugar diseñado para dejarlo.

Si quieres ver cómo se ordena esto sobre tu flujo actual, revisamos qué proveedores tienes, qué señales ya consultas y cómo quedaría la política con sus tres carriles y su evidencia. Hablemos.