Enforcing FINRA Rule 2111 suitability checks before an AI agent recommends a product

Why suitability is an execution-path problem, not a prompt problem

Rule 2111(a) requires a member or associated person to have a reasonable basis to believe a recommended transaction or investment strategy involving a security is suitable for the customer. That belief must rest on information obtained through reasonable diligence to ascertain the customer's investment profile. FINRA identifies three main obligations: reasonable-basis, customer-specific and quantitative suitability.

FINRA's 2026 oversight material states that its rules are technologically neutral and continue to apply to GenAI, and that GenAI use can implicate supervision, communications, recordkeeping and fair dealing. It also lists AI agents acting autonomously without human validation and approval as an emerging trend. A prompt that tells a model to consider suitability is an instruction, not a control. Review after the fact finds an unsuitable recommendation once the customer has already seen it, and leaves a gap in the record about what was checked beforehand.

FINRA's 2018 retail suitability findings describe firms with sound supervision as using tailored controls, including restrictions on recommending certain products to certain investors and systems-based hard blocks. Runtime enforcement applies that same control type to an AI agent.

Scope comes first. A recommendation, determined by facts and circumstances, is the event that triggers Rule 2111, and the rule does not apply to recommendations subject to Regulation Best Interest. Your compliance function must decide which agent outputs are recommendations and which regime governs them. That classification needs a documented method, because everything downstream depends on it. As of November 2026, the rule text has no reported amendment.

Step 1: Break Rule 2111 into checkable conditions

Convert the rule into conditions a policy engine can evaluate. The firm's own methodology defines what each condition means. The list below is a design starting point, not a regulatory template.

• Profile factors obtained: The investment profile includes age, other investments, financial situation and needs, tax status, objectives, experience, time horizon, liquidity needs, risk tolerance and other disclosed information. Check that the factors your procedures require are present and current enough to rely on.
• Reasonable-basis diligence on file: A diligence record exists for the product, showing the firm has worked to understand its risks and rewards.
• Suitable for at least some investors: The firm has determined, based on that understanding, that the product is suitable for at least some investors. A broker can violate either prong of reasonable-basis suitability.
• Fit with this customer's profile: The product matches this customer's investment profile under the firm's methodology.
• Cost consideration: Fees, sales charges or commissions were considered. FINRA's exam findings note failures to consider cumulative costs.
• Institutional-account route: Under Rule 2111(b), the customer-specific obligation is met if the firm reasonably believes the customer can evaluate risks independently and the customer affirmatively indicates independent judgment. Where decisions are delegated, the factors apply to the delegate.

Step 2: Place decision points in the AI execution path

An agent that recommends a product typically makes at least three consequential moves, and each is a place to enforce policy. Keeping enforcement separate from the model and the agent means the same policy applies regardless of which model or agent produces the output.

The first is the tool call that retrieves customer profile data. Because the firm must obtain and analyze enough customer information to have a reasonable basis, a missing or insufficient profile is a candidate trigger to block the flow or escalate. This is also where you decide which profile fields the agent may see or carry forward, and which should be redacted.

The second is the tool call that retrieves product data. Diligence on the product must exist before a recommendation. FINRA cautions that if an associated person remains uncertain about a product's risks and rewards, or believes the firm's analysis was incomplete or inaccurate, further inquiry is needed before recommending. A product with no diligence record, or one flagged as uncertain, should not pass silently.

The third is the outbound message. Here the policy evaluates the drafted output against the profile and product data already retrieved, classifies whether it is a recommendation, and decides whether it can reach the customer. Evaluating at all three points means a failure is caught at the step where it occurs, and each step produces its own record.

Step 3: Define allow, redact, block and escalate outcomes

These outcomes are the firm's policy design. No rule prescribes them, so each should be tied to a Rule 2111 condition and to the written procedure it implements. Thresholds are firm-defined.

• Allow: All mandatory conditions are met: profile complete, diligence on file, fit confirmed, costs considered. The recommendation is released and the decision is recorded.
• Redact: The recommendation may proceed, but specified data must not reach the customer-facing output or be used by the agent. Which fields to redact is a firm decision.
• Block: A mandatory condition fails, such as an incomplete profile, no product diligence record, or a product restricted for this customer type. The recommendation is not released.
• Escalate: Diligence is uncertain or the case falls outside defined rules. The agent output is held for human approval before release.

Step 4: Design human approval and the evidence record

Escalation is only as good as its documentation. Define who may approve, what the approver sees (the draft, the profile inputs, the product diligence status and the failed condition), and what is recorded. FINRA's oversight questions on agents ask where to place human-in-the-loop oversight and how to track agent actions and decisions, so these design choices are likely to be examined.

For each decision, capture the inputs evaluated, the policy version, the outcome, the approver identity where applicable, and a timestamp. Add the tool call or message the decision applied to and the condition that triggered a block or escalation. These fields are a proposal, not a prescribed list. They are meant to support the firm's general obligation to evidence compliance and the books-and-records framework FINRA cites for GenAI use: SEA Rules 17a-3 and 17a-4, which set minimum record, retention and format requirements, and FINRA Rules 4511(a) and 3110(b)(1). Your records and compliance teams decide how retention and format apply.

Version policies and trace each to the written supervisory procedure it implements. Then an examiner's question about what the AI was permitted to do on a given date can be answered from the policy version in force, and the question of what it did from the decision record.

Limits of runtime enforcement and where Trussed fits

Runtime enforcement applies decisions; it does not make them. The firm's suitability determination methodology defines what fit means, what counts as sufficient diligence and how costs are weighed. Rule 3110 requires a supervisory system reasonably designed and tailored to the firm's business, with written procedures under 3110(b)(1). Model risk management still governs how the underlying models are validated and monitored. This guide does not define a test for quantitative suitability; that belongs to the firm's methodology. Revisit controls as FINRA continues to engage with firms on GenAI.

Trussed provides runtime policy enforcement in the execution path across models, agents, tools and MCP servers. It can allow, redact, block, rate limit or escalate for human approval, at the level of individual interactions and tool calls, and enforcement itself generates audit-ready evidence. The platform has run continuously in production in a regulated enterprise for more than 18 months, and its deepest experience is in insurance. Trussed does not claim transaction-level governance or end-to-end tracing of agentic workflows, and the suitability conditions and thresholds described here remain the firm's to define.