Una solicitud de estrés del regulador llega antes del almuerzo. A media tarde, el director de riesgos todavía no tiene una visión fiable de la exposición por entidades jurídicas, regiones, productos y clases de activos. Un equipo está conciliando hojas de cálculo, otro espera un fichero de origen que llega tarde y el panel en el que todos confían se basa en los datos de ayer.

Esta situación no es habitual porque a las entidades financieras les falten datos. El problema es que los datos no pueden circular por la organización con suficiente control, contexto y velocidad. La disciplina práctica de la gestión de datos en servicios financieros existe para resolver precisamente eso, desde el origen en los sistemas core hasta la agregación, la validación, el reporting, el uso en modelos y las evidencias de auditoría.

Índice de contenidos

• Cuando los datos de riesgo no circulaban lo bastante rápido

• Qué abarca realmente la gestión de datos financieros

  • Cuatro pilares del modelo operativo

• Convertir BCBS 239 en controles de ingeniería

  • Del principio al pipeline

• Las seis dimensiones de calidad de datos que ningún banco puede omitir

  • Las dimensiones en términos operativos

  • Controles deterministas y detección adaptativa

• Linaje, seguimiento de esquemas y puntualidad como un único sistema

  • Qué debe registrar el plano de control

• Modernizar sin centralizarlo todo

  • Utilizar un plano de control, no solo una plataforma de destino

• La calidad de datos como control en tiempo de ejecución para IA y modelos

• Un modelo operativo de 90 días para la gestión de datos financieros

Cuando los datos de riesgo no circulaban lo bastante rápido

El patrón se volvió imposible de ignorar durante la crisis financiera global de 2007-2009. Los supervisores comprobaron que muchos grandes bancos no podían agregar con rapidez las exposiciones por líneas de negocio, entidades jurídicas, regiones y productos, sobre todo en situaciones de estrés. Un banco podía disponer de los registros pertinentes, pero sus sistemas no eran capaces de ofrecer una visión fiable a nivel de grupo cuando los responsables de decisiones la necesitaban.

Una solicitud de estrés pone de manifiesto la debilidad muy rápido. El equipo de riesgos pide la exposición por contraparte en todas las filiales. La primera extracción llega sin identificadores de entidad. Una segunda fuente utiliza otra taxonomía de productos. Tesorería tiene un saldo más actual, pero finanzas dispone de la cifra de reporting aprobada. Operaciones sabe que un feed llegó tarde, y aun así el panel presenta el resultado como completo.

Regla práctica: si un informe de riesgos depende de conciliaciones manuales durante una crisis, la entidad no tiene un proceso de reporting. Tiene una dependencia operativa sin gestionar.

El Comité de Basilea respondió publicando en enero de 2013 los “Principios para una eficaz agregación de datos de riesgo y presentación de informes de riesgo”. El marco contiene 14 principios, de los cuales 11 se aplican directamente a los bancos y tres se refieren a la revisión supervisora, las herramientas y la cooperación. Sus expectativas van más allá de la tecnología de reporting. Los bancos necesitan gobierno, una arquitectura adecuada, datos fiables y completos, agregación puntual, capacidad de adaptación ante solicitudes ad hoc y un reporting claro. La capacidad debe funcionar tanto en condiciones normales como durante una crisis, con una agregación realizada en gran medida mediante procesos automatizados para reducir errores. El marco de Basilea sigue siendo una referencia fundamental para la gestión de datos y riesgos en banca.

La lección es operativa. La calidad de datos, el linaje, la conciliación, la puntualidad y la consistencia estructural no son mejoras independientes que puedan esperar a una futura migración de plataforma. Determinan si la alta dirección puede identificar concentraciones, explicar variaciones, responder a los supervisores y actuar antes de que un riesgo se convierta en una pérdida. Los equipos que quieran una visión práctica de las consecuencias pueden consultar también cómo la mala calidad de datos genera costes a las entidades financieras.

El resto de la disciplina se deriva de este punto. El gobierno define la responsabilidad, la arquitectura mueve los datos y preserva su contexto, la calidad comprueba su idoneidad para el uso y el reporting demuestra que el resultado es fiable.

Qué abarca realmente la gestión de datos financieros

La gestión de datos en servicios financieros es la disciplina integral de gobernar, mover, validar, almacenar, dar acceso y reportar datos en toda una entidad. Comienza cuando un evento de cliente, pago, operación, préstamo o mercado entra en un sistema de origen. Continúa a través de data warehouses, data lakes, motores regulatorios, cálculos de riesgo, informes de gestión, modelos y evidencias conservadas.

Una analogía útil es la instrumentación. Los productos y procesos del banco son el motor, mientras que la gestión de datos aporta los indicadores, sensores, alertas y registros de mantenimiento. La instrumentación no genera la actividad de negocio, pero sin ella el conductor no puede saber si el motor funciona con normalidad o se acerca a una avería.

Cuatro pilares del modelo operativo

• Gobierno: asigna a los datos críticos propietarios responsables, stewards, definiciones, umbrales, vías de escalado y usos permitidos.

• Arquitectura: conecta core bancario, pagos, trading, finanzas, riesgos, data warehouses, data lakes y servicios de reporting sin perder significado ni control.

• Calidad de datos: comprueba si los registros son completos, exactos, puntuales, válidos, únicos y consistentes para un caso de uso definido.

• Reporting: proporciona información clara, exhaustiva y conciliada con la frecuencia que requieren el consejo, la dirección, los reguladores y los equipos operativos.

Estos pilares dependen unos de otros. Una regla de calidad sin propietario no tiene una vía de respuesta duradera. Un informe sin linaje no puede explicar de dónde procede una cifra. Un repositorio centralizado sin validación solo concentra registros poco fiables. Una política de gobierno sin controles legibles por máquina sigue siendo difícil de comprobar y fácil de interpretar de forma distinta en cada departamento.

Empiece por el caso de uso, no por el repositorio. Un informe de liquidez, un cálculo de exposición crediticia, una decisión de riesgo de cliente y una comunicación regulatoria pueden utilizar datos solapados, pero cada uno tiene requisitos distintos de actualidad, completitud y conciliación. La arquitectura debe preservar esas diferencias y, al mismo tiempo, ofrecer a los equipos definiciones compartidas y evidencias de control visibles.

Convertir BCBS 239 en controles de ingeniería

BCBS 239 se cita a menudo en los comités de dirección como un requisito de gobierno y luego se implementa como un proyecto de reporting más. Ese enfoque pierde de vista su intención operativa. Los principios dirigidos a los bancos establecen expectativas sobre cómo una entidad identifica los datos materiales, los agrega a nivel de grupo, valida el resultado y entrega información que siga siendo útil tanto en condiciones normales como de estrés.

El Comité de Basilea organizó los 11 principios dirigidos a los bancos en tres áreas operativas: gobierno e infraestructura generales, capacidades de agregación de datos de riesgo y prácticas de presentación de informes de riesgo. Los equipos de ingeniería pueden traducir esas áreas en controles que generen evidencias en lugar de declaraciones de política. La publicación original de BCBS 239 es la referencia que rige el marco.

Del principio al pipeline

El gobierno se convierte en metadatos que los sistemas pueden hacer cumplir. Para cada conjunto de datos crítico, registre quién es responsable del significado de negocio, quién opera el control, qué constituye un fallo y quién debe actuar. La propiedad debe acompañar a los datos a través de las capas de origen, transformación, agregación e informe, y no detenerse en los límites de la aplicación.

La capacidad de agregación requiere algo más que un job ejecutado con éxito. Compare los totales de origen y destino, concilie los saldos entre sistemas, verifique las dimensiones obligatorias como la entidad jurídica y la línea de negocio, y conserve el resultado de cada ciclo de reporting. Un pipeline que termina sin errores puede, aun así, omitir una partición, duplicar registros o aplicar un mapeo de datos de referencia incorrecto.

Los controles de reporting deben evaluar el resultado como un producto para la toma de decisiones. ¿Puede un alto directivo entender la exposición? ¿Puede un analista profundizar hasta la entidad o el tipo de activo que la origina? ¿Puede el banco dar una respuesta útil a una solicitud ad hoc sin reconstruir el informe manualmente?

El alineamiento con BCBS 239 sigue siendo un reto técnico considerable. La evaluación de 2023 del Comité de Basilea abarcó 31 G-SIB y constató que los bancos seguían en distintas fases de alineamiento casi una década después de la publicación de los principios y siete años después de la fecha prevista de cumplimiento. La implicación práctica es directa: una plataforma de riesgos debe ser un pipeline controlado y repetible de agregación, conciliación, linaje y entrega, no un repositorio pasivo de informes. La evaluación de Basilea ofrece el contexto supervisor. Los equipos que evalúan opciones de implementación también pueden analizar un enfoque basado en IA para cumplir los principios de BCBS 239.

Las seis dimensiones de calidad de datos que ningún banco puede omitir

Un conjunto de datos no es de “alta calidad” en abstracto. Es apto, o no apto, para una decisión, informe, modelo o control concretos. Una cartera de préstamos puede estar completa pero desactualizada. Un feed de clientes puede estar al día pero ser inexacto. Una extracción regulatoria puede superar los controles de formato y, sin embargo, aplicar un tratamiento de divisas incoherente entre entidades.

Las dimensiones en términos operativos

• La completitud pregunta si están presentes los registros y campos obligatorios. La falta de atributos de identificación del cliente en un feed de KYC, o la ausencia del código de entidad jurídica en una extracción de préstamos, puede inutilizar un conjunto de datos que por lo demás está poblado.

• La exactitud pregunta si el valor representa la situación real. Un saldo de préstamo que no coincide con el registro de administración de referencia debe desencadenar una investigación antes de llegar a un informe de capital o de gestión.

• La puntualidad pregunta si la información llega mientras todavía puede respaldar la decisión. Un fichero de operaciones que llega tarde puede ser técnicamente válido pero operativamente erróneo para una visión de riesgo intradía.

• La validez comprueba si los valores siguen las reglas de negocio y estructurales definidas. Fechas, identificadores de cuenta, divisas, clasificaciones y códigos de producto necesitan formatos aceptados y valores permitidos.

• La unicidad impide que el mismo cliente, contraparte, cuenta u operación aparezca más de una vez donde se espera un único registro. Las contrapartes duplicadas pueden distorsionar la agregación de exposiciones y las vistas de relación.

• La consistencia comprueba si un mismo hecho coincide entre sistemas. Un saldo, la normalización de divisas, la jerarquía de entidades o una clasificación de riesgo no deberían cambiar sin aviso entre la plataforma core y el data warehouse.

Estas dimensiones funcionan conjuntamente, pero no deben reducirse a una única puntuación. Una puntuación compuesta puede ocultar un fallo material. En su lugar, informe de la dimensión que ha fallado, el elemento de datos afectado, el impacto en el negocio, el propietario y el estado de la remediación. Un comité de riesgos necesita saber que un feed llega tarde o que una conciliación de saldos ha fallado, no simplemente que una puntuación de calidad ha bajado.

Controles deterministas y detección adaptativa

La validación determinista es más sólida donde la regla es explícita. Compruebe que cada préstamo tiene una entidad jurídica, que cada operación hace referencia a un instrumento conocido, que cada cuenta utiliza una divisa aceptada y que los totales de origen y destino concilian. Estos controles son explicables y fáciles de vincular a las evidencias de auditoría.

La detección de anomalías aporta una capacidad diferente. Puede identificar un cambio inusual de volumen, una variación de distribución o un movimiento de saldo respecto al comportamiento normal de un conjunto de datos concreto. No debe sustituir a las reglas de negocio. Debe ayudar a determinar si un movimiento es un evento real de la cartera, una carga parcial del origen o una transformación defectuosa.

Para un tratamiento práctico de las dimensiones y su aplicación, consulte las seis dimensiones de la calidad de datos. El cambio operativo importante es monitorizar la calidad de forma continua. Perfilar una tabla durante un proyecto de remediación le indica lo que ocurrió entonces. Los controles en tiempo de ejecución le indican si el conjunto de datos sigue siendo seguro para usarse hoy.

Linaje, seguimiento de esquemas y puntualidad como un único sistema

El linaje suele tratarse como un ejercicio de elaboración de diagramas. La puntualidad se delega en operaciones. El seguimiento de esquemas se añade después de que se rompa un job posterior. En servicios financieros, estos tres controles van juntos, porque un cambio estructural o un retraso en la entrega pueden alterar el significado de un informe aunque todos los jobs programados se completen con éxito.

Piense en un sistema de origen que cambia un campo numérico de exposición a texto. El proceso de ingesta acepta el nuevo tipo, una transformación convierte algunos valores y el job de reporting se completa. La exposición resultante puede contener nulos, valores truncados o joins fallidos. Sin seguimiento de esquemas, la organización descubre el defecto solo cuando alguien cuestiona la cifra.

Una partición perdida genera un problema similar. El pipeline se ejecuta, pero falta una región o una entidad jurídica. Un feed de mercado o de transacciones que llega tarde puede ser igual de perjudicial cuando un informe utiliza el último valor válido y lo presenta como actual.

Qué debe registrar el plano de control

El linaje de extremo a extremo debe identificar la tabla de origen, el campo, la transformación, los datos de referencia, el conjunto de datos de destino, el informe y el modelo que dependen de un elemento crítico. También necesita historial de versiones, propiedad, última entrega correcta y los resultados de control asociados a cada ejecución.

El seguimiento de esquemas debe detectar:

• Columnas añadidas o eliminadas: un campo nuevo puede ser inofensivo, mientras que un identificador eliminado puede romper joins o la clasificación regulatoria.

• Modificaciones de tipo de dato: un importe, una fecha o una clave con un tipo distinto pueden alterar los cálculos sin detener el pipeline.

• Cambios de definición: un campo puede conservar su nombre mientras cambian su significado de negocio o su lógica de población.

• Deriva estructural aguas abajo: un data warehouse o una capa de reporting pueden desviarse del contrato aprobado aunque el origen se mantenga estable.

La monitorización de la puntualidad debe aprender el comportamiento esperado de entrega en lugar de aplicar un único calendario fijo a todos los feeds. Las fuentes de mercado, transaccionales y batch funcionan de forma distinta. Un feed que normalmente llega temprano puede ser anómalo si no llega en su ventana esperada, mientras que un horario rígido puede generar ruido en una fuente con variaciones legítimas.

La evaluación de 2023 del Comité de Basilea abarcó 31 G-SIB y encontró entidades en distintas fases de alineamiento con BCBS 239, lo que refuerza la necesidad de pipelines controlados que respalden la agregación, la conciliación, el linaje y la entrega en condiciones normales y de estrés. Los detalles de la evaluación dejan clara la implicación para la ingeniería.

Conviene distinguir entre procedencia y linaje. La procedencia responde a qué le ocurrió a los datos y bajo qué proceso. El linaje describe cómo se mueve un campo a través de sistemas y dependencias. Los equipos que comparan ambos conceptos pueden utilizar esta guía sobre procedencia y linaje de datos. Ninguno de los dos es suficiente por sí solo. Un linaje sin controles estructurales y de actualidad es solo un plano de control parcial.

Modernizar sin centralizarlo todo

Un banco puede centralizar sus datos de reporting y aun así no superar una revisión de BCBS 239. La copia central puede estar incompleta, llegar tarde o estar desconectada del sistema responsable del proceso de negocio. La centralización cambia dónde residen los datos. Por sí sola, no establece propiedad, validación, puntualidad ni evidencias.

Copiar datos de producción sensibles a una nueva plataforma también genera costes. El banco debe proteger, clasificar, conciliar, gobernar y explicar otro repositorio más. Un repositorio central puede simplificar el acceso para algunos usuarios y, a la vez, aumentar la duplicación, la exposición de la privacidad, la latencia y el trabajo de integración.

La realidad operativa es distribuida. Los registros de clientes pueden permanecer en los sistemas core, las transacciones en data warehouses, los datos de mercado en plataformas especializadas y las copias específicas de cada jurisdicción bajo controles separados. La pregunta práctica es si el banco puede demostrar que los datos críticos son aptos para su uso allí donde se encuentren.

Utilizar un plano de control, no solo una plataforma de destino

Un plano de control distribuido ejecuta los controles cerca de los sistemas de origen o dentro de la base de datos del cliente, y después centraliza los metadatos y las evidencias en lugar de los registros sensibles. Sus controles operativos deberían incluir:

• Validación in situ: aplicar reglas de negocio a las tablas de origen sin crear otra copia de producción.

• Propiedad: asignar cada conjunto de datos crítico, regla, excepción y acción de remediación a un equipo responsable.

• Monitorización estructural: detectar cambios de esquema en el punto de origen e identificar a los consumidores afectados mediante el linaje.

• Controles de actualidad: comparar la entrega real con el comportamiento esperado de cada feed.

• Conservación de evidencias: preservar resultados de reglas, excepciones, aprobaciones, escalados e historial de remediación.

• Priorización basada en el riesgo: empezar por los conjuntos de datos que respaldan el reporting de capital, liquidez, crédito, finanzas y regulatorio.

Este diseño convierte las expectativas supervisoras de BCBS 239, las revisiones del BCE y SR 11-7 en evidencias operativas. Los equipos pueden demostrar quién es responsable de un control, qué validación se ejecutó, si un feed llegó dentro de su ventana esperada, qué esquema cambió y cómo se resolvieron las excepciones.

La contrapartida es real. Los controles in situ exigen más disciplina en metadatos, conectores y propiedad. Las plataformas centralizadas pueden simplificar el análisis, pero una copia central puede ocultar defectos del origen o convertirse en la fuente de referencia sin pruebas de que sigue sincronizada. Los bancos que deban elegir entre estos patrones pueden consultar esta comparativa entre data mesh y plataformas de datos centralizadas. La decisión debe basarse en la cobertura de controles, la sensibilidad de los datos, el rendimiento, la jurisdicción y las limitaciones heredadas, no en la preferencia por una arquitectura concreta.

La calidad de datos como control en tiempo de ejecución para IA y modelos

La preparación para la IA en servicios financieros es ante todo un problema de comportamiento de los datos, no de selección de modelos. Un modelo validado puede comportarse de forma insegura cuando su feed de entrada llega tarde, cambia de esquema, pierde una clase, desarrolla una nueva distribución o se aleja de la línea base utilizada durante la validación.

Una encuesta de IIF-EY de 2025 reveló que el 79 % de las empresas de servicios financieros en conjunto, y el 100 % de los G-SIB y de las aseguradoras de importancia sistémica mundial, señalaron la calidad de datos como uno de los principales retos para el desarrollo de IA. Entre esas empresas, el 96 % destacó los datos ruidosos, extemporáneos, inexactos o poco adaptables como el principal obstáculo en producción. La encuesta de IIF-EY aporta la evidencia que respalda esta preocupación operativa.

SR 11-7 añade una perspectiva de gobierno del riesgo de modelo. Los bancos necesitan controles documentados en el desarrollo, la implementación, la validación, la monitorización continua y el gobierno de los modelos. La carta supervisora SR 11-7 de la Reserva Federal implica que una anomalía de datos puede convertirse en un evento de riesgo de modelo cuando modifica una entrada sin una explicación aprobada.

Conserve evidencias del periodo posterior a la validación, no solo del propio paquete de validación:

• Cambio de línea base: qué se desplazó, cuándo y si el movimiento era esperado.

• Comportamiento del feed: si el conjunto de datos llegó tarde, de forma parcial o con particiones ausentes.

• Estado del esquema: qué campos, tipos o definiciones cambiaron.

• Comportamiento de la distribución: si las distribuciones de clases o valores superaron el umbral aceptado.

• Registro de decisión: quién evaluó el incidente y si la respuesta fue continuar, revertir o revalidar.

Los equipos que exploran soluciones de IA para finanzas deberían tratar este ciclo de evidencias como parte de la implementación, no como un añadido posterior de gobierno. El propietario de un modelo necesita umbrales específicos por conjunto de datos y desencadenantes explícitos para investigar, revertir o revalidar.

La encuesta de IIF-EY de 2025 también indicó que el 72 % de las empresas disponía de mecanismos de retroalimentación o controles para corregir modelos de IA, y otro 25 % estaba trabajando en ellos. Esta tendencia refuerza la idea: el gobierno de modelos se está volviendo correctivo y operativo. La data observability debe conectarse directamente con ese ciclo.

Un modelo operativo de 90 días para la gestión de datos financieros

Empiece por los datos que pueden modificar una decisión de riesgo, una comunicación regulatoria, un cálculo de capital o la entrada de un modelo. Defina los elementos de datos críticos por dominio de riesgo, entidad jurídica, línea de negocio, clase de activo, geografía y caso de uso de reporting.

Asigne un propietario responsable y un steward como metadatos legibles por máquina. Vincule a cada elemento controles de completitud, puntualidad, conciliación, integridad referencial, duplicados y esquema. Ejecute los controles lo más cerca posible del origen, conserve evidencias de cada ciclo de reporting y dirija las excepciones a personas concretas.

Utilice la validación determinista para las reglas conocidas y la detección de anomalías basada en líneas base para los comportamientos inesperados. Pruebe el modelo operativo con una entrega normal y con un escenario de estrés antes de ampliar la cobertura. Un pequeño conjunto de datasets controlados y con evidencias es más defendible que un amplio catálogo sin una vía de respuesta fiable.

digna ofrece calidad de datos y observability dentro de su propio entorno para equipos de servicios financieros, con validación dentro de la base de datos, monitorización de la puntualidad, detección de anomalías, seguimiento de esquemas y evidencias para pipelines de datos distribuidos. Visite digna para ver cómo su enfoque de plano de control puede ayudarle a monitorizar los datos críticos sin dar por hecho que la centralización es la respuesta.

Las contrapartes duplicadas y los préstamos sin una entidad jurídica válida son, en el fondo, relaciones rotas entre sistemas. Para conocer los controles que mantienen alineadas esas claves desde el core bancario hasta el data warehouse de riesgos, consulte la integridad referencial en los datos bancarios.

Preguntas frecuentes

¿Qué abarca la gestión de datos en servicios financieros?

Abarca el gobierno, el movimiento, la validación, el almacenamiento y el reporting de los datos desde que un evento de pago, operación, préstamo o cliente entra en un sistema de origen hasta que llega a los cálculos de riesgo, los informes regulatorios y los modelos. Gobierno, arquitectura, calidad de datos y reporting forman cuatro pilares que solo funcionan si se apoyan mutuamente.

¿Cómo se convierte BCBS 239 en controles de ingeniería?

Traduciendo cada área de principios en controles que generen evidencias: un registro de elementos de datos críticos con propietarios y umbrales para el gobierno, conciliaciones de origen a destino y monitorización de la actualidad para la agregación, y validación y certificación a nivel de informe para el reporting. Conserve los resultados de las reglas, las instantáneas de linaje y los registros de incidentes de cada ciclo de reporting.

¿Qué dimensiones de calidad de datos son más importantes para los bancos?

Completitud, exactitud, puntualidad, validez, unicidad y consistencia. Cada una responde a una pregunta distinta, por ejemplo si un préstamo incluye su código de entidad jurídica o si un saldo coincide entre la plataforma core y el data warehouse. Informe por separado de la dimensión que falla, el propietario y el impacto, en lugar de reducirlos a una puntuación compuesta que puede ocultar un fallo material.

¿Necesitan los bancos centralizar todos sus datos para cumplir BCBS 239?

No. Una copia central puede seguir estando incompleta, llegar tarde o estar desconectada del sistema responsable del proceso. Un plano de control distribuido ejecuta los controles in situ, cerca de los sistemas de origen, y centraliza solo metadatos y evidencias, lo que evita copias adicionales de datos sensibles y permite demostrar igualmente que los datos críticos son aptos para su uso.

¿Por qué la calidad de datos es un control en tiempo de ejecución para los modelos de IA en finanzas?

Un modelo validado puede comportarse de forma insegura cuando su entrada llega tarde, cambia de esquema o se desvía de su línea base. En una encuesta de IIF-EY de 2025, el 79 % de las empresas de servicios financieros señaló la calidad de datos como uno de los principales retos de la IA. Según SR 11-7, un cambio de entrada sin explicación puede convertirse en un evento de riesgo de modelo que exige investigación o revalidación.