FINRA Rule 3120 Control Testing for n8n AI Workflows: Test Scripts and Evidence

What Rule 3120 asks of the firm

Rule 3120(a) requires a member to designate one or more principals who establish, maintain and enforce supervisory control policies and procedures. Those procedures must test and verify that the firm's supervisory procedures are reasonably designed to achieve compliance with securities laws and FINRA rules, and must create or amend supervisory procedures where testing shows a need. The designated principals report to senior management at least annually. The report covers the system of supervisory controls, a summary of test results and significant identified exceptions, and any additional or amended procedures created in response. As of November 2026, the rule is in effect as published, with no amendment reported.

Two distinctions shape the test plan. First, supervisory control policies are separate from written supervisory procedures: the firm maintains the procedures and also tests and verifies them. AI workflow controls need to appear in both. Second, FINRA states that risk-based methodologies and sampling may determine the scope of testing, and that a self-assessment, internal audit or inspection process may satisfy the testing requirement in whole or in part. Existing audit steps can therefore be extended to cover workflows rather than rebuilt.

Firms with $200 million or more in gross revenue on the prior year's FOCUS report have additional report content under Rule 3120(b), to the extent applicable to their business. Check whether that applies before scoping the report.

FINRA describes its rules as technology neutral. They apply to generative AI whether a firm builds the tool or uses a third party's, including embedded features in existing products. FINRA's 2026 oversight report names supervision, communications, recordkeeping and fair dealing as areas GenAI can implicate. It points to robust testing of capabilities, limitations and performance, including privacy, integrity, reliability and accuracy. It also raises how to limit or restrict agent behaviors, actions or decisions.

Decompose the workflow into control points

An n8n workflow is a chain of nodes: a trigger that starts it, nodes that prepare data, an AI agent or model node, tool or HTTP nodes that call other systems, and often a step where a person approves or rejects. Each node that reads data, makes a model call, takes an action or hands off to a person is a candidate control point. Credentials attached to nodes matter too, because they set what a workflow can reach.

Start with an inventory of workflows that touch customer or communications data. Record, for each one, the trigger, the models called, the tools and APIs invoked, the data entering and leaving, and the approval steps. Include vendor-hosted models and tools, since embedded and third-party AI is in scope on the same terms as internally built AI. Then map each control point to a control objective the firm's written supervisory procedures already address, such as review of communications or protection of customer information. If no procedure covers a control point, that gap is itself a design finding and may call for an amended procedure.

For the test plan, confirm early what execution data the firm's n8n deployment actually retains and for how long. Test scripts can only rely on records that exist.

Test scripts by control point

Each script below states an objective, a procedure, an expected result and an evidence artifact. Adapt the wording to your own procedures. Expected results for model calls can draw on the testing areas FINRA names: privacy, integrity, reliability and accuracy.

• 1. Data inputs: Objective: only approved data categories enter the workflow. Procedure: submit test inputs containing permitted and prohibited data through the trigger. Expected result: permitted inputs proceed; prohibited inputs are stopped, masked or escalated per procedure. Evidence: test inputs, execution record, and the documented handling outcome.
• 2. Model calls: Objective: the approved model, configuration and instructions are used, and outputs meet accuracy and privacy criteria. Procedure: run a fixed test set, including edge cases, and compare outputs to written criteria. Expected result: outputs meet criteria; deviations are recorded as exceptions. Evidence: test set, outputs, reviewer scoring, model and configuration identifiers.
• 3. Tool and API calls: Objective: the workflow can only take actions its procedure permits. Procedure: attempt permitted and out-of-scope calls, such as a write action the procedure excludes. Expected result: permitted calls succeed; out-of-scope calls are blocked or require approval. Evidence: call records showing target, parameters and outcome.
• 4. Data outputs: Objective: outputs sent to customers or stored in records meet communications and recordkeeping requirements. Procedure: trace sampled outputs to their destination and retention location. Expected result: each output is attributable, retained and reviewable. Evidence: output copies, destination records, retention configuration.
• 5. Human approval: Objective: designated reviewers approve required actions before they execute. Procedure: trigger an action that requires approval and attempt to proceed without it. Expected result: execution pauses until an authorized reviewer decides. Evidence: approval request, reviewer identity, decision, timestamp.
• 6. Credentials and change: Objective: workflow access and logic change only through an approved process. Procedure: compare credential scope and current workflow version to the approved baseline. Expected result: no unapproved changes or excess permissions. Evidence: baseline, current configuration, change tickets.

Design effectiveness and operating effectiveness

Rule 3120 tests whether supervisory procedures are reasonably designed. Whether a control operates as designed at runtime is a separate question, and firms commonly test both. This is a testing practice rather than a FINRA requirement, and it fits the regulator's own definition of model validation: processes that verify models perform as expected, in line with their design objectives and business uses.

Design testing asks whether the control, as written, would address the objective. It is a walkthrough of the workflow configuration against the procedure, and it can happen before go-live, which is consistent with FINRA's expectation that firms evaluate GenAI tools before deploying them. Operating testing asks whether the control did what it was designed to do across real executions. It needs a sample.

FINRA allows risk-based scoping and sampling. Define the population (executions in the period), stratify by risk, for example workflows touching customer communications or invoking write actions, and record why you chose the sample size and selection method. Sample sizes are the firm's judgment, so the rationale is what makes the sample defensible. Add targeted tests with known inputs, because routine traffic may never exercise a control such as a block or an escalation.

Define in advance how a failed test is classed as a significant exception. A control that failed once in a low-risk workflow is a different finding from one that allowed a prohibited tool call on customer data. The classification feeds the annual report and any procedure amendments.

Where runtime enforcement supports testing

Reviewing records after the fact shows what happened, but it leaves a gap between the documented control and runtime behavior. A control that acts in the execution path, before a model response is returned or a tool call runs, can be tested directly: send the prohibited input, attempt the out-of-scope call, and confirm the result. The control either held or it did not, and the record of that decision is the evidence.

Trussed enforces policy in the execution path across models, agents and tools, with outcomes of allow, redact, block, rate limit or escalate for human approval, applied to individual interactions and tool calls. Each enforcement decision produces audit-ready evidence, so scripts 1, 3 and 5 above can retain the decision record as the artifact. Evidence is generated continuously, which supports operating tests across a sample rather than only on test days. Deployment is self-managed in the customer's cloud, with configurable retention and data residency, which matters when evidence must be kept for the reporting cycle.

The scope is specific. Trussed evidences individual interactions and tool calls, not an entire workflow end to end, so workflow-level questions still rely on the firm's own test scripts and execution data. Trussed's deepest experience is in insurance, another regulated sector that faces examiner scrutiny of model risk management and evidence quality.