AI for Banks: Use Cases for Community and Regional Banks, the 2026 Supervisory Picture, and Where the Models Should Run

What AI in banking looks like in 2026

Banks are not new to AI. Fraud scoring, transaction monitoring, credit scorecards and interest rate models have used statistical learning for decades, and they sit inside model risk programmes that examiners know well. What changed is the arrival of models that read and write: they can summarise a 40-page commercial loan package, draft a complaint response or answer a teller’s question about wire cut-off times from the procedures manual.

The OCC’s Spring 2026 Semiannual Risk Perspective describes where most banks are. It says banks are taking a measured approach to generative and agentic AI, with use limited to specific cases, guardrails and human-in-the-loop accountability, and that the use cases the OCC has seen are mainly productivity and customer experience tools. That matches what we see in practice: the first wave is internal, reviewable and close to existing documents.

This guide covers the use cases that hold up, the US and EU rules that shape them, and the deployment decision. It is written for community and regional banks in particular, where a small team has to pick projects carefully. Regulatory texts were read on the agencies’ own sites on 25 October 2026.

AI for banks: the use cases that hold up

The common thread is that each task produces a draft, a classification or a cited answer, and a qualified person decides what happens next.

KYC and AML alert review

Transaction monitoring systems generate far more alerts than investigators can clear quickly, and most close as false positives. Language models help with the reading and writing around each alert:

• gathering the customer profile, prior alerts, account activity and adverse media into one case summary;
• comparing the activity with the customer’s expected behaviour from onboarding;
• drafting a disposition rationale for alerts the investigator closes;
• drafting the narrative section of a suspicious activity report for the investigator to rewrite and approve.

The decision to file stays with the BSA team. The AML and sanctions triage agent and the on-premises KYC and AML triage playbook show how such a workflow is split into steps with a reviewer at the end, and our longer piece on agents for KYC and AML investigations goes into case design.

One rule shapes where this work runs. Under 31 CFR 1020.320(e), a bank and its directors, officers, employees and agents may not disclose a SAR or any information that would reveal one exists. A tool that stores SAR drafts, prompts and outputs becomes part of that confidentiality boundary.

Credit memos and loan review

Commercial lenders spend hours turning tax returns, financial statements, rent rolls and appraisals into a credit memo. A model can spread the statements into the bank’s template, calculate ratios through a spreadsheet tool rather than in its head, summarise collateral and guarantor support, and list covenant terms. Loan review teams use the same approach in reverse, checking a sample or the full portfolio for missing documents and stale financials. The credit memo preparation guide walks through the controls.

Complaints

Complaints arrive by letter, email, phone and branch notes. Models can classify each one by product and issue, flag those that mention discrimination, elder abuse or a possible UDAAP problem for priority handling, and draft a response from the account history for a complaints officer to approve. Classification across the full complaint log also gives compliance a trend view that manual sampling misses.

Policy and procedure questions

Every bank has hundreds of procedures that staff rarely read end to end. A retrieval assistant that answers only from the current approved versions, quotes the paragraph and names the document gives frontline and operations staff faster answers and cuts calls to compliance. It is also one of the lowest-risk starting points, because the source material is internal and the user is an employee.

Regulatory reporting and exam preparation

Call report preparation, reconciliation of reporting schedules to the general ledger and responses to examiner requests involve repetitive gathering and checking. Agents can assemble supporting data, compare it with the prior quarter and draft variance explanations for the finance team. For AI for bank reconciliation more broadly, the payment reconciliation use case shows how break investigation can be prepared for an operations analyst to clear.

Contact-centre support

Call summaries, suggested next steps for the agent on the line and draft follow-up letters are common first projects. Fully automated customer chat carries more risk: it must not give wrong answers about fees or disputes, and it must hand over to a person when the customer asks. In the EU, the AI Act’s transparency rules, applying from August 2026, require people to be told when they are talking to an AI system.

How community banks can leverage AI

Community and small banks rarely build models of their own. Their AI arrives through the core processor, the digital banking platform, the fraud vendor, the loan origination system and office software. That makes vendor management the first AI control, not an afterthought.

Practical steps for a small institution:

1. Build a short inventory. List every tool that uses AI, who owns it, what data it receives and what decisions it informs. Include features switched on by vendors.
2. Start with internal work. Policy Q&A, call summaries, complaint triage and first-draft credit memos deliver value without putting a model in front of a customer.
3. Write the review rule down. For each use, state who checks the output and what they check before it leaves the bank.
4. Ask vendors the same questions every time. Which model provider processes our data, in which location, under which retention terms, and can we export prompts, outputs and logs?
5. Size governance to the risk. OCC Bulletin 2025-26 told community banks, defined as those with up to $30 billion in assets, that model risk guidance does not require annual model validation and that validation frequency and scope can follow the bank’s risk exposure.

The OCC has also said it wants AI opportunities to be available to all the banks it supervises, not only the largest, and that it is reviewing supervisory expectations with community banks that rely on third-party technology in mind. The finance executive brief summarises the governance questions a board will ask.

The US supervisory frame in 2026

There is no AI-specific banking rule in the United States. Existing guidance and regulations apply, and 2026 changed the most important piece.

SR 26-2 replaced SR 11-7

On 17 April 2026 the Federal Reserve, OCC and FDIC issued revised model risk management guidance: SR 26-2 at the Fed and OCC Bulletin 2026-13 at the OCC. It supersedes SR 11-7 from 2011 and the 2021 interagency statement on model risk for BSA/AML systems. The Fed says it is expected to be most relevant to organisations with more than $30 billion in assets, while the OCC says it applies to community banks subject to the limits the guidance describes.

The scope note matters most for this topic. The guidance states that generative and agentic AI models are novel and rapidly evolving and are not within its scope, while its principles still apply to traditional statistical models and to non-generative, non-agentic AI. It adds that a bank’s broader risk management and governance practices should determine the controls for tools it does not cover. The agencies also said they plan to issue a request for information on model risk management with particular attention to AI, including generative and agentic AI. So a fraud model sits under SR 26-2, while a language model drafting SAR narratives is governed by the bank’s own framework, its third-party programme and the rules below.

Third-party risk management

The interagency guidance on third-party relationships, issued in June 2023 by the Fed, FDIC and OCC, is the framework for AI vendors. It covers the whole relationship from planning and due diligence through contract negotiation, ongoing monitoring and termination. For an AI provider, due diligence should cover where data is processed, whether it is used for training, how long prompts and outputs are retained, which subcontractors are involved and how the bank exits.

Information security and incident notification

The Interagency Guidelines Establishing Information Security Standards, which implement the Gramm-Leach-Bliley Act for banks, require due diligence in selecting service providers and contracts that oblige them to protect customer information. The computer-security incident notification rule requires a bank to notify its primary federal regulator within 36 hours of determining that a notification incident has occurred, and requires bank service providers to notify affected bank customers of significant disruptions. Both reach an AI vendor that handles customer data.

Credit decisions and the CFPB

Under Regulation B, an applicant denied credit must receive specific principal reasons for the adverse action. The CFPB withdrew its 2022 and 2023 circulars on adverse action and complex algorithms on 12 May 2025, saying the withdrawal was not necessarily final, but the regulation they interpreted still requires specific reasons. On 22 April 2026 the CFPB issued a final rule, effective 21 July 2026, amending Regulation B on disparate impact, discouragement and special purpose credit programmes. Any model that informs a credit decision still has to support accurate reasons, and other fair lending laws were not changed by that rule.

EU banks: DORA and the AI Act

European banks work under two layers that interact with AI deployment.

DORA. The Digital Operational Resilience Act has applied since 17 January 2025. It sets requirements for ICT risk management, incident reporting, resilience testing and ICT third-party risk, including a register of information on ICT contracts and specific contractual terms. An external AI service that supports a critical or important function falls inside that framework.

The AI Act. Annex III point 5(b) makes AI used to evaluate the creditworthiness of natural persons or to establish their credit score high-risk, with an exception for fraud detection. Following the AI Omnibus, which entered into force on 27 July 2026, the European Commission says the Annex III high-risk obligations apply from 2 December 2027. Transparency obligations for systems that interact with people apply from August 2026. Our guide to the AI Act for banks and insurers covers deployer duties and the fundamental rights impact assessment in detail.

AI in banking challenges that stall projects

Most bank AI projects that stall do so for one of a handful of reasons:

• No citation, no trust. Investigators and credit officers will not rely on a summary they cannot trace to a document. Answers need sources.
• Data that cannot leave. SAR material, examination findings and customer files often cannot go to a third party under the bank’s own policies, even when the law might allow it with the right contract.
• Unclear ownership. With generative AI outside SR 26-2, someone has to own the governance standard for it. Banks that do not decide who that is find that every project waits for an answer.
• Vendor concentration. When the same few model providers sit behind many vendors, an outage or policy change affects several tools at once.
• Skills. Smaller banks rarely have staff who can evaluate a model. Narrow, well-defined use cases with clear review rules reduce how much expertise is needed.

Cloud assistant or the bank’s own infrastructure

The table is a starting point for a bank’s data policy. It assumes an enterprise cloud plan under terms that exclude training on customer data.

Confidential supervisory information and SAR material are the two categories that most often push a bank towards running models on its own servers or in a private cloud it controls. The overview of on-premises AI for financial services compares the deployment patterns.

Choosing AI tools for banking

Four kinds of product compete for the same budget:

Core and banking software add-ons. Core processors, digital banking platforms and loan origination systems increasingly include AI features. They are easy to switch on, but the processing happens in the vendor’s environment under its contract, so the third-party questions above apply to each feature.

Specialist vendors. Fraud, AML monitoring and credit decisioning vendors bring models trained for one job. They usually fall under SR 26-2 if they are non-generative models, and validation of vendor models is expected even when the code is proprietary.

General enterprise assistants. Good for drafting and summarising non-sensitive material. Check the data processing location, retention and training terms, and whether the bank can export logs for its own records.

A platform on the bank’s own infrastructure. For work on SAR material, credit files and supervisory information, a self-hosted platform keeps documents, indexes and logs inside the bank. It also lets the bank build its own agents for the use cases above. Whichever route a bank takes, the same due diligence questions on data location, retention, training use, logging and exit apply.

How VDF AI fits a bank

VDF AI is installed in the bank’s own data centre, a private cloud it controls or an air-gapped network. When it is configured to use local models only, prompts, documents, retrieval indexes, conversation history and audit logs never leave that environment, which keeps SAR drafts and examination material inside the bank’s confidentiality boundary. VDF AI has no banking regulator approval or certification of its own; the deployment is governed by the bank’s information security programme, third-party oversight and model governance like any other system.

Each use case becomes a knowledge collection with its own access rules. Retrieval respects those permissions, so a BSA investigator, a credit analyst and a branch employee each see only the documents their role allows. Governed agents carry out the multi-step work described above, such as alert case assembly, credit memo drafting or complaint classification, with tool access granted per role and a human approval step before anything is filed, sent or posted. Every interaction is logged with the user, the model, the source passages and any tool calls, which gives model governance and internal audit a record to test.

The VDF AI Router registers open-weight models served by Ollama, vLLM or other OpenAI-compatible endpoints, and can add a cloud model only where the bank’s policy permits it, with budgets and per-call audit. Staff sign in through Microsoft Entra ID, which is supported natively on-premises; banks using Okta, Keycloak or another SAML or OIDC provider connect it through an SSO-aware reverse proxy. Role-based access control is included on every plan, and a bank can begin with a three-month platform trial on its own hardware before committing to a seat bundle.

The finance and banking solution describes the on-premises setup for banks in more depth, the banking AI use case hub lists further workflows, and the banking agents catalogue covers onboarding, servicing, reporting and treasury agents. To find out which of these a bank is ready for, start with the free AI readiness assessment.

Nothing here is legal or supervisory advice for a specific institution; read the cited texts and consult counsel before relying on them.