An exception agent you can audit

The first question any risk function asks about an AI feature in a finance system is not how accurate it is. It is: what happens when it is wrong, and how would we know?

That question rules out most of the obvious designs. It does not rule out the useful ones.

The boundary

There is exactly one rule in our architecture that never bends: the model proposes and explains, deterministic code verifies and posts. Everything else is a detail.

The verification layer matters more than the model. A proposed classification is checked against a closed list of reason codes — a code that is not in the library is rejected outright rather than passed through as free text. A proposed posting is checked for balance, for permitted accounts, and against a value ceiling. Anything failing verification is discarded and the exception is presented unexplained, which is exactly the state it would have been in without the model.

The worst outcome of a model failure should be the absence of help, never the presence of a wrong answer that looks like help.

Earning autonomy, one reason code at a time

Full automation on day one is indefensible, and permanent full manual review makes the whole exercise pointless. The middle path is autonomy that is granted narrowly, earned through evidence, and revoked automatically.

1. 01A new reason code always requires human approval, whatever the confidence score attached to it.
2. 02After three consecutive approvals with no edits, that specific code becomes eligible for unattended posting.
3. 03Eligibility is still bounded by a value ceiling and a daily volume cap, both set by the customer.
4. 04Any edit to a proposal resets the counter to zero and feeds the correction back into the rule.
5. 05Classes touching customer money — chargebacks, returns, unidentified cash — are never eligible, at any confidence, forever.

That fifth point is the one that gets debated, and it should not be. The value of automating a chargeback posting is a few minutes of analyst time. The cost of getting one wrong is a customer whose balance is incorrect and a control failure to report. That trade is not close.

What has to be recorded

An auditor arriving eighteen months later will ask what was known at the time and who decided what to do about it. Answering that requires more than logging the outcome.

• The input records, hashed on ingestion, retained exactly as received.
• The engine version and the full parameter set in force for that run.
• Every pass attempted against the record, and why each one declined it.
• The proposal as generated, including the confidence and the evidence cited.
• Whether a human accepted, edited or rejected it, which human, and when.
• The posting as it actually landed, linked to all of the above.

Rules change over time, which creates the subtlest problem in the whole design. Replaying an old run under today's rules produces a different answer and proves nothing. Runs must replay at the engine version and parameter set that produced them, which means versioning the rules as data and keeping every version indefinitely.

Confidence, honestly reported

Confidence scores are widely abused. A number attached to an output that was not calibrated against outcomes is decoration, and reviewers learn to ignore it within a week.

Ours is derived, not asserted. A deterministic match carries the confidence its pass earns — 100% for exact agreement on reference, amount, currency and date; a scored value for a repaired reference; a fixed lower band for a value-only pairing that nothing else corroborates. Because the score comes from the mechanism rather than from a model's self-assessment, it means the same thing every time, and a reviewer can develop an accurate intuition about it.

For classifications, we report the model's confidence separately from the engine's, clearly labelled, and we never combine them into a single figure. Two different kinds of uncertainty averaged together produce a number that describes neither.

The point

None of this is a constraint on what the product can do. It is the reason a regulated institution can put it in front of an examiner. An exception agent that explains breaks in plain language, cites its evidence, drafts a balanced entry and then stops — waiting for a person to agree — is more useful than one that posts autonomously, because the second one cannot be deployed at all.