# Finance AI Governance — free starter kit

AutoGovern · reviewed 2026-09-12

Use governance metadata only. Keep customer records, account data and documents in your authorised systems. These templates are planning aids, not legal advice, regulatory approval or model validation.

## Model inventory and tiering record

- Model or AI system name and business purpose: [complete]
- Decision or action influenced; products, channels and segments in scope: [complete]
- Out-of-scope uses and prohibited actions: [complete]
- Model type (rules / supervised ML / generative / agentic) and developer or vendor: [complete]
- Version, inputs, outputs and downstream consumers: [complete]
- Impact if wrong (1–3) and exposure (1–3) → materiality tier: [complete]
- Model owner, independent validation owner and approving committee: [complete]
- Who can suspend use and the tested fallback: [complete]
- Applicable regimes (SR 26-2, PRA SS1/23, OSFI E-23, MAS, EU AI Act, NAIC …): [complete]
- Validation status, last validation and next validation date: [complete]
- Revalidation triggers (change, breach, data shift, regulation): [complete]
- Linked data flows, third parties and monitoring plan references: [complete]

## Independent validation and effective-challenge report

- Model, version and scope of this validation: [complete]
- Validator, independence from development and authority to reject: [complete]
- Conceptual soundness: method, assumptions, limitations, implementation checks: [complete]
- Data representativeness, quality and lineage findings: [complete]
- Outcomes analysis and backtesting results against pre-set limits, with denominators: [complete]
- Segment and stress results; segments with insufficient sample: [complete]
- Fairness testing: bases, proxies, method, results and jurisdiction relied on: [complete]
- Explainability: reason-code accuracy, specificity and stability tests: [complete]
- Findings by severity with required remediation and owners: [complete]
- Conclusion: approved / approved with conditions / rejected, and expiry: [complete]
- Ongoing-monitoring requirements handed to the model owner: [complete]

## Fair lending, adverse action and consumer-harm review

- Decision type (credit, insurance, pricing, marketing, servicing) and jurisdictions: [complete]
- Prohibited bases considered and proxy variables reviewed: [complete]
- Disparate-treatment checks and disparate-impact test results by group: [complete]
- Jurisdictions where disparate impact is relied on (FHA/HUD, DOJ, states, NY DFS, Colorado, EU/UK) and the ECOA status note: [complete]
- Adverse-action reason codes: source, verification method and sample notices: [complete]
- FCRA notice and consumer-report source handling: [complete]
- Foreseeable-harm / Consumer Duty and UDAAP assessment for customer-facing use: [complete]
- Complaint, dispute and human-override routes: [complete]
- Open issues, mitigations and conditions: [complete]
- Reviewer, date and next review: [complete]

## AI third-party and ICT register entry

- Provider, service, version, hosting region and subcontractors: [complete]
- Function supported and criticality (critical / important / standard): [complete]
- Data sent, data returned and training / retention terms: [complete]
- Validation approach and vendor transparency available: [complete]
- Contract reference: audit rights, incident notification, exit and data return: [complete]
- Concentration: alternatives available and tested exit plan: [complete]
- DORA register-of-information fields (EU entities) and interagency third-party lifecycle stage (US): [complete]
- Ongoing-monitoring cadence, owner and last review: [complete]
- Incidents and material changes since last review: [complete]
- Decision, conditions and next review date: [complete]

## How to use the templates

### 1. Register and tier a model or AI system

Owner: Model owner (first line) + model risk management (second line)

1. Describe the business purpose, the decision or action it influences, the products, channels and customer segments in scope, and the uses that are out of scope. Separate a model used for operations from one that affects a customer outcome.
2. Record the model type (rules, supervised machine learning, generative or agentic AI), the developer or vendor, version, input data, output destination and level of autonomy. Note that SR 26-2 places generative and agentic AI outside its scope; those systems still need governance under safety-and-soundness, conduct and third-party expectations.
3. Assign a materiality tier from impact if the model is wrong and exposure (volume, value, customer reach). Tier sets the depth and frequency of independent validation, monitoring and approval — proportionality is expected by SR 26-2, PRA SS1/23, OSFI E-23 and the MAS AI model-risk paper alike.
4. Name the model owner, an independent validation owner outside the development team, the approving committee and who can suspend use. Register the next validation date and the events that trigger revalidation: material change, performance breach, data change, regulatory change.

Output: An inventory record with purpose, type, tier, owners, version and a dated validation plan.

### 2. Map data, lineage and consumer-report use

Owner: Data owner + compliance + privacy

1. Draw each source → transformation → feature → decision path, including bureau data, external data vendors, internal transaction history and any model that feeds another model. List data categories; do not copy customer records into a governance worksheet.
2. Classify the data: personal, consumer report (FCRA permissible purpose and dispute duties apply, including AI-derived scores that function as consumer reports), special-category or protected-class data, transactional, market data. Record the legal basis or permissible purpose for each use.
3. Apply BCBS 239 discipline: accuracy, completeness, timeliness and reconciliation to source. Record data-quality controls, known gaps and how missing or stale inputs are handled in the model and in the decision engine.
4. Define retention for inputs, features, outputs, explanations and monitoring data. Decision records (input snapshot, model version, reason codes, outcome, human overrides) must be retained long enough to answer adverse-action disputes, complaints, supervisory requests and litigation.

Output: A reviewed lineage register with data classes, permissible-purpose rationale, quality controls and retention decisions.

### 3. Review a vendor model or AI third party

Owner: Third-party risk + model risk + legal

1. Inventory the exact service: provider, product, version, hosting, subcontractors, data it receives and what it returns. Rate its criticality to the process it supports and whether an alternative exists — concentration in one provider is itself a risk to record.
2. Obtain what validation needs: developmental evidence, performance results, documentation of limitations, change-notification terms and access for testing. Where transparency is limited, compensate with outcomes analysis, benchmarking and sensitivity testing on your own portfolio, and record the residual uncertainty.
3. Review the contract for data use and training terms, incident notification, audit and information rights, exit and data return. EU financial entities must keep a DORA register of information for every ICT third-party arrangement and meet its contractual requirements; critical providers face direct supervisory oversight.
4. Set an ongoing-monitoring cadence: performance, provider changes, incidents, financial condition and sub-outsourcing. Recheck material provider, model or hosting changes before extending the approved use; tested exit plans matter most for critical services.

Output: A service-specific third-party decision with contract evidence, validation approach, criticality, exit plan and a review date.

### 4. Validate: conceptual soundness, outcomes, fairness and explainability

Owner: Independent validation + fair-lending compliance

1. Independent validators assess conceptual soundness: is the method appropriate for the decision, are assumptions and limitations documented, is the implementation faithful to the design, and is the data representative of the intended population? Effective challenge needs people with the competence, authority and independence to reject the model.
2. Run outcomes analysis and backtesting against defined limits: discrimination, calibration, stability by segment, and behaviour under stress or data shift. Record denominators, sample sizes and uncertainty; a segment with too few observations is unknown coverage, not a pass.
3. Test fairness across prohibited bases, including proxies and external data. Disparate treatment remains unlawful everywhere. The CFPB removed the ECOA disparate-impact effects test with effect from 21 July 2026, but that rule is contested and does not reach the Fair Housing Act, DOJ, state law, NY DFS Circular 7 or Colorado SB 21-169 — keep disparate-impact testing and record which jurisdictions you rely on it for.
4. Verify explainability for the decision: adverse-action reason codes must be accurate, specific and consistent with how the model actually works (ECOA / Regulation B §1002.9, FCRA §1681m). Test that reason codes are stable for similar applicants and that the notice process can produce them for every declined or counter-offered application.
5. Document findings by severity, required remediation, conditions of approval and the validation conclusion. Retain rejected and conditional outcomes; validation that only records approvals is not credible to a supervisor.

Output: A versioned validation report with scope, methods, results, fairness and explainability evidence, findings and an independent conclusion.

### 5. Approve a controlled deployment with consumer safeguards

Owner: Model risk committee / release authority + compliance

1. Review the validation conclusion, open findings, third-party decisions, data permissions and tier-appropriate approvals. Record conditions, limits (products, channels, segments, volume) and the expiry of the approval.
2. Confirm the consumer safeguards are live before the first customer decision: adverse-action and counter-offer notices with specific reasons, FCRA notices where consumer reports are used, complaint and dispute routes, human review and override for declines and edge cases.
3. For customer-facing generative assistants and advice tools, assess foreseeable harm and conduct duties before release: FCA Consumer Duty outcomes, UDAAP, marketing claims about AI (the SEC has enforced against "AI-washing"), suitability and recordkeeping. Bound topics, escalation and disclosure.
4. Map jurisdiction-specific readiness: EU credit scoring and life/health insurance pricing become high-risk under the AI Act with obligations from 2 December 2027 after the Digital Omnibus deferral, including a deployer Fundamental Rights Impact Assessment; DORA applies now; NAIC AI Systems Program expectations apply in adopting states; PRA SS1/23 for UK banks with internal-model approval.
5. Rehearse the stop and fallback: who can suspend the model, how decisions route to manual underwriting or a prior approved version, and how affected customers are identified and remediated. A UI toggle that nobody has tested is not a kill switch.

Output: A dated release decision naming the approved version, scope, conditions, safeguards, fallback owner, expiry and revalidation triggers.

### 6. Monitor performance, drift, fairness and incidents

Owner: Model owner + monitoring team + operational resilience

1. Define ongoing-monitoring metrics per model: outcome performance, calibration, population and feature drift, override and exception rates, reason-code distribution, complaint and dispute volumes, and fairness metrics by segment. Record cadence, freshness limits and who reviews results.
2. Set escalation thresholds with the model owner and validation team. Treat threshold breaches as revalidation triggers; log the decision to continue, restrict or suspend, and the evidence used.
3. Watch the operational layer: latency, availability, provider changes and security events such as prompt injection or data leakage. For algorithmic trading, pre-trade controls and the ability to halt order flow are required under SEC Rule 15c3-5.
4. Classify incidents and start the reporting clocks: DORA major ICT-related incident notifications for EU entities, supervisory and conduct reporting where required, and consumer remediation when decisions were wrong. Keep customer details in the authorised case system; keep governance references here.
5. Close the loop: corrective action, retest, updated documentation and a new review before restarting or expanding. Retire models cleanly — remove access, archive decision records per retention, and update the inventory.

Output: A monitoring plan per model, incident runbook with reporting deadlines, and a record of revalidation decisions.

## Frequently asked questions

**Does SR 26-2 apply to generative or agentic AI?**

No. SR 26-2 (April 2026, superseding SR 11-7) covers models including supervised machine learning at banks over $30 billion in assets, and states that generative and agentic AI are outside its scope pending further interagency work. Those systems are still expected to be inventoried, governed and controlled under safety-and-soundness, third-party and conduct expectations.

**Is disparate-impact testing still required after the 2026 Regulation B change?**

The CFPB rule effective 21 July 2026 removed the disparate-impact "effects test" under ECOA only, and it is being contested. Disparate impact remains actionable under the Fair Housing Act, by the Department of Justice, under many state laws, NY DFS Circular 7 and Colorado SB 21-169. Most institutions keep testing and record which jurisdiction each test supports.

**When does the EU AI Act apply to credit scoring and insurance pricing?**

Creditworthiness assessment and credit scoring (Annex III 5(b), with a fraud-detection carve-out) and life and health insurance risk assessment and pricing (5(c)) are high-risk uses. The Digital Omnibus deferred Annex III obligations to 2 December 2027. Deployers of these systems must also complete a fundamental rights impact assessment under Article 27.

**What does DORA require for AI vendors?**

Since 17 January 2025, EU financial entities must operate an ICT risk-management framework, keep a register of information on all ICT third-party arrangements (which includes AI and cloud providers), meet contractual requirements on audit, incidents and exit, report major ICT incidents, and run resilience testing. Critical third-party providers are overseen directly by the European Supervisory Authorities.

**Can I say "the model is too complex" in an adverse-action notice?**

No. Regulation B §1002.9 requires the specific principal reasons for an adverse credit decision regardless of model complexity, and FCRA §1681m adds notice duties when a consumer report or score is used. Reason codes must reflect how the model actually reached the decision.

## Official sources

- [Federal Reserve: SR 26-2 Model Risk Management (April 2026)](https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm)
- [Cyber Risk Institute: Financial Services AI Risk Management Framework](https://cyberriskinstitute.org/artificial-intelligence-risk-management/)
- [CFPB: Regulation B (Equal Credit Opportunity Act)](https://www.consumerfinance.gov/rules-policy/regulations/1002/)
- [CFPB: Regulation V (Fair Credit Reporting Act)](https://www.consumerfinance.gov/rules-policy/regulations/1022/)
- [OCC Bulletin 2023-17: Interagency guidance on third-party relationships](https://www.occ.gov/news-issuances/bulletins/2023/bulletin-2023-17.html)
- [NAIC: Model Bulletin on the Use of AI Systems by Insurers and adoption tracker](https://content.naic.org/insurance-topics/artificial-intelligence)
- [NY DFS: Circular Letter No. 7 (2024) on AI and external data in underwriting and pricing](https://www.dfs.ny.gov/industry-guidance/circular-letters/cl2024-07)
- [EUR-Lex: Regulation (EU) 2022/2554 — Digital Operational Resilience Act](https://eur-lex.europa.eu/eli/reg/2022/2554/oj)
- [EUR-Lex: Regulation (EU) 2024/1689 — Artificial Intelligence Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)
- [Bank of England: PRA SS1/23 Model risk management principles for banks](https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss)
- [FCA: Consumer Duty](https://www.fca.org.uk/firms/consumer-duty)
- [MAS: Artificial Intelligence Model Risk Management information paper](https://www.mas.gov.sg/publications/monographs-or-information-paper/2024/artificial-intelligence-model-risk-management)
- [BIS: BCBS 239 Principles for effective risk data aggregation and risk reporting](https://www.bis.org/publ/bcbs239.htm)
- [NIST: AI Risk Management Framework Playbook](https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook)

Public guide: https://autogovern.io/finance-ai-governance