Model Risk Management for ML Credit Models: SR 11-7, Validation, Explainability and Monitoring (2026)

Disclaimer: this article analyses systems and governance architecture. It is not legal, regulatory, compliance or investment advice. Regulatory status changes quickly; confirm every point with counsel and the primary texts before acting.

Most engineers who build credit models have heard of SR 11-7, and many believe it is still the rulebook. It is not. On April 17, 2026, the Federal Reserve, the OCC and the FDIC jointly issued revised model risk guidance (Fed letter SR 26-2) that supersedes the 2011 letter. Yet model risk management SR 11-7 remains the vocabulary every validator, examiner and audit team still uses, because the three-part logic it established (development, validation, governance) survives in the new text and in almost every internal policy written in the last fifteen years.

That gap between the paper and the practice is where machine learning credit teams get hurt. A gradient-boosted model can be more accurate than a scorecard and still be impossible to defend, because the evidence an examiner, a fair lending officer or a consumer needs was never captured. This post separates what changed from what did not, then walks through the validation, explainability and monitoring controls an ML credit model needs, and a reference architecture for the platform that produces the evidence automatically.

What this covers: the 2026 regulatory status of SR 11-7, the governance lifecycle, ML-specific validation, adverse action reasons under ECOA and Regulation B, drift monitoring with worked PSI numbers, and a model-governance platform design.

Context and Background

SR 11-7, “Guidance on Model Risk Management,” was issued on April 4, 2011, with the OCC publishing the same text as Bulletin 2011-12. It defined a model as a quantitative method that applies statistical, economic, financial or mathematical theories to turn inputs into quantitative estimates, and it defined model risk as the potential for adverse consequences from decisions based on incorrect or misused model output. For fifteen years those two definitions shaped credit, market-risk, stress-testing and anti-money-laundering programmes at US banks.

The April 2026 revision changes the surface of that framework. According to law-firm summaries of the joint release (I have read the Fed’s SR 26-2 landing page directly, and the rest from secondary sources, so treat details as “reported”), the new guidance replaces SR 11-7 and the 2021 BSA/AML model statement, and the OCC also withdrew its 1997 credit-scoring examination bulletin and its Comptroller’s Handbook booklet. It states that it is most relevant to organisations above roughly $30 billion in assets, compared with a $1 billion mark in the old text. It narrows the definition of a model to complex quantitative methods, carving out simple arithmetic, deterministic rule processes and spreadsheets. It also says it does not set enforceable standards, while preserving enforcement for violations of law or unsafe and unsound practices.

Two items matter especially for ML credit teams. First, reports say generative and agentic AI are explicitly excluded from the guidance, with the agencies planning a request for information on AI use. A gradient-boosted credit model is not generative AI, so it presumably sits inside the definition, but I could not verify any ML-specific wording and you should read the text yourself. Second, the guidance retains the three validation components (conceptual soundness, outcomes analysis, ongoing monitoring) and a risk-based view of materiality, while softening prescriptive detail on board duties, audit tasks and organisational independence.

The lesson for practitioners is that the supervisory text got shorter, but your obligations did not. Credit decisions remain subject to the Equal Credit Opportunity Act (ECOA), the Fair Credit Reporting Act (FCRA), state law, prudential safety-and-soundness expectations, and customer litigation. Those regimes want the same evidence SR 11-7 produced: documented reasoning, tested performance, explainable outcomes and monitoring. If you also run real-time risk engines, the same governance applies to the real-time fraud detection architecture you probably operate beside your credit stack.

A note on naming. Throughout this post “SR 11-7 framework” means the lifecycle logic: inventory, development, independent validation, governance, monitoring. That logic is what the 2026 revision keeps, and it is what regulators in other jurisdictions (for instance the UK PRA’s supervisory statement SS1/23, which took effect in May 2024) also encode. Authoritative reading: the Federal Reserve SR 26-2 letter.

The Model Risk Management SR 11-7 Lifecycle, Rebuilt for ML Credit

Model risk management for credit is a closed loop with five controls: a tiered inventory that decides how much scrutiny a model gets, documented development, independent validation before use, governed deployment with limits, and ongoing monitoring that feeds back into the inventory. SR 11-7 named the pillars; SR 26-2 keeps them under a more risk-based, principles-led wording.

Figure 1: The model risk management lifecycle as a closed loop. Monitoring findings and issue logs flow back into tiering and revalidation rather than ending at deployment.

The diagram is worth reading as a data-flow, not an org chart. Each arrow is an artefact that must exist and be retrievable: the inventory record, the development document, the validation report, the approval decision, the monitoring pack and the issue log. A framework that cannot produce those artefacts on demand fails in an exam even if the model is excellent.

Inventory and tiering decide everything downstream

You cannot manage a model you have not listed. The inventory is the register of every model in use, with owner, purpose, inputs, outputs, vendor or in-house origin, tier, validation date and known limitations. For ML credit this includes the obvious application scorecard, but also the less obvious pieces: a debt-to-income estimator that uses a fitted income model, a fraud score used as a decline trigger, a line-assignment model, a collections propensity model and any vendor attribute whose derivation you do not control.

Tiering converts the inventory into a work plan. The old text did not prescribe tiers, and neither, as far as I can verify, does the new one; each bank designs its own. A defensible scheme scores two dimensions. Inherent risk captures complexity, data quality, novelty of method and opacity. Materiality captures exposure (balances decided, share of originations), purpose (does the model decide credit, price, or only prioritise a queue) and customer impact. The 2026 text reportedly frames risk this way, as inherent risk judged in the context of materiality.

A pragmatic mapping looks like this. Tier 1: the model decides approval or pricing for a major product, uses ML or third-party data, and touches protected-class risk. Tier 2: it drives limits, collections strategy or capital estimates. Tier 3: it supports internal analytics with no direct customer effect. Tier 1 gets full independent validation before launch, annual performance review and quarterly monitoring; Tier 3 gets documentation and a sanity check. The point is proportionality: spending validator time on a spreadsheet while a 600-feature boosted tree runs unreviewed is the failure the revision is trying to prevent.

The three pillars in an ML context

Development is where the evidence starts. The developer states the purpose, the target definition (for example, ever 90 days past due within 12 months), the population and exclusions, the sampling window, the feature set with business rationale, the algorithm choice and the alternatives rejected. For ML, add the hyperparameter search space, the random seeds, the early-stopping rule and the leakage checks. A model whose target window overlaps the feature window is the single most common cause of an impressive validation Gini and a disastrous production one.

Validation is a second pair of eyes with the skill and standing to say no. SR 11-7 listed conceptual soundness, outcomes analysis and ongoing monitoring as the core components, and the 2026 text keeps them. Conceptual soundness asks whether the design is justified by theory and evidence; outcomes analysis compares predictions with realised results through backtesting and benchmarking; monitoring checks that the model keeps behaving. Crucially, validation should replicate, not merely read: an independent rebuild of the training set from raw data catches more defects than a review of the developer’s notebook.

Governance assigns accountability. A model risk committee owns policy, the inventory, issue tracking and exceptions; the board or a delegated committee sees aggregate model risk and material limitations. The 2026 revision reportedly replaces detailed board and audit enumerations with higher-level principles, and de-emphasises reporting-line independence in favour of review rigour. That is a reasonable direction, but it also removes the cover that a rigid checklist gave. If a regulator asks why your Tier 1 model was approved with an open high-severity finding, “the policy did not forbid it” is not an answer.

Effective challenge is a behaviour, not a department

Effective challenge is critical analysis by objective, informed parties who can identify limitations and force change. The 2011 wording tied it to incentives, competence and influence. A reported reading of the 2026 text is: appropriate expertise, enough independence for objectivity, and the standing to effect change. The practical test is whether a validator has ever delayed a launch. If the answer for the last three years is no, the challenge function is ceremonial, whatever the org chart says.

For ML the competence bar is higher. A validator must be able to reproduce a SHAP computation, interpret a calibration plot, and understand why a tree ensemble with 400 trees can behave non-monotonically in a thin region of feature space. Teams that outsource this skill to the developers whose work is being challenged lose the point of the exercise.

Validating and Explaining a Machine Learning Credit Model

Machine learning credit scoring adds three burdens to classical validation: you must prove the model’s behaviour is stable and sensible across the feature space, you must produce specific adverse action reasons that faithfully reflect the model, and you must show that a simpler challenger does not do the job almost as well. The architecture below is built to generate all three pieces of evidence as by-products of normal operation.

Figure 2: Decision path for an ML credit model. The decline branch feeds a reason engine; a challenger scorecard runs in shadow beside the champion.

In the diagram the champion is a monotonic gradient-boosted model fed by a versioned feature store. Every decline passes through a reason engine that maps model attributions to notice reasons. A challenger, often a logistic regression scorecard, scores the same applicants in shadow so that validators can quantify what the complexity buys.

Conceptual soundness for a model nobody can write down

A scorecard can be printed on one page. A boosted ensemble cannot, so conceptual soundness shifts from reading coefficients to testing behaviour. Five tests carry most of the weight.

The first is monotonicity and sign checks. For features with an unambiguous economic direction (more delinquencies should never lower risk), constrain the learner so that the score is monotone in that feature. In XGBoost this is the monotone_constraints parameter; LightGBM exposes the equivalent monotone_constraints option. Constraints cost a little discrimination but remove the embarrassing partial-dependence dips that make a model indefensible, and they make reason codes consistent: if the score can only rise with utilisation, “high utilisation” is always a legitimate reason when utilisation is the driver.

The second is partial dependence and ICE plots across the training range, with special attention to sparse regions where a tree can extrapolate wildly. The third is sensitivity and stress testing: perturb each input by a defined amount and by a realistic joint shock (rates up, unemployment up) and check that the score distribution moves in a direction and magnitude that finance and risk can explain.

The fourth is calibration. Discrimination (ranking power) and calibration (probabilities that match observed default rates) are separate properties. A boosted tree trained with log-loss is often reasonably calibrated but can drift at the tails; validators should inspect reliability curves by decile and test whether Platt scaling or isotonic regression is applied on a held-out calibration set rather than the training set. The fifth is benchmarking against a challenger, covered below.

Performance metrics: Gini, KS and what they hide

Credit teams report the Gini coefficient, which equals 2 x AUC – 1, and the Kolmogorov-Smirnov (KS) statistic, the maximum gap between cumulative score distributions of good and bad accounts. As an illustration only (these are made-up numbers, not benchmarks): an AUC of 0.78 gives a Gini of 0.56; a challenger scorecard at 0.75 AUC gives 0.50. The six-point Gini lift is what you are buying with complexity.

Whether it is worth buying depends on money, not statistics. If the extra discrimination lets you approve an additional slice of applicants at a stable loss rate, convert it into expected loss avoided or approvals gained at the portfolio level and compare it with the governance cost of the more complex model. Many teams find the lift is concentrated in thin-file segments, which suggests a hybrid design: scorecard for the mainstream, ML for the segment where it wins, with the boundary itself documented and tested.

Aggregate metrics also hide subpopulation failure. Report Gini and calibration by vintage, channel, product and, where lawful and available through proxy methods or self-reported data, by protected-class group. A model with a healthy overall AUC that is badly mis-calibrated for young applicants is a fair lending exposure waiting to happen.

Explainability that survives an adverse action notice

Explainability in credit is not an academic nicety; it is a legal output. Under ECOA and Regulation B (12 CFR 1002.9), a creditor taking adverse action must give the applicant a statement of specific reasons. The CFPB’s Circular 2022-03 made two points that matter for ML. First, a creditor cannot defend a vague notice by pointing to model complexity: the circular says a lack of understanding of one’s own methods is not a defense. Second, the sample forms in Regulation B’s Appendix C are not a safe harbor, and a creditor cannot tick the closest listed reason if it was not the factor actually used. The circular also says that where post-hoc explanation tools approximate a model, the creditor must validate their accuracy.

What the circular does not say is how to compute reasons, so practice has converged on attribution methods. SHAP (Lundberg and Lee, “A Unified Approach to Interpreting Model Predictions,” NeurIPS 2017) assigns each feature a Shapley value representing its contribution to moving a given prediction away from the baseline. For tree ensembles, TreeSHAP computes exact attributions in polynomial time, which is why it dominates credit practice.

A worked, illustrative example. Suppose the baseline (average applicant) log-odds of default is -2.40 and an applicant’s log-odds is -1.10, so the model score is above the cutoff and the applicant is declined. The SHAP values explain the +1.30 move: revolving utilisation +0.62, recent delinquencies +0.41, length of credit history +0.19, inquiries in six months +0.12, income verification gap -0.04 (a protective factor). Sorted by contribution, the top four positive drivers become candidate reasons. Four is common because the FCRA requires a credit score disclosure to include up to four key factors (five if inquiries are a factor), and many lenders align ECOA reasons to the same number; confirm your own legal reading.

Three engineering problems then appear. One is reference choice: Shapley attributions depend on the baseline, and “average applicant” is a different thing from “average approved applicant” or “the cutoff-score applicant.” Pick one, document it and test that reasons change sensibly when it does. Another is correlated features: when utilisation on cards and total revolving utilisation are both inputs, attribution splits arbitrarily between them. Group correlated features into reason families before ranking, so the notice says “level of revolving credit usage” rather than flipping between two near-duplicate items. The last is fidelity: reasons should be consistent with a counterfactual. If the notice says utilisation was the principal reason, lowering utilisation to a typical level should plausibly flip the decision. Test that on a sample, and log the results as the validation evidence the circular implies.

Here is a compact reference pattern for the reason engine and the monotonic training step (illustrative, not production code).

import numpy as np, shap, xgboost as xgb

# +1 means score may only rise with feature, 0 unconstrained
mono = {"utilisation": 1, "delinq_24m": 1, "history_months": -1,
        "inquiries_6m": 1, "income_gap": 0}
cols = list(mono)
params = {"objective": "binary:logistic", "max_depth": 4,
          "eta": 0.05, "subsample": 0.8, "seed": 7,
          "monotone_constraints": "(" + ",".join(str(mono[c]) for c in cols) + ")"}
model = xgb.train(params, xgb.DMatrix(X_train[cols], y_train), 400)

explainer = shap.TreeExplainer(model, data=X_ref[cols],
                               feature_perturbation="interventional",
                               model_output="raw")
families = {"utilisation": "REVOLVING_USE", "delinq_24m": "DELINQUENCY",
            "history_months": "HISTORY_LENGTH", "inquiries_6m": "INQUIRIES",
            "income_gap": "INCOME"}

def reasons(x_row, k=4):
    sv = explainer.shap_values(x_row[cols])[0]
    agg = {}
    for c, v in zip(cols, sv):
        agg[families[c]] = agg.get(families[c], 0.0) + v   # sum within family
    top = sorted((kv for kv in agg.items() if kv[1] > 0),
                 key=lambda kv: -kv[1])[:k]
    return [name for name, _ in top]

The interventional option with a fixed reference set makes the baseline an explicit, versionable choice rather than an accident of the training data. Store the reference-set hash in the decision log beside the reason codes, so a notice sent eight months ago can be reproduced exactly.

Fairness testing and the 2026 legal shift

Fairness testing is where the 2026 environment is most confusing, so it is worth being precise. On April 22, 2026, the CFPB published a final rule amending Regulation B that removes the “effects test” and states that ECOA does not recognise disparate-impact liability; it took effect July 21, 2026, adopting the November 2025 proposal without changes. Reports describe a lawsuit by fair-lending groups challenging it, and the court schedule had not resolved the matter as of the most recent reporting I found, so treat the status as live.

Even if the rule stands, it does not make fairness testing optional engineering hygiene. Disparate treatment, including the intentional use of facially neutral proxies, remains prohibited. The Fair Housing Act’s disparate-impact liability, state laws and private ECOA claims remain sources of effects-based risk, according to law-firm reporting. Prudential regulators’ fair lending exam procedures remain in force, and a model that behaves like a proxy for a protected attribute is a bad outcome whatever the legal theory. My analytic position (opinion, not legal advice): keep running approval-ratio, pricing-gap and score-distribution tests and the search for less discriminatory alternatives, because the cost of the tests is small and the cost of an unexplained disparity is large. Document the legal basis for each test so it can be tuned as the law settles.

A practical battery: adverse-impact ratio of approval rates against the most-favoured group (the long-standing four-fifths heuristic is a screening convention, not a legal threshold), standardised mean differences in score, calibration by group, and a search over feature subsets and regularisation that checks whether a candidate with similar accuracy and a smaller disparity exists. If it does, record why you did not choose it.

Challenger models as an evidence machine

A challenger is a second model scoring the same population without driving decisions. It earns its keep in three ways. It benchmarks the champion’s performance, as discussed above. It acts as a drift sentinel: when champion and challenger rank-correlation drops sharply, something has changed in the data. And it is the foundation of the less-discriminatory-alternative search. The cost is compute and feature-pipeline discipline: both models must read the same versioned features at the same point in time, or the comparison is meaningless.

Monitoring: PSI, KS and Gini Drift in Production

Ongoing monitoring answers one question every day: is the model still operating in the world it was built for? Three signal families do the job. Input drift measures whether the applicant population or feature distributions have moved, typically with the Population Stability Index (PSI). Performance drift measures whether ranking power (KS, Gini) and calibration have degraded once outcomes mature. Outcome-fairness drift watches approval ratios and score distributions across groups.

Figure 3: Monitoring pipeline. Three metric families feed one threshold engine that routes to a quarterly report, analyst review or escalation and revalidation.

PSI by hand

PSI compares a recent distribution with a reference (usually the development sample). Bin a variable or the score into buckets, then compute the sum over bins of (actual share – expected share) multiplied by ln(actual share / expected share). Each term is non-negative, so PSI is zero only when the distributions match.

An illustrative example with five equal-population score bands in development (20% each). In production this quarter the shares are 14%, 18%, 20%, 22% and 26%, shifting mass toward the safer bands. The PSI works out to roughly 0.041. Next, suppose a marketing push brings in a very different applicant mix and the shares become 8%, 14%, 20%, 26% and 32%. The PSI is roughly 0.203. Both figures are calculated from those made-up shares and are not from any real portfolio.

The common rules of thumb read below 0.10 as stable, 0.10 to 0.25 as moderate shift needing a look, and above 0.25 as significant change. These cut-offs are industry convention, not regulatory thresholds, and I am not aware of an official source for them. Treat them as starting values, then calibrate to your own volume: with 500 applications a quarter, PSI is noisy; with 500,000 it will flag shifts too small to matter economically.

import numpy as np

def psi(expected, actual, bins=10, eps=1e-6):
    # quantile bins from the development sample, fixed once and versioned
    edges = np.quantile(expected, np.linspace(0, 1, bins + 1))
    edges[0], edges[-1] = -np.inf, np.inf
    e = np.histogram(expected, edges)[0] / len(expected)
    a = np.histogram(actual, edges)[0] / len(actual)
    e, a = np.clip(e, eps, None), np.clip(a, eps, None)
    return float(np.sum((a - e) * np.log(a / e)))

Fix the bin edges at development time and store them with the model version. Re-deriving edges from each new sample makes PSI look permanently stable, which is exactly the wrong failure mode.

Performance drift has a lag problem

Input drift is available instantly; performance drift is not. A 12-month default definition means you will not know the true Gini of this month’s approvals for a year. The fix is a layered signal: early-delinquency indicators (first-payment default, 30 days past due at month 3) as leading proxies; vintage curves that compare each cohort with the expected curve at the same age; and the champion-challenger gap as a real-time sanity check. Define in advance which proxy triggers which action, and what size of Gini decline (for example, a drop of more than a few points against the validation baseline, confidence-adjusted for sample size) causes a mandatory revalidation.

KS and Gini also change for reasons unrelated to model decay. A tightened cutoff narrows the approved population, mechanically reducing observed discrimination because the easy rejects are gone. Always compute performance on the through-the-door population where outcomes are observable (via reject inference or a small random-approval holdout, if policy and law allow it), or at least report both the approved-only and the reweighted figures.

Thresholds, escalation and the closed loop

The threshold engine in Figure 3 should be boring. Green means the metrics sit inside limits and the result goes into the quarterly pack. Amber means an analyst must explain the movement within a stated period. Red means the owner must act: restrict use, add a manual overlay, recalibrate, or retrain, followed by a revalidation proportionate to the change. Recalibrating the intercept is a different change from retraining on new features, and policy should say which needs full validation and which needs a lighter confirmation.

Retraining deserves its own gate. Automated retraining pipelines are attractive and dangerous: a new model is a new model, with fresh conceptual soundness, new reason-code behaviour and new fairness properties. A defensible pattern is automated candidate generation, automated test battery, human sign-off by an independent validator, and a canary release with the previous model kept as fallback.

Architecture of a Model-Governance Platform

The central design idea: governance evidence should be a by-product of the pipeline, not a document written afterwards. If code, data, parameters and metrics are captured automatically and linked to the inventory record, a validator spends time on judgement instead of archaeology, and an examiner request becomes a query.

Figure 4: A model-governance platform. The registry is the hub: it joins source, data and runs, feeds the validation workbench and receives monitoring results back.

Components and what each must record

The model registry and lineage store is the system of record. Each registered version holds the Git commit hash, container image digest, dependency lockfile, training-data snapshot identifier and content hash, feature definitions, hyperparameters, seeds, metrics and the inventory ID. Open-source registries such as MLflow provide a starting point; the governance layer on top adds tier, owner, approval state and expiry.

The data snapshot service freezes training and validation extracts with hashes, so a validation replicated six months later uses identical rows. The validation workbench runs the standard battery (back-tests, stability, monotonicity, calibration, fairness, challenger comparison, reason-code fidelity) in a clean environment and emits a signed evidence package. Using the same library of tests for every model makes validation comparable across the portfolio and prevents cherry-picking.

The approval workflow encodes tier-based gates: who must sign, what findings must be closed, which limitations must be attached to the decision engine as use restrictions. The serving layer logs each decision with model version, feature vector hash, score, cutoff, reason codes and reference-set version. The monitoring store receives those logs plus matured outcomes and computes the Figure 3 metrics. The inventory and audit views read from the registry rather than a manually maintained spreadsheet; the 2026 definitional narrowing is a good prompt to retire spreadsheets-as-inventory in any case.

Capacity and cost, in orders of magnitude

Consider an illustrative lender making 2 million decisions a month. Logging a 300-feature vector at about 2 KB per decision, plus score and reasons, yields roughly 4 to 5 GB a month of raw decision logs. That is trivial storage; what costs money is retention (ECOA creditor record retention is generally 25 months for consumer credit applications under Regulation B, so verify your product) and the compute for monthly PSI across hundreds of features and dozens of segments. Both are modest next to the cost of one failed exam or one remediation project. The expensive resource is validator time, which is why automating the repeatable test battery pays back quickly.

Where it connects to the rest of the stack

Credit models rarely stand alone. The decisioning engine that calls them, including the policy rules, cutoffs and pricing logic, is the subject of our credit decisioning architecture for BNPL underwriting; every model there needs an inventory entry and a use restriction attached at the decision node. Risk signals from onboarding and ongoing due diligence, such as those produced by perpetual KYC architecture, often feed credit and fraud features, so their drift is your drift. Treat upstream score providers as vendor models: under both the old and new guidance a bank remains responsible for understanding and documenting the limits of a third-party model even when the vendor will not share internals, and customised vendor models require documented justification of the adjustments.

Trade-offs, Gotchas, and What Goes Wrong

Treating a shorter rulebook as a lighter obligation. SR 26-2 is reported to be non-enforceable guidance with a higher asset-size focus, and some teams read that as permission to cut validation. But fair lending law, FCRA, safety-and-soundness authority, state regulators, investors, bank partners and plaintiffs have not gone away. A fintech lender working through a sponsor bank will usually find the bank’s third-party risk programme demands the old evidence regardless of the new text.

Explanations that do not match the model. The classic failure is a reason engine built from a surrogate (a logistic regression fitted to the boosted model’s outputs) whose reasons agree with the real model perhaps 80% of the time. The other 20% of notices state reasons that were not the actual drivers, which is the exact defect Circular 2022-03 warns about. Compute reasons from the deployed model, and measure fidelity.

Monotone constraints that hide a data problem. Forcing a sign can mask a real interaction (for example, high inquiries with a long history may not mean what high inquiries with a thin file means). Constraints are a governance device, not a free lunch; review what accuracy they cost by segment.

Leakage and label shift. Features computed after the decision date, or bureau attributes refreshed retroactively, inflate development metrics. Point-in-time correctness in the feature store is a validation requirement, not an engineering nicety. Equally, a macro regime change breaks the link between features and default; no monitoring statistic cures that, only judgement and overlays.

Selection bias. You observe outcomes only for approved applicants. Training and validating on the approved set bakes in the previous policy. Reject inference methods help but are assumptions; a small controlled test-and-learn allocation is better where legal and ethically acceptable.

Alert fatigue. A PSI alert on 400 features every week trains analysts to ignore them. Alert on the score, on the top reason-code features by importance, and on any feature with a business-critical role; keep the rest in a dashboard.

Vendor opacity. If a bureau score is a decline trigger, you cannot SHAP it. Document its role, benchmark its stability, and ensure the notice uses the reasons the vendor supplies, with your own checks on consistency.

Regional divergence. The EU AI Act classifies creditworthiness assessment of natural persons as high-risk (Annex III). The AI Omnibus, reported as published on July 24, 2026 and in force from July 27, moves stand-alone Annex III obligations from August 2026 to December 2, 2027. UK banks follow PRA SS1/23. A global lender therefore keeps the strictest common evidence set rather than building per-country pipelines.

Practical Recommendations

Start by reconciling your policies with the actual state of play. Update internal documents that cite SR 11-7 to reference SR 26-2 and your own principles, and have legal confirm which parts of your programme rest on law and contract rather than guidance. Do not delete controls merely because the new text is less prescriptive; remove them only after a documented risk assessment.

Next, make the platform produce the evidence. Version everything that can change a decision, log every decision with enough context to reproduce its reasons, and make the validation battery a pipeline stage, not a project. Keep the champion honest with a challenger, and let validation see the challenger gap.

Finally, align roles. Developers own the development document and the reason-code logic; validators own independent replication and a veto; the compliance function owns the fair lending legal basis and notice content; operations own the monitoring runbook. Publish the thresholds in advance so that an amber result triggers a defined action rather than a debate.

A short checklist for a Tier 1 ML credit model:

• Inventory entry with owner, tier, purpose, use restrictions and expiry date.
• Reproducible build: commit, image digest, data hash, seeds, feature definitions.
• Monotonic constraints or documented behavioural tests for each key feature.
• Out-of-time test and calibration check, plus challenger comparison with money-denominated lift.
• Reason engine computed from the deployed model, with fidelity test on a sample and a documented baseline.
• Fairness battery with documented legal basis and a less-discriminatory-alternative search log.
• Monitoring with fixed PSI bins, leading-indicator proxies, thresholds and owners.
• Defined triggers for recalibration, retraining and revalidation.
• Decision log retention matched to the longest applicable record-keeping rule.

Frequently Asked Questions

Is SR 11-7 still in effect in 2026?

No. On April 17, 2026 the Federal Reserve, OCC and FDIC issued revised model risk management guidance (SR 26-2) that supersedes SR 11-7 and the 2021 BSA/AML model statement. The core structure of development, validation, governance and monitoring carries over, so many institutions still use SR 11-7 language internally. Confirm applicability and any transition expectations against the primary text and your supervisor’s messages.

Do machine learning credit models fall under model risk management?

Generally yes. A trained statistical or ML model that produces credit estimates fits any reasonable reading of “model,” and the revised guidance reportedly excludes only generative and agentic AI and simple deterministic tools, while a federal AI request for information is planned. Even if a model fell outside the formal definition, ECOA, FCRA and fair lending law would still require tested, explainable and monitored decisions, so most banks keep ML models in scope.

How do you explain an ML credit decision to satisfy adverse action rules?

Compute attributions from the deployed model, for tree ensembles typically with TreeSHAP against a documented baseline, then group correlated features into reason families and rank the positive contributors to the decline. Map them to specific, accurate notice reasons rather than the nearest checklist item, as CFPB Circular 2022-03 requires. Validate the explanation method, because the circular says approximations of the model must be checked for accuracy.

What is a good PSI threshold for credit model monitoring?

The common convention is below 0.10 stable, 0.10 to 0.25 worth investigating, and above 0.25 significant. These are industry rules of thumb, not regulatory limits. Calibrate them to portfolio volume, since small samples produce noisy PSI, and apply them to the score and key features with fixed development-time bins. Pair PSI with performance and fairness metrics, because a stable distribution can still hide worsening ranking power.

How often should an ML credit model be validated?

Validation happens before deployment, then at a frequency that follows risk. A typical programme gives a Tier 1 model a full revalidation on a periodic cycle (annually or biennially depending on policy) plus event-driven revalidation after material changes, performance breaches or population shifts. Monitoring runs continuously in between. The 2026 guidance reportedly favours risk-based timing over fixed default cycles, so document your rationale.

Does the Regulation B change remove the need for fairness testing?

No. The CFPB’s final rule, effective July 21, 2026, eliminates the effects test under ECOA, but disparate treatment, including intentional use of proxies, stays prohibited, and the Fair Housing Act, state laws and private claims can still carry effects-based risk. The rule also faces litigation. Most governance teams keep fairness testing and alternative-search documentation, adjusting the legal framing with counsel rather than dropping the controls.

Further Reading

Related posts on this site:

• Credit decisioning architecture for BNPL underwriting engines – where the models sit in the real-time decision path.
• Real-time fraud detection architecture – a sibling high-stakes model stack with the same governance needs.
• Perpetual KYC architecture for continuous risk – upstream risk signals that become model inputs.

Primary sources:

• Federal Reserve SR 26-2, Revised Guidance on Model Risk Management
• CFPB Circular 2022-03, adverse action notification for credit decisions based on complex algorithms
• Lundberg and Lee, “A Unified Approach to Interpreting Model Predictions,” NeurIPS 2017 (arXiv:1705.07874)

By Riju — about