The first article in this series made one argument: a language model is a probability, finance is a certainty, and the gap between them is closed by a responsible person, not by a better prompt. This article is the practical half. It describes the standard we apply when we put AI into a system that moves or accounts for money.
The standard fits in one sentence. The model proposes, deterministic code decides, and a named person owns the outcome. Everything below is that sentence applied.
Rule 1: No model on the money path
Authorization, capture, void, refund, ACH origination, settlement, and posting to the system of record are executed by deterministic code. Idempotency keys on every mutating call. A compensating step defined for every step that touches real money, so a workflow that fails halfway cleans up automatically. Structured logs and tracing from the first commit.
This is the same discipline we already run for a live payment processor's production stack, with Go services, Temporal orchestration, and NetSuite as the system of record. AI does not change it. A model may be consulted before a money operation. It never executes one.
Rule 2: Models work at the edges, on judgment calls that used to be manual
The places where a model earns its keep in finance are the places where a person previously read something and formed an opinion:
- Reconciliation exception triage. Classifying unmatched items by likely cause (partial payment, duplicate, fee deduction, wrong customer) and routing them, so a person clears a sorted queue instead of a raw one.
- Document extraction. Pulling invoice numbers, amounts, and references out of remittance advices, lockbox images, and emailed PDFs, then handing the structured result to code that checks it against the ledger.
- Customer and support drafting. Writing the explanation for a declined card or a returned ACH in plain language, with a person pressing send.
- Anomaly flagging. Noticing that a merchant's settlement pattern changed, or that a batch is outside its historical range, and raising it before the bank does.
- Read-only questions over reporting data. "Which customers had a failed recurring charge twice this month?" answered from the data, never by writing to it.
Each of these produces a suggestion. None of them produces a posting.
Rule 3: Every model output is a proposal with a schema
The model's answer is a typed object, not free text. Code validates it: the amount matches an open invoice, the customer exists, the classification is one of the allowed values, the confidence is above the threshold set for that task. A proposal that fails validation goes to a review queue with the reason attached. It does not go to production, and it does not get retried until it passes.
Rule 4: A person is in the loop wherever money moves, by design
Human review is not a fallback for when the model is uncertain. It is the designed path for any action with financial effect. The model's job is to make that review fast: sorted, pre-filled, with the evidence attached. The person's job is to decide. That division is what makes the person responsible in the real sense, because they know what they approved and why.
Rule 5: Everything is reproducible after the fact
For every model call we keep the prompt, the model and version, the input, the output, the validation result, the decision, and who approved it. When an auditor, an acquiring bank, or a customer asks how a specific item was handled, the answer is a record, not a reconstruction. This is also what makes it possible to answer the only question that matters after an error: what did the system know, and who decided.
Rule 6: Evaluation before launch, with your data
Before any AI component ships, it runs against a harness built from the client's own historical cases: last year's exceptions, last quarter's remittances, the support tickets that were actually resolved. We measure the error rate per task and set the threshold with the client. If the component does not clear the bar, it does not ship, and the honest outcome of some engagements is "this part does not need a model."
Rule 7: Cost ceilings are designed in, not discovered on the invoice
Each task gets a budget. The smallest model that clears the evaluation bar is the one that runs. Repeated inputs are cached. Batch work is batched. Spend is reported per task, so the client knows what each capability costs and can turn it off. An AI feature whose cost cannot be predicted is a feature that has not been engineered yet.
Rule 8: Failure-mode analysis comes first
Before design, we write down what happens when the model is wrong: what the wrong answer looks like, what it would touch, who notices, and how long it takes them. If the answer is "a customer is charged twice and finds out on their statement," the design is wrong and we start over. If the answer is "an item lands in the review queue with the wrong label and a person re-labels it," the design is acceptable.
What this looks like in an engagement
A typical engagement starts with the process, not the model. We map where the manual judgment actually happens, measure how much of it there is, and fix anything in the underlying process that is broken before AI touches it. Then we pick one edge, build the proposal-validate-review loop around it, evaluate it on real history, ship it with a cost ceiling and a full audit trail, and operate it. The next edge follows once the first one has run clean for a month.
That is slower than dropping an agent onto the problem. It is also the only version of AI in finance that leaves somebody responsible, which is the only version we are willing to put our name on.