SR 26-2 and Machine Learning Deposit Pricing and ALM Models

Decide scope at the component level

Deposit pricing and ALM work rarely sits in a single model. A pricing engine may combine a deposit beta estimator, an elasticity model, a decay or attrition forecast and a rate-scenario generator, with spreadsheets and rules around them. Treating the whole stack as one inventory entry hides the question that matters: which parts use machine learning to produce quantitative estimates that inform decisions, and which parts only pass data along.

The most defensible approach is to break each model into components and record the task and method of each. The NIST AI Risk Management Framework describes this practice for AI systems generally. Its MAP 2.1 subcategory calls for defining the specific tasks and methods used to implement the tasks a system supports, for example classifiers or recommenders. It is a voluntary framework, not a bank supervisory requirement, but the same description discipline works well for a gradient-boosted beta estimator or a neural attrition forecast.

Once each component is described, test it against the model definition in SR 26-2 itself. The label "machine learning" should neither pull a component into scope nor exempt it. The definition, applied to what the component does and how its output is used, should decide.

Typical ML components and the scope questions they raise

The table lists common component types and the questions a model owner should answer when testing each against the guidance's definition. It frames questions, not conclusions.

• Deposit beta and elasticity estimation: Does the component generate quantitative estimates of rate sensitivity? Do pricing decisions or committee materials rely on its output?
• Decay and attrition forecasting: Does an ML method produce balance runoff or lifetime estimates that feed liquidity, earnings or valuation measures?
• Rate-scenario generation and simulation: Is ML used to generate or shape scenarios, or does it only run deterministic shocks? Which downstream measures consume the output?
• Feature pipelines and data inputs: Is the component a data transformation, or does it embed estimation logic that changes the result? Where does an input end and a model begin?
• Vendor-supplied ML components: Does the institution use the output in decisions? What does it know about the method well enough to describe task and approach?

Common assumptions to test against the text

Institutions tend to carry assumptions into inventory decisions. Three recur in deposit and ALM work. The first is that an ML component is in scope because it is ML, or out of scope because it is only a forecast feeding a larger process. The second is that a vendor-supplied component sits outside the institution's inventory. The third is that validating a model before deployment also covers how it behaves once embedded in production workflows.

None of these should be adopted by habit. Each should be checked against what SR 26-2 actually says, and the answer recorded. Uneven results across pricing, treasury and finance teams usually trace to different teams applying different unwritten assumptions, not to genuine differences between their models. A single written decision method, applied the same way to every component, removes most of that inconsistency and gives examiners one logic to follow.

Validation, monitoring and documentation follow scope

For components judged in scope, the obligations that follow sit in the text of SR 26-2: how the model is defined and inventoried, how it is validated, how it is monitored over time, and what documentation supports each. The practical point for risk leaders is sequencing. The scope decision comes first, because uneven validation almost always begins with an uneven inventory.

For ML components, documentation is easier to defend when it is written for the component rather than the overall model. A deposit beta estimator and a scenario generator differ in purpose, data, method and use, so one narrative covering both rarely answers an examiner's questions about either. Writing per component also makes it clear which evidence belongs to development and validation and which belongs to production behavior.

Where runtime control and evidence fit

Model development and validation practices answer questions about how a model was built, tested and challenged. A narrower set of needs arises when ML-driven or AI-driven components act in production workflows. Examples include an AI assistant that calls a pricing tool, an agent that drafts rate recommendations from model output, or an automated step that writes results into an ALM system. For these, the questions are what the component was permitted to do, what it actually did on a given interaction, and whether a human approved a sensitive action.

These are design considerations, not additional regulatory requirements derived from the guidance. They matter because a validation file describes a model at a point in time and cannot show the behavior of individual production interactions. Runtime policy enforcement and evidence from the execution path can fill that gap. They do not test, validate or re-estimate anything, so they sit alongside validation and never in place of it.

Trussed operates in this narrower space. It enforces policy in the execution path across models, agents, tools and MCP servers, with actions to allow, redact, block, rate limit or escalate for human approval, at the level of individual interactions and tool calls. That enforcement generates audit-ready evidence, and it can be deployed self-managed in the customer's cloud with configurable retention and data residency. Trussed does not perform model validation, model lineage or pre-deployment testing, and it is not a substitute for any of them.