AI is genuinely good at reading documents, classifying transactions, and summarizing long reports. In financial services, though, that’s only half the picture — the other half is who, or what, actually makes the decision, and whether that decision can be reproduced a month or a year later. In a regulated industry, that line isn’t a technical detail; it’s the condition that makes deploying AI safe in the first place.
Why a regulated industry treats AI differently
Banking and financial services operate under constant oversight and regular audits — every decision of consequence has to be explainable and reproducible, with clear accountability attached to it. That’s not a matter of good intentions; it’s the foundation the whole financial system’s trust rests on. Bringing AI into that environment means designing the solution so that reproducibility and accountability stay intact, no matter how much of the process gets automated.
What “deterministic decision” actually means
A deterministic decision is one that, given the same inputs, always produces the same output — today, next month, a year from now, regardless of who runs it. An engine calculating interest, a fee, or a tax liability has to follow exactly the same logic every single time, and that logic has to be something you can walk through step by step.
A language model works differently by nature. Even given the same question, it can phrase its answer a little differently each time, and its reasoning isn’t a set of explicit, versioned rules — it’s a pattern learned from a huge dataset. That doesn’t make it a worse tool. It makes it the wrong tool for a specific role: calculating financial obligations or making a final credit decision.
Where AI genuinely helps in finance
There’s plenty AI can speed up without raising audit concerns: reading and classifying documents, extracting data from invoices and statements, flagging transactions for further review, summarizing long reports, or drafting customer communications. In every one of these cases, AI proposes or prepares material, while a person or a deterministic system makes the final call.
We see this daily in our own accounting product. In Qkwit, AI reads documents and invoices, but a deterministic engine calculates taxes and social security contributions — the model doesn’t guess at figures, it feeds inputs into calculations that a piece of code runs the same way every time. We covered a similar mechanism in our piece on AI accounting for sole proprietors — the same logic carries straight over to financial services, just with the stakes raised.
Where the decision has to stay in code
Anywhere a result has a direct financial or legal consequence, and anywhere someone might reasonably ask “why this exact result” months later, the decision should be made by deterministic code, not the language model itself. That covers interest and fee calculations, risk-scoring thresholds, compliance checks against internal rules, and final sign-off on a transaction.
That’s exactly the principle behind all our AI implementations: the model reads, classifies, and proposes; code calculates and decides on anything critical. We laid this out in more depth in AI proposes, code decides: why we separate the two — in financial services, that separation isn’t just good practice, it’s a hard requirement.
What breaks when that line gets blurry
The risk isn’t that AI enters a financial process at all — it’s that a team starts treating the model’s answer as a finished decision rather than a proposal awaiting approval. In practice, this shows up when a model is asked to “assess the risk of this transaction” without a clearly defined, separate step that translates that assessment into a concrete, repeatable decision rule. Two seemingly identical transactions can then get handled differently, and nobody can point to the rule that explains why — because there wasn’t one, just the model’s impression at that particular moment.
Good architecture keeps these steps physically separate: the model produces an assessment or recommendation and records it as an input, while a separate, versioned set of rules decides what to do with that input. If the rule changes, the change is deliberate, documented, and traceable — which is not something you can say about a model “changing its mind” between one query and the next.
Auditability and accountability
A deterministic engine has one huge advantage for audit purposes: its logic is explicit, versioned, and can be walked through step by step, no matter when a given case gets reviewed. A language model, even a very good one, is harder to reproduce identically after months have passed — and if the model has been updated in the meantime, reproducing an old answer exactly can be practically impossible.
This is why a model with human escalation for edge cases works well in practice — we covered this in the context of decision automation with human escalation as the safer default. In financial services, that principle pairs with the deterministic-engine rule: code handles the clear, repeatable cases, borderline cases go to a person, and AI supports both stages without replacing either one at the moment that matters.
What this means for system architecture
In practice, this means that when designing a system for a financial institution, it’s worth drawing the line between the reading layer (AI) and the decision layer (code) from day one — and logging each one separately: what the model proposed, and what decision the engine ultimately made. That way, if a regulator or a customer ever raises a question, you can show exactly what the decision was based on, without pointing back to “the model said so.”
It’s also worth remembering that a language model update running in the background should never change the outcome of a financial calculation. If it does, that’s a sign the decision logic is still sitting in the wrong part of the architecture.
Our experience in IT for banking and financial services
We’ve delivered IT projects for the banking and financial services sector for years, so we understand the specifics of audit requirements and compliance, and how carefully automation needs to be approached in this industry — without getting into details of specific client engagements. We apply the same caution in our own products: in Qkwit, AI reads documents while a deterministic engine calculates obligations, following exactly the principle we describe in our AI implementation offering.
FAQ
Can AI make financial decisions at all? It can prepare inputs, classify, and propose — but the final decision on an amount, fee, or obligation should be made by deterministic code that can be reproduced identically at any point in time.
What’s the difference between “AI proposes” and “AI decides”? In an “AI proposes” setup, the language model reads, classifies, or drafts, and a person or a separate deterministic system approves the decision. In an “AI decides” setup, the model sets the outcome itself — which is risky in a regulated industry, since it’s hard to reproduce and explain later.
What does this look like during an audit? A deterministic engine shows its logic step by step, regardless of when a case is reviewed. That’s far simpler to explain than a language model’s answer, whose behavior may have changed after an update.
Do AI models change, and is that a problem for audits? Yes, models get updated over time, which makes it harder to reproduce an old answer exactly. That’s why we keep critical calculations in code that doesn’t change without a deliberate, versioned decision.
Where should a regulated business start with AI? With a process audit that shows where AI can genuinely help — reading, classification, summaries — and where the decision has to stay with deterministic code.
Thinking about how to do this safely at your company?
If you’re considering AI in a regulated business and want decisions to stay auditable and reproducible, we’re happy to talk through your specific situation — get in touch.