The Error You Will Not See: AI Governance for Banks and Fintechs

Picture a file. An AML alert fired on a customer’s account. A model reviewed it, pulled the transaction history and KYC record, wrote four coherent paragraphs explaining why the activity fit the customer’s profile, and closed it. The account citations are accurate. A QA reviewer pulls the file in the monthly sample, confirms the documentation supports the decision, and passes it.

The decision was wrong. The model never learned to recognize the structuring pattern this customer is using, and it has closed every alert of that kind the same way, with the same confident narrative, since it went live. Nobody has noticed, because every one of those files looks like the best work in the queue.

That is what AI changes in bank and fintech compliance. The law has not moved. Fair lending, UDAAP, the Bank Secrecy Act, privacy, information security, and third-party risk rules apply to a model as they apply to an analyst. What changes is how quietly, and at what scale, those obligations can be breached. An analyst with a blind spot errs occasionally and inconsistently, and controls were built to catch that. A model with a blind spot makes an error, documents it well, and makes it over and over again.

Regulators have left AI governance to institutions

When the federal banking agencies replaced SR 11-7 with SR 26-2 in April 2026, they placed generative and agentic AI outside the model risk guidance and left institutions to set their own controls. The OCC’s Spring 2026 Semiannual Risk Perspective says a request for information on AI is forthcoming; the guidance will follow. The same month, FinCEN’s proposed AML program rule encouraged institutions to consider generative AI for fighting financial crime. One agency is encouraging the tool while the others have, for now, declined to say how to govern it. Whether a generative tool is fit to close alerts or talk to a customer is a question each institution now answers for itself, with evidence it generates itself.

State regulators have published their approach. The AI Supervisory Framework the Conference of State Bank Supervisors released in September gives examiners a common approach to reviewing AI at banks and nonbanks. State regulators supervise nearly four in five FDIC-insured institutions, so its reach is wider than “state” suggests. It creates no legal obligation, but it is specific: its model risk supplement names confabulation, overreliance, and non-repeatable outputs as risks traditional model review misses.

Where AI breaks is the operating model, not the model

In AML, fraud, and KYC, the direction is set. AI takes first-level review and disposition; senior analysts handle escalations and check the machine’s work. The efficiency is real. So are three strains institutions tend to discover after the headcount decision is made.

People. When AI clears the routine volume, the human queue becomes almost entirely hard cases, and the junior roles where analysts learned what unusual looked like start to disappear. No one decides to stop training the next generation of investigators; it is a side effect of the staffing model. The analysts who remain spend their days reviewing a tool that is usually right, which is the condition under which people stop checking. A 2026 study in the Harvard Data Science Review had 2,784 people verify AI-extracted figures: when flagging an error took one extra step, people corrected less and accepted more wrong answers, and the participants most favorable toward AI performed worst. An institution that cuts headcount on projected savings before the tool has proven itself has removed its own fallback.

Process. QA built to catch human error asks one question: does the file support the decision? Against systematic machine error that is the wrong question, because the model’s files always support its decisions. QA for AI has to test the decision itself: independently re-review a sample of auto-closed alerts and of activity that never alerted, target the typologies the model handles poorly, set clear criteria for what goes to a person regardless of score, and keep SAR decisions with named individuals.

Technology. Log every disposition with enough rationale to reconstruct it in a lookback, so that when a flaw is found you know which cases it touched and can reprocess them. Vendor model updates should trigger review. Agentic tools need defined permissions and an off switch. Keep a tested manual fallback, and confirm the people assigned to it still know how to do the work.

Evidence before authority in AI risk management

The AI governance failure is rarely a missing policy. It is putting a tool into a regulated workflow before anyone has evidence it works, then treating the absence of visible problems as proof.

Make each expansion of the tool’s authority contingent on evidence from the stage before. First, inventory what is already running, including AI features vendors have switched on inside existing software; name an owner accountable to senior management and the board; and confine use to low-risk internal work a person checks line by line. Second, move the tool into regulated operations as decision support only, with analysts making the call, and treat that stage as measurement: the analysts’ agreement rate with the tool, its error cases, and any pattern in those errors. Only then let it execute, and only with performance data, tested controls, and QA built for machine error in hand. Re-approve when the model, vendor, or data changes. None of this is new; the common failure is skipping the second stage because the first went well and the vendor’s slides were persuasive.

The customer-facing AI version of the same problem

The stakes rise when the model touches a customer. If AI informs a credit denial, Regulation B requires specific and accurate reasons, and “the model said no” is not one. A chatbot that misstates a fee is the institution speaking, and a wrong answer can be a UDAAP or UDAP violation. One that gives the wrong dispute deadline can cost a customer the 60-day windows under Regulation E or Regulation Z. The potential scale of harm is both clear and difficult to comprehend: the CFPB estimated that, way back in 2022, 37 percent of Americans, about 98 million people, interacted with a bank chatbot.

A loan officer who gives bad adverse action reasons gives them to the applicants in front of him; a model gives them to every applicant it scores. So run AI through the product approval process you already have, with AI-specific steps; bring compliance in at design, not launch; test for disparate outcomes before release and keep testing; keep a person who can override consequential decisions; and know before launch how you would roll the feature back.

Where AI governance plugs into what you already run

AI governance cannot run as a silo. State privacy and AI laws are where fintechs, and through them their sponsor banks, are most often exposed without knowing it. Colorado’s SB26-189, effective January 1, 2027, no longer carves out banks and credit unions; it requires notice before an automated tool influences a lending decision, an explanation within 30 days of an adverse outcome, and human review on request. It excludes AML, sanctions, fraud, and identity verification from “consequential decisions,” so it reaches the credit side of this article and not the AML side. Map each law to the data and decisions it reaches before the data reaches a model. Vendor contracts need to cover data use and training rights, notice of model changes, incident reporting, and access to testing results; Colorado will require developers to give that notice from 2027, so put the term in your contracts now. And sponsor banks are beginning to require that fintech partners maintain documented AI policies and monitoring, because a bank’s third-party risk obligations extend to its partners’ AI.

The exam question for your AI risk management program

If an examiner, sponsor bank, or auditor asked tomorrow to see your AI risk management program, what would you show them? If the answer is a policy, a vendor’s validation report, and testing that has never found a problem, start with the testing.

‍