Why Governance, Not Capability, Will Decide Which Banks Actually Scale AI

Every bank I talk to today has an AI capability. Fewer than one in eight have the governance infrastructure to run it safely at scale, according to a 2024 Wolters Kluwer banking compliance survey. That gap, not the technology, is what will separate the banks that compound their AI investment from the ones that spend the next several years remediating it.  

I have spent thirty years across banking, financial services, and public-sector technology, and I have watched this pattern before. A genuinely powerful capability arrives faster than an organisation’s ability to govern it responsibly. It happened with core banking automation in the 1990s. It happened with algorithmic trading in the 2000s. AI is the same pattern again, except the pace this time has no real precedent, and the decisions it now touches, credit, fraud, customer servicing, compliance itself, sit closer to the centre of what a bank actually is than either of those two waves ever did. 

This is the present regulatory posture already, converging faster than most banks’ governance programmes are moving. 

The Convergence Is Already Here 

Look at four jurisdictions at once. The EU AI Act’s high-risk obligations under Annex III, covering credit scoring, AML monitoring, and insurance underwriting, were pushed back by the May 2026 Digital Omnibus agreement from August 2026 to December 2027. Read that as relief and you have misread it. The Act’s prohibited-practice rules have applied since February 2025, and the European AI Office gains direct enforcement power over general-purpose AI providers from August 2026 regardless of the extension. 

In the United States, the Federal Reserve’s SR 26-2, issued in April 2026, has replaced SR 11-7 as the model risk guidance banks are actually examined against. The CFPB’s Circular 2026-03 confirmed that lenders remain fully accountable under ECOA and Regulation B for explaining adverse decisions made by machine-learning models. A complex or proprietary model is not a legal defence. 

In the UK, the PRA has named AI a 2026 supervisory priority under SS1/23, and a House of Commons Treasury Committee report has pushed the FCA and PRA toward AI-specific accountability guidance by year end. The FCA has been clear it does not want a bespoke AI rulebook, preferring to supervise through existing conduct rules and senior-manager accountability instead. That is a different posture from Brussels or Washington today, but it is moving in the same direction, just starting from a different point. 

Singapore’s MAS FEAT Principles remain the reference standard across the wider Asia-Pacific region, and Hong Kong’s HKMA and India’s RBI have each issued their own AI risk expectations inside existing supervisory frameworks rather than standalone AI law. For a bank operating across all four regions at once, the practical result is convergence of substance without convergence of instrument. The same four capabilities, explainability, auditability, human accountability, and lifecycle monitoring, satisfy the letter of every regime, even though no single filing satisfies all of them simultaneously. 

The instruments differ by jurisdiction. The direction does not. Every regulator with real supervisory authority over banking AI is asking the same underlying question now. Not whether you use AI, but whether you can prove, on demand, that it is controlled. 

What Vendor Content Gets Wrong About This 

Most content on AI governance treats the obligation and the resource to meet it as the same problem. They are not. 

A global systemically important bank can staff a dedicated AI governance function, build proprietary monitoring tooling, and run parallel validation teams. SR 26-2, the EU AI Act, and the PRA’s posture apply the identical requirement to a $10 billion regional bank. What that regional bank does not have is the same balance sheet to absorb the fixed cost of building it. 

Three constraints hit the regional and upper-mid-market bank that a Tier 1 institution rarely faces. The specialist who can build a drift-monitoring pipeline and then explain it to an examiner is a role most regional banks compete for against employers three times their size, and usually lose. Legacy core banking platforms were often never built to expose the event-level telemetry continuous monitoring depends on, so the core has to modernise in parallel with the governance build, not after it. And governance budget has to compete, line by line, against revenue-generating technology spend, in a way a larger institution rarely has to justify with the same scrutiny. 

This is why I think build-versus-buy resolves differently for this part of the market. A regional bank is structurally more likely to need a governance platform it can configure than one it has to build from scratch. The scarcest resource in the whole architecture is the people, not the budget line. 

Four Trade-Offs With No Universal Right Answer 

Before any bank builds this architecture, four design choices have to be made deliberately. The mistake I see most often is a bank arriving at an answer by default, through inaction, rather than by decision. 

1. Centralised governance buys consistency across every business line, at the cost of slower innovation velocity in any one of them. Federated governance buys speed and business-line fit, at the cost of the fragmented-ownership problem I described above. Banks with concentrated risk in a single jurisdiction tend toward centralised. Banks with genuinely distinct business-line risk profiles across multiple jurisdictions tend toward a federated model sitting on a centralised policy layer. 
2. Then there is innovation against control. Over-control slows AI adoption to the point of real competitive disadvantage against digital-native challengers. Under-control creates exactly the regulatory exposure I described earlier. The answer is applying more control to higher-consequence decisions, credit, AML, adverse action, and less to lower-consequence ones like internal productivity tools, rather than settling on a single midpoint. That is precisely the risk-based classification every regulatory instrument already requires anyway.
3. Build versus buy is the third. Internal platforms preserve control and auditability at the cost of speed and the specialist talent a bank has to recruit and retain. External AI services buy speed at the cost of a third-party blind spot: regulatory accountability for the outcome sits with the institution regardless of who built the model. A vendor’s model card is not evidence a bank validated anything against its own risk appetite.
4. The fourth is explainability against performance. Simpler, interpretable models are easier to explain in an examination. Higher-performing black-box models can outperform them materially on accuracy, at the cost of exactly the opacity that creates regulatory friction. A well-built accountability architecture is designed so this trade-off does not have to be resolved by simplifying the model. Decision-level explainability sitting alongside a high-performing model can satisfy the regulatory requirement without giving up the performance. 

A Four-Layer Way to Think About This 

The framework I use has four layers, and each one only works if the layer beneath it is already in place.  

1. The first is the policy and risk layer. A shared AI risk taxonomy, owned by the CRO with CIO input, mapped to every regulatory regime the bank actually operates under.  
2. The second is lifecycle governance: development standards, validation workflow, and deployment control, owned jointly by the CIO and the engineering organisation.  
3. The third is continuous monitoring, real-time drift and bias tracking in production rather than a quarterly review, jointly owned by the CIO and CRO.  
4. The fourth is accountability and audit: clear ownership of every AI-driven outcome, a full audit trail, and reporting that is ready on demand instead of assembled under deadline. 

Skip a layer and the one above it stops meaning anything. A monitoring dashboard built without a risk taxonomy underneath it monitors the wrong things. An audit trail built without lifecycle governance has nothing traceable to actually audit. I have watched more than one bank buy the monitoring layer as a standalone purchase, and wonder six months later why the alerts it generates do not connect to anything the business can act on. 

Underneath all four layers sits a maturity question most banks have not asked themselves directly. Are you operating ad hoc, with isolated AI use and no shared risk taxonomy at all? Have you at least defined basic policies, even if controls stay manual and ownership stays fragmented? Is governance actually integrated into delivery, with engineering and compliance sharing one definition of production-ready? Have you industrialised it, so automated monitoring and audit-readiness are a permanent state rather than an event? Very few institutions I talk to can honestly place themselves past the second stage, and almost none of them realise it until they try to answer a regulator’s question and cannot. 

I go through this architecture in full, including the maturity model and a jurisdiction-by-jurisdiction implementation map, in Paper 5 of our CIO Mandate series. 

The Evidence Isn’t Theoretical 

Across our own research into AI-first banking transformation, the failure pattern keeps showing up at exactly the point where one of these four layers is missing. A personalisation programme that raised first-call resolution to 90 percent still needs a shared customer risk taxonomy underneath it, or it starts contradicting itself across channels. A core modernisation programme can ship faster on paper while building on data governance debt that was never resolved, which is a lifecycle-governance failure wearing a delivery-speed costume. A fraud programme that cut false positives sharply still needs continuous monitoring, or the model quietly drifts for months before anyone notices. 

Three or four apparently separate governance problems, spread across different parts of the bank, turn out to be one dependency structure showing up every time. 

Where to Actually Start 

None of this requires a multi-year programme before it produces value. 

In the first ninety days, a bank can define its AI risk taxonomy, inventory every model actually in production, including the shadow AI nobody formally approved, and assign a named executive owner to each one. That alone closes the single most common finding regulators cite: fragmented accountability. 

The following nine months is where lifecycle governance and production monitoring actually get built, not planned. The year after that is where it industrialises, so being audit-ready stops being a seasonal scramble before an examination and becomes a permanent operating state.  

Banks treating this as a compliance cost are solving the wrong problem. Governance built this way produces faster approvals for new AI use cases, because the evidence a regulator asks for already exists rather than needing to be assembled under deadline. It produces more board confidence in AI-driven decisions. And, somewhat counterintuitively, it produces faster deployment overall, because a properly governed pipeline removes the manual review cycles that slow down AI built without one. 

The Mandate 

The question in front of every CIO and CRO I speak with is no longer whether to govern AI. It is whether they can do it at the speed their business and their regulators are both now demanding, across every jurisdiction they operate in, at the same time.  

This is a joint mandate that belongs to the CIO and the CRO together, starting now, not a technology upgrade to hand off to one function alone. I have spent enough of my career watching organisations get the sequencing of a hard problem wrong to say this plainly: waiting for the regulatory instruments to fully settle before you start building is not caution, it is a decision to be examined against a standard someone else writes rather than one you helped define.