Audience: Model Risk Officers, OCC/Fed examiners, Chief Risk Officers, AI governance teams at banks and bank holding companies, and third-party model vendors serving Treasury-regulated institutions.
AI models are models under SR 11-7. The Federal Reserve and OCC have confirmed that machine learning and AI systems used in credit decisions, fraud detection, BSA/AML screening, and capital planning are subject to the same model risk management standards as traditional quantitative models. The challenge: AI models produce different evidence than traditional quant models. This guide maps the evidence SWT3 produces to the evidence examiners expect.
1. Why AI Models Need Different Evidence
Traditional model risk management assumes models are equations with fixed parameters, validated once and monitored on a schedule. AI models break every one of those assumptions:
- Opacity: A logistic regression has coefficients an examiner can read. A transformer has billions of weights no human can inspect. Evidence must prove the right model ran, not explain how it works.
- Drift: Traditional models are stable between recalibration cycles. AI models can drift continuously as input distributions shift. Evidence must be continuous, not periodic.
- Data dependency: A traditional model's training data is documented in a model card. An AI model's retrieval pipeline (RAG) pulls context dynamically. Evidence must cover what was retrieved, not just what was trained.
- Agent autonomy: AI agents make tool calls, access databases, and delegate to sub-agents. Traditional models produce a number. Evidence must cover every action, not just the output.
SWT3 addresses each gap by producing cryptographic witness anchors at the point of action. Every inference, every tool call, every resource access generates a tamper-proof record. The examiner does not need to trust the bank's logs. The examiner can independently verify every anchor using only the anchor string and a SHA-256 hash function.
2. Full Crosswalk: SR 11-7 to SWT3
| SR 11-7 Section | Requirement Area | SWT3 Procedures | Count |
|---|---|---|---|
| II.A | Risk Identification and Categorization | AI-RISK.1 | 1 |
| III.A | Bias, Disparity, and Fairness | AI-FAIR.1, AI-FAIR.2, AI-FAIR.3 | 3 |
| III.B | Model Validation and Data Integrity | AI-DATA.1, AI-FIN.1, AI-MDL.1, AI-MDL.4, AI-MDL.5 | 5 |
| IV.A | Performance Monitoring | AI-DRIFT.1, AI-INF.1, AI-INF.2, AI-MDL.3, AI-PERF.1, AI-RAG.2, AI-ROBUST.1 | 7 |
| IV.B | Governance and Documentation | AI-EXPL.1, AI-EXPL.2, AI-HITL.1 | 3 |
| V.A | Third-Party Vendor Assessment | AI-GOV.5 | 1 |
20 procedures. 5 SR 11-7 sections. Zero gaps. Every procedure is machine-readable in the bidirectional crosswalk file under the SR-11-7 framework key.
3. Section II.A: Risk Identification and Categorization
SR 11-7 requires institutions to identify all models in use, assess their risk, and categorize them by materiality. For AI systems, this includes identifying which models are deployed, their risk tier, and their intended use.
Model Inventory and Risk Classification
SR 11-7 requires: A comprehensive inventory of all models, risk-rated by materiality, with clear documentation of intended use, limitations, and risk category.
How SWT3 addresses it: Every model that passes through the SDK is automatically inventoried by model ID, provider, and version hash. The witness anchor records the model identity at every inference, creating a live inventory that cannot diverge from reality. Risk categorization is captured in the clearing level assignment and the AI-RISK.1 factor schema: factor_a records the risk tier (1-4), factor_b records the number of risk dimensions assessed, and factor_c records a policy compliance indicator.
Export the model inventory from the AI Witness dashboard. Each entry shows model ID, first seen / last seen dates, total inference count, clearing level, and risk tier. The examiner can verify any entry by recomputing the anchor fingerprint. No reliance on self-reported logs.
4. Section III.A: Bias, Disparity, and Fairness
SR 11-7 Section III.A addresses fair lending, disparate impact, and bias in model outcomes. For AI models used in credit, pricing, or customer segmentation, this section creates the highest examination intensity.
Quantitative Bias Metrics
SR 11-7 requires: Regular measurement of disparate impact across protected classes, with documented thresholds and remediation plans when bias is detected.
How SWT3 addresses it: AI-FAIR.1 witnesses the output of your bias measurement pipeline. Factor_a records the disparity ratio (0.0-1.0), factor_b records the number of protected classes evaluated, and factor_c records whether the measurement passed the four-fifths rule threshold. Each measurement is anchored with a timestamp, creating an immutable bias measurement timeline.
Filter the witness ledger by AI-FAIR.1 for the model under review. The examiner sees every bias measurement, when it ran, what the disparity ratio was, and whether it passed. Trend the factor_a values over time to show measurement consistency.
Calibration Across Subgroups
SR 11-7 requires: Evidence that model predictions are calibrated consistently across demographic subgroups, not just accurate in aggregate.
How SWT3 addresses it: AI-FAIR.2 records calibration metrics per subgroup. Factor_a is the calibration score, factor_b is the number of subgroups tested, and factor_c indicates whether the calibration meets the institution's defined threshold.
Independent Audit Trail
SR 11-7 requires: Independent review of bias assessments, with documentation that the reviewer was independent from the model development team.
How SWT3 addresses it: AI-FAIR.3 witnesses the completion of a bias audit. Factor_a records whether the audit was internal or external (1=internal, 2=external), factor_b records the audit scope (number of models covered), and factor_c records the audit outcome (1=passed, 0=findings). The anchor is signed by the reviewing agent's signing key, cryptographically binding the reviewer identity.
5. Section III.B: Model Validation and Data Integrity
SR 11-7 Section III.B requires independent validation of models before deployment and ongoing verification of data quality. For AI models, this extends to training data provenance, weight integrity, feedback loop isolation, and transaction authorization.
Data Lineage and Quality
SR 11-7 requires: Documentation of data sources, transformations, quality checks, and fitness for the model's intended use.
How SWT3 addresses it: AI-DATA.1 witnesses the provenance of training data. Factor_a records the number of data sources, factor_b records a data quality score (0-100), and factor_c records whether data lineage documentation is complete. For RAG-augmented models, combine with AI-RAG.1 (context retrieval provenance) to cover both training and runtime data.
Deployed Model Matches Approved Model
SR 11-7 requires: Verification that the model in production is the same model that was validated. No unauthorized modifications.
How SWT3 addresses it: AI-MDL.1 records the SHA-256 hash of the deployed model weights at every inference. If the model changes between examinations, the hash changes. The examiner can compare the current hash against the validation record to confirm the model has not been modified.
Pull the AI-MDL.1 anchor from the last validation date. Pull the current AI-MDL.1 anchor. If the model_hash in factor_a matches, the model has not changed. If it differs, the examiner has cryptographic proof of when the change occurred.
Preventing Uncontrolled Self-Reinforcement
SR 11-7 requires: Controls to prevent models from learning from their own outputs in ways that amplify errors or bias.
How SWT3 addresses it: AI-MDL.4 witnesses whether feedback loop isolation controls are in place. Factor_a records whether isolation exists (1=yes, 0=no), factor_b records the feedback path count, and factor_c records whether any path is self-referencing.
Model Binary Verification
SR 11-7 requires: Assurance that model files have not been tampered with between validation and production deployment.
How SWT3 addresses it: AI-MDL.5 streams the model file through SHA-256 and records the hash. Combined with AI-MDL.1 (runtime verification), this creates a two-point integrity chain: file on disk matches file in memory matches file that was validated.
Autonomous Financial Operations
SR 11-7 requires: Controls over model outputs that directly affect financial transactions, including authorization checks and settlement verification.
How SWT3 addresses it: AI-FIN.1 witnesses autonomous agent financial operations before execution. Factor_a records the authorization type (pre-authorized, human-approved, auto-approved), factor_b records the transaction amount in cents, and factor_c records the settlement status. Every AI-driven transaction carries a witness anchor that can be audited independently.
Filter by AI-FIN.1 for the examination period. The examiner sees every AI-initiated transaction: authorization type, amount range, and settlement outcome. No reliance on application logs. The anchor is independently verifiable.
6. Section IV.A: Performance Monitoring
SR 11-7 Section IV.A requires ongoing monitoring of model performance in production. For AI models, "ongoing" means every inference, not quarterly. This section has the highest procedure count because AI models produce the most evidence here.
Continuous Distribution Monitoring
SR 11-7 requires: Mechanisms to detect when model performance degrades due to changing input distributions, concept drift, or data quality deterioration.
How SWT3 addresses it: AI-DRIFT.1 witnesses drift detection results. Factor_a records the drift score (0.0-1.0), factor_b records the number of features monitored, and factor_c records whether drift exceeded the alerting threshold. Each measurement is anchored, creating a continuous drift timeline the examiner can trend.
Every Inference Logged
SR 11-7 requires: Logging of model inputs and outputs sufficient to reconstruct any decision for examination.
How SWT3 addresses it: AI-INF.1 hashes the prompt and response at every inference. The raw text never leaves the institution's infrastructure. The anchor proves the inference occurred, when it occurred, which model produced it, and the SHA-256 hash of the input/output. The examiner can request the institution reproduce a specific inference and verify the hash matches.
For a sampled decision, provide the raw input/output and the AI-INF.1 anchor. The examiner recomputes SHA-256 locally. If the hashes match the anchor, the record is authentic. No trust in the institution's logging system required.
Response Time Monitoring
SR 11-7 requires: Monitoring of operational risk indicators including system performance and response times.
How SWT3 addresses it: AI-INF.2 records the actual latency of every inference against a configured threshold. Factor_a is the threshold in milliseconds, factor_b is the actual latency, and factor_c flags whether the threshold was exceeded. Persistent latency violations indicate infrastructure degradation or model complexity issues.
Output Distribution Monitoring
SR 11-7 requires: Detection of shifts in model output distributions that may indicate degradation or changed operating conditions.
How SWT3 addresses it: AI-MDL.3 complements AI-DRIFT.1 by focusing on output-side drift. Factor_a records the statistical distance metric (e.g., KL divergence), factor_b records the reference period, and factor_c records the verdict against the institution's drift tolerance.
Accuracy and Reliability Tracking
SR 11-7 requires: Ongoing measurement of model accuracy, precision, recall, and other performance metrics appropriate to the model's use case.
How SWT3 addresses it: AI-PERF.1 witnesses performance metric snapshots. Factor_a records the primary metric value (e.g., AUC-ROC), factor_b records the number of evaluation samples, and factor_c records whether the metric meets the institution's minimum threshold.
Retrieval Quality for RAG Models
SR 11-7 requires: For models that use retrieval-augmented generation, evidence that retrieved context is relevant and not introducing noise or bias into decisions.
How SWT3 addresses it: AI-RAG.2 records the relevance score of each retrieved context chunk against a similarity threshold. Factor_a is the average similarity score, factor_b is the number of chunks retrieved, and factor_c records whether all chunks exceeded the minimum relevance threshold. Low relevance scores trigger FAIL verdicts.
Adversarial and Stress Testing
SR 11-7 requires: Stress testing and sensitivity analysis to understand model behavior under adverse conditions.
How SWT3 addresses it: AI-ROBUST.1 witnesses the results of robustness testing campaigns. Factor_a records the number of test scenarios, factor_b records the pass rate, and factor_c records whether the test campaign met the institution's acceptance criteria.
7. Section IV.B: Governance and Documentation
SR 11-7 Section IV.B requires governance structures, documentation standards, and human oversight mechanisms. For AI models, this includes explainability (where possible), confidence calibration, and human-in-the-loop controls.
Decision Transparency
SR 11-7 requires: Documentation sufficient for stakeholders to understand model outputs and their drivers, even for complex models.
How SWT3 addresses it: AI-EXPL.1 witnesses whether an explanation was generated for a given inference. Factor_a records whether an explanation exists (1=yes, 0=no), factor_b records the explanation method (e.g., SHAP, LIME, attention), and factor_c records a coherence score. The explanation text is never transmitted. Only the fact that an explanation was generated, and its quality metric, are anchored.
Calibrated Uncertainty
SR 11-7 requires: Model outputs should include confidence indicators so that downstream consumers can assess reliability.
How SWT3 addresses it: AI-EXPL.2 records the model's confidence score for each inference. Factor_a is the confidence value (0.0-1.0), factor_b is a calibration metric, and factor_c records whether the confidence exceeds the institution's minimum threshold for automated action.
Distribution of AI-EXPL.2 confidence scores over the examination period. Low-confidence inferences that proceeded without human review are flagged by cross-referencing AI-EXPL.2 (low factor_a) with AI-HITL.1 (no review recorded).
Human-in-the-Loop Controls
SR 11-7 requires: Appropriate human oversight of model outputs, especially for high-impact decisions.
How SWT3 addresses it: AI-HITL.1 witnesses human review events. Factor_a records whether review was required (1=yes, 0=no), factor_b records whether review was completed (1=yes, 0=no), and factor_c records the reviewer method (manual, tool-assisted, escalation). The anchor proves a human was in the loop for the specific decision, not just that a review policy exists.
For sampled credit decisions, show the AI-HITL.1 anchor alongside the AI-INF.1 anchor. The timestamps prove the sequence: inference occurred, then human review completed. The cycle_id links both anchors to the same decision.
8. Section V.A: Third-Party Vendor Assessment
SR 11-7 Section V.A addresses models developed or hosted by third parties. When a bank uses a vendor's AI model (e.g., a cloud-hosted fraud detection API), the bank retains responsibility for model risk management. The vendor's model must meet the same evidence standards.
Vendor Model Governance
SR 11-7 requires: Due diligence on third-party model providers, ongoing monitoring of vendor model performance, and contractual provisions for examination access.
How SWT3 addresses it: AI-GOV.5 witnesses the completion of vendor assessments. Factor_a records the assessment completeness score, factor_b records the number of vendor controls evaluated, and factor_c records the assessment outcome. When the vendor also uses SWT3, the bank can independently verify the vendor's witness anchors without relying on vendor-provided reports.
Vendor assessment AI-GOV.5 anchors for each third-party model. If the vendor uses SWT3, provide the vendor's anchor fingerprints and demonstrate independent verification. This is cryptographic vendor due diligence, not a questionnaire.
9. Quick Start: fintech-model-risk Profile
The SDK ships with a fintech-model-risk profile pre-configured for SR 11-7 compliance:
The fintech-model-risk profile sets:
- Clearing level 2 (Sensitive) -- strips provider metadata, protects customer data
- Signing required -- every anchor carries HMAC-SHA256 for non-repudiation
- Drift monitoring enabled -- AI-DRIFT.1 and AI-MDL.3 active by default
- 16 procedures pre-selected for SR 11-7 coverage
- Jurisdiction: US -- compliance status fields bound to US regulatory context
Run swt3 doctor to verify your configuration covers all 20 SR 11-7 procedures.
10. Examiner Quick Reference
| Examiner Question | SWT3 Evidence |
|---|---|
| What AI models are in production? | AI Witness dashboard: model inventory with first seen, last seen, inference count, and version hash per model. |
| Has this model been modified since validation? | AI-MDL.1 + AI-MDL.5: compare weight hash at validation date to current. Any change produces a different fingerprint. |
| How is bias measured? | AI-FAIR.1: trend factor_a (disparity ratio) over time. AI-FAIR.3: audit completion anchors with reviewer identity. |
| Is drift being monitored? | AI-DRIFT.1 + AI-MDL.3: continuous drift scores with alerting thresholds. Every measurement anchored. |
| Can you reconstruct a specific decision? | AI-INF.1: provide input/output, examiner recomputes SHA-256, compares to anchor. Match proves authenticity. |
| Was a human in the loop? | AI-HITL.1: anchor proves human review occurred. Timestamp proves it happened after inference. Cycle_id links both. |
| How are third-party models governed? | AI-GOV.5: vendor assessment anchors. If vendor uses SWT3, examiner can independently verify vendor's anchors. |
| Are AI-driven transactions authorized? | AI-FIN.1: every AI-initiated transaction carries authorization type, amount, and settlement status in a witness anchor. |
| How is RAG retrieval quality controlled? | AI-RAG.2: relevance scores per chunk, threshold enforcement, FAIL verdicts when context quality degrades. |
| Can I verify this evidence independently? | Yes. Every anchor is verifiable with SHA-256 and the anchor string alone. No vendor access, no API keys, no special tools. |
References
- Federal Reserve SR 11-7: Guidance on Model Risk Management
- OCC Bulletin 2011-12: Supervisory Guidance on Model Risk Management
- SR 11-7 Model Risk Overlay (FIN namespace)
- SWT3 Protocol Specification
- UCT Registry (full procedure catalog)
- Framework Crosswalks (machine-readable JSON)
- SDK Documentation (Python + TypeScript)