Is a Prompt or Model Change a Supervisory Procedure Change at a Broker-Dealer?
It depends on the effect of the change, not the artifact that changed. Under FINRA Rule 3110, written supervisory procedures (WSPs) must be promptly amended as changes occur in the supervisory system. A prompt, system-instruction or model edit that alters supervised activity, controls, reviewers or escalation paths is a supervisory change. An edit that leaves those unchanged is generally a technical change that is still recorded and approved. As of November 2026, FINRA has not published a classification standard for prompt or model changes, so firms need a documented, defensible tiering of their own.
Evidence records that support an examiner or internal audit review
- Change record: what changed, its tier, the rationale, the approver and the date.
- WSP version in force on a given date, with the amendment and its communication to affected persons.
- Policy version in force: permitted tools, data exposure, output scope and escalation rules.
- Per-interaction record: the action requested, the policy decision (allowed, redacted, blocked or escalated) and the policy version applied.
- Human approval records for escalated actions, showing the reviewer, the decision and the time.
- Monitoring results comparing observed behavior with expected behavior after each change.
What Rule 3110 and Notice 24-09 establish
Rule 3110 requires a supervisory system reasonably designed to achieve compliance, and written procedures that are established, maintained and enforced. That includes principal review of transactions evidenced in writing and review of incoming and outgoing electronic correspondence. The rule also requires members to promptly amend WSPs to reflect changes in applicable laws and rules and "as changes occur in its supervisory system," and to communicate amendments to the associated persons they concern.
FINRA's WSP checklist describes WSPs as a living document, to be updated when the supervisory process changes and not only when rules change. It also treats how well a firm updates procedures to reflect operating experience as a factor in future compliance. Acceptance of a firm's WSPs is not a safe harbor against supervisory deficiencies.
Regulatory Notice 24-09 states that FINRA rules are technology neutral and apply when firms use generative AI as they apply to any other tool. If a firm uses generative AI within its supervisory system, such as to review electronic correspondence, its procedures should address technology governance, including model risk management, data privacy and integrity, and the reliability and accuracy of the model. None of this text classifies prompt or model changes. Examiners are likely to assess them under existing supervision obligations, which makes the classification a firm-level judgment that must be documented.
A tiered framework for classifying changes
The Rule 3110 trigger is a change in the supervisory system, which suggests a simple test: does the change alter supervised activity, controls, reviewers or escalation paths? The tiers below are an analytical framework, not a FINRA standard. Classify by effect on supervised activity, not by artifact. A model version swap can sit in Tier 2 or Tier 3 depending on what it changes in practice.
- Tier 1: No effect on supervised activity: Formatting, typo or wording edits that do not change permitted behavior. Record the change and the approver. No WSP amendment.
- Tier 2: Behavior change within approved scope: Revised instructions or a model version update for the same use case, tools and data. Test against expected behavior, obtain owner and compliance approval, and document why no WSP amendment is needed.
- Tier 3: Change to supervised activity or controls: New tool access, new data exposure, wider customer-facing output, removed or altered human approval, or extension to a new use. Route to WSP review and amendment, principal approval and communication to affected persons.
- Tier 4: Change to AI inside the supervisory system: Any prompt or model change to a tool used for correspondence review or similar supervision. Apply technology governance covering model risk, data integrity, and reliability and accuracy before release.
Borrowing from model risk management, with care
Model risk guidance supplies useful concepts, but it is written for banks. As of November 2026, the agencies' SR 26-2 revised model risk management guidance supersedes and replaces the earlier letter, widely cited as SR 11-7. SR 26-2 emphasizes a risk-based approach tailored to a banking organization's model risk profile, size and complexity. Applying either document to a broker-dealer is by analogy.
Three concepts carry over well. First, material changes to model structure or technique warrant validation of appropriate range and rigor before implementation, with effective challenge from objective, informed parties. Second, extending a tool beyond its original scope should be verified as valid, which maps to Tier 3 use expansion. Third, ongoing monitoring should test whether a model performs as expected as products, activities, clients and data change.
FINRA's Notice 15-09 on trading algorithms adds a practical parallel: change management that tracks material changes, with approval protocols scaled to the scope of the change, and monitoring that the procedures are actually followed. The tradeoff is depth. Over-classifying every wording edit as supervisory slows delivery and dilutes review, while under-classifying leaves unreviewed behavior changes. Document the rationale for where each change type lands.
Policy defines what is permitted; runtime enforces and evidences it
A change process on paper does not show what the system did. Separate two layers. The policy layer defines what is permitted for each AI use case: which tools it may call, which data it may touch, which outputs may reach customers, and which actions require human approval. Changes to that layer are the supervisory changes, and they belong in WSP review.
The enforcement layer applies the approved policy at execution. Where a prompt or model change would otherwise alter behavior silently, enforcement at the level of individual interactions and tool calls keeps the system inside the approved boundary regardless of what the prompt says. A prompt edit then cannot grant a tool permission the policy withholds, and a human approval step cannot be dropped by a rewritten instruction.
This separation also helps classification. If tool access, data exposure and escalation are controlled by versioned policy rather than embedded in prompt text, most prompt edits stay in Tier 1 or Tier 2, and the changes that matter become explicit policy changes with an approval trail.
Where Trussed fits
Trussed addresses the enforcement and evidence layers, not the policy-authoring layer. It enforces policy in the execution path across models, agents, tools and MCP servers: allow, redact, block, rate limit, or escalate for human approval, at the level of individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact. That enforcement produces continuous, audit-ready evidence of what the AI was allowed to do and what it did. Evidence is mapped to frameworks including NAIC, NYDFS and NIST, and can be deployed self-managed in the customer cloud with configurable retention and data residency.
Trussed does not author or manage WSPs and does not provide model lineage. Insurance is where Trussed is deepest among regulated financial sectors, with customers across insurance, pharma, healthcare and education. This page makes no claim of broker-dealer deployments. The approach is described here because examiner scrutiny of change control depends on the same thing in any regulated enterprise: showing which behavior was permitted and what actually happened.
From change to examiner evidence
Classify
Decide whether the change alters supervised activity, controls, reviewers or escalation.
Approve
Route supervisory changes to WSP review and amendment; scale testing to scope.
Enforce
Apply the approved policy to each interaction and tool call at runtime.
Evidence
Retain records showing what was permitted on a given date and what the system did.
Show what your AI was allowed to do, and what it did
Talk through how runtime policy enforcement and audit-ready evidence can support your change-control and examiner-readiness process.
Talk to an Expert