Model risk (SR 11-7 and SR 26-2)

Guidance

SR 11-7 (April 4, 2011), superseded by SR 26-2 (April 17, 2026)

Agents under SR 26-2

Outside its scope; the bank’s own governance sets the controls

Flow evidence

kirto-flow-replay: exit 0 match, 1 diverged, 2 could not run

Gate evidence

kirto-gate audit verify over the signed trail

Where the guidance stands

SR 11-7 is the Federal Reserve and OCC guidance on model risk management of April 4, 2011. On April 17, 2026 the Federal Reserve, the OCC and the FDIC issued SR 26-2, Revised Guidance on Model Risk Management, which supersedes and replaces it.

SR 26-2 puts generative AI and agentic AI models outside its scope, in a footnote to its Purpose and Scope section. The same footnote says a banking organization’s own risk management and governance practices should decide the controls for systems the guidance does not cover. Its principles apply to traditional statistical and quantitative models and to AI models that are neither generative nor agentic.

Its definition of a model also excludes deterministic rule-based processes with no statistical, economic or financial theory behind them. A process definition and a DMN table of business rules fall on that side. A credit score that a process step calls is a model in the guidance’s sense. An agent step is outside it.

A reviewer who holds an agent to the model-risk disciplines anyway asks the questions below. Each names the section of the guidance it comes from and the record that answers it.

What a reviewer asks, and what answers it

Is it implemented and used as intended?

SR 11-7’s section on validation makes ongoing monitoring its second core element: monitoring confirms that a model is appropriately implemented and is being used and is performing as intended. Its process verification checks that every component functions as designed. SR 26-2 keeps ongoing model monitoring as a component of validation.

Flow answers for the process around the model. Each case records its inputs as seeds: the events that arrived and each command’s result, an agent step’s output among them. A replay feeds those seeds through a fresh engine over the pinned process definition and compares the chain it derives with the stored one, row by row. A clean diff shows the engine reached the recorded steps from the recorded inputs alone. A divergence is reported with its position and the field that differs.

The replay runs from the command line as kirto-flow-replay -model order.bpmn -history case-1.json, from the case API at GET /v1/cases/{kind}/{id}/replay, and in the browser. All three call the same code.

Can the code change without approval?

SR 11-7 asks that code implementing a model be under change control, so that only approved parties can alter it and every change is logged and can be audited.

Flow keeps each process definition in an append-only store keyed by namespace, kind, name and semantic version. Bytes stored under a version never change. Every case records the definition’s name, its version and the Flow build it ran on. A replay under a different major or minor build is flagged as version skew, and the CLI exits 1.

Gate keeps retained revisions of its configuration. kirto-gate config diff shows what a revision changed and kirto-gate config rollback writes an earlier one back. Each configuration write lands in the audit trail with its actor and the revision now serving.

What did the model see, and what did it return?

Process verification in SR 11-7 includes checking that internal and external data inputs stay accurate, complete and consistent with the model’s purpose and design.

An agent step’s result in Flow carries the OpenTelemetry GenAI attributes: the provider, the model the step requested, input and output tokens, and the finish reason. The agent’s own run records each turn’s raw response. In a process case the step’s output is the replay seed. Gate sits on the call itself. Its guardrails run on the request and the response, and each refusal or rewrite is recorded with the entity types found and their counts. The matched text is never in the record.

Who overrode the output, and how often?

SR 11-7 asks that ongoing monitoring analyse overrides, with documentation, because a model whose output users often ignore or reverse is not performing as intended.

A human approval in a Flow process is a human.gate row on the case, keyed to the task and carrying the decision. The record is queryable by event type, model, element, principal and time window across a namespace, so an override rate is a query over it. Flow does not compute the rate.

Can a party unfamiliar with it see how it works?

SR 11-7 asks for documentation detailed enough that parties unfamiliar with a model can understand how it operates, its limitations and its key assumptions. SR 26-2 says documentation supports continuity and the tracking of recommendations, responses and exceptions.

In Flow the process definition is the document that ran. BPMN, CMMN and DMN are published standards a reviewer can read without the product, and each case names the version it executed. The agent’s model is documented by whoever validated it.

Which models are in use, and under what restrictions?

SR 11-7’s model inventory describes each model’s purpose, its usage and any restrictions on use. SR 26-2 keeps the inventory in its Governance and Controls section.

Every model call that crosses Gate is counted in kirto_gate_tokens_total by route, provider and model. Access rules decide which providers and models a key may reach, and a refusal is recorded with the rule that refused it. That is the observed half of an inventory. The owners, the validation dates and the purpose stay in the bank’s own register.

Is the record itself trustworthy?

SR 26-2 gives internal audit the job of evaluating whether model risk management practices are rigorous and whether policies are implemented. That evaluation reads records.

Gate’s audit trail is a hash chain per node, each entry signed with the node’s ed25519 key. kirto-gate audit verify reads an exported trail and reports any record altered, removed from the middle, moved or forged. Witnessed chain heads cover a trail cut at the end. A rule may carry governance control identifiers, and every decision it makes carries them onto the record. kirto-gate controls reads a configuration the other way round: each control, the rules that name it, and the controls nothing enforces. See Verify the audit trail and Show what enforces a control.

Flow’s case record is append-only, and every Flow host writes the same rows for a case. The Flow record is not signed.