Gobierno del dato en servicios financieros

¿Por qué los servicios financieros tienen requisitos de datos más exigentes?

La crisis financiera de 2008 puso de manifiesto que muchas entidades bancarias no tenían capacidad para agregar datos de riesgo de forma precisa y rápida cuando los reguladores lo exigieron. La respuesta regulatoria fue BCBS 239 y una sucesión de marcos normativos que hacen del sector financiero el entorno con mayores exigencias de gobierno del dato.

¿Qué marcos regulatorios afectan a los datos en finanzas?

BCBS 239: datos de riesgo

Los 14 principios de BCBS 239 cubren gobernanza, arquitectura de datos, exactitud e integridad, completitud, puntualidad, adaptabilidad y distribución de informes. Concretamente, exigen que los bancos puedan generar informes de riesgo agregados con alta frecuencia y en escenarios de estrés, lo que requiere datos de riesgo unificados, trazables y de calidad contrastada.

DORA: resiliencia digital y datos de TI

El Reglamento de Resiliencia Operacional Digital (DORA), aplicable desde enero de 2025, exige a entidades financieras de la UE gestionar el riesgo TIC con rigor: inventario de activos de datos, gestión de incidentes relacionados con datos, reporting de incidentes a reguladores y pruebas de resiliencia. Implica tener trazabilidad completa de dónde viven los datos críticos.

PSD2 y Open Banking: interoperabilidad y calidad de datos de pago

PSD2 exige que los bancos expongan datos de cuentas y pagos a terceros (TPPs) via APIs. Esto requiere datos de alta calidad, actualizados en tiempo real y con esquemas estandarizados. Los errores en datos de pago no son solo un problema de calidad: pueden ser incumplimientos regulatorios.

RGPD: protección de datos personales

Las entidades financieras manejan datos personales muy sensibles. El RGPD exige no solo protegerlos, sino conocer exactamente dónde están, durante cuánto tiempo se retienen y qué datos se comparten con terceros. El gobierno del dato es un prerrequisito técnico del cumplimiento del RGPD.

¿Qué retos tiene el gobierno del dato en entidades financieras?

¿Cómo estructurar un programa de gobierno del dato en finanzas?

1. Establecer una Data Office o función de gobierno

Sin una función organizativa dedicada al gobierno del dato, el programa no avanza. No necesita ser un equipo grande: un Chief Data Officer o Data Governance Lead con autoridad para definir políticas, resolver conflictos de definición y coordinar con reguladores es suficiente para empezar.

2. Construir el catálogo de datos y glosario de negocio

El primer entregable tangible es un catálogo de datos que incluya qué datos existen, dónde están, quién es el responsable (data owner) y cómo se definen los términos de negocio críticos. Herramientas como Collibra, Atlan o Alation soportan este proceso en entornos financieros complejos.

3. Implementar linaje de datos extremo a extremo

textlinktext

4. Definir y monitorizar métricas de calidad del dato

textlinktext

Herramientas más usadas en el sector financiero

• Collibra: catálogo de datos y gobierno de datos empresarial, ampliamente adoptado en banca
• Informatica Axon: gestión de metadatos y linaje para entornos complejos
• IBM OpenPages: gestión de riesgo y compliance con integración de datos
• Monte Carlo o Bigeye: observabilidad de datos en tiempo real
• dbt: linaje de transformaciones en el data warehouse

¿Qué papel juega el CDO en servicios financieros?

El Chief Data Officer (CDO) en una entidad financiera no es un rol tecnológico. Su función es garantizar que los datos sean un activo gestionado con la misma rigurosidad que el capital o el riesgo. En banca y aseguradoras, el CDO responde ante el Consejo o la Dirección General, no ante el CTO, precisamente porque su autoridad tiene que ser transversal a todos los departamentos que producen o consumen datos.

En la práctica, el CDO arbitra conflictos de definición (¿quién tiene la versión correcta del saldo de cliente: contabilidad o riesgo?), representa los datos ante el regulador (EBA, BdE, CNMV) y decide qué inversiones en plataforma de datos se financian. Sin esa autoridad formal, el programa de gobierno del dato se convierte en un proyecto de catalogación sin impacto real.

Subequipos habituales bajo la función de datos

Una aseguradora mediana (500-2.000 empleados) puede operar con un equipo de 8-12 personas bajo el CDO sin necesitar una Data Office masiva. La clave es que los data stewards no sean externos al negocio: tienen que ser personas del área que conocen los datos de riesgo, siniestros o primas desde dentro. El CDO les da el marco y la autoridad; ellos aportan el conocimiento de dominio.

La diferencia entre data owner y data steward

Confundir estos dos roles genera problemas organizativos. El data owner es el directivo (típicamente director de área) que tiene responsabilidad última sobre los datos de su dominio y toma decisiones estratégicas sobre ellos. El data steward es quien gestiona operativamente esa responsabilidad: valida definiciones, revisa incidencias de calidad y mantiene el catálogo actualizado. En banca, el director de Riesgo es el data owner del dominio de riesgo; el data steward de riesgo es quien trabaja diariamente con esos datos.

¿Qué métricas miden el progreso del programa?

Un programa de gobierno del dato sin métricas es un programa que nadie sabe si funciona. En servicios financieros, donde el regulador puede pedir evidencia del progreso, tener un cuadro de mando de gobierno del dato no es una opción. Estas seis métricas cubren las dimensiones principales de cualquier programa maduro.

Estas métricas se reportan mensualmente al CDO y trimestralmente al Comité de Dirección o al Consejo. En entidades supervisadas directamente por el BCE, el equipo supervisor puede solicitar el detalle de algunas de ellas, especialmente la cobertura de linaje y el score de completitud en datos de riesgo.