Skip to content
¿Requiere Big Data o SQL convencional es suficiente?¿Cuál de las 5 Vs es el driver principal del problema?¿Cuál sería la primera pregunta qué harías antes de diseñar la solución?
El proceso: qué decisión se toma, con qué frecuencia, quién la tomaEl problema de datos: qué V de las 5 es el cuello de botella principalEl costo del status quo: cuánto vale —en pesos, margen, riesgo o eficiencia— mejorar esa decisiónLa hipótesis de solución: qué tipo de dato adicional o qué velocidad de procesamiento cambiaría la calidad de la decisión
Davenport, T. & Patil, D. (2012). . Harvard Business Review. — Contexto histórico del surgimiento del rol analítico en organizaciones.McAfee, A. & Brynjolfsson, E. (2012). . Harvard Business Review. — Argumento de negocio para inversión en capacidades analíticas.BIS (Bank for International Settlements). Big data and machine learning in central banks. — Perspectiva regulatoria y casos de uso en banca central. Disponible en .CNBV. Disposiciones de carácter general aplicables a las instituciones de crédito (Circular Única de Bancos). — Marco regulatorio mexicano relevante para gobierno de datos.
Clase 1 — Introducción al Big Data Financiero
Big Data Business Solutions in Finance
Data Scientist: The Sexiest Job of the 21st Century
Big Data: The Management Revolution
Volumen — cuántos datos se generan
Velocidad — con qué rapidez llegan y deben procesarse
Variedad — qué tipos de datos existen
Veracidad — qué tan confiables son los datos
Valor — del potencial informacional a la creación de valor en servicios financieros
Fuentes de datos masivos en finanzas
Duración: 2 horas · Fecha: 30 de abril, 2026 · Horario: 6:00–8:00 pm CDMX
Objetivo de la sesión
Establecer por qué el volumen, variedad y velocidad de datos en finanzas rompe los paradigmas de procesamiento tradicional. Al terminar esta clase el participante podrá diagnosticar si un problema financiero específico requiere Big Data o si SQL convencional es suficiente — y articular el argumento de negocio para justificar la inversión.
Agenda
Bloque
Encuadre: el problema que Big Data resuelve en finanzas
Las 5 Vs — traducción a impacto financiero
Fuentes de datos masivos en finanzas
Por qué falla el procesamiento tradicional
Ejercicio de diagnóstico + cierre
There are no rows in this table
1. El problema que Big Data resuelve en finanzas
Las instituciones financieras no tienen un problema de falta de datos. Tienen un problema de incapacidad para procesar los datos que ya generan a la velocidad y escala que el negocio requiere. Big Data no es una tecnología — es una respuesta arquitectónica a ese problema.
El quiebre entre datos disponibles y capacidad de procesamiento
Durante décadas, el volumen de datos financieros creció de forma manejable: registros contables, transacciones en ventanilla, estados de cuenta mensuales. Los sistemas relacionales (Oracle, SQL Server, DB2) fueron diseñados para ese mundo y lo resolvieron bien.
La consecuencia de no resolverlo
Una institución que no procesa sus datos a escala toma decisiones con información incompleta, tarde, o ambas cosas.
En detección de fraude, eso significa pérdida directa y fricción de cliente. En riesgo, significa exposición no visibilizada. En comercial, significa ofertas genéricas con conversión baja. En cumplimiento, significa reportes que llegan tarde al regulador.
El costo de no actuar es medible. El ROI de Big Data se calcula contra ese costo.
2. Las 5 Vs — en el negocio financiero
Las 5 Vs son el marco conceptual estándar para caracterizar el problema de Big Data. Lo relevante no es memorizarlas — es entender qué decisión de negocio implica cada una.
Las Vs fácticas
Las Vs fácticas del Big Data financiero —Volumen, Variedad y Velocidad— describen condiciones objetivas del entorno de datos en el que operan bancos, aseguradoras, fintechs, casas de bolsa e instituciones financieras.
No son atributos deseables ni metas de gestión:
son hechos derivados de la operación digital del sector. Las transacciones electrónicas, las cotizaciones de alta frecuencia, los datos de clientes, las redes sociales y los sensores IoT/insuretech generan datos masivos, diversos y dinámicos que rebasan las capacidades del procesamiento tradicional. Por eso, estas tres Vs explican por qué surge el problema Big Data: hay demasiados datos, de demasiados tipos y con demasiada rapidez como para tratarlos con arquitecturas convencionales.
Las Vs deseables
Las Vs deseables del Big Data financiero —Veracidad y Valor— no describen simplemente la realidad de los datos, sino la calidad institucional con la que esos datos se convierten en mejores decisiones. A diferencia del volumen, la variedad y la velocidad, la veracidad y el valor
no aparecen automáticamente por operar en un entorno digital: deben construirse mediante gobierno de datos, controles de calidad, trazabilidad, seguridad, criterio analítico y claridad estratégica.
En finanzas, donde una mala decisión puede traducirse en pérdida crediticia, fraude, sanción regulatoria o deterioro reputacional, no basta con tener muchos datos, de muchos tipos y en tiempo real. Los datos deben ser confiables y deben justificar una acción, una predicción, una automatización o una ventaja económica concreta.
3.
Mapa de fuentes por dimensión
Las fuentes de datos financieros se caracterizan en dos dimensiones que determinan su arquitectura de procesamiento: latencia (qué tan rápido llegan y deben procesarse) y valor incremental (cuánto agregan sobre las fuentes convencionales ya disponibles).
4. Por qué falla el procesamiento tradicional
El RDBMS y sus límites estructurales
Los sistemas de gestión de bases de datos relacionales (Oracle, SQL Server, MySQL, PostgreSQL) fueron diseñados en los años 70–80 para un mundo donde el dato era escaso, estructurado y transaccional. Siguen siendo la herramienta correcta para muchos casos. El problema ocurre cuando se les pide resolver problemas para los que no fueron diseñados.
Límite 1 — Escala vertical
El RDBMS convencional escala verticalmente: para más capacidad, se necesita un servidor más grande (más CPU, más RAM, más almacenamiento). Esto funciona hasta cierto punto, pero el costo crece exponencialmente y existe un techo físico. Un servidor de $500,000 USD procesa más que uno de $50,000 USD, pero no 10 veces más.
Big Data resuelve esto con escala horizontal: en lugar de un servidor más grande, se agregan más servidores del mismo tipo. El costo crece linealmente con la capacidad. Un cluster de 100 nodos de commodity hardware supera en capacidad a cualquier servidor monolítico.
Límite 2 — Procesamiento secuencial
El RDBMS procesa una consulta usando los recursos de un único servidor. Un JOIN entre dos tablas de 500 millones de registros puede tomar horas. Spark distribuye esa operación entre 100 nodos y la completa en minutos — cada nodo procesa una partición del dataset en paralelo.
Límite 3 — Schema-on-write
En SQL, el esquema de la tabla debe definirse antes de insertar datos. Si llega un nuevo tipo de dato, hay que alterar la tabla — operación costosa y a veces bloqueante en sistemas en producción. Big Data usa schema-on-read: los datos se almacenan en formato nativo y el esquema se aplica al momento de la consulta. Esto permite incorporar nuevas fuentes sin rediseñar la arquitectura.
Límite 4 — Datos no estructurados
Un RDBMS no sabe cómo almacenar un tweet, una transcripción de llamada o una imagen de un cheque. Se puede forzar almacenándolos como texto en un campo CLOB, pero esto destruye la capacidad de buscar, indexar y analizar esos datos eficientemente.
Límite 5 — Costo a escala
Las licencias de Oracle o SQL Server Enterprise para volúmenes de petabytes son prohibitivas. El stack Big Data (Hadoop, Spark, herramientas del ecosistema Apache) es open source. El costo se traslada de licencias a infraestructura y talento, con una curva de costo mucho más favorable a escala.
Cuándo Big Data no es la respuesta
Big Data tiene costos — de infraestructura, de talento especializado, de complejidad operativa. No es la solución correcta para todos los problemas.
Situación
Solución correcta
Menos de 10 M registros, consultas analíticas
SQL moderno (BigQuery, Redshift, DuckDB)
Datos estructurados, latencia de horas aceptable
DWH convencional bien optimizado
Prototipo o prueba de concepto
Pandas, SQL, muestra representativa
Equipo sin experiencia en Spark/Flink
Managed services cloud antes que stack propio
ROI no cuantificado
No construir nada hasta cuantificarlo
There are no rows in this table
Si la consulta más pesada tarda menos de 30 segundos en SQL bien indexado, no se necesita Big Data. El umbral real no es técnico — es económico: el costo de construir y operar el stack Big Data debe ser menor que el valor que genera.
Comparativo de decisión
Criterio
RDBMS convencional
Big Data
Volumen máximo práctico
~10 TB con rendimiento aceptable
Petabytes
Escalabilidad
Vertical (cara, tiene techo)
Horizontal (lineal, sin techo práctico)
Tipos de datos
Estructurados únicamente
Estructurados, semiestructurados, no estructurados
Latencia mínima
Segundos a minutos en consultas pesadas
Milisegundos en streaming
Costo a escala
Alto (licencias + hardware especializado)
Moderado (open source + commodity hardware)
Complejidad operativa
Baja
Alta
Talento requerido
DBA, desarrolladores SQL
Data engineers, architects, DevOps
Time-to-value
Rápido
Lento (meses para arquitectura inicial)
There are no rows in this table
5. Ejercicio de diagnóstico
Instrucciones
Para cada uno de los siguientes escenarios, determinar:
Registrar las respuestas en la tabla al final de esta sección. Se discutirán en los últimos 20 minutos de la sesión.
Escenario A — Banco minorista
Un banco con 3 millones de clientes quiere predecir cuáles cancelarán su cuenta en los próximos 90 días. Tiene historial de transacciones de los últimos 5 años, datos de uso de app, y registros de llamadas al call center (texto transcrito). El modelo actual es una regresión logística entrenada con variables demográficas y saldo promedio mensual, con un AUC de 0.62.
Escenario B — Mesa de dinero
Una casa de bolsa quiere analizar si existe correlación entre el sentiment en Twitter/X sobre empresas del IPC y el movimiento de precio de esas acciones en la siguiente hora de operación. Quiere actualizar el análisis cada 15 minutos durante el horario de mercado.
Escenario C — Aseguradora
Una aseguradora de autos tiene 180,000 pólizas activas. Quiere calcular la probabilidad de siniestro de cada póliza en el siguiente mes, usando historial de siniestros, datos de la unidad (modelo, año, zona geográfica) y score crediticio del asegurado. La frecuencia de actualización del modelo es mensual.
Escenario D — Fintech de crédito
Una fintech de crédito al consumo procesa 50,000 solicitudes de crédito al día a través de su app. Cada solicitud debe recibir una decisión en menos de 3 segundos. Quieren incorporar al modelo variables de comportamiento en la app (tiempo de sesión, pantallas visitadas antes de solicitar, número de intentos previos rechazados).
Escenario E — Banco de desarrollo
Un banco de desarrollo necesita generar el reporte mensual de exposición crediticia por sector económico, requerido por la CNBV. El reporte consolida datos de 12 sistemas internos distintos, cada uno con su propia estructura de datos. Actualmente toma 3 días generarlo manualmente.
Ejercicio para entregar antes de la Clase 2
Instrucciones
Seleccionar un proceso o decisión en tu organización (o en una institución financiera de referencia) que actualmente se realice con datos limitados o con latencia alta. Describir:
Extensión máxima: media página. Se usará como caso base para el taller de la Clase 4.
Registrar la respuesta en la página de ejercicios de este Coda antes del inicio de la Clase 2.
Lecturas de referencia
Clase 1 de 4 · Big Data Business Solutions in Finance · RiskMathics Financial Institute · 2026
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.