Wanneer toezichthouders spreken over BCBS 239, klinkt het al snel als een compliance-vraagstuk: een checklist die je afwerkt voor de volgende DNB-review. Maar wie de veertien principes goed leest, ziet iets fundamentelers. BCBS 239 is in de kern een set eisen aan de kwaliteit, traceerbaarheid en beheersing van data. Precies daar draait een goed metadata-framework om.
Wat vraagt BCBS 239 eigenlijk?
De Basel Committee on Banking Supervision publiceerde in 2013 de principes voor effectieve risicodata-aggregatie en risicorapportage. De kern:
- Principe 2 – Datakwaliteitsborging: risicodata moet accuraat, volledig en tijdig zijn, en de bank moet kunnen aantonen hoe die kwaliteit geborgd is.
- Principe 3 – Volledigheid: alle relevante risicogegevens moeten beschikbaar zijn, ook over entiteiten, business lines en geografieën heen.
- Principe 4 – Tijdigheid: aggregatie moet snel en betrouwbaar mogelijk zijn, ook in stresstijden.
- Principe 6 – Aanpasbaarheid: rapportages moeten flexibel aanpasbaar zijn op verzoek van het management.
Dit zijn geen IT-eisen. Het zijn eisen aan de architectuur van data.
Waar metadata-frameworks het verschil maken
BCBS 239 veronderstelt stilzwijgend dat een bank weet welke data er is, waar het vandaan komt, wie er verantwoordelijk voor is, en hoe betrouwbaar het is. Zonder metadata-framework is dat onmogelijk te beantwoorden.
Neem principe 2: datakwaliteitsborging. Om aan te tonen dat risicodata accuraat is, moet je drie dingen kunnen laten zien:
- Wat de definitie is van elk risicoattribuut (business metadata)
- Hoe de data tot stand is gekomen van bronregistratie tot rapportage (operationele metadata / lineage)
- Wat de kwaliteitsregel is en wat de uitkomst was van de laatste validatierun (technische + operationele metadata)
Zonder een gestructureerd metadata-framework is elk van die drie vragen een handmatig speurwerk. Met een framework is het een query.
De praktijk bij financiële instellingen
Bij een opdracht in de financiële sector, gericht op het BCBS 239-compliant maken van ESG-dataproducten, bleek het grootste probleem niet de tooling. De platformen waren aanwezig: Databricks, een data vault en Azure Purview als catalogus. Het probleem was dat niemand had nagedacht over welke metadata per dataset verplicht was, wie die moest aanleveren en hoe het beheer moest veranderen wanneer de context veranderde.
De oplossing begon niet met een tool-configuratie, maar met een conceptueel model:
- Welke metadata-attributen zijn verplicht voor elk risicodata-object?
- Wie is de business owner, en wat is zijn/haar verantwoordelijkheid?
- Hoe wordt lineage automatisch vastgelegd in de pipeline, niet handmatig gedocumenteerd achteraf?
Pas na die conceptuele stap konden we de technische implementatie doen die daadwerkelijk standhield bij een toezichtsvraag.
BCBS 239 als architectuureis, niet als compliance-oefening
Organisaties die BCBS 239 als checklist behandelen, komen er vaak wel doorheen, maar bouwen geen duurzame beheersing op. Organisaties die het als architectuureis benaderen, bouwen iets wat ook bij de volgende toezichtsronde, de volgende fusie of de volgende strategische heroriëntatie standhoudt.
Het verschil zit niet in het budget of de toolkeuze. Het zit in de vraag of metadata een architectuurprincipe is of een bijproduct.
Een metadata-framework maakt van BCBS 239 geen last, maar een leidraad. Precies zo is het bedoeld.