How to Run FINRA Rule 3110 Supervisory Review on n8n AI Agent Outputs

What Rule 3110 asks of a supervisory system

Rule 3110(a) requires each member to establish and maintain a system to supervise the activities of each associated person that is reasonably designed to achieve compliance with applicable securities laws and regulations and FINRA rules. Final responsibility for proper supervision rests with the member. The minimum elements include written procedures, designation of appropriately registered principals with supervisory authority for each type of business, and reasonable efforts to determine that supervisory personnel are qualified by experience or training.

Rule 3110(b) adds two review requirements that matter for agent output. The procedures must include review by a registered principal, evidenced in writing, of transactions relating to the investment banking or securities business. They must also include review of incoming and outgoing written, including electronic, correspondence and internal communications relating to the securities business, evidenced in writing electronically or on paper. FINRA also says written supervisory procedures should identify who is responsible for each review, the supervisory activities they perform, and the frequency of review.

FINRA Regulatory Notice 24-09 states that FINRA rules apply to AI, including GenAI, whether built in-house or obtained from a third party. FINRA's 2026 oversight report continues that theme and names AI agents acting autonomously without human validation and approval as an emerging risk. As of November 2026, the Rule 3110 text itself does not distinguish agent workflows from any other technology. The design work falls to the firm.

Classify reviewable units by supervisory risk

An n8n workflow that chains model calls, tool calls and external actions is not one thing to supervise. FINRA describes an AI agent as able to plan, decide and act toward goals without predefined rules, which is a reason to treat each step as its own unit. The first decision is whether a unit is a communication, a transaction-related action, or neither, because Rule 3110(b) attaches written principal review to the first two. The review approach below is a design judgment for your procedures, not a rule requirement.

• Customer-facing drafts and messages: Treat as correspondence. Route to a registered principal before release, with the approval evidenced in writing.
• Internal communications about the business: Also within Rule 3110(b) review scope. Define the reviewer and review frequency in the procedures.
• Recommendations or classifications that inform a customer outcome: Review before use. The agent output should not reach a customer without a human decision.
• Account-related and order-related tool calls: Transaction-related. Require principal approval, or block outright until the procedures cover them.
• Data retrieval for the agent's own use: Lower supervisory risk, but check what data enters the prompt. Redact or block sensitive fields.
• Internal summaries or tagging with no outbound effect: Neither category. Document the classification and the reason so the decision can be reviewed later.

Structuring human approval and escalation

Human approval works only if the reviewer is the person the procedures name and is qualified for the business in question. Map each workflow to a designated registered principal, record the reasonable efforts made to confirm that person's qualification by experience or training, and state the review frequency. FINRA's 2026 report also cites formal review and approval processes that involve both business and technology experts, so adoption of a workflow should have a sign-off from both sides before deployment.

Define what the reviewer sees. An approval screen that shows only the final text hides the context needed to judge it. The reviewer should see the output, the inputs that produced it, the tool calls requested, and the model version in use. Give the reviewer three outcomes: approve, edit and approve, or reject. Escalate to a second principal or to compliance when the output touches a restricted category, when an agent action exceeds a defined limit, or when the reviewer is uncertain.

For actions that would otherwise run without a human, set explicit limits. FINRA's discussion of autonomous ML actions cites amount or threshold limits on trade orders as an example. The same idea applies to agent tool calls: anything above the limit blocks or escalates, and anything the procedures do not cover does not run.

Evidence a supervisory review should produce

An examiner will ask what was reviewed, by whom, when, and what happened as a result. FINRA's 2026 report lists example practices that translate directly into evidence: prompt and output logs, tracking which model version was used and when, and records of human-in-the-loop validation, including regular checks for errors or bias. For each reviewed item, retain the input, the model output, the model version, the tool calls requested, the reviewer's identity, the decision, any edits made, and the time of each step. Keep blocked and rejected items as well as approved ones, since they show the system working.

Test whatever your workflow tool records by default against that list. Execution records built for debugging are not automatically a supervisory record. Check whether they identify the reviewer, capture the edit between draft and final, and persist for as long as your firm's recordkeeping obligations require. If they do not, add a deliberate evidence step to the workflow or capture it outside the workflow tool.

If AI is used to perform part of the supervisory review itself, Regulatory Notice 24-09 says procedures should address technology governance, including model risk management, data privacy and integrity, and reliability and accuracy. Evaluate third-party and embedded AI components before deployment, and record who signed off. The firm keeps final responsibility whichever tool does the work.

Where runtime policy enforcement supports review

Sampling workflow logs after the fact tells you what an agent did. It does not stop an out-of-policy output from reaching a customer. Policy enforced at runtime, in the execution path, applies a decision to each interaction and tool call before it completes: allow, redact, block, or escalate for human approval. That gives the principal's review a defined trigger and gives the firm a consistent escalation path.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with scope at the level of individual interactions and tool calls. Each enforcement decision generates audit-ready evidence, so allowed, redacted, blocked and escalated actions leave a durable record. Trussed does not trace agentic workflows end to end or govern at the transaction level, so the written supervisory procedures, reviewer designation and classification of outputs remain the firm's own work.

Trussed is deployed self-managed in the customer's cloud, with configurable retention and data residency. It has run continuously in production in a regulated enterprise for more than 18 months, with insurance as the regulated sector where it is deepest. Its evidence is mapped to frameworks including NAIC, NYDFS, NIST and the EU AI Act. For a broker-dealer, the relevant question is how enforcement decisions and human approvals would be read under examiner scrutiny and your model risk management program.