AI Compliance for Banks: FINRA, SEC & OCC Rules for Deploying AI in 2026

Banks and broker-dealers can deploy AI in 2026 without new AI-specific statutes because existing rules already cover it: FINRA's technology-neutral supervision and recordkeeping obligations, the SEC's examination focus on AI-washing and Regulation S-P data handling, and the banking agencies' model risk management framework — the successor to SR 11-7 — together define what a compliant deployment must log, explain, validate, and keep a human accountable for.

That is the answer most compliance officers are looking for, and it cuts both ways. There is no waiting period for an "AI rule" that permits deployment — but there is also no gap to hide in. Every regulator that touches a bank or broker-dealer has now said, in writing, that its existing rulebook applies to large language models and agents. The institutions moving fastest are not the ones with the biggest models; they are the ones that mapped each regulator's expectations to engineering controls and staffed the team to run them.

What FINRA expects from broker-dealers using AI

FINRA's position is deliberately old-fashioned. Regulatory Notice 24-09, issued June 27, 2024, reminds member firms that securities laws are technology-neutral: using generative AI changes nothing about whether the rules apply — only how the firm is using it determines which rules bite. Three obligations dominate:

Supervision (Rule 3110). If registered representatives use an LLM to draft client emails, summarize research, or answer product questions, the firm's written supervisory procedures must address that use. A chatbot the compliance department has never reviewed is an unsupervised communication channel, and FINRA has treated unsupervised channels harshly — the off-channel communications sweep that produced hundreds of millions in fines is the template.

Communications with the public (Rule 2210). AI-generated content sent to retail investors is still a communication subject to content standards: fair and balanced, not misleading, with required disclosures. Generation by a model does not dilute the firm's responsibility for the output; it concentrates it, because the firm chose to automate.

Books and records (SEA Rules 17a-3/17a-4 and FINRA Rule 4511). This is the sleeper obligation. FINRA's Annual Regulatory Oversight Reports have flagged AI's impact on books and records as an emerging risk: if an AI tool generates, summarizes, or transforms records — or holds conversations that constitute business communications — those artifacts may need to be captured and retained in compliant storage. Prompts and outputs from a customer-facing assistant are records. Most off-the-shelf AI tools were not built to write to WORM-compliant archives, which is exactly the kind of gap an examiner finds first.

A broker-dealer's AI problem is rarely the model. It is the surrounding machinery — supervision procedures that name the tool, communications review that covers generated content, and an archive that captures what the model actually said to whom.

What SEC examiners are looking for in 2026

The SEC's Division of Examinations released its FY2026 priorities in November 2025, and AI appears in two distinct forms.

The first is AI-washing: misleading claims about a firm's AI capabilities or the role AI plays in investment processes. The Division has already brought enforcement actions against advisers whose marketing described AI-driven strategies that did not exist as described. The 2026 posture, as firms like Goodwin and Akin have summarized it, is that examiners are less interested in whether you use AI and more interested in how you supervise it — and whether your Form ADV, marketing, and client disclosures match the deployed system. The defensive control is unglamorous: an AI inventory that ties every public claim to a system that actually does what the claim says.

The second is data handling under Regulation S-P. The SEC's 2024 amendments to Reg S-P — requiring a written incident-response program and customer notification of data breaches, generally within 30 days — reached their compliance dates on December 3, 2025 for larger entities and June 3, 2026 for smaller ones. Both deadlines have now passed. Every AI system that touches customer nonpublic personal information is inside that program's perimeter: the vector store holding account documents, the prompt logs containing customer names, the third-party model provider processing them. If your incident-response program does not enumerate your AI data flows, it is incomplete on its face.

SR 11-7 model risk management applied to LLMs and agents

For banks, the center of gravity is model risk management. SR 11-7 governed this space from 2011 until April 2026, when the OCC, Federal Reserve, and FDIC jointly issued the Revised Guidance on Model Risk Management (OCC Bulletin 2026-13, Fed SR 26-2), superseding SR 11-7 and the 2021 supplement.

Two things about the revision matter enormously for AI teams:

1. Generative and agentic AI are explicitly carved out of formal scope. The agencies called these technologies "novel and rapidly evolving" and announced a forthcoming request for information on how MRM should treat them.
2. The carve-out is not a free pass. The three-pillar architecture carries forward — robust development with conceptual soundness, effective challenge through independent review, and ongoing monitoring against documented thresholds — and examiners expect banks to apply those principles to any AI system that influences credit, fraud, AML, capital, or consumer-facing decisions, proportionate to the bank's size and risk profile.

Applying that framework to LLMs is genuinely harder than applying it to a logistic regression, and pretending otherwise is where programs fail:

• Conceptual soundness cannot rest on inspecting weights. It rests on documented use-case boundaries, prompt and retrieval design, and evidence that the system was tested against the failure modes that matter — hallucinated figures, unsupported advice, biased outcomes across protected classes.
• Effective challenge becomes evaluation engineering. Independent validation of a nondeterministic system requires curated test suites, adversarial probes, and reproducible scoring — evaluation harnesses built and versioned with the same rigor as the system under test.
• Ongoing monitoring must track drift in a system whose vendor may swap the underlying model version without notice. Output-quality metrics, escalation rates, and guardrail-trigger frequencies belong on the same dashboards as traditional model KPIs, which is the core argument for treating AgentOps observability as an MRM deliverable rather than a DevOps nicety.

Banks that shipped models under SR 11-7 for a decade have an advantage here: the governance muscle exists. What they usually lack is engineers who can express MRM requirements as code — evaluation harnesses, logging schemas, versioned prompts — which is precisely the profile Gain America deploys into model risk and AI platform teams.

Audit logging, explainability, and human-in-the-loop checkpoints

Across FINRA, SEC, and the banking agencies, three engineering controls satisfy the largest share of expectations.

Audit logging. Every agentic workflow should emit an immutable, timestamped record of the prompt, retrieved context, model version, tool calls made, outputs produced, and the identity of the human who approved or overrode the result. This single artifact serves 17a-4 recordkeeping, MRM monitoring, and incident reconstruction simultaneously. Log at the decision level, not just the request level — an examiner asking "why did the system flag this transaction?" needs the chain, not the token count.

Explainability. For regulated decisions — credit, suitability, AML dispositions — the system must produce reasons a human can review and a regulator can test. In practice this means constraining LLMs to roles where their output is evidence for a decision (summarization, document extraction, ranked leads) rather than the decision itself, or pairing them with interpretable models that carry the decisioning weight. Adverse-action notices under ECOA/Regulation B still require specific, accurate reasons; "the model said so" has never been acceptable and is not becoming so.

Human-in-the-loop checkpoints. The pattern that survives examination is tiered autonomy: agents act freely on read-only and reversible tasks, require approval for customer-visible or money-moving actions, and are architecturally prevented from irreversible actions without a named human's sign-off. We cover the checkpoint patterns in depth in human-in-the-loop AI agent design — the compliance version of the argument is simple: the approval record is what converts an agent's action into a supervised action under Rule 3110.

An audit trail an examiner can replay, a reason a human can review, and a checkpoint a named person approved — those three artifacts answer more regulatory questions than any policy binder.

GLBA and PCI DSS data boundaries in prompts, RAG stores, and model providers

AI systems create new copies of regulated data in new places, and the data rules follow the data.

GLBA / Reg S-P. Nonpublic personal information in a prompt, an embedding, or a vector store is still NPI. The Safeguards Rule and amended Reg S-P require you to know where it lives, who can reach it, and how you would detect and report its compromise. That drives three architectural requirements: redact or tokenize identifiers before they reach a third-party model API; apply document-level access controls in retrieval so an assistant cannot surface one customer's records to another user's session — the permission-aware design detailed in our enterprise RAG architecture guide; and put model providers through the same third-party risk process as any other data processor, with contractual limits on training-use and retention.

PCI DSS. Cardholder data is the brightest line. If primary account numbers enter prompts or logs, the model provider and the logging pipeline enter PCI DSS scope — an outcome almost no one wants. The standard approach is absolute: PAN never reaches the model. Tokenize upstream, mask in retrieval, and run automated scanners over prompt logs to catch leakage, treating any hit as an incident.

These boundaries are also where security and compliance converge: prompt injection against a RAG assistant with over-broad data access is simultaneously a security incident and a Reg S-P event. The threat model belongs in the design review, as we argue in agentic AI security.

A reference compliant architecture — and the team that runs it

Put together, a defensible bank AI deployment in 2026 looks like this:

The architecture is the easy half. The operating model is where programs live or die, and it takes three roles in permanent contact: model risk management owns validation standards, effective challenge, and monitoring thresholds; engineering owns guardrails, logging, redaction, and the evaluation pipeline; compliance owns WSP updates, records retention, communications review, and disclosure accuracy. When these functions interact only at quarterly sign-off meetings, AI projects stall in review for months — a leading reason AI agents fail to reach production in regulated institutions.

The fix most banks land on is embedding builders inside the governance loop. Gain America staffs forward-deployed AI engineers who have shipped systems under SR 11-7-style governance and who sit with MRM and compliance teams — translating validation requirements into test harnesses, logging schemas into code, and checkpoint policies into working approval flows, instead of handing over a findings PDF and leaving. It is the same delivery model behind our broader financial services AI consulting practice: the regulatory map above only becomes a deployed system when someone on the team has built inside it before.

The rulebook for bank AI in 2026 is demanding but knowable. FINRA has told you the old rules apply. The SEC has told you where it will look. The banking agencies have told you the MRM principles endure even as the guidance evolves. What remains is execution — and execution is a staffing question.