Enterprise

AI in Regulated Finance: What Banks Can Deploy Today Without Failing an Audit

39 mins | Published: October 19, 2026

AI in regulated finance: what banks can deploy today

Last verified: October 16, 2026. We re-check this guide to AI in banking compliance every quarter against primary sources, from SR 26-2 to the EU AI Act.

TL;DR

The US banking agencies replaced SR 11-7 with SR 26-2 on April 17, 2026. The new guidance sets no enforceable standards and excludes generative and agentic AI, so each bank documents its own framework for those systems.
Credit scoring stays high-risk under the EU AI Act, and its obligations now start on December 2, 2027.
AI built mainly to detect financial fraud falls outside the Act’s credit-scoring clause, although GDPR still reaches its decisions.
Chatbot disclosure under Article 50 has applied since August 2, 2026, so an undisclosed assistant is an open compliance gap.
The audit-safe deployment map below sorts nine common bank use cases into three zones, from immediate deployment to hold.
The evidence pack lists eight artifacts an examiner asks for, and a governed build produces them as the system takes shape.

Two things changed for AI in banking compliance in 2026

Banks don’t fail AI audits because the model was wrong. They failed because the evidence wasn’t there. Our study of 33 practitioners working with AI in regulated sectors, 9 of them in fintech, found the same pattern. In that sample, 19 of the 33 blocking constraints concerned producing evidence rather than model accuracy. The 6 respondents who quantified their remediation reported between 6 weeks and more than a year of work. All of it went into systems that already functioned.

Classification is the second failure point, when a team places a system in the wrong regulatory category at scoping. The question then stays closed until an examiner reopens it. Both failures became harder to avoid in 2026, because the two reference points banks steer by have moved.

What is SR 26-2, and what did it replace?

SR 26-2 is the Federal Reserve’s April 17, 2026 letter issuing revised interagency guidance on model risk management, which replaced SR 11-7 and excludes generative and agentic AI. The OCC issued the same guidance as OCC Bulletin 2026-13, and the FDIC issued it as FIL-15-2026. Together, the agencies rescinded the 2021 interagency statement on model risk for BSA/AML systems. The OCC also withdrew its 1997 guidance on credit scoring models, along with the Model Risk Management booklet of its Comptroller’s Handbook.

The successor takes a risk-based approach, and it calls itself most relevant to banks above $30 billion in total assets. The FDIC’s letter adds that the guidance sets no enforceable standards and that non-compliance with it alone “will not result in supervisory criticism.” That word “alone” keeps unsafe practices and legal violations open to supervisory criticism.

The guidance’s definition of a model leaves out deterministic rule-based processes. The agencies promised a request for information on AI model risk at the same time, and they had not issued it as of October 16, 2026.

The EU kept its classification and moved its calendar

Credit scoring still counts as high-risk under Annex III point 5(b) of the EU AI Act. The Digital Omnibus reached the Official Journal on July 24, 2026, and entered into force three days later. It moved standalone Annex III obligations to December 2, 2027. Annex I obligations for AI inside regulated products now start on August 2, 2028.

The Omnibus kept the Article 50 transparency duties on their original schedule. For banks, the relevant change is a four-month grace period for marking content from generative systems already on the market. Point 5(b) also excludes AI used to detect financial fraud, which moves fraud work to the front of a bank’s AI roadmap. Our guide to how the EU AI Act changes AI development covers the full timeline beyond banking.

The sections below map a bank’s AI estate by use case, and each verdict names the evidence an examiner expects. SumatoSoft wrote this guide from official sources, drawing on our banking software delivery under both regimes. It does not constitute legal advice, and edge-case classification calls for counsel.

The audit-safe deployment map

Every AI use case in a bank falls into one of three zones. Deploy means no new regime attaches, so existing controls carry the use case. Deploy with controls means a named obligation applies and the bank can meet it now. Hold means the full high-risk stack applies, or no framework covers the use case yet.

Use case	Zone	What applies	When	Verdict
Fraud detection and transaction monitoring	Deploy	Outside Annex III point 5(b). GDPR Article 22 and FATF Recommendation 15 still apply	In force now	Deploy with the evidence pack
Internal and back-office automation	Deploy	Minimal risk. Scope on what the tool decides	In force now	Deploy, scope before you build
Engineering and developer tooling	Deploy	Article 4 literacy duty only. Exposure is code confidentiality and dependency provenance	In force now	Deploy, govern the data path
Customer-facing chatbots and servicing	Deploy with controls	AI Act Article 50 disclosure	Applies since August 2, 2026	Deploy, disclosure is already due
Personalization and next-best-offer	Deploy with controls	AI Act Article 5(1)(a) and 5(1)(b) prohibitions	In force since February 2, 2025	Deploy after a prohibited-practice review
AML risk profiling and customer risk rating	Deploy with controls	BSA/AML model risk statement rescinded April 17, 2026	Framework now self-set	Deploy, document your own tiering
Credit scoring and creditworthiness	Hold	Annex III point 5(b) and the Article 27 FRIA. GDPR Article 22 per Case C-634/21 applies now	December 2, 2027	Hold the launch, start the work
Insurance risk assessment and pricing	Hold	Annex III point 5(c). Same high-risk stack	December 2, 2027	Hold, run it with credit
Generative and agentic AI in decisioning	Hold	Outside SR 26-2 scope. Annex III point 5(b) still applies to credit use	Framework pending	Hold decisioning, deploy assistance

What decides where a use case lands

Two factors decide placement: the system’s intended purpose and the regime that attaches to that purpose. That regime can be an AI Act tier, a US examiner expectation, GDPR, or a sectoral rule such as the Consumer Credit Directive.

Of the two, purpose carries more weight than most model inventories give it. Classification follows what the system does, whatever model it runs. A gradient-boosted model that detects fraud stays outside the high-risk tier, while the same model scoring creditworthiness falls inside.

Article 6(3) offers an exit for Annex III systems that perform only a narrow procedural or preparatory task. The same article treats any Annex III system that profiles natural persons as high-risk, which rules the exit out for credit scoring. A provider relying on Article 6(3) must still register the system, a duty the Omnibus kept.

The Commission published draft guidelines on high-risk classification on May 19, 2026, and extended the consultation to July 23. Final guidelines are due by the end of 2026. Where a system’s purpose stays unclear, an AI readiness assessment that sorts the backlog costs less than a misclassification an examiner finds.

Green: What banks can deploy today

Can banks deploy AI fraud detection under the EU AI Act?

Yes, when detecting fraud is the system’s main purpose. The EU AI Act carves fraud detection out of its credit-scoring clause; credit scoring itself stays high-risk. Annex III point 5(b) names creditworthiness evaluation and credit scoring as high-risk, then excludes AI used to detect financial fraud. The Commission’s draft guidelines read that exception narrowly, according to summaries by DLA Piper and William Fry. Fraud detection has to be the main intended purpose, and the exception does not extend to AML/CFT checks.

AML transaction monitoring and sanctions screening stay outside point 5(b) unless their purpose links to a credit decision. On their own, they assess no one’s creditworthiness. Other regimes still reach both kinds of system, starting with GDPR Article 22 on solely automated decisions with legal or similarly significant effects. An automated block that closes an account is that kind of decision. FATF Recommendation 15 also requires a risk assessment before a new technology goes live. AML case files, in addition, need a trail showing why an alert fired and who closed it.

Verdict: deploy, and build the evidence pack you would want anyway.

Internal and back-office automation

Back-office tools such as KYC document extraction, contract review, reconciliation support and regulatory-reporting drafts carry minimal risk under the AI Act. The scoping question is what the tool decides, because a human reviewer adds a control without changing the classification. Our framework for planning custom AI automation covers how operations teams sequence this work.

An internal tool that starts deciding about employees moves into the employment category of Annex III. Performance scoring and task allocation based on individual behavior both put a tool in that category. Scope the employment use separately from document processing, even when one model serves both. A bank draws that line during AI integration work, when the tool first meets HR and operations systems.

Verdict: deploy, after scoping what the tool decides.

Engineering and developer tooling

Verdict: deploy, after scoping what the tool decides.

Amber: What banks can deploy with specific controls

What does Article 50 require from bank chatbots?

Article 50 requires providers to design interactive AI systems so that people know they are dealing with AI. The Omnibus did not defer that duty, which has applied since August 2, 2026. A bank running an undisclosed assistant therefore has an open gap today. Closing it takes a disclosure in the interface and a record showing when that disclosure went live.

A bank that builds its own generative assistant is that system’s provider, so Article 50(2) also requires machine-readable marking of its output. An assistant already on the market before August 2, 2026 has until December 2, 2026, to add that marking.

A servicing bot also needs a boundary around advice. Once its output resembles an investment recommendation, MiFID II suitability rules attach to answers the bot was never scoped to give. A route to a human agent belongs in the same design, since disputes and complaints need a person who can act on them.

Verdict: deploy, with disclosure live now and a hard boundary against advice.

Personalization and next-best-offer

Most personalization carries minimal risk, but the Article 5 prohibitions, in force since February 2, 2025, apply in full whatever the risk tier. Article 5(1)(a) bars tricks that steer people into choices they would not otherwise make, through manipulation or deception. Its neighbor, Article 5(1)(b), bars exploiting vulnerabilities, including those that stem from a person’s economic situation.

Nudges inside credit or debt-collection flows cross those lines when they exploit financial distress. The risk runs higher for lenders, because their customer base includes exactly the people Article 5(1)(b) protects. A concept that depends on that pressure needs redesign at the product stage, since no model-level control removes it. Under Article 99 of the AI Act, penalties for prohibited practices reach €35 million or 7% of global annual turnover. Breaches of high-risk duties carry up to €15 million or 3%.

Verdict: deploy after a prohibited-practice review at scoping, with a documented line between relevance and pressure.

AML risk profiling and customer risk rating

AML risk rating borders the fraud exception without falling under it. The Commission’s draft guidelines exclude AML/CFT checks from that exception, and a customer risk-rating model evaluates laundering risk rather than creditworthiness. When its output decides whether a customer opens or keeps an account, GDPR Article 22 attaches to that decision.

The April rescission hit this row more directly than any other in the map. It withdrew the interagency statement on model risk for BSA/AML systems, issued as OCC Bulletin 2021-19 and SR 21-8. Compliance teams cited that statement when they defended their transaction-monitoring tiers. No successor covers that ground, so each bank now sets its own tiering logic and defends it at examination.

In the EU, the single rulebook comes from the AML Regulation, which applies from July 10, 2027. The new Anti-Money Laundering Authority adds direct supervision of selected institutions from 2028, and with it a higher bar for evidence. Our guide to choosing a fintech development partner tracks that timeline.

Verdict: deploy, after scoping what the model decides and documenting your own tiering.

Red: What should wait, and what to do meanwhile

Is credit scoring high-risk under the EU AI Act?

Yes, AI that evaluates the creditworthiness of natural persons, or sets their credit score, is high-risk under Annex III point 5(b). Its obligations start on December 2, 2027, and cover the full high-risk stack:

Risk management under Article 9 and data governance under Article 10
Technical documentation under Article 11 and Annex IV, plus automatic logging under Article 12
Transparency toward deployers under Article 13 and human oversight under Article 14
Accuracy and robustness under Article 15, alongside a quality management system under Article 17
Conformity assessment under Article 43 and registration in the EU database under Article 49

Why the work starts before December 2027

Two EU duties make waiting until 2027 the wrong plan. From December 2, 2027, Article 27 requires a bank deploying a point 5(b) system to complete a fundamental rights impact assessment, or FRIA, before first use. A deployer that assumes the provider’s conformity work covers this duty reaches first use without one. Article 27(4), as the Omnibus rewrote it, lets the FRIA cross-reference the relevant sections of an existing data protection impact assessment instead of repeating them.

The second duty already applies through GDPR, as the Court of Justice made clear in Case C-634/21 on December 7, 2023. The court held that a credit reference agency makes an automated individual decision when it produces a score that lenders draw strongly on. The obligation therefore reaches the party producing the score as well as the lender relying on it. Bird & Bird’s analysis explains that consequence, which holds whatever the AI Act calendar says.

The US adverse-action duty

The US layer points the same way, because Regulation B requires a specific statement of the principal reasons for adverse action. The same section rules out reasons that cite only the creditor’s internal standards or the applicant’s failure to reach a qualifying score. Algorithmic complexity is not a defense. A model that cannot attribute an outcome to particular inputs cannot support a compliant notice.

The CFPB withdrew its 2022 circular on complex algorithms in May 2025. The regulation and its official interpretations stayed in force, as the National Consumer Law Center points out. The duty to explain each denial has not changed.

Verdict: hold the launch and start the work. The work between a well-scoring model and a live one is documentation. It covers bias testing against defined groups, per-decision reasons, an override path with authority to change outcomes and a monitoring plan. The Annex III date leaves 14 months from October 2026, and that documentation belongs at the start of the window. A bounded proof of concept with explicit exit criteria makes a sound first step. Custom machine learning development for the production model should begin in parallel.

Insurance risk assessment and pricing

Annex III point 5(c) covers AI used for risk assessment and pricing of natural persons in life and health insurance. The stack and the date match point 5(b), and the Article 27 FRIA applies to deployers here too. An insurer running both lending and underwriting models gains nothing from two programs, because the artifacts and the bias testing carry across.

Verdict: hold, and run it as the same program as credit.

Generative and agentic AI in decisioning

SR 26-2 excludes generative and agentic AI, and its model definition leaves out deterministic rule-based processes. Both exclusions remove the framework a bank would have cited, while the risk itself stays where it was. Until the planned request for information produces guidance, material uses need a substitute framework. The NIST AI Risk Management Framework and ISO/IEC 42001 both serve, each backed by internal controls the bank can defend.

The EU offers no exemption either. A generative system that contributes to a creditworthiness assessment stays within point 5(b), whatever technique it uses.

Assistance falls outside decisioning, which leaves room to deploy now. A search tool over internal policy and rule documents helps staff without deciding anything about a customer. Our agentic RAG implementation guide describes that pattern.

Verdict: hold for decisioning and deploy for assistance, with an internal framework documented for both.

The evidence pack: What an examiner asks for

An examiner reviewing an AI system in regulated finance works from its file, and duties across every regime converge on the same artifacts. The EBA reached a similar conclusion in its November 2025 mapping of the AI Act against banking and payments law. It found no significant contradictions and judged the Act complementary to rules banks already follow.

Timing decides whether that file holds up, as our compliance and audit barriers research shows. In that study, 7 respondents named retrofitted records as an approach that failed under review. Another 9 named evidence captured at the moment of decision as a practice that worked.

Eight artifacts mapped to regimes and build phases

Artifact	Why an examiner asks for it	Which regime wants it	Where it comes from in the build
Model inventory entry	The system is classified and has a named owner	AI Act Article 11, SR 26-2	Scoping
Data lineage and provenance	Where every feature came from and what happened to it	AI Act Article 10, GDPR	Data engineering
Validation report	Performance, benchmarks, known limits and tested boundaries	AI Act Article 15, SR 26-2	Evaluation
Bias and fairness testing	Documented thresholds against defined groups	AI Act Article 10, ECOA Regulation B	Evaluation
Per-decision explanation	The artifact behind an adverse-action notice	ECOA Regulation B, GDPR Article 22	Model design
Human oversight log	A person held override authority and used it	AI Act Articles 14 and 26	Controlled deployment
Monitoring and drift thresholds	Evidence that the bank would notice degradation	AI Act Articles 72 and 26, SR 26-2	AgentOps
Vendor governance file	Supplier documents mapped to Annex IV	AI Act Articles 25 and 26, DORA	Procurement

Where evidence programs stall

The model inventory needs two classification fields, because an AI Act tier and a model-materiality tier belong to different schemes. Those schemes do not map onto each other, so a single field forces a wrong choice for one of them.

Data lineage is where credit programs built on legacy cores lose the most time. Many bank ML pilots stall at the same point: models built in Python never get a steady feed from legacy SQL cores. Article 10 turns that integration debt into a documentation problem. Our guide to modernizing legacy systems with custom AI covers the engineering side.

Model performance starts to drift once it meets live data, and the Act responds with two monitoring duties. Providers run post-market monitoring under Article 72, while deployers monitor operation under Article 26. For banks, Article 26 folds log retention and monitoring into governance records they already keep under financial services law. The file still has to show that the bank would catch drift before a customer does.

A governed AI development lifecycle emits these artifacts as a by-product of its phases, from guardrails through red-teaming to AgentOps. Article 4, as amended by the Omnibus, also requires measures that support AI literacy among the staff who run these systems. Training records therefore belong in the same file.

Vendor models and the deployer’s obligations

A bank that licenses a scoring model from a fintech is the deployer, and the fintech is the provider. Both carry duties under the AI Act, and a procurement contract leaves the deployer’s share with the bank. Providers bear the heavier burden of documentation and conformity assessment. Deployers still owe the Article 26 duties: competent human oversight, use according to the provider’s instructions, log retention and monitoring. For point 5(b) and 5(c) systems, the deployer also owes the Article 27 FRIA. Buying a model does not outsource the audit answer.

Roles can also reverse, because a bank that substantially modifies a licensed system takes on provider obligations under Article 25. The same applies when the bank puts the system to a purpose the provider did not intend. Our EU AI Act guide walks through this fine-tuning trap. In our compliance research, 5 respondents named treating a supplier’s certification as internal validation as a practice that failed.

Vendor selection as an audit control

Vendor selection therefore works as an audit control, and the useful questions are narrow. Ask where compliance lives in the vendor’s own lifecycle, then check the documents you receive against Annex IV. In addition, confirm whether the architecture changes your regulatory role and who owns each artifact after the contract ends. Our 10 questions to ask an AI development company cover the governance side of that review. The commercial side, meanwhile, appears in our fintech development partner shortlist.

On September 11, 2026, four US agencies proposed to replace their 2023 interagency guidance on third-party risk management. The OCC, the Federal Reserve, the FDIC and the NCUA are taking comments until November 16, 2026. The proposal contains no AI-specific provisions, so an AI vendor falls under the same general expectations as any other supplier.

One control program across three regimes

The AI Act and DORA draw on the same controls, including risk management, third-party governance, resilience evidence and logging. The PSD3 and Payment Services Regulation texts that EU institutions agreed in November 2025 add to that overlap. Banks that implemented DORA already hold much of the capability, such as ICT third-party registers and resilience testing. They can extend it to AI, and the EBA’s mapping supports that approach.

Model risk works the same way, since rescinding SR 11-7 left intact the programs banks built under it. Those programs also remain the best available scaffolding for the work under Articles 9 to 15. Banks now justify their own framework where they previously cited a bulletin.

The US guidance calls itself most relevant above $30 billion in assets, so smaller institutions get less direction from it. For them, a self-documented framework therefore becomes the main reference an examiner has. Our AI readiness research surveyed 72 leaders across 30+ industries. Of those, 61% cited rebuilding processes around AI as the #1 factor in moving from pilot to production. Another 58% named messy or fragmented data as their biggest readiness gap, and both weaknesses surface again in a thin audit file.

Build one control set and tag each control to every regime it serves, so the investment happens once. That approach also lets financial software development and compliance engineering run as one workstream.

Frequently asked questions about AI in banking compliance

Was SR 11-7 rescinded, and what replaced it?

SR 11-7 was rescinded in April 2026, and the guidance that replaced it puts generative and agentic AI outside its scope. That exclusion leaves a governance gap, which each bank fills with its own documented framework. The OCC, the Federal Reserve and the FDIC issued the replacement on April 17, 2026, as OCC Bulletin 2026-13, SR 26-2 and FIL-15-2026.

Is AI fraud detection high-risk under the EU AI Act?

No, fraud detection is not high-risk under the credit-scoring clause when detecting fraud is the system’s main purpose. Credit scoring itself stays high-risk under that clause, and GDPR Article 22 still reaches automated fraud decisions with legal or similarly significant effects.

When do the EU AI Act’s credit-scoring rules apply?

They apply from December 2, 2027, after the Digital Omnibus moved them from August 2, 2026. The Omnibus, Regulation (EU) 2026/1744, entered into force on July 27, 2026. GDPR exposure for scoring applies today, independent of that calendar.

Does the EU AI Act apply to a US bank?

It applies when a US institution places an AI system on the EU market. It also applies when the system’s output reaches users in the EU, which EU customers or an EU branch can trigger.

What is a fundamental rights impact assessment, and who has to do one?

A FRIA is the Article 27 assessment of how a high-risk system affects the people subject to its decisions. The deployer completes it before first use, so a bank running a point 5(b) or 5(c) system carries the duty.

Can we still use a model we can’t fully explain for lending decisions?

Not for decisions that trigger an adverse-action notice, because Regulation B requires specific principal reasons for each one. Algorithmic complexity is not a defense. SHAP values and counterfactual methods produce per-decision reasons from complex models, so the constraint is engineering effort rather than model class.

Does buying an AI model from a vendor transfer the compliance obligation?

The obligation stays split between vendor and bank. Buying a model does not outsource the audit answer. The vendor, as provider, carries documentation and conformity duties. The bank, as deployer, carries the Article 26 duties, plus the Article 27 FRIA for point 5(b) and 5(c) systems.

What AI can a bank safely put in production right now?

Fraud detection and transaction monitoring can go live today, and so can internal automation and engineering tooling. Chatbots and personalization need named controls first, as does AML risk rating. Credit scoring and insurance pricing should wait while the documentation work starts, and generative decisioning should wait for a framework.

Conclusion: Build the evidence with the system

The rules for AI in regulated finance moved twice in 2026, and the next changes already have dates or announced processes. The nearest is the Article 50(2) marking deadline on December 2, 2026, and the Annex III start follows in December 2027. The US request for information also remains pending. A bank protects its roadmap by building systems whose evidence survives those changes. An artifact produced during the build answers the question whichever regime asks it.

A bank that sorts its estate by what the rules say can start with the use cases those rules leave open. It can then build the file alongside each system from the first sprint. Banks don’t fail AI audits because the model was wrong. They fail because the evidence wasn’t there.

SumatoSoft has built custom software since 2012 and has delivered 350+ products for clients in 25+ countries. It holds ISO 27001 and ISO 9001 certification. Our banking and fintech development work runs from a Boston headquarters and a Warsaw engineering center, which places our teams inside both regulatory perimeters. Our governed AI development lifecycle produces the evidence pack as part of delivery. Documented systems reach production sooner as a result, because examiners and validators work from records that already exist.

For the regulatory picture beyond banking, read how the EU AI Act changes AI development. For the enterprise-wide risk surface, see the seven enterprise AI adoption risks. Before you shortlist a build partner, work through the 10 questions to ask an AI development company.

Map your AI estate against what the rules say

Bring your AI backlog, and our engineers will sort it into the three zones. They also flag where your architecture changes your regulatory role, and you receive the evidence pack each use case needs. SumatoSoft holds ISO 27001 certification and delivers banking software under both US and EU rules. The assessment covers engineering readiness and does not replace legal advice.

Schedule a readiness call

Download the Bank AI Deployment Map and Evidence Checklist

The checklist gives one page per zone. Each page covers the classification questions, the artifacts an examiner asks for, the vendor-governance questions and a readiness score for your team.

Get the checklist (PDF)

About the author

Katerina Merzlova is a Digital Transformation Consultant at SumatoSoft who authored its 2026 study of compliance and audit barriers to AI in healthcare and financial services. She also co-authored the company’s research on how businesses move AI from pilot to production.