The Decision Card: Designing Human Approval for AI in Finance

Fifty-five held payments took a little over four minutes. We sat beside a group treasury manager clearing the morning's payment run for seven group companies, the first run a new workflow had prepared, then asked what they had checked on each. The honest answer: the total per company, and whether the payee names looked familiar.

The screen listed payee, amount, currency, due date and paying company, a documents link and an approve button. It never said why a payment was held. So the checking went to what could be checked fast, as it would for any of us with fifty-five rows and a cut-off at eleven. The audit log recorded fifty-five releases by a named approver, and could not show what had been looked at.

Finance has long separated who prepares a payment from who commits it. We build AI workflows on the same split: the AI prepares, a person commits. Whether that works comes down to the moment in between: what the person sees when asked to commit, and how long they really look.

One card per reason for stopping

The system already knows why it held the payment, so the screen should say, instead of leaving the reviewer to find the problem. We replace the record view with a decision card built around one question.

The card opens with one line: the decision needed, and why the payment stopped. "This payment is four times the largest this company has made to this payee." Under it, side by side: the field that triggered the hold, the value found and the value expected. Then the evidence for that point alone. The full record is a click away.

In that treasury, a typical card opened with the decision in bold: release 86,400 EUR from the Spanish company to a freight carrier, or send it back to the team that prepares supplier payments. Then the reason: the rule holds anything above twice the company's largest payment to that carrier in twelve months, which was 21,750 EUR. Then the last payment, 18,920 EUR in August for two weeks of transport, other fields matching and folded away. The evidence panel held the framework contract for a new seasonal route and the October bookings on the purchase order. In seconds a reviewer sees that the jump has a reason, a route contracted and booked, and that nothing else moved.

Other holds get other cards. A payee new to this company but paid by a sister company for years opens on that history: a known relationship, not a blank. A currency the company has never used opens on the currency, the exchange rate source and what it normally pays in. Two reasons mean two cards. Documents that could not be matched open on what is missing.

Each card is engineering work, so we build first for the commonest holds. Rare ones fall back to the record view, labelled as a fallback so nobody mistakes it for the finished design.

Show what is different, not what is there

In our experience reviewers are quicker and more accurate comparing than reading. So each card sets the payment beside its nearest precedent: the last released payment to the same payee from the same company, or from a sister company if this one never paid them. Unchanged fields collapse, changed ones are highlighted, so an amount far outside the usual range or a new currency sits where the eye lands first. It is what a treasurer would spot on a printed payment list, given the time.

We leave the AI's confidence score off the card. A reviewer who sees a high number tends to check less. Microsoft's literature review on overreliance on AI (Passi and Vorvoreanu, June 2022) includes a study where even an uninformative accuracy figure raised trust. Reviewers ask for the score anyway. We use it where it can't anchor a judgement: sorting the queue, lowest first.

Batching is a property of the cases

Releasing payments one by one is slow, and treasurers ask for a bulk release button in week one. Bulk approval is also where review quietly thins out, so cases have to qualify for it.

They qualify when they stopped for the same reason, match the same precedent on every field but the one being approved, share a currency, and sit in an amount range the treasurer set. Twelve payments to one carrier from three companies, all held because new seasonal rates pushed them past the same precedent, are one decision. The same carrier with twelve different reasons is twelve.

Every override carries a reason

When a reviewer changes the system's proposal, the card asks why, from a short list agreed with treasury: amount agreed outside the contract, wrong paying company, duplicate of an earlier payment, split or defer, or other with a note. People fill in a short list far more reliably than a free-text box.

Those reasons are some of the most useful data the system produces: which hold rules are wrong, which supplier relationships are changing and, over a quarter or two, which payment types no longer need a hold.

Review effort is measured

We measure the review itself: time per card, evidence opened, proposals changed, and releases later reversed or recalled. None of it rates people; it shows whether the control works.

If every case at a review point is approved unchanged in seconds, week after week, it adds no judgement. Either the cases don't need a person, and an automated check should replace it, or the card isn't showing what the person needs. Both are design problems; asking for more care solves neither.

Before go-live, in a test copy of the system, reviewers work through cases with known answers, some of which should be held, to see before real money moves whether the card makes the wrong answer visible. After go-live a second treasury approver re-reviews a small random sample of released cards each week, blind to the first decision. Where they disagree we look at the card first. It is the most direct measure we have found of whether review catches what it is there to catch.

We watch for two lines falling together: time per card and the rate of changed proposals. It usually means a reviewer has learned the system is mostly right, and checking slips. Then one card in twenty hides the proposed action until the reviewer has made their own call. Researchers call this a cognitive forcing function. Buçinca, Malaya and Gajos at Harvard found in 2021 that such designs reduced overreliance on AI, and that people rated the most effective ones the least pleasant to use. So it runs only when the numbers call for it, and the team knows why.

Approval is recorded like any finance control

The approver is never the system that prepared the run, nor the person who proposed the payment. Each approval is stored with the reviewer, the time, the card exactly as shown, the evidence opened and the reason for any change. An auditor can see what the reviewer saw, not only that they clicked. For the same reason we don't offer approval by email reply or a chat button: it strips out the evidence and keeps just the signature.

The name in the log should mean something

A review point nobody reads can be worse than none, because it leaves a record saying someone checked. Design the card so the name in the audit log describes what actually happened.