Audience: Bank Chief Risk Officers, Chief Model Risk Officers, AI governance teams at financial institutions, OCC / Federal Reserve / CFPB examiners, fintech compliance officers, and third-party AI vendors serving Treasury-regulated banks.
Released February 19, 2026. The U.S. Department of the Treasury published the Financial Services AI Risk Management Framework (FS AI RMF) with 230 control objectives across 7 risk domains. Developed jointly with the Financial Services Sector Coordinating Council (FSSCC), the Cyber Risk Institute (CRI), and over 100 financial institutions. This is voluntary guidance (no new legal obligations), but it establishes the baseline expectations examination teams will reference when evaluating AI deployments at regulated institutions. Financial institutions should prepare evidence now.
1. What Is the FS AI RMF
The Financial Services AI Risk Management Framework (FS AI RMF) is a sector-specific risk management guide published by the U.S. Department of the Treasury on February 19, 2026. It is the first comprehensive framework that translates NIST AI RMF principles into actionable control objectives tailored to the financial services industry.
How It Differs from SR 11-7
SR 11-7 (2011) and OCC Bulletin 2011-12 address model risk management broadly. They treat AI models as a subset of all quantitative models. The FS AI RMF goes further:
- AI-specific controls: SR 11-7 requires "appropriate governance" for all models. The FS AI RMF specifies 230 control objectives for AI systems explicitly, covering agentic behavior, retrieval-augmented generation, generative output, and third-party foundation models.
- 7 risk domains: SR 11-7 is organized around the model lifecycle (development, validation, monitoring). The FS AI RMF organizes around risk categories (governance, data integrity, fairness, explainability), which maps more naturally to how examination teams evaluate AI deployments.
- Shared vocabulary: The accompanying AI Lexicon establishes common terminology so that institutions, vendors, and examiners use the same words for the same concepts.
- Voluntary but expected: SR 11-7 is supervisory guidance with examination consequences. The FS AI RMF is voluntary, but Treasury developed it with FSSCC and CRI specifically so examiners would have a reference framework. Institutions that ignore it will face harder examinations.
Relationship to NIST AI RMF
The FS AI RMF builds on NIST AI RMF 1.0 (January 2023) and its profiles. Where NIST provides general-purpose functions (Govern, Map, Measure, Manage), Treasury maps those functions into financial services-specific control objectives. SWT3 procedures cover both: the same witness anchor that satisfies a Treasury control objective also satisfies the underlying NIST AI RMF subcategory.
Why It Matters Now
Examination teams at the OCC, Federal Reserve, and CFPB are adopting the FS AI RMF as their reference framework for evaluating AI deployments. An institution that can produce SWT3 witness anchors mapped to Treasury control objectives demonstrates a level of AI governance maturity that examiners recognize. An institution that relies on spreadsheets, screenshots, and self-reported logs will spend more time in examination and face more Matters Requiring Attention (MRAs).
2. The 4 Components
The FS AI RMF is not a single document. It is a toolkit of four interrelated components, each serving a different audience:
2.1 AI Adoption Stage Questionnaire
A self-assessment tool for institutions to determine their current AI maturity level. It categorizes institutions into adoption stages (exploratory, developing, mature) and recommends which control objectives to prioritize based on the institution's stage. Institutions in early adoption can focus on governance and data integrity before tackling advanced monitoring and explainability controls.
2.2 Risk and Control Matrix
The core of the framework: 230 control objectives organized across 7 risk domains. Each control objective specifies what the institution must demonstrate, not how to implement it. This is where SWT3 procedures map directly. The matrix is structured so that examiners can select control objectives by risk domain and evaluate evidence against each one.
2.3 User Guidebook
Implementation guidance for practitioners. It walks through each risk domain with examples, explanations, and recommended practices. The guidebook bridges the gap between the control matrix (what to demonstrate) and operational reality (how to gather evidence). SWT3 automates much of the evidence gathering the guidebook describes as manual processes.
2.4 Control Objective Reference Guide
Detailed descriptions of each of the 230 control objectives, including rationale, expected evidence, and relationships to other frameworks (NIST AI RMF, SR 11-7, FFIEC guidance). This is the document examiners consult when evaluating an institution's AI governance program.
3. Risk Domain Overview
| Risk Domain | Control Objectives | SWT3 Procedures | Coverage |
|---|---|---|---|
| 1. Governance | ~40 | AI-GOV.1, AI-GOV.2, AI-GOV.3, AI-GOV.5, AI-AUDIT.1 | 5 procedures |
| 2. Data Integrity | ~30 | AI-DATA.1, AI-RAG.1, AI-RAG.2 | 3 procedures |
| 3. Model Development | ~35 | AI-MDL.1, AI-MDL.3, AI-MDL.4, AI-MDL.5, AI-BASE.1 | 5 procedures |
| 4. Monitoring | ~40 | AI-DRIFT.1, AI-DRIFT.2, AI-PERF.1, AI-INF.1, AI-INF.2 | 5 procedures |
| 5. Third-Party Risk | ~25 | AI-SUPPLY.1, AI-SBOM.1, AI-GOV.5 | 3 procedures |
| 6. Fairness & Consumer Protection | ~35 | AI-FAIR.1, AI-FAIR.2, AI-FAIR.3, AI-CONSENT.1 | 4 procedures |
| 7. Explainability | ~25 | AI-EXPL.1, AI-EXPL.2, AI-TRANS.1, AI-HITL.1 | 4 procedures |
~25 procedures across 7 risk domains. Every procedure is machine-readable in the bidirectional crosswalk file. Because the FS AI RMF builds on NIST AI RMF, SWT3 coverage carries across both frameworks simultaneously.
4. Full Crosswalk Table
| Domain | Requirement Area | SWT3 Procedures | Count |
|---|---|---|---|
| Governance | AI strategy and oversight | AI-GOV.1, AI-GOV.2 | 2 |
| Governance | Policy and accountability | AI-GOV.3, AI-GOV.5 | 2 |
| Governance | Audit and compliance monitoring | AI-AUDIT.1 | 1 |
| Data Integrity | Training data provenance and quality | AI-DATA.1 | 1 |
| Data Integrity | Runtime data retrieval and relevance | AI-RAG.1, AI-RAG.2 | 2 |
| Model Development | Model integrity and validation | AI-MDL.1, AI-MDL.5 | 2 |
| Model Development | Output drift and feedback loops | AI-MDL.3, AI-MDL.4 | 2 |
| Model Development | Foundation model evaluation | AI-BASE.1 | 1 |
| Monitoring | Drift detection and consequence mapping | AI-DRIFT.1, AI-DRIFT.2 | 2 |
| Monitoring | Performance metrics and thresholds | AI-PERF.1 | 1 |
| Monitoring | Inference provenance and latency | AI-INF.1, AI-INF.2 | 2 |
| Third-Party Risk | Supply chain and vendor assessment | AI-SUPPLY.1, AI-GOV.5 | 2 |
| Third-Party Risk | AI software bill of materials | AI-SBOM.1 | 1 |
| Fairness | Bias measurement and calibration | AI-FAIR.1, AI-FAIR.2 | 2 |
| Fairness | Bias audit and consent | AI-FAIR.3, AI-CONSENT.1 | 2 |
| Explainability | Explanation and confidence scoring | AI-EXPL.1, AI-EXPL.2 | 2 |
| Explainability | Transparency and human oversight | AI-TRANS.1, AI-HITL.1 | 2 |
5. Detailed Procedure Cards
Institutional AI Strategy and Oversight
FS AI RMF requires: A documented AI governance framework with board-level accountability, defined roles and responsibilities, and an AI risk appetite statement aligned to the institution's overall risk management strategy.
How SWT3 addresses it: AI-GOV.1 witnesses the existence and review of governance documentation. Factor_a records the governance maturity score (1-5), factor_b records the number of governance artifacts reviewed, and factor_c records whether all required roles are documented. Every governance review cycle produces a new witness anchor, creating a verifiable history of governance evolution.
Filter the witness ledger by AI-GOV.1 to show the governance review timeline. Each anchor proves when governance documentation was last reviewed, who reviewed it, and whether it met the institution's maturity threshold. Trend the factor_a maturity score over quarters to demonstrate governance improvement.
Vendor Governance and Due Diligence
FS AI RMF requires: Assessment and ongoing monitoring of third-party AI providers, including foundation model vendors, cloud AI services, and embedded AI in vendor products. Control objectives span vendor selection, contractual requirements, performance monitoring, and exit planning.
How SWT3 addresses it: AI-GOV.5 witnesses vendor assessment completions. 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.
Show AI-GOV.5 anchors for each third-party AI vendor. If the vendor deploys SWT3, provide the vendor's anchor fingerprints and demonstrate independent verification. Cryptographic vendor due diligence replaces questionnaire-based approaches.
Compliance Monitoring and Audit Readiness
FS AI RMF requires: Comprehensive audit trails for AI systems covering decision provenance, access controls, configuration changes, and compliance status across all risk domains.
How SWT3 addresses it: AI-AUDIT.1 witnesses audit trail completeness. Factor_a records the number of audit events captured, factor_b records the coverage percentage across required domains, and factor_c records whether the audit trail meets retention requirements. The SWT3 ledger itself serves as the immutable audit trail.
Data Lineage, Quality, and Fitness
FS AI RMF requires: Documentation and verification of data sources, transformations, quality checks, and fitness for the model's intended use. For financial models, this includes data representativeness across customer segments and geographic markets.
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. Combine with AI-RAG.1 for models that consume dynamic retrieval data at inference time.
Present AI-DATA.1 anchors alongside the institution's data governance artifacts. The anchor proves data quality was evaluated at a specific point in time with a specific score. The examiner can verify the data quality trend independently.
Runtime Data Retrieval Integrity
FS AI RMF requires: For models using retrieval-augmented generation, documentation of what data was retrieved, from which sources, and whether the retrieval met quality thresholds.
How SWT3 addresses it: AI-RAG.1 witnesses every retrieval event. Factor_a records the number of source documents, factor_b records the retrieval method, and factor_c records a provenance completeness indicator. Each retrieval is anchored with the source identifiers hashed, so the examiner can verify which sources informed a specific decision.
Binary Verification and Tamper Detection
FS AI RMF requires: Assurance that the deployed model binary matches the validated model. This is critical in financial services where model substitution or tampering could affect credit decisions, trading algorithms, or BSA/AML screening.
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: the file on disk matches the file in memory matches the file that was validated. Any unauthorized modification produces a different hash and a FAIL verdict.
Pull the AI-MDL.5 anchor from the last validation date and the current anchor. If the model_hash in factor_a matches, the model has not changed. If it differs, the examiner has cryptographic proof of exactly when the change occurred.
Pre-Deployment Foundation Model Assessment
FS AI RMF requires: Evaluation of foundation models before deployment, including capability assessment, safety testing, and fitness for the intended financial services use case.
How SWT3 addresses it: AI-BASE.1 witnesses the completion of foundation model evaluation. Factor_a records the evaluation score, factor_b records the number of evaluation dimensions, and factor_c records whether the model meets the institution's deployment threshold. This is especially relevant for institutions adopting third-party large language models for customer-facing or decision-support applications.
Continuous Distribution Monitoring
FS AI RMF requires: Mechanisms to detect when model performance degrades due to changing input distributions, concept drift, or data quality deterioration. Financial models face unique drift risks from market regime changes, regulatory shifts, and customer behavior evolution.
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.
Risk-Proportional Drift Response
FS AI RMF requires: Drift thresholds calibrated to the downstream consequences of model degradation. A credit scoring model drifting by 5% has different consequences than a chatbot drifting by 5%. The framework expects institutions to define and enforce consequence-aware thresholds.
How SWT3 addresses it: AI-DRIFT.2 witnesses consequence-mapped drift evaluations. Factor_a records the consequence severity tier, factor_b records the drift magnitude, and factor_c records whether the drift-to-consequence mapping triggered an escalation. This procedure pairs with AI-DRIFT.1 to add risk proportionality to raw drift scores.
Show AI-DRIFT.2 anchors alongside the institution's consequence mapping policy. The examiner verifies that drift thresholds vary by model criticality. A BSA/AML model should have tighter thresholds than a marketing recommendation model.
Every Inference Logged Cryptographically
FS AI RMF requires: Logging of model inputs and outputs sufficient to reconstruct any decision for examination. For credit, lending, and BSA/AML models, this is a regulatory expectation independent of the FS AI RMF.
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 pair. The examiner can request the institution reproduce a specific inference and verify the hash matches.
Vendor and Dependency Risk
FS AI RMF requires: Identification, assessment, and monitoring of all third-party components in the AI supply chain, including model providers, data vendors, cloud infrastructure, and open-source dependencies.
How SWT3 addresses it: AI-SUPPLY.1 witnesses the completion of supply chain assessments. Factor_a records the number of supply chain components evaluated, factor_b records a supply chain risk score, and factor_c records whether all critical dependencies are documented. Combine with AI-SBOM.1 for a complete software bill of materials.
Component Inventory and Vulnerability Tracking
FS AI RMF requires: A complete inventory of software components used in AI systems, including libraries, frameworks, pre-trained models, and data processing pipelines.
How SWT3 addresses it: AI-SBOM.1 witnesses the generation and verification of AI-specific SBOMs. Factor_a records the number of components inventoried, factor_b records the number of known vulnerabilities in the dependency tree, and factor_c records whether all components meet the institution's minimum security baseline.
Quantitative Bias Metrics for Fair Lending
FS AI RMF requires: Regular measurement of disparate impact across protected classes, with documented thresholds and remediation plans. For financial services, this intersects with ECOA, Fair Housing Act, and CFPB fair lending requirements.
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.
For credit models, filter by AI-FAIR.1 and trend the factor_a disparity ratio over the examination period. Cross-reference with AI-HITL.1 to demonstrate that human reviewers evaluated cases where bias metrics approached the threshold. This is the evidence CFPB examiners expect to see.
Consent Collection and Management
FS AI RMF requires: Documentation that consumer consent was obtained where required, consent is specific to the AI use case, and consumers can withdraw consent. Financial institutions must demonstrate that AI-driven decisions respect consumer preferences and regulatory consent requirements.
How SWT3 addresses it: AI-CONSENT.1 witnesses consent events. Factor_a records the consent type (opt-in, opt-out, explicit), factor_b records the scope of consent, and factor_c records whether consent was active at the time of inference. The anchor creates a verifiable chain from consent to decision.
Decision Transparency for Consumers and Examiners
FS AI RMF requires: Explanations of AI-driven decisions that are appropriate for the audience. Consumer-facing explanations (adverse action notices) differ from examiner-facing explanations (model behavior documentation). Both must be generated and retained.
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, and factor_c records a coherence score. The explanation text is never transmitted. Only the fact that it was generated, and its quality metric, are anchored.
Human Oversight for High-Impact Decisions
FS AI RMF requires: Appropriate human oversight of AI outputs, especially for credit decisions, BSA/AML alerts, and customer-facing interactions. The framework specifies that human review must be meaningful, not rubber-stamping.
How SWT3 addresses it: AI-HITL.1 witnesses human review events. Factor_a records whether review was required, factor_b records whether review was completed, 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, proving the review was decision-specific rather than batch-level.
6. Relationship to Existing Guidance
The FS AI RMF does not replace existing supervisory guidance. It supplements it. Understanding how these frameworks relate to each other is essential for efficient evidence production.
SR 11-7 / OCC 2011-12
SR 11-7 remains the foundational model risk management guidance. The FS AI RMF extends SR 11-7 by adding AI-specific control objectives that SR 11-7 does not address (e.g., retrieval-augmented generation, agentic behavior, foundation model evaluation). Institutions subject to SR 11-7 should treat the FS AI RMF as the AI-specific layer on top of their existing model risk management program. See the SR 11-7 crosswalk guide for detailed SR 11-7 procedure mappings.
NIST AI RMF 1.0
The FS AI RMF explicitly builds on NIST AI RMF 1.0. Treasury's 7 risk domains map to NIST's 4 functions (Govern, Map, Measure, Manage). SWT3 procedures that satisfy Treasury control objectives automatically produce evidence relevant to NIST AI RMF subcategories. Institutions pursuing both frameworks can use a single SWT3 deployment.
FFIEC Guidance
The Federal Financial Institutions Examination Council (FFIEC) has issued guidance on technology risk management and third-party relationships. The FS AI RMF's Third-Party Risk domain (Domain 5) aligns with FFIEC third-party risk management guidance. AI-GOV.5 and AI-SUPPLY.1 anchors serve both frameworks.
AI Action Plan
Treasury published the AI Action Plan alongside the FS AI RMF. The Action Plan describes Treasury's strategic priorities for AI in financial services. The FS AI RMF operationalizes those priorities into control objectives that examination teams can evaluate.
7. Examiner Quick Reference
| Examiner Question | SWT3 Evidence |
|---|---|
| Does the institution have AI governance? | AI-GOV.1: governance framework anchors with maturity scores. AI-GOV.2/GOV.3: policy and accountability anchors. Trend governance maturity over quarters. |
| How is training data quality verified? | AI-DATA.1: data provenance anchors with quality scores and source counts. AI-RAG.1: runtime retrieval provenance for RAG-augmented models. |
| Is the deployed model the validated model? | AI-MDL.1 + AI-MDL.5: compare weight hash at validation date to current. Any change produces a different fingerprint and a new anchor. |
| How is model drift monitored? | AI-DRIFT.1: continuous drift scores with alerting thresholds. AI-DRIFT.2: consequence-mapped thresholds calibrated to model criticality. |
| Can you reconstruct a specific decision? | AI-INF.1: provide input/output, examiner recomputes SHA-256, compares to anchor. Match proves authenticity without trusting the institution's logs. |
| How is bias measured for fair lending? | AI-FAIR.1: disparity ratio trend over time. AI-FAIR.2: calibration across subgroups. AI-FAIR.3: independent audit completion anchors. |
| Was a human in the loop for this decision? | AI-HITL.1: anchor proves human review occurred. Timestamp proves sequence. Cycle_id links inference to review. |
| How are third-party AI vendors governed? | AI-GOV.5: vendor assessment anchors. AI-SUPPLY.1: supply chain integrity. AI-SBOM.1: component inventory. If vendor uses SWT3, independent verification. |
| Are explanations generated for decisions? | AI-EXPL.1: explanation generation anchors. AI-EXPL.2: confidence scores. AI-TRANS.1: transparency disclosure records. |
| Was consumer consent obtained? | AI-CONSENT.1: consent type, scope, and active status at time of inference. Verifiable chain from consent event to AI decision. |
| What is in the AI software stack? | AI-SBOM.1: component inventory with vulnerability counts. Independently verifiable software bill of materials for the AI pipeline. |
| 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 required. |
8. Quick Start
Python
TypeScript
Both SDKs support the resolve() function to map FS AI RMF control objectives to SWT3 procedures offline, and the coverage() function to calculate session-level framework coverage.
9. References
- U.S. Treasury Press Release: Financial Services AI Risk Management Framework (February 19, 2026)
- FS AI RMF: Risk and Control Matrix (PDF)
- Financial Services Sector Coordinating Council (FSSCC)
- Cyber Risk Institute (CRI)
- Treasury AI Lexicon: Shared Terminology for Financial Services
- Federal Reserve SR 11-7: Guidance on Model Risk Management
- SWT3 SR 11-7 / OCC Crosswalk Guide (detailed SR 11-7 mapping)
- SR 11-7 Model Risk Overlay
- NIST AI RMF 1.0 and Interoperability
- UCT Registry (full procedure catalog)
- Framework Crosswalks (machine-readable JSON)
- SDK Documentation (Python + TypeScript)