Skip to content
Distinguir entre data lake, data warehouse y arquitecturas híbridas.Explicar cómo se integran datos de mercados, riesgos, clientes, operaciones y cumplimiento.Diseñar una arquitectura conceptual de datos para una institución financiera.Identificar los principales riesgos de calidad, seguridad, privacidad y cumplimiento.Traducir requerimientos regulatorios en controles de arquitectura y gobierno.Diferenciar decisiones de arquitectura para casos batch, near real time y streaming.Proponer un bosquejo de arquitectura objetivo con fuentes, capas, controles y salidas.
Detección de fraude en pagos digitales.Scoring crediticio con datos tradicionales y alternativos.Monitoreo de liquidez intradía.Visión 360 del cliente.Alertas de cumplimiento AML.Análisis de sentimiento para inversiones.Prevención de churn en banca minorista.
Clase 3 — Arquitectura de datos y gobierno en instituciones financieras
Big Data Business Solutions in Finance
Esta clase funciona como el puente entre la tecnología vista en la clase 2 y los casos analíticos de la clase 4. El objetivo es que el participante deje de pensar en herramientas aisladas —Hadoop, Spark, NoSQL, nube— y empiece a pensar en una arquitectura institucional de datos: cómo entran los datos, dónde viven, cómo se gobiernan, quién puede usarlos, bajo qué controles y para qué decisiones financieras.
1. Objetivo de aprendizaje de la clase
Al finalizar la sesión, el participante será capaz de:
En servicios financieros, una arquitectura Big Data no es solamente una plataforma tecnológica. Es un sistema institucional para convertir datos dispersos, sensibles y regulados en decisiones trazables, seguras y económicamente valiosas.
Esta idea es importante porque muchas instituciones financieras ya tienen enormes volúmenes de datos, pero no necesariamente tienen una arquitectura que permita usarlos bien. Los datos suelen estar fragmentados por área: riesgos, crédito, canales digitales, sucursales, core bancario, tesorería, mercados, cumplimiento, cobranza, CRM y call center. La arquitectura busca resolver esa fragmentación sin perder control, seguridad ni trazabilidad.
Estructura de la clase
Duración total: 2 horas
Tiempo
Bloque
Contenido
0–10 min
Apertura
Recapitulación de tecnologías de clase 2 y pregunta guía
10–30 min
Arquitectura base
Data lake, data warehouse, lakehouse y capas
30–50 min
Integración financiera
Mercados, riesgos, clientes, operaciones y cumplimiento
50–60 min
Receso
10 minutos
60–80 min
Gobierno de datos
Calidad, consistencia, seguridad, linaje y acceso
80–100 min
Regulación y privacidad
GDPR, secreto bancario, CNBV, auditoría y monitoreo
100–120 min
Ejercicio aplicado
Bosquejo de arquitectura objetivo
There are no rows in this table
2. Apertura
Si un banco tiene todos sus datos, pero cada área los define, guarda y procesa de manera distinta, ¿realmente tiene una ventaja de Big Data?
La respuesta esperada es: no necesariamente. Tener datos no equivale a tener capacidad analítica. Para que los datos generen valor deben estar integrados, documentados, gobernados y disponibles para los casos de uso correctos.
Conexión con clases anteriores
En la clase 1 se discutió por qué los datos financieros tienen volumen, variedad, velocidad, veracidad y valor. En la clase 2 se revisaron tecnologías como Hadoop, NoSQL, Spark, Flink y nube. La clase 3 responde la pregunta arquitectónica:
¿Cómo se organizan esas tecnologías en una institución financiera real?
3.
4.
5.
6.
El punto central: una arquitectura Big Data no solo analiza clientes o mercados; también puede analizar a la propia institución.
7. Caso de clase: arquitectura para visión 360 de cliente y riesgo
Planteamiento
Arquitectura sugerida
8. Ejercicio aplicado de la clase
Producto final
Bosquejo de arquitectura objetivo para una institución financiera, tal como lo plantea el programa oficial.
Instrucciones para participantes
Dividir al grupo en equipos. Cada equipo debe diseñar una arquitectura conceptual para uno de estos casos:
Plantilla de trabajo
Elemento
Pregunta guía
Caso de uso
¿Qué decisión o proceso se quiere mejorar?
Fuentes
¿Qué datos se necesitan?
Ingesta
¿Batch, streaming, API o combinación?
Almacenamiento
¿Lake, warehouse, lakehouse o NoSQL?
Procesamiento
¿Qué transformaciones son necesarias?
Gobierno
¿Qué controles de calidad, acceso y linaje aplican?
Salidas
¿Dashboard, alerta, modelo, reporte o API?
There are no rows in this table
Criterios de evaluación del ejercicio
El bosquejo debe evaluarse con una rúbrica sencilla:
Criterio
Qué se evalúa
Alineación al negocio
El caso resuelve una decisión financiera relevante
Integración de datos
Las fuentes están bien identificadas
Diseño arquitectónico
Las capas son lógicas y completas
Gobierno
Incluye calidad, seguridad, linaje y privacidad
Cumplimiento
Considera regulación y auditoría
Escalabilidad
Puede crecer en volumen, velocidad y variedad
Claridad
Se entiende como arquitectura objetivo
There are no rows in this table
Cierre de la clase
Primero, la arquitectura precede a la analítica. Sin arquitectura, los modelos quedan aislados, los tableros se contradicen y los proyectos de IA no escalan.
Segundo, el gobierno no es burocracia. En servicios financieros, el gobierno permite que los datos se usen con confianza, seguridad y trazabilidad.
Tercero, el valor aparece en la conexión entre datos, controles y decisiones. Una arquitectura bien diseñada no solo almacena información: reduce incertidumbre, acelera decisiones y mejora resultados de negocio.
En finanzas, el dato que no está gobernado no puede convertirse plenamente en confianza; y el dato que no genera decisiones no puede convertirse plenamente en valor.
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.