Cada deslizamiento de tarjeta, cada transferencia y cada pago en una red financiera moderna codifica un patrón de comportamiento humano. Los datos transaccionales son una de las señales más ricas que tiene un banco o una fintech, pero la mayoría de los casos de uso en producción todavía dependen de features hechas a mano y reglas que son frágiles, caras de mantener y ciegas a la estructura secuencial dentro del historial del cliente.

Los modelos fundacionales preentrenados sobre grandes volúmenes de secuencias sin etiquetar cambian la ecuación: producen representaciones de propósito general del comportamiento financiero que transfieren a tareas muy distintas. Un solo backbone cubre detección de fraude, scoring crediticio, predicción de valor de vida del cliente, segmentación, recomendaciones personalizadas y detección de transacciones recurrentes.

La señal de la industria es fuerte y se acelera. Las firmas financieras innovadoras ya están entrenando transformers sobre miles de millones de transacciones y reportan mejoras relativas de dos dígitos en tareas a escala de producción. Algunos ejemplos públicos: el modelo fundacional de pagos de Stripe, el NuFormer de Nubank, el TransactionGPT de Visa, el modelo tabular grande de Mastercard, el PRAGMA de Revolut y el modelo fundacional de Plaid.

El Build Your Own Transaction Model de NVIDIA recorre el camino completo para construir uno end-to-end con computación acelerada en GPU.

El workflow consta de cinco pasos:

  • Procesamiento de datos acelerado por GPU con la librería CUDA-X cuDF.
  • Tokenización customizada con las librerías CUDA-X cuDF y cuML.
  • Preentrenamiento de un decoder transformer desde cero con NVIDIA NeMo AutoModel, parte del framework NVIDIA NeMo.
  • Extracción de los embeddings aprendidos.
  • Aumento de un clasificador downstream de fraude con esos embeddings.

Al final, se reproduce un alza cercana al 50% en Average Precision (AP), el área bajo la curva precisión-recall, sobre un baseline robusto de XGBoost en el dataset de fraude IBM TabFormer.

Figura 1. Pipeline end-to-end del modelo fundacional de transacciones: las transacciones crudas pasan por procesamiento de datos y tokenización de dominio sobre GPU con NVIDIA CUDA-X, luego al modelo fundacional
Figura 1. Pipeline end-to-end del modelo fundacional de transacciones: las transacciones crudas pasan por procesamiento de datos y tokenización de dominio sobre GPU con NVIDIA CUDA-X, luego al modelo fundacional

¿Por qué los Transformers calzan tan bien con historiales de transacciones?

Los modelos grandes de lenguaje aprenden de secuencias de palabras. Durante el preentrenamiento ven texto y aprenden que las palabras, frases y oraciones cargan significado a través del orden y el contexto. Un modelo fundacional de transacciones aplica el mismo principio al comportamiento financiero. Una secuencia tipo "depósito de sueldo, compra de supermercado, pasaje de transporte, suscripción recurrente, pago con tarjeta presente en restaurante" carga información que ningún registro aislado puede expresar.

Los Transformers calzan bien con esta estructura porque la self-attention puede conectar eventos que están lejos en el historial. Una transacción fraudulenta puede verse sospechosa solo cuando aparece junto a un patrón reciente de viaje o una ráfaga súbita de autorizaciones chicas. Las features tabulares tradicionales pueden aproximar esos patrones, pero los ingenieros tienen que decidir qué ventanas, agregados y reglas construir de antemano. Un transformer preentrenado aprende esas relaciones directamente desde la secuencia.

El enfoque se complementa con otros workflows de IA financiera de NVIDIA, incluyendo el Blueprint para detección de fraude basado en redes neuronales de grafos (GNN). Las GNN capturan relaciones entre entidades conectadas como cuentas, comercios, dispositivos y transacciones. Los modelos fundacionales de transacciones se enfocan en historiales de comportamiento dentro de la secuencia de un cliente. En la práctica, ambos métodos producen embeddings ricos con información complementaria que se combinan naturalmente.

Cargar los datos y fijar un baseline

El notebook 01_dataset_baseline.ipynb carga el dataset IBM TabFormer, aproximadamente 24,4 millones de transacciones de tarjeta sintéticas con una tasa de fraude del 0,12%, directo a memoria de GPU con cuDF.

Los splits del dataset se parten temporalmente por cantidad acumulada: el primer 80% de transacciones por fecha se usa para entrenamiento, el siguiente 10% para validación y el 10% final para test. Esos splits ocupan ventanas temporales disjuntas y ordenadas, lo que evita data leakage y refleja entornos de producción reales.

Con los splits en su lugar, el notebook entrena un clasificador XGBoost con aceleración GPU nativa usando tree_method="hist" y device="cuda" sobre una muestra balanceada de 1M de filas. La evaluación corre sobre un holdout estratificado de 100k que preserva la prevalencia realista de fraude del 0,1%.

Las cifras baseline marcan el listón para el resto del tutorial:

  • Test ROC-AUC: 0,9885
  • Test AP: 0,1238

La métrica a mirar es AP, no ROC-AUC. Con desbalance de clase bajo el 0,1%, ROC-AUC se satura rápido y oculta diferencias importantes en regiones de alto score. AP mide a lo largo de toda la curva de recall y responde a las mejoras donde importan operacionalmente.

Tokenizar transacciones sobre la GPU

Los tokenizadores LLM de propósito general desperdician capacidad sobre datos tabulares financieros. Un tokenizador BPE típico parte una sola transacción en aproximadamente 39 subword tokens, donde la mayoría codifica comas y signos pesos en lugar de comportamiento. El notebook 02_seq_preproc_tokenization.ipynb introduce un tokenizador de dominio que convierte cada transacción en aproximadamente 12 tokens semánticos con un vocabulario mucho más chico (6.251 símbolos frente a 50.257 de BPE).

La eficiencia también permite caber más de 3 veces más transacciones para un mismo presupuesto de tokens. En términos prácticos, un modelo con ventana de contexto de 4.092 alberga un historial de ~315 transacciones con el tokenizador de dominio y solo ~102 con el tokenizador BPE.

El tokenizador de dominio está implementado en src/tokenizer/financial_pipeline.py. El pipeline maneja binning de montos, hashing de comercios, hora del día y día de la semana, mes, identidad de tarjeta, tipo de chip, ZIP3 y estado, y la identidad del cliente. Cada paso corre sobre GPU vía cuDF.

Figura 2. Comparación de eficiencia de tokens entre el tokenizador de dominio (~12 tokens por transacción, vocabulario de 6.251 símbolos) y GPT-2 BPE (~39 tokens por transacción, 50.257 símbolos) sobre los mismos registros
Figura 2. Comparación de eficiencia de tokens entre el tokenizador de dominio (~12 tokens por transacción, vocabulario de 6.251 símbolos) y GPT-2 BPE (~39 tokens por transacción, 50.257 símbolos) sobre los mismos registros

Preentrenar con NeMo AutoModel

NeMo AutoModel es una librería open source nativa de PyTorch bajo el framework NVIDIA NeMo, diseñada para escalar el entrenamiento y el fine-tuning de LLM y VLM.

El notebook 03_foundation_model_training.ipynb preentrena un modelo fundacional decoder-only sobre el corpus tokenizado usando causal language modeling. El objetivo es simple: predecir el siguiente token dado los anteriores, pero la señal de supervisión es densa. Cada posición de la secuencia aporta un gradiente, por lo que una sola secuencia empaquetada de transacciones entrega miles de predicciones de próximo evento.

El modelo es un decoder Llama compacto definido en configs/pretrain_financial_decoder.yaml:

  • ~29M parámetros
  • Hidden size 512, 8 capas de transformer
  • Grouped-Query Attention con 8 query heads y 2 KV heads
  • Ventana de contexto RoPE de 8.192 tokens
  • Activación SwiGLU, RMSNorm, vocabulario de dominio de 6.251 tokens

NeMo AutoModel se encarga del resto del stack. Para arrancar una corrida de validación sobre una sola GPU:

Código
python scripts/train_decoder_model.py \
  --config configs/pretrain_financial_decoder.yaml \
  --step_scheduler.max_steps 30

La demo de 30 pasos baja la pérdida de entrenamiento desde ln(6251) ≈ 8,74 (el baseline aleatorio para ese vocabulario) hasta aproximadamente 6,0. Para escalar la misma corrida a ocho GPUs basta con prefijar el comando con torchrun --nproc-per-node=8, sin cambios al script ni al boilerplate distribuido. El escalamiento multinodo es igual de directo: NeMo AutoModel conecta sharding FSDP2, precisión mixta, acumulación de gradientes y consolidación de checkpoints desde el YAML.

Los checkpoints quedan como archivos safetensors, lo que significa que el backbone entrenado se carga con una línea donde sea que esté instalado HuggingFace Transformers:

Código
from transformers import AutoModelForCausalLM

model = AutoModelForCausalLM.from_pretrained("models/decoder-foundation-model")

El repositorio entrega un checkpoint completo entrenado por 3.000 pasos, que cargan los notebooks 04 y 05; los 30 pasos son para validación.

¿Qué deja esto para fintechs y bancos en LatAm?

Para una fintech chilena o un banco mediano de la región, la receta abre dos puertas concretas. La primera: el modelo fundacional sale en USD 29M de parámetros, escala razonable que se puede entrenar fuera de los hyperscalers más caros, incluso en un H100 single-node arrendado a USD 4-5/h. Tres días de entrenamiento serio entran en USD 300-360 de cómputo, frente a los costos sustanciales de mantener equipos completos de feature engineering tradicional.

La segunda: el dataset usado en la demo (IBM TabFormer, sintético) es público y reproducible, pero la receta migra naturalmente a datos reales. La factura de feature engineering manual que carga sobre los equipos de riesgo en Mercado Pago, Tenpo, Tapp, Mach o cualquier banco con scoring crediticio podría rebajarse si se cambia el paradigma de reglas a embeddings preentrenados.