A bank rolls out AI for customer service and sees a real drop in response time within a quarter. Three months later, someone asks the question that should have come up on day one: could the same model, in the next project, also approve transfers or calculate interest? The answer is no, it shouldn’t — and not out of caution, but for a specific reason.

Why banking calls for a different approach

The banking sector operates under constant oversight, regular audits, and high expectations around being able to reconstruct a decision later — that’s not a matter of any single rule, but a whole set of principles that apply regardless of how automated a given process is.

Rather than pointing to specific regulations, it helps to hold onto the underlying principle: any decision with a real financial consequence has to be explainable, reproducible, and clearly attributable to a specific person or system. That principle — not a specific regulation — is what draws the line between what’s safe to automate without hard controls and what has to stay under oversight.

In practice, this means the question “can this process be automated” matters less than “what happens if the automation gets it wrong, and can that be explained later.” The answer to that second question splits banking processes into two clear groups.

Processes that automate well while keeping oversight

The first group covers processes where AI genuinely speeds things up, and a mistake is easy to catch and correct before it has any financial consequence:

  • Document preparation. Assembling loan applications, filling out forms from customer data, generating contract or letter templates from previously approved patterns — AI prepares the material and a human approves it before it’s sent or signed.
  • Request classification. Routing complaints, customer queries, or applications to the right department or queue is a task where a mistake costs, at worst, an extra redirect — not a real financial loss.
  • Data extraction. Reading data from statements, invoices, ID documents, or paper forms and getting it into a system — as long as the output goes on to further verification rather than straight into a decision.

Across all three, the common thread is the same: AI does the preparatory work, and a human checks the result before it carries any financial or legal weight.

Where the decision has to stay with a human or deterministic code

The second group covers processes where a mistake isn’t easy to undo, or touches a customer’s money directly — automating these without hard controls is a risk, no matter how well the model performs statistically:

  • Financial calculations. The amount of interest, fees, installments, or a tax liability has to come from explicit, versioned logic that produces the same result from the same inputs. That’s a job for a deterministic engine, not a language model.
  • Final credit decisions and risk assessment. AI can help organize data and flag whether an application meets certain criteria, but the final yes or no should stay with a human or a clearly defined decision rule.
  • Approving operations and checking internal compliance. Verifying that a transaction meets a bank’s internal rules is where accountability needs to be clearly assigned — to a specific person or rule, not to what the model judged at a given moment.

The common thread here: wherever a result has a direct financial or legal consequence, and someone might ask “why this decision” long after the fact, the decision belongs to code or to a human — never to a language model acting alone.

The principle that ties it together

The split described above comes down to one principle we apply across all our AI implementations: AI reads, classifies, and proposes, while code calculates and decides in anything critical. We covered it in more depth in AI proposes, code decides: why we separate the two roles, and expanded on it for the financial sector specifically in where decisions must stay deterministic. In banking, this principle isn’t an add-on — it’s the starting condition for designing automation safely at all.

A good complement to this split is the model of escalating borderline cases to a human, which we wrote about in decision automation with human escalation — instead of “automate everything or nothing,” the system acts automatically where it’s confident and hands the case off where it isn’t.

What this looks like in practice

We apply the same pattern in our own accounting product. In Qkwit, AI reads documents — invoices, confirmations, statements — but a deterministic engine calculates taxes and contributions, not the model. AI never “decides” the amount owed — its role stops at reading and classifying, and code takes over from there, calculating according to the same checkable rules every time. That’s the same split we’d propose to banks and financial institutions: AI at the reading and classification stage, code at the calculation and decision stage.

In short

In practice, the best starting point is mapping processes into these two categories before any tooling decision gets made. For each process, it helps to ask one question: is the mistake easy to catch and fix, or does it touch a customer’s money or a compliance rule directly — the answer points straight to which group the process belongs in. We apply the same split of roles across all our AI implementations, not just in financial services — more on the AI page.

Frequently asked questions

Can AI be used in banking at all?

Yes, and quite broadly — as long as its role is limited to reading, classifying, and preparing material, while decisions with a real financial consequence are made by deterministic code or a human.

How do you check whether a given process is a good fit for automation?

Ask what happens if AI gets that specific process wrong. If the mistake is easy to catch and has no direct financial consequence, the process is a good fit for automation with oversight.

Does automating request classification require human review of every decision?

No — oversight can focus on borderline or unusual cases, while routine classifications run automatically.

Why shouldn’t a language model handle financial calculations?

Because a model can naturally phrase its output a little differently each time, while financial calculations need explicit, repeatable logic that can be shown step by step during an audit.

Where should a bank or financial institution start with automation?

By mapping out processes and splitting them into those where a mistake is cheap and reversible, and those where the decision has to stay with code or a human — tool choices come after that, not before.