Skip to content
Muestra el paso de las finanzas intuitivas a las finanzas basadas en datos.
El libro explica cómo y construyeron una forma de inversión basada en matemáticas, estadística, cómputo y patrones en datos de mercado, no en narrativas tradicionales de Wall Street. Esto conecta directamente con el objetivo del curso: diseñar soluciones de Big Data que extraigan valor de datos estructurados y no estructurados en instituciones financieras .Es un caso extremo de “datos como ventaja competitiva”. Su fondo Medallion tuvo una rentabilidad de más del 66 % anualizada antes de comisiones y del 39 % después de comisiones en un periodo de 30 años, de 1988 a 2018.
Renaissance no solo usó modelos; creó una organización alrededor de la captura, limpieza, integración y explotación sistemática de datos. Esa lógica conversa muy bien con los temas del curso sobre data lakes, data warehouses, gobierno de datos, calidad, consistencia y seguridad .Ilustra el verdadero valor de la analítica avanzada.
El subtítulo del libro habla de la “revolución quant”. Según Penguin Random House, la obra narra cómo Simons impulsó el uso de enfoques matemáticos y computacionales para operar mercados financieros, y fue finalista del premio Financial Times/McKinsey Business Book of the Year .Permite discutir los límites de los modelos.
No es solo una historia de éxito. También permite hablar de overfitting, ruido, sesgos, opacidad, dependencia de infraestructura, talento escaso y riesgo operacional. Estos temas son centrales cuando se enseña machine learning escalable, scoring, fraude, trading, riesgo y cumplimiento en finanzas .Ayuda a entender el perfil de talento requerido.
Simons contrató matemáticos, físicos, científicos e ingenieros más que financieros tradicionales. Ese punto es útil para discutir por qué las instituciones financieras modernas necesitan equipos híbridos: negocio, datos, tecnología, riesgo, regulación y ciencia aplicada.
Clase 4 — Analítica, AI y Taller Práctico
Duración: 2 horas
Cómo convertir una arquitectura Big Data en soluciones analíticas aplicadas al negocio financiero.
Objetivo de aprendizaje
Al finalizar la clase, el participante será capaz de identificar casos de uso prioritarios de Big Data en instituciones financieras, comprender cómo se integran modelos de machine learning en arquitecturas distribuidas y diseñar una solución conceptual para detección de fraude en pagos móviles considerando fuentes de datos, procesamiento batch/streaming, modelos analíticos, outputs de negocio, escalabilidad y costo-efectividad.
De la arquitectura al valor analítico
En las primeras tres clases se construyó el fundamento: qué es Big Data en finanzas, qué tecnologías lo hacen posible y cómo se organiza una arquitectura institucional con data lakes, data warehouses y gobierno de datos.
La cuarta clase responde la pregunta final:
¿Para qué sirve todo esto en una institución financiera?
La respuesta no está en almacenar más datos ni en adoptar tecnologías sofisticadas por sí mismas. El valor aparece cuando los datos se convierten en decisiones: aprobar o rechazar una transacción, detectar un fraude, ajustar una oferta, anticipar la salida de un cliente, recalibrar un modelo de riesgo o activar una alerta regulatoria.
En finanzas, Big Data se justifica cuando permite tomar decisiones con mayor precisión, mayor velocidad, mayor cobertura o menor costo operativo que los métodos tradicionales.
2. Analítica de Big Data en finanzas
La analítica de Big Data puede entenderse como el conjunto de métodos, modelos y procesos que permiten transformar grandes volúmenes de datos financieros en señales accionables.
No se trata únicamente de hacer reportes más grandes. Se trata de construir sistemas capaces de aprender de millones de eventos, detectar patrones difíciles de observar manualmente y operar con niveles de velocidad compatibles con la realidad financiera moderna.
Tipos de analítica
Modelo_madurez_analitica_BDS.pdf
Tipo de analítica
Pregunta que responde
Ejemplo financiero
Descriptiva
¿Qué pasó?
Evolución diaria de transacciones rechazadas
Diagnóstica
¿Por qué pasó?
Causas del aumento en fraudes por canal digital
Predictiva
¿Qué puede pasar?
Probabilidad de churn o default
Prescriptiva
¿Qué conviene hacer?
Mejor acción comercial para cada cliente
Automatizada
¿Qué acción debe ejecutarse ahora?
Bloquear o autorizar una transacción en tiempo real
There are no rows in this table
La diferencia clave de Big Data es que estos análisis pueden ejecutarse sobre fuentes múltiples, con datos estructurados y no estructurados, y en algunos casos con latencias de segundos o milisegundos.
3. Casos de uso
Analytics Value Framework – Financial Services.mmap
91.2 KB
3.1 Comportamiento del cliente
Uno de los casos más importantes de Big Data en banca, seguros y fintech es el análisis del comportamiento del cliente.
Las instituciones financieras ya no dependen únicamente de variables demográficas o saldos promedio. Ahora pueden integrar datos de transacciones, navegación digital, uso de app, interacciones con call center, campañas, redes sociales y comportamiento histórico.
Preguntas de negocio
Pregunta
Aplicación analítica
¿Qué clientes están en riesgo de abandono?
Modelos de churn
¿Qué producto es más probable que compre cada cliente?
Next best offer
¿Qué clientes están subatendidos?
Segmentación conductual
¿Qué canal prefiere cada cliente?
Optimización omnicanal
¿Qué señales anticipan insatisfacción?
Análisis de experiencia y texto
There are no rows in this table
Ejemplo
Un banco quiere reducir la cancelación de cuentas. El modelo tradicional usa edad, ingreso estimado, saldo promedio y antigüedad. Un enfoque Big Data incorpora además frecuencia de uso de la app, caída en transacciones, llamadas al call center, reclamos, navegación web, respuestas a campañas y comentarios en canales digitales.
El resultado no es solamente una predicción de churn, sino una recomendación de acción: llamada preventiva, ajuste de comisión, oferta personalizada, cambio de canal o seguimiento por ejecutivo.
3.2 Detección de fraude a gran escala
La detección de fraude es uno de los casos más naturales para Big Data porque combina volumen, velocidad, variedad y costo económico directo.
Cada transacción puede contener señales de riesgo: monto, comercio, ubicación, dispositivo, hora, patrón histórico, comportamiento del cliente, tipo de tarjeta, IP, geolocalización, historial del comercio y relación con eventos previos.
Por qué Big Data es necesario
El fraude financiero no se comporta como un problema estático. Los patrones cambian, los atacantes aprenden y las reglas fijas se vuelven obsoletas. Además, las instituciones deben encontrar un equilibrio delicado: bloquear fraudes sin afectar transacciones legítimas.
Reto
Implicación
Millones de transacciones
Se requiere procesamiento distribuido
Decisiones en segundos
Se requiere streaming
Patrones cambiantes
Se requieren modelos adaptativos
Falsos positivos costosos
Se requiere calibración fina
Ataques coordinados
Se requiere análisis de redes y anomalías
There are no rows in this table
Ejemplo
Una billetera digital procesa pagos móviles. Cada transacción debe evaluarse casi en tiempo real. El sistema combina reglas de negocio, modelos supervisados, detección de anomalías y alertas operativas. Algunas transacciones se aprueban automáticamente, otras se rechazan y otras se envían a revisión.
3.3 Trading e inversiones
En trading e inversiones, Big Data se utiliza para integrar datos de mercado, noticias, reportes, redes sociales, indicadores macroeconómicos y señales alternativas.
El objetivo no es solamente procesar más información, sino encontrar señales que ayuden a tomar decisiones de inversión, cobertura, arbitraje o gestión de portafolio.
Fuentes de datos
Fuente
Uso potencial
Precios y volúmenes intradía
Modelos cuantitativos
Libros de órdenes
Microestructura de mercado
Noticias financieras
Señales de evento
Reportes corporativos
Análisis fundamental automatizado
Redes sociales
Sentiment y señales tempranas
Datos macroeconómicos
Modelos de asignación de activos
There are no rows in this table
Advertencia
En inversiones, más datos no necesariamente significan mejores decisiones. El riesgo de sobreajuste (overfitting) es alto. Un modelo puede encontrar patrones estadísticos que funcionaron en el pasado, pero que no tienen poder predictivo real hacia adelante.
Por eso, los modelos de trading requieren backtesting robusto, validación fuera de muestra, control de costos de transacción y evaluación de estabilidad.
3.4 Riesgos y cumplimiento
Big Data también permite mejorar la gestión de riesgos financieros, operativos, de liquidez, mercado, crédito y cumplimiento regulatorio.
La diferencia frente a los enfoques tradicionales es que la institución puede monitorear eventos en tiempo casi real y no solamente producir reportes periódicos.
Aplicaciones
Tipo de riesgo
Aplicación Big Data
Crédito
Scoring alternativo y alertas tempranas
Mercado
Monitoreo intradía de exposiciones
Liquidez
Alertas por salidas inusuales de fondos
Operativo
Detección de fallas, errores y eventos anómalos
Cumplimiento
Monitoreo AML, KYC y transacciones sospechosas
There are no rows in this table
Ejemplo
Una institución puede detectar una caída anómala de liquidez intradía si integra transacciones, retiros, transferencias, pagos programados, saldos, límites y eventos externos. El valor no está sólo en medir el riesgo, sino en activar alertas antes de que el problema escale.
4. Integración de Big Data con Machine Learning
Big Data y Machine Learning se complementan. Big Data provee la infraestructura para capturar, procesar y organizar grandes volúmenes de información. Machine Learning permite extraer patrones, clasificar eventos, predecir comportamientos y recomendar acciones.
La integración ocurre cuando los datos dejan de alimentar únicamente dashboards y comienzan a alimentar modelos que operan en producción.
4.1 Flujo general de un modelo ML en Big Data
Etapa
Descripción
Ingesta
Captura de datos transaccionales, digitales, históricos y externos
Preparación
Limpieza, deduplicación, homologación y enriquecimiento
Feature engineering
Construcción de variables predictivas
Entrenamiento
Uso de datos históricos para aprender patrones
Validación
Pruebas de desempeño, sesgo, estabilidad y generalización
Despliegue
Modelo disponible para scoring batch o en tiempo real
Monitoreo
Seguimiento de desempeño, drift y falsos positivos
There are no rows in this table
4.2 MLlib de Spark
MLlib es la biblioteca de machine learning de Apache Spark. Su ventaja principal es que permite entrenar modelos sobre grandes volúmenes de datos distribuidos.
En lugar de mover toda la información a una sola máquina, Spark distribuye el procesamiento entre múltiples nodos. Esto resulta útil cuando el volumen de datos supera la capacidad de herramientas tradicionales.
Casos típicos
Caso
Uso de MLlib
Scoring crediticio
Entrenar modelos sobre millones de historiales
Segmentación
Agrupar clientes por comportamiento
Propensión de compra
Predecir probabilidad de contratación
Fraude
Clasificación de transacciones sospechosas
Riesgo
Modelos de predicción con grandes datasets
There are no rows in this table
4.3 TensorFlow distribuido
TensorFlow distribuido permite entrenar modelos más complejos, incluyendo redes neuronales profundas, sobre infraestructura escalable.
Puede utilizarse cuando el problema requiere procesar datos de gran tamaño, señales no estructuradas o arquitecturas de modelos más sofisticadas.
Casos posibles
Caso
Aplicación
Texto de reclamos
Clasificación automática de motivos
Imágenes de documentos
Validación y extracción de información
Series temporales
Predicción de comportamiento financiero
Fraude complejo
Redes neuronales para patrones no lineales
Riesgo alternativo
Modelos con fuentes no tradicionales
There are no rows in this table
5. Ejemplo desarrollado: scoring crediticio con Big Data
Un banco desea mejorar su modelo de originación de crédito personal. El modelo actual utiliza variables tradicionales: ingreso, edad, empleo, historial crediticio y deuda actual.
Con Big Data, el banco puede integrar nuevas señales:
Fuente
Variable posible
Transacciones bancarias
Estabilidad de ingresos y gasto recurrente
Comportamiento digital
Frecuencia de uso de app y canales
Historial interno
Pagos, retrasos, productos contratados
Datos externos
Información macro o buró
Interacciones
Reclamos, llamadas y solicitudes previas
There are no rows in this table
El objetivo no es sustituir el criterio financiero, sino enriquecerlo. Un buen modelo de scoring debe mejorar la capacidad predictiva sin introducir sesgos injustificados, sin violar privacidad y sin volverse incomprensible para auditoría o regulación.
6. Riesgos analíticos: sesgos, overfitting y costo computacional
La analítica avanzada en finanzas tiene límites importantes. Un modelo puede ser técnicamente sofisticado y, aun así, ser inadecuado para una institución financiera.
6.1 Sesgos
Los modelos aprenden de datos históricos. Si los datos históricos reflejan decisiones sesgadas, el modelo puede reproducir o amplificar esos sesgos.
Ejemplo
Si en el pasado ciertos segmentos recibieron menos crédito por razones no relacionadas con su capacidad real de pago, el modelo puede aprender que pertenecer a esos segmentos implica mayor riesgo, aunque la relación sea espuria.
Mitigación
La institución debe revisar variables sensibles, proxies indirectos, estabilidad por segmento, explicabilidad y criterios regulatorios. La pregunta no es sólo si el modelo predice bien, sino si predice de manera defendible.
6.2 Overfitting
El overfitting ocurre cuando un modelo aprende demasiado bien los datos históricos, incluyendo ruido, coincidencias y patrones irrelevantes.
En finanzas esto es especialmente peligroso porque las condiciones cambian: tasas, inflación, empleo, comportamiento del consumidor, regulación, competencia y tecnología.
Señales de alerta
Señal
Interpretación
Alto desempeño en entrenamiento
Puede estar memorizando
Bajo desempeño en datos nuevos
No generaliza
Muchas variables sin justificación
Riesgo de ruido
Backtesting perfecto
Sospecha de sobreajuste
Inestabilidad mensual
El patrón no es robusto
There are no rows in this table
6.3 Costo computacional
No todo problema requiere una arquitectura masiva. Una decisión importante en Big Data es saber cuándo no usar Big Data.
Un modelo distribuido puede generar costos innecesarios si el problema puede resolverse con SQL, Python o herramientas tradicionales.
Criterio práctico
Big Data se justifica cuando hay una combinación relevante de volumen, velocidad, variedad, complejidad o necesidad de escalabilidad. Si el problema tiene pocos datos, baja frecuencia y baja complejidad, una solución tradicional puede ser suficiente.
Libro recomendado
, de Gregory Zuckerman. Es muy recomendable para este curso porque conecta narrativa empresarial, finanzas cuantitativas, datos, modelación y ventaja competitiva.
La lectura es valiosa por cinco razones:
En síntesis, es una lectura indispensable porque convierte los conceptos del curso en una historia concreta: cómo una institución puede transformar datos masivos, infraestructura computacional, modelos estadísticos y cultura científica en una ventaja económica sostenida. No debe leerse como una receta para “ganarle al mercado”, sino como un caso de estudio sobre cómo Big Data y analítica avanzada cambian la función de producción de decisiones en finanzas.
7. Segundo bloque: Taller práctico
Taller: Diseño de arquitectura Big Data para detección de fraude en pagos móviles
El taller final busca que los participantes apliquen lo aprendido durante las cuatro clases. El objetivo es diseñar una arquitectura conceptual para detectar fraude en pagos móviles.
No se espera una arquitectura técnica exhaustiva, sino una propuesta clara que conecte problema de negocio, fuentes de datos, tecnologías, procesamiento, modelos y outputs.
7.1. Caso del taller
Una fintech procesa pagos móviles para comercios y usuarios finales. En los últimos meses ha observado un aumento en transacciones sospechosas. El equipo de fraude utiliza reglas manuales, pero éstas generan muchos falsos positivos y no se actualizan con suficiente rapidez.
La dirección quiere una solución Big Data que permita detectar fraude en tiempo casi real, aprender de eventos históricos y reducir el impacto en clientes legítimos.
Situación actual
Dimensión
Estado actual
Transacciones
Millones de pagos móviles al mes
Detección
Reglas manuales y reportes posteriores
Problema
Fraude creciente y falsos positivos
Latencia
La reacción ocurre tarde
Datos
Dispersos entre sistemas transaccionales, app, comercio y soporte
Objetivo
Detectar riesgo antes o durante la autorización
There are no rows in this table
7.2. Instrucciones del taller
Los participantes deberán diseñar una arquitectura Big Data que responda a seis preguntas.
7.2.1 Preguntas guía
Pregunta
Lo que debe definirse
¿Qué fuentes de datos se necesitan?
Transacciones, dispositivos, clientes, comercios, geolocalización, historial
¿Qué datos se procesan en streaming?
Eventos que requieren decisión inmediata
¿Qué datos se procesan en batch?
Históricos para entrenamiento y análisis
¿Dónde se almacenan los datos?
Data lake, zona curada, warehouse, feature store
¿Qué modelos o reglas se aplican?
Reglas, anomalías, clasificación, redes
¿Qué outputs recibe el negocio?
Alertas, score, bloqueo, dashboard, casos de investigación
There are no rows in this table
7.3. Arquitectura de referencia para el taller
7.3.1. Fuentes de datos
Fuente
Ejemplos de variables
Transacción
Monto, comercio, hora, canal, tipo de pago
Cliente
Historial, frecuencia, saldo, comportamiento previo
Dispositivo
ID, sistema operativo, IP, cambios recientes
Comercio
Categoría, ubicación, historial de contracargos
Geolocalización
Distancia contra patrones habituales
Soporte
Reclamos, reportes, disputas
Listas externas
Comercios, cuentas o dispositivos de riesgo
There are no rows in this table
7.3.2. Procesamiento batch y streaming
Tipo de procesamiento
Uso en la solución
Streaming
Evaluar transacciones en tiempo casi real
Batch
Entrenar modelos con históricos
Micro-batch
Actualizar variables frecuentes por ventanas de tiempo
Feature computation
Calcular variables reutilizables de riesgo
Model scoring
Asignar probabilidad de fraude
Monitoreo
Detectar drift, falsos positivos y cambios de patrón
There are no rows in this table
7.3.3 Componentes de la arquitectura
Componente
Función
Capa de ingesta
Recibe eventos transaccionales y datos históricos
Data lake
Guarda datos crudos y semiestructurados
Zona curada
Limpia, deduplica y homologa entidades
Feature store
Administra variables reutilizables para modelos
Motor de streaming
Evalúa eventos en tiempo casi real
Motor ML
Entrena y despliega modelos
Capa de consumo
Dashboards, alertas, APIs y reportes
There are no rows in this table
7.4. Outputs esperados
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.