Regulatory comparison

    SR 26-2 vs SEC and FINRA AI expectations: what bank-affiliated broker-dealers must track

    SR 26-2 is revised Federal Reserve model risk management guidance, dated April 17, 2026, built around a risk-based lifecycle of development, effective challenge, governance, ongoing monitoring and internal audit. FINRA applies its technology-neutral rules, including Rule 3110 supervision, to GenAI, including third-party and embedded features. A bank-affiliated broker-dealer should keep one AI inventory, one accountable owner per use, and records created at the time of use that answer both regimes: what the AI was permitted to do, and what it did.

    What a bank-affiliated broker-dealer should track

    • An AI use-case inventory with owner, business line, model risk tier, and whether the use touches FINRA-regulated activity such as communications, AML or KYC, including third-party tools with embedded AI features
    • A written rationale for risk tiering and supervisory design that holds up under both SR 26-2 and Rule 3110
    • AI-specific supervisory procedures and the evidence that they are tested, not only an enterprise model policy
    • Classification of each AI-generated communication use as correspondence, institutional or retail, with the applicable pre-use or post-use review
    • Ongoing monitoring outputs and issue-response records that show what the AI was permitted to do and what it did, generated at the time of use
    • Status tracking for the Rule 2210 modernization proposal in Regulatory Notice 26-14

    What each regime is actually asking for

    SR 26-2 transmits revised model risk management guidance. It updates the approach in SR 11-7 based on supervisory experience and industry feedback, clarifies model risk management principles, and emphasizes a risk-based approach tailored to a banking organization's model risk profile and the size and complexity of its operations. Practices are expected to vary by organization, and each organization is ultimately responsible for adopting practices that are appropriate and effective for the risks it faces.

    FINRA takes a different starting point. It does not create a separate AI regime. Its technology-neutral rules and the securities laws apply when member firms use GenAI, whether the firm builds the tool or uses third-party technology, including embedded features in existing third-party products. Its 2026 oversight report tells firms to consider how they will comply with applicable rules, including FINRA rules, when evaluating GenAI tools before testing and deployment, and it points to Rule 3110, which requires a supervisory system reasonably designed and tailored to the firm's business.

    The practical difference is the unit of analysis. SR 26-2 organizes oversight around the model and its lifecycle. FINRA organizes it around the regulated activity and the firm's supervisory system. A single AI use can sit in both frames at once.

    Side-by-side by obligation

    The table is organized by obligation rather than by regulator, because an examiner on either side will ask about the same underlying control. Rule 2210 modernization is a proposal only as of November 2026.

    • Scope and definitions: SR 26-2: risk-based and tailored to each organization's model risk profile, size and complexity. FINRA and securities laws: technology-neutral rules apply to GenAI, whether built in-house or third-party, including embedded features.
    • Governance and accountability: SR 26-2: each banking organization is responsible for practices that are appropriate and effective for its risks. FINRA: members are responsible for their communications whether generated by a human or AI, and for third-party AI they use.
    • Supervision: SR 26-2: governance with clear policies and controls. FINRA: a supervisory system reasonably designed and tailored to the business (Rule 3110), with supervisory control systems (Rule 3120).
    • Validation and ongoing monitoring: SR 26-2: effective challenge by objective experts across the lifecycle; monitoring that may assess limitations at development and over time, with procedures for issues before and after approval. FINRA: model risk management and data governance listed as adoption factors.
    • Third-party and vendor risk: SR 26-2: practices scale with the organization's risks and model usage. FINRA: obligations are not reduced when the AI is supplied by a vendor or embedded in an existing product.
    • Recordkeeping and evidence: SR 26-2: internal audit evaluates whether practices are rigorous, effective and implemented in line with policy. FINRA: communications must be classified (correspondence, institutional, retail) to apply the right review standard; AI uses touching KYC or AML map to Rules 2090 and 3310.

    Where the expectations converge and where they diverge

    They converge on accountability and on risk-proportionate control. Neither regime lets a firm treat AI as exempt because it is new, and neither accepts a vendor as the accountable party. Both expect a documented rationale for the controls chosen. Because SR 26-2 is risk-based and varies by firm, a bank-affiliated broker-dealer should record why its risk tiering and supervisory choices are appropriate under both regimes, not only the one that produced the policy.

    They diverge in scope and in what gets tested. FINRA's reach to embedded AI features in third-party products is broader than internally built models. An inventory built only for model risk management may therefore miss tools that FINRA treats as in scope. This is an inference from FINRA's statements, but it is a direct one: if the inventory is narrower than the supervised activity, the supervisory system is narrower than it appears.

    They also diverge in timing. SR 26-2 emphasizes approval, challenge and monitoring across the lifecycle. Rule 3110 asks whether supervision is reasonably designed for the business as it operates. FINRA itself notes that principal pre-use approval of AI-generated retail communications can be challenging in practice. Controls that act at the point of AI use, not only at approval, give supervisors something concrete to evidence.

    Evidence is the common test

    An examiner on either side will eventually ask the same two questions for a given AI use: what was it allowed to do, and what did it do. Documents written after the fact can describe intent, but records generated by the control itself are stronger evidence of behavior. If policy lives only in a document and monitoring is reconstructed later, the answer depends on memory and assembly.

    The tradeoff is real. Evidence generated at the time of use requires controls that sit where the AI acts, which is a design decision rather than a paperwork task. It also raises retention and data residency questions that compliance, legal and security teams need to settle together. Neither regime, as described here, specifies log content, so the firm has to decide what an examiner would reasonably need and defend that choice.

    A useful self-test: pick one AI use that touches customer communications and try to produce, within a day, its owner, its risk tier, the policy that applied, each interaction's outcome, and any escalation to a human. Gaps in that exercise show where either examination would stall.

    How runtime enforcement supports the evidence requirement

    Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Policy is enforced at runtime, not reviewed after the fact: each interaction or tool call can be allowed, redacted, blocked, rate limited, or escalated for human approval. Enforcement itself generates continuous, audit-ready evidence, so the record of what the AI was permitted to do and what happened comes from the same mechanism that applied the policy. Trussed has run continuously in production in a regulated enterprise for more than 18 months, and its deepest experience is in insurance, a regulated financial sector.

    The scope is specific. Trussed works at the level of individual interactions and tool calls. It does not perform model validation, and it does not provide model lineage or transaction-level governance, so those parts of an SR 26-2 program and a Rule 3110 supervisory system remain with the firm's own processes. Runtime enforcement addresses the question of permitted and actual behavior at the point of use, and it is one input to the evidence both regimes imply.

    One AI use, two examination lenses

    Banking lens

    Model lifecycle, effective challenge, ongoing monitoring, internal audit

    Securities lens

    Supervision under Rule 3110, supervisory controls, communications, third-party tools

    Shared need

    Inventory, accountable owner, and evidence generated at the time of use

    Test your evidence against both examinations

    Walk through one AI use and see how enforcement at runtime produces the records an examiner would ask for.

    Talk to an Expert