De bug van $89 miljoen: wat Apple en Goldman Sachs fout deden met AI in de financiële sector

Ik zat op een dinsdagavond afgelopen oktober in mijn thuiskantoor toen het persbericht van de CFPB in mijn feed verscheen. Apple en Goldman Sachs, veroordeeld tot het betalen van ruim $89 miljoen wegens systemisch falen in de manier waarop ze geschillen over de Apple Card afhandelden. Ik las het consent order twee keer. Daarna las ik het een derde keer, omdat ik niet kon geloven wat ik zag.

Het kernfalen was geen exotische financiële engineering die misging. Het was geen op hol geslagen algoritme dat discriminerende kredietbeslissingen nam. Het was een knop. Een secundair formulier in de Apple Wallet-app dat, wanneer consumenten het onvoltooid lieten, hun geschillen over afschrijvingen in een digitale leegte deed verdwijnen. Tienduizenden mensen meldden ongeautoriseerde afschrijvingen, en het systeem... vrat ze gewoon op. Geen onderzoek. Geen ontvangstbevestiging. Geen oplossing. De consumenten bleven met de rekening zitten.

Ik bouw AI-systemen voor de kost. Mijn bedrijf, Veriprajna, richt zich op wat wij deep AI noemen — neurosymbolische architecturen die de flexibiliteit van grote taalmodellen combineren met de wiskundige striktheid van formele verificatie. Toen ik dat consent order las, voelde ik me niet in mijn gelijk gesterkt. Ik werd er misselijk van. Want alles wat er misging met de Apple Card was te voorkomen. Niet met beter testen. Niet met meer engineers. Maar met een fundamenteel andere manier van denken over hoe AI-systemen voor gereguleerde sectoren gebouwd zouden moeten worden.

Wat gebeurde er werkelijk met jouw Apple Card-geschil?

Laat me je door het falen heen leiden, want de details doen er meer toe dan het cijfer in de krantenkop.

Apple en Goldman Sachs tekenden hun samenwerkingsovereenkomst in 2017. Apple zou eigenaar zijn van de consumentenervaring — de strakke Wallet-interface, het berichtensysteem, de hele front-end. Goldman Sachs zou de bank achter het gordijn zijn: krediet verstrekken, transacties verwerken en geschillen onderzoeken wanneer er iets misging.

In juni 2020 bracht Apple een update uit voor de "Report an Issue"-workflow. Vóór de update tikte je op een verdachte transactie, drukte je op "Report an Issue" en werd je doorgestuurd naar een chat via Messages met Goldman Sachs. Rechttoe rechtaan. Na de update voegde Apple een secundair formulier toe — een extra stap die consumenten na hun eerste bericht moesten voltooien.

Hier ging het mis: wanneer mensen hun geschil via Messages indienden maar het secundaire formulier niet afmaakten, behandelde het systeem het geschil als onvolledig. Het stuurde de klacht nooit door naar Goldman Sachs. Vanuit regelgevend oogpunt kwalificeerden veel van deze berichten als geldige Billing Error Notices onder de Truth in Lending Act. Juridisch gezien hadden ze binnen specifieke termijnen een onderzoek moeten uitlokken. In plaats daarvan verdwenen ze.

Tienduizenden juridisch geldige consumentengeschillen werden opgeslokt door een toestandsmachine die niemand formeel had geverifieerd.

Ik herinner me dat ik dat detail las en dacht aan elk gesprek dat ik heb gevoerd met bestuurders in de financiële dienstverlening die me vertellen dat hun systemen "battle-tested" zijn. Battle-tested tegen wát? Tegen het specifieke scenario waarin een UI-wijziging een dode toestand introduceert in een gedistribueerde workflow? Dat is niet het soort dingen dat je opspoort met unit tests en QA-sprints.

De clausule van $25 miljoen die alles kapotmaakte

Er zit een detail begraven in het consent order waar ik steeds op terugkom. Apple's contract met Goldman Sachs bevatte een schadevergoedingsbeding van $25 miljoen voor elke vertraging van 90 dagen die Goldman veroorzaakte bij de lancering van de Apple Card.

Vijfentwintig miljoen dollar. Per kwartaal. Voor te laat zijn.

Ik heb in vergaderzalen gezeten waar commerciële druk technische beslissingen verwringt. Ik heb teams dingen zien uitbrengen waarvan ze wisten dat ze nog niet klaar waren, omdat de kosten van uitstel concreter aanvoelden dan de kosten van falen. Maar ik heb nog nooit een prikkelstructuur zo expliciet uitgeschreven gezien. Goldman Sachs werd in feite vooraf beboet voor voorzichtigheid.

De Apple Card ging live op 20 augustus 2019. Interne teams bij Goldman hadden zorgen gemeld over de gereedheid van het systeem. De berichtenwachtrijen tussen de Wallet-app en Goldmans back-end waren ondergetest. De synchronisatieprotocollen waren fragiel. Maar de rekensom was simpel: nu uitbrengen en later repareren, of $25 miljoen betalen en eerst repareren.

Ze brachten het uit. En ruim een jaar lang draaide het systeem met een gat erin dat van buitenaf niemand kon zien.

Hier denk ik aan wanneer mensen me vragen waarom Veriprajna aandringt op formele verificatie vóór uitrol. "Is dat niet traag?" vragen ze. "Kun je niet gewoon monitoren in productie en problemen opvangen?" Zeker. Je kunt ook rijden zonder remmen en van plan zijn om om obstakels heen te sturen. Het werkt tot het niet meer werkt. En wanneer het niet werkt in de financiële dienstverlening, raken echte mensen gewond.

Waarom heeft niemand dit opgemerkt?

Dit is de vraag die me achtervolgt. Twee van de technologisch meest geavanceerde bedrijven ter wereld — Apple, met zijn legendarische engineeringcultuur, en Goldman Sachs, met zijn kwantitatieve vuurkracht — en geen van beide merkte dat duizenden geschillen in een zwart gat vielen?

Het antwoord is volgens mij architectonisch. Het systeem was ontworpen als een estafette: Apple doet de front-end, Goldman doet de back-end, en er stromen berichten tussen de twee door. Maar niemand was eigenaar van de ruimte tussen de twee systemen. Niemand had een formeel model van wat er zou moeten gebeuren wanneer een geschil in toestand A ("bericht ingediend") terechtkwam maar toestand B ("formulier voltooid") nooit bereikte. In een goed ontworpen toestandsmachine is dat een overgang waar je expliciet rekening mee houdt. In het Apple Card-systeem was het een gat dat niemand specificeerde, en dus monitorde niemand het.

Ongeveer een jaar geleden maakte ik een lange avond — mijn team en ik bouwden een compliance-workflow voor een klant, en een van onze engineers, Priya, signaleerde iets soortgelijks. Ze had de toestandsovergangen voor een documentbeoordelingsproces gemodelleerd en vond een pad waarbij een inzending oneindig lang kon blijven hangen in een toestand "in afwachting van verrijking" als een API van een derde partij een time-out kreeg. Het was geen fout in de code. De code deed precies wat haar was opgedragen. Het was een fout in het ontwerp — een toestand waar de specificatie geen rekening mee hield.

We vingen het op omdat we formele-verificatietools gebruiken — specifiek: we modelleren workflows als toestandsmachines en halen ze door SMT-solvers die uitputtend elk mogelijk pad controleren. De solver vond Priya's dode toestand in seconden. In het Apple Card-systeem draaide die dode toestand maandenlang in productie.

Het falen van de Apple Card was geen fout in de code. De code deed precies wat haar was opgedragen. Het was een fout in het ontwerp — een toestand die niemand specificeerde, en dus monitorde niemand hem.

Waarom kun je hier niet gewoon GPT voor gebruiken?

Ik krijg deze vraag voortdurend. Een investeerder zei het bijna letterlijk tegen me tijdens een pitchgesprek: "Waarom kun je GPT-4 niet gewoon fine-tunen op TILA-regelgeving en het geschillen laten afhandelen?"

Ik haalde adem. Toen vroeg ik hem: "Als GPT-4 een consument vertelt dat zijn geschil is opgelost, terwijl het in werkelijkheid nooit naar de bank is doorgestuurd, wie is er dan aansprakelijk?"

Hij had geen antwoord. Dat heeft niemand, want de vraag legt bloot wat er fundamenteel mis is met wat ik de "mega-prompt"-aanpak van AI in gereguleerde sectoren noem. Je neemt een groot taalmodel, propt de relevante regelgeving in zijn contextvenster en hoopt dat het alles correct afhandelt. Geen governancelaag. Geen formele verificatie. Geen wiskundige garantie dat de output van het systeem consistent is met de wet.

In het geval van de Apple Card was het falen een logische fout in een gedistribueerde toestandsmachine. Een LLM-wrapper zou dit niet hebben opgelost — het had het erger kunnen maken. Stel je een LLM voor die een consument zelfverzekerd vertelt: "Uw geschil is ingediend en wordt onderzocht," terwijl het geschil in werkelijkheid de servers van Apple nooit heeft verlaten. Dat is niet hypothetisch. Zo ziet hallucinatie eruit in een financiële context, en het is angstaanjagend.

De populaire financiële uitlegsites en veelgedeelde content over AI in het bankwezen missen dit onderscheid bijna zonder uitzondering. Ze praten over AI die compliance "automatiseert", alsof het moeilijke deel het lezen van de regelgeving is. Het moeilijke deel is niet het lezen ervan. Het moeilijke deel is bewijzen dat je systeem ze volgt in elk mogelijk scenario, inclusief scenario's waar je nog niet aan hebt gedacht.

Voor een diepgaandere blik op hoe het falen van Apple-Goldman zich verhoudt tot specifieke overtredingen van regelgeving en architectonische hiaten, schreef ik een interactieve analyse die het consent order in detail doorloopt.

Wat "aantoonbaar correct" werkelijk betekent

Wanneer ik zeg dat Veriprajna "aantoonbaar correcte" compliance-systemen bouwt, bedoel ik niet "heel goed getest". Ik bedoel wiskundig bewezen. Er is een verschil, en dat doet er enorm toe.

Testen controleert specifieke scenario's. Je schrijft een test die zegt: "als een gebruiker een geschil indient en het formulier voltooit, verifieer dan dat het bij Goldman Sachs aankomt." Die test slaagt. Prima. Maar je hebt het scenario niet getest waarin de gebruiker een geschil indient en het formulier niet voltooit. Of waarin ze het wel voltooien maar het netwerk het pakket laat vallen. Of waarin twee geschillen tegelijkertijd binnenkomen en het ene het andere overschrijft.

Formele verificatie controleert geen scenario's. Ze controleert eigenschappen. Je definieert een eigenschap — "elk ingediend geschil moet uiteindelijk een onderzoekstoestand bereiken" — en een wiskundige solver bewijst uitputtend dat die eigenschap geldt in elke mogelijke uitvoering van het systeem. Elk pad. Elk randgeval. Elke race condition. Als er ook maar één tegenvoorbeeld is, vindt de solver het en laat hij je precies zien hoe het systeem kan falen.

We gebruiken tools zoals Imandra, waarmee we in wezen een digital twin van de compliance-logica kunnen bouwen. De twin draait naast het productiesysteem, en als de productiecode ooit een actie probeert die afwijkt van het geverifieerde model — zoals een geschil laten vallen vanwege een onvoltooide UI-stap — vangt het systeem dat in realtime op.

Dit is het soort aanpak dat de Apple Card-bug zou hebben opgevangen voordat ook maar één consument getroffen was. Tijdens de ontwerpfase zou een SMT-solver onmiddellijk hebben vastgesteld dat de variabele "CompletedFormB" onder TILA geen verplicht veld was. De transmissielogica vereiste het, maar de wet niet. Die discrepantie is een aantoonbaar defect, en het zou vóór uitrol gesignaleerd zijn.

De architectuur die wij daadwerkelijk bouwen

Ik wil specifiek zijn over hoe een "deep AI"-compliancesysteem er in de praktijk uitziet, want vage beweringen over "AI-aangedreven compliance" zijn onderdeel van het probleem.

Veriprajna gebruikt een multi-agentarchitectuur. In plaats van één monolithische AI die alles probeert te doen, zetten we gespecialiseerde agents in met gedefinieerde rollen en grenzen. Zie het minder als het inhuren van één genie en meer als het samenstellen van een team waarin iedereen een specifieke taak heeft en een supervisor het werk controleert.

Een Intake Agent handelt het rommelige, menselijke deel af — het parsen van geschillen in natuurlijke taal. Wanneer iemand schrijft: "Ik heb deze koffie in Seattle nooit gekocht; ik was die dag in Londen," haalt de agent de belangrijkste entiteiten eruit: de transactie, de handelaar, de datum, de aard van de claim. Dit is waar LLM's echt uitblinken.

Maar dan — en hier wijken we af van elke wrapper-gebaseerde aanpak die ik heb gezien — gaat de geëxtraheerde informatie naar een symbolische Policy Engine die niet voorspelt of gokt. Hij evalueert het geschil tegen coderingen in eerste-orde-logica van federale wetgeving. Bevat dit bericht genoeg informatie om een geldige Billing Error Notice onder TILA te vormen? De engine schat niet. Hij bewijst.

Een Workflow Agent handhaaft de volgorde van de operaties. Een Verification Agent voert wiskundige controles in realtime uit. Een Audit Agent legt elke interactie vast in wat wij een "glass box" noemen — volledige transparantie voor toezichthouders.

En cruciaal: een Sentinel Agent bewaakt precies het soort dode toestand dat het Apple Card-systeem fataal werd. Als een geschil langer dan een gedefinieerde drempel blijft staan in "ingediend maar niet doorgestuurd", wacht de Sentinel niet tot een mens het opmerkt. Hij bepaalt autonoom of de bestaande informatie voldoende is om verder te gaan, verpakt die en verstuurt die via een geverifieerd kanaal.

In een systeem dat voor absolute compliance is gebouwd, bepaalt de wet — niet de UI — of een geschil geldig is. Als een consument je heeft verteld over een ongeautoriseerde afschrijving, is het ontbreken van een voltooid formulier jouw probleem, niet het hunne.

Waarom timing een wettelijke vereiste is, geen prestatiemaatstaf

Er is nog een dimensie hieraan die de meeste technische discussies volledig missen. In financiële compliance geldt: tijd is wet. Regulation Z zegt niet alleen dat je geschillen moet onderzoeken. Het zegt dat je ze binnen specifieke termijnen moet bevestigen en binnen 60 dagen moet afhandelen. Goldman Sachs werd deels beboet omdat het naliet ontvangstbevestigingen binnen deze termijnen te versturen.

Mijn team besteedde maanden aan het ontwikkelen van wat wij Symbolic Latency-analyse noemen — een manier om wiskundig te bewijzen dat een gedistribueerd systeem zijn werk binnen een regelgevende deadline afrondt onder worst-case-omstandigheden. Niet gemiddelde omstandigheden. Niet het "95e percentiel". Worst case.

Traditionele monitoring vertelt je of je systeem traag was. Symbolic Latency vertelt je of je systeem traag kan zijn. Als een wijziging in de UI-code de worst-case verwerkingstijd voorbij de door de regelgeving voorgeschreven termijn van 60 dagen duwt, wordt de uitrol automatisch afgewezen. Je komt er niet achteraf achter. Je komt er vóór het uitbrengen achter.

Ik herinner me het meningsverschil dat we intern hadden over de vraag of dit niveau van striktheid nodig was. Een van mijn engineers — een briljante man die jaren bij een grote cloudprovider had gewerkt — verzette zich fel. "Je voegt weken toe aan de uitrolcyclus voor een scenario dat misschien nooit gebeurt," zei hij. Ik wees naar het Apple Card-consent order. "Het is gebeurd," zei ik. "Bij Apple. Bij Goldman Sachs. Bij tienduizenden consumenten die niets verkeerd hebben gedaan."

Daarna bracht hij er niets meer tegenin.

Voor de volledige technische uiteenzetting van onze aanpak van formele verificatie, inclusief de Performal-methodologie voor latentiegrenzen, zie ons onderzoeksrapport.

"Maar dit zou te lang duren om te bouwen"

Mensen verzetten zich hier altijd tegen, en ik begrijp waarom. De Apple Card werd in maanden gelanceerd. Een formeel geverifieerde compliance-architectuur kost 18 tot 36 maanden voor volledige optimalisatie in een legacy-zware omgeving. Dat voelt als een eeuwigheid in een wereld waarin concurrenten wekelijks uitbrengen.

Maar laat me de rekensom herkaderen. Apple en Goldman Sachs besteedden jaren aan het bouwen en lanceren van de Apple Card. Vervolgens besteedden ze jaren aan het opruimen van de gevolgen — interne onderzoeken, toezichtsonderzoeken, juridische kosten, reputatieschade en uiteindelijk $89,8 miljoen aan boetes en consumentencompensatie. De "snelle" aanpak was niet snel. Het was snelheid vooraf met een catastrofe achteraf.

Onze gefaseerde uitrolaanpak erkent de realiteit. Je kunt de kernsystemen van een bank er niet uitrukken. COBOL-mainframes die sinds de jaren tachtig draaien, verdwijnen niet van de ene op de andere dag. Dus integreren we in lagen: de bestaande architectuur auditen, een intelligente API-gateway bouwen, het AI-systeem in shadow mode draaien om de output van het legacysysteem te valideren, en geleidelijk beslissingsbevoegdheid verschuiven naarmate de formele bewijzen zich opstapelen.

De eerste fase — assessment en formele modellering — duurt 14 tot 20 weken. Aan het eind daarvan heb je een wiskundig model van je compliance-logica dat het soort dode-toestandsfouten kan opsporen dat de Apple Card teisterde. Dat is geen 36 maanden. Dat is minder dan vijf maanden tot een fundamenteel veiliger systeem.

Het moment dat mijn denken hierover veranderde

Er is één specifiek moment waar ik steeds naar terugkeer. Het was ongeveer acht maanden geleden, en we draaiden een proof-of-concept voor een klant in de financiële dienstverlening. We hadden hun workflow voor geschillenoplossing gemodelleerd als een gedistribueerde toestandsmachine en lieten de formele-verificatiesuite draaien.

De solver vond elf dode toestanden.

Elf paden door het systeem waarbij de klacht van een consument kon blijven hangen zonder oplossing en zonder waarschuwing. Het engineeringteam van de klant draaide dit systeem al drie jaar. Ze hadden miljoenen transacties verwerkt. Ze hadden monitoringdashboards, alerteringssystemen, kwartaalaudits. En niets daarvan had deze elf gaten opgemerkt.

Het werd stil in de kamer toen ik hun de resultaten liet zien. Hun hoofd compliance — een vrouw met twintig jaar ervaring in bankregelgeving — keek naar het scherm en zei: "Hoeveel consumenten zijn in die toestanden gevallen?"

Dat wisten we niet. Zij wisten het ook niet. Dat is het punt met dode toestanden in gedistribueerde systemen: als niemand ernaar kijkt, zijn ze onzichtbaar. De getroffen consumenten hebben misschien de klantenservice gebeld, zijn van het kastje naar de muur gestuurd en hebben het uiteindelijk opgegeven. Of misschien betalen ze nog steeds voor afschrijvingen die ze nooit hebben gedaan.

Zo ziet het falen van de Apple Card er van binnenuit uit. Geen dramatische explosie. Een trage, stille opeenstapeling van schade die niemand kan zien tot een toezichthouder de black box openbreekt.

Hoe de komende vijf jaar eruitzien

De actie van de CFPB tegen Apple en Goldman Sachs staat niet op zichzelf. Het is het begin van een regelgevende afrekening met de manier waarop technologiebedrijven omgaan met financiële infrastructuur. Naarmate bankieren meer ingebed raakt — in telefoons, in apps, in platformen die oorspronkelijk niet als financiële dienstverlening waren ontworpen — wordt de kloof tussen "werkt meestal" en "werkt aantoonbaar altijd" een aansprakelijkheid van honderden miljoenen dollars.

Ik denk aan het bezwaar dat ik het vaakst hoor: "Is formele verificatie niet overdreven voor de meeste financiële systemen?" En mijn antwoord is in de loop van de tijd eenvoudiger geworden. De Apple Card is een van de meest zichtbare financiële consumentenproducten ter wereld, gebouwd door twee bedrijven met in wezen onbeperkte engineeringmiddelen. Als zij een dode toestand in een geschillenworkflow niet konden opsporen met traditioneel testen en monitoren, waarom denk je dan dat jouw systeem anders is?

De sector beweegt richting wat ik Absolute Compliance noem — geen compliance als afvinkoefening, maar compliance als architectonische eigenschap. Een systeem waarin naleving van de wet niet iets is dat je achteraf verifieert, maar iets dat je vóór uitrol bewijst. Waarin de kloof tussen de UI en de regelgeving niet wordt overbrugd door menselijke waakzaamheid maar door wiskundige zekerheid.

Het tijdperk van "snel uitbrengen en later repareren" is onverenigbaar met de "geld verplaatsen en mensen beschermen"-eisen van de wereldwijde financiële sector. De Apple Card heeft dat bewezen. De vraag is of de sector de les leert vóór of na de volgende boete van $89 miljoen.

Wij bouwen die toekomst bij Veriprajna. Niet omdat het makkelijk is — formele verificatie van gedistribueerde financiële systemen is oprecht moeilijk, en wie je iets anders vertelt, verkoopt je iets. Maar omdat het alternatief is wat we in oktober 2024 zagen: twee van 's werelds machtigste bedrijven, een kapotte knop, en tienduizenden mensen die bleven zitten met de rekening voor afschrijvingen die ze nooit hebben gedaan.

Dat is geen technologieprobleem. Het is een probleem van engineeringethiek. En de oplossing is niet betere monitoring of snellere patches. Het is systemen bouwen die correct by construction zijn — systemen waarin de wiskunde garandeert dat het geschil van geen enkele consument ooit in een leegte zal verdwijnen.

De boete van $89 miljoen is al betaald. De echte kosten zijn het vertrouwen dat geschonden is. Het herstellen daarvan vereist meer dan beloften. Het vereist bewijs.