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 die de ochtendbetaalrun voor zeven groepsbedrijven afwerkte, de eerste run die een nieuwe workflow had voorbereid, en vroegen daarna wat er bij elke betaling was gecontroleerd. Het eerlijke antwoord: het totaal per bedrijf, en of de namen van de ontvangers bekend klonken.

Het scherm toonde ontvanger, bedrag, valuta, vervaldatum en betalend bedrijf, een link naar de stukken en een goedkeurknop. Waarom een betaling was tegengehouden, stond er nergens. Dus werd gecontroleerd wat snel te controleren viel, zoals ieder van ons zou doen met vijfenvijftig regels en een cut-off om elf uur. De auditlog toonde vijfenvijftig vrijgaven door een bij naam genoemde persoon, en kon niet laten zien wat er was bekeken.

Finance scheidt al lang wie een betaling voorbereidt van wie haar doorvoert. Op diezelfde scheiding bouwen wij AI-workflows: de AI bereidt voor, een mens voert door. Of dat werkt, hangt af van het moment daartussen: wat de mens ziet als hem wordt gevraagd door te voeren, en hoe lang hij echt kijkt.

Eén verzoek per reden voor tegenhouden

Het systeem weet al waarom het de betaling tegenhield, dus het scherm hoort dat te zeggen, in plaats van de beoordelaar het probleem te laten zoeken. 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 dit bedrijf ooit aan deze ontvanger deed." Daaronder naast elkaar: het veld dat de stop veroorzaakte, de aangetroffen en de verwachte waarde. Dan de onderbouwing voor alleen dat punt. Het volledige record is één klik verder.

In die treasury begon een typisch verzoek met het besluit vetgedrukt: 86.400 EUR van het Spaanse bedrijf aan een vervoerder vrijgeven, of terugsturen naar het team dat leveranciersbetalingen voorbereidt. Dan de reden: de regel houdt alles tegen boven twee keer de grootste betaling van het bedrijf aan die vervoerder in twaalf maanden, en dat was 21.750 EUR. Dan de vorige betaling, 18.920 EUR in augustus voor twee weken transport, overige velden gelijk en ingeklapt. In het paneel met onderbouwing zaten het raamcontract voor een nieuwe seizoensroute en de oktoberboekingen bij de inkooporder. In seconden ziet een beoordelaar dat de sprong een reden heeft, een gecontracteerde en geboekte route, en dat verder niets bewoog.

Andere redenen krijgen andere verzoeken. Een ontvanger die nieuw is voor dit bedrijf maar al jaren door een zusterbedrijf wordt betaald, opent op die geschiedenis: een bekende relatie, geen lege pagina. Een valuta die het bedrijf nooit gebruikte, opent op de valuta, de koersbron en waarin het normaal betaalt. Twee redenen betekenen twee verzoeken. Stukken die niet te koppelen zijn, openen op wat ontbreekt.

Elk verzoek is engineeringwerk, dus we bouwen eerst voor de meest voorkomende stops. Zeldzame vallen terug op de recordweergave, gemarkeerd als noodoplossing zodat niemand die voor het af 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: de laatst vrijgegeven betaling aan dezelfde ontvanger vanuit hetzelfde bedrijf, of vanuit een zusterbedrijf als dit bedrijf hem nooit betaalde. Ongewijzigde velden zijn ingeklapt, gewijzigde gemarkeerd, zodat een bedrag ver buiten het gebruikelijke of een nieuwe valuta staat waar de blik het eerst valt. Het is wat een treasurer op een geprinte betaallijst zou opvallen, als er tijd voor was.

De zekerheidsscore van de AI 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) bevat een studie waarin zelfs een nietszeggend nauwkeurigheidscijfer het vertrouwen verhoogde. Beoordelaars vragen er toch om. We gebruiken de score waar hij geen oordeel kan sturen: om de wachtrij te sorteren, laagste eerst.

Samen goedkeuren is een eigenschap van de gevallen

Eén voor één vrijgeven is traag, en treasurers vragen in week één om een bulkknop. Juist daar wordt de beoordeling ongemerkt dunner, dus gevallen moeten zich ervoor kwalificeren.

Dat doen ze als ze om dezelfde reden stopten, op elk veld behalve het goed te keuren veld gelijk zijn aan hetzelfde eerdere geval, dezelfde valuta hebben en binnen een bedragbandbreedte vallen die de treasurer vaststelde. Twaalf betalingen aan één vervoerder vanuit drie bedrijven, allemaal tegengehouden omdat nieuwe seizoenstarieven ze boven hetzelfde eerdere geval tilden, zijn één besluit. Dezelfde vervoerder met twaalf verschillende redenen zijn er twaalf.

Elke afwijking krijgt een reden

Wijzigt een beoordelaar het voorstel van het systeem, dan vraagt het verzoek waarom, uit een korte lijst die we met treasury afspreken: bedrag buiten het contract afgesproken, verkeerd betalend bedrijf, dubbel met een eerdere betaling, splitsen of uitstellen, of anders met een notitie. Een korte lijst wordt veel betrouwbaarder ingevuld dan een vrij tekstveld.

Die redenen behoren tot de nuttigste gegevens die het systeem oplevert: welke regels voor tegenhouden fout zijn, welke leveranciersrelaties veranderen en, na een kwartaal of twee, welke soorten betalingen geen stop meer nodig hebben.

De beoordelingsinspanning wordt gemeten

We meten de beoordeling zelf: tijd per verzoek, geopende onderbouwing, gewijzigde voorstellen en betalingen die later worden teruggedraaid of teruggehaald. Niets daarvan beoordeelt mensen; het laat zien of de controle werkt.

Wordt op een beoordelingspunt wekenlang elk geval in seconden ongewijzigd goedgekeurd, dan voegt het geen oordeel toe. Of de gevallen hebben geen mens nodig, en een automatische controle moet de plaats innemen, of het verzoek toont niet wat de mens nodig heeft. Beide zijn ontwerpproblemen; om meer zorgvuldigheid vragen lost geen van beide op.

Vóór livegang werken beoordelaars in een testkopie van het systeem gevallen met bekende antwoorden door, waarvan sommige tegengehouden moeten worden, om te zien voordat er echt geld beweegt of het verzoek het foute antwoord zichtbaar maakt. Na livegang beoordeelt een tweede fiatteur van treasury elke week een kleine willekeurige steekproef van vrijgegeven verzoeken opnieuw, zonder het eerste besluit te kennen. Waar ze verschillen, kijken we eerst naar het verzoek. Het is de meest directe maat die we kennen voor of de beoordeling vangt wat ze moet vangen.

We letten op twee lijnen die samen dalen: tijd per verzoek en het aandeel gewijzigde voorstellen. Meestal heeft een beoordelaar dan geleerd dat het systeem meestal gelijk heeft, en verslapt het controleren. Dan verbergt één op de twintig verzoeken de voorgestelde actie tot de beoordelaar zelf heeft besloten. Onderzoekers noemen dat een cognitive forcing function. Buçinca, Malaya en Gajos van Harvard vonden in 2021 dat zulke ontwerpen overmatig vertrouwen in AI verminderden, en dat mensen de effectiefste als het minst prettig ervoeren. Daarom draait het alleen als de cijfers erom vragen, en het team weet waarom.

Goedkeuring wordt vastgelegd als elke financiële controle

De goedkeurder is nooit het systeem dat de run voorbereidde, en nooit de persoon die de betaling voorstelde. Elke goedkeuring wordt opgeslagen met beoordelaar, tijdstip, het verzoek precies zoals getoond, de geopende onderbouwing en de reden voor elke wijziging. Een auditor ziet wat de beoordelaar zag, niet alleen dat er werd geklikt. Om dezelfde reden bieden we geen goedkeuring per e-mailantwoord of chatknop: dat haalt het bewijs weg en houdt alleen de handtekening over.

De naam in de log moet iets betekenen

Een beoordelingspunt dat niemand leest, kan erger zijn dan geen, omdat het een vastlegging achterlaat dat iemand heeft gecontroleerd. Ontwerp het verzoek zo dat de naam in de auditlog beschrijft wat er werkelijk gebeurde.