FINRA AI Requirement-to-Control Matrix Template for Broker-Dealers

Why broker-dealers need a matrix, not another policy list

FINRA states that its rules are technology neutral and continue to apply when member firms use generative AI, just as they apply to any other tool. Regulatory Notice 24-09 says this holds whether a firm builds AI tools for proprietary use or uses a third party's technology, including embedded features in existing third-party products. The notice creates no new requirements. It does say that the rules that apply depend on how the firm deploys the technology.

That framing puts the burden on the firm to show the mapping. The 2026 Annual Regulatory Oversight Report ties generative AI to supervision, communications, recordkeeping and fair dealing. Many firms hold these obligations in separate spreadsheets and policy documents, with no link to a control that acts when the AI runs and no link to evidence that the control operated. A matrix closes that gap by making each requirement traceable to a control, an owner and an artifact. The matrix is a working document; confirm current FINRA publications as of November 2026 before you finalize it.

Column definitions

Keep policy statements, enforcement points and evidence in separate columns. Combining them hides the difference between what a firm says it does and what its systems do.

Start with the requirement column: the rule or guidance citation and the obligation in plain language. Add the AI use case, such as customer communications, supervision, research or operations, because the applicable rules depend on deployment. Then record the control objective, which states what must be true, and the control type, which is either procedural or runtime-enforced.

The enforcement point names where the control acts. For a procedural control, this is a review step or a committee. For a runtime control, it is a position in the AI execution path, such as before a prompt reaches a model or before a tool call executes. The control owner should be a named role, and cross-functional ownership fits FINRA's description of review and approval processes that involve both business and technology experts.

Finish with the test procedure, the review frequency and the evidence artifact. The test procedure states how someone confirms the control works. The evidence artifact is the record an examiner can be given without reconstruction.

Worked example rows

The rows below seed a matrix. They draw on obligations FINRA has linked to AI use. The control type and enforcement point are illustrative and depend on your architecture and your own assessment.

• Supervision of AI-assisted customer communications (Rule 3110): Objective: communications comply with federal securities laws and FINRA rules before release. Type: runtime-enforced where the workflow permits. Enforcement point: escalate for human approval before output is released. Owner: supervisory principal. Evidence: approval record per interaction.
• Recordkeeping of AI interactions: Objective: interaction records are retained under the firm's retention schedule. Type: runtime-enforced capture, procedural retention review. Enforcement point: the AI execution path. Owner: compliance operations. Evidence: retained interaction records and retention configuration.
• Pre-deployment evaluation (Notice 24-09): Objective: the firm can continue to comply with existing rules before a tool goes live. Type: procedural. Enforcement point: formal review and approval. Owner: cross-functional review group. Evidence: dated approval record and assessment.
• Third-party and embedded AI oversight (Notice 21-29): Objective: vendor-supplied and embedded AI features stay within supervisory obligations. Type: procedural vendor review, plus runtime allow or block on approved tools. Owner: vendor risk and compliance. Evidence: due diligence file and enforcement records.
• Customer information safeguards (Reg S-P Rule 30): Objective: customer information is protected by administrative, technical and physical safeguards. Type: runtime-enforced. Enforcement point: redact before data leaves the firm boundary. Owner: information security. Evidence: redaction events by interaction.
• Limits on agent behavior (2026 report): Objective: agents act only within approved tools and scope. Type: runtime-enforced. Enforcement point: block unapproved tool calls, rate limit, escalate exceptions. Owner: technology and compliance. Evidence: decision records for each tool call.

Separating procedural controls from runtime enforcement

A procedural control relies on people reviewing activity after the fact: sampling outputs, reviewing vendor files, approving a tool before launch. These controls are necessary. Pre-deployment evaluation and vendor due diligence cannot be enforced by software in the execution path. Their weakness is timing. A sampled review finds a problem after the output has reached a customer or the data has left the firm.

A runtime control acts while the AI executes. The available actions are allow, redact, block, rate limit and escalate for human approval. Whether a given requirement can use one depends on where the firm can place an enforcement point, and the FINRA material does not prescribe runtime technical controls. Classify each row from your own architecture review, and record the reason when a row stays procedural.

The distinction matters for evidence. A policy document shows intent. A record produced by enforcement shows that a specific rule was applied to a specific interaction or tool call. For examiner requests and model risk management reviews, the second kind is easier to test because it exists independently of anyone's recollection. Access, entitlement and authentication controls and encryption of sensitive data, which FINRA's 2020 AI report discusses, are good candidates for this kind of evidence. That report also cites Rules 3110 and 3120 for supervisory control systems.

The tradeoff is scope. Runtime enforcement covers what passes through the path. AI features outside it, including some embedded vendor features, still need procedural coverage.

Where Trussed fits

The matrix works without any particular product. For rows classified as runtime-enforceable, Trussed is one way to enforce policy in the execution path across models, agents, tools and MCP servers, using the actions allow, redact, block, rate limit and escalate for human approval. Scope is individual interactions and tool calls. Enforcement produces audit-ready evidence that can fill the evidence artifact column, mapped to frameworks including NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

Trussed has run in continuous production in a regulated enterprise for more than 18 months and holds SOC 2 Type II and ISO 27001 certifications. Its depth is in insurance, a regulated financial sector, and it works with customers in insurance, pharma, healthcare and education. Compliance leaders should validate any control against their own FINRA obligations and architecture.