SR 26-2 Collections and Loss Mitigation Models: Scope, Controls and Evidence

Reading SR 26-2 for collections and loss mitigation

Collections and loss mitigation sit in an awkward place for model risk programs. Many of the tools are operational: queue prioritization, dialer sequencing, contact timing rules, hardship screening, modification eligibility logic. They are often embedded in servicing platforms or supplied by vendors, and they may never have been registered as models. The first question under SR 26-2 is therefore a scoping question. Does each tool fall within the guidance's definition of a model, and who in the institution made that call?

This guide separates three layers so they are not confused. The first is the text of SR 26-2 itself, which the institution must read and apply directly. The second is adjacent supervisory guidance that shows a consistent pattern in how agencies look at scoring, collections effectiveness and model use. The third is operational interpretation: how a risk team might structure an inventory, controls and evidence for tools that sit in distributed servicing environments. Where this page describes the second and third layers, it labels them as such, and none of it should be quoted as SR 26-2 requirements.

The practical consequence is that scope decisions should be written down. A tool that is determined to be out of scope needs a recorded rationale as much as an in-scope tool needs controls, because the reasoning will be the first thing a reviewer asks to see.

What adjacent supervisory guidance already says

Two 2020 interagency documents show how supervisors have approached these areas. The interagency guidance on credit risk review systems states that, when applicable, credit risk review includes evaluating the appropriateness of automated underwriting and credit scoring, including prudent use of overrides. It also covers the effectiveness of account management strategies, collections and portfolio management activities in managing credit risk. In other words, collections strategy and automated scoring have long been treated as reviewable activities, not just operations.

The interagency policy statement on allowances for credit losses is narrower in purpose but useful as a model governance reference. It says that where an institution uses loss estimation models, management should evaluate them before they are employed, modify logic and assumptions as needed, and document its evaluations and conclusions on the appropriateness of using them. Models used for multiple purposes should be specifically adjusted and validated for the loss estimation use, with adjustments, outputs and compensating controls documented and supported. It also points to initial and ongoing validation, and notes that estimates that consistently and materially over- or under-predict actual losses may indicate a weakness in the forecasting process.

These documents are not SR 26-2 and do not define its scope. They are relevant because they show the pattern a risk leader can reasonably expect: evaluate before use, document the conclusion, validate on an ongoing basis, and support any adjustments. Collections and loss mitigation models that share data or outputs with loss forecasting inherit the multi-purpose concern directly.

Mortgage servicing: mapping AI use to Reg X touchpoints

For mortgage portfolios, loss mitigation is also governed by Regulation X, 12 CFR Part 1024 Subpart C, which is in force as of November 2026. It applies to mortgage servicing only and should not be generalized to other consumer credit collections. The subpart requires servicers to make personnel available by telephone to a delinquent borrower, who respond to inquiries and, as applicable, assist with available loss mitigation options. This continues until the borrower has made two consecutive mortgage payments without a late charge under a permanent loss mitigation agreement. It also addresses informing borrowers about the options available from the loan owner or assignee, the actions needed to be evaluated including submitting a complete application, and appeal rights where a trial or permanent modification denial is appealable. Section 1024.41 states that it imposes no duty on a servicer to provide any borrower with any specific loss mitigation option.

These are defined workflow steps, so AI-enabled components can be mapped to them: inquiry response, option information and application evaluation. That mapping is an operational interpretation, not a stated requirement. It is still useful, because it shows where an AI tool touches a regulated borrower interaction and therefore where a control or an escalation to a person is most likely to matter. A generative tool that drafts an answer about available options, for example, should be inventoried and constrained differently from one that summarizes a call for internal notes.

Separating pre-deployment evidence from runtime evidence

Two kinds of evidence answer different questions. Pre-deployment evidence shows that a model was evaluated, validated and documented before use, and that adjustments and compensating controls were supported. Runtime evidence shows what the tool was actually permitted to do and what it did when it ran. Distributed servicing environments tend to have more of the first than the second, which is why reviewers can be shown a validation report but not a record of production behavior for a vendor tool or an AI assistant.

The NIST AI RMF offers vocabulary for the runtime side. It describes operational testing and evaluation as including ongoing monitoring, periodic updates and recalibration, tracking and managing reported incidents or errors, detecting emergent properties, and processes for redress and response. It is a voluntary framework and not a regulatory requirement, but it gives risk teams a way to describe what ongoing use should look like for AI components.

The two evidence types should stay separate in the file. Runtime records do not validate a model's design, data or performance, and a validation report does not show what happened on a given day. Presenting one as a substitute for the other weakens both.

Where runtime policy enforcement fits

Runtime enforcement addresses a specific gap: showing what an AI system was allowed to do and what it did. Trussed enforces policy in the execution path for individual AI interactions and tool calls, so policy is enforced at runtime, not reviewed after the fact. For a collections or loss mitigation deployment, that means an agent-assist request to retrieve account data, or a generative response to a borrower, can be allowed, redacted, blocked, rate limited or escalated for human approval according to rules the institution sets. The enforcement decisions generate audit-ready evidence as a byproduct. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency.

The boundary is important. Runtime enforcement supports ongoing-use expectations by constraining and evidencing individual interactions and tool calls. It does not perform model validation, produce development documentation or replace pre-deployment testing, and it does not make a scope determination for the institution. It also does not address transaction-level governance, model lineage or end-to-end tracing of agentic workflows. A risk team should treat it as one input to the evidence file, alongside validation and monitoring work done elsewhere.

The tradeoff is design effort. Policies need to be written for each in-scope tool, with clear rules on which data a tool may retrieve, which statements a borrower-facing tool may make, and when a person must approve. That work is also what forces the institution to state what each tool is permitted to do.