Evidence needed for an n8n AI agent workflow for a FINRA exam

What FINRA's rules mean for an AI agent workflow

FINRA Regulatory Notice 24-09 states that FINRA rules are technology neutral and apply when member firms use generative AI, just as they apply to any other technology or tool. The notice cites Rule 3110, which requires a reasonably designed supervisory system tailored to the firm's business, and Rule 2210 on communications with the public. It also says the rules apply whether a firm builds the tool itself or uses third-party technology, including embedded features. An n8n workflow that calls external models and tools sits inside that scope.

Regulatory Notice 25-07 adds the recordkeeping link. It states that FINRA rules require members to supervise internal and external communications relating to their investment banking and securities business and to retain records of them for the period specified in Exchange Act Rule 17a-4(b)(4). Whether a given agent output counts as a communication is a question for the firm's own books-and-records analysis, and that analysis should be written down.

Examinations can involve targeted data requests and advance notices, so the practical test is speed and completeness: can the firm produce the workflow definition, the policies and the records without reconstructing them? As of November 2026, Regulatory Notice 26-14 proposes modernizing Rule 2210. It is a request for comment, has no effective date, and changes no current obligation.

The six categories below are a working list derived from supervision and recordkeeping duties. They are not a FINRA checklist.

Where native execution data helps and where gaps remain

Execution history and node-level logs establish that steps ran, in what order and with what status. That is useful supervisory material, but it answers a different question from the one an examiner asks about control. The examiner wants to know what the workflow was permitted to do and whether the permitted boundary held on each call. The assessment below is a starting point. Each line should be tested against your own n8n configuration, not assumed.

• Workflow and policy definitions: Partial. The workflow design is a starting point. The policy rules governing model and tool calls need their own versioned record.
• Per-interaction and per-tool-call records: Partial. Shows that a step ran. Does not show which policy applied or what decision was made.
• Data handling actions: Gap. Execution data does not establish whether sensitive data was redacted or blocked.
• Human approval records: Gap unless approval is enforced and recorded with approver identity and time.
• Access and change history: Verify. Confirm whether each tool call is attributable to a unique agent identity and whether changes are recorded.
• Retention: Verify. Compare configured retention and residency against the periods your 17a-4(b)(4) analysis requires.

How runtime policy enforcement produces examiner-ready evidence

Runtime policy enforcement places a decision point in the execution path of each model call and tool call. Before the call proceeds, policy is evaluated and one outcome is applied: allow, redact, block, rate limit or escalate for human approval. Because the decision is made and recorded at that moment, the evidence is a direct product of enforcement. It is not reconstructed afterward from step logs. The record can carry the timestamp, the acting identity, the policy version, the decision and, for escalations, the approval outcome.

This is the model-risk-management logic applied to agents: a control is only demonstrable if the firm can show it operated on the specific interaction in question. A policy document alone shows intent. A per-call decision record shows operation.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, and generates audit-ready evidence from that enforcement. It is self-managed in the customer's cloud, with configurable retention and data residency. Its scope is individual interactions and tool calls. It does not provide end-to-end tracing of agentic workflows or transaction-level governance, so firms should not treat it as a substitute for workflow-level supervisory design.

Trussed's deepest experience is in insurance, a regulated financial sector. Its approved operating record includes more than 18 months of continuous production in a regulated enterprise and 99.95% uptime on live production traffic.

Assessing your own n8n deployment

Start with one workflow that touches a consequential action and test it as an examiner would. Pick a past interaction and try to produce, within a short time, the workflow definition, the policy version in force, the decision on each model and tool call, any redaction or block, and any approval. Every item you cannot produce is a gap, whichever tool ends up closing it.

Keep the supervisory procedures tailored to the business and cover both in-house workflows and third-party models and tools the workflow calls. FINRA's scope extends to both. Where the firm requires human approval for agent actions, document its own risk-based rationale, since the approval design is a firm decision.

• Inventory every model call and tool call in the workflow, including external services.
• Record the firm's analysis of whether agent outputs are communications subject to supervision and retention.
• Assign each agent a unique identity and credentials, and keep access and change records.
• Define which actions require human approval and why, then record approver identity and time.
• Run a sample-request test and list what could not be produced.
• Set retention against the 17a-4(b)(4) period your analysis requires, with residency requirements.