Translating FINRA AI Expectations into Runtime Control and Evidence Requirements

What FINRA has stated, and what is engineering interpretation

Regulatory Notice 24-09, published June 27, 2024, reminds members of their obligations when using generative AI and large language models. It is a reminder, not a new rule. FINRA's 2026 Annual Regulatory Oversight Report, published December 9, 2025, repeats the position. As of November 2026, the sources reviewed show no withdrawal or amendment of either.

The stated position has a few parts. FINRA rules and the securities laws continue to apply when firms use GenAI. They apply whether a firm builds tools for proprietary use or relies on a third party, including features embedded in existing third-party products. Firms should evaluate GenAI tools before deployment and confirm they can still comply with applicable rules. Which rules apply depends on how the technology is deployed. The reports tie this most directly to Rule 3110 on supervision, Rule 4511 on books and records, and supervision of activities that third-party vendors perform.

FINRA's published material does not say which runtime actions to take, how long to retain AI interactions, or what an evidence record should contain. Everything in the mapping below that goes beyond those statements is engineering interpretation, and it is labeled that way. Treat it as a starting design for discussion with your compliance function, not as a statement of what an examiner requires.

Expectation to platform control and evidence

Each row follows the same structure: the expectation, the platform implication, the runtime enforcement point and the evidence artifact. The first element of each row reflects FINRA's published position. The rest is interpretation.

• Rules apply to third-party and embedded AI: Platform implication: inventory every model, agent and tool path, including vendor features. Enforcement point: route vendor-AI traffic through the platform where technically feasible. Evidence: an inventory of AI paths and an explicit list of paths that cannot be controlled.
• Supervision under Rule 3110: Platform implication: policy definitions can express permitted interactions and tool calls per use case, as a technical counterpart to written procedures. Enforcement point: allow, redact, block, rate limit or escalate at each call. Evidence: versioned policy definitions and the decision made on each call.
• Books and records under Rule 4511: Platform implication: retention and export must be configurable so the firm's own record determinations can be applied. Enforcement point: capture at the same point the decision is made. Evidence: retention settings, export capability and the retained interaction and decision records.
• Vendor-performed activities need supervision: Platform implication: vendor model and tool access is subject to the same per-use-case policy as internal access. Enforcement point: outbound calls to vendor models and tools. Evidence: decisions on vendor-bound calls, plus documented gaps.
• Applicable rules depend on deployment: Platform implication: controls cannot be uniform across business lines. Enforcement point: policy selected by use case, identity and context. Evidence: records that show which use case and policy version governed each decision.
• Human review where policy requires it: Platform implication: some actions should pause until a named reviewer decides. Enforcement point: escalation for human approval before the tool call executes. Evidence: the request, the approver and the outcome.

Why enforcement belongs in the execution path

A review performed after the fact can describe what happened, but it cannot change it. If a supervisory design depends on someone noticing a problem in a later report, the control has failed by the time it operates. Enforcing policy at the point of each model call and tool call lets the decision happen before the action. A request is allowed, has sensitive content redacted, is blocked, is rate limited, or is held for human approval.

This matters most for agents. A model response is one event, but an agent can chain tool calls that reach internal systems, external services and data stores. Per-call enforcement gives the platform a defined decision point for each one, and each decision can be tied to an identity, a use case and a policy version.

The tradeoff is operational. Inline enforcement adds a dependency to every AI interaction, so latency, availability and failure behavior need explicit design. Teams must decide whether a call fails open or fails closed when the policy service is unreachable, and that decision should itself be documented per use case.

What runtime enforcement cannot satisfy

Several expectations sit outside the platform. Rule 3110 requires a supervisory system reasonably designed for the firm's business, with written procedures and accountability. Platform policy can support that system, but it does not create it. Pre-deployment evaluation of GenAI tools is a governance process. Model validation and ongoing model risk management are also governance processes. Federal Reserve guidance such as SR 11-7 describes validation and sound governance, policies and controls as elements of a model risk management framework. Runtime controls do not validate a model.

Record scope is another boundary. Rule 4511 and the related references to SEA Rules 17a-3 and 17a-4 concern making and preserving records, but the published material does not say which AI interactions or tool calls are records. That determination belongs to the firm's compliance function. The platform's job is to make retention configurable and the result demonstrable.

Vendor oversight likewise includes contractual and due diligence work that no enforcement point can perform. Human approval workflows need a named reviewer and a defined escalation process before the platform can route requests to them. FINRA has also noted that general-purpose AI agents may lack the domain knowledge for complex, industry-specific tasks, which is a reason to scope agent permissions narrowly by use case.

What audit-ready evidence looks like

The examiner's question is simple: what was the AI allowed to do, and what did it do? A useful evidence record answers both halves. The first half is the policy in force: which interactions and tool calls were permitted for a given use case, and at which version. The second is the decision record: the action taken, the policy version applied, the identity, the use case and the timestamp. For escalations, the record should include the approver, the request and the outcome.

FINRA does not specify this schema, so it is a design choice. The test is practical. Pick a user, a use case and a date range, and ask whether you can list the policies in force and the decisions made without manual reconstruction. Evidence that must be assembled from application logs, tickets and screenshots after a request arrives is weak evidence, even if every piece exists.

Two further properties matter. Records should be durable and exportable under retention settings that the firm has chosen and documented. And the evidence should state its own limits. If vendor-embedded features do not pass through the platform, document that gap rather than implying full coverage.

Where Trussed fits

Trussed is runtime control and evidence infrastructure for regulated enterprises that must show a regulator or auditor what their AI was allowed to do and what it did. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, using allow, redact, block, rate limit and escalate for human approval. Scope is individual interactions and tool calls. It does not trace agentic workflows end to end. Enforcement generates audit-ready evidence continuously, mapped to frameworks including NIST, and it can be self-managed in the customer cloud with configurable retention and data residency.

Insurance is the regulated financial sector where Trussed is deepest. Trussed has customers in four regulated verticals: insurance, pharma, healthcare and education. Production history includes 18+ months of continuous operation in a regulated enterprise, 99.95% uptime on live production traffic, 100+ models under one policy plane and 30+ GB of audit evidence generated per day. The mapping in this guide is general, and it applies whichever tooling you use.