Five regulators’ AI questions read like an exam plan

The week

On March 29, 2021, five federal agencies announced a request for information on financial institutions’ use of artificial intelligence, including machine learning. The five were the Federal Reserve, the CFPB (the Consumer Financial Protection Bureau), the FDIC (which insures bank deposits), the NCUA (which supervises and insures credit unions) and the OCC (which charters and supervises national banks). Together, they are the main federal supervisors of banks and credit unions.

Artificial intelligence, in this context, means computer systems that make predictions or decisions that once needed human judgment, such as whether a transaction looks fraudulent. Machine learning is the most common way to build them today: instead of a person writing every rule, the system studies large amounts of past data and works out the patterns itself. A request for information, or RFI, is a formal invitation for the public and industry to tell regulators what they are doing and what worries them.

The RFI opened with a description of how institutions were already using AI. It listed flagging unusual transactions for fraud and anti-money laundering work, personalizing customer service through chatbots and call routing, making credit decisions with traditional or alternative data, managing risks such as loss forecasting and liquidity, analyzing text such as complaints and legal documents, and detecting cyber threats.

It then asked 17 numbered questions, grouped under headings: explainability, data quality and alternative data, overfitting, cybersecurity, dynamic updating of models, the use of AI by community institutions, oversight of third-party AI, fair lending, and a closing set on other uses, barriers and benefits. Five of the 17 questions concerned fair lending alone, the largest single group.

Some of those terms deserve a word now. Explainability is whether anyone can say why a model reached a particular decision. Alternative data means information beyond the traditional credit report, such as rent or cash-flow records. Overfitting is when a model learns the quirks of its training data so closely that it performs well in testing and poorly in the real world.

An appendix listed the laws and guidance the agencies considered relevant. It named safety and soundness standards, information security rules under the Gramm-Leach-Bliley Act, the Fair Credit Reporting Act, the Equal Credit Opportunity Act, the Fair Housing Act and the prohibitions on unfair, deceptive or abusive practices. It also named the 2011 model risk guidance, the agencies’ third-party risk guidance, a December 2019 interagency statement on alternative data in underwriting, and a July 2020 CFPB note on adverse action notices for AI models. Every item predated the RFI. The same five agencies had issued the alternative data statement together, so the RFI continued a joint line of work rather than starting one.

The request appeared in the Federal Register, the government’s official daily publication of rules and notices, on March 31. Comments were first due by June 1, and the agencies later extended the period to July 1. It did not propose any rule.

The week around it carried related signals. On March 23, the New York Department of Financial Services reported on its investigation of the Apple Card, issued by Goldman Sachs, after public complaints of gender bias in credit limits. It found no unlawful discrimination and found the decisions it reviewed explainable, while noting that weak customer service and a perceived lack of transparency had undermined trust. On April 9, the federal banking agencies, with FinCEN and the NCUA, issued a statement on applying model risk principles to systems used for Bank Secrecy Act compliance, with a separate request for information on that question.

Other events that spring set the backdrop. On March 30, the President signed a law extending the Paycheck Protection Program application deadline to May 31, and many lenders were still using automated intake and fraud screening to handle the volume. On April 21, the European Commission proposed its Artificial Intelligence Act, which would treat AI used for credit scoring as high-risk. American institutions with European customers took note.

Many observers filed the AI request under “wait and see.” Not every important regulatory moment arrives as a rule, though, and a document that required nothing still told banks and credit unions a great deal. A closer reading suggested that the questions described how examiners were already planning to look at AI.

A request for information can look like a regulatory non-event. Nothing became binding, and no AI rule followed. But the March 2021 RFI read like an examination plan, and that is how institutions should have read it.

Its questions sort into four tests drawn from rules that already existed: explainability, data, change over time, and third parties. None was new. Together they told institutions that AI would be judged against model risk, fair lending and vendor management expectations already on the books, so there was no reason to wait for an AI rule.

The RFI’s other headings fold into those four. Overfitting is a data problem. Cybersecurity of models and their inputs is part of the data test too. The community institution question lands mostly on third parties, because smaller institutions buy far more AI than they build. Fair lending runs through explainability and data.

The sections that follow explain what supervisors mean by a model, take the four tests one at a time, then show how they divide among teams, why the existing rulebook is enough, and how a single purchasing decision at a credit union plays out under each test.

What counts as a model, and who checks it

In banking, a model is any method that takes data in and produces an estimate or decision out. A credit score is a model. So is a system that flags a debit card transaction as possible fraud, or one that predicts how many customers will call the contact center next Monday. Models have been part of banking for decades. Many are simple formulas a person could check by hand.

Machine learning models are different in degree rather than kind. They can weigh hundreds of factors at once and find subtle patterns, which often makes them more accurate. The trade-off is that their inner workings can be hard for a person to follow. A traditional scorecard might say “add 20 points for five years at the same address.” A machine learning model might combine that fact with dozens of others in ways that are not obvious, even to the people who built it.

Because models drive decisions about money and people, supervisors expect banks to manage the risk that a model is wrong or misused. That discipline is called model risk management. Its core steps are familiar to anyone who has overseen a major project: build carefully and document what you did; have someone independent check the work, known as validation; approve the model formally before it goes live; and keep watching how it performs once it is in use.

A model is in effect a new employee making decisions on the institution’s behalf. You would check its qualifications before hiring, have someone review its early work, set out what it may decide, keep an eye on its performance, and expect it to explain its decisions to a customer who asks. The four tests in the RFI apply those expectations to software.

Which rulebook applies to whom

The 2011 model risk guidance was issued by the Federal Reserve as SR 11-7 and by the OCC as Bulletin 2011-12. The FDIC adopted it for the banks it supervises in 2017. Between them, those three agencies cover national banks, state banks and bank holding companies. The NCUA was not a party to that guidance, so federally insured credit unions faced model expectations through NCUA’s own examinations and its broader guidance on risk and third parties.

Consumer protection follows a different split. The CFPB supervises banks and credit unions with more than $10 billion in assets for compliance with federal consumer financial law, including the Equal Credit Opportunity Act. Smaller institutions are examined for those laws by their prudential regulator. A community bank and a large regional bank can therefore meet different examiners asking the same fair lending question about the same kind of model.

That split explains why the RFI had five signatories. Each of the four tests touches rules that more than one agency enforces, and no single agency could speak for all of them.

How supervisors scale expectations

Model risk guidance has always been meant to scale with the institution. A bank with hundreds of models and a dedicated validation group is held to a different depth of practice than a community bank with a handful of vendor tools. What does not scale away is the core expectation: know what models you use, understand their limits, and check that they work.

Institutions usually manage that through model tiering. Each model is assigned a risk tier based on how much money or how many customers its decisions affect, and how complex it is. High-tier models get full independent validation and frequent monitoring. Low-tier models get a lighter review. Tiering is where an institution decides how much of its limited validation capacity each AI tool deserves.

Test one, explainability: the adverse action problem

The RFI asked how institutions understood and explained the outputs of complex models. For credit, that is a compliance question with a specific legal hook.

Under the Equal Credit Opportunity Act and Regulation B, a creditor that denies credit or offers worse terms must give the applicant the specific principal reasons. This is the adverse action notice, the letter that tells an applicant why they were turned down. A model that cannot produce reasons the institution understands and can defend creates direct exposure.

In practice, institutions using machine learning in underwriting tend to pair the model with an explanation method that ranks the factors behind each decision, then map those factors to reason codes, the standard short phrases that appear in adverse action notices. The hard part is testing that the mapping is accurate. A reason code saying “insufficient credit history” must reflect what actually drove the score, not the nearest standard phrase.

The applicant bears the cost of a bad mapping. If a letter says “insufficient credit history” when the real driver was a high balance on one card, the applicant cannot fix the problem, and the institution has given a misleading explanation. Multiply that across thousands of decisions and it becomes a compliance finding and a fairness problem.

Beyond credit, explainability matters for fraud and anti-money laundering models, where investigators need to know why an alert fired, and for any automated decision that affects a customer or member. The workable standard is that the institution can explain, in terms an applicant and an examiner would accept, why the model did what it did. Simplicity is one way to meet that standard, but not the only one.

How explanation methods work, and where they fail

The RFI asked specifically about post-hoc explanation methods, tools that analyze a model after it is built to estimate which inputs mattered for a given decision. The common approaches assign each input a contribution to the score, or fit a simpler model that mimics the complex one near a particular applicant. Either way, the output is a ranked list of factors that can be mapped to reason codes.

These methods are estimates, and they have known weaknesses. Different methods can rank the same factors differently for the same applicant. Small changes in the input can shift the ranking. When inputs are strongly correlated, such as income and debt-to-income ratio, credit for a decision can be split between them in ways that are hard to interpret. A validation team has to test the explanation method itself as well as the model.

A practical test has three parts. Take a sample of declined applicants. Check that the reasons produced are stable when the method is rerun or the input is nudged slightly. Then have a credit expert confirm that the reasons are plausible and actionable for the applicant. Document the sample, the results and any changes to the mapping.

Explainability differs by use

The legal stakes vary by use. Credit decisions carry a specific notice obligation to the applicant. Fraud and anti-money laundering models carry no notice obligation to the customer, and institutions are generally barred from tipping off a subject about a suspicious activity report. There the audience for the explanation is the investigator and the examiner, who need to know why the alert fired and whether the system is missing patterns it should catch.

Marketing and customer service models sit at the low end of legal stakes, though not at zero. A model that steers some customers toward higher-cost products, or offers better terms to some groups than others, can raise unfair or deceptive practice concerns. The explanation standard there is internal: the institution should be able to say what the model optimizes and who it affects.

The case for simpler models

The strongest counter to complex models is that, for many credit decisions, a well-built traditional scorecard or a constrained machine learning model performs nearly as well and is far easier to explain. Some institutions concluded exactly that. They used machine learning to discover useful variables, then built a simpler model from them for the decision itself.

That approach trades a small amount of accuracy for a large gain in explainability and validation cost. For a community institution with no data science team, it is often the right trade. For a large card issuer where a small improvement in accuracy is worth a great deal, the complex model with a well-tested explanation layer may be justified. The test is the same either way: can the institution explain each decision accurately.

The New York Department of Financial Services’ Apple Card report, released the week before the RFI, showed the other side of explainability. The regulator found the decisions it reviewed explainable and lawful, yet customers had lost trust because no one explained them well. Explainability is a compliance property of the model and a service property of the institution.

Test two, data: quality, lineage and proxies

The second set of questions concerned the data feeding models. Machine learning can find patterns traditional methods miss, including patterns that act as proxies for protected characteristics. A proxy is a piece of information that is not itself about race, sex or age, for example, but that correlates closely enough with one of them that using it produces similar effects. A model never told an applicant’s race can still treat groups differently if it leans on factors that track race.

The RFI asked how institutions managed data quality and alternative data, such as cash-flow or rent payment data, and how they guarded against discrimination. Alternative data can help people with thin credit files get fair access to credit. It also needs care, because new data sources bring new ways to go wrong.

For most institutions, the binding constraint is data governance, the policies and practices that keep data accurate, documented and appropriately used. They need to know where training data came from, what population it represents, and whether that matches the population the model will score. That record of where data came from and what happened to it along the way is called lineage.

A model trained on approved applicants from one region, then used across a new market, can perform well in validation and badly in production.

Fair lending testing then needs its own data, because institutions generally cannot collect race or ethnicity for most non-mortgage credit and must estimate it to test outcomes. That creates an awkward but unavoidable task: to check that a model treats groups fairly, an institution has to build a careful, documented estimate of who is in each group.

Alternative data brings its own legal duties

The December 2019 interagency statement on alternative data, which the RFI cited, described cash-flow data, such as income and expenses seen in a bank account, as a promising way to assess applicants with thin credit files. It also reminded institutions that alternative data must be used in line with consumer protection law.

One consequence surprises some teams. When an institution obtains information about a consumer from an outside company and uses it in a credit decision, that company may be a consumer reporting agency under the Fair Credit Reporting Act. That brings obligations on accuracy, disputes and adverse action disclosures. Data that a vendor describes as alternative can still carry the full weight of credit reporting law.

Data drawn from the institution’s own accounts raises different questions. Using a member’s deposit history in a credit decision may be permitted, but the institution must be able to explain it, and should consider whether the data is equally available and meaningful across the groups it serves.

Overfitting and the population problem

The RFI’s overfitting question asked how institutions keep a model from learning noise, and how they adapt a model to a population different from the one it was trained on. Both are data problems.

Standard controls include holding back data the model never sees during training, testing on a later time period than the one used to build the model, and comparing the distributions of key inputs between the training set and the population being scored. A model that looks excellent on a random sample of past applicants and much worse on next year’s applicants has probably learned something specific to the past.

The population problem is sharper for purchased models. A vendor’s model may be trained on data pooled from many lenders whose customers look nothing like a particular credit union’s membership. The fix is a local validation: score a recent sample of the institution’s own applicants or transactions and compare predicted with actual outcomes before relying on the tool.

How fair lending testing works

Fair lending analysis of a model usually proceeds in steps. First, estimate group membership for the applicant population, often with a method that combines surname and geography to produce probabilities. Second, compare approval rates, pricing and other outcomes across groups. Third, where a disparity appears, test whether it is explained by legitimate credit factors. Fourth, search for a less discriminatory alternative: a version of the model that meets the business need with smaller disparities.

Mortgage lending is different because the Home Mortgage Disclosure Act requires many lenders to collect applicant demographics. A lender that does both mortgage and consumer lending will therefore run two kinds of fair lending analysis, one on reported data and one on estimates, and needs to explain the difference to examiners.

Security of the model and its inputs

The RFI’s cybersecurity question belongs in the data test because the risks run through data. A model can be manipulated by inputs designed to fool it, as fraudsters probe a scoring system to learn which transactions pass. Training data can be tampered with. A model exposed through an interface can leak information about the data it learned from.

The controls are extensions of existing information security programs. Restrict who can change training data and model files, log changes, monitor for unusual patterns of queries, and include models in penetration testing. Banks and credit unions already have information security obligations under the Gramm-Leach-Bliley Act. Those obligations cover the data feeding models as much as any other customer data.

Test three, change over time: models that keep learning

The RFI specifically raised dynamic updating, meaning models that retrain or adapt on new data. Traditional model risk management, set out in the Federal Reserve’s SR 11-7 and the OCC’s parallel 2011 bulletin, assumes a model is developed, validated, approved and then monitored. A model that changes itself challenges that sequence. A new employee who rewrote their own job description every month would make the original hiring checks less and less informative.

A common answer is to treat retraining as a controlled change. That means defined triggers, such as a drop in a performance measure or a shift in input distributions, thresholds that must be met before a retrained version goes live, and documented approval. Validation then shifts from approving a fixed artifact to approving the retraining procedure and its guardrails. The approach fits the existing framework. It also needs monitoring infrastructure many smaller institutions did not have.

The timing of the RFI made this concrete. Models trained on data from before 2020 met a world of stimulus payments, payment forbearance and sudden shifts in spending. Fraud and credit models that had been stable for years began to drift, meaning their accuracy slipped because the world they were predicting no longer looked like the data they learned from. Some institutions found they had no routine way to detect it beyond complaints from the business.

Drift monitoring, with named owners and agreed responses, turned out to matter for static models as much as for self-updating ones. A model does not have to change itself to go wrong. It only has to stay the same while everything around it changes.

What to measure

Useful monitoring measures are mostly simple. For inputs, compare the distribution of each important variable this month with the distribution in the training data, and flag large shifts. For outputs, track the share of applicants approved, the share of transactions flagged and the average score. For outcomes, compare predicted default or fraud rates with actual ones as loans season and fraud cases close.

Operational measures matter too. A rising rate of manual overrides by underwriters suggests the model no longer matches their judgment. A falling share of fraud alerts that lead to confirmed fraud suggests the model is flagging the wrong things. Rising complaints about declines are a lagging signal, but often the first one a small institution sees.

Each measure needs a threshold and an owner. A dashboard that nobody is responsible for reading does not count as monitoring.

The anti-money laundering case

Transaction monitoring systems for anti-money laundering are tuned constantly, as institutions adjust thresholds and scenarios to catch new patterns and reduce false alerts. Applying full model validation to every tuning change can freeze a system that needs to move.

The banking agencies addressed that tension on April 9, 2021, less than two weeks after the AI RFI. With FinCEN and the NCUA, they issued a statement on how model risk principles apply to systems that support Bank Secrecy Act compliance. It said the principles could be applied flexibly, that banks were not required to use a particular framework, and that it created no new expectations. The same tension applies to AI fraud models, and the same answer fits: define in advance which changes are routine and which need fresh validation.

The cost of controlling change

Tight change control has a price. Fraud patterns shift within days, and a fraud model that waits weeks for each retraining to clear validation will fall behind. Credit models move more slowly and can tolerate a longer cycle.

The workable compromise is a pre-approved envelope. Validation approves the retraining method, the data sources, the performance thresholds and the limits on how much the model may change. Retrained versions inside the envelope go live with a lighter review and a record. Anything outside it, such as a new data source or a change in model type, returns to full validation. The envelope makes speed and control compatible, provided someone checks that versions really stay inside it.

Test four, third parties: the vendor’s model is your model

The final test was oversight of AI supplied by vendors. Community banks and credit unions rarely build models. They buy fraud scoring, credit decisioning and chatbot services, or switch on AI features inside platforms they already use. The long-standing supervisory position is that using a vendor does not transfer accountability. If the vendor’s model makes a bad decision about your customer, it is your decision in the eyes of the customer and the examiner.

That creates a practical tension. Vendors often treat model details as proprietary, while institutions need enough transparency to validate, explain and monitor. Contracts resolve it, through rights to model documentation, independent validation reports, performance and fairness testing results, and advance notice of material changes.

The RFI’s separate question on community institutions pointed here. Smaller institutions face the same expectations with far fewer specialists, so most of the four tests land on vendor due diligence: asking the right questions before purchase and tracking outcomes such as approval rates, alert volumes and complaint themes after go-live. A short annual attestation from each AI vendor, covering changes made, testing performed and incidents, gives a small compliance team something concrete to review.

What the contract needs to say

A contract for an AI tool that affects customers should cover a short list of points. The right to receive model documentation sufficient for validation, including the training data population and known limitations. The right to see independent validation and fairness testing results, or to commission them. Advance notice of material changes to the model, data or explanation method. Access to decision-level data, so the institution can run its own monitoring. Support for adverse action reason codes where the tool affects credit. Cooperation with examiners and auditors.

Vendors resist some of these terms, and small institutions have little negotiating power alone. Credit union service organizations, bankers’ associations and shared due diligence arrangements give smaller buyers a way to pool requests and share the cost of reviews. The accountability still rests with each institution, but the work can be shared.

AI that arrives without a purchase decision

The harder third-party problem is AI that arrives as a feature. A core banking platform adds a fraud score. A contact center platform adds automated call summaries. A loan origination system adds an automated decision option. No new contract is signed for any of them, and nothing passes through procurement.

The control is a release review. Someone in the institution reads vendor release notes for AI features, decides whether each is switched on, and adds it to the model inventory if it is. Without that step, the inventory is wrong from the day it is written.

Where examiners can and cannot reach

The banking agencies have authority under the Bank Service Company Act to examine certain service providers to the banks they supervise, and they use it for major technology providers. The NCUA has long lacked comparable authority over credit union vendors, and has asked Congress for it. A credit union therefore carries more of the burden of vendor oversight itself, because its examiner cannot go directly to the vendor.

Partnerships between banks and fintech companies raise the same question in another form. When a fintech designs the credit model and the bank is the lender of record, the bank is accountable for the model’s compliance. Supervisors have been consistent that the partnership structure does not dilute that responsibility.

How the four tests show up inside an institution

In most institutions, responsibility for each test is spread across several teams.

The business line, such as consumer lending or fraud operations, chooses to use a model and lives with its results. It owns the decision to rely on the model and should be the first to notice when results look odd.

The model risk or validation team, which in a smaller institution may be one person or an outside firm, checks that the model works as intended and that its limitations are understood. This is where explainability and change over time are usually tested.

Compliance and fair lending staff own the adverse action notices and the testing for unfair outcomes. They depend heavily on the data team for the information they need.

The data and technology teams manage where training data comes from, how it is stored and how model performance is monitored. They make lineage and drift monitoring possible, or not.

Procurement and vendor management negotiate the contracts that determine how much the institution can see inside a vendor’s model.

No single team can pass all four tests alone. That is why the most useful governance step is often the simplest: a single list of models in use, each with a named owner who is responsible for pulling the right people together.

What a model inventory entry holds

An inventory entry does not need to be elaborate. For each model: its name and purpose, the business owner, whether it was built or bought, the vendor if any, the risk tier, the date of last validation, the monitoring measures and thresholds, the data sources, and whether it affects customers directly. For credit models, add the reason code mapping and the date it was last tested.

The inventory becomes the agenda for a model risk committee, which in a small institution may be a standing item at the existing risk or compliance committee. Each meeting reviews new models, models overdue for validation, and any that breached a monitoring threshold.

Small and large institutions do this differently

A large bank has a model risk management group with its own head, often reporting to the chief risk officer, and validators who specialize by model type. Its challenge is scale and consistency across hundreds of models and many business lines.

A community bank or credit union may have a dozen models, nearly all bought, and no one whose full-time job is model risk. Its practical approach is to assign model risk to an existing risk or compliance officer, buy validation from an outside firm for the highest-tier models, rely on vendor documentation for the rest, and invest time in the inventory and the contracts. The four tests are the same. The way of passing them is different.

The existing rulebook, applied seriously

The central message of the RFI was reassuringly simple: AI does not need a new rulebook to be governed well. It needs the existing rulebook applied seriously. That has consequences across the organization.

Customers and members experience models directly, in the loan they are offered, the card transaction that is declined, or the chatbot that answers their question. A model that is wrong, unfair or unexplainable shows up first as a frustrated customer.

Regulators will ask the four questions whether or not anyone writes an AI rule. An institution that can show its reason codes are tested, its data is documented, its models are monitored and its vendors are overseen will have a much easier examination.

Money and risk are at stake both ways. A drifting fraud model can let losses through or block good customers. A credit model built on unrepresentative data can approve the wrong loans or turn away the right ones. And fair lending findings can bring remediation costs and reputational damage.

Staff are affected too. Loan officers, fraud investigators and contact center agents work alongside models every day. They need to understand what the models do and feel able to question them. Often they are the first to notice that something has changed.

Two objections, and why the reading holds

One objection is that existing rules are too weak for AI. Model risk guidance was written for statistical models built by quants, and fair lending law relies on testing outcomes after the fact. Critics argued that opaque models at scale need new rules on transparency and bias.

A second objection runs the other way. Applying full model risk discipline to every AI tool, including a chatbot or a document classifier, could smother useful innovation, especially at small institutions that cannot afford validation for every tool.

Both objections have force, and both are answered by the same feature of the existing rulebook: it is risk-based. Tiering lets an institution apply light review to low-stakes tools and full validation to credit and fraud models. And the existing laws are more demanding than they look. A creditor that cannot explain a decline or show its model does not discriminate is already out of compliance, whatever the technology. The RFI did not settle the policy debate. It did tell institutions which standard they would be examined against while the debate continued.

A credit union buys a lending model

Suppose a community credit union buys a machine learning credit decisioning tool from a vendor to speed up small personal loans.

In the stronger version, the credit union’s contract gives it the vendor’s model documentation, an independent validation report and fairness testing results, and requires notice before any material change. Before go-live, the compliance officer checks a sample of declined applications to confirm that the reason codes match what drove each decision. The data team documents that the vendor’s training data came mostly from a different kind of lender and region, and the credit union runs a pilot on its own members before relying on the tool. After launch, a monthly dashboard tracks approval rates, decline reasons and complaints, with a named owner and agreed thresholds for escalation. Each year, the vendor provides a short attestation of changes, testing and incidents. When spending patterns shift, the dashboard shows it before members start calling.

In the weaker version, the credit union switches on the tool because it came bundled with its lending platform. Nobody reviews the reason codes. Nobody asks where the training data came from. The vendor updates the model without notice. Months later, a pattern of complaints about confusing decline letters reaches the CEO, and the credit union discovers it cannot explain how its own lending decisions are made.

The stronger version is not free. Negotiating the contract adds weeks to the purchase. The pilot delays the speed gain the tool was bought for. The compliance officer spends time each month on a dashboard. An outside validation for a high-tier model costs real money for an institution of that size. Against that, the weaker version’s costs arrive later and larger: remediation of affected members, a finding at the next examination, and the time spent reconstructing how the tool worked.

The four tests also give the credit union a sequence. Third-party terms come first, because they determine whether the other three tests can be run at all. Data comes next, in the pilot. Explainability is tested before go-live. Change over time is the monitoring that runs for as long as the tool is used.

The weaker version is assembled from familiar errors:

• Waiting for an AI rule instead of applying the model risk, fair lending and vendor expectations that already exist.
• Accepting generic reason codes without testing that they reflect real decision drivers.
• Ignoring the training population and assuming a model built elsewhere will work the same way here.
• Approving models once and forgetting them, with no drift monitoring or named owner.
• Treating vendor AI as the vendor’s problem, and signing contracts that give no right to documentation or notice of change.
• Not knowing where AI is in use, especially features switched on inside existing platforms without anyone deciding to use them.

Where model oversight starts

1. Where are we using models or AI today, including features that came built into vendor products? Do we have a complete list?
2. When we decline someone for credit, how do we know the reasons in the letter reflect what actually drove the decision?
3. How would we know if a model started drifting? Who watches for it, and what happens when they see it?
4. Do our vendor contracts give us documentation, validation reports, fairness testing results and notice before material changes?
5. If an examiner asked us tomorrow to explain one of our models, who would answer, and what would they show?

Strong answers will be specific and documented. If the answer to the first question is “we’re not sure,” that is the place to start.

The questions follow the order of the tests in reverse of how they usually fail. Inventory gaps hide everything else. Reason codes are the most visible failure to a customer. Drift is the one that grows unnoticed. Vendor terms decide whether any of the others can be checked. The examiner question simply asks whether all of it has been written down.

With hindsight

No AI-specific banking rule followed the RFI. Supervisors kept applying model risk, fair lending, consumer protection and third-party guidance. That bears out reading the 2021 questions as an exam plan rather than waiting for a rule.

The framework itself has moved. In April 2026 the Federal Reserve, OCC and FDIC replaced the 2011 guidance with revised, non-binding model risk guidance expected to matter most for banks with more than $30 billion in assets. It leaves generative and agentic AI out of scope and promises a separate request for information that will cover AI. Generative AI means systems that produce text, images or code; agentic AI means systems that can take actions on their own toward a goal. For many institutions, the new guidance raises as many questions as it answers about how the newest tools will be judged.

The 2026 guidance also rescinded several older documents, including the OCC’s model risk booklet for examiners and the April 2021 statement on Bank Secrecy Act systems. It said noncompliance with the guidance would not by itself lead to supervisory criticism. That followed an October 2025 OCC bulletin telling community banks that its model guidance did not require annual validation and that they could tailor validation to their risk. The direction of travel since 2021 has been toward lighter, more proportionate model expectations for most institutions.

Other pieces fell into place along the way. The agencies’ 2023 interagency guidance on third-party relationships reinforced the vendor test. The CFPB said in 2022 and 2023 that creditors using complex algorithms must still give specific and accurate adverse action reasons, confirming that complexity is no excuse for a vague decline letter. The underlying requirement sits in the Equal Credit Opportunity Act and Regulation B, whatever the status of any later guidance. The 2023 circular added that a creditor cannot simply pick from a sample list of reasons if none of them accurately describes what drove the decision.

Some expectations from 2021 did not hold. Many institutions assumed AI would bring heavier model validation for every tool. The trend for most banks and credit unions ran the other way, toward proportionality and fewer mandatory reviews. And the expected follow-up never became a rule. Five years on, the RFI’s main legacy is the structure of its questions, which supervisors, auditors and vendors still use when they ask how a model works.

Credit unions followed a separate track throughout. The NCUA did not join the 2023 third-party guidance or the 2026 model guidance, both issued by the Federal Reserve, FDIC and OCC, so credit unions had to read those documents as signals rather than as expectations addressed to them.

Outside the banking agencies, NIST published its AI Risk Management Framework in January 2023, a voluntary structure many institutions adopted to organize their AI governance. The Treasury Department ran its own request for information on AI in financial services in 2024. A broad federal executive order on AI, issued in October 2023, was revoked in January 2025. In Europe, the AI Act entered into force in August 2024 and classifies AI used to assess the creditworthiness of individuals as high-risk, which matters for any institution lending to EU residents.

Generative AI arrived in late 2022 and widened the use cases to customer-facing chat, document drafting and code generation, with new risks such as fabricated outputs and data leakage. Fabricated outputs are confident answers that are simply wrong; data leakage is sensitive information ending up somewhere it should not.

The four tests held up as a structure. What changed is scale: institutions now run many more models, many embedded in vendor products. That makes the simplest question, “where are we using AI?”, harder and more important than it was in 2021.

Federal policy toward AI regulation and consumer enforcement also shifted after January 2025, so institutions should confirm current supervisory expectations with counsel. Explainability, data, change and vendor oversight have outlasted the 2021 request. They are the questions any careful examiner, auditor or board member will keep asking, whatever the technology is called next.