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 AI evidence may matter in ECB operational-resilience supervision?

In its June 2026 speech, the ECB described AI as an operational-resilience and cyber-risk issue and said it planned targeted supervisory follow-up. For an AI deployment, a bank should be able to monitor relevant traffic, show which provider processed what data, and produce a per-decision record that a supervisor can inspect. Treat the scope and timing of any specific request as dependent on the final supervisory communication.

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

TL;DR

The practical answer is to control and record every AI request before it reaches a model provider.
A bank must bind each interaction to the caller, data classes, model, provider, policy, and decision.
A stateless inline proxy can classify prompts and apply a deterministic pass, block, or modify decision.
Per-decision records let the bank monitor production models, prove provider controls, reconstruct credit decisions, and review data disclosures.

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. In a June 2026 speech, the European Central Bank identified AI as an operational-resilience and cyber-risk concern and said it planned targeted supervisory follow-up. That signal sits alongside the existing regime rather than creating a verified new filing deadline. 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 ECB supervisory signals

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. Alongside DORA, the ECB has identified AI as a cyber- and operational-resilience concern and indicated targeted supervisory follow-up. Banks should be able to monitor AI threats and scrutinize AI providers, while treating any specific information request as a matter to verify against the final supervisory communication. 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.