Where governance frameworks miss the point
Ask any Head of AI Governance what their framework covers, and the answer is usually consistent: model validation, data lineage, explainability, and bias monitoring against EU AI Act requirements. All legitimate, all necessary. But every one of them assumes the AI decision worth governing is the one a model makes inside a defined system.
That assumption is where standard frameworks go blind. According to the Banking OS architecture that Backbase has built across 120+ financial institutions, roughly 50% of frontline banking work lives in the whitespace between systems. These are the handoffs, manual exceptions, and policy checks that no single system owns. This is precisely where AI governance blind spots are most acute, and least visible to standard model risk frameworks.
When an AI agent in onboarding passes a case to a fraud review agent, which triggers a manual exception handled by a CSR, which then re-enters the underwriting workflow - whose governance framework owns that chain? In most banks today, the answer is: nobody's. Each system has its own oversight regime. The seams between them have none.
McKinsey's 2026 AI Trust Maturity Survey found that only about one-third of organizations report mature governance levels for agentic AI controls. Governance and agentic AI oversight consistently lag behind technical and data capabilities across every region surveyed. Banks have governance policy, but what they don't have is governance that runs at the same layer as the decisions it's supposed to cover. So by the time it engages, the risk has already materialized.
The fragmentation problem compounds every governance risk
Standard AI governance frameworks assume you have one coherent system to govern. Banking doesn't work that way. A bank deploying AI agents across fraud detection, customer onboarding, servicing, and underwriting is deploying those agents onto a fragmented infrastructure. Each agent sees a different slice of the customer, works from different data, and writes back to different systems.
On that foundation, governance authority becomes as fragmented as the operations it's meant to cover. An agent authorised in the fraud system has no visibility into what the onboarding agent already decided. A policy applied in the servicing workflow doesn't carry forward to the dispute resolution process. Consistency - the most basic requirement of any governance framework - is structurally impossible.
As Valbona Dhjaku, a technology and digitalisation leader with 20 years at Credins Bank, put it on the Banking Reinvented podcast: "You have to constantly do these things in parallel - you have to build core systems, you have to build data foundation, you have to take care about data governance, about security, but you have to adapt to global standards and modern technologies." That sequencing reality - building governance and AI deployment simultaneously, not one after the other - is something standard compliance frameworks almost never account for.
The result is what Backbase calls AI theater: agents deployed without a unified authority record, so the dashboards show activity, not accountability. The evidence exists in fragments. The regulator, understandably, wants a coherent picture.
Governance as an operating model property
The banks making real progress on a governance framework for AI in banking have stopped treating governance as a compliance overlay and started treating it as an operating model property. The distinction matters enormously.
A compliance review reconstructs a decision three weeks after a fraud agent and an onboarding agent disagreed on the same customer. By then the account is open, the position is taken, and the audit trail is in two separate systems. A governance layer embedded in the execution environment registers what is happening as it happens, and stops the problem before it compounds. Every agent action is authorised before it executes, and every decision leaves a verifiable trail, built in at the moment of execution, not reconstructed after the fact. This is the difference between auditing AI and governing it.
Backbase builds this into the Banking OS through Sentinel - the Authority Layer that runs alongside every layer of the Runtime. The core invariant is non-negotiable: no action executes, by any actor (customer, employee, or AI agent), without a Decision Token. A Decision Token records the policy applied, the actor identity, the model version, the decision outcome, and full context. Governance becomes a continuous, embedded operational property rather than a periodic audit exercise.
This architecture directly addresses what McKinsey identifies as a core governance requirement for financial institutions: the need to monitor how AI applications adapt over time and ensure they remain compliant as they process new inputs. Periodic validation cycles can't do this. Only a real-time authority layer embedded in the execution environment can.
What a robust governance framework requires in practice
Most governance frameworks address the right questions - they just answer them in the wrong place. Policy enforcement, model authorisation, explainability, data lineage, escalation paths - all of these are legitimate governance requirements. The problem is locating them in a separate oversight structure that sits apart from the operational layer where decisions happen.
A governance framework for AI in banking needs to work at the operational level, not just the compliance level. Across more than 120 bank implementations, five properties consistently separate frameworks that hold under regulatory scrutiny from those that don't.
A shared semantic foundation. Every agent, every workflow, and every employee workspace must operate from the same source of truth about the customer. Backbase calls this Nexus - the Semantic Layer that provides a Customer State Graph, replacing the fragmented, inconsistent data scattered across dozens of systems. Without it, agents make decisions on partial information, and governance has no coherent object to attach to.
Authorised decision boundaries for every agent. Banks must define what every AI agent is entitled to do, under what authority, and with what limits. Those definitions must be built into the execution environment itself. This is the architecture challenge that separates AI-native banks from banks that add AI onto existing infrastructure. Progressive autonomy - assistive, delegated, autonomous - gives compliance teams a graduated model where autonomy is earned, measured, and revocable at any level.
Deterministic orchestration for known processes. Not every banking workflow should be agentic. For high-risk, structured processes like credit underwriting or KYC remediation, deterministic workflows with hardcoded rules and mandatory approvals provide governance by design. The coordination overhead between fragmented systems is itself a governance risk, and deterministic orchestration eliminates the manual bridging where non-compliant workarounds proliferate.
Continuous auditability, not periodic reporting. Decision Tokens turn governance from a reporting exercise into a continuous operational record. Every agent action - every recommendation, every escalation, every approval - carries a traceable evidence bundle. When a regulator asks how a fraud decision was made, the answer isn't a report generated after the fact. It's a verifiable chain of operational authority that existed before the decision executed. PwC found continuous monitoring is where governance intent breaks down in practice, and Decision Tokens are the mechanism that closes that operational weakness.
Parallel build, not sequential. The biggest practical mistake banks make when building a governance framework is treating it as a precondition for AI deployment. You can't finish building governance before you start deploying AI - the two have to happen at the same time. Modernization and governance must progress in parallel, with each domain deployment adding to the cumulative governance architecture rather than waiting for a fully formed framework to exist first.
The whitespace is the frontier - and the risk
There's a reason Deloitte, McKinsey, and the BIS are all publishing extensively on governance frameworks for AI in banking right now. Banks are moving fast, agents are proliferating, and the governance architecture most institutions have in place was designed for a world of isolated models and static rules. It was not designed for autonomous agents operating across fragmented systems at scale.
The 50% of frontline work that lives in the whitespace between systems is where the largest AI opportunity exists, and also where the largest governance risk lives. An agent that coordinates a dispute resolution across the payments system, fraud engine, and customer record - with no shared context, no unified authority, and no Decision Token - isn't a governed AI deployment. It's an operational liability dressed up as automation.
Building an AI-native bank means building governance into the architectural blueprint, not onto it. The banks that get this right won't just satisfy regulators - they'll be able to scale AI deployment faster precisely because their governance infrastructure is already in place. Moving from digital channels to an integrated frontline is what makes that possible: one operating system, one authority layer, one verifiable record - a single architectural decision that covers every actor, rather than three separate things to coordinate after the fact.
Banks that make it early will deploy AI at scale with confidence. Banks that treat governance as a downstream task will find that every new agent they deploy adds to a governance debt that gets harder to repay the longer they wait.
Frequently asked questions
What is a governance framework for AI in banking?
A governance framework for AI in banking is the set of policies, controls, and operational structures a bank uses to deploy AI safely and accountably. It covers who authorises AI actions, how decisions are recorded, how models are monitored over time, and how the bank demonstrates compliance to regulators. Strong frameworks embed these controls into the execution environment rather than managing them as a separate compliance overlay.
Why do AI governance frameworks fail banks that are already deploying agents?
Most governance frameworks for AI in banking were designed around isolated models, not multi-agent operations. When AI agents coordinate across fraud, onboarding, servicing, and underwriting on fragmented infrastructure, each agent operates on partial data and follows inconsistent rules. Governance becomes structurally impossible because the authority and context needed to govern decisions are as fragmented as the systems themselves.
How does the Banking OS enforce AI governance across the frontline?
Backbase's Banking OS enforces governance through Sentinel, the Authority Layer that runs alongside every operational layer. Every action by any actor - customer, employee, or AI agent - requires a Decision Token before it executes. Each token records the policy applied, actor identity, model version, and decision outcome, turning governance from periodic audit into a continuous, embedded operational property across the entire frontline operation.
What do regulators expect from a bank's AI governance framework in 2026?
Regulators expect banks to demonstrate explainability, transparency, and accountability for every AI-influenced decision, particularly in credit, fraud, and customer-facing interactions. The EU AI Act classifies credit-scoring AI as high-risk, requiring additional safeguards. U.S. regulators have consistently emphasized that explainability is a compliance requirement, not a design preference. Banks must provide verifiable audit trails, not retrospective reports.
Can AI governance be built in parallel with AI deployment, or must it come first?
Governance and AI deployment must progress in parallel - sequential approaches don't work when agents are already live across banking operations. Banks need to build core systems, data foundations, data governance, and security simultaneously while adapting to evolving global standards. Starting with high-value domains and expanding coverage progressively, as described in Backbase's modernization guide, allows governance architecture to compound with each new deployment rather than trail behind it.
