What FINRA's 2026 Oversight Report Means for Your LLM Deployments

The headline you may have missed

Buried in FINRA's 2026 Annual Regulatory Oversight Report — a document most compliance teams scan for the trading and surveillance items they already know about — is a section that has serious implications for any mid-market fintech using large language models in production.

FINRA explicitly called out LLM governance as an examination area. Not as a future concern. Not as a watch item. As an active examination priority for 2026.

This is not the first regulatory signal. The OCC and Federal Reserve have been clarifying since 2023 that SR 11-7, the federal model risk management guidance from 2011, applies to AI and ML systems including LLMs. The 2026 FINRA Report is the latest — and most operational — signal yet.

If your firm uses LLMs in any capacity that touches financial decisions, customer communications, or internal risk workflows, this affects you. Here's what you need to know.

What SR 11-7 actually requires

SR 11-7 ("Supervisory Guidance on Model Risk Management") was written for quantitative models — credit scoring engines, VaR models, algorithmic trading strategies. But its principles apply to any automated decision system, and regulators have confirmed that LLMs are within scope.

The three pillars:

Pillar 1: Model Development, Implementation, and Use. The model does what it's designed to do. This sounds obvious but requires documentation — what the model is intended to do, what inputs it takes, what outputs it produces, and what constraints govern its behavior.

Pillar 2: Model Validation. An independent function evaluates whether the model actually does what Pillar 1 says it does. For quantitative models, this typically means backtesting and sensitivity analysis. For LLMs, this means adversarial testing — probing the model to confirm it behaves within stated constraints under adversarial input.

Pillar 3: Model Risk Governance. Policies, procedures, and a governance framework that covers the entire model lifecycle — from procurement through retirement. Documentation must be auditable. Roles must be assigned. A model inventory must be maintained.

Why LLMs fail standard model risk management

Traditional model risk management was designed for deterministic models. LLMs introduce properties that break most existing MRM processes:

Non-determinism. The same prompt, sent twice, can produce different outputs. SR 11-7 requires that you document model behavior — but how do you document a stochastic system? The answer is probabilistic: you run the model many times across a representative set of inputs and characterize its behavior statistically. LLMSec's probe library does exactly this — each probe is run with consistent inputs, and the pass/fail distribution across a scan constitutes a behavioral characterization.

Adversarial manipulability. A credit scoring model isn't manipulable through natural language. An LLM is. A sophisticated user can jailbreak an LLM, inject instructions through untrusted content the model reads, or extract sensitive information from the model's training data or system prompt. SR 11-7's requirement for "sensitivity analysis and stress testing" maps directly to this: you need to test the model under adversarial conditions, not just happy-path inputs.

Opaque reasoning. LLMs cannot explain their outputs in the way a regression model can. This affects the SR 11-7 requirement for "conceptual soundness" — you can't inspect the coefficients to understand the model's behavior. Instead, you characterize behavior empirically through systematic testing.

Vendor model risk (Section 8). Most fintech firms using LLMs are using third-party models — GPT-4o-mini, Claude Sonnet, Llama 3 fine-tunes. SR 11-7 Section 8 requires that you manage the model risk of third-party models you rely on. "OpenAI does their own red-teaming" is not a valid model validation under SR 11-7. You need independent validation of the model in your specific deployment context, with your specific system prompt and use case.

What examiners are actually looking for

Based on examination guidance and conversations with firms that have been through LLM-related examinations, here's what examiners are asking:

Model inventory. Do you know which LLMs you're using and where? Every LLM in production should be in your model inventory. This includes third-party APIs (OpenAI, Anthropic, AWS Bedrock) and any self-hosted fine-tuned models.

Intended use documentation. For each LLM, can you articulate what it's supposed to do, what inputs it takes, and what the expected output range is? A system prompt and a use-case description are a starting point.

Validation evidence. Have you tested the model to confirm it behaves as intended? What was the methodology? Who conducted the test? Was it independent of the team that deployed the model? Can you produce a report?

Incident response. What happens if an LLM produces a harmful or non-compliant output? Is there a logging and incident response process? Are prompts and responses retained for investigation?

Ongoing monitoring. Model risk management is not a one-time event. Models drift. Attack techniques improve. Have you established a cadence for re-testing?

The independence requirement

SR 11-7 is explicit: model validation must be independent of model development. For LLMs, this means the team that validates the model should not be the team that built the system prompt, selected the model, or configured the deployment.

This is where internal red teams often fall short. If your engineering team both deploys the model and tests it, you don't have independent validation. If your compliance team runs a checklist against the system prompt but never actually probes the model's behavior, you don't have independent validation.

Independent validation for LLMs means:

An independent party runs adversarial tests against the model as deployed
The test methodology is documented and reproducible
The findings are reported to someone with authority to require remediation
The validation can be re-run when the model or system prompt changes

LLMSec is designed to support this workflow. It runs as an independent tool with a documented methodology. The scan produces a signed, reproducible report. The findings map to SR 11-7 controls. And the scan can be re-run on any schedule.

Building the documentation package

For a FINRA examination on LLM governance, you want to be able to produce:

Model inventory entry — which model, which endpoint, deployed where, owned by whom, what it does, when it was last validated.

Use case and system prompt documentation — what the model is instructed to do and not do.

Validation report — adversarial test results, methodology documentation, findings by severity, framework mapping.

Remediation evidence — for any high-severity findings: what was done to address them and when.

Ongoing monitoring plan — how often you re-test and what triggers a re-test outside the scheduled cadence (significant model change, significant system prompt change, new attack technique published).

This package should be auditable without your presence — an examiner should be able to read it and understand your validation process without you explaining it.

The timeline you're working against

FINRA examinations for the 2026 cycle are ongoing now. If your firm is in scope for a FINRA examination this year, you may have weeks, not months, to get your LLM governance documentation in order.

The good news: a basic SR 11-7-compliant LLM validation is achievable quickly. You don't need a six-month MRM program build-out. You need:

A current model inventory
Use case documentation for each LLM
An independent adversarial scan with a signed report
A remediation plan for high-severity findings
A re-test cadence

This is the minimum viable LLM governance package for a FINRA examination. It won't satisfy every possible question, but it demonstrates that you take model risk management seriously and have a functioning process.

Next steps

If you don't have LLM governance documentation today, start with the model inventory. List every LLM your firm uses — including third-party APIs called by internal systems, not just the AI features you built yourself. Shadow IT LLM usage (individual employees using ChatGPT or Claude for work tasks) is a separate governance question; focus first on production systems.

Then, for each production LLM: document the use case, the system prompt, and the expected output envelope. Then scan it. An LLMSec scan against a typical OpenAI or Anthropic API endpoint takes under a minute and produces a report you can attach to the model inventory.

The hardest part of LLM governance is not the technology — it's the organizational alignment. Getting the teams that build AI features to engage with model risk management before deployment, not after, is a governance change that takes time. Start that conversation now, before an examiner does.