A Financial Agent Must Show How It Reached Its Decision

In an audit, the opinion is the product, and the opinion is only as good as the basis behind it. I am Anirudh Veeraragavan, lead security engineer at Fieldguide. The question is what a decision-making process should look like when an agent does part of that work.

Consider bank reconciliation. An auditor compares the cash on a client’s books with the bank balance and explains differences, such as deposits in transit or outstanding checks. The goal is to test whether the financial position the client reports matches the evidence.

An agent could receive the books, a list of reconciling items, supporting evidence, audit methodology and prior-year examples. Previously reviewed audits could become an evaluation set, and a human reviewer could sign off on the result. That is a reasonable way to automate tedious, high-volume work.

Suppose the evaluations look excellent, users are happy and the product ships. Then an inspection asks why one specific audit procedure and one specific piece of evidence were sufficient. An aggregate score does not answer how the agent reached that particular decision.

Financial fraud shows why the consequences can be severe. In the Peregrine Financial Group case, Veeraragavan says, the claimed bank balance exceeded $200 million while only about $5 million was actually there. He uses it to explain why financial decisions need a basis that can be defended later.

The audit profession offers a useful standard: an experienced auditor who did not perform the work should be able to understand the test, the evidence and the decision. Applied to agents, that means another auditor should be able to follow what the agent did.

Veeraragavan groups the required controls into authorization, execution control, evidence provenance and evaluation integrity. They all depend on knowing when the agent should stop and a person should decide. He illustrates them with a fictional freight company’s 2026 bank reconciliation.

The fictional client has about $2.9 million according to the bank and $2.7 million on its books, with 41 items explaining the difference. The examples follow two checks and two deposits through the agent’s workflow.

First, a reviewer flags a check as an exception and signs the work. Days later, new information arrives and triggers the agent, which changes the item to “no exception.” Even if the new answer is right, the signature now appears on content the person did not review.

Authorization therefore depends on the object, its state and the time of the action, not just whether a tool call is permitted. An agent can draft a suggestion on an unreviewed item, but it should not silently overwrite a person’s reviewed work.

The second control is execution. Imagine rerunning the same work a year or two later and getting a different result. A generic log saying that the agent fetched evidence, reasoned and produced an answer is not enough to identify where the two runs diverged.

Record the run as a chain of identifiable steps, each with its inputs and outputs. Distinguish deterministic operations, such as fetching or matching, from model steps, such as extracting a field or reaching a conclusion. Then an individual step can be rerun and compared with the original.

In the example, comparing steps shows that the original run was right and the later run was wrong. The point is not merely to land on the correct answer: the record lets the reviewer show the path to it and investigate why another run differed.

The third control is evidence provenance. An agent cites “January bank statement, page two” while drawing a conclusion from the wrong account. In a large engagement, several documents can share that name; even a unique name does not tell a reviewer which version was used or who supplied it.

A citation should identify a specific document, version and content hash. Once the claim is tied to a concrete source, the system can enforce evidence rules—for example, accepting a statement obtained directly from the bank rather than one uploaded by the client.

Fourth, evaluate the evaluation data. A reviewed audit from last year is not necessarily a correct reference answer today. It may have been superseded, based on poor evidence or assessed under a methodology that has since changed.

In the illustrative evaluation, a 97% score hides different kinds of error. Four of nine apparent misses came from wrong reference answers, suggesting the agent did better on those examples. Twelve items marked as correct under old rules should now be exceptions, meaning the score also concealed real misses.

The agent needs to stop and ask a human when it tries to change signed work, a new run disagrees with an old one, or evidence fails the applicable rules. The reviewer should see what is wrong and where to investigate.

Escalations should be easy to verify, not necessarily easy to approve. If a system interrupts people constantly, automation bias can turn review into habitual acceptance. Flag exceptional cases and provide enough context for a meaningful decision, even when review takes time.

These controls work together. Without authorization, a signed answer can change underneath the reviewer. Without execution records, a correct answer cannot be reconstructed. Without evidence provenance, the source of a wrong answer can be unclear. Without sound evaluation data, a headline score can be misleading.

The same questions apply outside audit. A lender should be able to inspect why a loan was approved or declined; an anti-money-laundering team should be able to inspect the evidence behind closing or escalating an alert. For consequential financial decisions, “the model said so” is not a sufficient defense.