Broker-Dealer Supervision of AI Features Embedded in CRM and Wealth Platforms

Why embedded features change the supervision problem

CRM and wealth platform vendors are adding meeting summarization, email and client-communication drafting, next-best-action prompts and advisor copilots to tools that registered representatives already use daily. These features often arrive through vendor release cycles rather than a firm-led procurement, so the usual review gate may never run.

FINRA's position, as of November 2026, is that its rules are technology neutral and apply when member firms use generative AI, whether the firm builds the tool or uses third-party technology, including embedded features in existing third-party products. Rule 3110 requires a supervisory system reasonably designed and tailored to the firm's business. FINRA's 2026 oversight report links generative AI to supervision, communications, recordkeeping and fair dealing.

The practical consequence is that reliance on a vendor does not move the obligation. Compliance needs to see which features are active, what they generate and what evidence exists to show an examiner how outputs were supervised.

An implementation sequence for supervising embedded AI

The obligations are defined by activity, not by technology, so the work is to map each feature to duties you already have. The sequence below keeps that mapping explicit and testable.

Two decisions carry most of the weight. First, compliance should decide which outputs count as correspondence, retail communications, institutional communications or recommendations, because supervision and content standards differ by category. Second, the firm should name an owner for each interaction rule, so a redaction or block decision has an accountable decision-maker.

• 1. Discover: Inventory every AI feature enabled in each CRM and wealth platform, including features introduced in vendor releases. Set up a recurring process to learn about new ones.
• 2. Classify: Record the obligation each feature triggers. Client-facing drafts may be correspondence, retail or institutional communications. Recommendation prompts to retail customers may bring in Regulation Best Interest. Features that touch customer data raise Regulation S-P questions.
• 3. Map to written supervisory procedures: Update the procedures to reflect AI use, including review of correspondence and internal communications, and document the review and approval process with business and technology input.
• 4. Define interaction rules: For each feature, specify which interactions are allowed, which require redaction, which are blocked and which escalate for human approval.
• 5. Specify evidence: Define what is retained, in what format and for how long, before the feature is switched on.
• 6. Test and amend: Include the features in annual supervisory control testing and amend the procedures where testing finds gaps.

Deciding what to redact, block or escalate

Interaction rules work best when each is tied to a stated obligation. Content standards under Rules 2210 and 2220 require communications to be fair and balanced and prohibit false, misleading, promissory or exaggerated statements. A drafting feature that produces performance language or promissory phrasing for a client email is a candidate for escalation to a supervising principal before the message is sent.

Data rules follow from Regulation S-P policies for protecting customer information. If a summarization or drafting feature can receive account numbers or other sensitive fields that the task does not require, redaction before the data reaches the model is a defensible rule. Where an output amounts to a securities transaction or investment strategy recommendation to a retail customer, Regulation Best Interest applies, which usually argues for human approval.

FINRA also identifies thresholds and limits as a consideration where AI-driven tools trigger actions autonomously. For features that can take or trigger actions, such as creating tasks, sending messages or updating records, set explicit limits and an escalation path. Start conservatively. Loosen a rule only after the evidence shows how the feature behaves.

What each mechanism can and cannot establish

Vendor due diligence, periodic review and runtime enforcement answer different questions. The distinction below is an analytical one for designing a supervisory system, not a statement about any regulator's expectations of a specific tool.

• Vendor due diligence and attestations: Establishes the vendor's design, controls and commitments at a point in time. Cannot show feature-level behavior after a later release, or what a feature did in your firm.
• Annual supervisory control testing: Establishes whether the written procedures are reasonably designed and surfaces gaps to amend. Periodic by nature, so it does not cover behavior between test cycles.
• Post-hoc sampling: Establishes the quality of a sampled set of outputs. Does not cover interactions outside the sample, and cannot prevent an output from reaching a client.
• Runtime policy enforcement with retained evidence: Establishes what a feature was permitted to do and what happened in each interaction, because the decision is made and recorded when the interaction occurs.

Where runtime enforcement fits, and its limits

Runtime policy enforcement applies a decision to an individual interaction or tool call in the execution path, before an output or action takes effect. Trussed provides this: it enforces policy at runtime, not after the fact, with allow, redact, block, rate limit and escalate-for-human-approval decisions, and it generates audit-ready evidence from those decisions. Its scope is individual interactions and tool calls. Insurance, a regulated financial sector, is where Trussed is deepest, with customers across insurance, pharma, healthcare and education, 18+ months of continuous production in a regulated enterprise and 99.95% uptime on live production traffic.

There is a real limit. Enforcement can only act where the firm can place it in the path of the AI traffic and tool calls. If a feature runs entirely inside a third-party SaaS platform and offers no point of control, the firm is left with vendor-side configuration, contractual commitments, disabling the feature, and sampling. In that case the supervisory record should state plainly what is enforced, what is attested and what is reviewed afterward.

A sound design layers all three. Due diligence sets the baseline, runtime enforcement controls and records individual interactions, and periodic review tests whether the whole system still works as the written procedures describe.