Acelerador Datum

Datum para banca.

Datum acelera el despliegue del modelo operativo del dato en banca — con un Common Data Financial alineado con BIAN y una Business Layer regulatoria preparada para COREP, FINREP, BCBS 239 e IFRS 9. Lista para producción en semanas, no en trimestres.

Basilea III / IV · BCBS 239 · DORA · PSD2
BCBS 239
DORA
IFRS 9 / IRB
COREP / FINREP
Banco de España · BCE
El problema

Los datos bancarios fallan por falta de modelo, no por falta de tecnología.

La mayoría de entidades tienen plataformas, DWH y herramientas de reporting. Lo que no tienen es un modelo de dato que conecte gobierno, calidad, trazabilidad y explotación de forma sostenible.

Arquitectura sectorial

Cómo se estructura Datum para banca.

La arquitectura de Datum se extiende para banca con dos capas sectoriales explícitas: un Common Data Financial alineado con BIAN y una Business Layer orientada a reporting y cálculo regulatorio. No reinventamos la arquitectura — la especializamos.

Capas de la arquitectura de Datum para bancaCATALOGSCatálogos de negocioReporting · Riesgo · Finanzas · ComercialBUSINESSBusiness Layer regulatoriaCOREP · FINREP · BCBS 239 · IFRS 9 / IRB · Stress testsCDM_FINCommon Data Financial (BIAN)Party · Customer Offer · Credit · Payment · Collateral · …CDMCommon Data (core Datum)Corporate · Customer · Reference · operaciones transversalesOPOperationalDato técnico armonizado, historificado y trazableLANDINGLanding (RAW)Recepción fiel del dato desde sistemas origen

Qué significa para un banco

01
Common Data Financial — BIAN como primera clase

Las entidades bancarias centrales (cliente, contrato, operación, garantía, producto) se modelan desde el primer día alineadas con BIAN. No hay un paso intermedio de "traducir el CDM genérico al negocio bancario" — la capa existe con esa semántica.

02
Business Layer regulatoria — datasets certificables

COREP, FINREP, BCBS 239, IFRS 9 y los agregados de riesgo no son hojas de cálculo mensuales que reconstruye el equipo de riesgos. Son productos de datos gobernados, con linaje hasta el origen, versionados y reconciliados automáticamente.

03
Separación explícita de capas — gobierno por nivel

Cada capa tiene ownership propio: IT custodia Landing y Operational, la Oficina del Dato gobierna Common Data y Business, y el negocio consume desde los catálogos. El gobierno baja a la operación por diseño, no por voluntarismo.

Marco regulatorio

Qué abordamos desde Datum — y qué no.

La banca es uno de los sectores más regulados. Distinguimos con honestidad qué marcos cubre Datum como base técnica, cuáles alineamos parcialmente y cuáles son responsabilidad del banco.

Cubrimos con Datum

Datum aporta la base técnica real (gobierno, linaje, calidad, ownership, trazabilidad) para estos marcos.

BCBS 239
Principios de agregación y reporting de riesgo
Gobierno, linaje, calidad y reconciliación del dato de riesgo con trazabilidad completa hasta origen.
DORA
Resiliencia operativa digital
Continuidad, clasificación de activos críticos de dato, gestión de incidentes y registro de acceso.
IFRS 9 / IRB
Provisiones y riesgo de crédito
Ownership y calidad del dato de entrada a modelos de pérdida esperada y probabilidad de default.
COREP / FINREP
Reporting regulatorio
Datasets certificados sobre Common Data con reconciliación automática y versionado.
RGPD
Protección de datos personales
Clasificación, base jurídica trazada, derechos del titular ejecutables sobre dato con linaje.

Alineamos parcialmente

Datum facilita la conformidad; la integración técnica específica corresponde al banco.

MiFID II
Servicios de inversión
Metadato e información al cliente sobre dato gobernado. La aplicación operacional específica es del área de inversión.
PSD2
Pagos y acceso a cuentas
Dato de cuenta y operación expuesto con gobierno y auditoría. La capa de APIs y autenticación es del sistema transaccional.

Fuera de alcance

No sustituimos motores transaccionales ni supervisión directa. Seamos claros.

AML / KYC
Motor operacional
Los motores de screening, blacklists y decisión son sistemas específicos. Datum aporta el dato gobernado de cliente y operación subyacente.
BdE · BCE
Supervisión directa
La relación supervisora es del banco. Datum aporta trazabilidad y reproducibilidad de los datos reportados.
Cómo Datum soporta la pirámide regulatoria bancaria
Pirámide regulatoria bancaria y cobertura DatumReporting regulatorioCOREP · FINREP · BdE · BCEDatumDatasets certificados sobre CDM · reconciliación automáticaCálculo y modelosIFRS 9 · IRB · Stress testsDatumCalidad y ownership del dato de entrada · linaje a resultadosResiliencia del datoDORA · BCBS 239DatumContinuidad · linaje · calidad · auditoríaGobierno y trazabilidadRGPD · políticas internasDatumOwnership · base jurídica · clasificación · registro de uso
Estándar sectorial

BIAN como mapa semántico del dato bancario.

BIAN (Banking Industry Architecture Network) es el estándar de referencia mundial para la arquitectura de negocio bancaria. Define un catálogo de Service Domains que representan capacidades bancarias universales. Lo usamos como referencia semántica para diseñar el Common Data Financial de Datum.

Por qué BIAN importa en gobierno del dato bancario

01
Vocabulario común del sector

BIAN define más de 300 Service Domains que representan capacidades bancarias reconocibles por cualquier entidad del mundo: Customer Offer, Credit Management, Payment Order… Es el lenguaje común del negocio bancario.

02
Base para el Common Data Financial

Permite estructurar el CDM bancario alineado con la forma real en que opera la industria, en lugar de inventar un modelo propio incompatible con el ecosistema.

03
Conversación con arquitectos y CIOs

Un CIO, un arquitecto enterprise o un consultor de primera línea reconocen BIAN como referencia compartida. Hablar ese idioma acelera el alineamiento ejecutivo.

04
Reutilización entre entidades

Un modelo común alineado con BIAN acelera proyectos en otra entidad. Menos reinvención semántica por cliente, más foco en el diferencial real del caso de uso.

Service Domains que cubrimos en el CDM Financial de Datum

No cubrimos los 300+ Service Domains de BIAN. Cubrimos los que soportan el dato crítico para reporting, riesgo, cliente, producto y operación.

Áreas BIAN cubiertas por el Common Data Model de DatumDatum CDMCommon DataModel financieroPARTYPartyCUSTOMER_OFFERCustomer OfferCREDITCredit ManagementPAYMENTPayment OrderCOLLATERALCollateralPRODUCTProduct ManagementCHANNELChannel ActivityOPRISKOperational Risk
PARTY
Party
Cliente, contraparte, intermediarios, grupo económico.
CUSTOMER_OFFER
Customer Offer
Productos y condiciones contratados con el cliente.
CREDIT
Credit Management
Operaciones de crédito, exposiciones, impago.
PAYMENT
Payment Order
Órdenes de pago, transferencias, liquidación.
COLLATERAL
Collateral
Garantías, valoraciones, seguimiento.
PRODUCT
Product Management
Catálogo de productos, precios, características.
CHANNEL
Channel Activity
Canales, operaciones por canal, interacción.
OPRISK
Operational Risk
Eventos, pérdidas operacionales, controles.
BIAN no es un modelo físico único. Es un catálogo de Service Domains y capacidades. Datum traduce ese marco en estructuras reales de Common Data Financial, alineadas con BIAN pero optimizadas para la plataforma del banco y los requisitos regulatorios locales (BdE, BCE, EBA).
Qué activa Datum

Capacidades del dato diseñadas para el contexto bancario.

Experiencia en banca

Proyectos reales en entornos bancarios críticos.

+1.500% de rendimiento analítico en plataforma de financiación al consumo internacional
+600% de rendimiento en DWH de riesgos de crédito de un grupo bancario global
Arquitectura Data Fabric unificada para banco digital europeo con tiempo real y gobierno reforzado
Resultados con Datum · rangos sin atribución
mejora de rendimiento analítico en DWH de riesgos y reporting
reducción de latencia en procesos de tiempo real
TCO estimado frente al modelo clásico en banca
¿Otro sector?
Cada sector tiene su propio contexto regulatorio y semántico. Explora las demás soluciones sectoriales.
Siguiente paso

Acelera Datum en tu entidad.

Un assessment inicial identifica el punto de partida, el dominio piloto y el modelo de despliegue que mejor encaja.