What a governed AI system for banking actually requires

A governed AI system for banking needs four things in place at once: verified facts about the client, including what is still unknown; institutional assets that the bank owns and can change; deterministic execution; and an explanation written for each client. Governance also has to be part of how the system runs from the very first step. If one of the four is missing, what you have is a supervised system, which is a much weaker thing to put in front of a regulator.

Plenty of systems are described as governed today. Usually that means a person reviews what the model produced before a client sees it. Review is a useful control and banks should keep it. It still happens at the very end, and the reviewer rarely has any way to see how the output was put together.

Why isn't human review enough?

Review tells you whether an answer looks right, which is a different question from whether it was produced correctly.

A reviewer who approves a recommendation is judging a conclusion. They aren't checking that the liquidity threshold was applied, that suitability was assessed, that the figures were current, or that the same client with the same facts would get the same result tomorrow. At a hundred recommendations a day, the only way to scale review is to add reviewers, and governance has to scale without that.

Professional review, supervisory approval, escalation and override authority all still matter. They cover one part of governance, and the rest has to be built into the system itself.

What does “verified facts” mean in practice?

It means the system keeps track of what it knows about a client and what it still doesn't know.

Each fact comes with four things attached: where it came from, how recent it is, how confident the system is in it, and what is missing around it. People tend to overlook the last one, and it is often the one that matters most.

Take a client who is buying a home. The bank has verified their income, cash, investments, liabilities and stated liquidity needs, but it doesn't know how much they plan to spend on renovation. A system built to always produce an answer will estimate that figure. A governed system stops and asks for it first. We describe that step as “not yet, ask this first”.

A gap in the data is a good reason to pause. A system that always returns something gives you no signal in the one case where it shouldn't have answered at all.

What are institutional assets, and why do they matter?

An institutional asset is part of the bank's own expertise, written down in a form the system can execute. That covers liquidity rules, financing criteria, suitability requirements, product requirements, calculations, approval thresholds, approved guidance and the routes a client can take to act on it. Where they apply, Sharia requirements belong here too, as one more set of rules the institution defines. The model never decides what is permissible, because that decision stays with the institution.

This step is often skipped, and skipping it changes what the bank ends up owning.

Generative AI is very good at helping to build these assets. It can read unstructured policy documents, interpret them, suggest a structure and write a first draft. People review and approve the result before the system uses it. Generative AI shouldn't be making these rules up while a client waits for an answer.

A useful question for any vendor is what the bank owns once the model has done its work. Many setups leave the bank with a log of responses and little else. A governed approach leaves it with assets it can inspect, change and reuse, so its expertise is kept in a form the bank controls.

What does deterministic execution actually mean?

It means the same facts and the same rules lead to the same governed decision every time.

In practice the system works through five stages:

1. Ask for anything that is missing.
2. Decide against a threshold the institution has set.
3. Guide the client through the options, for example using less cash, borrowing more or selling some investments.
4. Escalate to a specialist when the institution requires it.
5. Route the client to the right place to act.

The threshold at the decision stage always comes from the institution, and the model has no say in it.

Deterministic execution doesn't mean every client reads the same words. An experienced investor and a first-time buyer should each get an explanation written for them. The institutional logic behind the decision is the same for both, and the model's job is to explain that logic clearly without changing it.

How do you prove any of this to a regulator?

You reconstruct a single recommendation from start to finish.

The question a regulator is likely to ask is a simple one: why did you tell her that? A governed system answers with a trace covering the facts it used, the rule it applied, the calculation, the path it followed, what the model contributed, who approved it and what the client saw. Provenance, approval, audit and human oversight cover the whole process, including everything that happens before a client sees anything.

If all a system can show is a log of what it said, you can see the output but not how the decision was reached, and governance can only look backwards.

Why is this hard to retrofit?

The four requirements are part of the architecture, so a review step added at the end can't supply them. Provenance has to be recorded from the moment a fact enters the system. Rules only become executable once someone has written them down in that form, and a decision can only be reproduced if its path is fixed in advance.

Putting an LLM wrapper in front of existing systems will get you a working demo. Demos are worth building, as long as nobody mistakes one for the architecture a regulated bank needs.

None of this asks a bank to invent a new control framework. The expertise already sits inside the institution, and the architecture makes it executable within the controls the bank already runs. There is more detail on our governance page, and on how this connects to Financial Guidance.