El orden cuenta la historia del cliente

Piense en dos clientes que el mes pasado iniciaron sesión cuatro veces cada uno e hicieron una transferencia grande. En una tabla mensual se ven iguales. Para el primero, la transferencia fue a una cuenta de ahorro que usa desde hace años. Para el segundo, el salario se movió a otro banco el mismo día en que llegó, poco después de un primer inicio de sesión desde un dispositivo nuevo. Los totales coinciden y las historias son distintas.

Los equipos resumen porque los modelos clásicos necesitan un conjunto fijo de columnas por cliente. Cada resumen es una decisión sobre qué olvidar: un conteo de 30 días no distingue un patrón estable de un cambio repentino en los últimos tres días. Los analistas lo compensan con más ventanas y razones, y la lista de variables crece hasta cientos de columnas difíciles de mantener.

El transformer, presentado en 2017 para la traducción automática, es la arquitectura que sustenta los modelos de lenguaje actuales (Vaswani et al.). Un modelo de lenguaje se entrena para predecir la siguiente palabra y, a gran escala, esa tarea le hace aprender gramática y hechos por el camino, porque ambos ayudan a la predicción.

La misma idea funciona con eventos. Trate el historial de cada cliente como una frase cuyas palabras son eventos: un pago con tarjeta, un inicio de sesión, una transferencia, una llamada a soporte. Un modelo entrenado para predecir el siguiente evento, o para completar los ocultos, tiene que aprender qué suele seguir a qué y cómo se ve una ruptura de la rutina, sin que se le diga qué variables calcular.

Varias empresas han publicado este enfoque. Stripe ha descrito un modelo fundacional de pagos entrenado con decenas de miles de millones de transacciones y informó que elevó en 64% su tasa de detección de ataques de prueba de tarjetas contra grandes empresas (TechCrunch, mayo de 2025). Nubank, en Brasil, informó de mejoras en grandes problemas de recomendación con modelos transformer entrenados con historiales de transacciones que ya tenía, sin nuevas fuentes de datos (Braithwaite et al., 2025). Los modelos PRAGMA de Revolut se preentrenan con secuencias de eventos bancarios y se usan para la puntuación de crédito, la detección de fraude y el valor del cliente a lo largo de su vida (Ostroukhov et al., 2026).

Lo habitual es un modelo por pregunta, para quién podría irse, quién tomará un préstamo o qué límite de crédito fijar, cada uno con su propio flujo de datos, su supervisión y su responsable. En unos pocos años un equipo mantiene decenas de flujos que describen a los mismos clientes de maneras ligeramente distintas.

Un modelo entrenado con el comportamiento aprende una representación de cada cliente a partir de sus eventos, y cada pregunta pasa a ser una tarea más pequeña sobre ella. El artículo de PRAGMA indica que un modelo lineal sencillo sobre esa representación ya rinde bien, con mejoras adicionales mediante un ajuste fino ligero. Una pregunta nueva pasa a ser un proyecto más pequeño que un flujo nuevo, y todos los equipos trabajan con la misma visión del cliente.

Tres condiciones deciden si este enfoque dará resultado. El volumen significa suficientes eventos como para que los patrones se repitan, y por eso los pagos y la banca digital son los casos más claros. La continuidad significa que el mismo cliente es reconocible entre sistemas y a lo largo del tiempo, de modo que su historial se lee como una sola historia y no como fragmentos repartidos entre la plataforma de tarjetas, la aplicación y el sistema central. Los resultados significan un registro de lo que ocurrió después de cada decisión, como si el cliente se quedó o pagó. Si falta una condición, empiece por esa.

Cada evento necesita como mínimo su hora, al segundo si es posible, su tipo, su valor y su canal. Conserve los eventos en bruto además de cualquier agregado, y un historial suficiente para cubrir los ciclos lentos de su negocio, como las temporadas y los plazos de los préstamos.

Una entidad de crédito con una base de clientes modesta y cortes mensuales, o un banco cuyos registros aún no pueden cruzarse entre sistemas, normalmente obtendrá más de los modelos clásicos y de variables elaboradas con cuidado. Para tablas pequeñas, TabPFN, un modelo preentrenado para conjuntos de datos tabulares pequeños, superó a los métodos anteriores en conjuntos de hasta 10.000 muestras en las pruebas de sus autores (Hollmann et al., Nature, 2025).

En esos casos el paso más valioso es poner en orden el registro de eventos: un único identificador de cliente, marcas de tiempo conservadas, resultados vinculados a las decisiones. Ese trabajo da frutos con cualquier modelo.

Un modelo entrenado con datos personales debe tratarse como un activo de datos personales. Deje por escrito los fines a los que puede servir y revise cualquier uso nuevo como lo haría con los datos. Controle quién puede consultarlo, fije reglas de conservación para el modelo además de para los datos y compruebe que no memoriza ni revela registros individuales.

Las normas varían según la jurisdicción. En los EAU difieren entre el territorio continental y las zonas francas financieras, y en Brasil se aplica la LGPD. Involucre a la asesoría jurídica desde el principio, mantenga el entrenamiento y la puesta en servicio donde lo exijan sus obligaciones y registre con qué datos se entrenó cada versión del modelo.

Compare un modelo de secuencias con el actual en períodos posteriores que no haya visto, con el plazo de anticipación que necesita el equipo, y compruebe que las tasas predichas coinciden con lo que ocurre: si dice que 7 de cada 100 clientes de un grupo se irán, deberían irse unos 7.

Después mida el resultado de negocio: clientes retenidos o productos contratados en el grupo sobre el que actuó su equipo, frente a un grupo de control reservado al que no contactó, y cuente los flujos independientes que reemplaza el nuevo enfoque.

Elija una pregunta con un responsable claro y resultados registrados, como quién podría irse el próximo trimestre, y ejecute el nuevo enfoque junto al actual antes de ampliarlo.

Mantika Tessera, construido sobre modelos transformer, lee los eventos de cada cliente en orden y predice quién podría irse y quién está listo para más; su equipo decide qué hacer.