The most common question about artificial intelligence in banking is still a capability question: how advanced is the system?
That matters. But once AI moves beyond information retrieval and starts participating in consequential financial workflows, it is no longer the most important question.
A model can be technically capable of doing something that the institution does not permit it to do. It can recommend an action without being allowed to execute it. It can prepare an instruction that still requires explicit approval. And it can execute one customer-approved action without possessing any continuing mandate.
For boards, regulators and executives, that means AI maturity and AI authority need to be treated as separate dimensions.
The distinction is easy to miss because most technology programmes are organised around capability: can the model retrieve the right information, reason across context, use tools reliably and reduce cost? Those are natural engineering and investment questions. Authority usually appears later, when the system is connected to a workflow that can change a customer's financial position or an institution's operational state.
At that point, a model evaluation is no longer enough. The institution is designing a permission system.
Two different questions
Conventional AI maturity frameworks naturally ask about models, data, infrastructure, talent, use cases, deployment and scale. These tell us whether an institution can build and operate sophisticated systems.
Authority asks something else: what can the system actually cause to happen?
That distinction becomes especially important in finance because an apparently small shift in the workflow can move responsibility. There is a material difference between showing a customer how to change a card limit, preparing the request, submitting it for approval, and being authorised to change it within a standing mandate.
Capability describes the system. Authority describes the relationship between the system, the institution and the customer.KEVIN MOSERI
High capability does not imply high authority.
CAPABILITYLOW
CAPABILITY
Technically capable, but consequential action remains behind explicit controls.
Capability and permission converge; governance becomes a first-order design question.
Low consequence and low authority.
Simple system, but genuine authority inside a bounded workflow.
Authority is a governance architecture
If an institution decides to move an AI system closer to execution, the relevant questions quickly stop being about the model alone.
Who granted permission? What data can the system see? Which tools can it call? Which actions are prohibited? What monetary or product limits apply? What requires fresh approval? How is authority revoked? Can the institution reconstruct why an action happened?
This is why I think the language of “human in the loop” is often too coarse. A human can appear somewhere in a process without necessarily controlling the decisive moment. The useful question is where the approval boundary sits and whether the system can continue acting after that approval.
Do not collapse different forms of permission.
Why this matters strategically
For a bank CEO, authority determines how far AI can change the operating model rather than simply improve the interface. For a chief AI officer, it determines which controls must surround tool use and workflow orchestration. For a regulator, it helps separate technical sophistication from the transfer of consequential decision power.
It also creates a more disciplined way to compare institutions. A bank that deploys a highly capable conversational model but keeps every consequential action behind deterministic approval may be technologically advanced while remaining conservative on authority. Another bank may automate a narrow action with much less sophisticated AI but grant genuine execution rights within a tightly bounded process.
Those are not better or worse by definition. They are different institutional choices.
The distinction also changes how risk should be discussed. Model risk asks whether the system can produce an incorrect or unreliable output. Authority risk asks what can happen if that output is connected to action. The same model error has very different consequences when it produces an explanation, a recommendation, a prepared order or an executable instruction.
This is one reason I would expect the most durable banking AI architectures to separate reasoning from permission. The model can interpret context and propose a next step; deterministic policy layers can decide which tools are available, which limits apply, what needs fresh authentication and what cannot be delegated at all.
The conceptual distinction becomes useful when it is tested against evidence.
This essay separates capability from authority. Torinel® asks what observable banking systems are actually permitted to decide and execute.
German banking research, methodology and institutional evidence.
The question boards should add
The next phase of banking AI will still require the familiar questions about model quality, cost, risk, data and deployment.
But one additional question belongs beside them:
What authority has moved to the system—and under whose control?KEVIN MOSERI
That question is harder than asking whether the AI works. It is also much closer to the institutional consequences.
It forces management to specify the boundary rather than rely on labels such as assistant, copilot or agent. It gives regulators something more concrete to examine than model branding. And it gives customers a clearer way to understand whether they are receiving information, approving an action or handing part of a financial decision to a system.
As banking AI becomes more capable, the quality of that boundary may matter as much as the quality of the model behind it.