Menselijke goedkeuring van AI in finance begint bij het goedkeuringsverzoek

Vijfenvijftig tegengehouden betalingen kostten iets meer dan vier minuten. We zaten naast de treasury manager van een groep terwijl die de ochtendbetaalrun voor zeven entiteiten afwerkte, de eerste run die een nieuwe workflow had voorbereid, en vroegen daarna waar er bij elke betaling naar was gekeken. Het antwoord was eerlijk: het totaal per entiteit, en of de namen van de begunstigden bekend voorkwamen.

Het scherm toonde elke tegengehouden betaling met begunstigde, bedrag, valuta, vervaldatum en betalende entiteit, een link naar de onderliggende stukken en een knop om goed te keuren. Waarom een betaling was tegengehouden, stond er nergens. Dus werd gecontroleerd wat snel te controleren viel, en dat had ieder van ons gedaan met vijfenvijftig regels en een cut-off om elf uur. In de auditlog stonden vijfenvijftig vrijgaven door een bij naam genoemde fiatteur. Wat er werkelijk was bekeken, kon de log niet laten zien.

Financiële beheersmaatregelen scheiden al lang wie een transactie voorbereidt van wie haar doorvoert. Op diezelfde scheiding bouwen wij workflows: een AI zet de actie klaar, een mens voert haar door. Of dat werkt, hangt af van het moment daartussen, van wat de mens ziet als hem wordt gevraagd door te voeren en hoe lang hij echt kijkt.

Eén goedkeuringsverzoek per reden voor beoordeling

Een scherm met het hele record vraagt de beoordelaar om zelf het probleem te gaan zoeken. Maar het systeem weet al waarom het de betaling heeft tegengehouden, dus het scherm hoort dat te zeggen. We vervangen de recordweergave door een goedkeuringsverzoek dat om één vraag draait.

Het verzoek begint met één regel: welk besluit nodig is en waarom de betaling stopte. "Deze betaling is vier keer zo groot als de grootste die deze entiteit ooit aan deze begunstigde heeft gedaan." Daaronder staan naast elkaar het veld dat de beoordeling veroorzaakte, de aangetroffen waarde en de verwachte waarde. Dan de onderbouwing voor alleen dat punt. Het volledige record is één klik verder, en staat niet als eerste op het scherm.

In die treasury begon een typisch verzoek over een bedrag met het besluit vetgedrukt: 86.400 EUR van de Spaanse entiteit aan een vervoerder vrijgeven, of terugsturen naar crediteurenadministratie. De regel eronder gaf de reden. De regel houdt alles tegen boven twee keer de grootste betaling van de entiteit aan die vervoerder in de afgelopen twaalf maanden, en dat was 21.750 EUR. Daarna kwam de vorige betaling, 18.920 EUR in augustus voor twee weken transport, met alle andere velden gelijk en ingeklapt. In het paneel met onderbouwing zaten het raamcontract voor een nieuwe seizoensroute en de boekingen voor oktober bij de inkooporder.

Een beoordelaar ziet in een paar seconden dat de sprong een reden heeft, een nieuwe route die is gecontracteerd en geboekt, en dat er verder niets aan de betaling is veranderd.

Andere redenen krijgen andere verzoeken. Is een begunstigde nieuw voor deze entiteit, maar betaalt een zusterentiteit hem al jaren, dan opent het verzoek op die geschiedenis, zodat de beoordelaar een bekende relatie ziet in plaats van een lege pagina. Betaalt een entiteit in een valuta die ze nooit eerder heeft gebruikt, dan begint het verzoek met de valuta, de koersbron en de valuta's waarin de entiteit normaal betaalt. Twee redenen betekenen twee verzoeken. En konden de onderliggende stukken helemaal niet worden gekoppeld, dan opent het verzoek op wat ontbreekt, met de betaalregel erachter.

Elke reden heeft een eigen verzoek nodig, en elk verzoek is engineeringwerk. We bouwen eerst verzoeken voor de redenen achter de meeste stops. De zeldzame vallen terug op de recordweergave, duidelijk gemarkeerd als noodoplossing, zodat niemand die voor het afgemaakte ontwerp aanziet.

Laat zien wat anders is, niet wat er staat

In onze ervaring werken beoordelaars sneller en nauwkeuriger als ze vergelijken dan als ze lezen. Elk verzoek zet de betaling daarom naast het meest vergelijkbare eerdere geval, meestal de laatst vrijgegeven betaling aan dezelfde begunstigde vanuit dezelfde entiteit, of vanuit een zusterentiteit als deze entiteit hem nooit heeft betaald. Velden die niet zijn veranderd, zijn ingeklapt en de veranderde zijn gemarkeerd. Een bedrag ver buiten het gebruikelijke, of een valuta die de entiteit nooit heeft gebruikt, staat waar de blik het eerst valt. Het is wat een treasurer op een geprinte betaallijst zou opvallen, als er tijd voor was.

De confidencescore van het model laten we weg. Een beoordelaar die een hoog getal ziet, controleert doorgaans minder. Het literatuuroverzicht van Microsoft over overmatig vertrouwen in AI (Passi en Vorvoreanu, juni 2022) brengt de studies hierover bij elkaar, met onder meer een studie waarin zelfs een nietszeggend nauwkeurigheidscijfer het vertrouwen van mensen in de antwoorden van het systeem verhoogde. Beoordelaars vragen er toch om. We gebruiken de score waar hij geen oordeel kan sturen: om de wachtrij te sorteren, laagste eerst.

Of gevallen samen mogen, hangt af van de gevallen zelf

Betalingen één voor één vrijgeven is traag, en treasuryteams vragen meestal in de eerste week al om een knop voor bulkvrijgave. Bij bulkgoedkeuring verwatert de beoordeling ongemerkt. Het scherm biedt die knop daarom niet als functie aan; gevallen moeten zich ervoor kwalificeren.

Dat doen ze als ze om dezelfde reden zijn tegengehouden, op elk veld behalve het veld dat wordt goedgekeurd overeenkomen met hetzelfde eerdere geval, dezelfde valuta hebben en binnen een bedragsgrens vallen die treasury heeft vastgesteld. Twaalf betalingen aan één vervoerder vanuit drie entiteiten, allemaal tegengehouden omdat de nieuwe seizoenstarieven het bedrag boven hetzelfde eerdere geval tilden, zijn één besluit. Dezelfde vervoerder met twaalf verschillende redenen zijn twaalf besluiten.

Elke afwijking krijgt een reden

Past een beoordelaar het voorstel van het systeem aan, dan vraagt het verzoek waarom, met een korte keuzelijst die met treasury is afgesproken: bedrag buiten het contract om afgesproken, verkeerde betalende entiteit, dubbel met een eerdere betaling, splitsen of uitstellen, overig met toelichting. Een korte keuzelijst wordt veel betrouwbaarder ingevuld dan een vrij tekstveld.

Na de livegang blijken die redenen tot de nuttigste gegevens te horen die het systeem oplevert. Ze laten ons zien welke tegenhoudregels niet kloppen en welke relaties met begunstigden aan het veranderen zijn. Over een kwartaal of twee laten ze ook zien welke soorten betalingen niet langer zonder tegenhouden mogen worden vrijgegeven.

De beoordelingsinspanning wordt gemeten

We meten de beoordeling zelf: de tijd per verzoek, of de onderbouwing is geopend, hoe vaak het voorstel wordt aangepast en hoe vaak een vrijgave later wordt teruggedraaid of teruggeroepen. Niets daarvan wordt gebruikt om mensen te beoordelen. Het vertelt ons of de beheersmaatregel werkt.

Wordt op een beoordelingsmoment week na week elk geval binnen een paar seconden ongewijzigd goedgekeurd, dan voegt dat moment geen oordeel toe. Misschien hebben de gevallen geen mens nodig en hoort er een geautomatiseerde controle te staan. Of het verzoek laat niet zien wat de mens nodig heeft. Beide zijn ontwerpproblemen, en beoordelaars vragen beter op te letten lost geen van beide op.

Voor de livegang behandelen beoordelaars in een schaduwomgeving ook gevallen waarvan het juiste antwoord al bekend is, waaronder een paar die tegengehouden moeten worden. Zo blijkt, voordat er echt geld beweegt, of het verzoek een fout antwoord zichtbaar maakt.

Na de livegang beoordeelt een tweede fiatteur binnen treasury elke week opnieuw een kleine willekeurige steekproef van vrijgegeven verzoeken, zonder het eerste besluit te zien. Waar de twee het oneens zijn, kijken we eerst naar het verzoek. Het is de meest directe maatstaf die we hebben gevonden voor de vraag of de beoordeling vangt waarvoor ze bestaat.

Het patroon waar we op letten, zijn twee lijnen die samen dalen: de tijd per verzoek en het percentage voorstellen dat wordt aangepast. Meestal betekent dat dat een beoordelaar heeft geleerd dat het systeem doorgaans gelijk heeft, en juist dan verslapt de controle. Zien we dat, dan verbergt één op de twintig verzoeken de voorgestelde actie tot de beoordelaar zelf een besluit heeft genomen. Onderzoekers noemen dat een cognitive forcing function. Buçinca, Malaya en Gajos van Harvard ontdekten in 2021 dat zulke ontwerpen overmatig vertrouwen in AI verminderden, en dat mensen de ontwerpen die het meest hielpen het minst prettig vonden. We nemen beide bevindingen serieus. Daarom gaat het aan als de cijfers erom vragen in plaats van altijd te draaien, en leggen we het team uit waarvoor het dient.

Goedkeuring wordt vastgelegd zoals elke financiële beheersmaatregel

Wie goedkeurt, is nooit het systeem dat de run heeft voorbereid, en nooit de persoon die de betaling heeft voorgesteld. Elke goedkeuring wordt vastgelegd met de beoordelaar, het tijdstip, het verzoek precies zoals het werd getoond, de geopende onderbouwing en de reden voor een eventuele aanpassing. Vraagt een auditor hoe de beheersmaatregel heeft gewerkt, dan kunnen we laten zien wat de beoordelaar te zien kreeg, niet alleen dat er is geklikt.

Om dezelfde reden bieden we geen goedkeuring aan via een antwoord op een e-mail of een knop in een chatvenster. Dan verdwijnt de onderbouwing uit het besluit en blijft alleen de handtekening over.

De naam in de log moet iets betekenen

Een beoordelingsmoment waar niemand echt naar kijkt, kan erger zijn dan geen beoordelingsmoment, want het laat een vastlegging achter die zegt dat iemand heeft gecontroleerd. Ontwerp het goedkeuringsverzoek zo dat de naam in de auditlog weergeeft wat er werkelijk is gebeurd.