Model Risk & EUC: van blinde vlek naar beheersing

Het duurste modelrisico van een bank zit zelden in het model dat maandenlang is gevalideerd. Het zit in de Excel-sheet ernaast, die niemand een model durft te noemen.

De blinde vlek

Vraag een risicomanager naar zijn modellen en hij wijst je de inventaris. Kredietrisicomodellen, de VaR-engine, het IFRS 9-provisioningmodel, het interne kapitaalmodel onder Solvency II. Netjes geregistreerd, jaarlijks onafhankelijk gevalideerd, voorzien van een eigenaar en een houdbaarheidsdatum. Daar is over nagedacht, en dat is te merken.

Vraag daarna hoe de cijfers die dat model in gaan tot stand komen, en hoe de uitkomsten worden bewerkt voordat ze op het dashboard van de directie belanden. Nu wordt het stiller. Ergens in die keten zit een spreadsheet. Meestal meer dan één. Gebouwd door een analist die inmiddels een andere functie heeft, onderhouden door wie er toevallig verstand van heeft, opgeslagen op een gedeelde schijf onder een naam als berekening_definitief_v3_echt_finaal.xlsx. Die spreadsheet staat in geen enkele inventaris. Hij is nooit gevalideerd. En hij bepaalt mee wat de bank denkt te weten over haar eigen risico.

Dit is de blinde vlek van model risk management. Het vakgebied heeft de afgelopen vijftien jaar een indrukwekkend bouwwerk opgetrokken rond de modellen die het als model erkent. Ondertussen leeft er een schaduwpopulatie van rekentools die feitelijk hetzelfde doen, invoer omzetten in kwantitatieve schattingen die besluiten sturen, maar die volledig buiten dat bouwwerk valt. End user computing, in het jargon. In gewoon Nederlands: de spreadsheets, macro's en zelfgebouwde tooltjes waarmee de organisatie draait.

Onderzoek naar operationele spreadsheets laat al decennia hetzelfde beeld zien. In negen veldaudits van spreadsheets die in de praktijk voor beslissingen werden gebruikt, bevatte 84 procent van de 163 onderzochte bestanden minstens één fout; beperk je het tot de vijf studies met de strengste methodiek en tel je alleen serieuze fouten, dan is het 91 procent.¹ Niet in een laboratorium, niet bij beginners; in het echte werk, gebouwd door professionals die overtuigd waren van hun eigen nauwkeurigheid. Precies die overtuiging is het probleem. Dit artikel gaat over de kloof tussen wat we een model noemen en wat er feitelijk als model functioneert, over wat die kloof kost, en over hoe je hem dicht.

Wat model risk management eigenlijk regelt

Model risk management is groot geworden in de financiële sector, en wel om een pijnlijke reden: modellen bleken te kunnen liegen met gezag. Voor een Nederlandse bank of verzekeraar is het staand toezicht. De kern is een discipline die inmiddels bekend zou moeten klinken. Elk model doorloopt een levenscyclus: ontwikkeling, implementatie, gebruik, doorlopende monitoring, uiteindelijk uitfasering. Elk model kent een onafhankelijke validatie: iemand die niet de bouwer is, toetst of het model conceptueel deugt, of het doet wat het belooft, en waar het faalt. En elk model staat in een centrale inventaris, met eigenaar, doel en risicoclassificatie.

Twee begrippen dragen het geheel. Het eerste is effective challenge: kritische, onbevooroordeelde tegenspraak door mensen met genoeg gezag, kennis en onafhankelijkheid om een modelbouwer daadwerkelijk te weerstaan. Het tweede is het three lines-denken. De eerste lijn bouwt en gebruikt de modellen. De tweede lijn, modelvalidatie en modelgovernance: challengt onafhankelijk. De derde lijn, internal audit, oordeelt over de vraag of dat hele stelsel werkt.³

Datzelfde stramien is voor instellingen in het eurogebied geen theorie. De Europese Centrale Bank dreef via haar Targeted Review of Internal Models: TRIM, begonnen in 2016 en destijds haar grootste toezichtsproject, de kwaliteit van interne bankmodellen op en drong de ongewenste variatie in risicogewogen activa terug. Dat project is afgerond, maar de verwachtingen zijn gebleven: in haar herziene Guide to internal models vraagt de ECB banken uitdrukkelijk een raamwerk voor modelrisicobeheer in te richten.⁵ Voor verzekeraars regelt Solvency II hetzelfde voor interne kapitaalmodellen: goedkeuring vooraf, doorlopend toezicht, en materiële modelwijzigingen opnieuw ter goedkeuring.⁶ Vlak over de Noordzee ging de Britse toezichthouder PRA nog een stap verder: die maakte het in mei 2024 met SS1/23 expliciet verplicht voor banken, in vijf principes: modelidentificatie en risicoclassificatie, governance, ontwikkeling en gebruik, onafhankelijke validatie, en het mitigeren van restrisico.⁴

En sinds kort reikt de Europese verwachting verder dan de modellen waarvoor een vergunning nodig is. In de herziene SREP-richtsnoeren die de Europese Bankautoriteit in juni 2026 vaststelde en die toezichthouders vanaf 1 januari 2027 toepassen, staat een aparte paragraaf over modelrisico. Die draagt de toezichthouder op het modelrisico te beoordelen “met specifieke aandacht voor interne, niet-regelgevende modellen”, met als voorbeelden AI-modellen, productprijzing, het stellen en bewaken van risicolimieten en de modellen achter ICAAP en ILAAP. Het criterium dat de EBA daarbij aanlegt is de vraag voor welke doeleinden een instelling modellen gebruikt om besluiten te nemen en hoe zwaar die besluiten wegen; waar dat het geval is, hoort er een deugdelijk validatie- of reviewproces te zijn, ook voor modellen zonder toezichtsgoedkeuring.³³ Dat is, in de taal van een toezichthouder, precies de functionele toets waar dit artikel over gaat.

Let nu op wat al die kaders delen, want daar draait dit hele verhaal om. Ze lopen uiteen in reikwijdte, in formulering en in wie ze binden, maar ze willen uiteindelijk hetzelfde weten: verandert dit ding de uitkomst van een besluit? Dat is een functionele vraag, geen technische. Zolang de reikwijdte aan een definitie hangt, gaat de discussie over de naam: heet dit ding een model of een rekenhulp? De schade van een verkeerde uitkomst verandert daar niet door. Onder die blik is een neuraal netwerk een model. En een Excel-sheet die twee getallen tot een risicoschatting verwerkt, óók.

De ECB zegt dat overigens zelf, zij het in een voetnoot. Haar gids voor interne modellen merkt op dat instellingen een effectief raamwerk voor modelrisicobeheer horen te hebben voor alle modellen die in gebruik zijn, om het hoofdstuk dat volgt vervolgens te beperken tot de modellen waarvoor een vergunning geldt.⁵ De verwachting is dus breder dan het hoofdstuk dat haar uitwerkt. En de gids vraagt instellingen om in hun eigen modelbeleid vast te leggen wát bij hen als model telt. Dat is een opmerkelijke opdracht: de instelling bepaalt daarmee zelf hoe groot haar blinde vlek wordt.

Wanneer is een spreadsheet een model?

Hier wringt het. De definitie is breed, maar de praktijk is smal. In veel instellingen stopt de model-inventaris bij de tools die iedereen intuïtief een model noemt: de statistische, de complexe, de door quants gebouwde. De duizenden spreadsheets die diezelfde modellen voeden, corrigeren, aanvullen of vertalen naar rapportage blijven buiten beeld. Ze doen kwantitatief werk dat besluiten stuurt, maar ze staan in geen enkele lijst.

De grens is minder vaag dan hij lijkt. Niet elke Excel is een risico. Een vergaderrooster of een adressenlijst is geen model, hoeveel cellen er ook in staan. Het omslagpunt ligt bij de vraag of het bestand kwantitatieve schattingen of berekeningen produceert die besluitvorming of externe rapportage voeden.⁷ Zodra dat het geval is, is het functioneel een model, of het nu zo heet of niet, en of iemand het ooit heeft gevalideerd of niet.

Vakliteratuur kwalificeert end user computing inmiddels onomwonden als de grootste ongecontroleerde bron van modelrisico bij financiële instellingen.⁸ Onderzoeksbureau Chartis schatte de gezamenlijke "EUC value at risk" voor de vijftig grootste financiële instellingen op meer dan twaalf miljard dollar.⁸ Het gaat dus niet om een randverschijnsel. Het gaat om het deel van de modellenpopulatie dat het grootst is, het minst zichtbaar, en het slechtst beheerst. De reden dat dit lang onopgemerkt bleef, is banaal: het gevalideerde model kreeg de aandacht omdat het een naam had. De spreadsheet eromheen was "gewoon een bestandje".

Wat het kost als je wegkijkt

De geschiedenis van het spreadsheet-incident is rijker dan vaak wordt gedacht, en de bedragen liegen er niet om. Het bekendste geval is de London Whale bij JPMorgan in 2012. Het waarderisicomodel voor een gigantische derivatenpositie draaide via een keten van Excel-bestanden waartussen data met de hand werd gekopieerd. Ergens in die keten deelde een formule door de som van twee volatiliteitsmaten, waar het gemiddelde had gemoeten. Het effect: het model halveerde het gerapporteerde risico. De positie liep uit de hand en kostte de bank uiteindelijk zo'n 6,2 miljard dollar. De opdracht om het model te automatiseren en uit de spreadsheet-keten te halen was gegeven, met een deadline; die werd gemist.⁹

Het is geen incident op zichzelf. In 2003 verloor het Canadese energiebedrijf TransAlta 24 miljoen dollar, ongeveer een tiende van de jaarwinst, doordat gesorteerde rijen in een biedingsspreadsheet verkeerd werden uitgelijnd bij het plakken. Hoge biedingen belandden op de verkeerde contracten, en biedingen konden na indiening niet terug. De president van het bedrijf noemde het letterlijk "een knip-en-plakfout in een Excel-spreadsheet".¹⁰ In datzelfde jaar onderschatte Fannie Mae zijn eigen vermogen met 1,1 miljard dollar door een onjuiste formule bij de implementatie van een nieuwe boekhoudstandaard, een fout die de reviewfase gewoon passeerde.¹¹

Soms zit de fout in wat zichtbaar is. Bij de overname van de resten van Lehman Brothers door Barclays in 2008 converteerde een junior advocaat vlak voor de deadline een Excel-bestand van duizend rijen naar pdf. Verborgen rijen, bewust gemarkeerd als "niet meenemen", werden bij die bewerking weer zichtbaar en daarmee onderdeel van het contract. Barclays kocht zo 179 posities die het niet had willen kopen, ontdekt pas nadat de rechter de deal had goedgekeurd.¹² Vijftien jaar later gebeurde iets vergelijkbaars zonder dat er een transactie aan te pas kwam. De Noord-Ierse politie beantwoordde in augustus 2023 een verzoek om openbaarmaking met een Excel-export uit het personeelssysteem. Daarin zat een tabblad dat niemand had opengeklapt, met naam, rang en standplaats van alle 9.483 medewerkers, en zo belandde dat op een publiek toegankelijke website. Zes medewerkers hadden het bestand voor publicatie in handen gehad. De toezichthouder stelde de boete eerst vast op 5,6 miljoen pond en bracht die met het oog op de publieke sector terug naar 750.000 pond; de werkelijke last lag elders, bij medewerkers die hun thuisbeveiliging aanpasten of moesten verhuizen.³⁰ Buiten de financiële sector veranderde in 2013 een spreadsheetfout zelfs even de wereldpolitiek: in de invloedrijke studie Growth in a Time of Debt van de economen Reinhart en Rogoff was bij het middelen van groeicijfers een aantal landen simpelweg niet in de celselectie meegenomen. Na correctie sloeg de gerapporteerde krimp om in groei, nadat de oorspronkelijke conclusie al als argument voor bezuinigingsbeleid had gediend.¹³

En het stopt niet in het verleden. In 2024 werd bekend dat het Noorse staatsfonds, het grootste ter wereld, zich voor omgerekend zo'n 92 miljoen dollar had verrekend doordat een medewerker in een benchmarkberekening 1 december had ingetypt in plaats van 1 november.¹⁴ En in november 2025 stond de volledige Britse budgetprognose uren voor de speech van de minister op een onbeveiligde link, doordat de bescherming op de website verkeerd was ingesteld; het stuk werd in dat uur 43 keer opgehaald vanaf 32 apparaten, het eigen onderzoek noemde het het zwaarste falen in vijftien jaar en de voorzitter trad af.³¹ En het loopt door tot in het heden: in juni 2026 moest PGIM de intrinsieke waarde van drie obligatie-ETF's met terugwerkende kracht corrigeren nadat de externe administrateur die waarde verkeerd had berekend. Voor het grootste fonds ging de koers van 42,88 naar 42,13 dollar per aandeel, een correctie van 1,75 procent op het getal waarop beleggers die dag hadden gehandeld. Het rekenwerk lag bij de externe administrateur, het risico bleef bij PGIM.³² En in 2020 raakte de Britse gezondheidsdienst bijna 16.000 positieve coronatestuitslagen kwijt omdat resultaten werden ingeladen in een verouderd Excel-formaat met een limiet van 65.536 rijen; alles daaronder viel geruisloos buiten het bestand. Zo'n 50.000 mogelijk besmette contacten werden niet getraceerd, een spreadsheetlimiet met gevolgen voor de volksgezondheid.¹⁵

Twee waarschuwingen bij dit rijtje, want een goede these verdient eerlijke voetnoten. De veelgeciteerde miljoenenzaak rond vermogensbeheerder AXA Rosenberg was géén Excel-incident: primaire bronnen van de Amerikaanse toezichthouder spreken consequent van een coderingsfout in eigen modelsoftware, niet van een spreadsheet. Het is een prima voorbeeld van modelrisico, maar geen EUC-voorbeeld. En "Lehman" is eigenlijk twee verhalen: het bredere falen van Lehmans eigen risicomodellen vóór de val, en de Barclays-spreadsheet ná de val. Alleen het tweede is een spreadsheetincident. Beide horen in het verhaal thuis; de spreadsheet verklaart de val van Lehman niet.

Waarom juist spreadsheets zo verraderlijk zijn

Dat spreadsheets fouten bevatten is een kwestie van statistiek. De onderzoeker Ray Panko bundelde de experimenten waarin ervaren bouwers een spreadsheet vanaf nul opzetten, en vond foutpercentages van ruwweg één tot zes procent per cel-met-formule, met een gemiddelde rond de drie.¹⁶ Dat klinkt beheersbaar, tot je bedenkt dat een spreadsheet uit honderden formules bestaat. Bij een foutkans van enkele procenten per formule is de kans dat een grote spreadsheet érgens een verkeerde einduitkomst produceert juist zeer groot. Vandaar die percentages uit de veldaudits: het logische gevolg van die paar procent per cel zodra je de omvang meerekent.

De fouten zijn bovendien van een soort dat zich slecht laat betrappen. De vakliteratuur onderscheidt vier hardnekkige categorieën, en elk incident hierboven past er precies in. Logicafouten: de verkeerde formule, zoals de som in plaats van het gemiddelde bij JPMorgan. Verwijzingsfouten: een celbereik dat niet meebeweegt bij sorteren of kopiëren, zoals bij TransAlta en Reinhart-Rogoff. Invoerfouten: een verkeerd getal of een verkeerde datum, zoals het Noorse fonds. En versiebeheerfouten: werken in de verkeerde kopie, of een fout die in de ene versie is gerepareerd en in een parallelle kopie blijft rondspoken.

Bij die vier hoort een vijfde die in de praktijk even duur is als een rekenfout: zichtbaarheidsfouten. Het bestand geeft meer prijs of brengt meer mee dan bedoeld, terwijl de uitkomst zelf klopt. De verborgen rijen die bij Barclays weer zichtbaar werden, het tabblad dat bij de Noord-Ierse politie niemand had opengeklapt, de afscherming die bij de Britse begrotingsprognose verkeerd stond. De eerste vier categorieën leiden tot een verkeerd besluit; de vijfde tot schade zonder dat iemand verkeerd heeft gerekend. Een controle die alleen naar formules kijkt, vangt die laatste categorie nooit.

Wat het echt gevaarlijk maakt, is het vertrouwen. Panko's terugkerende bevinding is dat zowel de bouwers als hun organisaties structureel te zeker zijn van de juistheid van hun spreadsheets. Een model met een naam en een validatiestempel wordt met gezond wantrouwen bekeken; een Excel-bestand dat er verzorgd uitziet wordt geloofd. De opmaak wekt de indruk van betrouwbaarheid, terwijl over de logica erachter zelden iemand systematisch de tweede hand heeft gehad. Voeg daarbij dat de kennis vaak in één hoofd zit: het is "het bestand van Jan", en je hebt een model zonder eigenaar, zonder documentatie en zonder houdbaarheidsdatum, dat wél in de besluitvorming meedraait.

Een model is een softwareartefact

Tot hier ging het over de vraag wanneer een spreadsheet een model is. Die vraag is te beantwoorden met een functionele test: verandert dit ding de uitkomst van een besluit? Daarmee staat vast dát het bestand een model is, maar niet wát een model dan is in beheersingstermen. En dat is precies de vraag waar een controller, een risicomanager of een auditor mee verder moet.

Haal de vaktaal weg en er blijft iets heel gewoons over. Een model neemt gegevens in, past er logica op toe en levert een uitkomst waar iemand op vertrouwt. Het is door een persoon gemaakt, het bestaat in versies, het verandert in de tijd, en er zitten aannames in die ooit door iemand zijn gekozen. Dat is de omschrijving van software. Een model gedraagt zich, voor beheersingsdoeleinden, als een softwareartefact: het kent logica, versies, aannames, wijzigingen en afhankelijkheden. Daarmee laten dezelfde disciplines zich erop toepassen als op elk ander stuk software dat de organisatie in bedrijf heeft, in een zwaarte die past bij wat er van de uitkomst afhangt.

Die vergelijking is niet vrijblijvend. Geen enkele organisatie neemt een CRM-systeem in gebruik zonder te weten wie eigenaar is, zonder wijzigingen vast te leggen, zonder scheiding tussen wie bouwt en wie goedkeurt, zonder afspraken over de stamgegevens die erin staan. Bij een rekenbestand dat de voorziening bepaalt of de tarieven vaststelt gebeurt precies dat wel, routineus. Dat gebeurt niet uit onwil: het bestand is nooit als systeem aangemerkt. De disciplines die een organisatie op elk informatiesysteem loslaat, laten zich zonder vertaalslag op een model toepassen.

Discipline	Wat het voor een model betekent	Waar het al genormeerd is
Wijzigingsbeheer	Elke aanpassing van een formule of een aanname is herleidbaar tot wie, wanneer en waarom, en de vorige versie blijft terugvindbaar.	ITGC en COBIT voor systemen; de ICAEW-principes over versiebeheer en back-up voor werkboeken
Documentatie	Doel, reikwijdte, aannames en beperkingen liggen vast, ook als de maker er niet meer is.	SS1/23 en de ECB-gids voor modellen; het toelichtingsblad uit de ICAEW-principes
Functiescheiding	De bouwer keurt niet zelf goed, en de gebruiker van de uitkomst is niet de enige die de logica kent.	Three lines of defence; onafhankelijke validatie in Solvency II en SS1/23
Stamgegevens	De vaste tabellen, parameters en referentiewaarden hebben een bron, een eigenaar en een ritme waarin ze worden ververst.	Datagovernance; artikel 10 van de AI-verordening voor datasets
Invoer	Elke gegevensstroom heeft een herkomst en een controle op volledigheid en juistheid, ook als iemand hem er handmatig in plakt.	Invoercontroles uit de ITGC; de scheiding van invoer en bewerking in de ICAEW-principes en de FAST-standaard
Uitvoer	De uitkomst is reproduceerbaar, de reikwijdte ervan is expliciet, en er is een spoor van wat op welke datum is opgeleverd.	Logging en traceerbaarheid uit de generieke softwarekaders
Validatie	Iemand anders dan de maker toetst of het model doet wat het zegt te doen, met een frequentie die past bij het gewicht van de uitkomst.	ECB-gids, Solvency II en SS1/23 voor interne modellen

De rechterkolom laat meteen het echte probleem zien. Voor elk van deze zeven bestaat al een norm. Alleen staan die normen in vier verschillende werelden, en geen van die vier claimt het rekenbestand van de doorsnee organisatie.

De toezichtkaders zijn het meest volledig. De ECB-gids voor interne modellen, de eisen rond interne modellen onder Solvency II en de Britse SS1/23 dekken de zeven disciplines vrijwel allemaal, inclusief onafhankelijke validatie en een expliciete modelinventaris.⁴ Maar ze gelden voor banken en verzekeraars, en de zwaarste eisen hangen aan de modellen waarvoor een vergunning nodig is. Dat de EBA het toezicht per 2027 uitdrukkelijk uitbreidt naar interne modellen zónder die status is precies de beweging die dit artikel bepleit, maar ze blijft binnen de sector. Voor een woningcorporatie, een ziekenhuis of een middelgrote onderneming bestaat er geen equivalent. Simpelweg omdat er geen toezichthouder is die erom vraagt.

De spreadsheetnormen zitten aan de andere kant van het spectrum: concreet tot op celniveau, maar zonder organisatie eromheen. De twintig principes van de ICAEW voor goed spreadsheetgebruik, in 2024 herzien, schrijven voor dat invoer, bewerking en uitvoer strikt gescheiden en herkenbaar zijn, dat er een toelichtingsblad in het bestand zit, dat niets wat ooit kan veranderen in een formule wordt vastgeschreven, en dat er versiebeheer, tests en ingebouwde controles zijn.²⁵ De FAST-standaard doet hetzelfde vanuit de ontwerpkant, met flexibel, passend, gestructureerd en transparant als leidraad.²⁶ De European Spreadsheet Risk Interest Group verzamelt al ruim vijfentwintig jaar het onderzoek en de praktijkervaring erachter.²⁷ Het zijn uitstekende bouwvoorschriften. Wat ze niet regelen is wie goedkeurt, wie valideert en wie eigenaar is. De organisatorische helft ontbreekt, en juist daar zit het risico.

De generieke software- en IT-kaders regelen die helft wél. ISO/IEC/IEEE 12207 beschrijft de levenscyclus van software, van verwerving tot afvoer; ISO/IEC 25010 beschrijft de kwaliteitseigenschappen waarop een product te meten valt; en de klassieke ITGC-indeling in wijzigingsbeheer, logische toegang en IT-operations hoort bij de standaard jaarrekeningcontrole.²⁸ Alleen worden ze zelden op een spreadsheet losgelaten. Het bestand staat niet in de applicatieportefeuille, het heeft geen beheerorganisatie, en het valt daarmee buiten de reikwijdte die de IT-auditor krijgt aangereikt. Het kader bestaat; de scope sluit het uit.

De AI-kaders ten slotte zijn de nieuwste en de best gefinancierde. ISO/IEC 42001 vraagt om een managementsysteem rond AI, het NIST AI Risk Management Framework ordent het werk in besturen, in kaart brengen, meten en beheersen, en de AI-verordening stelt harde eisen aan datakwaliteit, technische documentatie, logging en menselijk toezicht.²⁹ Ze raken dezelfde zeven disciplines. Maar ze richten zich per definitie op systemen die leren of afleiden. Een deterministisch rekenmodel valt buiten de definitie van een AI-systeem waarmee de verordening werkt, en daarmee buiten haar reikwijdte, hoe zwaar de uitkomst ook weegt. Dat is geen oordeel over het risico. Het is de afbakening van een ánder classificatiestelsel, dat naast het modelbegrip staat in plaats van erin te passen, en dat verklaart waarom je een kritisch rekenbestand tevergeefs in de AI-verordening zoekt.

Wat overblijft is een dekkingsprobleem. De strengste eisen liggen bij de sector die het risico toch al ziet, de scherpste bouwvoorschriften missen een eigenaar, de breedste kaders kijken langs het bestand heen, en de nieuwste kaders sluiten juist het type model uit dat het vaakst voorkomt. Buiten de financiële sector rust modelbeheersing dus op eigen initiatief. Dat verklaart waarom het zo weinig gebeurt. Het maakt de opgave niet groter, wel eenzamer: er is geen toezichtbrief die het werk afdwingt, dus moet de organisatie het zelf willen.

Al beweegt die grens, en wel in twee richtingen tegelijk. Waar de Amerikaanse toezichthouder de spreadsheet in 2026 uitdrukkelijk buiten de definitie van een model zette, trekt de Europese het toezicht juist naar de modellen zónder vergunning toe. Twee toezichthouders, dezelfde vraag, tegengestelde antwoorden. Dat bewijst vooral dat de definitie van een model een keuze is en geen natuurwet, en dat een organisatie die haar beheersing op die definitie bouwt, haar op drijfzand bouwt.

Van blinde vlek naar beheersing

Het goede nieuws is dat je hier niet met een nieuwe wetenschap begint. De discipline om modellen te beheersen bestaat al; ze hoeft alleen te worden uitgebreid naar de tools die tot nu toe buiten bereik bleven. Dat gaat in vier bewegingen.

Eerst zien wat je hebt. Je kunt niet beheersen wat je niet kent, en organisaties hebben vaak geen idee hoeveel bedrijfskritische spreadsheets er rondgaan. Een discovery- en inventarisatieronde legt ze vast: eigenaar, afdeling, welk proces ze voeden, en hoe kritisch ze zijn.¹⁷ Dit is meestal het confronterende deel, organisaties vinden er stelselmatig meer dan verwacht, en juist de belangrijkste zijn vaak het slechtst gedocumenteerd.

Dan prioriteren. Niet elke spreadsheet verdient dezelfde aandacht, en doen alsof leidt tot een controleprogramma dat onder zijn eigen gewicht bezwijkt. Classificeer op twee assen: materialiteit, wat is de financiële of rapportage-impact als het misgaat, en complexiteit, hoeveel formules, koppelingen en macro's zitten erin.¹⁸ Een simpele sheet met grote impact verdient meer aandacht dan een ingewikkelde zonder gevolgen. Deze indeling naar risiconiveau maakt het verschil tussen een programma dat werkt en een dat verzandt in het beheersen van onbelangrijke bestanden.

Vervolgens beheersen. Op de tools die er echt toe doen, leg je gerichte maatregelen. Invoercontroles die onmogelijke waarden weren. Verificatie van de formules zelf, over tabbladen en koppelingen heen. Versie- en wijzigingsbeheer, zodat een aanpassing wordt getest en goedgekeurd in plaats van stilletjes doorgevoerd. Toegangsbeheer en functiescheiding, zodat de opsteller niet ook de enige controleur is. Documentatie van doel en aannames. En reconciliatie: sluit de uitkomst aan op een bronsysteem of een controlegetal.¹⁹

Ten slotte valideren. Voor de zwaarste categorie, de spreadsheets die feitelijk kernmodellen zijn, is er geen reden om lichtere eisen te stellen dan aan een "echt" model. De beproefde principes van modelvalidatie laten zich rechtstreeks toepassen: is de opzet conceptueel gezond, kloppen de uitkomsten bij het terugtoetsen, houdt het stand tegen een benchmark?²⁰ Een spreadsheet in deze categorie hoort dezelfde validatie te doorlopen als een model.

De beheersing moet meegroeien met de afhankelijkheid

Classificeren op materialiteit en complexiteit vertelt je hoe zwaar een bestand technisch weegt. Maar er is een tweede vraag die vaak scherper snijdt, en die de eigenaar zelf het beste kan beantwoorden: hoezeer leunt een besluit op dit ding? Laat de business dat bij de inventarisatie verklaren. Geeft het model alleen inzicht, zonder dat er een beslissing aan hangt? Is het één van meerdere inputs, een mede-basis? Of volgt een beslissing er rechtstreeks uit, zodat het de enige basis is? Die zelfverklaarde afhankelijkheid zegt vaak meer over het werkelijke risico dan welk technisch kenmerk ook.

Er is nog een derde vraag, en die wordt het vaakst overgeslagen: hoe hard beweegt het bestand? Een model dat eenmaal per jaar draait en er de rest van het jaar bevroren bij staat, is iets anders dan een model dat wekelijks wordt bijgesteld, door vijf mensen wordt bewerkt en telkens nieuwe aannames krijgt. Elke wijziging is een nieuwe kans op een fout, en juist versiebeheerfouten ontstaan waar veel handen aan hetzelfde bestand zitten. Een eenvoudige spreadsheet die elke week verandert kan daardoor meer risico dragen dan een ingewikkelde die stilstaat, terwijl de eerste op materialiteit en complexiteit lager scoort. Classificatie telt daarom drie dingen: wat het bestand weegt, waar de beslissing op rust, en hoe vaak het ding verandert.

Zet die afhankelijkheid af tegen de mate waarin het bestand daadwerkelijk beheerst wordt, en je krijgt een kaart die meteen laat zien waar het wringt (figuur 2). De verticale as loopt met het risico mee, dus bovenaan staat de ongecontroleerde privé-EUC: geen benoemde eigenaar, geen versiebeheer, het bestand van Jan. In het midden de managed EUC, met basiswaarborgen; een eigenaar, toegangsbeperking, review, eenvoudig versiebeheer. Onderaan de controlled application: een volwaardig softwareregime met change management, versiebeheer, geautomatiseerd testen en gecontroleerde deployment (DevOps).

De regel die eruit volgt is kort: hoe meer een beslissing op een model rust, hoe zwaarder het beheersingsregime dat erbij hoort. Een spreadsheet dat alleen een grafiek kleurt mag een privé-EUC blijven, dat is proportioneel. Maar zodra een besluit er rechtstreeks uit volgt, hoort het in het controlled-regime, niet in een Excel-bestand op een gedeelde schijf. De gevaarlijke hoek is die rechtsboven, waar volledige afhankelijkheid samenvalt met nauwelijks beheersing. Dat is geen theoretisch geval: de London Whale bracht precies die combinatie samen, tot en met het uitblijven van effectieve tegenspraak.

Het auditperspectief

Voor internal audit is dit een dankbaar terrein, juist omdat het zo lang is overgeslagen. De derde lijn oordeelt niet over de juistheid van elke afzonderlijke spreadsheet, dat is werk voor de eerste en tweede lijn, maar over de vraag of er überhaupt een stelsel is dat de EUC-populatie in de gaten houdt. Het risicogebaseerde auditprogramma volgt de logische keten: bestaat er een inventaris, worden bestanden geclassificeerd, en hangen aan de kritische exemplaren daadwerkelijk controles?²¹

De concrete teststappen zijn herkenbaar voor wie IT general controls kent. Toegang: wie kan bij het bestand, en is dat nodig? Data-integriteit: zijn er invoercontroles, of kan elke waarde erin? Berekeningen: kloppen de formules bij onafhankelijke natelling, ook op de verborgen tabbladen? Wijzigingsbeheer: hoe worden aanpassingen vastgelegd, getest en goedgekeurd? De bevindingen zijn even herkenbaar, en ze keren organisatie na organisatie terug. Bedrijfskritische bestanden die nergens geregistreerd staan. Geen functiescheiding tussen wie de sheet bouwt en wie erop steunt. En een handvol parallelle versies die allemaal "definitief" heten.

Het zwaartepunt van dit artikel ligt bij banken en verzekeraars, omdat het toezicht daar het scherpst is en de bedragen het grootst zijn. De mechaniek is daarmee nog niet bancair. In een woningcorporatie, een zorginstelling of een middelgroot bedrijf gelden de ECB-gids en Solvency II niet. De vraag zelf blijft staan. Juist waar geen toezichthouder een modelinventaris afdwingt, is er ook niemand die hem stelt. Toch komt hij binnen langs een andere deur. De accountant kijkt onder de herziene controlestandaarden naar de IT-toepassingen en de end user computing in de keten die de jaarrekening voedt, en een spreadsheet die de vastgoedwaardering of de onderhoudsvoorziening bepaalt is precies zo'n toepassing. De raad van commissarissen vraagt waarop een investeringsbesluit rust. En zodra een model meebeslist over mensen, huurders, cliënten of kandidaten, ligt de AI Act klaar. Het verschil met de bank is niet dat het risico kleiner is. Het verschil is dat niemand het voor je heeft opgeschreven.

De horizon verschuift - en de blinde vlek verplaatst zich

Dit hoofdstuk is niet afgesloten. Het landschap beweegt snel, en wel op een manier die het punt van dit artikel eerder onderstreept dan ontkracht. Van de ene kant komt er regelgeving bij, en die is deze keer Europees. De EU AI Act trad op 1 augustus 2024 in werking en geldt gefaseerd: de verboden praktijken en de eis van AI-geletterdheid sinds februari 2025, de regels voor AI voor algemene doeleinden sinds augustus 2025, en sinds 2 augustus 2026 het merendeel van de verplichtingen, handhaving inbegrepen. De hoogrisico-categorieën uit Annex III, waaronder de kredietwaardigheidsbeoordeling van particulieren, volgen per 2 december 2027.²³ Daarmee stapelt de verordening documentatie-, toezicht- en transparantie-eisen bovenop de bestaande modelkaders. En de aard van het modelrisico zelf verschuift. Generatieve AI introduceert risico's, hallucinatie, ondoorgrondelijkheid; die de klassieke kaders niet dekten.

Van de andere kant beweegt er iets opvallends met de regels zelf, en dat gebeurt buiten de EU. De Amerikaanse toezichthouder die de standaard ooit zette, scherpte hem onlangs aan.²² De nieuwe versie is op papier verstandiger: meer op risico gericht, minder een one-size-fits-all, maar met één pikant gevolg. De definitie van wat officieel een model mag heten wordt strikter, en de nieuwe tekst zegt met zoveel woorden dat het begrip model “eenvoudige rekenkundige berekeningen, zoals die binnen spreadsheets” uitsluit, evenals deterministische, regelgebaseerde processen zonder statistische, economische of financiële theorie eronder. De toezichthouder noemt de spreadsheet dus bij naam, om hem buiten de deur te zetten. Juist de categorie waar veel kritische rekentools in vallen, glipt daarmee buiten de formele regel. Veelzeggend genoeg houdt diezelfde richtlijn ook generatieve en agentic AI uitdrukkelijk buiten haar reikwijdte, met als motivering dat die techniek nieuw is en snel verandert. Dat alles bindt een Nederlandse instelling formeel niet, en juist daarom is het leerzaam. De les is bestuurlijk. Of iets nu officieel een model heet of niet: het risico verandert er niet door. Kritische spreadsheets verdienen die aandacht voordat een voorschrift erom vraagt. Governance hoort niet te stoppen waar de compliance-tekst ophoudt.

Het belangrijkste is misschien wel dit: de blinde vlek verplaatst zich, maar verdwijnt niet. Waar het gisteren Excel was, is het vandaag het low-code- en no-code-platform waarmee medewerkers zonder één regel code hun eigen applicaties bouwen. Gartner voorspelde dat in 2025 zeventig procent van alle nieuwe bedrijfsapplicaties met low-code- of no-codetechnologie gebouwd zou worden, tegen minder dan een kwart in 2020, terwijl in enquêtes een ruime meerderheid van de organisaties toegeeft daar nog geen governance op te hebben.²⁴ Het is end user computing in een nieuw jasje: dezelfde dynamiek van goedbedoelde zelfredzaamheid die aan elk toezicht ontsnapt. De namen veranderen: spreadsheet, script, citizen-developed app, maar het patroon is telkens hetzelfde.

Waar het echt om draait

Model risk management is volwassen geworden rond de modellen die het als model herkent. De volgende stap in die volwassenheid is te erkennen dat de definitie van "model" altijd om de functie draait, niet om de vorm. Bepalend is de simpele vraag of een fout in dat ding een verkeerd besluit kan veroorzaken, ongeacht de statistische zwaarte, het label op het tabblad, of er een quant aan te pas kwam.

De echte toets voor een organisatie is daarom niet hoe dik het validatierapport van het vlaggenschipmodel is. Het is of iemand de vraag kan beantwoorden welke spreadsheets het bedrijf feitelijk besturen, en of aan díe bestanden dezelfde discipline hangt als aan de modellen die wél een naam hebben. Zolang dat antwoord er niet is, is de duurste fout van de organisatie niet de fout die je hebt gevalideerd. Het is de fout die je nooit een model hebt durven noemen.

Literatuur en bronnen

Bronverwijzingen

1. Panko, R. Audits of Operational Spreadsheets. University of Hawaii. Negen veldaudits (1995-2008) van 163 operationele spreadsheets vonden fouten in 84% (gewogen gemiddelde); bij de vijf studies met de strengste methodiek, alleen serieuze fouten geteld, 91% van 55. De oudere en veelgeciteerde bevinding “94% van 88 spreadsheets in zeven studies” komt uit Panko’s eerdere overzicht en is door hemzelf herzien. panko.com
2. Board of Governors of the Federal Reserve System & OCC (2011). Supervisory Guidance on Model Risk Management (SR 11-7 / OCC Bulletin 2011-12). Gepubliceerd 4 april 2011. federalreserve.gov
3. Yields.io (2023). The Three Lines of Defence in Model Risk Management. yields.io
4. Bank of England / PRA (2023). SS1/23, Model risk management principles for banks. Van kracht per 17 mei 2024. bankofengland.co.uk
5. Europese Centrale Bank (2021). Targeted Review of Internal Models (TRIM), Project report. bankingsupervision.europa.eu. Staande verwachtingen: ECB, Guide to internal models (meest recente versie juni 2026), met een expliciete paragraaf over het inrichten van een raamwerk voor modelrisicobeheer. Voetnoot 15 bij hoofdstuk 4 stelt dat instellingen een effectief raamwerk voor modelrisicobeheer horen te hebben “for all models in use”, waarna het hoofdstuk zich beperkt tot de goedgekeurde interne modellen; paragraaf 12(a) vraagt de instelling in haar eigen beleid vast te leggen wat bij haar als model geldt. Guide to internal models (juni 2026)
6. EIOPA. Solvency II, Internal models (art. 120-125). eiopa.europa.eu
7. Apparity. Model Risk Management & The Elephant in the Room. apparity.com
8. Mitratech (ClusterSeven). End User Computing Risk Management, o.a. Chartis-schatting "EUC value at risk" > $12 mrd voor de 50 grootste financiële instellingen. mitratech.com
9. US Senate Permanent Subcommittee on Investigations, JPMorgan Chase Whale Trades: A Case History of Derivatives Risks and Abuses (2013), het onderzoeksrapport en de hoorzitting van 15 maart 2013. Verlies ~$6,2 mrd; het model werd gevoed via een keten van spreadsheets waartussen met de hand werd gekopieerd, en een formule deelde door de som in plaats van het gemiddelde van twee hazard rates. govinfo.gov. Toegankelijke samenvattingen: Groenfeldt, T., Solutions To Spreadsheet Risk Post JPM’s London Whale, Forbes (2013); Revolution Analytics, Did an Excel error bring down the London Whale? (2013)
10. The Register (2003). Excel snafu costs firm $24m (TransAlta). theregister.com
11. Full Stack Modeller. The Fannie Mae Spreadsheet Error, onderschatting eigen vermogen ~$1,1 mrd (2003). Secundaire bron: de correctie is destijds door Fannie Mae zelf bekendgemaakt bij de derdekwartaalcijfers van 2003. Niet te verwarren met de latere, veel grotere herwaardering uit het OFHEO-onderzoek (2006), die opzettelijke resultaatsturing betrof en geen rekenfout. fullstackmodeller.com
12. The Register (2008). Lehman Excel snafu could cost Barclays dear; AccountingWEB, Hidden spreadsheet rows hit Barclays with toxic Lehman contracts. theregister.com
13. Bloomberg (2013). FAQ: Reinhart, Rogoff, and the Excel Error That Changed History. bloomberg.com
14. Financial Times (februari 2024), The Norwegian sovereign wealth fund’s $92mn Excel error: een fout in de berekening van de mandaatbenchmark (verkeerde datum, 1 december i.p.v. 1 november) leidde tot een neerwaartse correctie van circa NKr 980 miljoen. Samengevat met bronvermelding door spreadsheetrisico-vakblad i-nth. i-nth.com
15. Daring Fireball / Office Watch (2020). Excel row limit caused loss of 16,000 COVID test results in England, .XLS-limiet van 65.536 rijen; ~50.000 contacten niet getraceerd. office-watch.com
16. Panko, R. Spreadsheet Development Error Experiments. Laboratoriumexperimenten waarin deelnemers een spreadsheet vanaf nul bouwen: gerapporteerde cell error rates van 1,1% tot 5,6%, gemiddeld circa 3,2%. panko.com
17. KPMG UK (2022). Our Approach to Managing the Risk of End User Computing (EUC). kpmg.com
18. Apparity. Building a Spreadsheet Risk Assessment Model, indeling naar risiconiveau op basis van materialiteit en complexiteit. apparity.com
19. Mitratech. The Ultimate End User Computing Checklist; soxmadeeasy, EUC Applications; Audit Programs. mitratech.com
20. RiskSpan. Mitigating EUC Risk Using Model Validation Principles. riskspan.com
21. soxmadeeasy. End User Computing (EUC) Applications, Audit Programs. soxmadeeasy.com
22. Federal Reserve (2026). SR 26-2: Revised Guidance on Model Risk Management (OCC Bulletin 2026-13); Sullivan & Cromwell memo. Vervangt SR 11-7 (2011). De nieuwe definitie beperkt “model” tot een complexe kwantitatieve methode en sluit letterlijk uit: “simple arithmetic calculations, such as those found within spreadsheets, as well as deterministic rule-based processes and software where there are no statistical, economic, or financial theories underpinning their design or use”. Voetnoot 3 plaatst generatieve en agentic AI buiten de reikwijdte. federalreserve.gov
23. Europese Commissie, Timeline for the Implementation of the EU AI Act (geraadpleegd augustus 2026): inwerkingtreding 1 augustus 2024; verboden praktijken en AI-geletterdheid vanaf 2 februari 2025; AI voor algemene doeleinden vanaf 2 augustus 2025; merendeel van de verplichtingen en handhaving vanaf 2 augustus 2026; hoogrisicosystemen uit Annex III, waaronder kredietwaardigheidsbeoordeling van particulieren, vanaf 2 december 2027. ec.europa.eu
24. Gartner-prognose (2021): 70% van de nieuwe bedrijfsapplicaties wordt in 2025 met low-code- of no-codetechnologie gebouwd, tegen minder dan 25% in 2020. Het cijfer is een voorspelling, geen gemeten uitkomst. Voor het governance-tekort: KPMG-enquête EMEA, samengevat door TXMinds, Low-code governance and citizen development. txminds.com
25. ICAEW. Twenty principles for good spreadsheet practice. Herziene editie 2024. Onder meer: scheiding van invoer, bewerking en uitvoer; een toelichtingsblad in het werkboek; niets vastschrijven in een formule dat kan veranderen; back-up en versiebeheer; testen en ingebouwde controles. icaew.com
26. The FAST Standard Organisation. The FAST Standard, versie 02c (juli 2019). FAST staat voor flexible, appropriate, structured, transparent; de regels betreffen werkboekopbouw, werkbladopbouw en regelontwerp. fast-standard.org
27. European Spreadsheet Risk Interest Group (EuSpRIG). Research and Best Practice. Bibliotheek van ruim tweehonderd onderzoekspapers over spreadsheetrisico, opgebouwd sinds eind jaren negentig. eusprig.org
28. ISO/IEC/IEEE 12207:2017, Systems and software engineering, Software life cycle processes, en ISO/IEC 25010:2023, Product quality model (negen kwaliteitseigenschappen, waaronder betrouwbaarheid, beveiliging en onderhoudbaarheid). Voor de beheersingskant: COBIT en de gangbare ITGC-indeling in wijzigingsbeheer, logische toegang en IT-operations. iso.org
29. ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system, en NIST, AI Risk Management Framework 1.0 (2023) met de vier functies govern, map, measure en manage. De AI-verordening stelt de eisen aan datagovernance (artikel 10), technische documentatie, logging en menselijk toezicht voor hoogrisicosystemen. iso.org · nist.gov
30. Information Commissioner's Office (2024). Penalty Notice: Police Service of Northern Ireland, 26 september 2024. Boete 750.000 pond (oorspronkelijk bepaald op 5,6 mln), 9.483 betrokkenen, incident 8 augustus 2023. ico.org.uk
31. Office for Budget Responsibility (2025). Report of investigation into the November 2025 Economic and fiscal outlook publication error, 1 december 2025. obr.uk
32. PGIM (2026). PGIM Announces Net Asset Value Restatement for Three Exchange-Traded Funds (PAB, PSDM, PTRB), persbericht 2 juni 2026. NAV van 29 mei 2026 herzien op 1 juni 2026 na een rekenfout bij de externe fondsadministrateur. businesswire.com
33. European Banking Authority (2026). Guidelines (revised) on common procedures and methodologies for the supervisory review and evaluation process (SREP) and supervisory stress testing (EBA/GL/2026/06), vastgesteld 26 juni 2026, van toepassing vanaf 1 januari 2027; vervangt EBA/GL/2022/03 en EBA/GL/2017/05. Sectie 6.4.2.2 (Model risk), paragrafen 210-213: toezichthouders beoordelen modelrisico onder het operationeel risico “with specific regard to internal non-regulatory models (e.g. AI models, product pricing, setting and monitoring risk limits, ICAAP/ILAAP models, recovery options)”, en toetsen bij modellen die voor besluitvorming worden gebruikt of er een deugdelijk validatie- of reviewproces is “(other than regulatory models)”. eba.europa.eu

← Terug naar Publicaties