Het is één ding om te stellen dat BCBS 239 en een metadata-framework elkaar versterken. Het is iets anders om dat in de praktijk te realiseren in een organisatie met legacy-systemen, meerdere databronnen en teams die niet altijd dezelfde taal spreken.
In dit artikel beschrijf ik de aanpak die ik hanteer om die brug te slaan. Ik laat zien hoe je van een regulatoire eis naar een werkend metaframework komt dat ook over twee jaar nog klopt.
Stap 1: Vertaal de principes naar concrete metadata-verplichtingen
BCBS 239 spreekt over “accurate, complete en tijdige data”. Dat klinkt helder, maar het zegt nog niets over wat er vastgelegd moet worden. De eerste stap is die vertaalslag maken.
Per risicodata-object, zoals een kredietpositie, een tegenpartijlimiet of een ESG-score, bepaal je welke metadata verplicht is. Ik gebruik daarvoor een eenvoudig model met drie niveaus:
| Niveau | Metadata-type | Voorbeelden |
|---|---|---|
| Business | Definitie, eigenaar, classificatie | ”Wat is dit attribuut?” / “Wie is verantwoordelijk?” |
| Technisch | Formaat, bron, validatieregel | ”Wat is het datatype?” / “Hoe wordt het gevalideerd?” |
| Operationeel | Lineage, kwaliteitsscore, tijdstempel | ”Waar komt het vandaan?” / “Was de laatste run succesvol?” |
De combinatie van deze drie niveaus maakt het mogelijk om elke BCBS 239-vraag te beantwoorden zonder handmatig speurwerk.
Stap 2: Leg governance vast voordat de tooling wordt gekozen
De meestgemaakte fout in metadata-trajecten is dat de toolkeuze voorafgaat aan het governance-model. Men kiest een catalogus, bijvoorbeeld Microsoft Purview, Collibra of Atlan, en verwacht dat de governance vanzelf volgt. Dat werkt niet.
Wat wél werkt: bepaal eerst wie welke metadata aanlevert, beheert en accordeert. Typische rollen in een financiële context:
- Data owner: verantwoordelijk voor business metadata en classificatie
- Data steward: dagelijks beheer van definities, validatieregels en wijzigingen
- Platformteam: automatische inname van technische en operationele metadata via pipelines
- Risk & Compliance: afname van metadata voor toezichtsrapportages
Als dit niet helder is, wordt de catalogus een kerkhof van verouderde definities die niemand meer vertrouwt.
Stap 3: Zorg dat lineage geen nagedachte is
BCBS 239 principe 2 en 6 vragen informatie over de herkomst van data en over de mogelijkheid om rapportages flexibel aan te passen. Beide vereisen end-to-end lineage, van bronsysteem tot toezichtsrapportage.
Lineage werkt alleen als het by design is ingebakken. Praktisch betekent dat:
- Datacontracten tussen producent en consument leggen de verwachte structuur en kwaliteit vast
- Pipeline-orchestratie (Databricks, dbt, Azure Data Factory) legt automatisch run-metadata per stap vast
- Medallion-architectuur geeft elke laag (bron → verrijkt → gecureerd) een expliciete kwaliteitsstatus
Lineage die handmatig bijgehouden wordt in een Excel of een wiki, is bij de eerste reorganisatie verouderd.
Het resultaat: van snapshot naar levend systeem
Een metadata-framework dat BCBS 239 serieus ondersteunt is geen eenmalig project. Het is een levend systeem dat meebeweegt met de organisatie. Nieuwe dataproducten krijgen direct verplichte metadata mee, nieuwe business owners worden opgenomen in het stewardship-model en toezichtsvragen zijn te beantwoorden met een query in plaats van met een taskforce.
Dat vraagt investering in ontwerp, governance en cultuur. Het alternatief is dat je bij elke audit opnieuw handmatig moet aantonen dat de data klopt. Dat is structureel duurder en kwetsbaarder.
De route van BCBS 239 naar een werkend metaframework begint niet bij de toolkeuze. Die begint bij de vraag: wat moeten we eigenlijk weten over onze data, en wie is daarvoor verantwoordelijk?