La historia de MuleTrace AI no empieza con una ronda de inversión ni con una nota de prensa. Empieza con analistas de fraude revisando a mano cadenas de cuentas receptoras que se activaban y se apagaban en cuestión de horas. Estas son las etapas que fuimos atravesando hasta llegar al modelo que hoy evalúa órdenes interbancarias en tiempo real.
Antes de escribir una línea de código, el equipo dedicó semanas a levantar expedientes cerrados de fraude con mulas. Se etiquetaron dispositivos, horarios de apertura de cuenta, patrones de dispersión y saltos biométricos entre perfiles. Ese corpus inicial, todavía pequeño y desordenado, definió qué señales valía la pena perseguir y cuáles eran ruido de fondo.
Con los casos etiquetados construimos un grafo que conectaba cuentas por dispositivo compartido, IP de origen y ventanas de actividad coincidentes. La primera versión marcaba demasiadas cuentas nómina como sospechosas. Aprendimos que la antigüedad de la cuenta y el tipo de producto pesan tanto como el comportamiento reciente, y ajustamos los umbrales por segmento.
El salto importante fue mover la evaluación del cierre del día al momento exacto en que se ordena la transferencia. Eso obligó a reescribir el motor de inferencia para que tolerara datos incompletos: si la huella biométrica del receptor no estaba disponible, el modelo debía decidir igual sin bloquear operaciones legítimas. Fue la etapa más incómoda y la que más cambió el producto.
Las redes de mulas no usan una sola identidad, rotan perfiles cuando uno se quema. Empezamos a rastrear esas transiciones: cambios de titular efectivo sin cambio de cuenta receptora, sesiones que migran de dispositivo en horas raras, selfies que pasan la verificación pero no coinciden con el historial de uso. Ese rastreo es hoy una de las señales más fuertes del sistema.
Un modelo con buen recall puede ser inservible si bloquea clientes reales. Trabajamos con equipos de atención al cliente para medir el coste de cada bloqueo erróneo y ajustar umbrales por tipo de cuenta, antigüedad y canal. El resultado no es un modelo perfecto, es un modelo que el banco puede defender ante una reclamación sin perder capacidad de detección.
Ninguna entidad resuelve sola el problema de las cuentas de alquiler. Estas son las organizaciones con las que hemos construido, probado y desplegado los modelos de detección en producción, con nombre y función dentro del proyecto.
Primer entorno donde se probó el grafo de relación entre cuentas receptoras. Aportaron doce meses de transferencias interbancarias anonimizadas y el equipo de prevención de fraude revisó cada umbral antes de activarlo en horario productivo.
Integramos su motor de prueba de vida con nuestra capa de detección de perfiles sintéticos. El acuerdo cubre el uso de plantillas biométricas bajo consentimiento y un protocolo conjunto para revisar falsos positivos en selfies nocturnas.
Nos dieron acceso a cuentas nómina con poco historial, el segmento donde más se disparan las alertas erróneas. Su equipo de atención al socio documentó cada bloqueo revisado durante la fase piloto.
Auditan nuestros informes de caso antes de que se envíen a la unidad de investigación. Su trabajo se centra en verificar que la evidencia de una cadena de mulas sea defendible ante un requerimiento judicial.
Colaboración abierta para revisar la robustez del modelo frente a datos incompletos. Publicamos conjuntamente las métricas de precisión por segmento y los límites conocidos del sistema.
No venimos de una consultora genérica. El equipo se formó entre mesas de riesgo operacional, equipos antifraude de banca minorista y grupos que construyen grafos transaccionales para pagos inmediatos. Trabajamos con bancos, PSP y cooperativas de crédito que procesan transferencias interbancarias en Argentina y en corredores regionales, y que necesitan decidir antes de que la orden salga del emisor.
MuleTrace nació de una pregunta incómoda: por qué las redes de cuentas mula seguían operando con perfiles biométricos que ya habían sido marcados en otro banco. La respuesta estaba en la falta de señales compartidas en el momento de la ordenación. Empezamos a construir el motor desde ahí, no desde un catálogo de funciones.
Equipo fundador, 2021Nuestros interlocutores habituales son analistas de fraude, responsables de cumplimiento y equipos de ingeniería de datos. Rara vez hablamos con áreas de marketing. Eso define el tono: lenguaje técnico cuando hace falta, sin adornos, y con la suficiente paciencia para explicar por qué un umbral se calibra distinto en banca retail que en banca corporativa.
Perfil de cliente habitualAntes de añadir una señal al modelo, pedimos verla en producción con datos reales y con su tasa de falsos positivos medida por segmento. Si una regla bloquea cuentas nómina legítimas, no entra, aunque mejore el recall. Preferimos un sistema que el equipo de fraude pueda defender ante una reclamación antes que uno que solo luzca bien en una demo.
Principio operativoNo vendemos scoring genérico ni prometemos detección perfecta. Tampoco desplegamos modelos que no puedan auditarse: cada decisión tiene que poder reconstruirse con las señales que la dispararon. Si un cliente pide una caja negra, no es nuestro proyecto.
Límites explícitosOperamos desde Barrio Islas Malvinas, Santiago del Estero, con un equipo distribuido que cubre despliegues en varias zonas horarias. La cercanía con equipos de operaciones locales nos ayuda a entender cómo se comporta el fraude cuando cambian los horarios de acreditación o aparecen nuevas ventanas de liquidación.
Base operativaMuleTrace AI no nació como producto cerrado. Empezó como un ejercicio de análisis sobre transferencias interbancarias que llegaban con señales contradictorias: cuentas nuevas, montos bajos y una dispersión posterior imposible de ignorar. Lo que sigue es el recorrido real de esa idea hasta convertirse en un sistema que hoy corre dentro del flujo de ordenación de pagos.
El trabajo inicial se hizo con datos históricos de un solo banco emisor. La pregunta era acotada: ¿se puede distinguir una cuenta mula de una cuenta nómina recién abierta antes de que la orden salga? Los primeros modelos acertaban en casos evidentes, pero fallaban en cuentas con poca antigüedad y en clientes que operaban desde dispositivos compartidos. Ese límite marcó la agenda de los meses siguientes.
La detección por señales aisladas no alcanzaba para las cadenas de perfiles biométricos falsos. Incorporamos grafos que conectan cuentas por dispositivo, IP, horario de actividad y patrón de dispersión. Cuando un perfil se quema, otro toma el relevo con la misma cuenta receptora; el grafo lo muestra antes de que el titular cambie. Fue el cambio de enfoque más importante del proyecto.
Un modelo con buen recall puede ser inservible si bloquea cuentas legítimas. Trabajamos con equipos de fraude y de atención al cliente para medir el coste real de cada bloqueo erróneo: reclamación, tiempo de resolución y pérdida de confianza. Los umbrales se ajustan por tipo de cuenta, antigüedad y volumen operativo, no con una regla única para toda la cartera.
La decisión se toma en la ventana de milisegundos previa a la salida del dinero, con datos que a veces llegan incompletos. Eso obliga a que el sistema tolere huecos, devuelva una señal clara y no frene la operación cuando la evidencia es débil. Hoy la capa convive con los motores de riesgo existentes y aporta una lectura adicional que antes no estaba disponible.
El siguiente frente son las redes que operan entre varias entidades y cambian de banco receptor cada pocos días. Ahí el reto no es solo el modelo, sino compartir señales sin exponer datos de clientes. Esa discusión, más de gobernanza que de algoritmia, define hacia dónde avanza MuleTrace AI en los próximos trimestres.
Detrás de cada alerta hay un equipo que responde. Cuando un banco emisor recibe una marca de cuenta mula, la duda no es solo técnica: hay que saber a quién escribir, en qué horario y qué esperar. Estos son los canales activos y los plazos que manejamos con las entidades integradas.
Antes de escribir, conviene revisar las preguntas frecuentes: muchas dudas sobre falsos positivos, calibración de umbrales y límites del modelo ya están resueltas ahí.
Ir a preguntas frecuentes Política de tratamiento de datos