SR 26-2 (April 2026) directs institutions to apply existing model risk management principles to AI systems by materiality, but leaves the mechanics to each institution. The SRF finance schema operationalizes those mechanics: 40 controls across five layers, each with a named accountable persona, a measurable threshold, and a pointer to the OCSF telemetry stream that proves the control is functioning.
Institutions and their counterparties are moving away from point-in-time attestations toward continuous, verifiable evidence that controls are operating. The OCSF evidence plane in this schema is built for exactly that standard.
SR 26-2 supersedes SR 11-7 (Guidance on Model Risk Management, 2011) and SR 21-8 (Interagency Statement on Model Risk Management for BSA/AML, 2021), issued jointly by the Federal Reserve, OCC, and FDIC. Read SR 26-2 ↗
Five-step workflow
Identify your operating model
The schema covers four operating models. Filter to the ones relevant to your deployment before beginning any control mapping. Controls not tagged for your model do not apply and need not appear in your workpaper.
Agent-PaaS deployments carry the largest control surface. SR 26-2 places agentic AI formally out of scope but directs institutions to apply existing MRM principles. SRF L3 and L4 controls address that gap directly, covering agent authorization, tool execution limits, guardrail bypass monitoring, and runtime integrity verification.
Map personas to internal owners
Each control names an accountable_persona. Map every schema persona
to the team or role in your institution that owns it. This mapping becomes the RACI
column in your validation workpaper and establishes who must produce evidence for
each control.
| Schema persona | Typical internal owner | Layers |
|---|---|---|
ai-system-governance |
AI risk officer / model risk committee | L1 |
data-provider |
Data engineering / data steward | L2 |
application-developer |
Model development team | L3 |
agentic-platform-provider |
Agent orchestration platform team or vendor | L3 |
ai-platform-provider |
MLOps / cloud platform team or vendor | L4 |
model-provider |
Foundation model vendor (external) or ML science team | L5 |
For vendor-sourced AI components (AI-SaaS, AI-PaaS), the accountable persona is still mapped to the internal team responsible for vendor oversight, not to the vendor itself. Accountability does not transfer with the contract.
Set your tier parameters
Controls with param_type: "tier-defined" carry no fixed values.
Your institution fills them based on SR 26-2's materiality approach. Maintain
a single institutional tier table and reference it across all workpapers rather
than duplicating values per model.
| Tier | Example model types | Drift threshold (L2-MON-002) | Review cadence (L1-MON-003) |
|---|---|---|---|
| Tier 1: Critical | Credit decisioning, fraud detection, trading algorithms | PSI < 0.10, 30-day window | 30 days |
| Tier 2: Non-critical | Document summarization, internal Q&A, report generation | PSI < 0.25, 60-day window | 60 days |
Controls with param_type: "zero-tolerance" or
param_type: "verification" carry fixed values by design and
require no tier parameterization. Any unauthorized write to an agent memory
store is a breach regardless of model tier; a load-time integrity check either
passes or it does not.
Confirm OCSF evidence streams
Before beginning validation, confirm with your platform team that the event types
required by in-scope controls are being emitted. Each control's
threshold.evidence block names an OCSF event class, an attribute,
and the schema version.
SRF-L4-MON-001 · L4 Guardrails & Safety · Ongoing monitoring
Runtime guardrail bypass rate monitoring
OCSF class
ai_operation unverified-proposal
Attribute
guardrail_bypass_flag
Operator · param type
<= · zero-tolerance
Window
24h
Breach action
escalate-l1-governance
OCSF version
1.8.0
Note on ai_operation:
This OCSF class is a proposal in v1.8.0, pending final ratification. Controls
using it carry ocsf_class_status: "unverified-proposal". Until
ratified, validate against your vendor's equivalent event schema and note the
substitution in your workpaper.
Controls at L1 (governance artifacts, board minutes, policy records) do not
produce streaming OCSF events. Their ocsf_class fields are
prefixed TBD: with a note on the artifact type. Validate these
against the relevant records management system or GRC platform.
Perform and document effective challenge
For each in-scope control, query the evidence stream for the specified window, compare the observed metric against your tier parameter, and record the result. The workpaper should be self-contained: an examiner reading it cold must be able to trace each control to its SR 26-2 principle without additional lookup.
| Column | Source | Notes |
|---|---|---|
| Control ID and title | id and title |
Copy verbatim from the schema |
| Accountable party | Your persona-to-team mapping (step 2) | Internal team name, not the schema persona ID |
| Tier parameter value | Your institutional tier table (step 3) | Reference your tier table by version, not by copying values |
| Observed metric and window | OCSF query result | Include query timestamp and event count |
| Pass / Fail | Operator comparison | For zero-tolerance controls, any non-zero value is a Fail |
| SR 26-2 principle addressed | mappings.sr26_2 |
Gives examiners a direct traceability chain to the letter text |
| Escalation taken (if breach) | breach_action |
Record date, recipient, and resolution status |
The mappings.sr26_2 and mappings.finos_aigf fields
on each control provide the traceability chain examiners expect: control to
existing MRM principle to regulatory text. For controls where the SR 26-2
mapping is still marked TBD, verify against the letter text at
federalreserve.gov
before including in examiner-facing documentation.
Effective challenge workpaper: example template