Federal Reserve Guidance on Generative AI in Banking

The most common request in bank AI governance is for the Federal Reserve’s guidance on generative AI. The accurate answer is that there is not one. That is a more useful answer than a summary of something that does not exist, because it tells you where the obligation actually comes from.

There is no generative AI SR letter

As at the date on this page, the Board of Governors has not issued a supervision and regulation letter addressed to generative artificial intelligence or to large language models, and there is no interagency guidance dedicated to them. The Federal Reserve maintains a public index of its SR letters, and the fastest way to confirm the position for yourself is to read it rather than to trust this sentence. The Federal Reserve publishes its SR letters index.

This is deliberate rather than accidental. The agencies have said repeatedly that supervisory expectations are technology-neutral: the existing frameworks for model risk, third-party risk, consumer compliance, information security and operational resilience apply to an activity regardless of the technology used to perform it. Issuing an AI-specific letter would risk implying that the existing frameworks did not already apply.

The letters that do the work

• SR 11-7, model risk management (April 2011). The primary instrument. It governs development, implementation, use, validation and governance of models, and its vendor-model section reaches a hosted third-party model. Its hardest requirement for AI is effective challenge; see effective challenge applied to AI models.
• SR 23-4, interagency third-party risk management (June 2023). Governs the relationship with the model provider or the AI-powered vendor across the lifecycle. See third-party AI model risk.
• Consumer compliance frameworks. Nothing about the technology changes the Equal Credit Opportunity Act, the Fair Housing Act, the Fair Credit Reporting Act or the prohibition on unfair, deceptive or abusive acts and practices. The adverse action duty is the clearest concrete case: see adverse action notices when an AI model denies credit.
• Information security and resilience. The interagency guidelines establishing information security standards, and the architecture, operations and resilience expectations examiners work from, apply to inference infrastructure like any other.
• Board and management oversight. The general expectation that the board understands and oversees material risks is what turns an AI programme into a board-reportable item once it is material.

If you want one sentence for a governance committee: the Federal Reserve’s expectation for generative AI is that you apply SR 11-7 and SR 23-4 to it, and that you can show you did.

What is not guidance

A great deal of material is quoted as though it established expectations. It does not, and the distinction matters when someone asks what your programme is built on.

Speeches. Governors and Reserve Bank presidents have spoken about AI in financial services, and those remarks are useful for reading the direction of supervisory attention. They are expressly the speaker’s own views and are not Board policy. Citing a speech as a requirement is a category error.

Requests for information. In March 2021 the Federal Reserve, the OCC, the FDIC, the National Credit Union Administration and the Consumer Financial Protection Bureau jointly published a Request for Information and Comment on Financial Institutions’ Use of Artificial Intelligence, Including Machine Learning. The Federal Register carries the notice. It asked questions about explainability, dynamic updating, data quality, overfitting and third-party use. It produced a substantial comment file and, to date, no rule and no consolidated guidance. That outcome is itself informative: the agencies looked at whether new AI rules were needed and did not issue them.

Reports and studies. The Treasury Department and the Financial Stability Oversight Council have published work on AI in financial services, and the Financial Stability Oversight Council’s annual reports have identified AI as a vulnerability to monitor. These are analysis, not supervisory expectation, and they bind nobody.

The genuinely open questions

Four things are unresolved, and a governance document that pretends otherwise will be wrong in a predictable direction.

Whether a generative system is a model. Discussed at length under SR 11-7; the definition speaks of quantitative estimates and a text generator does not obviously produce one. No agency has resolved it in writing. What would resolve it is amended or supplemental interagency model risk guidance.

What validation means for an opaque third-party model.SR 11-7 requires developmental evidence and conceptual soundness review. Providers do not supply the first and no one outside them can perform the second. Examiners have in practice accepted empirical validation on the institution’s own data plus strong use limits, but that is a supervisory practice observed second-hand rather than a published position.

Explainability for consumer-facing decisions. The statutory adverse action duty requires specific principal reasons. Whether post-hoc attribution methods satisfy it for a model that is not intrinsically interpretable has never been tested in litigation. Until it is, the conservative reading — that the duty is on the outcome, not on the method, and a model whose reasons cannot be stated should not be making that decision alone — is the defensible one.

Concentration and third-party dependency at sector scale. Identified as a vulnerability in official reports; no supervisory expectation has been attached to it.

A defensible posture in the meantime

1. Inventory every generative AI use, including ones adopted inside business units without a procurement process, and classify each by the consequence of the decision it touches rather than by cost.
2. Bring anything touching a credit, suitability, pricing, fraud or customer-communication decision inside the model risk framework, and record the reasoning for anything you leave outside.
3. Run the third-party file under SR 23-4 for each provider, and get the subcontractor chain named rather than described.
4. Validate empirically on your own data, stratified by protected class proxies where lawful to do so, and re-validate when a model version changes.
5. Log the model version, prompt template version and output for every consequential decision, and keep it for as long as the underlying record retention rule requires. This is the artefact an examination will actually ask for.
6. Report material AI risk to the board, and be able to show when you started.

None of that depends on a new SR letter arriving. If one does arrive, an institution that has done the six steps above will be revising documentation rather than starting.