Continuous Monitoring vs Periodic Validation for AI/ML Bank Models

SR 11-7, issued by the Federal Reserve in 2011, and OCC Bulletin 2011-12 remain the governing supervisory guidance for model risk management at U.S. banks. Both documents structure model risk management around three pillars: model development, implementation, and use; model validation; and governance, policies, and controls. Within the validation pillar, SR 11-7 explicitly names ongoing monitoring as a core element alongside evaluation of conceptual soundness and outcomes analysis. This means continuous monitoring is not a new supervisory concept introduced by AI/ML adoption. It is the operational expression of a requirement that has existed in guidance since 2011. What has changed is the technical means available to satisfy it, and the complexity of the models it now applies to. Neither SR 11-7 nor OCC 2011-12 defines AI/ML-specific triggers, drift thresholds, or monitoring cadence. Both predate mainstream machine learning and agent-based deployment in banking, leaving banks to interpret how existing principles apply to newer model types.

Periodic Validation vs Continuous Monitoring

Both practices belong to the same validation framework rather than competing with one another. The table below summarizes how periodic validation and continuous monitoring divide responsibility, and how the two are meant to feed into a single governance process.

Triggers That Determine Which Approach Applies

Data drift, a shift in the distribution of input features, and concept drift, a shift in the relationship between inputs and outputs, are distinct technical conditions that can call for different responses. SR 11-7 does not define either term, but its ongoing monitoring requirement encompasses both, since the guidance requires confirming that a model continues to perform as intended and that its underlying assumptions remain appropriate. Performance decay, measured through outcomes analysis, is the clearest signal that a full periodic revalidation may be warranted rather than a lighter monitoring response. Materiality tiering, already described in SR 11-7 as a function of complexity, input uncertainty, and scope of use, is the practical basis for deciding which models justify investment in continuous monitoring infrastructure and which can rely on periodic validation alone. This mapping is an interpretive extension of existing guidance, not an explicit regulatory requirement, and should be documented as such.

Runtime Governance When AI Agents Interact With Bank Models

SR 11-7 and OCC 2011-12 do not address agent identity, least-privilege permissions, or tool-call auditability, because both predate agent-based automation in banking. Where AI/ML credit, fraud, or underwriting models are embedded in agentic or automated workflows, monitoring needs to extend beyond model output accuracy to the actions taken by agents acting on those outputs. This is an emerging control layer that banks must define internally rather than a documented supervisory expectation. Runtime governance in this context typically involves establishing verifiable agent identity, enforcing least-privilege access to model endpoints and data, requiring approval workflows for higher-risk tool calls, and maintaining audit logs of agent actions alongside model performance metrics. Trussed AI provides runtime governance capabilities in these areas, including agent identity, permissions enforcement, tool approval workflows, and audit logging, which can be positioned as the operational layer that captures agent-driven actions for the same governance function that already reviews periodic validation and continuous monitoring results.