Los principales marcos de supervisión definen la gestión de datos en los bancos a través de cuatro dimensiones de control medibles: exactitud, integridad, completitud y oportunidad. En la práctica, esto significa que el trabajo no consiste solo en almacenar datos, sino en demostrar que siguen siendo fiables hasta llegar a los flujos de riesgos, finanzas y reporting.

Los bancos que lo tratan como un ejercicio de documentación suelen pasar por alto lo esencial. El trabajo difícil está en los controles operativos, las comprobaciones de frescura, las conciliaciones, el linaje y la trazabilidad a lo largo de todo el recorrido de los datos, porque los datos de entrada desactualizados o incompletos se propagan rápidamente en cuanto entran en los sistemas posteriores.

Índice

• Dimensiones de control clave que miden los reguladores

  • Qué significa cada dimensión de control en la práctica

• Modelos prácticos de gobierno y responsabilidad

  • Cómo es una responsabilidad que funciona

  • El patrón de fallo que hay que evitar

• Requisitos de BCBS 239 y arquitectura de cumplimiento

• Por qué fallan los controles sin responsabilidad en el origen

  • Por qué los controles implantados siguen sin llegar a la causa raíz

  • Qué provocan los flujos fragmentados en la remediación

• La brecha del modelo operativo preparado para la IA

  • Dónde se estancan los programas de IA

  • Cómo es un modelo operativo realista

• Cómo construir un marco integrado de gestión de datos

  • El marco que realmente se sostiene

Dimensiones de control clave que miden los reguladores

Cuatro dimensiones de control ofrecen a los reguladores una forma práctica de evaluar la calidad de los datos bancarios: exactitud, integridad, completitud y oportunidad. Se espera que los bancos conecten estas dimensiones con el gobierno del dato, una arquitectura de datos integrada y controles de calidad medibles, en lugar de dejarlas como simple lenguaje de política interna (BDO). Las consecuencias operativas son inmediatas. Un feed retrasado puede distorsionar la agregación de riesgos, un campo ausente puede debilitar un control financiero y un registro incoherente puede propagar errores a las capas de reporting que dependen de datos compartidos.

Qué significa cada dimensión de control en la práctica

La exactitud significa que los valores coinciden con el registro fuente autorizado que pretenden representar. En un banco, los saldos, los atributos de clientes, las clasificaciones y los datos de referencia deben coincidir con el sistema de registro aprobado, y no limitarse a coincidir con una copia del data warehouse que quizá ya esté desactualizada.

La integridad preserva las relaciones y el significado a medida que los registros se mueven entre sistemas. Incluye claves válidas, pistas de auditoría completas, transformaciones controladas y definiciones coherentes. Sin esos controles, una cifra reportada puede conservar su formato y perder el significado que tenía en el momento de la captura.

La completitud abarca los campos, registros y atributos necesarios para un control de negocio o regulatorio. Un feed de transacciones puede parecer sano y, sin embargo, omitir un componente obligatorio. Los informes posteriores pueden entonces parecer terminados mientras ocultan una carencia material.

La oportunidad identifica los datos que llegan demasiado tarde para el uso previsto. Un banco puede disponer de los registros necesarios, pero los datos de entrada desactualizados no sirven para el análisis de liquidez actual, las pruebas de estrés, la agregación de riesgos ni el reporting regulatorio.

Regla práctica: trate las comprobaciones de frescura y las conciliaciones como controles operativos, no como tareas de limpieza periódicas.

La guía del BCE sobre agregación eficaz de datos de riesgo y presentación de informes de riesgos aplica las mismas dimensiones y exige KPI detallados para ellas (guía del BCE). Un KPI útil debe mostrar algo más que si una regla se ha cumplido. Debe identificar la fuente afectada, el pipeline, el responsable, el informe posterior y el momento de la detección.

Esa distinción pone de manifiesto la brecha entre el diseño del control y su ejecución. Un banco puede documentar un umbral de frescura y, aun así, descubrir un feed fallido solo cuando un informe llega tarde. Las herramientas modernas de observabilidad pueden supervisar la entrega, los cambios de Schema, las variaciones de volumen y los incumplimientos de reglas en todo el pipeline. La validación dentro de la base de datos puede comprobar saldos, relaciones referenciales y reglas de negocio cerca de los datos, antes de que los defectos se propaguen.

Empiece por separar las comprobaciones descriptivas de calidad de las comprobaciones de control. Las reglas descriptivas identifican anomalías evidentes. Las reglas de control demuestran que el pipeline funciona dentro de las expectativas definidas antes de que los datos lleguen a los procesos de riesgos, finanzas o reporting.

Utilice un vocabulario común para auditores, ingenieros y responsables de negocio, y vincule cada regla a una consecuencia de negocio. Las dimensiones de la calidad de datos son una referencia útil para ese vocabulario. La gestión de datos en los bancos se convierte en una disciplina operativa cuando los equipos pueden medir cada dimensión, rastrear los fallos hasta su origen y aportar pruebas de la remediación.

Modelos prácticos de gobierno y responsabilidad

El buen gobierno falla cuando nadie es responsable de un problema de datos de principio a fin. Los bancos necesitan una responsabilidad explícita, rutinas de escalado claras y un linaje documentado para que los defectos de calidad se prioricen y se corrijan, en lugar de limitarse a registrarlos y olvidarlos (Dunnixer). Esa es la diferencia práctica entre un estatuto de gobierno y un modelo de control que funciona. Uno crea responsabilidad sobre el papel; el otro cambia la forma en que los incidentes recorren la organización.

Cómo es una responsabilidad que funciona

Un banco no necesita más comités. Necesita responsables designados para los dominios de datos críticos, un camino de escalado documentado y una definición compartida de lo que significa “resuelto”. Si un feed de datos de referencia se rompe, el data steward debe saber quién lo clasifica, quién aprueba la corrección y qué consumidores posteriores deben ser informados.

Los programas más sólidos también estandarizan las definiciones críticas. Cuando cliente, producto, exposición o saldo significan cosas distintas en diferentes partes del banco, cada conciliación se complica y cada auditoría se alarga. Las definiciones estándar reducen las discusiones semánticas y desplazan la atención hacia los defectos reales.

La responsabilidad no es una línea jerárquica. Es la obligación de asegurarse de que los datos sigan funcionando cuando termina la reunión.

Por la misma razón importa contar con una línea base de calidad actualizada. Si nadie sabe qué es “normal”, una deriva silenciosa puede permanecer en producción durante semanas antes de que alguien la detecte. Esto es especialmente peligroso en bancos con entornos mixtos, donde las plataformas core, los data marts y las capas de reporting interpretan el mismo registro de forma ligeramente distinta.

Nuestra guía sobre gobierno de datos financieros encaja bien con este modelo, porque el gobierno solo funciona cuando conecta políticas, stewardship y monitorización operativa. En la práctica, los mejores bancos organizan la responsabilidad de los controles en torno al recorrido de los datos, no en torno a una frontera departamental difusa. Eso significa que el responsable del sistema fuente, el steward de la definición de negocio y el consumidor del informe tienen obligaciones definidas.

El patrón de fallo que hay que evitar

El patrón de fallo habitual es sencillo. Se registra un problema de calidad, pero nadie tiene autoridad para corregir la fuente, así que el equipo aplica una solución provisional aguas abajo. Esa solución mantiene el informe en marcha, pero oculta el problema original y crea un segundo problema en el linaje.

Por eso el gobierno tiene que incluir el escalado. Si un defecto afecta a un conjunto de datos regulatorio, el problema no debería esperar a un ciclo de revisión mensual. Debería seguir un camino definido que active medidas, la recogida de evidencias y una responsabilidad clara del seguimiento.

Los bancos que lo hacen bien no dependen de actos heroicos. Se apoyan en roles claros, definiciones estándar y la disciplina de tratar los problemas de calidad como incidentes operativos, no como ruido administrativo.

Requisitos de BCBS 239 y arquitectura de cumplimiento

BCBS 239 sigue siendo la referencia porque vincula la agregación de datos de riesgo con las expectativas supervisoras. El marco define 14 principios para la agregación eficaz de datos de riesgo y la presentación de informes de riesgos, y ayuda a los bancos a producir información de riesgos exacta, oportuna y completa, también en periodos de tensión (BPI). Sus requisitos van más allá del equipo de reporting. Condicionan el gobierno, la arquitectura, el diseño de controles y la capacidad del banco para agregar información de riesgos de forma coherente entre entidades jurídicas y líneas de negocio.

La automatización importa porque cada traspaso manual crea otro punto de fallo. El personal puede volver a teclear valores con errores, retrasar un envío o aplicar lógica de hojas de cálculo que nunca entra en el diseño formal de controles. Los flujos automatizados reducen esos puntos de fallo, pero no sustituyen la responsabilidad sobre los controles. Hacen que los controles definidos sean repetibles y medibles a escala.

La cobertura plantea una prueba arquitectónica distinta. La agregación de riesgos debe representar a la entidad en su conjunto, incluidas las entidades jurídicas, regiones, grupos de activos y vistas de reporting relevantes. Excluir alguna de estas áreas puede dejar al banco con un informe impecable y una visión de riesgos incompleta. Por ello, el diseño necesita un alcance explícito, reglas de inclusión y comprobaciones que detecten poblaciones ausentes antes del reporting.

El linaje es la capa de evidencia. Las orientaciones supervisoras asociadas a BCBS 239 hacen hincapié en la trazabilidad desde la captura de datos hasta el reporting final, incluida la capacidad de seguir atributos individuales (EY). Un diagrama de linaje por sí solo no demuestra que el control funcione. Los equipos necesitan evidencias de ejecución que muestren el valor de origen, cada transformación, el resultado de la validación y la salida del informe.

La guía del BCE añade detalle operativo al exigir a los bancos que definan KPI para supervisar las dimensiones de calidad de datos. Esto desplaza la arquitectura de cumplimiento de la documentación estática a la observación continua. Las herramientas modernas de observabilidad pueden poner de manifiesto fallos de frescura, volumen, Schema y reglas en pipelines fragmentados, mientras que la validación dentro de la base de datos puede comprobar los registros cerca del punto en que se crean o modifican.

Para más detalles sobre la implantación, consulte la guía sobre cómo cumplir los principios de BCBS 239 con calidad de datos impulsada por IA.

Prueba operativa: cuando cambia una cifra de riesgo, el equipo debería poder identificar su origen, sus transformaciones, sus controles de validación y las evidencias que la respaldan sin reconstrucción manual.

Los bancos suelen presentar una cobertura parcial de controles como cobertura de BCBS 239. La diferencia importa. Las carencias de linaje, automatización o alcance institucional pueden permanecer ocultas hasta que una situación de tensión aumenta el volumen de reporting o deja al descubierto datos incoherentes. Una arquitectura resiliente debería hacer visibles esas carencias mediante la monitorización, en lugar de esperar a que una revisión supervisora o un incidente de reporting las revele.

Por qué fallan los controles sin responsabilidad en el origen

Lo frustrante de la gestión de datos en los bancos es que los controles pueden parecer sólidos sobre el papel y aun así fallar en producción. Un estudio europeo de 2025 sobre reporting regulatorio concluyó que el 90% de los bancos tenía al menos tres controles de calidad de datos y el 66% una arquitectura de datos centralizada, pero solo el 18% declaraba una implantación completa de BCBS 239 y apenas el 24% contaba con una documentación de linaje amplia (Deloitte). El mismo estudio reveló que los datos fuente ausentes o incorrectos seguían siendo la principal causa de errores de reporting, citados por el 56% y el 50% de los bancos, respectivamente.

Por qué los controles implantados siguen sin llegar a la causa raíz

Esta es la lección incómoda que la mayoría de los bancos necesita escuchar. El factor limitante no suele ser la falta de controles, sino una débil responsabilidad sobre los datos fuente, flujos fragmentados y una visibilidad insuficiente del linaje. Los equipos pueden implantar reglas de validación, pero si nadie es responsable del sistema fuente y nadie puede rastrear un valor erróneo hasta su origen, el mismo defecto vuelve a aparecer una y otra vez en distintos informes.

Por eso la gestión de incidentes es tan importante. Registrar un problema no es lo mismo que resolverlo. Si el defecto está aguas arriba, el equipo aguas abajo solo puede parchear los síntomas, no la causa.

Nuestra guía sobre las responsabilidades del data owner encaja con esta realidad operativa. La responsabilidad tiene que llegar hasta el origen, porque ahí es donde empieza la rendición de cuentas y donde normalmente se puede corregir el problema.

Qué provocan los flujos fragmentados en la remediación

Los flujos fragmentados encarecen la remediación de formas fáciles de subestimar. Un banco puede corregir el informe visible, pero si falta el linaje, cada consumidor posterior tiene que volver a validar el mismo problema por separado. Eso multiplica el esfuerzo de revisión y retrasa el cierre.

También debilita la respuesta ante auditorías. Cuando los auditores preguntan cómo se obtuvo una cifra, los equipos necesitan un camino desde la captura del registro hasta la salida del informe, no una colección suelta de capturas de pantalla y notas de tickets. Si el linaje es escaso, el banco puede demostrar que un control se ejecutó, pero no que los datos correctos pasaron por él.

Si el equipo solo puede describir el síntoma, el problema de origen sigue gobernando el banco.

Un mejor diagnóstico consiste en preguntarse si la organización puede rastrear las excepciones hasta sus puntos de origen. Si la respuesta es no, los controles actúan como filtros, no como mecanismos de rendición de cuentas. Esa distinción importa porque los filtros pueden reducir los errores visibles sin cambiar el proceso productivo.

Los bancos que rompen este patrón suelen hacer dos cosas de forma diferente. Asignan la responsabilidad en el origen y diseñan controles que conservan la evidencia del recorrido de los datos. Esa combinación es la que cierra la brecha entre el diseño del control y su ejecución.

La brecha del modelo operativo preparado para la IA

Los bancos saben que los datos son clave para la IA, pero muchos todavía no logran pasar de la ambición a la ejecución. Una encuesta reciente de KPMG al sector bancario reveló que el 93% de los encuestados señalaba la privacidad y el riesgo de los datos, el 89% la calidad de datos y el 81% la complejidad de los sistemas heredados y de la integración como principales retos de modernización, mientras que el 68% afirmaba tener una visión del estado objetivo y el 65% una hoja de ruta y un modelo de financiación (encuesta bancaria de KPMG). Esa brecha dice algo importante. La estrategia existe. La columna vertebral operativa, a menudo no.

Dónde se estancan los programas de IA

El primer punto de fallo suele ser la confianza. Si la calidad de los datos es irregular, los equipos no se fiarán de ellos para entrenar modelos, monitorizarlos ni para el retrieval de GenAI. Eso frena la experimentación antes de que el primer piloto produzca algo útil.

El segundo punto de fallo es la integración. Los entornos heredados dificultan mover datos validados entre los flujos de riesgos, finanzas e IA sin crear nuevas copias y nuevo trabajo de conciliación. El resultado es un stack que parece moderno por arriba y frágil por debajo.

El tercer punto de fallo es la presión del gobierno. Los bancos no solo necesitan datos que funcionen técnicamente, sino datos capaces de superar una revisión de cumplimiento. Si la entrada del modelo no se puede rastrear, explicar y validar, el banco puede tener un caso de uso prometedor que nunca supere la revisión operativa.

Nuestro recurso sobre datos preparados para la IA es pertinente aquí, porque estar preparado para la IA depende sobre todo de la solidez de los controles, no del hype. Si el Data Pipeline subyacente no puede demostrar frescura, estructura y trazabilidad, la capa de IA hereda esa debilidad.

Cómo es un modelo operativo realista

Un modelo realista no empieza por el modelo. Empieza por el recorrido de los datos. Los bancos necesitan validación donde aterrizan los datos, comprobaciones de puntualidad donde llegan los feeds y un linaje que se mantenga intacto cuando los registros se transforman o se combinan.

Ahí es donde la observabilidad resulta útil. Los equipos necesitan ver cuándo cambia un feed, cuándo se modifica un Schema o cuándo una fuente deja de entregar a tiempo, antes de que el problema quede incorporado en la analítica posterior. El valor no está solo en la rapidez. Está en la capacidad de impedir que unos datos defectuosos se conviertan en un modelo defectuoso.

Estar preparado para la IA es, ante todo, un problema de operaciones de datos.

La conclusión práctica es que las hojas de ruta hacia el estado objetivo no bastan. Los bancos necesitan controles operativos que sobrevivan al salto de las diapositivas de modernización a los pipelines en producción. De lo contrario, el programa de IA se convierte en otra iniciativa que parece comprometida sobre el papel y es frágil en producción.

Cómo construir un marco integrado de gestión de datos

Un marco eficaz une gobierno, arquitectura, linaje y validación en un único modelo operativo. No se trata de añadir más pasos de revisión. Se trata de hacer visible la calidad con la antelación suficiente para que el banco pueda impedir que datos defectuosos lleguen al reporting regulatorio, a los modelos de riesgo o a los flujos de IA.

El diseño más sólido empieza con una monitorización continua a nivel del recorrido de los datos. Los bancos necesitan vigilar la frescura de las entregas, los cambios de Schema y los incumplimientos de reglas en el punto en que los datos entran en el entorno, no solo cuando alguien detecta un informe erróneo. Ahí es donde importa la validación dentro de la base de datos, porque las comprobaciones que se ejecutan cerca de los datos reducen su movimiento, conservan la evidencia de control y evitan que cada excepción se convierta en un ejercicio de copiar y comparar.

El marco que realmente se sostiene

Un marco práctico para un banco suele tener cinco capas.

• Definición de controles: cada conjunto de datos crítico tiene reglas explícitas de exactitud, integridad, completitud y oportunidad.

• Responsabilidad: un responsable y un steward designados responden del comportamiento de la fuente y de la remediación.

• Linaje: el banco puede rastrear los datos desde la captura, pasando por la transformación, hasta el reporting final.

• Monitorización: la frescura, la validación y los cambios de Schema se comprueban de forma continua, no periódica.

• Respuesta: las excepciones activan un escalado con evidencias, no solo un número de ticket.

Esas capas deben asentarse sobre la arquitectura real del banco, no fuera de ella. Si los controles residen en herramientas separadas que requieren sincronización manual, los equipos acaban conciliando los propios controles en lugar de los datos.

El mejor modelo de control es aquel en el que los operadores pueden confiar sin volver a comprobarlo a mano.

Por eso las herramientas de observabilidad importan hoy más que nunca. Las expectativas supervisoras se mueven cada vez más hacia la evidencia, no hacia la intención. Si el banco puede mostrar qué llegó, qué cambió, qué falló y qué se corrigió, el modelo de control se vuelve auditable en lugar de aspiracional.

digna es una opción en este ámbito porque combina validación de datos, monitorización de Timeliness, seguimiento de Schema y ejecución dentro de la base de datos en el propio entorno del cliente. En un contexto bancario, este tipo de diseño responde a la necesidad de mantener los datos donde están mientras se comprueban de forma continua en data warehouses, data lakes y pipelines.

La prueba final es sencilla. Si el banco puede detectar pronto los datos de entrada defectuosos, rastrearlos hasta su origen y demostrar lo que ocurrió sin reconstrucciones manuales, el modelo operativo está haciendo un trabajo real. Si no, la organización sigue teniendo lenguaje de gobierno, pero todavía no una capacidad resiliente de gestión de datos bancarios.

Si está modernizando los controles de datos de su banco y busca una forma práctica de supervisar la frescura, validar registros y preservar el linaje dentro de su propio entorno, visite digna y descubra cómo sus módulos de observabilidad y validación encajan en operaciones de datos reguladas. Está pensado para equipos que necesitan evidencias, no solo dashboards.

Más de una década después de la publicación de BCBS 239, muchos bancos todavía lo tratan como un proyecto de documentación y no como una mejora de la forma en que gestionan los datos de riesgo. Nuestro artículo sobre cómo convertir el cumplimiento de BCBS 239 en valor de negocio analiza los principios de exactitud, oportunidad y reporting, y cómo los bancos pueden transformar esa obligación regulatoria en una ventaja competitiva.

Preguntas frecuentes

¿Cuáles son las cuatro dimensiones de calidad de datos que utilizan los reguladores con los bancos?

Los reguladores evalúan los datos bancarios según su exactitud, integridad, completitud y oportunidad. La guía del BCE sobre agregación de datos de riesgo pide a los bancos que definan KPI detallados para cada una, y un KPI útil debe indicar la fuente afectada, el pipeline, el responsable, el informe posterior y el momento de la detección, no solo si una regla se cumplió.

¿Cuántos principios tiene BCBS 239?

BCBS 239 establece 14 principios para la agregación eficaz de datos de riesgo y la presentación de informes de riesgos. Tres requisitos son los que más condicionan la arquitectura bancaria: una agregación en gran medida automatizada para reducir errores manuales, la cobertura de entidades jurídicas, regiones y tipos de activos, y un linaje que rastree atributos individuales desde la captura de datos hasta el informe final.

¿Por qué los bancos siguen sin cumplir BCBS 239 pese a tener controles de calidad de datos?

Los controles fallan sobre todo porque los datos fuente no tienen un responsable claro. Un estudio de Deloitte de 2025 concluyó que el 90% de los bancos europeos aplica al menos tres controles de calidad de datos, pero solo el 18% declara una implantación completa de BCBS 239 y el 24% tiene un linaje amplio, mientras que los datos fuente ausentes o incorrectos siguen siendo la principal causa de errores de reporting.

¿Qué frena la adopción de la IA en los datos bancarios?

La confianza en los datos y la integración, más que la estrategia. En una encuesta de KPMG al sector bancario, el 89% citó la calidad de datos y el 81% la complejidad de los sistemas heredados y de la integración como principales retos, aunque el 68% ya tenía una visión del estado objetivo. Sin comprobaciones de frescura, validación y linaje en el recorrido de los datos, los modelos de IA heredan las debilidades de sus entradas.

¿Qué debe incluir un marco de gestión de datos bancarios?

Un marco viable tiene cinco capas: definición de controles, responsabilidad, linaje, monitorización y respuesta. Cada conjunto de datos crítico cuenta con reglas explícitas, un responsable y un steward designados, trazabilidad hasta el informe final, comprobaciones continuas de frescura, validación y cambios de Schema, y un escalado que aporta evidencias en lugar de solo un número de ticket.