Deterministic vs generative AI comes down to one property: deterministic software gives the same output every time it is given the same inputs, and generative AI composes a fresh answer each time, which is usually close and occasionally wrong. Agentic AI in banking — software agents that take a job end to end, finding the documents, reading them and producing something a person can act on — is built on generative models, so the question is not whether agents can do operations work but where the deterministic line falls. The honest line is between reading and arithmetic. An agent that reads a credit agreement and tells you the day-count clause is on page 31 is doing work it is good at. An agent that is asked for the interest figure itself is being asked to generate a number, and a generated number cannot be replayed. Botminds' Loan Interest & Fee Calculation is built on that split: its agents read the agreement, collect the published fixings and read the transactions, and the sixth of its six agents is a deterministic calculator, the only one that never reads, which does the sums.
This page is for the operations or risk executive deciding whether agents may go near a billing run, and for the model-risk reviewer who will be asked to sign. The worked figures come from a fictional sample bank inside the solution; the supervisory language comes from the Federal Reserve, the OCC and NIST, linked where it appears.
What is the difference between deterministic and generative AI?
Deterministic software follows fixed rules, so the same inputs always produce the same output and anyone can re-run it to check. Generative AI produces its output by predicting it, so two runs on the same inputs can differ, and the only way to check a generated figure is to work it out again some other way. Both have a place in a bank; the mistake is letting the second do the first one's job.
An agent, in this sense, is a program given a goal, a set of tools and a boundary. It decides which tool to use next — open this document, look up that published rate, read this transaction history — and keeps going until it has what the goal asked for. That is a real advance over a model that answers one prompt, because most operations work is not one question. Checking a quarterly loan bill means finding the right version of a credit agreement among its amendments, reading perhaps twelve pricing terms out of sixty pages, finding the fixing for each reset date, and reconstructing a balance that moved three times.
What makes it work in a bank is also what limits it. Each of those steps has a verifiable answer sitting in a document, a published rate table or a transaction history. An agent's output can be pointed at its evidence and checked. The moment an agent is asked for something with no such anchor — a number it composes rather than finds — nobody can check it except by doing the work again.
The line that matters: reading a clause is not producing a number
Put the two halves of a billing check side by side and they behave differently under pressure. Reading tasks fail visibly and locally: the agent cites the wrong clause, and the citation is right there to be disagreed with. Arithmetic tasks fail invisibly and systematically: a figure that is $2,691.55 too high looks exactly like a figure that is right, and it will be wrong the same way on every bill until somebody notices.
Two kinds of work on one loan bill, and how each one fails
Reading — an agent's work: A term, with the clause and page it came from. "Term loan interest: 30/360, §2.4(c), page 31."
Arithmetic — deterministic work: A figure, from inputs that are already fixed: days, balance, rate, basis.
Reading — an agent's work: Open the clause and read it. A reviewer who disagrees can point at the sentence.
Arithmetic — deterministic work: Run the same inputs again and compare. The same inputs must give the same figure, every time.
Reading — an agent's work: A term that disagrees with the document, caught by anyone who opens it.
Arithmetic — deterministic work: A bill that is quietly wrong, by a little, on every loan with that set-up.
Reading — an agent's work: The reviewer, before anything is sent.
Arithmetic — deterministic work: The borrower’s controller, a quarter or four later.
Reading — an agent's work: One click to the clause.
Arithmetic — deterministic work: A rebuild of the whole period, by hand, in a spreadsheet.
Reading — an agent's work: Document controls: is the right version being read, is the citation real.
Arithmetic — deterministic work: Model and calculation controls: inputs, method, replay, independent re-computation.
The practical consequence is that the two halves want different controls, and mixing them means the whole thing inherits the heavier set. Keep them apart, and the reading half can be governed as document work while the arithmetic half is governed as arithmetic — which is far easier to prove, because arithmetic can be run again.
Can generative AI calculate loan interest accurately?
A language model can produce an interest figure that is usually close and sometimes wrong, and "usually close" is not a standard a billing run can be held to. The right answer is that AI should not calculate loan interest at all. It should assemble the inputs — which clause governs, which published fixing applies to this period, what the balance was on each day — and hand them to ordinary arithmetic, which is accurate by construction and can be re-run by anyone with the same inputs.
Accuracy also has a definition worth borrowing. NIST's AI Risk Management Framework takes it from an international standard, and in substance it is how close a result comes to the true value, or the value accepted as true. On a loan bill the true value is not a matter of opinion. It is what the agreement says, applied to the days and the balance that actually occurred, at the rate that was actually published. There is one right answer, and a system either reproduces it or does not.
That is why the split pays for itself twice. It removes the one task where a generated answer cannot be checked, and it turns the remaining tasks into ones where a wrong answer is visible to the first person who looks. The day-count error worked through in what the 365/360 interest method costs a borrower is a good test of the idea: the figure was wrong because a term was wrong, and the term was a reading question all along.
Is generative AI a model under SR 26-2? What the 2026 guidance says
Not in the guidance's own terms, and neither is the arithmetic — which is exactly why the split has to be drawn by the bank. On 17 April 2026 the Federal Reserve, the OCC and the FDIC replaced the 2011 model risk guidance, SR 11-7, with SR 26-2. The revised guidance narrows the definition of a model to a complex quantitative method that applies statistical, economic or financial theories to produce quantitative estimates, and it excludes two things outright: simple arithmetic of the kind found in spreadsheets, and deterministic rule-based processes with no such theory behind them.
A footnote then puts generative and agentic AI models outside the guidance's scope altogether, as novel and rapidly evolving, and says a bank's own risk management and governance practices should decide the controls for tools the guidance does not cover. (How a bank decides what is and is not a model under the new definition is worked through in a sibling guide on SR 26-2's model definition.)
Where each half of a billing check sits after SR 26-2
The generative half — reading: Finds the clause, the agreement version, the fixing date and the transactions, and cites each
The deterministic half — arithmetic: Turns days, balance, rate and basis into a figure, rounded as the agreement says
The generative half — reading: Generative and agentic AI are outside its scope; the bank’s own governance decides the controls
The deterministic half — arithmetic: Simple arithmetic and deterministic rules are excluded from the definition of a model
The generative half — reading: The bank’s AI governance: version control, citation checks, human sign-off
The deterministic half — arithmetic: Ordinary calculation controls: specification, test cases, replay, independent re-computation
The generative half — reading: Open the cited clause and read it
The deterministic half — arithmetic: Run the same inputs again and compare to the cent
Read that against a system asked to produce an interest figure from a loan agreement. If a generative agent composes the figure, the bank has put a number on a borrower's bill that comes from the one kind of tool the guidance declines to cover, and that no examiner's checklist will validate for it. If a deterministic calculator produces the figure from cited inputs, the number sits in the plainest category there is — arithmetic — and the generative part is confined to reading, where every output carries the sentence it came from. Excluded from the definition does not mean ungoverned: a calculation engine still has to be specified, tested and controlled. But arithmetic can be tested exhaustively against known answers, and that is a far cheaper kind of proof than a statistical one.
The six jobs on a billing run, and which of them an agent may hold
Decomposition is the whole technique. A billing check looks like one task and is six, and only five of them are reading. In the solution each is a separate agent with its own boundary, and the sixth — the arithmetic — is not an agent at all.
One bill, six jobs: five readers, one calculator, two signatures
Agent
Agreement terms readerReads the pricing and fee terms from the credit agreement and its amendments in date order, each with its clause and page.
Never: fills a term the documents do not state.
Agent
Rate fixing collectorWorks out each fixing date the agreement defines, pulls the published fixing for it and tests the floor.
Never: estimates or interpolates a rate. A missing fixing stops the calculation.
Agent
Transaction readerReads draws, repayments, amortization, letters of credit and payments from the transaction history.
Never: uses the system’s billed interest as an input.
Agent
Independent calculatorSplits the period wherever the balance or the rate changes and rebuilds every accrual period, rounded as the agreement says.
Never: generates a number. Deterministic arithmetic only.
Agent
Difference explainerCompares the recalculation with the system bill line by line and finds the term whose set-up differs.
Never: closes a difference it cannot reproduce.
Agent
Dispute and letter drafterChecks each claim in a borrower or participant letter against the agreement and drafts the answer or the correction.
Never: sends a letter or a credit.
A person decides
Loan servicing officerOpens each held bill, reads the clause and the arithmetic, corrects it and signs credits up to the officer limit.
A person decides
Loan operations supervisorCo-signs credits above the officer limit and approves any change to the core system’s set-up.
Notice what the calculator is not allowed to see. The transaction reader never uses the system's billed interest as an input, which means the recalculation cannot be contaminated by the thing it is checking. That is the oldest control in the book, and the OCC's commercial loans examination asks for it in so many words: "Are any independent interest computations made and compared or tested to initial interest record by persons who do not also: – Issue official checks or drafts singly? – Handle cash?" An independent computation is only independent if it does not start from the answer.
What an agent may never do, written as rules rather than hopes
A limit that lives in a prompt is a hope. A limit worth putting in front of a reviewer is one the system enforces and one you can demonstrate failing — ask for a bill on a loan whose August fixing is missing, and watch the run stop rather than produce a plausible figure.
Six limits, and the failure each one is there to prevent
| The rule | What happens when it fires | The failure it prevents |
|---|---|---|
| No term is filled that the documents do not state | The term is left open and the bill is flagged for a person, with the pages that were read. | A confident default — Actual/360 because most revolvers use it — quietly standing in for a clause nobody found. |
| No rate is estimated or interpolated | A missing published fixing stops the calculation outright. | An interpolated rate that is right to three decimals and wrong in the fourth, on every loan priced that day. |
| The system’s billed interest is never an input | The recalculation is built only from agreement, fixings and transactions. | A check that agrees with the thing it is checking. |
| Arithmetic is deterministic | Figures come from the calculator, never from a generated answer. | A number that cannot be reproduced, and therefore cannot be defended to a borrower. |
| A difference is not closed unless it can be reproduced | Replaying the system’s own set-up must reproduce the bill to the cent, or the difference stays open. | A plausible cause named for a difference that actually had another cause. |
| Nothing is sent | Letters, corrections and credits are drafted and wait for a signature. | An agent issuing a credit, or telling a borrower something the bank has not decided. |
Evidence an agent must produce with every answer
NIST's framework makes trustworthy AI depend on accountability, and accountability depend on transparency. In operations that cashes out as a simple test — can the person who signs see, without leaving the page, everything the answer rests on? For one line of one loan bill, that is six things.
What one recalculated line carries with it
The clause
On this line§2.4(c), page 31 of the amended and restated credit agreement of 3 April 2026
Why a signer needs itSays what the arithmetic was supposed to be: a 360-day year of twelve 30-day months.
The agreement version
On this lineAmended and restated, 3 April 2026
Why a signer needs itSays which paper governed on the billing date, when a loan has three amendments.
The rate and its date
On this lineTerm SOFR 1-month, 3.86192%, published 28 August
Why a signer needs itSays the number was read from a published fixing, not estimated.
The transactions
On this lineDraw 14 August, amortization 1 September, repayment 18 September
Why a signer needs itSays where the balance changed, and therefore where the period was split.
The arithmetic
On this line7,814,177.42 × 6.20% × 60 ÷ 360 = 80,746.50
Why a signer needs itCan be checked on paper by the officer who signs, with no system in the way.
What did not apply
On this lineFloor not reached; no Event of Default in the quarter
Why a signer needs itNames the tests that ran and passed, so silence is not mistaken for absence.
The stamped total: recalculated against billed, with the checks that did not apply
The last row of the table matters more than it looks. Most systems tell you what applied. Very few tell you what was tested and did not apply, and that is exactly the list a borrower's controller will raise three months later — was the floor in play, was there a default rate running, did the letter of credit count against the line. The related question of what counts as usage is worked through in how an unused line fee is actually calculated.
How to validate it: test sets, replay and effective challenge
Validation has a definition too, which NIST borrows from ISO 9000: objective evidence that the system meets the requirements of the specific use it is put to. For a billing check the objective evidence is unusually easy to come by, because the bank already owns thousands of answered examples: the bills it has already sent, and the disputes it has already settled.
Replay is the second half, and it is the part that turns a named cause into a proven one. In the solution a difference counts as explained only when re-running the receipt with the core system's own set-up reproduces the original bill to the cent. If it does not reproduce, the stated cause is wrong — there is something else in the bill — and the difference stays open rather than being closed with a plausible story.
Replay: the test that separates a named cause from a proven one
The third half, if a thing may have three, is the reviewer. Supervisors have long called this effective challenge — critical analysis by objective, informed people who can find a system's limits and get them changed — and SR 26-2 keeps the idea for the models it covers. A bank that applies it to an AI tool outside that scope is choosing to, which is the right choice. Effective challenge of a billing check means handing someone a quarter of real bills and letting them look for the differences the system did not find — the false negatives — not only reviewing the ones it did. A system that is only ever judged on what it flags is being graded by itself.
Questions to ask a vendor before an agent touches a bill
These are the eight we would put, in the order we would put them. Most can be answered in a live session with the bank's own files, and a vendor who needs to come back to you on the first three is telling you something.
Eight questions before an agent is allowed near a billing run
- Which figures on this page were generated, and which were calculated?
If the answer is not immediate and absolute, the line between reading and arithmetic has not been drawn.
- Run it twice on the same inputs. Are the figures identical?
Deterministic arithmetic gives the same answer every time. Anything that drifts is a model, and needs the governance of one.
- Show me a run where an input was missing.
The right behaviour is to stop and say which fixing is missing, not to produce a number and a caveat.
- For this line, show me the clause, the page and the agreement version.
A citation that cannot be opened is a claim. A reviewer should be able to disagree with the sentence.
- Prove the cause of this difference by reproducing the original bill.
Naming a cause is cheap. Reproducing the bill to the cent with the old set-up is the proof.
- What does the system do that the agreement is silent about?
Rounding, calendars and fee bases all have defaults. They should be your settings, written down and versioned, not a vendor’s convention.
- Who signs, and what cannot be sent without a signature?
Drafting is useful. Sending a credit or a letter without a named person behind it is not a feature.
- What is the record of a run, and how long does it survive?
Your auditor will ask what the system did in a quarter that closed two years ago. The answer should not be "we would have to re-run it".
One question deliberately not on the list is how accurate the system is in the abstract. A single accuracy percentage for a billing check is close to meaningless, because the population it was measured on decides the number. What to measure instead, and on whose data, is the subject of testing loan accounting software on bills you already sent.
Questions people ask
Is agentic AI deterministic?
No. An agent is software given a goal, a set of tools and a boundary, and the model that decides its next step is generative, so two runs can take different paths. What can be deterministic is what the agent hands its work to: in a billing check the agents read and cite, and a fixed calculator produces the figure, so the same inputs always give the same answer.
Can an AI agent be trusted to calculate interest?
It should not be asked to. The reliable arrangement is for agents to assemble the inputs — the governing clause, the published fixing for the reset date, the balance on each day — and for deterministic arithmetic to produce the figure. That way the same inputs always give the same answer, and any person with the inputs can check it on paper.
Does using an AI agent make our billing system a model under SR 26-2?
Not as the 2026 guidance draws it, which is why the bank has to decide. SR 26-2, which replaced SR 11-7 on 17 April 2026, excludes simple arithmetic and deterministic rule-based processes from the definition of a model and places generative and agentic AI outside its scope, leaving their controls to the bank's own governance. A calculator fed by cited inputs can be tested exhaustively; a generated interest figure cannot, whatever the guidance's scope.
What evidence should an agent produce with every answer?
Enough for the person who signs to check it without leaving the page: the clause and page relied on, which version of the agreement governed, the rate and its publication date, the transactions that moved the balance, the arithmetic written out, and the tests that ran and did not apply. The last one is the one most often missing and most often asked about later.
Does an agent need a human approval step?
For anything that leaves the bank, yes. In this solution the agents draft; a servicing officer signs corrections and credits up to a set limit, a supervisor co-signs above it, and changes to the core system's set-up are proposed by the agents, approved by a supervisor and applied by loan operations. The agents never send a bill, a credit or a letter.
How do you audit what an agent did?
By keeping the run itself rather than only its conclusion: which documents were opened, which fixings were used, which version of the agreement governed, what the arithmetic was, which bills were held, who released or signed each one. The practical test is whether a closed quarter can be re-explained two years later without re-running anything.