En resumen: Probamos Jev, el nuevo modelo de Sistema Uno de TypeSafe AI para tomar decisiones rápidas entre sistemas de software, en tres problemas de fraude y cumplimiento normativo de Sardine. En una red de fraude real, detectó el 93 % de las transacciones fraudulentas, frente al 62 % de Claude Sonnet (31 puntos más de exhaustividad), con aproximadamente 1/25 del coste y ~100 ms por llamada.
- Decisiones sobre redes de fraude: Jev detectó 27 de 29 transacciones fraudulentas, frente a 26 con nuestro enfoque basado en reglas y 18 con Sonnet.
- Discrepancia entre el nombre y el correo electrónico: una señal que durante años se ha resistido a ser codificada ahora es lo bastante rápida y precisa como para utilizarla en una decisión en tiempo real.
- Respuestas de KYB para otro software: Jev es ahora un nodo de Sardine Flow que convierte los hallazgos en respuestas estructuradas sobre las que puede actuar el agente de un cliente.
Sardine ayuda a bancos, empresas fintech y compañías de pagos a determinar si un inicio de sesión, un pago o una nueva cuenta empresarial son legítimos. Estas decisiones se toman cientos de veces por segundo, y cada una debe completarse en una fracción de segundo, porque hay un cliente esperando.
Esa limitación explica por qué el sector se basa en reglas y modelos de aprendizaje automático, y por qué los grandes modelos de lenguaje se han mantenido en gran medida al margen. Un LLM puede analizar bien una transacción sospechosa, pero tarda varios segundos en responder y cuesta alrededor de un centavo por consulta, y ninguna de las dos cosas resulta viable cuando hay que decidir sobre miles de pagos por minuto.
TypeSafe AI lanzó Jev en septiembre como un tipo de modelo diferente. Está diseñado para que lo invoque un programa, sin intervención humana. Se le envía un bloque de datos y una lista de preguntas tipificadas, y devuelve una respuesta por pregunta: un sí o un no con una probabilidad, una opción de una lista definida por el usuario o una posición en una escala también definida por el usuario. Cada llamada tarda unos 100 milisegundos y cuesta una fracción de céntimo.
TypeSafe AI lo denomina un modelo de Sistema 1, en referencia al modo de pensamiento rápido e intuitivo descrito por Daniel Kahneman en Pensar rápido, pensar despacio. En una plataforma de detección de fraude hay multitud de situaciones en las que el software necesita precisamente eso: una evaluación rápida y coherente basada en pruebas estructuradas. Probamos Jev en tres de ellas.
Primero, como decisión final sobre una red de fraude; después, como forma de calcular una señal que durante años se ha resistido a ser codificada; y, por último, como la pieza que convierte una comprobación de negocio en respuestas sobre las que otros programas pueden actuar.
1. Detección de transacciones vinculadas a redes de fraude
En septiembre, uno de nuestros clientes, una plataforma de acceso a stablecoins, lanzó un nuevo producto y, en cuestión de días, fue víctima de una red de fraude. Nos remitieron cinco usuarios que sabían que eran fraudulentos. Nuestro análisis de vínculos, que relaciona las cuentas que comparten un dispositivo, una dirección de correo electrónico o una tarjeta, amplió esa lista a 13 usuarios y 29 transacciones fraudulentas con tarjeta que habían pasado inadvertidas.
Utilizamos este incidente para comparar tres formas de determinar si esas 29 transacciones eran fraudulentas.
El primero fue nuestro enfoque actual. Nuestro Agente Analista de Datos, un agente de IA que investiga incidentes escribiendo sus propias consultas a la base de datos, comparó el comportamiento de la red con el de miles de usuarios normales durante esos mismos diez días. Descubrió que la red utilizaba una media de cuatro tarjetas por cuenta, frente a las 1,8 del resto de los usuarios, y que usaba más del doble de direcciones IP.
A continuación, propuso tres reglas de velocidad (reglas que contabilizan la frecuencia con la que ocurre algo durante un intervalo de tiempo) basadas en esas diferencias. Esas reglas habrían detectado 26 de las 29 transacciones, lo que supone una tasa de detección del 90 %.
El segundo y el tercero parten del mismo punto: el código calcula los datos de cada transacción, como cuántos clientes distintos comparten esta tarjeta o dispositivo y cuántas transacciones se han asociado a este correo electrónico durante la última hora. A continuación, esos datos se pasan a un modelo para que tome la decisión. En uno de los procesos, el modelo era Claude Sonnet, un LLM de propósito general. En el otro era Jev, que planteaba una única pregunta: en una escala de bajo a muy alto, ¿qué nivel de riesgo de pertenecer a una red de fraude presenta esta transacción?
Jev detectó 27 de 29 casos, es decir, el 93 %. El LLM detectó 18, o el 62 %.
La diferencia se reduce a la consistencia. Una cuenta de la red, registrada con el nombre «Jedi Force», realizó 12 transacciones en unos 100 minutos. Algunas de esas transacciones utilizaron una tarjeta que también había usado otra cuenta de la red, mientras que otras utilizaron una tarjeta nueva.
Una salvedad: le hicimos a Jev una única pregunta general: «¿Qué nivel de riesgo de estar vinculada a una red de fraude presenta esta transacción?». Tras comentar los resultados con TypeSafe, nuestro siguiente paso será desglosarla en preguntas más específicas, como si la cuenta está mostrando un pico de actividad y si la tarjeta o el dispositivo están vinculados a otras cuentas. Comprobaremos si esto permite afinar aún más las puntuaciones. Estos resultados corresponden a la versión con una sola pregunta.
Jev calificó las 12 transacciones como de alto riesgo, dentro de un margen estrecho, porque consideró que el hecho predominante era que se hubieran realizado doce transacciones en menos de dos horas y que el uso compartido de la tarjeta era solo un pequeño factor adicional. Sonnet evaluó cada transacción por separado y permitió que la alerta de la tarjeta modificara su veredicto en un nivel completo, por lo que el mismo pico de actividad de la misma cuenta dio como resultado una combinación de riesgo medio y alto. El nivel más bajo de esos dos normalmente no bloquea un pago.
Jev también resultó mucho más barato y rápido. Sus llamadas contenían menos de mil tokens de entrada (aproximadamente una página de texto) y tardaban unos 100 milisegundos cada una; las 29 decisiones costaron en total alrededor de una décima de centavo. La ejecución con el LLM costó unas 25 veces más, y eso agrupando las 29 evaluaciones en una sola solicitud, algo que no puede hacerse en un flujo de pagos en tiempo real. Si se evalúa cada transacción a medida que llega, un LLM tendría que procesar todas sus instrucciones en cada llamada y tardaría varios segundos en responder.
Jev no tiene estado: no conserva memoria entre llamadas ni puede obtener datos por sí mismo, por lo que todo lo que sabe sobre una transacción debe calcularse primero mediante código e incluirse en la solicitud. Esa es también la razón por la que las reglas obtuvieron resultados tan similares. La vinculación de cuentas y los recuentos de frecuencia son los que detectan la mayor parte del fraude, y son idénticos en todos los pipelines. Lo que aporta Jev es una forma más barata, rápida y coherente de convertir esas pruebas en una decisión.
Esa coherencia también aporta beneficios en las etapas posteriores. Nuestros agentes de recomendación de reglas aprenden de casos etiquetados, y un modelo que evalúa siempre el mismo comportamiento de la misma manera genera mejores etiquetas que uno cuyas respuestas varían de una llamada a otra; a su vez, esas etiquetas se convierten en reglas más sólidas.
2. Identificación de señales sospechosas durante la incorporación
Se abre una cuenta a nombre de Krista Thomason, pero la dirección de correo electrónico asociada es dylan.whitman@gmail.com. Una persona detecta el problema en un segundo. Sin embargo, crear código que lo detecte de forma fiable ha resultado sorprendentemente difícil, y todos los equipos de prevención del fraude llevan años intentándolo.
La dificultad radica en que la mayoría de las discrepancias son inocentes. La gente usa apodos, iniciales y segundos nombres, y los cónyuges y familiares comparten una dirección. Los nombres se transliteran, se reordenan y pierden los acentos, y una gran proporción de los correos electrónicos no contiene ningún nombre, sino solo un alias o una cadena de dígitos. Una regla lo bastante estricta como para detectar a Dylan también marca a miles de clientes legítimos.
Ya hemos intentado resolver este problema antes, al igual que casi todos los que llevan suficiente tiempo trabajando en la prevención del fraude, y los dos obstáculos siempre han sido los mismos: la precisión y la latencia. Los métodos que ofrecían suficiente precisión, incluido consultar a un LLM, tardaban demasiado en ejecutarse como parte de una decisión que debe tomarse antes de que se cargue la página.
Así que le planteamos el problema a Jev. La solicitud incluye los campos de nombre y la dirección de correo electrónico. La pregunta ofrece tres opciones:
- el correo electrónico coincide con el nombre
- el correo electrónico no contiene información útil sobre el nombre
- el correo electrónico pertenece claramente a otra persona.
Las instrucciones detallan los casos inocuos para que el modelo los considere coherentes y reservan «persona diferente» para los correos electrónicos que contienen el nombre de otra persona.
Reformulamos esa pregunta varias veces. Cada versión distinguía las cuentas que no coincidían de las legítimas con mayor claridad que nuestro enfoque anterior, e incluso las probabilidades predeterminadas que devuelve Jev, antes de cualquier ajuste, ofrecían una separación útil. Todas las respuestas llegaron con la rapidez suficiente para usarlas en la decisión en tiempo real. En nuestra herramienta interna de pruebas, «Richard Anderson» asociado al correo electrónico de un desconocido se identifica como una persona diferente, mientras que el mismo nombre con un correo electrónico r.anderson se considera coherente con un 98 % de confianza.
La respuesta es una característica, en el sentido del aprendizaje automático: una nueva señal que nuestras reglas y modelos pueden utilizar junto con las miles que ya tienen. El plan es ponerla a disposición de la misma forma en que ofrecemos cualquier otro dato. Así, se podría escribir una regla como «si el correo electrónico pertenece a otra persona y la tarjeta se añadió en la última hora, solicitar un paso de verificación adicional». El caso límite pendiente son los apellidos de casada, en los que el apellido cambia legítimamente, y estamos trabajando en ello antes de lanzar esta función. Al integrar Jev en nuestro motor de reglas, no solo podemos ofrecer funciones avanzadas como esta a nuestros clientes, sino que también permitimos que nuestros usuarios definan sus propias funciones personalizadas para realizar comprobaciones rápidas sobre todo tipo de problemas.
3. Automatización de las comprobaciones de riesgo KYB
Cuando mostramos este tercer uso al equipo de TypeSafe AI, lo calificaron como el caso de uso por excelencia de Jev.
Cuando una empresa solicita una cuenta de comercio o una cuenta bancaria, la institución debe comprobar que se trata de una empresa registrada y en funcionamiento, entender a qué se dedica y detectar posibles señales de alerta antes de aprobar la solicitud. En el sector, este proceso se conoce como Know Your Business (KYB). Nuestro producto Web360 se encarga de recopilar la información: verifica el número de identificación fiscal y los registros estatales de la empresa, consulta su sitio web, realiza búsquedas en Internet y recopila reseñas en línea. A continuación, presenta los resultados para que un investigador los evalúe.
En los últimos meses, cada vez más clientes nos han pedido algo diferente. Están desarrollando sus propios agentes de IA y flujos automatizados de apertura de cuentas, y quieren que los hallazgos de Web360 se proporcionen como respuestas que su software pueda utilizar.
¿Existen hallazgos adversos graves sobre esta empresa, como demandas o medidas regulatorias? ¿La actividad observada se ajusta a nuestra política de incorporación de clientes? ¿Se trata de la entidad jurídica correcta? Cada una de estas preguntas requiere siempre un campo fijo con un conjunto definido de valores.
Nuestro enfoque anterior consistía en escribir manualmente la lógica de la aplicación para cada pregunta. Tomemos como ejemplo el historial de reclamaciones. Aplicábamos una heurística a las reseñas del Better Business Bureau para intentar distinguir un patrón de reclamaciones graves de las quejas habituales, y cada cliente quería que se definiera de una manera ligeramente distinta. Mantener una lógica personalizada para cada pregunta y cada cliente no es escalable.
Con Jev, escribimos la pregunta una sola vez, le proporcionamos la información que hemos recopilado y recibimos una respuesta con una estructura fija. Hemos añadido Jev como nodo en Sardine Flow, nuestro creador de flujos de trabajo. Ahora, un flujo puede recopilar la información en sus primeros pasos, plantearle a Jev una serie de preguntas específicas al respecto y registrar las respuestas como etiquetas estructuradas. En una demostración realizada en nuestro entorno de pruebas con la propia Sardine, un flujo que añade un paso de búsqueda web y pregunta «¿esta empresa cuenta con financiación de capital riesgo?» responde que sí e indica una cifra superior a los 100 millones de dólares.
El mismo proceso de investigación ahora termina de una de estas dos maneras. La vía destinada a los investigadores muestra a una persona todo lo que encontró Web360. La vía destinada a la API, a la que recurre otro software, procesa la misma información mediante Jev y devuelve las respuestas estructuradas que espera el agente del propio cliente.
Estamos ultimando el desarrollo conjunto de Web360 y Jev con una empresa de la lista Fortune 500 como socio de diseño. Uno de los mayores bancos digitales del mundo también tiene previsto utilizar agentes basados en Jev para revisar sus alertas de cumplimiento e incorporar los resultados a sus propios flujos de trabajo.
Dónde nos deja esto
En los tres casos de uso, Jev asumió una tarea concreta: tomar una decisión basada en pruebas estructuradas dentro del tiempo que un cliente está dispuesto a esperar. Hasta ahora, esa decisión recaía en una persona, en una heurística poco robusta o en un LLM demasiado lento para decidir en tiempo real. La recopilación de datos, la vinculación de cuentas y las reglas se mantienen, porque Jev solo ve aquello que el código pone ante él.
Lo primero: probar preguntas descompuestas para puntuar redes de fraude, siguiendo las recomendaciones de TypeSafe. El etiquetado de eventos, las recomendaciones de reglas y la puntuación de riesgos tienen la misma estructura, así que esos son los siguientes ámbitos en los que pensamos probarlo. Publicaremos más información a medida que repitamos los experimentos con más incidentes. Si estás creando sistemas de decisión con Jev en otro ámbito, nos gustaría intercambiar experiencias.
