AI in Banking: Which Use Cases Should Banks Fund First?

The Prioritization Framework for Banking Technology Leaders

Half the US banks in one 2026 survey have already deployed generative AI. The harder question for AI in banking now is which use case earns the next budget line, and which one will still be defensible when an examiner asks how it reached a decision.

The Defining Problem in AI in Banking

Adoption has moved faster than most governance programs. Cornerstone Advisors’ What’s Going On in Banking 2026, a survey of 416 executives at US banks and credit unions between $250 million and $50 billion in assets, found that 49% of banks and 59% of credit unions have already deployed generative AI, and that agentic AI is now discussed at the executive or board level at more than half of institutions.

Deployment is not the same as value. BCG’s 2024 research found that 74% of companies had yet to show tangible value from AI, and traced around 70% of the obstacles to people and process, with only about a tenth coming from the algorithms themselves. For most banks, what holds AI back sits around the model: the data it needs, the person who reviews its output, the controls risk will ask for and the baseline that would prove it worked.

For a regional bank, that turns AI strategy into a selection problem. Pilots are usually chosen one request at a time, led by whichever business line asks loudest or whichever demonstration impressed most. Each request looks reasonable on its own. Together they fill the portfolio with projects that share the same unresolved dependencies: a customer data store four pilots rely on, a model risk team with capacity for two validations a quarter, a compliance function that has not agreed how generative AI output will be reviewed. Every new pilot then competes with the ones already running for the same scarce people, and the program slows as it grows.

Regional banks feel this more sharply than the largest institutions. A bank with $40 billion in assets can face a list of AI candidates as long as a bank ten times its size, with a fraction of the data engineers, validators and compliance technologists. Much of its technology arrives through core and SaaS vendors on release cycles it does not set. The margin for a poorly chosen pilot is thinner, and the cost of one spreads across the whole portfolio.

The practical conclusion is that the unit of AI strategy at a regional bank is the portfolio. A bank that chooses well, in the right order, can move faster with fewer pilots than a bank that approves everything and waits for the winners to emerge.

This framework is written for CIOs, CTOs and their risk and compliance counterparts at US regional banks, super-regionals and large credit unions: institutions where AI budgets are real, teams are lean and every dollar still has to earn its place.

Read the full analysis: Banking Transformation Strategy: Why AI Use Case Selection Is Now the Strategy: why portfolios of disconnected pilots stall, and how to run selection as a quarterly portfolio decision.

The Five-Question Prioritization Framework

Every AI use case can be rated from 1 (weak) to 5 (strong) on five questions, for a total out of 25. Each question names a dependency that sits outside the model team and can stall a pilot long after the model itself works. The questions apply equally to a fraud model, a chatbot or a test generator, which is what makes them useful for comparing use cases across functions and business lines.

Question 1. Value: How Significant Is the Problem?

What it tests: whether a business owner can put a number on the cost, risk or revenue at stake, and is waiting for the result.

What a 1 looks like: the use case was proposed because the capability exists. Nobody has sized the problem, and no budget line would change if it succeeded.

What a 5 looks like: a named owner can state the baseline (fraud losses, hours of manual review, abandoned applications, days of commercial onboarding) and has agreed what improvement would justify scaling.

Failure mode: treating interest as demand. A use case that many people find exciting and nobody owns tends to survive the pilot and then lose its sponsor at the first budget review.

Question 2. Data: How Ready Is the Underlying Data?

What it tests: whether the data is accessible, joined across systems, monitored for quality, traceable through lineage and permitted for the intended use.

What a 1 looks like: the data exists somewhere in the bank, in several systems that disagree, with no agreed owner and no record of whether it may be used for this purpose.

What a 5 looks like: the sources are known, joined and monitored, quality issues are tracked to an owner, and the permitted use has been confirmed with privacy and legal.

Failure mode: assuming that data which exists is ready for a model. In American Banker’s 2025 Data-Driven Bank survey, 36% of regional bankers said their systems were not precise. Data is also the question where one weakness spreads furthest, because several use cases usually draw on the same customer, transaction or document sources.

Question 3. Judgment: How Clear Is the Human Review Point?

What it tests: whether AI supports a decision that a named person still makes, or replaces that person on a consequential call.

What a 1 looks like: the model acts directly on a customer outcome, such as declining credit or blocking a payment, and no one is assigned to review its decisions.

What a 5 looks like: a named role reviews each output, or a defined sample, with written authority to override, and the review fits within that person’s working day at production volume.

Failure mode: automating the decision before the bank can monitor and defend it. Use cases with a clear review point move faster through risk and compliance, because the control is easy to describe: who reviews which output, and when.

Question 4. Controls: How Ready Are the Controls Around It?

What it tests: whether model risk, explainability, privacy, fair lending and audit requirements are defined and owned before launch.

What a 1 looks like: the controls conversation has not started, and the team expects to address it once the pilot shows results.

What a 5 looks like: the validation scope, explainability standard, monitoring thresholds and evidence trail are agreed with risk and compliance, and someone owns each one.

Failure mode: governance added after deployment. The Architecture of Trust in AI-Driven Banking names governance that is audited after deployment, rather than engineered from the start, as one of the failure points that keeps AI at the edges of the bank.

Question 5. Measure: Can You Measure the Outcome?

What it tests: whether a baseline and an agreed metric exist before the pilot starts.

What a 1 looks like: success will be judged by user feedback or by the share of work automated, with no figure captured beforehand.

What a 5 looks like: the baseline was recorded before launch, the metric reflects the business outcome rather than activity, and the evidence that would justify scaling was agreed in advance.

Failure mode: a pilot that succeeds but cannot prove it. Engineering Trusted Automation in AI-First Banking Operations calls automation rate a vanity metric and warns that automation becomes accumulated risk when it scales past the validation that makes it defensible.

The five questions are cumulative. A use case with excellent value and weak data waits for the data, however strong its other scores look.

Reading the Scores: The Lowest Number Decides

A total out of 25 is useful for ranking, but it hides the most important information on the scorecard. Consider two use cases at the same hypothetical $40 billion bank. The scores below are illustrative.

On totals alone, the two are tied, and the first looks more attractive because its value is higher. In practice the second can start this quarter and the first cannot. Its data score of 2 means the offer engine would run on customer records that do not reconcile across channels, so every recommendation it makes would inherit that problem.

Two rules follow. First, a score of 1 or 2 on any question is a blocker, whatever the total. The total ranks use cases only among those with no blockers. Second, a blocker is worth tracing to its source. If the data score of 2 comes from the same customer data store that four other use cases depend on, fixing it is a portfolio investment that lifts all five at once, and it may be worth more than any single pilot on the list.

This is why the scorecard is most valuable when every candidate is scored at the same time. Scored one at a time, each use case looks like a separate decision. Scored together, the shared blockers become visible, and the bank can fund the fix that unlocks the most value instead of the pilot that argued best.

Read the full analysis: Data Quality in Banking: The Score That Decides Every Other AI Use Case: why the data question sets the ceiling for the whole portfolio, and which shared fixes lift several use cases at once.

Who Owns Which Decision

Most AI programs at regional banks stall at an organizational seam before they stall at a technical one. Each of the five questions has a natural owner, and a use case is only as ready as the least prepared owner.

Scoring a use case with all five owners in the same session is the single most effective change a regional bank can make. A practical format is a working session of about 90 minutes, with a one-page description of each candidate circulated beforehand and each owner scoring their own question first.

The disagreements are the useful output. When the business scores value at 5 and model risk scores controls at 2, the gap is the agenda: either the controls can be designed in the next quarter, or the use case waits. Gaps like these usually surface months later, one approval at a time, when they are far more expensive to resolve.

Where the AI Comes From: Build, Buy or Already Embedded

Much of the AI in a regional bank was never selected as an AI project. It arrives inside core platforms, CRM, fraud tools, document systems and productivity software, switched on with a release or bundled into a renewal. These embedded capabilities belong on the scorecard alongside the use cases the bank builds, because they carry the same risks and draw on the same data and reviewers.

The five questions apply to all three sources, but they shift emphasis:

Built in-house, the bank controls the data, the model and the evidence trail, and the data and controls questions are answered by its own teams. The constraint is capacity: every built use case needs engineers, validators and monitoring the bank has to staff.
Bought as a dedicated product, the data question becomes what the vendor model sees, and the controls question becomes what the vendor will disclose about training, testing, performance and changes. A product that cannot explain its own outputs to the bank cannot be explained by the bank to an examiner.
Embedded in an existing platform, the first challenge is knowing it is there. A vendor can add an AI feature to a system the bank already relies on, and the feature can touch customer outcomes before anyone has scored it.

For bought and embedded AI, the contract is part of the control. Terms that give the bank access to performance data, notice of material model changes and the information needed to explain individual decisions turn a low controls score into a workable one. Without them, the score stays low however good the product is.

The Regulatory Frame After SR 26-2

On April 17, 2026, the Federal Reserve, the FDIC and the OCC issued revised Supervisory Guidance on Model Risk Management, known at the Federal Reserve as SR 26-2, replacing the 2011 guidance (SR 11-7). Two points matter for an AI roadmap. The guidance “is expected to be most relevant to banking organizations with over $30 billion in total assets,” though it may also be relevant to smaller banks with significant model risk exposure. And “generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance.”

The agencies said they plan to issue a request for information on model risk management that considers banks’ use of AI, including generative and agentic AI. Six months later, it had still not appeared in the Federal Register, according to a late-October 2026 report, which leaves banks governing generative and agentic AI on their own for now.

Credit unions sit outside that interagency guidance altogether. In its May 2025 report, Artificial Intelligence: Use and Oversight in Financial Services, the US Government Accountability Office found that the NCUA’s model risk guidance is limited in scope and detail, and that the NCUA lacks authority to examine technology service providers. Because much credit union AI runs inside vendor platforms, that second finding places more of the governance burden on the credit union itself.Existing obligations still apply in every row. In July 2025, the Massachusetts Attorney General reached a $2.5 million settlement with student lender Earnest Operations over allegations that its algorithmic underwriting models were not tested for disparate impact and produced inaccurate adverse action notices. No AI-specific rule was needed to bring the case.

For scoring, the regulatory frame changes how much weight the controls question carries. A traditional model inside SR 26-2 has a known validation path, so its controls score depends mostly on capacity. A generative use case outside it has no external standard to meet, which sounds easier but is harder: the bank has to define the standard, apply it and be ready to defend it later. An AI acceptable use policy is a start. On its own, it does not show how an individual customer decision was made, monitored or reviewed. A CIO and CRO Mandate for Global Banks: AI Compliance and Regulatory Governance sets out the Enterprise AI Accountability Architecture, with four layers: policy and risk framework, lifecycle governance, continuous monitoring, and accountability and audit.

Read the full analysis: AI Risk in Banking After SR 26-2: What the New Guidance Leaves to You: what the revised guidance covers, what it leaves out, and six controls regional banks and credit unions can put in place now.

AI in Financial Services, Function by Function

The scorecard behind this framework covers 36 use cases across nine functions. The table below shows where use cases in each function usually meet friction. Your own scores will depend on your data, your controls and who owns the outcome.

The sections that follow look at what usually decides the scores in each function, and which use cases tend to earn an early place.

Fraud, KYC and AML: High Value, Hard Controls

Fraud use cases usually score well on value and measurability, because losses are counted and detection rates have baselines. The friction sits in judgment. Real-time scoring that blocks a payment is an autonomous decision with a customer on the other end, and its false positives land in the contact center, far from the team that tuned the model. A fraud model can improve its detection rate and still worsen the customer experience, and only a measure that counts both will show it.

KYC and AML show the gap between adoption and results more sharply than any other function. In Fenergo’s 2025 global survey, reported use of advanced AI tools in KYC and AML rose to 82%, yet 70% of firms lost clients in the past year to inefficient onboarding. The tools arrived, but the work around them did not change: alerts still landed in the same queues, and onboarding still waited on documents held in disconnected systems.

The use cases that tend to earn an early place here are the ones where an analyst still makes the call: sanctions and adverse media screening, and document verification. They cut the time an analyst spends on each case without changing who decides. Automated SAR drafting scores lower on controls, because the narrative supports a regulatory determination, and continuous risk scoring usually waits on entity resolution, the ability to recognize the same customer across systems.

Read the full analysis: AI for AML Compliance: Where Fraud and KYC Use Cases Earn Their Place: why adoption has outrun results in financial crime, and the order in which to fund the eight use cases.

Lending: Where Explainability Is Tested

Credit decisions carry adverse action and fair lending obligations, so explainability decides most lending scores. Engineering Trust in AI Compliance and Regulatory Governance calls this the adverse action trap, in which exposure comes from reasons that were never documented as much as from wrong decisions, and argues for determination-level explainability: the ability to explain each individual outcome as well as the model in general.

The distinction matters for scoring. A model can be well understood in aggregate, with validated features and stable performance, and still be unable to produce the specific reasons for a single applicant’s decline. Lending use cases score well on controls only when the explanation for each decision is captured at the moment it is made, in language the applicant and an examiner can both follow.

Commercial and consumer lending differ here. Consumer credit carries the heaviest adverse action burden and the most visible fair lending exposure. Commercial credit relies more on relationship managers, which makes early warning for credit risk and portfolio monitoring natural first use cases: they flag deterioration for a banker who already owns the relationship and the decision. Collections prioritization follows a similar pattern. Automated underwriting, where the model makes or shapes the credit decision itself, usually belongs in a later wave, once the bank has shown it can produce and evidence individual reasons.

Read the full analysis: Explainable AI in Banking: Why Lending Is Where It Gets Tested: what the Earnest settlement shows, and how to score lending use cases on explainability before they reach an examiner.

Operations and Customer Service: Measure Before You Automate

Document processing and exception handling score well on measurability, since volumes and handling times are already tracked. The risk in operations is quieter. Automation that handles the simple cases and hands back the rest can leave cost per item almost unchanged, because the people who remain spend longer on harder exceptions. And automation that accumulates team by team, as scripts, bots and model calls, can reach a point where nobody can say how many automated decisions the bank makes each day.

The measure question therefore carries extra weight in operations. A useful set goes beyond the share of work automated to cover end-to-end cycle time, exception rate, rework and reversals, the share of automated decisions that are validated, and cost per completed item, each captured before the pilot starts.

Customer service has the most visible AI use case in banking and often the weakest data. A chatbot can only resolve what it can see, and in many banks the context a customer gives the bot does not travel with them when they reach an agent. From Digital-First to AI-First names context loss in contact centers as one of the shortfalls of the digital-first model. Case routing and sentiment analysis support the agent directly and are easier to govern than a chatbot that answers on the bank’s behalf, which is why they often score higher despite drawing less attention.

Read the full analysis: Banking Operations Automation: Measuring What AI Actually Changes: the five measures that replace automation rate, and how to bring shadow automation under governance.

Compliance and Regulatory Reporting: Controls That Enable Scale

Regulatory change monitoring and automated compliance checks support people and are relatively easy to control. For a regional bank tracking federal and state changes with a small compliance team, regulatory change monitoring often lands in the first wave: the compliance officer still interprets the rule, and the measure (time from publication to impact assessment) is easy to agree.

Explainable AI for audit and regulatory reporting is different. It is a control in its own right, and it often has to be in place before the other use cases in the portfolio can scale. Banks that score it low tend to find that several other use cases are quietly waiting on it, from transaction monitoring to lending. Scoring it next to the use cases it supports makes that dependency visible. The CIO and CRO mandate whitepaper describes the wider shift as regulatory convergence, from periodic validation toward continuous assurance, with a phased 24-month roadmap.

Read the full analysis: Compliance Automation in Banking: From Faster Checks to Defensible Decisions: where compliance automation pays back, where it creates new exposure, and what to ask of any compliance technology solution.

Testing and Quality Engineering: The Fastest Measurable Return

Testing use cases carry the lowest customer and regulatory exposure of the nine functions and usually show measurable returns quickly, which makes them a good place to build the bank’s AI delivery habits. They also matter more as AI speeds up development. AI coding assistants increase the volume and pace of change, but they do not carry the business reasoning behind a change, so the risk moves into testing: code that looks correct and behaves wrongly in a payment flow, a disclosure or a vendor integration.

The use cases that tend to score highest generate test cases from requirements, create compliant test data, and predict where defects are most likely, each with a quality engineer reviewing the output. Three Maveric whitepapers cover this function: Your Developers Already Sped Up. Did QA?, Breaking the 33% Ceiling and The Context Continuum, which explains why AI agents in the delivery pipeline do not inherit the business reasoning behind their instructions.

Read the full analysis: Test Automation in Banking: Quality at the Speed of AI-Assisted Delivery: why AI-paced development needs a different quality model, and how to score testing use cases.

Data, Analytics and Cybersecurity: The Enablers

Customer 360, real-time data quality monitoring and natural language analytics are enablers more than end uses. They raise the data score of nearly every other use case, so they are best judged as infrastructure investments in data trust and scored by how many other use cases they unblock. The CIO’s Guide to AI-Enabled Core Banking Modernisation describes the architectural shift as a move from systems of record to systems of intelligence, with decision-specific context assembled on demand.

Cybersecurity use cases rarely face a value question, and much of the capability arrives inside vendor tools. The scoring question is control: whether the bank can explain, tune and evidence what a vendor model flags, and whether its analysts can act on the output without drowning in it.

From Pilot to Production: What Scaling Requires

A pilot that worked has answered one question: the model can do the task. Scaling raises five more, and they map onto the same framework.

Value at volume. The benefit measured on a few hundred cases has to hold across the full population, including the harder cases a pilot often excludes.
Data in production. Pilot data is often a cleaned extract. Production data arrives late, incomplete and from more sources, and the monitoring has to catch that.
Reviewer capacity. A reviewer who checked 50 outputs a day in the pilot may face thousands in production. Either the sample design changes or the review point quietly disappears.
Controls that run continuously. Validation at launch is not enough for a model whose data, prompts or vendor version can change. The bank needs defined triggers for re-validation.
Cost to run. Inference, monitoring, review and support costs belong in the business case alongside the build cost, and they grow with volume.

Re-scoring a use case at the scale gate, with the same owners in the room, turns these from surprises into agenda items. It also gives the board a consistent answer to the question it will ask: what evidence did this pilot produce, and was it the evidence we agreed before it started?

What Waiting Costs

The cost of a poor first choice goes beyond the pilot budget. A stalled flagship project draws down the board’s patience for the next request. It ties up the data and risk teams every other use case depends on, and it leaves the bank’s governance untested when examiners eventually ask about generative AI. Meanwhile, institutions with narrower, better-governed pilots are building the monitoring, review points and evidence trails that make each later wave faster to approve.

The cost of not choosing is also real. AI is arriving in regional banks whether or not the bank selects it, embedded in the platforms it already runs. A bank that does not score and inventory its use cases ends up governing the AI its vendors chose, which may not be the AI it would have chosen.

What Changes in the Next 24 Months

Three shifts are already visible. The banking agencies have said they plan a request for information on model risk management that considers banks’ use of generative and agentic AI; when it appears, it will be the first step toward bringing today’s self-governed generative AI into supervision. GAO’s recommendation leaves the NCUA under pressure to update its model risk guidance for credit unions. And with agentic AI already on board agendas at more than half of institutions in Cornerstone’s research, the next wave of use cases will act across systems on its own, which turns today’s review questions into questions about chains of automated actions.

Each shift raises the weight of the judgment and controls questions. A bank that scores and governs its portfolio now will be updating a working process when guidance arrives, while others build one under examination.

A 90-Day Sequence, Starting From Your Readiness Waves

These thresholds are a suggested framework from Maveric, not a regulatory standard. Much of the value sits in the conversation the exercise forces between technology, risk and the business.

Five Diagnostic Questions

Could your team name, today, the three AI use cases with the highest scores across the bank, and the data each one depends on?
If an examiner picked one AI-assisted customer decision from last quarter, how long would it take to explain it?
For each AI pilot running now, who reviews its output, and is that written down?
Which of your pilots had a baseline metric before they started?
How many AI features are running inside your vendor platforms, and who owns each one?

If two or more answers are uncertain, the bank is likely funding pilots faster than it can govern them.

The First 90 days

Weeks 1 to 3: Score. List candidate use cases with their business owners, including AI already embedded in vendor products, and score each on the five questions with all five owners in the room.
Weeks 4 to 8: Prepare. Trace each blocker to its source and fund the shared fixes first. Give each Wave 1 candidate a baseline metric and a named reviewer.
Weeks 9 to 12: Pilot. Launch one or two Wave 1 pilots with monitoring in place from the first day, and agree in advance the evidence that will justify scaling them.

Making It a Quarterly Rhythm

After the first cycle, the scorecard works best as a standing quarterly review with the same five owners. Each review re-scores the portfolio, moves use cases between waves as data and controls mature, takes running pilots through the scale gate and adds new candidates, including any AI that vendors have switched on since the last review. That discipline is where AI transformation in banking either compounds or stalls.

Score Your AI Use Cases

Maveric Systems works only in banking and financial services technology. The free AI in Banking Scorecard applies the five questions to 36 use cases across nine functions and returns a ranked shortlist with a starting wave for each. It takes under 10 minutes, keeps scores in your browser, and includes a Share for input link so colleagues can score the functions they own.

The research behind this framework:

For the trust architecture that sits underneath every use case, read the companion pillar, Engineering Trust in AI-First Banking.

If your board asked next week which three AI use cases the bank should fund next year, could you show the score behind each one, the data it depends on and the person who will review its output?

AI in Banking: How Regional Banks Decide Which Use Cases to Fund First Key Questions

What is AI in banking used for?

Banks use AI across fraud and financial crime, KYC and AML, lending, customer service, operations, compliance, software testing, data and analytics, and cybersecurity. Common examples include real-time fraud scoring, document verification, early warning for credit risk, case routing and automated test generation. The value depends less on the function than on whether the data, controls and human review point are ready.

How should banks prioritize AI use cases?

Score each candidate on value, data readiness, human review, controls and measurability, from 1 to 5 each. Treat any score of 1 or 2 as a blocker, then rank the unblocked use cases by total: 20 to 25 suggests a pilot now, 15 to 19 suggests preparing data or controls first, and below 15 suggests revisiting later. Score with technology, risk and the business together, and re-score every quarter.

Which AI use cases should a regional bank start with?

Start with use cases that score high on all five questions: a material problem, ready data, a clear review point, designed controls and an agreed baseline. These are often decision-support use cases, such as sanctions screening, case routing, early warning for credit risk or automated test generation, because a named person still makes the final call.

How does vendor-embedded AI change prioritization?

AI that arrives inside core, CRM, fraud or productivity platforms belongs on the same scorecard as the use cases a bank builds. The data and controls questions shift to what the vendor model sees and what the vendor will disclose, so contract terms covering performance data, change notice and decision-level explanations become part of the control.

Does SR 26-2 cover generative AI and agentic AI?

No. The April 2026 guidance, issued by the Federal Reserve, FDIC and OCC, replaces SR 11-7 and states that generative and agentic AI models are not within its scope. It is expected to be most relevant to banks with over $30 billion in total assets, and the agencies plan a request for information on AI, which had not been published as of late October 2026.

How does AI oversight differ for credit unions?

Credit unions are supervised by the NCUA, not by the interagency SR 26-2 guidance. GAO’s May 2025 report found the NCUA’s model risk guidance limited in scope and detail and recommended that it be updated, so credit unions need their own model risk standard, especially for vendor-supplied AI.

Why do so many AI pilots fail to scale?

BCG’s 2024 research found that 74% of companies had yet to show tangible value from AI, with most obstacles rooted in people and process. In banking, pilots most often stall on data access, unclear review points, controls designed after launch and review workloads that do not hold at production volume.

What is the Maveric AI in Banking Scorecard?

A free online tool that applies five questions to 36 AI use cases across nine banking functions and returns a ranked shortlist with a starting wave for each. It takes under 10 minutes, keeps scores in the browser, and lets colleagues add scores for the functions they own. The wave thresholds are a suggested framework, not a regulatory standard.

AI in Banking: How Regional Banks Decide Which Use Cases to Fund First