Which AI regulation applies first to a bank?

They apply together. A US bank running an LLM in a credit workflow is under SR 11-7 for model risk, ECOA and Regulation B for the credit decision, and GLBA for the customer data, at the same time. An EU bank adds DORA, the ECB's supervisory expectations, and the EU AI Act's high-risk classification. There is no sequencing where one clears before the next begins, which is why banks treat the shared operational evidence as the efficient place to invest rather than building a separate control per regime.

Does SR 11-7 cover large language models?

SR 11-7 defines a model broadly as a quantitative method that produces outputs to inform decisions, and supervisors have applied that definition to AI and machine learning systems. An LLM that informs a decision falls within scope, which brings development standards, independent validation, and ongoing monitoring. The practical difficulty is that validating a non-deterministic third-party model with traditional techniques is limited, so production monitoring of what the model is actually asked and what it returns carries more of the weight.

What evidence does the ECB letter expect by October 31?

The ECB asked its 110 directly supervised banks for plans covering faster vulnerability and threat monitoring, stronger detection, and closer scrutiny of third-party technology providers, including AI providers. The in-scope slice for an AI deployment is the ability to monitor AI traffic, show which provider processed what data, and produce a per-decision record a supervisor can inspect. The deep dive on the letter covers which of the ECB's asks a request-layer control produces evidence for and which sit elsewhere.

How does fair lending law reach an AI model?

The Equal Credit Opportunity Act and Regulation B govern the decision, not the technology, so a model that contributes to declining an applicant triggers adverse-action notice requirements and disparate-impact scrutiny. Compliance depends on reconstructing what the model received and returned for a specific applicant, which requires a record of the request and response tied to an identity. Without that record, a bank cannot produce the principal reasons a notice requires or defend against a disparate-impact finding.

AI Compliance in Banking: The Regulatory Map for a Bank Running LLMs

A bank that puts an LLM into a customer-service workflow or a credit-decision pipeline does not pick up one AI regulation. It picks up model risk guidance from its prudential supervisor, operational resilience rules on its technology providers, fair lending law on any decision that touches credit, and data protection statutes on the customer records in the prompt, all at once. On July 7, 2026 the European Central Bank wrote to the 110 banks it directly supervises and gave them until October 31 to file plans against AI-enabled threats, which is one more deadline stacked on the existing regime. I want to map the frameworks a bank compliance officer has to satisfy together, point to the deep dive on each, and show the operational thread that runs through all of them.

Model risk: SR 11-7

In the United States, an AI model that informs a decision falls under the model risk management guidance in Federal Reserve SR 11-7 and OCC Bulletin 2011-12. The guidance requires sound model development, independent validation, and governance across three lines of defense. LLMs strain each of those, because a vendor model is opaque to the validation team and non-deterministic across runs. The full treatment is in banking AI model risk and SR 11-7, and the compliance point here is that a bank has to inventory which models inform which decisions and monitor them in production, not only at onboarding.

Operational resilience: DORA and the ECB letter

For EU banks, the Digital Operational Resilience Act treats LLM providers as ICT third parties and requires a register, an exit strategy, and concentration-risk analysis, covered in DORA AI compliance for banks. Layered on top, the ECB's July 2026 letter asks its supervised banks for faster monitoring of AI threats and closer scrutiny of AI providers, with an October 31 filing, detailed in the ECB AI cyber letter analysis. Both turn on the bank being able to show, per interaction, which provider processed what data under which policy.

Fair lending: ECOA and Regulation B

Any AI that touches a credit decision inherits the Equal Credit Opportunity Act and Regulation B. A model that declines an applicant triggers adverse-action notice requirements with specific principal reasons, and a model that produces disparate impact creates fair-lending exposure regardless of intent. The high-risk credit angle is in banking AI credit scoring. The operational requirement is that the bank can reconstruct what the model was given and what it returned for a specific applicant, because that reconstruction is what an adverse-action notice and a fair-lending exam both depend on.

Data protection and the EU AI Act

The customer records inside a prompt bring the Gramm-Leach-Bliley Safeguards Rule in the US and the GDPR in the EU, both of which govern how that data is processed and disclosed to a third-party model. Separately, the EU AI Act classifies creditworthiness assessment as a high-risk use under Annex III, which adds record-keeping and human-oversight obligations. Each regime uses different words for the same operational facts: which identity made the request, what data it carried, which model it reached, and whether a record exists.

The operational thread

The regimes read as five separate compliance programs, and they converge on one layer. SR 11-7 wants ongoing monitoring of models in production. DORA and the ECB want per-interaction evidence of which provider processed what. ECOA wants reconstruction of a specific decision. GLBA and GDPR want control over what data reached a third party. Every one of those requirements lands on the AI request traffic, the HTTP calls between the bank's applications and the model endpoints, and most banks have no control reading that traffic. The compliance map has a single blind spot in the middle, and it is the request layer.

DeepInspect

This is the layer every banking AI regime converges on, and it is where DeepInspect sits. DeepInspect is a stateless proxy on the AI request path between a bank's applications, analysts, and agents and the model endpoints they call. It binds each request to the authenticated identity, classifies what the prompt carries against MNPI, PII, and customer-record categories, and applies a deterministic pass, block, or modify decision before the request reaches a provider.

It commits a per-decision audit record naming the caller, the data classes involved, the model reached, and the policy applied. That single record is what SR 11-7 ongoing monitoring, a DORA or ECB provider-evidence request, an ECOA adverse-action reconstruction, and a GLBA disclosure review each draw from, in their own vocabulary. It runs inline and fails closed, so a request that violates policy is stopped rather than found in a later exam. Book a demo today.