The Decision Card: Designing Human Approval for AI in Finance

Fifty-five held payments took a little over four minutes. We were sitting next to a group treasury manager while they worked through the morning's payment run for seven entities, the first run a new workflow had prepared, and afterwards we asked what they had looked at on each one. They thought about it and gave an honest answer: the total per entity, and whether the beneficiary names looked familiar.

The screen listed each held payment with its beneficiary, amount, currency, due date and paying entity, a link to the supporting documents and an approve button. It never said why a payment had been held. So the checking went to what could be checked fast, which is what any of us would do with fifty-five rows and a cut-off at eleven. The audit log recorded fifty-five releases by a named approver, and had no way of showing what had actually been looked at.

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

One card per reason for stopping

A screen showing the whole record asks the reviewer to go and find the problem. But the system already knows why it held the payment, so the screen ought to say. We replace the record view with a decision card built around a single question.

The card opens with one line: the decision needed, and why the payment stopped. "This payment is four times the largest this entity has made to this beneficiary." Under it, side by side, are the field that triggered the hold, the value found and the value expected. Then the evidence for that one point and nothing else. The full record is a click away, and it is not the first thing on screen.

In that treasury, a typical amount card opened with the decision in bold: release 86,400 EUR from the Spanish entity to a freight carrier, or send it back to accounts payable. The line under it gave the reason. The rule holds anything above twice the entity's largest payment to that carrier in the past twelve months, and that was 21,750 EUR. Next came the last payment, 18,920 EUR in August for two weeks of transport, with every other field matching it and folded away. The evidence panel held the framework contract for a new seasonal route and the October bookings on the purchase order.

A reviewer can see in a few seconds that the jump has a reason, a new route that was contracted and booked, and that nothing else about the payment moved.

Other holds get other cards. When a beneficiary is new to this entity but a sister entity has paid them for years, the card opens on that history, so the reviewer sees a known relationship instead of a blank. When an entity is paying in a currency it has never used, the card leads with the currency, the rate source and what the entity normally pays in. Two reasons for a hold mean two cards. And if the supporting documents could not be matched at all, the card opens on what is missing, with the payment line behind it.

Every reason for stopping needs its own card, and each one is engineering work. We build cards first for the reasons behind most holds. The rare ones fall back to the record view, clearly labelled as a fallback, so nobody takes it for the finished design.

Show what is different, not what is there

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

We leave the model'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) gathers studies on this, including one in which even an uninformative accuracy figure raised people's trust in the system's answers. Reviewers ask for the score anyway. We use it where it can't anchor a judgement, to sort the queue with the lowest first.

Batching is a property of the cases

Releasing payments one at a time is slow, and treasurers tend to ask for a bulk release button in the first week. Bulk approval is also where review quietly thins out. So the screen doesn't offer it as a feature; cases have to qualify.

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

Every override carries a reason

When a reviewer changes what the system proposed, the card asks why, from a short list we agree with treasury: amount agreed outside the contract, wrong paying entity, 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.

Once the system is live, those reasons turn out to be some of the most useful data it produces. They show us which hold rules are wrong and which beneficiary relationships are changing. Over a quarter or two they also show which payment types should stop being released without a hold.

Review effort is measured

We measure the review itself: time on each card, whether the evidence panels were opened, how often the proposal is changed, and how often a release is later reversed or recalled. None of this is used to rate people. It tells us whether the control works.

If every case at a review point is approved unchanged in a few seconds, week after week, that review point adds no judgement. Maybe the cases don't need a person, and an automated check should take its place. Or the card isn't showing what the person needs. Both are design problems, and asking reviewers to be more careful solves neither.

Before go-live, in a shadow environment, reviewers also work through cases with known answers, some of which should be held. That shows, before any 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, without seeing the first decision. Where the two disagree we look at the card before anything else. It is the most direct measure we have found of whether review catches what it is there to catch.

The pattern we watch for is two lines falling together: time per card, and the rate at which proposals get changed. Usually it means a reviewer has learned that the system is mostly right, and that is when checking tends to slip. When we see it, 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 designs like this reduced overreliance on AI, and that people rated the designs that reduced it most as the least pleasant to use. We take both findings seriously, which is why it switches on when the numbers call for it rather than running all the time, and why we tell the team what it is for.

Approval is recorded like any finance control

The approver is never the system that prepared the run, and never the person who proposed the payment. Each approval is stored with the reviewer, the time, the card exactly as it was shown, the evidence opened and the reason for any change. When an auditor asks how the control operated, we can show what the reviewer saw, not only that they clicked.

For the same reason we don't offer approval by email reply or a button in a chat window. That strips the evidence out of the decision and keeps just the signature.

The name in the log should mean something

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