SR 11-7 and AI Models in Private Credit: A Model-Risk Guide

1. The Guidance That Runs Model Risk

There is a short document that quietly governs how serious lenders think about models. It is called SR 11-7, its formal name is Supervisory Guidance on Model Risk Management, and the Federal Reserve and the OCC issued it in 2011. The FDIC adopted the same standard in 2017.

It was written well before anyone was putting a large language model near a credit file. That is exactly why it has aged well. It is principles-based, not a checklist tied to a technology, so it applies just as cleanly to an AI risk model as it did to a spreadsheet regression.

Its central idea fits in a sentence. A model produces a number, someone acts on that number, and model risk is the chance the number is wrong or the chance a sound number is used the wrong way. Both of those failures are live the moment AI starts touching your underwriting.

2. It Was Written for Banks. Why It Reached You.

Be precise about who SR 11-7 binds. It is supervisory guidance for banking organizations regulated by the Fed and the OCC. A private credit fund, a business development company, or an independent direct lender is not a bank, and no examiner is going to hold you to SR 11-7 by its letter.

It reaches you anyway, through the people you answer to. Your warehouse lenders and bank counterparties expect the firms they finance to manage model risk. LPs, many of them pensions, insurers, and banks, now ask about model governance in operational due diligence. Insurance-affiliated capital carries its own model expectations into the room. None of that is optional in the way a regulation is, but all of it is real.

So adopting SR 11-7 is a choice, and a shrewd one. It lets you answer a diligence question in the vocabulary the person asking already uses. It sits naturally alongside the discipline in our private credit guide and the examiner-facing posture in AI governance and SEC exam readiness. You are not pretending to be a bank. You are borrowing the best model-risk thinking that exists.

3. What SR 11-7 Means by a Model

The definition matters, because it decides what you actually have to govern. SR 11-7 describes a model as a quantitative method that turns input data into a quantitative estimate. Think of three parts: the inputs, the processing that acts on them, and a reported output that a person or a system then relies on. In a lending context the inputs are the borrower's financials and the deal terms, the processing is whatever logic turns them into a score, and the output is the rating or the pricing signal that lands in the credit memo.

The reported output is the part that creates the risk. A number that just sits there is harmless. A number that sets a price, ranks a deal, or feeds a covenant calculation is a number someone is about to act on, and if it is wrong, the loan is mispriced or misstructured before anyone notices.

SR 11-7 names two sources of that risk, and both apply to AI. The model can be fundamentally wrong, producing inaccurate outputs from bad design or bad data. Or a perfectly sound model can be used outside its purpose, trusted for a job it was never built to do. An AI that spreads borrower financials, the front of the underwriting workflow, can fail either way: a wrong extraction, or a right extraction leaned on for a judgment it cannot make.

4. Model or Tool? The Line That Sets the Rules

This is the most useful question you can ask about any AI in your shop, and most firms never ask it. Is this thing a model or a tool?

A model produces a number that drives a decision. A tool drafts text a person reads and checks. The distinction is not about how advanced the technology is. The same language model is either one depending on how you wire it. Point it at a credit file and let its score rank or approve, and you have built a model, whether you meant to or not. Point it at the same file and have a person verify every figure and own the output, and you have a tool with a human control in front of it.

Govern by what the output does, not by how impressive the technology sounds. Most of the AI a lending team touches, drafting memos, summarizing a data room, reading a sector, sits on the tool side, and the sensible controls there are lighter: an approved-tool list and a verification habit, the kind of choices in the best AI tools for private credit. The small number of uses that cross into producing a decision-driving number are where SR 11-7 earns its keep.

5. Start With an Inventory

You cannot govern what you have not listed. SR 11-7 expects a model inventory, and building yours is the first hour of work and the most clarifying. List every model in use, in development, or recently retired, with an owner, a purpose, its inputs, and a note on how much rides on it.

The exercise almost always surprises people. AI has a way of creeping into decisions nobody logged: a spreadsheet macro that calls an API, a scoring prompt an analyst built and shared, a vendor feature switched on last quarter. Until it is on the list, it is running unwatched.

Then rank the list by materiality, because that is what tells you where to spend your attention. Materiality here is just the honest answer to one question: if this model were quietly wrong for a month, how much money or credibility is at risk. A model that sets pricing or a risk rating outranks one that sorts your inbox by a mile. The inventory is not paperwork for its own sake. It is the map that keeps the rest of the framework proportionate, so you challenge the models that can hurt you and leave the trivial ones alone.

6. Validation and Effective Challenge

Validation is the set of checks that confirm a model does what it claims. SR 11-7 frames it in three parts, and they translate straight to an AI credit model. Is the design conceptually sound, meaning does the approach make sense for the job. Is it still working, through ongoing monitoring. And do its outputs actually match reality, tested against real outcomes.

The third check, testing outputs against real outcomes, is the one that gets awkward with AI, and it is worth being honest about it. A default model can be back-tested against loans that did or did not default. A model drafting a rating rationale often has no clean numeric outcome to score against, so conceptual soundness and steady monitoring have to carry more of the weight. That is not a reason to skip validation. It is a reason to lean on the parts of it that do work.

Underneath all three sits the idea that is the heart of the whole guidance: effective challenge. It means critical review by someone competent, independent of the people who built and use the model, and empowered to force a change. For an AI model that means the person kicking the tires is not the analyst who wrote the prompt, and that person can actually turn the thing off.

The hard part is never the math. It is the independence and the authority. A review by the model's own author is a rubber stamp. A challenge with no power to change anything is theater. If you take one thing from SR 11-7 into your firm, take this: someone who did not build the model has to be able to break it and stop it.

7. Documentation That Outlives the Author

SR 11-7 sets a documentation test that is simple and unforgiving. A competent stranger should be able to pick up the file and understand how the model works, what it assumes, and where it breaks. Write it so the knowledge survives the person.

If the only human who truly understands your AI risk model is the analyst who built it, you do not have a model, you have a dependency with a resignation risk attached. Document the inputs, the logic, the known weaknesses, and, just as important, what the model must not be used for. The limits are the part people skip and the part that saves you.

This is also the file an examiner or an LP's operational due diligence team will ask to see, so it does double duty. The data-handling and vendor side of that record lives in our AI security and data governance guide. Good documentation is not bureaucracy. It is the difference between a model you own and one that owns you.

8. Ongoing Monitoring

A model is not validated once and trusted forever. Models drift. The data shifts, the market turns, a prompt that worked in a calm quarter degrades in a volatile one, and the outputs slide away from reality while everyone assumes they are fine.

AI adds a drift the old model-risk world never had. Your provider can update the model underneath you. A new version ships, the behavior moves, and your outputs change without a single edit on your side. That is easy to miss precisely because nothing in your own process changed. Monitoring has to watch for it.

In practice, monitoring is a schedule and a trigger. Scheduled checks that outputs still track real outcomes, and a defined trigger to revalidate when the world moves or the vendor pushes a change. For a material model that can be a quarterly review with a short exception log, plus an immediate recheck any time the provider announces a new model version. This is the same discipline that runs a live loan book, which is why it fits alongside covenant monitoring with Claude and a broader portfolio risk monitoring program. A model you are not watching is a model you are trusting on faith.

9. Governance and Roles

Governance answers one blunt question: who is accountable when the model is wrong. SR 11-7 splits the roles so the answer is never nobody. Owners who use the model, developers who build it, validators who challenge it, and senior leadership that sets the policy and carries the risk.

The separation is the whole point. The builder cannot be the only checker, and the person who benefits from the model saying yes cannot be the person who decides whether to trust it. That is not an insult to anyone's integrity. It is just how you keep an honest incentive in the room.

A lean private credit firm does not need a model-risk department to honor this. You need named roles, a short written policy, and one person with genuine authority to halt a model. That is the practical core of an AI governance program, and it is far more about clear accountability than about headcount.

Senior leadership does not have to meet weekly to own this. What they have to do is set the policy, know which models are material, and be the ones who answer for the risk. A quarterly sign-off is enough for most firms, as long as it is a real review and not a signature on a page nobody read.

10. A Proportionate Framework, Not a Bank's

Here is the judgment that keeps this sane. You are not a bank, and you should not build a bank's model-risk apparatus. SR 11-7 is principles-based and scales with risk on purpose. The rigor is supposed to match the stakes, not max out for its own sake.

For most credit managers, a defensible framework is smaller than it sounds. A short written policy. A one-page inventory ranked by materiality. An independent checker for the models that actually drive decisions. A monitoring calendar with a trigger. That is genuinely enough to answer an LP, satisfy a counterparty, and, more to the point, catch a bad number before it prices a loan.

The mistake runs in both directions. One is ignoring model risk because no regulator is forcing your hand, right up until a mispriced credit or an awkward diligence meeting forces it for you. The other is importing a bank's full machinery you have no capacity to sustain, so it lapses within a year. Proportionate and maintained beats elaborate and abandoned, every time.

11. Where to Start

Do it in the order that builds on itself. Write the inventory first, every AI touching a decision, with an owner. Then split the list into models and tools using the one question from section four. Most of it will be tools, and you can govern those lightly.

Take the one or two most material models, the ones producing a number that drives a decision, and give each an independent checker and a monitoring date. Write the three-line policy that says who can halt a model. That is a defensible, proportionate model-risk framework for AI, and it is a week of focused work, not a quarter of committee.

If you want that inventory and framework built for your firm rather than assembled from a template, that is what an AI Readiness Sprint produces: the map of where AI already touches your decisions, the model-versus-tool split, and the controls that make it hold up in front of an LP or an examiner. Start with the list. You will govern what you can finally see.