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. Van 88 spreadsheets die in de praktijk voor beslissingen werden gebruikt, bevatte 94 procent minstens één fout.1 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. In 2011 publiceerden de Amerikaanse Federal Reserve en de OCC de toezichtsrichtlijn SR 11-7, tot voor kort het referentiekader wereldwijd.2 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 niet over de modellen zelf, maar over de vraag of dat hele stelsel werkt.3
Datzelfde stramien keert overal terug. De Britse toezichthouder PRA 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.4 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.5 Voor verzekeraars regelt Solvency II hetzelfde voor interne kapitaalmodellen: goedkeuring vooraf, doorlopend toezicht, en materiële modelwijzigingen opnieuw ter goedkeuring.6
Let op één detail in de oorspronkelijke definitie van SR 11-7, want daar draait dit hele verhaal om. Een model is "een kwantitatieve methode, systeem of benadering die statistische, economische, financiële of wiskundige theorieën en technieken toepast om invoergegevens te verwerken tot kwantitatieve schattingen". Bewust breed geformuleerd. Onder die definitie is een neuraal netwerk een model. En een Excel-sheet die twee getallen tot een risicoschatting verwerkt, óók.
Wanneer is een spreadsheet een model?
Hier wringt het. De definitie is breed, maar de praktijk is smal. In de meeste 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.7 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.
De test in één vraag
Zou een fout in dit bestand tot een verkeerd besluit, een onjuiste rapportage of een financieel verlies kunnen leiden? Is het antwoord ja, dan is het bestand een model in de zin die ertoe doet — ongeacht wat de model-inventaris zegt. De naam op het tabblad is niet de grens; de gevolgen van een fout zijn dat wel.
Vakliteratuur kwalificeert end user computing inmiddels onomwonden als de grootste ongecontroleerde bron van modelrisico in de meeste financiële instellingen.8 Onderzoeksbureau Chartis schatte de gezamenlijke "EUC value at risk" voor de vijftig grootste financiële instellingen op meer dan twaalf miljard dollar.8 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 de meeste risicomanagers denken, 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.9
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".10 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.11
Soms is de fout niet in de rekenlogica, maar 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.12 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.13
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.14 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.15
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. Wie deze nuances laat staan, houdt het verhaal geloofwaardig — en dat is precies wat een risicomanager van zijn eigen cijfers ook zou moeten eisen.
Waarom juist spreadsheets zo verraderlijk zijn
Dat spreadsheets fouten bevatten is geen kwestie van slordigheid, maar van statistiek. De onderzoeker Ray Panko bundelde dertien studies naar operationele spreadsheets en vond een gemiddeld foutpercentage van ruwweg 5 procent per cel-met-formule.16 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 niet klein, maar juist zeer groot. Vandaar die 94 procent uit de veldaudits: geen tegenspraak met de 5 procent, maar het logische gevolg ervan 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.
Wat het echt gevaarlijk maakt, is niet de fout maar 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.
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 de meeste organisaties hebben 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.17 Dit is bijna altijd 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.18 Een simpele sheet met grote impact verdient meer aandacht dan een ingewikkelde zonder gevolgen. Deze tiering 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.19
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?20 Wie een spreadsheet als model behandelt, valideert hem als 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.
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). Onderaan de ladder 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. Bovenaan 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 hoger het in de beheersingsladder thuishoort. 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 rechtsonder, waar volledige afhankelijkheid samenvalt met nul beheersing. Dat is geen theoretisch geval: daar zat de London Whale.
Waar tooling wel en niet helpt
Er is een volwassen markt van EUC-beheerplatforms — Mitratech ClusterSeven, Apparity, CIMCON, Incisive — die spreadsheets, Access-databases en tegenwoordig ook Python- en R-scripts automatisch ontdekken, wijzigingen volgen en risico's scoren. Nuttig, en op schaal (denk aan SOX-omgevingen met tienduizenden bestanden) onmisbaar. Maar tooling vervangt de governance niet; ze voert haar uit. Een platform dat elke wijziging logt zonder dat iemand op de bevindingen acteert, produceert vooral een keurig gedocumenteerde blinde vlek.
Dit is precies waar Modelio voor gebouwd is
De vijfslag hierboven, inventariseren, classificeren, beheersen, valideren en borgen, is het uitgangspunt van Modelio, het EUC- en modelregister van Audirium. Elke spreadsheet, elk model en elke zelfgebouwde tool krijgt een eigenaar en een risicotier op basis van materialiteit maal complexiteit, geëscaleerd door de afhankelijkheid die in de vorige paragraaf is beschreven: geeft het bestand alleen inzicht, is het een mede-basis, of is het de enige basis voor een beslissing? Aan die tier hangt automatisch het bijbehorende beheersingsniveau, van ongecontroleerd via managed naar controlled application. Via een magic link declareren en ondertekenen eigenaren zelf hun artefacten, zodat het register een levend document blijft in plaats van een momentopname, en de organisatie via validatie en een auditspoor kan aantonen dat het stelsel daadwerkelijk werkt.
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?21
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.
De horizon verschuift — en de blinde vlek verplaatst zich
Wie denkt dat dit een afgesloten hoofdstuk is, onderschat hoe snel het landschap beweegt — en wel op een manier die het punt van dit artikel eerder onderstreept dan ontkracht. Er is namelijk iets opvallends gebeurd met de regels zelf. De toezichthouder die ooit de wereldwijde standaard voor modelrisico zette, scherpte die onlangs aan.22 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 sluit eenvoudige, vaste rekensommen voortaan expliciet uit. Juist de categorie waar veel kritische spreadsheets in vallen, zou daarmee buiten de formele regel kunnen glippen. De les daarvan is niet regeltechnisch, maar bestuurlijk. Of iets nu officieel een model heet of niet: het risico verandert er niet door. Wie zijn kritische spreadsheets pas serieus neemt zodra een voorschrift het afdwingt, is te laat. Governance hoort niet te stoppen waar de compliance-tekst ophoudt.
Tegelijk komt er van een andere kant regelgeving bij. De EU AI Act, gefaseerd in werking sinds 2024, bestempelt onder meer kredietwaardigheidsbeoordeling van particulieren als hoogrisico en stapelt documentatie-, toezicht- en transparantie-eisen bovenop de bestaande modelkaders.23 En de aard van het modelrisico zelf verschuift. Generatieve AI introduceert risico's — hallucinatie, ondoorgrondelijkheid — die de klassieke kaders niet dekten; veelzeggend genoeg sluit ook de nieuwe Amerikaanse richtlijn generatieve AI voorlopig expliciet uit, omdat de techniek te snel beweegt om vast te leggen.
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. Naar schatting verliep in 2025 al meer dan zeventig procent van alle applicatieontwikkeling via low-code, terwijl in enquêtes een ruime meerderheid van de organisaties toegeeft daar nog geen governance op te hebben.24 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" nooit de vorm was, maar de functie. Niet de statistische zwaarte, niet het label op het tabblad, niet of er een quant aan te pas kwam — maar de simpele vraag of een fout in dat ding een verkeerd besluit kan veroorzaken.
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.
Hoe kan Audirium u helpen?
De grens tussen "model" en "gewoon een spreadsheet" is precies waar het risico zich verstopt. Ik help organisaties die grens scherp te trekken en de tools die er feitelijk toe doen onder controle te brengen — pragmatisch, en zonder een governance-apparaat op te tuigen dat onder zijn eigen gewicht bezwijkt.
- EUC- en modelrisico-nulmeting: welke spreadsheets en zelfgebouwde tools sturen feitelijk uw besluitvorming en rapportage, en welke horen in de model-inventaris thuis?
- Risicoclassificatie en tiering: een werkbaar model om op materialiteit en complexiteit te prioriteren, zodat de aandacht naar de bestanden gaat die het verdienen
- Beheersings- en validatieraamwerk: gerichte controls en modelvalidatie-principes voor uw kritische EUC's, aangesloten op three lines en bestaande MRM-kaders
- Auditprogramma EUC/MRM: een risicogebaseerd toetsprogramma voor internal audit, met concrete teststappen en herkenbare bevindingen
- Horizon-check: wat betekenen SR 26-2, SS1/23, Solvency II en de EU AI Act voor uw modellenlandschap — inclusief de nieuwe EUC in low-code en GenAI
Wilt u weten welke spreadsheets uw organisatie stilletjes besturen? Neem contact op →
Literatuur en bronnen
Bronverwijzingen
- Panko, R. (2015). What We Know About Spreadsheet Errors. University of Hawaii. Bevinding: van 88 onderzochte operationele spreadsheets bevatte 94% ten minste één fout. panko.com
- 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
- Yields.io (2023). The Three Lines of Defence in Model Risk Management. yields.io
- Bank of England / PRA (2023). SS1/23 – Model risk management principles for banks. Van kracht per 17 mei 2024. bankofengland.co.uk
- Europese Centrale Bank (2021). Targeted Review of Internal Models (TRIM) – Project report. bankingsupervision.europa.eu
- EIOPA. Solvency II – Internal models (art. 120–125). eiopa.europa.eu
- Apparity. Model Risk Management & The Elephant in the Room. apparity.com
- 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
- Groenfeldt, T. (2013). Solutions To Spreadsheet Risk Post JPM's London Whale, Forbes; en Revolution Analytics, Did an Excel error bring down the London Whale? (2013). Verlies ~$6,2 mrd; formule deelde door de som i.p.v. het gemiddelde van twee hazard rates. forbes.com
- The Register (2003). Excel snafu costs firm $24m (TransAlta). theregister.com
- Full Stack Modeller. The Fannie Mae Spreadsheet Error — onderschatting eigen vermogen ~$1,1 mrd (2003). fullstackmodeller.com
- The Register (2008). Lehman Excel snafu could cost Barclays dear; AccountingWEB, Hidden spreadsheet rows hit Barclays with toxic Lehman contracts. theregister.com
- Bloomberg (2013). FAQ: Reinhart, Rogoff, and the Excel Error That Changed History. bloomberg.com
- Financial Times / Slashdot (2024). The Norwegian Sovereign Wealth Fund's $92 Million Excel Error — verkeerde datum (1 dec i.p.v. 1 nov) in benchmarkberekening. slashdot.org
- 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
- Panko, R. Spreadsheet Development Error Experiments — gemiddelde cell error rate ~5,2% over 13 studies (1995–2004). panko.com
- KPMG UK (2022). Our Approach to Managing the Risk of End User Computing (EUC). kpmg.com
- Apparity. Building a Spreadsheet Risk Assessment Model — tiering op materialiteit en complexiteit. apparity.com
- Mitratech. The Ultimate End User Computing Checklist; soxmadeeasy, EUC Applications – Audit Programs. mitratech.com
- RiskSpan. Mitigating EUC Risk Using Model Validation Principles. riskspan.com
- soxmadeeasy. End User Computing (EUC) Applications – Audit Programs. soxmadeeasy.com
- Federal Reserve (2026). SR 26-2: Revised Guidance on Model Risk Management (OCC Bulletin 2026-13); Sullivan & Cromwell memo. Vervangt SR 11-7 (2011); engere modeldefinitie, sluit eenvoudige deterministische processen en generatieve AI expliciet uit. federalreserve.gov
- Europese Commissie. Timeline for the Implementation of the EU AI Act — kredietwaardigheidsbeoordeling van particulieren als hoogrisico (Annex III). ec.europa.eu
- CIO.com (2025), Low code, no fear; KPMG-enquête EMEA (via txminds) — meerderheid organisaties zonder low-code governance. txminds.com