Retention Periods and Evidence Requirements for Bank AI Decision Records After SR 26-2

Treat retention as evidence design

Examiners reviewing an AI-assisted decision want to see what the system was permitted to do and what it actually did. A retention setting alone cannot answer that. The question comes first: which records, if kept, let the bank reconstruct a decision for the period in which it may be questioned?

This matters because SR 26-2 does not hand risk teams one retention number. The schedule has to be assembled by reconciling model risk management practice with the record-keeping rules that already apply to the underlying business activity. Where AI supports a credit decision, the retention duty attaches to the decision and the information used to make it. The use of AI does not remove that duty.

The practical output is a documented schedule that states, for each record type, why it is kept, for how long, and under which rule. That document is what a bank can hand an examiner. It also shows that over-retention of sensitive data was a deliberate tradeoff rather than a default.

Retention clocks that may apply to AI-assisted credit decisions

These are current federal periods as of November 2026 that could govern records tied to AI-assisted credit decisions. They run from different trigger events, so one AI record may sit under more than one clock. Counsel should confirm applicability and identify other obligations, including state requirements, privacy rules and legal holds.

• Regulation B, consumer credit: 25 months for the application and related records, running from the date the creditor notifies the applicant of action taken or of incompleteness. Covered records include any other written or recorded information used in evaluating the application.
• Regulation B, business credit: 12 months in general, with special rules for certain business credit.
• Regulation B, larger business and trade credit: At least 60 days after notice of action. If the applicant asks in writing within that period for reasons for adverse action or for retention, the creditor keeps records for 12 months.
• Regulation Z: Two years after the date disclosures or action are required. Enforcing agencies may require a longer period.
• Small business lending recordkeeping (12 CFR 1002.111): At least three years after the register is required to be submitted to the Bureau.
• FDI Act Section 21: Prescribed periods may not exceed six years unless a longer period is determined necessary for a particular record type. Applicability to AI decision records needs counsel's confirmation.

Which AI decision records to retain

Regulation B reaches the application and any written or recorded information used in evaluating it. It includes a provision for computerized systems that decide mechanically from entered items, where retaining the information actually entered may suffice. Whether that provision extends to AI-assisted decisions with intermediate steps is a question for counsel. Until it is answered, a conservative record set is easier to defend than a minimal one.

Five record types cover most of what is needed to reconstruct an interaction-level decision. Policy decisions record whether each interaction or tool call was allowed, redacted, blocked or escalated, with a timestamp. Interaction inputs and outputs record what the AI received and returned, after redaction of sensitive fields where the bank's policy requires it. Tool calls record which tools or systems the AI invoked and with what parameters. Human approvals record who reviewed an escalated action and what they decided. Policy versions record which rule set was in force at the time, so a decision can be matched to the policy that governed it.

If a third party supplies a score or model, the bank still carries its own retention duties for the decision. Contracts should give the bank the inputs, outputs and any version identifier for the model or data used, available for the full retention period, including after the contract ends. Vendors may update models while earlier decisions are still inside their retention window, so the version needs to be tied to the decision date.

Where runtime enforcement evidence fits

A runtime enforcement layer is relevant to one part of this problem: evidence at the level of individual interactions and tool calls. When policy is enforced in the execution path, each allow, redact, block or escalate decision can produce a record at the moment it happens, rather than being reconstructed afterward. Trussed works at this level, producing audit-ready evidence from enforcement and supporting self-managed deployment in the customer's cloud with configurable retention and data residency. It generates more than 30 GB of audit evidence per day in production, which is why tiering and storage planning belong in the design from the start.

It does not cover everything a bank may need. It does not provide workflow-level tracing or model lineage, so those records have to be covered elsewhere in the model risk management program.

When evaluating any enforcement layer against this schedule, ask five questions. Does it record inputs, outputs and the policy decision for each interaction and tool call, with a timestamp? Can retention be set per record type and per rule, and can legal holds override it? Is evidence stored in the bank's own cloud account, and in which region? How are sensitive fields redacted before retention, and how is deletion evidenced? Which records does it not capture? The answers show whether the tool can support the schedule or only part of it.