When AI decides who gets credit, the governing framework is not NIST or the EU AI Act. It is fair-lending law — older, sharper, and enforceable in ways no AI framework is yet.
On February 19, 2026, the US Treasury published its Financial Services AI Risk Management Framework: 230 control objectives across seven domains, purpose-built for the industry. It is a genuinely good document. Within a week I watched teams across fintech start mapping their models to it, the way we all mapped to the NIST AI RMF the year before, and treat that mapping as the answer to the question every board is now asking — "how do we govern our AI?" In consumer credit, that is the wrong question. Or rather, it is the second question wearing the first one's clothes.
Because when your AI touches a credit or financial-wellness decision, the binding constraint is not the newest framework. It is a body of law that has been on the books, litigated, and enforced for half a century: the Equal Credit Opportunity Act and its Regulation B, the Fair Credit Reporting Act, the adverse-action requirements those impose, the CFPB's stated scrutiny of opaque models, and — for the banks you serve — the model-risk discipline of SR 11-7. None of it says "artificial intelligence." All of it governs your model anyway.
Here is the reframe I want to make stick. The AI-governance frameworks are voluntary, mostly aspirational, and almost entirely unlitigated. Fair-lending law is none of those things. It carries a private right of action, statutory and punitive damages, a fifty-year enforcement record, and a Justice Department that refers pattern-or-practice cases for prosecution. I run information security and platform teams in a regulated fintech that serves more than 1,500 financial institutions, and I will tell you plainly: the framework you will actually be judged against for an AI credit decision is the one that predates the phrase.
The binding constraint is older than the framework
A framework tells you to manage risk. Fair-lending law tells you, specifically, what you must be able to do — and lets a consumer sue you when you cannot. That specificity is the whole difference, and it is why I keep pulling these conversations back down from the framework to the statute.
The new instruments are real and worth reading. The Treasury RMF gives financial services a sector-specific control set. The EU AI Act's general-purpose-AI obligations switch on August 2, 2026, with fines up to three percent of global turnover. California's CCPA automated-decision rules land in January 2027 and reach any covered business making significant decisions about consumers. These matter. But notice what they are: process obligations and penalty ceilings, most of them prospective, most of them untested in a courtroom. For a US consumer lender, the nearer and sharper edge is the one that has already been drawn a thousand times. ECOA does not ask whether you documented your model. It asks whether a real person was denied credit for a reason you can defend, on a basis the law permits.
So use the frameworks as scaffolding. Map to the Treasury RMF; it is good hygiene. But understand that the frameworks inherit their teeth from the underlying law, not the other way around. When an examiner or a plaintiff's lawyer comes for your credit model, they will not ask which AI framework you adopted. They will ask why this applicant was denied, and whether the model treats a protected class worse than it treats everyone else.
Adverse action is a specific-reason requirement, not an explainability nice-to-have
Here is the requirement that quietly decides whether your model is deployable at all. When you deny credit, or offer worse terms, ECOA's Regulation B and the FCRA require you to tell the applicant the specific principal reasons why. Not a category. Not "you did not meet our credit criteria." Not "the model scored you below our threshold." A specific, accurate reason that reflects what actually drove the decision.
The CFPB put this beyond argument in 2022: a creditor cannot hide behind the complexity of an algorithm to escape the obligation to give specific and accurate reasons. "The model is a black box" is not a defense; it is an admission. If your system can produce a score but not a reason a human can stand behind, you have not built an advanced credit model. You have built a compliance liability that happens to return a number.
This is where explainability stops being a research aspiration and becomes a legal precondition. And it is more demanding than the demos suggest, because the reason has to be true. A post-hoc explainer that generates a plausible-sounding factor the model did not actually rely on is worse than no explanation — it is an inaccurate adverse-action reason, which is its own violation. What the law wants is narrow and hard: reasons that are faithful to what the model did, legible to the person receiving them, and defensible to the examiner reading them later.
A deployable adverse-action capability, in practice, has to produce all of this:
- Specific principal reasons tied to the factors that actually moved the decision, not a generic reason code pulled from a menu.
- Reasons faithful to the model — an accurate account of what the model relied on, not a persuasive story bolted on afterward that the model would not recognize.
- Reasons captured at decision time, not reconstructed months later when a complaint arrives and the model has already been retrained twice.
- Reasons a human can defend to a regulator, in plain language, without a data scientist in the room translating.
The instinct here is one I have built before, in a different context. When my team built AgentOS, our governed agent platform, the non-negotiable was an audit trail and a clean boundary between the moment a system decides and the moment it acts — capture why, at the point of decision, in a form you can produce on demand. Credit decisioning demands exactly that instinct, except the law, not an architecture review, is the thing enforcing it.
Disparate impact does not care what your model intended
Fair-lending law recognizes two ways to discriminate. Disparate treatment is intentional: you treated someone worse because of a protected characteristic. That one is easy to understand and, for a model, easy to avoid on purpose — you do not feed it race. The dangerous one is disparate impact: a facially neutral policy or model that produces a disproportionately adverse outcome for a protected class, whether or not anyone intended it.
A model has no intent. That is precisely the trap. Machine-learning models are proxy machines — give one enough features and it will reconstruct the protected characteristic you carefully left out, through zip code, through device, through the timing and pattern of transactions, through a hundred correlates you never sat down and chose. The model does not know it is redlining. It just found that the variable predicts, and the fact that it predicts because it stands in for a protected class is not a distinction the loss function can see.
Under disparate-impact analysis, a discriminatory outcome is not excused by a clean conscience. It is defensible only if the practice serves a legitimate business necessity and there is no less discriminatory alternative that meets the same need. That last clause is the one regulators are pressing hardest on now, and it is doing real work: it means the obligation is not merely to test your model for disparity, but to go looking for a fairer model that performs comparably — a less-discriminatory-alternative search — and to keep the record of having looked. If a model with similar business results and materially less disparate impact exists and you did not adopt it, the disparity is not an accident of the data. It is a choice you made.
So disparate-impact testing and the less-discriminatory-alternative search are not data-science flourishes you get to prioritize after launch. They are the governance obligation, on a schedule, with the evidence retained. The examiner's question is not "did your model perform well." It is "did you check whether it performs worse for a protected class, and if it did, what did you do about it."
SR 11-7 already told you to validate the model
If you sell into banks, as my team does, there is a document their examiners have been holding models to since 2011, long before anyone said "generative": SR 11-7, the interagency guidance on model risk management. Read it today and it is uncanny how completely it anticipated the AI-governance conversation we are all having as if it were new.
SR 11-7 requires a model inventory — every model, owned, cataloged, and risk-rated. It requires development documentation, so the model is not a folk artifact living in one engineer's head. It requires independent validation by someone who did not build the model, on a cadence. It requires ongoing monitoring for drift, because a model that was sound at launch decays as the world moves. And it requires "effective challenge" — a genuinely empowered second set of eyes with the standing to say no. That is not a description of a novel AI-governance program. It is the AI-governance program, written fifteen years ago, for a narrower class of models, by regulators who understood the failure mode perfectly.
The teams treating AI governance as greenfield are re-deriving SR 11-7 badly and slowly. The teams that already live under it have most of the scaffolding and mainly need to extend it to models that are larger, more opaque, and retrained more often. Model inventory becomes a registry that includes your AI systems. Independent validation becomes the effective-challenge function that also probes for disparate impact and adverse-action faithfulness. Ongoing monitoring becomes drift detection with a provenance trail. These are the same governance primitives I build on the security side — a registry of what exists, scoped authority, an audit trail, memory with provenance — pointed at the decisioning model instead of the agent. The discipline is old. AI just made it mandatory at a scale and a speed the 2011 authors did not have to imagine.
What to actually do Monday
Stop treating "which AI framework" as the governing question for a credit model, and start with the law that already binds it. Concretely, four moves.
Inventory every model that touches a credit, pricing, or financial-wellness decision, and treat SR 11-7 as the floor rather than a voluntary framework as the ceiling. Prove the adverse-action reason before you ship — if the model cannot produce a specific, faithful, human-legible reason at the moment it decides, it is not deployable, no matter how well it scores. Run disparate-impact testing and a less-discriminatory-alternative search on a schedule, and keep the record of having run them. And map your AI framework of choice back onto the fair-lending law it inherits its enforceability from, not the reverse — the Treasury RMF is the scaffolding, ECOA and FCRA are the load-bearing wall.
Explainability in consumer credit was never a nicety you would get to once the model was accurate enough. It is a fifty-year-old legal obligation that AI made harder to meet and impossible to avoid. Govern to the law, and the frameworks mostly take care of themselves. Govern to the framework, and the law will find you anyway — usually in the form of a denied applicant you cannot explain.
If you build or validate credit models under ECOA and SR 11-7, I want to hear where the adverse-action-faithfulness problem actually bites for you — where the model's real reasons and the reasons you can defensibly put on a notice come apart. That gap is where this gets hard, and it is the part the frameworks do not help with. Tell me in the comments.
