Model risk discipline
Inventory every model and AI system, tier it by materiality, validate it independently, monitor it continuously and revalidate on change.
AUTOGOVERN FINANCE · FREE PUBLIC LEARNING
Finance AI governance,
from model risk to customer outcome.
Learn how to inventory and tier models, trace the data behind them, review vendors, validate for soundness and fairness, approve a controlled release and keep monitoring — in the language of SR 26-2, Regulation B, DORA, the EU AI Act and the FCA Consumer Duty.
EXPLORE THE FULL PLATFORM DESIGN
Financial Services AI Architecture & Model Risk
A dedicated 18-section reference report covering the decisioning platform, its data lineage, model risk management, fair lending, DORA resilience and the work needed to operate it.
01 / PLATFORM ARCHITECTURE
Design the decisioning platform
Business modules, trust zones, lineage, bureau and payment integrations, decision engine and event flows.
02 / MODEL RISK & FAIR LENDINGDefine the controls
Inventory, tiering, independent validation, adverse-action explainability, DORA third parties and monitoring.
03 / IMPLEMENTATION ROADMAPUnderstand the work ahead
Current capabilities, proposed additions, delivery phases and effort estimates.
01 / UNDERSTAND THE SCOPE
Govern the model, the data and the customer decision.
Finance AI governance assigns responsibility for what a model or AI system is allowed to decide, the evidence required before it decides anything, and what happens when its behaviour, data or the rules change. Model risk, fair lending, consumer protection, third-party risk, operational resilience and market conduct all belong in the review — and most of them predate AI.
Customer outcomes and fairness
Prove decisions are not discriminatory, give specific reasons for adverse decisions, and design for good outcomes rather than average accuracy.
Resilience and accountability
Keep third parties, data lineage, incidents, approvals and monitoring connected to the exact model version a supervisor will ask about.
| Term | Meaning for your review |
|---|---|
| Model vs. AI system | SR 26-2 defines a model as a quantitative method that applies theory or assumptions to inputs to produce estimates, including supervised machine learning. Generative and agentic AI are outside SR 26-2 but still need to be inventoried and governed under other expectations. |
| Materiality tier | A rating from impact if the model is wrong and how much is exposed. Tier sets validation depth, monitoring frequency and approval level; it must be explainable to an examiner. |
| Independent validation and effective challenge | Review by people outside development with the competence, authority and incentives to reject the model: conceptual soundness, outcomes analysis and ongoing-monitoring design. |
| Adverse action | A decision to deny, terminate, or offer less favourable terms. Regulation B §1002.9 requires the specific principal reasons; FCRA §1681m adds notice duties when a consumer report or score is used. |
| Disparate treatment vs. disparate impact | Treatment: using a prohibited basis or proxy to decide. Impact: a neutral practice with a disproportionate effect. The ECOA effects test was removed in July 2026 (contested); impact remains live under the Fair Housing Act, DOJ, state law and insurance regimes. |
| Consumer report | Information from a consumer reporting agency used for credit, insurance or employment eligibility. AI-derived scores can be consumer reports, triggering permissible-purpose, accuracy and dispute duties. |
| ICT third party (DORA) | Any provider of ICT services to an EU financial entity, including AI and cloud providers. Must appear in the register of information with the required contractual terms. |
| FRIA | The fundamental rights impact assessment that EU AI Act Article 27 requires from deployers of high-risk systems such as credit scoring and life/health insurance pricing. |
Scope references: SR 26-2; Regulation B; EU AI Act.
This is an educational starting point across US, EU, UK and selected APAC regimes. Entity type, size, products and state law add obligations. The how-tos are AutoGovern's suggested workflow, not a certification checklist, a model validation or regulatory approval.
02 / PUT IT INTO PRACTICE
Finance AI governance how-tos
Use these steps with your existing approved tools or the free templates below. Each step names a responsible team and the record it should produce.
01
Register and tier a model or AI system
Start with one decision: a credit score, a pricing model, a fraud alert or a customer-facing assistant. Record what it decides, who is affected and how wrong it can be before you decide how much validation it needs.
- 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.
- 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.
- 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.
- 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.
What to produce: An inventory record with purpose, type, tier, owners, version and a dated validation plan.
02
Map data, lineage and consumer-report use
Follow every input from its golden source to the decision record. A feature that cannot be traced cannot be validated, explained in an adverse-action notice or corrected after a dispute.
- 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.
- 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.
- 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.
- 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.
What to produce: A reviewed lineage register with data classes, permissible-purpose rationale, quality controls and retention decisions.
03
Review a vendor model or AI third party
Model risk is not outsourced. A vendor score, a cloud inference endpoint or an external data source is subject to the same validation expectations, with the added difficulty that you may not see inside it.
- 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.
- 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.
- 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.
- 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.
What to produce: A service-specific third-party decision with contract evidence, validation approach, criticality, exit plan and a review date.
04
Validate: conceptual soundness, outcomes, fairness and explainability
Define acceptance limits before you look at results. Validation asks whether the model is fit for its purpose, not whether it is accurate on average.
- 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.
- 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.
- 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.
- 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.
- 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.
What to produce: A versioned validation report with scope, methods, results, fairness and explainability evidence, findings and an independent conclusion.
05
Approve a controlled deployment with consumer safeguards
Make the approval specific enough that another team can see exactly what was authorised, for which customers, with which safeguards, and until when.
- 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.
- 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.
- 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.
- 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.
- 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.
What to produce: A dated release decision naming the approved version, scope, conditions, safeguards, fallback owner, expiry and revalidation triggers.
06
Monitor performance, drift, fairness and incidents
Specify each signal, its source, denominator, threshold and response. A dashboard with no data behind it is silence, not assurance.
- 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.
- 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.
- 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.
- 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.
- 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.
What to produce: A monitoring plan per model, incident runbook with reporting deadlines, and a record of revalidation decisions.
03 / SEE THE REVIEW IN CONTEXT
Three finance AI examples
Illustrative scenarios to adapt to your use case. These are not customer records, validated models or customer assessments.
Credit decisioning model
Purpose: Score consumer loan applications and support approve / decline / counter-offer decisions.
Risk: Unlawful disparate treatment or unexplained proxies, inaccurate adverse-action reasons, drift after a change in applicant mix, and reliance on consumer-report data without permissible purpose.
Controls to consider: Independent validation with outcomes analysis by segment; fair-lending testing including proxies; verified reason-code generation; FCRA notices; human review of declines near threshold; decision records with input snapshots.
Evidence: Validation report with fairness and explainability sections, reason-code stability tests, dispute-handling records and monitoring with denominators.
Insurance underwriting and pricing with external data
Purpose: Use external consumer data and a machine-learning model to underwrite or price life or property coverage.
Risk: Unfair discrimination through external data proxies, opaque pricing factors, state-specific testing duties and inaccurate data driving adverse decisions.
Controls to consider: Written AI Systems Program (NAIC bulletin states); quantitative proxy and bias testing (NY DFS Circular 7, Colorado SB 21-169); actuarial model governance under ASOP 56; data-vendor due diligence; disclosure and appeal routes.
Evidence: Proxy-testing results by protected class, actuarial review, vendor data-quality evidence, filed attestations where required and consumer-notice samples.
Customer-facing generative assistant at a bank
Purpose: Answer servicing questions, explain products and route customers to staff.
Risk: Misleading product or fee information, unsuitable steering, missed vulnerability signals, prompt injection, data leakage and marketing claims the system cannot support.
Controls to consider: Bounded topics with approved sources; escalation to a person; Consumer Duty foreseeable-harm assessment and UDAAP review; adversarial testing; disclosure that a customer is speaking to AI; recordkeeping of interactions. Outside SR 26-2 scope, but still inventoried and governed.
Evidence: Accuracy and harm test results, escalation drills, injection and leakage tests, complaint monitoring and a signed conduct review.
04 / TAKE A STARTING POINT
Free templates you can use today
Expand a template to see every field. Download the complete Markdown kit to edit in your own document system. No upload, registration or email is needed.
Model inventory and tiering recordView template +
- 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 reportView template +
- 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 reviewView template +
- 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 entryView template +
- 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]
05 / QUESTIONS EXAMINERS ASK
Straight answers to the questions that decide scope.
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.
06 / MAKE A MANAGEABLE START
Your first 30 days
A suggested planning cadence, not a regulatory deadline or a promise that a model will be ready for production.
Inventory and tier
List models and AI in use, assign owners, tier by materiality and identify the regimes that apply to each.
Data and third parties
Trace lineage for one decision, classify consumer-report and special-category data, and review the vendors behind it.
Validation and fairness
Set acceptance limits, review validation and fairness evidence, and verify adverse-action reason codes.
Release and monitoring
Record the release or hold decision, safeguards, monitoring plan and next review. Hold when evidence is insufficient.
WHEN YOU NEED A SHARED WORKSPACE
Keep your team's governance records together.
The Finance Governance workspace supports use cases, a model inventory with tiering, validations, fair-lending reviews, third parties, data flows, risks, control tests, releases, monitoring plans and independent domain reviews with a signed-off dossier export. Sign-in is required for saved organization records. The public guide and starter kit above remain free without an account.
07 / CHECK THE PRIMARY GUIDANCE
Official sources and further reading
Source review: . Check current requirements for your entity type, products and jurisdiction before making a formal decision.
- Federal Reserve: SR 26-2 Model Risk Management (April 2026) ↗
- Cyber Risk Institute: Financial Services AI Risk Management Framework ↗
- CFPB: Regulation B (Equal Credit Opportunity Act) ↗
- CFPB: Regulation V (Fair Credit Reporting Act) ↗
- OCC Bulletin 2023-17: Interagency guidance on third-party relationships ↗
- NAIC: Model Bulletin on the Use of AI Systems by Insurers and adoption tracker ↗
- NY DFS: Circular Letter No. 7 (2024) on AI and external data in underwriting and pricing ↗
- EUR-Lex: Regulation (EU) 2022/2554 — Digital Operational Resilience Act ↗
- EUR-Lex: Regulation (EU) 2024/1689 — Artificial Intelligence Act ↗
- Bank of England: PRA SS1/23 Model risk management principles for banks ↗
- FCA: Consumer Duty ↗
- MAS: Artificial Intelligence Model Risk Management information paper ↗
- BIS: BCBS 239 Principles for effective risk data aggregation and risk reporting ↗
- NIST: AI Risk Management Framework Playbook ↗