Audience: You are a bank examiner, model risk auditor, or MRM governance professional evaluating AI/ML model risk management practices under SR 11-7 (OCC 2011-12). This walkthrough maps SR 11-7 requirements to SWT3 procedures that generate cryptographic model governance evidence. Each procedure produces a tamper-evident Witness Anchor that proves a specific MRM activity occurred, when it occurred, and what the result was.
Contents
1. Anatomy of an SR 11-7 Witness Anchor 2. Section II: Model Development and Implementation II.A: Governance, Risk Assessment, Human Oversight 3. Section III: Model Development Details III.A: Model Design and Documentation III.B: Training Data Quality 4. Section IV: Model Validation IV.A: Ongoing Monitoring and Drift Detection IV.B: Outcomes Analysis, Explainability, Fairness 5. Section V: Governance, Policies, and Controls V.A: Audit, Inventory, Incident Response, Lifecycle 6. MRM Integration 7. Regulatory Examination Tips1. Anatomy of an SR 11-7 Witness Anchor
Every SWT3 Witness Anchor follows the same format regardless of framework. When a model risk management activity is witnessed, the SDK mints an anchor that encodes the tier, infrastructure provider, procedure namespace, specific procedure, verdict, timestamp, and a SHA-256 fingerprint. Here is a sample anchor from a model drift check:
| Segment | Value | What It Tells the Examiner |
|---|---|---|
| SWT3-S | SaaS tier | Connected deployment, anchors verified against central ledger |
| AWS | Cloud provider | Infrastructure where the model inference occurred |
| AI | UCT domain | AI namespace, all model risk procedures live here |
| DRIFT1 | AI-DRIFT.1 | The specific SR 11-7 procedure being witnessed |
| PASS | Verdict | The model's drift metric was within the defined threshold |
| 1780502400 | Unix epoch | Exact second the witness event was recorded |
| a3f1c8b20e47 | Fingerprint | SHA-256 hash binding all factors; independently verifiable at /verify |
SHA256("WITNESS:{tenant}:{proc}:{fa}:{fb}:{fc}:{ts_ms}").hex()[:12]. Paste the anchor into the public verifier or compute the hash offline.
2. Section II: Model Development and Implementation
SR 11-7, Section II requires banks to establish sound practices for model development, including effective governance, risk assessment, and human oversight throughout the model lifecycle. Before any model enters production, the institution must demonstrate that governance structures exist, risk has been evaluated, and qualified personnel exercise oversight.
II.A: Governance, Risk Assessment, Human Oversight
What SR 11-7 requires: The board of directors and senior management bear ultimate responsibility for model risk. A governance framework must define roles, responsibilities, escalation paths, and approval authorities. Models carrying material risk require documented risk assessments. Human oversight must be sufficient to identify, measure, and control model risk at every stage.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-GOV.1 | Model Governance Policy | Existence and version of the institution's model governance policy; PASS when a current, board-approved policy is in effect |
AI-HITL.1 | Human-in-the-Loop Override | Whether a human review gate exists for model outputs above a risk threshold; PASS when override capability is confirmed active |
AI-RISK.1 | Risk Assessment Documentation | Completion and currency of the model's risk assessment; PASS when the assessment is current and covers material risk factors |
How a bank examiner verifies this
Request the AI-GOV.1 anchor chain
Filter the audit portal by procedure AI-GOV.1. Each anchor proves the governance policy was attested as current on a specific date. Confirm the attestation frequency aligns with the institution's policy review cycle (typically annual or upon material change).
Examine AI-HITL.1 for override capability
A PASS verdict on AI-HITL.1 confirms the model has a functioning human override gate. Cross-reference the anchor's factor values against the institution's escalation matrix. The anchor provides evidence that an override capability exists; the examiner determines whether the override threshold aligns with the institution's risk appetite statement.
Verify AI-RISK.1 currency
Check the timestamp on the most recent AI-RISK.1 anchor. The anchor provides evidence of when the risk assessment was last attested. FAIL verdicts indicate the risk assessment was found deficient or missing during attestation. The examiner determines whether the assessment frequency is appropriate for the model's risk tier.
Governance policy exists but has no attestation chain
The institution has a model governance policy document but no AI-GOV.1 anchors, meaning the policy's currency and board approval have never been cryptographically witnessed. This is a documentation gap, not a policy gap, but it undermines the examiner's ability to verify the policy was actively maintained. The absence of attestation evidence is itself an examination finding.
3. Section III: Model Development Details
Section III addresses the technical rigor of model construction. SR 11-7 requires that model development follow sound methodology, that design choices be documented, and that training data be adequate, relevant, and representative.
III.A: Model Design and Documentation
What SR 11-7 requires: Model developers must document the theoretical basis for the approach chosen, the variables selected, the data used for estimation, and any known limitations. Documentation should be sufficiently detailed that a qualified third party could replicate the model independently.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-MDL.1 | Model Registration | Model name, version hash, and registration status; PASS when the deployed model matches the registered and approved version |
AI-MDL.2 | Model Versioning | Version lineage and change documentation; PASS when version transitions are tracked and each version has an auditable record |
How a bank examiner verifies this
Check AI-MDL.1 for model inventory completeness
Each AI-MDL.1 anchor represents a model registration event. The factor values encode the model's SHA-256 hash and registration status. Compare the anchor's model hash against the production deployment artifact. A mismatch indicates the model in production was not the model that was approved -- a red flag for unauthorized model changes.
Trace version lineage with AI-MDL.2
Filter anchors by AI-MDL.2 to see the model's version history. Each anchor records a version transition. Look for gaps in the chain -- a model that jumped from v1.0 to v3.0 without a v2.0 anchor suggests either an undocumented intermediate version or a bypassed approval process.
Model hash in production does not match registered version
AI-MDL.1 returns FAIL because the deployed model's hash diverges from the approved version in the model inventory. This commonly occurs when data scientists deploy hotfixes directly to production without going through the model approval workflow. The FAIL anchor itself becomes the examination evidence -- it proves the mismatch was detected and recorded, even if remediation is still pending.
III.B: Training Data Quality
What SR 11-7 requires: Training data must be relevant, sufficient, and representative. Data quality assessments should evaluate completeness, accuracy, and appropriateness for the model's intended use. Limitations arising from data should be clearly documented.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-DATA.1 | Training Data Provenance | Data source, vintage, completeness metrics, and consent status; PASS when training data meets the institution's data quality standards |
How a bank examiner verifies this
Review AI-DATA.1 anchor factors
The AI-DATA.1 anchor records the training data's provenance attestation. Factor values encode data source identification, vintage (how current the data is), and quality metrics. Verify that the training data vintage recorded in the anchor aligns with the institution's documented data governance policy. The examiner determines whether the vintage is appropriate for the model's use case.
No training data provenance attestation for Tier 1 models
High-risk models have no AI-DATA.1 anchors. The institution cannot demonstrate that training data quality was evaluated or that data sources were documented. Under SR 11-7, this is a material deficiency -- the examiner has no way to assess whether the model's foundation is sound.
4. Section IV: Model Validation
SR 11-7 requires independent model validation through "effective challenge" -- critical analysis by objective, informed parties who can identify model limitations and produce appropriate changes. Validation is not a one-time event; ongoing monitoring and outcomes analysis are essential components.
IV.A: Ongoing Monitoring and Drift Detection
What SR 11-7 requires: Models must be subject to ongoing monitoring to confirm they continue to perform as intended. Processes should be in place to detect deterioration in model performance, including population stability, concept drift, and input data changes. Deterioration should trigger review and, if necessary, model redevelopment.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-DRIFT.1 | Model Drift Detection | Drift metric (PSI, CSI, KL divergence) compared against defined threshold; PASS when within bounds, FAIL when threshold breached |
AI-MDL.3 | Model Performance Baseline | Baseline performance metrics at deployment; establishes the reference point against which ongoing monitoring compares |
How a bank examiner verifies this
Establish monitoring frequency from anchor cadence
Filter the audit portal by AI-DRIFT.1 and examine the timestamp intervals between consecutive anchors. Daily anchors demonstrate daily monitoring. Weekly or monthly intervals should be evaluated against the model's risk tier. The examiner determines appropriate monitoring frequency based on the model's risk tier and use case.
Identify drift events and response times
Look for FAIL verdicts in the AI-DRIFT.1 chain. Each FAIL represents a threshold breach -- the model's behavior has diverged from its baseline. Then check whether a remediation action followed: a subsequent AI-MDL.1 or AI-MDL.2 anchor indicates a model update was deployed. The time gap between the FAIL and the remediation anchor is the institution's drift response time.
Verify the baseline exists
AI-MDL.3 anchors establish the performance baseline. Without a baseline, drift detection has no reference point. Confirm that each model in the inventory has at least one AI-MDL.3 anchor, and that the baseline was refreshed after any model retrain event.
Drift detected but no remediation within policy timeframe
AI-DRIFT.1 shows a FAIL on March 3, but the next AI-MDL.2 version update does not appear until April 28 -- 56 days of operating with a drifted model. The anchor chain provides irrefutable evidence of the remediation timeline. The examiner compares this timeline against the institution's own remediation policy to determine whether a policy violation occurred.
IV.B: Outcomes Analysis, Explainability, Fairness
What SR 11-7 requires: Outcomes analysis compares model predictions to actual results. Models should be explainable to the degree required by their use case and regulatory context. The examiner determines which additional regulatory requirements apply based on the model's use case. Back-testing, sensitivity analysis, and benchmarking are standard validation techniques.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-EXPL.1 | Model Explainability | Whether the model produces interpretable outputs (SHAP, LIME, feature importance); PASS when explainability artifacts are current |
AI-FAIR.1 | Fairness and Bias Assessment | Bias testing results across protected classes; PASS when disparate impact ratios are within thresholds |
AI-PERF.1 | Performance Validation | Back-test or holdout results; PASS when accuracy, precision, recall, or custom KPI meets the defined acceptance criteria |
How a bank examiner verifies this
Assess explainability coverage
AI-EXPL.1 anchors prove the institution evaluated the model's interpretability. A FAIL verdict provides evidence that the explainability assessment did not pass attestation. The examiner determines whether the absence of explainability evidence is material based on the model's use case and applicable regulatory requirements.
Review fairness testing cadence and results
AI-FAIR.1 anchors record bias assessments. The anchor chain provides evidence of testing frequency and verdict history. A pattern of alternating PASS/FAIL suggests the model is near its defined threshold boundary. The examiner determines whether the testing cadence and results are appropriate for the model's use case.
Validate back-testing rigor with AI-PERF.1
AI-PERF.1 factor values encode the performance metric and acceptance threshold. The anchor provides evidence of which metric was used and whether the model met its threshold. The examiner determines whether the metric is appropriate for the model type and whether the threshold aligns with the institution's risk appetite.
No fairness testing for consumer-facing AI model
A model has no AI-FAIR.1 anchors. The absence of fairness testing evidence for any model that affects individuals should be noted. The examiner determines whether additional testing is warranted based on the model's use case and applicable regulations.
5. Section V: Governance, Policies, and Controls
Section V addresses the enterprise-wide control environment. SR 11-7 requires a comprehensive framework of policies, procedures, and controls that covers the entire model lifecycle -- from initial development through ongoing use, modification, and eventual retirement. Internal audit should assess the overall model risk management framework.
V.A: Audit, Inventory, Incident Response, and Lifecycle Management
What SR 11-7 requires: Internal audit should assess the effectiveness of the model risk management framework. A firm-wide model inventory must be maintained. Processes for incident response and model retirement must be established. The control framework should provide reasonable assurance that model risk is identified, measured, monitored, and controlled.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-AUDIT.1 | Audit Trail Completeness | Whether the model's audit trail is complete, covering all lifecycle events; PASS when no gaps are detected in the evidence chain |
AI-GOV.4 | Policy Version Control | Governance policy versioning and change tracking; PASS when current policy version is approved and changes are documented |
AI-GOV.5 | Stakeholder Notification | Whether relevant stakeholders were notified of model changes; PASS when notification records are confirmed |
AI-GOV.6 | Regulatory Mapping | Model's regulatory obligation mapping; PASS when all applicable regulations are identified and mapped |
AI-GOV.7 | Third-Party Model Governance | Governance controls for vendor-supplied or third-party models; PASS when vendor due diligence is current |
AI-IR.1 | Incident Response | Whether a model incident response procedure exists and was tested; PASS when the IRP covers model failure scenarios |
AI-PMM.1 | Post-Market Monitoring | Ongoing production monitoring beyond initial validation; PASS when post-deployment monitoring is active and current |
AI-REV.1 | Anchor Revocation | Revocation of a prior anchor due to model recall, data contamination, or error correction; documents why a previously valid attestation is no longer trustworthy |
How a bank examiner verifies this
Audit the audit trail with AI-AUDIT.1
AI-AUDIT.1 is the meta-control -- it witnesses whether the model's full evidence chain is intact. A PASS verdict means the system confirmed continuity across all lifecycle procedures. A FAIL means gaps were detected: missing validation events, skipped monitoring periods, or undocumented version changes. This is often the first procedure an examiner should check, as it provides an immediate completeness assessment.
Evaluate third-party model governance
Many institutions use vendor-supplied models. AI-GOV.7 anchors prove the institution conducted vendor due diligence and maintains oversight of third-party model performance. FAIL indicates either missing vendor documentation or expired due diligence reviews. The examiner determines whether additional third-party risk management requirements apply.
Verify incident response readiness
AI-IR.1 anchors prove the model incident response procedure was tested. Look for both the existence of the procedure (at least one anchor) and the testing frequency. An institution that has never tested its model failure response plan has an untested control. The anchor provides evidence of whether the procedure was tested; the examiner determines the appropriate citation.
Check for revocation events
AI-REV.1 anchors are significant findings. Each revocation documents why a previously valid anchor was invalidated. Seven reason codes exist: model recall, policy violation, data contamination, consent withdrawal, regulatory order, error correction, or unspecified. The presence of revocations is not inherently negative -- it demonstrates the institution has a functioning recall mechanism. The absence of revocations in an institution with many models may indicate the mechanism exists but has never been exercised.
Vendor models have no governance attestation
The institution relies on three vendor-supplied fraud models but has zero AI-GOV.7 anchors. SR 11-7 is clear: "use of vendor and other third-party products does not diminish the responsibility of the board of directors and senior management to ensure that the bank's model risk management framework covers all models." Without third-party governance evidence, the examiner cannot verify that vendor model risk is being managed. The anchor record (or its absence) provides the evidence; the examiner determines materiality.
No post-market monitoring distinction from pre-deployment validation
The institution has AI-PERF.1 anchors (performance validation) but no AI-PMM.1 anchors (post-market monitoring). This suggests the institution treats validation and monitoring as the same activity. SR 11-7 distinguishes between pre-deployment validation and ongoing production surveillance. AI-PMM.1 specifically witnesses production behavior monitoring, which should be continuous and may cover metrics that differ from the initial validation criteria.
6. MRM Integration
SWT3 Witness Anchors do not replace the institution's model risk management framework. They provide a cryptographic evidence layer that sits alongside existing MRM documentation, committee minutes, and validation reports. The following guidance helps MRM teams integrate anchor evidence into their existing workflows.
Model Inventory Enrichment
Each model in the institution's inventory can be enriched with its SWT3 anchor chain. The recommended approach is to add a "Witness Evidence" column to the model inventory that links to the audit portal filtered by model identifier. This gives examiners a single-click path from the inventory to the full evidence chain.
Model Risk Reports
Quarterly model risk reports to the board can incorporate SWT3 evidence summaries. Recommended metrics include:
- Anchor coverage ratio: percentage of Tier 1 models with complete procedure coverage
- Drift event count: number of AI-DRIFT.1 FAIL verdicts in the reporting period
- Mean time to remediate: average days between a FAIL verdict and the next PASS on the same procedure
- Revocation count: number of AI-REV.1 events, broken down by reason code
- Third-party governance currency: percentage of vendor models with AI-GOV.7 attestation within 12 months
Three Lines of Defense Mapping
| Line | Role | SWT3 Usage |
|---|---|---|
| 1st Line | Model developers, business units | SDK integration generates AI-MDL.1, AI-MDL.2, AI-DATA.1 anchors automatically during model lifecycle events |
| 2nd Line | MRM team, Chief Risk Officer | Reviews anchor chains for completeness; uses AI-DRIFT.1 and AI-PERF.1 trends in model risk reports; manages AI-GOV.1 attestation cycle |
| 3rd Line | Internal Audit | Verifies anchor integrity via public verifier; confirms AI-AUDIT.1 completeness; uses anchor timestamps for testing sample selection |
7. Regulatory Examination Tips
Scoping the Model Risk Examination
When scoping an AI/ML model risk examination at an institution using SWT3:
- Request the full anchor export for all models in scope. The SR 11-7 checklist maps each procedure to the specific guidance paragraph.
- Start with AI-AUDIT.1 for each model. This immediately reveals which models have complete evidence chains and which have gaps.
- Prioritize by model tier. High-risk models should have coverage across all 19 mapped procedures. Lower-tier models may have reduced coverage consistent with the institution's risk-based approach.
- Compare anchor cadence against policy. If the MRM policy requires monthly drift monitoring, confirm AI-DRIFT.1 anchors appear at monthly intervals. Cadence gaps are policy violations regardless of the individual verdicts.
- Verify at least one anchor independently. Use the public verifier to confirm the SHA-256 fingerprint matches. This establishes the integrity of the entire evidence chain for the examination workpapers.
Common Examiner Questions and Where to Look
| Examiner Question | Where to Look | Red Flag |
|---|---|---|
| "Show me your model governance structure" | AI-GOV.1 anchors; governance policy document | No anchors, or last anchor is older than the policy review cycle |
| "How do you monitor model drift?" | AI-DRIFT.1 time series; AI-MDL.3 baseline | No baseline anchor; monitoring gaps longer than policy permits |
| "What happens when a model fails?" | AI-IR.1 (incident response); AI-REV.1 (revocation events) | No AI-IR.1 anchors; AI-REV.1 with reason code "unspecified" used excessively |
| "Who validated this model?" | AI-PERF.1 + AI-EXPL.1 anchor chain; validator identity in ledger metadata | Validator is the same person/team that developed the model (independence concern) |
| "Is your training data appropriate?" | AI-DATA.1 provenance attestation | Training data vintage does not align with the institution's data governance policy |
| "How do you manage vendor models?" | AI-GOV.7 third-party governance anchors | No vendor model governance evidence despite material vendor model reliance |
| "Can I verify this evidence independently?" | Public verifier or offline SHA-256 computation | Fingerprint does not match (indicates tampering or data corruption) |
| "What is your model decommission process?" | AI-REV.1 with reason code "model_recall"; AI-PMM.1 cessation | Models remain in production with no recent monitoring anchors |
Related Resources
- SR 11-7 Overlay -- FIN procedure mapping to SR 11-7 sections
- SR 11-7 Assessment Checklist -- procedure-by-procedure examination tool
- SR 11-7 Compliance Checklist -- printable checklist for field examiners
- Assessment Playbook -- general assessment methodology for all frameworks
- Public Verifier -- independent anchor verification
- SDK Documentation -- integration guides for model development teams