AI in Banking: What Ships, What Stalls, and What the New Model Risk Guidance Left Out

For fifteen years, SR 11-7 was how US banks governed every model they ran. It was replaced in April 2026 — and both the OCC and the Fed’s Vice Chair for Supervision have since confirmed the replacement does not cover generative or agentic AI. Meanwhile 52% of financial firms are adopting agentic AI. Where that leaves AI in banking, function by function.

Andrew Tyutyunnyk

Chief Business Development Officer

Link copied

Last update: Nov 02, 2026

19 min read

For fifteen years, one framework governed how American banks built, validated, and signed off on models: the 2011 interagency guidance, issued by the Federal Reserve as SR 11-7 and by the OCC as Bulletin 2011-12. Every model risk team worked from it, and as AI in banking spread, it was the document people reached for to govern that too.

On 17 April 2026 it was superseded. The Federal Reserve, the OCC, and the FDIC jointly issued revised guidance on model risk management — SR 26-2 at the Fed, Bulletin 2026-13 at the OCC. It also absorbed the separate 2021 statement covering models behind anti-money-laundering systems, and rescinded the OCC’s dedicated examination guidance on credit scoring models, which had stood since 1997.

Then came the part that matters for anyone planning AI work. The OCC’s Spring 2026 Semiannual Risk Perspective states that generative and agentic AI models “are novel and rapidly evolving and are not within the scope of the revised model risk management guidance” (p. 7). Two weeks after the guidance landed, the Fed’s Vice Chair for Supervision said the same thing in a speech on 1 May 2026: the revised guidance “does not apply to generative or agentic AI.”

So the framework that tells a bank how to govern a model was rewritten, and the kind of AI most banks are currently buying sits outside it. In the Cambridge Centre for Alternative Finance’s 2026 Global AI in Financial Services Report, 52% of surveyed financial services firms said they were actively adopting agentic AI.

That is not a prohibition. Nor is the guidance itself a rulebook — the OCC’s bulletin says plainly that it “does not set forth enforceable standards or prescriptive requirements.” What changed is narrower and more awkward than a ban: the one framework examiners and model risk teams had been reading AI into no longer reaches the fastest-growing part of it, and nothing has replaced it yet.

That changes which AI in banking projects are straightforward and which ones carry a risk that has nothing to do with whether the model works.

The functions below sit on a spectrum from lowest to highest governance burden. The sections that follow explain each row.

Why banking is not like the other AI sectors

In manufacturing and supply chain, the thing that decides whether an AI initiative succeeds is data: whether the history exists, whether it is clean, whether you can test a model before you build it. We have written about that asymmetry in general enterprise terms.

Banking has that problem too. Cambridge found data availability and quality to be the leading barrier for 40% of industry respondents. But in banking it is not the binding constraint, because a second constraint sits above it: whether you can explain the output.

The gap there is measurable. In the same Cambridge research, 78% of regulators rated explainability as critical or important, while 50% of industry respondents had adopted explainable AI methods. Roughly two-thirds of industry respondents were not monitoring for bias at all.

In one function that gap is not a governance preference. It is statute. Under the Equal Credit Opportunity Act, a declined applicant is entitled to a statement of specific reasons, and the CFPB addressed the model-complexity question directly in Circular 2022-03: creditors must still provide accurate specific reasons, and a creditor’s lack of understanding of its own methods is not a defence.

Read those two findings together and the shape of the sector becomes clear. A bank can run an AI system it cannot fully explain in plenty of places. It cannot do so in the place where the money is lent.

AI use cases in banking: where it actually ships 

The AI applications in banking that reach production cluster in one place, and it is not where vendor material points.

Internal operations and the back office

Governance burden: lowest. This is where the volume is. Cambridge found process automation at 79% and software engineering at 75% — and noted that four of the top five use cases overall were back-office functions.

Nothing here touches a credit decision or a customer disclosure. The outputs are reviewed by employees who can be trained to check them, the failure mode is a wasted hour rather than a regulatory finding, and the benefit lands in operating cost, which finance already reports. The OCC’s own characterisation of current generative AI use in banks is that it is “primarily productivity and customer experience enhancement tools” (p. 6).

It is also the least interesting part of any vendor deck, which is roughly why it works.

Fraud detection and transaction monitoring

Governance burden: known. Fraud detection sits at 58% of industry respondents in the Cambridge data, among the leading risk and compliance applications.

The reason this one is comfortable is that it has a supervisory path. Models behind anti-money-laundering systems were covered by their own interagency statement from 2021, and SR 26-2 has now folded that into the single revised framework. These are predictive models of exactly the type the guidance still covers. A bank doing this work is not in novel territory.

One caution on the numbers. Search for transaction-monitoring statistics and you will find false-positive rates quoted with great confidence — frequently above 90%. Tracing any specific figure to a primary study is difficult; the sources are overwhelmingly vendor blogs citing other vendor blogs. The operational problem is real and well known to anyone who has staffed an alert queue. The percentage should not go into a business case.

Customer service and document work

Governance burden: moderate, and depends on the design. Customer support was the leading front-office use case in the Cambridge data, with 74% of industry respondents at pilot stage or beyond.

The design question that decides the governance burden is whether the system answers the customer or drafts an answer for a person to send. The second is substantially easier to defend, and it captures most of the handling-time benefit.

Document-heavy work inside the bank — policy lookup, procedure retrieval, servicing files, onboarding packs — is the quietest win in the category, because the output is a pointer to a source a human then reads. That is the shape of an AI knowledge assistant for regulated and document-heavy environments rather than a general-purpose assistant.

Data residency usually decides the architecture here before anything else does. Cambridge found data privacy ranked as the top risk for both groups it surveyed — 80% among regulators and 74% among industry. Where customer data cannot leave the bank’s own environment, a hosted API is off the table and the build becomes a self-hosted one. CodeIT’s self-hosted AI support layer case study is that exact pattern: the deployment constraint drove the architecture rather than the other way round.

Where AI in banking stalls

Credit decisioning

The constraint is legal, not technical. Cambridge put credit risk modelling at 54% of industry respondents, which sounds like broad success until you separate modelling from deciding.

Using a model to rank, segment, or flag applications for review is well-trodden. Using one to decline an application creates an obligation to say why, in specific and accurate terms, to the applicant. CFPB Circular 2022-03 closed the obvious escape route: model complexity does not reduce the obligation, and not understanding your own method is not a defence.

It is worth being precise about what moved in April 2026 and what did not. The 1997 examination guidance on credit scoring models was rescinded, folded into the general risk-based framework. The ECOA obligation was untouched. Supervisory expectations for credit models became more flexible; the duty owed to the applicant who was declined did not move at all.

This is why credit is the function where banks that move fast get into trouble and banks that move carefully look slow for reasons that are not technical. The workable version keeps the model on the ranking side of the line, or uses a method whose reasons survive being written on a notice. The unworkable version is a high-performing model nobody can turn into an adverse action reason.

Two-thirds of industry respondents not monitoring for bias is the same finding viewed from the other side. Fair lending exposure does not require anyone to have intended it.

Agentic AI and autonomous action

The constraint is that the framework is absent, which is not the same as permissive. This is the live tension in the sector right now. Cambridge found 52% of firms actively adopting agentic AI, and 81% expecting meaningful achievement by 2030. The OCC and the Fed have both said the revised model risk guidance does not reach it.

The OCC names what is missing rather than waving it through: “lack of explainability, data privacy and data poisoning issues,” and “validation challenges where industry approaches are evolving” (p. 6). It also notes that the agencies plan to issue a request for information on model risk management, including banks’ use of AI (p. 7) — which is a fairly direct signal that the current position is temporary.

A bank scoping agentic AI for anything that moves money or commits the institution is building something it will later have to retrofit to a framework that does not exist yet. Scoping it where a person approves each action keeps the option open at a fraction of the rework.

What this is not

Two topics get folded into “AI in banking” discussions and are genuinely separate questions. Generative AI in banking has its own set of applications and constraints, covered in our article on generative AI in banking. The traditional modelling side — propensity, churn, risk scoring, collections — is treated in predictive analytics in banking. This article is about which of them clears the governance bar in which function, not how either works.

The $30 billion line

One detail is worth reading carefully if you are not a large institution. SR 26-2 says the guidance “is expected to be most relevant to banking organizations with over $30 billion in total assets” regulated by the Federal Reserve, and that practices appropriately vary across organisations. The framing throughout is risk-based and tailored to the institution’s model risk profile.

That threshold is easy to misread as an exemption, and the OCC’s version of the same guidance closes that reading off. Bulletin 2026-13 states that the guidance “is applicable to all community banks, subject to the limitations discussed in the guidance,” and that it may also apply to smaller institutions with significant model risk exposure. The $30 billion figure describes where the guidance is most relevant, not where it stops.

The OCC is otherwise sympathetic on this point, saying it is reviewing supervisory expectations so that AI opportunities are available to all supervised banks rather than only a few, and that it is “seeking to support community banks that leverage third-party technology” (p. 7).

So for a community bank or a mid-size institution the practical reading is that proportionality is explicit rather than implied — but the perimeter still includes you, and the obligations which bite hardest on AI are not in the model risk guidance at all. ECOA applies regardless of balance sheet size. So does the third-party risk question, which is where a smaller bank’s AI usually arrives: embedded in a vendor product, governed by a contract nobody read with model risk in mind.

The UK made the opposite choice, six days later

Worth knowing if you operate on both sides of the Atlantic, because the two regimes diverged within a week of each other.

The two regimes diverged within a week of each other.

The PRA’s SS1/23, Model risk management principles for banks, has been in effect since May 2024, and its current version was published on 23 April 2026 — six days after the US agencies issued theirs. Its principles apply to “all types of models that are used to inform business decisions”, developed in-house or bought from a vendor, “regardless of technology”. One sub-principle deals specifically with “identifying and managing the risks associated with the use of artificial intelligence in modelling techniques”.

Nothing is carved out. AI and machine learning models are treated as models, under the same principles as everything else. The PRA has also been working through what that means with firms directly, holding roundtables with 21 regulated firms in October 2025 on AI and machine learning adoption in the context of implementing SS1/23.

Two caveats before anyone reads this as straightforwardly the stricter regime. SS1/23’s applicability is narrower than it first appears: it reaches UK-incorporated banks, building societies, and PRA-designated investment firms holding internal model approval for credit risk, market risk, or counterparty credit risk — not every UK bank. And principles-based coverage is not the same as detailed expectations. The PRA has extended the perimeter rather than filled it in.

The consequence for a group operating in both markets is concrete: the same generative AI deployment can sit outside the US model risk framework and inside the UK one. That is a design question to answer before the build, not a compliance footnote to discover after it.

Why the published AI in banking figures should be treated carefully

Published statistics on AI in banking and finance have a sourcing problem worth naming, because it affects anyone building a business case from a quick search.

The most-circulated figures — a 90%-plus share of banks “now using AI”, large dollar market sizes, specific ROI multiples — appear overwhelmingly on aggregator pages citing one another. Several trace back to nothing identifiable. That does not make them false; it makes them unusable in a document someone will be asked to approve.

The figures that do trace are less dramatic and considerably more useful:

The last row is the one most worth sitting with. Broad adoption, narrow transformation, and a measurement problem — which is the same pattern that shows up in enterprise AI failure rates across every sector, not just this one.

What to settle before scoping a banking AI initiative

Five questions, in this order. The first one you cannot answer cleanly is where the project will stall.

1. Does this function produce a decision a customer can be adversely affected by? If yes, explainability is a legal requirement and the model choice narrows immediately. If no, you have far more latitude than the compliance conversation usually assumes.
2. Is the model type in scope of SR 26-2 or outside it? Traditional and basic AI applications have a defined supervisory path. Generative and agentic do not, and that gap is yours to manage, not to inherit.
3. Can customer data leave your environment? This decides the architecture before any model comparison is worth running, and it is the question most often answered too late.
4. Is the AI yours or your vendor’s? Embedded AI inside a third-party product is still your risk, and the contract was probably not written with that in mind.
5. Who signs the validation? Not a committee — a named person with the standing to refuse. If nobody will sign, the project is not funded, whatever the budget line says.

Questions 1 and 2 sort the functions in the first half of this article from those in the second. Both are answerable in days, which is the point of running an AI readiness assessment before the build rather than discovering the answers alongside it.

Find out which banking functions your governance can actually support

Start an AI readiness assessment

Starting narrow in a regulated environment

The sequence that works for a banking AI programme is the same one that works elsewhere, with one change: the first project is chosen for how defensible it is, not for how much it is worth.

Internal operations first, because the governance burden is lowest and the data work is reusable. Fraud and monitoring second, because the supervisory path is established. Customer-facing and document work third, designed so a person stays in the loop. Credit decisioning and agentic workflows last, after the validation practice exists and has been exercised on something that does not matter as much.

The delivery side splits along the same line. Monitoring, scoring and forecasting are predictive analytics and machine learning problems with established validation methods. Document and drafting work is generative AI development, where model choice and hosting are governance decisions as much as technical ones. Where the workflow is specific enough that no product will fit it, that is custom AI development.

Because the governance questions in this sector arrive before the technical ones, the ordering is usually what needs an outside view — which is what AI governance consulting addresses, and where the uncertainty is narrow and specific, a proof of concept settles it for a fraction of a build.

CodeIT’s wider work in the sector sits under financial software development.

Turn a banking AI shortlist into a roadmap that will survive review

Explore AI strategy consulting

FAQ

About author

Andrew Tyutyunnyk

Chief Business Development Officer

Andrew, CodeIT’s CBDO, bridges the gap between client needs and innovative solutions. He brings a unique perspective with combined technical expertise and business development experience. Andrew prioritizes understanding business challenges and audiences before tapping into software development.