FINRA Generative AI Oversight Report Requirements: Runtime Controls and Evidence to Build

What the report says, and what it leaves to engineering

The 2026 FINRA Annual Regulatory Oversight Report was published on December 9, 2025. It includes a new topic, GenAI: Continuing and Emerging Trends. FINRA states that its rules are technologically neutral and, together with the securities laws, continue to apply when firms use GenAI, whether they build tools for proprietary use or rely on a third party's technology, including embedded features in existing products. The report is guidance, not a rule, and FINRA advises firms to incorporate its relevant elements into their compliance programs and to update written supervisory procedures.

The report ties GenAI use to existing obligations. These include Rule 3110 on supervision, communications rules such as 2210 and 2220, human-in-the-loop oversight protocols for agents, and documented processes to identify, assess, mitigate and monitor technology risks. FINRA also says firms should consider how they will comply with applicable regulations when evaluating GenAI tools before testing and deployment. Regulatory Notice 24-09 from June 2024 makes the same point: it creates no new requirements and does not relieve firms of existing ones.

None of this names a technical control. The mapping from obligation to enforcement point and evidence artifact is an engineering judgment, and this guide labels it as such. The question for a platform team is what an examiner would reasonably expect to see: what the AI was permitted to do, and what it did, at the moment of each interaction or tool call.

Enforcing policy in the execution path, and what to record

Pre-deployment review shows what a team intended to ship. Log inspection after the fact shows what happened, but not what the system was permitted to do when it happened. An examiner reviewing supervision wants both, tied together per interaction. That points to enforcement in the execution path, with a decision made before the model call or tool call proceeds.

Five actions cover most needs. Allow permits the interaction under a named policy. Redact removes defined data from a prompt, context or response. Block stops the interaction. Rate limit constrains volume for a user, tool or agent. Escalate pauses the action until a human approves or rejects it. Which action applies should vary by use case, so start with the summarization and extraction workflows most firms already run, then extend to agents with tool access.

Each decision should produce a record containing the actor, the model or tool, the policy version, the action, the reason, and any human approval with its outcome. Recording the policy version matters because policies change, and an examiner may ask what rule was in force on a given date. Keep the record separate from application logs so that it can be retrieved by interaction without reconstructing events from several systems.

Retention, recordkeeping and deployment decisions

Retention design should start from the FINRA recordkeeping rules that apply to each use case, and those should be confirmed with compliance counsel rather than assumed from the platform. Communications content and the decisions applied to it may fall under different retention periods than internal summarization traffic. Make retention configurable by policy class, and make it possible to retrieve evidence by user, tool, agent, policy version or time range.

Two deployment questions affect what you can say to an examiner. The first is data residency: where prompts, outputs and evidence are stored, and whether that can be fixed to a region. The second is hosting: whether enforcement and evidence storage run in your own cloud or in a vendor's environment. Self-managed deployment keeps evidence under the firm's existing access controls and retention tooling. It also adds operational responsibility for availability and upgrades. Neither choice is dictated by the report, so document the reasoning behind the one you make.

Volume is a planning input. Evidence generated per interaction and per tool call grows quickly once agents are involved, so size storage and retrieval before enabling broad coverage.

What runtime enforcement does not cover

Enforcement evidence supports supervision. It does not replace it. FINRA advises firms to update written supervisory procedures and tailor compliance programs to their activities, and no technical control can substitute for those documents or for the people who carry them out.

Several expectations sit outside the platform. Evaluating GenAI tools against FINRA rules before testing and deployment is a business and model risk activity, as are model validation and vendor due diligence. The report's call for clear accountability, oversight structures and documented processes to identify, assess, mitigate and monitor technology risks across the enterprise is also organizational. A runtime control can enforce a policy, but someone must decide what the policy should be, who owns it and how exceptions are handled.

For examiners, a short boundary document helps. List each expectation, state whether it is met by execution-path enforcement, by a procedure, or by both, and point to the evidence for each. Where a platform control only partially addresses an expectation, say so. No technical control guarantees compliance, and the document should not imply that one does.

One example of enforcement and evidence in the execution path

Trussed is one example of this approach. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with allow, redact, block, rate limit and escalate-for-human-approval actions applied to individual interactions and tool calls. Enforced at runtime, not reviewed after the fact, each decision produces audit-ready evidence. That evidence is mapped to frameworks including HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Deployment can be self-managed in the customer cloud, with configurable retention and data residency.

Insurance, a regulated financial sector, is where Trussed is deepest. Trussed has run continuously in a regulated enterprise production environment for more than 18 months, with 99.95% uptime on live production traffic, and operates more than 100 models under one policy plane. Customers span four regulated verticals: insurance, pharma, healthcare and education.

Trussed does not provide transaction-level governance, model or dataset provenance, or end-to-end tracing of agentic workflows. It records what was enforced at each interaction and tool call. It is not a substitute for supervisory procedures, model validation or vendor due diligence, and it does not make any firm compliant with FINRA rules on its own.