SR 26-2 Robo-Advisory Models: Scoping Portfolio Recommendation Systems at Banks

What SR 26-2 is and who it reaches

On 17 April 2026 the FDIC, OCC and Federal Reserve issued revised model risk management guidance and rescinded existing model risk management guidance. The Federal Reserve publishes it as SR 26-2. The FDIC stated that it is rescinding FIL-22-2017 and FIL-27-2021 with this release. As of November 2026, no later amendment has been reported.

The agencies describe the approach as risk-based and commensurate with a banking organization's size, complexity and extent of model use. The guidance discusses the factors that influence model risk, the features of effective model development and use, model validation and monitoring, and governance and controls. It says that not all models present the same level of risk, and that a similar model at two banks may present different risks. It is expected to be most useful for models supporting significant business lines, operations, services and functions.

The guidance generally does not apply to models at banking organizations with total assets of $30 billion or less, to the extent they lack significant exposure to model risk. The FDIC notes that such models are typically subject to internal risk management and governance practices appropriate to the institution's size and risk profile. The OCC adds that the guidance may also be relevant to smaller institutions with significant model risk exposure, for example because of the prevalence and complexity of their models. A bank should therefore record its asset-size position and its assessment of model risk exposure as a documented determination, not an assumption.

Scoping the advisory pipeline component by component

A robo-advisory product is not one model. It is a chain of components with different technical natures, and the model definition has to be applied to each. The table below frames the scoping question for each component. It does not state outcomes, because the answer depends on the definition in the primary text and on how the bank has built the component.

The point most likely to be contested is deterministic, rules-based logic. Teams sometimes assume that fixed rules fall outside the model definition. That assumption should not be recorded as a conclusion until counsel has tested it against the text of SR 26-2. Even where a rules engine is judged out of scope, a documented rationale is what makes the exclusion defensible.

• Client profiling: Questionnaire scoring or inferred risk tolerance. Ask whether the output is a quantitative estimate that feeds downstream decisions, and how inputs are validated.
• Allocation logic: A rules-based glide path and an optimizer or machine learning allocator are technically different. Scope each on its own mechanics and record the rationale.
• Recommendation generation: Product selection and rebalancing triggers. Consider materiality: client impact and the significance of the business line.
• Generative AI explanation layer: Text shown to clients. The OCC describes generative and agentic AI models as novel and rapidly evolving, so classification and risk rating need explicit reasoning.
• Vendor-supplied advice tool: Scope the tool as deployed at the bank. Establish what validation and monitoring evidence the vendor will provide when the bank cannot see underlying code or data.

Inventory, validation, monitoring and documentation

Once a component is judged in scope, the expectations that follow come from the guidance's treatment of development and use, validation and monitoring, and governance and controls. The precise wording of each expectation, including third-party provisions, should be confirmed in the primary text. The practical implications for a recommendation system are fairly stable.

Inventory comes first. An incomplete inventory is the most common way advisory models escape validation and monitoring altogether. Entries for borderline tools, such as rules engines, vendor advice tools and generative explanation layers, should carry the scoping rationale, not only the components clearly treated as models. Each entry should carry a risk rating based on materiality, so that validation and monitoring effort is proportionate, consistent with the guidance's tailoring principle.

For validation, an examiner would reasonably expect evidence that inputs, logic and outputs were reviewed independently of the developers. FINRA's AI report, written for securities firms and relevant to banks by analogy, points to validation that covers input data, algorithms, parameters and output explainability, and to parallel running before current models are retired.

For ongoing monitoring, define performance benchmarks for recommendation outputs, run them on a schedule and retain the results. FINRA's examples include tracking error types such as false negatives. Documentation should let a reviewer who was not on the project understand the intended use, the limits of the model and the basis for any scoping exclusion.

Obligations that operate alongside model risk management

SR 26-2 addresses model risk. It does not replace the rules that govern investment advice. SEC staff guidance on robo-advisers states that registered investment advisers, including robo-advisers, are subject to the substantive and fiduciary obligations of the Advisers Act. It focuses on three areas: disclosures to clients, obtaining client information to support the duty to provide suitable advice, and compliance programs designed to address automated advice.

FINRA's AI report cites its earlier Report on Digital Investment Advice, which calls for governance and supervision covering suitability of recommendations, conflicts of interest, customer risk profiles and portfolio rebalancing.

The overlap is real but incomplete. Client profiling inputs matter to both suitability and model risk. A model validation report, however, does not by itself show that a recommendation was suitable for a given client, and a suitability file does not show that the model was validated. Neither SEC nor FINRA material addresses bank applicability directly, so counsel should map these obligations to the bank's entity structure, including any affiliated adviser or broker-dealer, and decide how the two sets of evidence are kept together.

Where runtime and production evidence gaps appear

Examiners tend to ask two questions about an advisory system: what was it permitted to do, and what did it actually produce. Development-time documentation answers the first only in design terms. The gap typically appears in production. Policies exist as documents, but nothing records which policy applied to a specific client interaction, which tool call was made, or whether an output was altered or held back. Explanation layers make this sharper, because free-text output varies between interactions.

Runtime enforcement is one design option for closing that gap. SR 26-2 is not stated to require it, and it does not replace model validation. Trussed enforces policy in the execution path for individual interactions and tool calls, with actions to allow, redact, block or escalate for human approval, and it generates audit-ready evidence from that enforcement. For example, a bank could constrain what an explanation layer may say to a client and retain a record of each decision. Trussed does not provide model lineage or dataset provenance, and it does not claim financial-services deployments. Its production record spans 18+ months of continuous operation in a regulated enterprise, and insurance is where it is deepest.

Whatever tooling is chosen, the test is the same: for a sampled client interaction, can the bank show the applicable policy, the action taken and the output delivered? Settle that question early, because the evidence has to exist before the examination.