Cronología interna · MuleTrace AI
La historia del proyecto no empieza con una arquitectura de red neuronal, sino con analistas de fraude anotando a mano qué cuentas receptoras se comportaban raro en las transferencias interbancarias. Estos hitos marcan cómo pasamos de ese cuaderno a un sistema que evalúa la ordenación antes de que el dinero salga del banco emisor.
Un grupo reducido de analistas empezó a registrar patrones repetidos en cuentas que recibían y dispersaban fondos en pocas horas. Anotaban dispositivo, huella de sesión, antigüedad de la cuenta y velocidad de salida. Ese cuaderno, todavía sin modelo detrás, se convirtió en el primer conjunto de etiquetas que usamos para entrenar.
Al cruzar los registros aparecieron cadenas: una cuenta receptora que enviaba a tres, y esas tres a otras cinco. Construimos un grafo de relaciones y comprobamos que muchas mulas compartían dispositivo o rango horario aunque los titulares fueran distintos. Fue el punto en el que dejamos de mirar cuentas sueltas y empezamos a mirar redes.
El primer despliegue real evaluaba la operación en el momento de la ordenación, no al cierre del día. Eso obligó a trabajar con datos incompletos y a tolerar latencias mínimas. Aprendimos que un modelo con buen recall puede ser inservible si bloquea cuentas nómina legítimas, así que ajustamos umbrales por segmento antes de ampliar cobertura.
Las redes empezaron a operar con varios perfiles que se activaban por turnos: cuando uno se quemaba, otro tomaba el relevo sin cambiar de titular receptor. Incorporamos señales de transición biométrica y de continuidad de sesión para detectar esos relevos. No es una verificación por selfie más estricta, es leer la coordinación temporal entre perfiles.
Hoy el sistema marca operaciones sospechosas y las envía a un equipo que revisa casos límite antes de cualquier bloqueo definitivo. Los falsos positivos siguen siendo el coste más caro de este trabajo, así que medimos precisión por tipo de cuenta y por antigüedad, no solo recall global. La siguiente etapa es ampliar la cobertura a más corredores interbancarios sin perder esa calibración.
MuleTrace AI no nació como producto, sino como una pregunta incómoda: por qué las redes de cuentas mula seguían operando con normalidad mientras los equipos de fraude revisaban los casos al día siguiente. La respuesta estaba en el momento exacto de la ordenación interbancaria, y ahí empezó todo.
El equipo inicial trabajó con extractos anonimizados de dos entidades cooperativas. La idea era simple: si una cuenta receptora aparece en varias dispersiones rápidas hacia dispositivos distintos, algo no encaja. Los primeros modelos apenas distinguían nóminas recurrentes de cuentas de paso, y ese error nos obligó a rehacer la lógica de umbrales por segmento.
Durante meses tratamos el fraude como un problema de flujos. Los datos mostraron lo contrario: las cadenas de perfiles biométricos falsos se sostenían semanas porque cada selfie parecía legítima por separado. Incorporamos señales de sesión, dispositivo y transición entre perfiles, y el recall subió sin disparar los bloqueos erróneos en cuentas con poco historial.
Pasar del cuaderno al entorno real exigió adaptar el motor a latencias de milisegundos y a datos incompletos. La primera integración con un core bancario regional nos enseñó que un modelo con buena precisión offline puede ser inservible si no tolera respuestas parciales. Ajustamos la arquitectura para decidir con lo que hay, no con lo que quisiéramos tener.
Bloquear a un cliente legítimo cuesta más que dejar pasar una operación dudosa. Revisamos curvas de precisión y recall en banca retail y corporativa, y separamos umbrales por antigüedad de cuenta y tipo de titular. El resultado fue menos reclamaciones y una confianza operativa que ningún informe de métricas recoge bien.
El siguiente paso no es más precisión, sino explicabilidad. Los equipos de cumplimiento necesitan reconstruir por qué se marcó una cuenta y qué señales pesaron. Estamos trabajando en registros auditables por operación, sin exponer datos personales, para que la detección sea defendible ante un regulador y ante el propio cliente afectado.