Un apunte llega al almacén de datos (data warehouse) con un account_id que no existe en la tabla de cuentas. Una autorización de tarjeta apunta a un comercio que nunca se cargó. Un pago menciona un ID de contraparte que el sistema de riesgos no ha visto nunca. Nada se cae. Las filas simplemente desaparecen de cada inner join, y los totales aguas abajo quedan mal sin que nadie lo note. La integridad referencial en datos bancarios significa que cada referencia (la cuenta de un apunte, la contraparte de un pago, el cliente de un préstamo) apunta a un registro que realmente existe en la tabla maestra que nombra.

Los sistemas de core bancario suelen aplicar sus propias claves. El problema empieza cuando los datos salen de ellos: el almacén de datos, el motor de riesgos, la plataforma AML y la capa de reporting reciben cada uno su propia copia, con su propio calendario y, a menudo, con un formato de clave distinto. Ahí es donde aparecen los huérfanos, y donde realmente se decide la calidad de los datos bancarios.

A continuación: las referencias que importan en un banco, qué se rompe cuando no se cumplen, por qué siguen apareciendo huérfanos y cómo comprobar cada una con digna sin copiar datos fuera de sus sistemas.

Puntos clave

• Un huérfano en los datos bancarios no es un mensaje de error. Es un apunte, un pago o una exposición que desaparece en silencio de un join.

• Compruebe los joins de los que dependen los informes: apuntes, autorizaciones, pagos, préstamos, tipos de cambio y alertas AML frente a sus maestros.

• La mayoría de los huérfanos se deben a desfases temporales y a traducciones entre sistemas: datos maestros que llegan tarde, migraciones, lanzamientos de productos y formatos de clave distintos.

• En digna Data Validation, cada relación es una regla Referential Integrity, con umbral cero para los datos regulatorios y umbrales relativos solo para feeds con ruido.

• Desde Release 2026.01, una regla puede comparar una tabla del sistema core con otra del almacén de datos, y los registros fallidos pueden exportarse como evidencia.

Índice de contenidos

• Puntos clave

• ¿Qué referencias importan más en los datos bancarios?

  • Claves compuestas

  • Referencias entre sistemas

• ¿Qué ocurre cuando se rompe una referencia bancaria?

• ¿Por qué aparecen registros huérfanos en los sistemas bancarios?

• ¿Cómo se encuentran apuntes huérfanos con SQL?

• ¿Cómo se configura una comprobación de integridad referencial en digna?

• ¿Qué umbral deberían usar los datos regulatorios?

• ¿Cómo se comprueba el core bancario frente al almacén de datos?

• ¿Cómo se convierten los registros fallidos en evidencia de auditoría?

• Empiece por las claves de las que dependen sus informes

¿Qué referencias importan más en los datos bancarios?

Las referencias que más importan en los datos bancarios son aquellas a través de las que se unen todos los informes y cifras de riesgo: apuntes con cuentas, autorizaciones de tarjeta con tarjetas y comercios, pagos con contrapartes, préstamos con clientes y garantías, tipos de cambio con códigos de divisa, y alertas AML con cuentas y clientes. Si alguna de ellas no se une, el registro desaparece del resultado.

Para la definición general, consulte el artículo principal ¿Pueden sus datos seguir encontrando a sus padres? Entender la integridad referencial. En un banco, la lista es bastante estable:

• Apuntes → cuentas. Los saldos, intereses y comisiones se calculan a través de este join.

• Autorizaciones de tarjeta → tarjetas y comercios. La tarjeta lleva a la cuenta y al cliente; el comercio aporta el código de categoría.

• Pagos → contrapartes. El registro de la contraparte se utiliza para el screening, las estadísticas y la exposición.

• Préstamos → clientes y garantías. Tanto el prestatario como la garantía alimentan el riesgo y las provisiones.

• Tipos de cambio → códigos de divisa. Los tipos y los importes en divisa hacen referencia a una tabla de divisas, normalmente con códigos ISO 4217 como clave.

• Alertas AML → cuentas y clientes. Sin ellos, nadie puede tramitar la alerta.

Claves compuestas

Muchas claves bancarias no son una sola columna. Una cuenta multidivisa suele identificarse por cuenta + divisa; un préstamo sindicado o con disposiciones, por contrato + tramo. Comprobar solo account_id daría por bueno un apunte en EUR contra una cuenta que solo existe en USD. La comprobación tiene que hacerse sobre la combinación, con el mismo orden de columnas en ambos lados.

Referencias entre sistemas

Las referencias más frágiles cruzan los límites entre sistemas. El maestro de clientes reside en el sistema de core bancario, las transacciones en el almacén de datos del core bancario, las exposiciones en un sistema de riesgos con su propia tabla de contrapartes. Cada copia es coherente consigo misma. La cuestión es si coinciden entre sí.

¿Qué ocurre cuando se rompe una referencia bancaria?

Cuando se rompe una referencia bancaria, el registro hijo no falla de forma visible. Desaparece de los joins, de modo que los saldos, las exposiciones, las poblaciones de los informes y las colas de alertas se calculan sobre menos registros de los que existen. La consecuencia depende de qué relación se rompió, y la tabla siguiente la expone claramente para las más habituales.

Nada de esto produce un error en el log del ETL. El proceso terminó correctamente; el join simplemente fue más pequeño.

¿Por qué aparecen registros huérfanos en los sistemas bancarios?

Los registros huérfanos aparecen en los sistemas bancarios principalmente porque los datos maestros y las transacciones llegan con calendarios distintos y a través de traducciones distintas. Una transacción puede llegar al almacén de datos antes que su cuenta, una migración puede reescribir un lado de una clave y dos sistemas pueden dar formato distinto al mismo identificador. Cada causa es corriente; juntas hacen que los huérfanos sean algo rutinario.

• Datos maestros que llegan tarde. Las transacciones se cargan intradía y el maestro de cuentas una vez por noche. Un cliente dado de alta a las 10:00 que opera a las 10:05 es un huérfano hasta la siguiente carga del maestro.

• Fusiones y migraciones. Cuando una cartera pasa de un banco adquirido o de un core antiguo, los números de cliente y de contrato se remapean. Las filas que se quedan fuera del mapeo conservan las claves antiguas.

• Lanzamientos de productos. Un nuevo producto de tarjeta, tipo de cuenta o divisa entra en producción en el core antes de que las tablas de referencia del almacén de datos lo conozcan.

• Diferencias de formato de clave. Un sistema rellena los números de cuenta con ceros a la izquierda y otro los almacena como enteros; uno usa el IBAN y otro un ID interno; uno guarda los ID de contraparte en mayúsculas. Los valores significan lo mismo y aun así no se unen.

• Restricciones que no se aplican. La base de datos del core puede aplicar sus claves foráneas, pero las plataformas de almacén de datos suelen tratar las claves declaradas como informativas. Snowflake, por ejemplo, documenta que las claves foráneas en tablas estándar no se aplican. Nada impide que se cargue un huérfano.

Los supervisores esperan que los bancos agreguen los datos de riesgo de forma completa y exacta, tal como establecen los principios BCBS 239 del Comité de Basilea, y las exposiciones huérfanas van directamente en contra de ello. Para la vertiente organizativa más amplia, consulte la gestión de datos en los bancos.

¿Cómo se encuentran apuntes huérfanos con SQL?

Los apuntes huérfanos se encuentran con un anti-join: seleccione los apuntes cuyo account_id no es nulo y no tiene ninguna fila coincidente en accounts. Comparar con el conjunto de IDs de cuenta distintos mantiene el resultado correcto aunque la tabla de cuentas tenga duplicados, y excluir los nulos separa las referencias ausentes de las erróneas.

-- Postings whose account does not exist in the account master
SELECT p.*
FROM postings p
LEFT JOIN (SELECT DISTINCT account_id FROM accounts) a
  ON p.account_id = a.account_id
WHERE p.account_id IS NOT NULL
  AND a.account_id IS NULL

-- Postings whose account does not exist in the account master
SELECT p.*
FROM postings p
LEFT JOIN (SELECT DISTINCT account_id FROM accounts) a
  ON p.account_id = a.account_id
WHERE p.account_id IS NOT NULL
  AND a.account_id IS NULL

-- Postings whose account does not exist in the account master
SELECT p.*
FROM postings p
LEFT JOIN (SELECT DISTINCT account_id FROM accounts) a
  ON p.account_id = a.account_id
WHERE p.account_id IS NOT NULL
  AND a.account_id IS NULL

Para una clave compuesta como cuenta + divisa, el join simplemente incluye ambas columnas:

SELECT p.*
FROM postings p
LEFT JOIN (SELECT DISTINCT account_id, currency FROM accounts) a
  ON p.account_id = a.account_id
 AND p.currency   = a.currency
WHERE p.account_id IS NOT NULL
  AND p.currency   IS NOT NULL
  AND a.account_id IS NULL

SELECT p.*
FROM postings p
LEFT JOIN (SELECT DISTINCT account_id, currency FROM accounts) a
  ON p.account_id = a.account_id
 AND p.currency   = a.currency
WHERE p.account_id IS NOT NULL
  AND p.currency   IS NOT NULL
  AND a.account_id IS NULL

SELECT p.*
FROM postings p
LEFT JOIN (SELECT DISTINCT account_id, currency FROM accounts) a
  ON p.account_id = a.account_id
 AND p.currency   = a.currency
WHERE p.account_id IS NOT NULL
  AND p.currency   IS NOT NULL
  AND a.account_id IS NULL

Eso funciona para una relación en una base de datos. Un banco tiene decenas de relaciones repartidas entre varias bases de datos y necesita el resultado cada día. Mantener estas consultas a mano es la parte que suele acabar abandonándose.

¿Cómo se configura una comprobación de integridad referencial en digna?

En digna, una comprobación de integridad referencial se configura añadiendo una regla de tipo Referential Integrity a la fuente de datos hija, eligiendo sus columnas clave e indicando la fuente de datos y las columnas en las que deben existir. No hay que escribir SQL. digna genera la comprobación, la ejecuta dentro de su base de datos en cada inspección e informa del número de registros superados y fallidos.

Para postings.account_id → accounts.account_id, los pasos en digna Data Validation son:

1. Vaya a Configuration, seleccione la fuente de datos postings, abra la pestaña Data Validation y haga clic en Add Rule. Se abre el cuadro de diálogo Add Data Validation Rule.

2. Introduzca un Name (nombre) y una Description (descripción), por ejemplo posting_account_exists, "Cada apunte pertenece a una cuenta del maestro de cuentas".

3. Establezca Type (tipo) en Referential Integrity.

4. En Attributes (atributos), elija account_id (añada también currency para una clave cuenta + divisa).

5. En must exist in (debe existir en), elija la Data Source (fuente de datos) accounts y sus Attributes account_id, en el mismo orden que a la izquierda.

6. Elija el Threshold Mode (modo de umbral) y establezca el Info threshold y el Warn threshold.

7. Guarde. La regla se ejecuta con cada inspección de postings, programada o bajo demanda.

La captura de pantalla siguiente procede de la demostración hospitalaria de digna y no de un banco, pero el cuadro de diálogo es idéntico para una tabla bancaria: sustituya product_code y hospital_medications por account_id y accounts.

El cuadro de diálogo de la regla Referential Integrity en digna. Datos de demostración de Danubia Kliniken, un grupo hospitalario austriaco ficticio.

digna toma los valores distintos de la fuente de datos padre y marca como fallida cualquier fila hija que no se una. Las dos listas de columnas deben tener la misma longitud; una discrepancia se rechaza en lugar de comprobar en silencio una condición más débil. Las claves foráneas nulas se omiten, así que un pago sin ID de contraparte no hace fallar esta regla. Si la contraparte es obligatoria, añada una Rule independiente con counterparty_id IS NOT NULL. El recorrido completo está en cómo configurar una comprobación de integridad referencial; la documentación de digna explica cómo se evalúa la validación.

¿Qué umbral deberían usar los datos regulatorios?

Los datos regulatorios deberían usar tolerancia cero: el modo de umbral Absolute, configurado para que un solo huérfano haga fallar la comprobación. Una exposición que falta en un informe regulatorio es un defecto, por muchas filas que hayan superado la comprobación. Los umbrales relativos solo tienen sentido en feeds con ruido, donde se espera una proporción pequeña y conocida de referencias que llegan tarde.

digna evalúa dos niveles. Por encima del Info threshold, el estado es Uncertain; por encima del Warn threshold, es Failed; en otro caso, Passed. Ambos umbrales son cero por defecto, así que una regla nueva falla con el primer registro incorrecto hasta que usted decida otra cosa. La regla de demostración anterior usa Absolute, Info 0, Warn 1, de modo que un solo huérfano ya genera un estado Uncertain y dos o más hacen fallar la comprobación; para datos regulatorios, deje Warn en 0 para que un solo huérfano haga fallar la comprobación.

Si un umbral relativo absorbe datos maestros que llegan tarde, vuelva a comprobar los mismos datos más adelante, para que "tarde" no se convierta en silencio en permanente.

¿Cómo se comprueba el core bancario frente al almacén de datos?

El core bancario se comprueba frente al almacén de datos con una regla de integridad referencial cuyas dos fuentes de datos están en distintas conexiones de base de datos del mismo proyecto de digna. Desde Release 2026.01 esto se admite directamente, de modo que el maestro de cuentas del sistema core y los apuntes del almacén de datos se validan sin replicar ninguna de las dos tablas.

Esto detecta los problemas entre sistemas descritos más arriba: diferencias de formato de clave, números de cliente remapeados, cuentas que nunca llegaron al almacén de datos. En digna, las conexiones de base de datos son globales y reutilizables entre proyectos, y una fuente de datos puede ser una tabla, una vista o una sentencia SQL personalizada. Una fuente de datos de vista o SQL es un lugar práctico para normalizar el formato de una clave (por ejemplo, quitando los ceros a la izquierda) antes de comparar. Las comprobaciones se ejecutan dentro de sus bases de datos; sus datos nunca salen de su infraestructura. Los detalles, incluidos esquemas y vistas, están en integridad referencial entre bases de datos y conexiones.

¿Cómo se convierten los registros fallidos en evidencia de auditoría?

Los registros fallidos se convierten en evidencia de auditoría porque digna devuelve las propias filas, no solo un recuento. La vista Invalid Records (registros no válidos) lista cada registro que no superó una comprobación en una inspección determinada, filtrado por Passed, Uncertain o Failed, y la lista puede exportarse para un auditor, un responsable de datos o un ticket de incidencia.

Técnicamente, es la misma consulta con la condición de aprobación negada, ejecutada dentro de la base de datos de origen. Para una regla sobre apuntes, ve cada apunte huérfano con su ID de cuenta, importe, fecha contable y otras columnas, normalmente suficiente para que el equipo responsable rastree la causa. digna también puede notificar al equipo responsable de los datos.

Invalid Records de una comprobación de integridad referencial fallida, de la misma demostración hospitalaria; una tabla bancaria muestra sus propias columnas en la misma vista.

Como los resultados se conservan por fecha de inspección, puede mostrar cuándo se rompió una relación y cuándo se corrigió. Ese registro de comprobaciones, resultados y filas fallidas es material útil cuando explica sus controles, aunque por sí solo no hace que un proceso cumpla la normativa.

Empiece por las claves de las que dependen sus informes

No necesita todas las relaciones el primer día. Tome los cinco o seis joins de los que dependen sus informes regulatorios y de riesgos, añada una regla Referential Integrity por relación, establezca tolerancia cero donde una fila que falta es una exposición que falta y deje que se ejecuten las inspecciones. Pronto verá qué feeds producen huérfanos, y cuándo. Si quiere verlo con sus propias tablas del core y del almacén de datos, reserve una demostración con el equipo de digna.

Preguntas frecuentes

¿Qué es la integridad referencial en datos bancarios?

Significa que cada referencia en los datos de un banco apunta a un registro que existe: cada apunte a una cuenta conocida, cada pago a una contraparte conocida, cada préstamo a un cliente conocido. Cuando una referencia se rompe, el registro desaparece en silencio de los joins, de modo que los saldos, las exposiciones y los informes se calculan sobre menos filas de las que existen.

¿Por qué aparecen registros huérfanos en un almacén de datos de core bancario?

Sobre todo porque las transacciones y los datos maestros llegan con calendarios distintos. Los apuntes se cargan intradía mientras que el maestro de cuentas se carga cada noche, las migraciones remapean números de cliente, los productos nuevos entran en producción antes de que las tablas de referencia los conozcan y los sistemas dan formato distinto a la misma clave, por ejemplo con o sin ceros a la izquierda.

¿Cómo encuentro con SQL apuntes sin una cuenta coincidente?

Utilice un anti-join: haga un LEFT JOIN de los apuntes con los IDs de cuenta distintos de la tabla de cuentas y quédese con las filas en las que el lado de la cuenta es NULL, excluyendo los apuntes cuyo account_id ya es NULL. Para una clave de cuenta más divisa, una ambas columnas en el mismo orden.

¿Deberían los datos de reporting regulatorio admitir algún registro huérfano?

No. Para los datos que alimentan informes regulatorios o de riesgos, utilice un umbral Absolute para que un solo huérfano haga fallar la comprobación, porque cada fila que falta es una exposición o un movimiento que falta. Los umbrales relativos solo son razonables para feeds con ruido, como las autorizaciones de tarjeta intradía que esperan los datos maestros de comercios.

¿Puede digna comprobar referencias entre el sistema de core bancario y el almacén de datos?

Sí. Desde Release 2026.01, una regla Referential Integrity de digna puede comparar fuentes de datos en distintas conexiones de base de datos del mismo proyecto, como el maestro de cuentas del sistema core y los apuntes del almacén de datos. Las comprobaciones se ejecutan dentro de sus bases de datos y no se replica ninguna tabla.