How SWT3 Witness Anchors provide examiner-ready evidence for model risk management
Who this is for: Model Risk Management Officers, Chief Risk Officers, internal auditors, and OCC/Federal Reserve examiners evaluating model governance frameworks. If your institution uses AI or statistical models for credit, fraud, pricing, or capital decisions, this document maps SWT3 procedures to the specific SR 11-7 examination requirements.
SWT3 defines 5 procedures for model risk management. Each procedure produces a tamper-evident Witness Anchor that proves a specific MRM activity occurred, when it occurred, and what the outcome was.
| Procedure | What it proves | SR 11-7 Section | Examination Focus |
|---|---|---|---|
| FIN-GOV.1 | Governance committee reviewed and approved the model | Section III | Committee minutes, quorum, approval votes |
| FIN-MRM.1 | Model registered, version matches approved inventory | Section V | Inventory completeness, version lineage |
| FIN-VAL.1 | Independent validator performed effective challenge | Section VI | Validator independence, sign-off records |
| FIN-MON.1 | Performance metric within threshold, no drift | Section VII | PSI/CSI thresholds, alerting frequency |
| FIN-OUT.1 | Back-test completed, results within tolerance | Section VIII | Sample adequacy, prediction accuracy |
SR 11-7 requires: The board and senior management should ensure model risk management is part of the overall risk framework. A governance structure with clear roles and responsibilities should be established.
How SWT3 addresses it: When the Model Risk Governance Committee votes to approve a model, the vote is anchored with three factors: quorum requirement (factor_a), actual vote count (factor_b), and approval decision (factor_c). The anchor proves a properly constituted committee made a documented decision on a specific date.
The SWT3 anchor for FIN-GOV.1. Factor values confirm quorum was met and the vote was recorded. Cross-reference with your committee charter to confirm the quorum threshold matches governance policy. The anchor is independently verifiable with no vendor dependency.
SR 11-7 requires: A firm-wide model inventory should be maintained with version lineage, purpose, limitations, and risk tier for each model.
How SWT3 addresses it: Each time a model is deployed or updated, the SDK records whether the deployed model hash matches the approved version. PASS means production matches inventory. FAIL means a mismatch was detected, which could indicate an unauthorized model change.
The SWT3 ledger filtered by FIN-MRM.1 for your model. A continuous chain of PASS verdicts demonstrates the model in production has always matched the approved inventory. Any FAIL creates an auditable record of when a mismatch was detected.
SR 11-7 requires: Validation should be conducted by qualified staff independent of model development. "Effective challenge" involves critical analysis by objective, informed parties.
How SWT3 addresses it: When an independent validator signs off, the sign-off is anchored. Factor_b confirms the validator signed. Factor_c records days since last validation for staleness tracking. The anchor proves effective challenge occurred on a specific date.
The SWT3 anchor for FIN-VAL.1 along with the validator's identity from ledger metadata. The examiner confirms: validation occurred, when it occurred, and the record hasn't been altered. Factor_c provides a built-in staleness indicator to compare against your validation frequency policy.
SR 11-7 requires: Models should be subject to ongoing monitoring to confirm they continue to perform as expected. Deterioration should trigger review.
How SWT3 addresses it: The SDK records the performance metric (PSI, CSI, AUC, Gini) against its defined threshold at each monitoring interval. PASS means within bounds. FAIL means the threshold was breached, creating a tamper-evident record of when drift was detected.
The time series of FIN-MON.1 anchors. The examiner sees: monitoring frequency, consecutive PASS verdicts showing stability, and if drift occurred, exactly when. The cryptographic integrity layer binds all monitoring anchors into a single tamper-evident verification artifact.
SR 11-7 requires: Outcomes analysis compares model outputs to actual outcomes. This should be performed regularly with sufficient sample sizes.
How SWT3 addresses it: Each back-testing cycle is anchored with: required sample size (factor_a), actual sample size (factor_b), and whether results were within tolerance (factor_c). PASS means adequate data and predictions aligned with reality.
The SWT3 anchor for FIN-OUT.1 from the most recent cycle. Factor_a vs factor_b proves sample adequacy. Factor_c proves tolerance was evaluated. The timestamp proves when the analysis was conducted. Compare frequency against your MRM policy.
| Examiner question | Where to look |
|---|---|
| "Show me your model governance documentation" | FIN-GOV.1 anchors. Each represents a committee vote with quorum and approval status. |
| "Is this model in your inventory?" | FIN-MRM.1 anchors. PASS = hash matches approved version. FAIL = mismatch detected. |
| "Who validated this model?" | FIN-VAL.1 anchors + ledger metadata for validator identity. |
| "How often do you monitor performance?" | FIN-MON.1 anchor frequency. Daily anchors = daily monitoring. |
| "Has this model drifted?" | FIN-MON.1 factor_c values. 0 = no drift. 1 = threshold breached. |
| "When was the last back-test?" | FIN-OUT.1 most recent anchor timestamp. |
| "Can I verify this independently?" | Yes. Public verifier or offline SHA-256 formula. No vendor dependency. |
| "How do I know records weren't altered?" | Each anchor is a SHA-256 fingerprint. A periodic integrity rollup binds all anchors into a tamper-evident digest. Tampering breaks the chain. |
| "Where is the data stored?" | Clearing Level 2+: factors only, no model details on TeNova side. |
When documenting SWT3 in your Model Risk Management Policy, consider language similar to the following: