Credit risk rating software: is what you are buying a model?

Credit risk rating software is anything a bank buys to help decide, record or check the internal risk grade on a loan — and a buyer asks two questions about it at once. What does it do, and what will model risk management make me do about it? The second question has a sharper answer than it used to: in April 2026 the Federal Reserve, the OCC and the FDIC replaced the 2011 model risk guidance with a revised version, SR 26-2, which keeps a definition of "model" and an exclusion that together decide most of the argument. The practical rule is that the validation burden follows the method, not the marketing. Botminds' Credit Risk Review sits in the third of the three categories below — it reads a loan's credit file and proposes a grade with every reason cited to a page — and this guide is written so a model risk officer can place it, and anything else, on the right side of that line.

Nothing here is a validation opinion on any product, including ours. No tool is or is not a model in the abstract: the definition is applied by a bank, under its own policy, to a specific use. What this page gives you is the definition, the exclusion, the test and the questions.

What is credit risk rating software?

In the narrowest sense, it is the system of record for a loan's internal grade: the field, the history, the approval of a change, the report that rolls grades up to the board. Almost every core banking system does that much. Everything sold as credit risk rating software above that line is doing one of three further things — scoring, applying rules, or reading — and buyers get into trouble because all three are described with the same verbs.

The distinction that matters to a bank is not feature-level. It is this: does the tool produce a number from a fitted statistical relationship, does it produce a number by applying rules someone wrote down, or does it produce an argument from documents that a person can check line by line? Those three answers lead to three different conversations with model risk, three different test plans and three different sets of evidence for an examiner.

A fourth thing is often bundled in and should be priced separately: workflow. Assigning reviews, enforcing independence, running a challenge clock, producing the board report. That part is not a rating method at all, and it is usually the part that decides whether the function works. What loan review software must do before you buy it covers that half.

Three things sold under one name

A statistical scorecard fits a relationship between inputs and outcomes on a development sample and applies it to new cases. Its strength is consistency: the same inputs always produce the same grade, across every lender and region. Its weaknesses are the familiar ones — it is only as good as the sample it was fitted on, it degrades as the population drifts, and it cannot see anything that is not an input. A letter in the file saying the largest customer is leaving is not an input.

A rules engine encodes the bank's own credit policy. If debt service coverage is below the covenant minimum and has fallen for two quarters, propose a downgrade. Its strength is that it is auditable in the most literal sense: a reviewer can read the rule and the policy paragraph it came from. Its weakness is that it only knows what policy anticipated, and credit policies are written in general terms precisely because credits are specific.

A file-reader starts from the documents. It assembles the relationship's file, spreads the statements on the credit agreement's own definitions rather than the borrower's, recomputes each covenant against what the borrower certified, and proposes a grade with a reason for each rating factor and a citation for each reason. Its strength is that every output points at a page a person can open. Its weakness is that it depends entirely on the quality of the documents and on how clearly the rating scale is written.

Most banks will end up with more than one. The question to answer before signing is not which is best, but which one you are buying, because the governance attached to the answer is different.

Is a credit risk rating tool a model?

It depends on the method, and the test is short enough to apply yourself. The revised guidance treats as a model a complex quantitative method that applies statistical, economic or financial theory to input data to produce quantitative estimates. Four tests sit inside that: is it quantitative, is it complex, does it rest on statistical, economic or financial theory, and does it produce an estimate. The guidance then carves out simple arithmetic, such as a spreadsheet's, and deterministic rule-based software with no such theory behind it.

A scorecard passes all four tests comfortably. A rules engine that applies written policy thresholds fails at least the theory test and usually the complexity one, and falls into the carve-out. A file-reader built on AI agents — Credit Risk Review's six agents are one — meets a different sentence altogether: a footnote in the same guidance puts generative and agentic AI outside its scope and leaves the governance of such tools to the bank's own risk management practices. None of that is a conclusion for your bank, because your bank's own model risk policy may define the term more broadly than the guidance does — many do, deliberately. The definition, the carve-out and how a validator applies them to a rating system itself are worked through in Risk Rating Validation's guide to credit risk model validation.

What the April 2026 guidance changes for a buyer

Four things about SR 26-2 are worth knowing before anyone leans on it in a negotiation. It supersedes and replaces SR 11-7, the 2011 guidance most existing model policies were written against, so a policy that cites 11-7 by number is now citing a withdrawn letter. It aims itself at banking organisations above $30 billion in total assets, with smaller organisations generally outside it unless their model risk is unusual. It says in its own terms that it does not set enforceable standards and that non-compliance with it will not result in supervisory criticism — while noting in a footnote that unsafe or unsound practices stemming from insufficient management of model risk are a different matter. And it puts generative and agentic AI outside its scope, which for a buyer of an AI-built tool means the bank's own governance has to say what testing, monitoring and controls apply; the footnote is quoted in full, with what follows from it, in AI in credit risk.

For a community bank, the practical consequence is that the answer to "do we have to validate this?" comes from your own policy, not from this letter. The letter is still the best available description of what a sound answer looks like.

Effective challenge, and who has to be able to do it

The idea that does most of the work in model risk management is not validation but effective challenge: critical analysis by objective experts who can evaluate the risk and make changes happen, from development through ongoing monitoring. The guidance asks of them expertise, enough independence to stay objective, and the standing to force a change.

Two words there decide a purchase. Objective means the challenger is not the person who built or bought the thing — which, for a vendor product, means your own staff or an outside party, not the vendor's own testing. Experts means they have to be capable of the challenge, and that is where a scorecard and a file-reader differ most. Challenging a scorecard needs someone who can read a development sample and a performance report. Challenging a file-reader needs an experienced credit person who can open the cited page and say whether the tool read it correctly — a skill most banks already have and most model risk functions do not count.

The guidance is explicit that vendor products are inside this. It expects an understanding of the vendor model's conceptual soundness, design, development data and performance, acknowledges that a bank may never receive the underlying code, data or methodology, and says the principles of model risk management remain applicable anyway. "The vendor validated it" is not a validation.

What validating a rating tool involves

Three components, and the guidance names them in order. Conceptual soundness assesses and documents the design, the key modelling choices and assumptions, the data selection and the developmental testing. Outcomes analysis compares outputs with what actually happened. Ongoing monitoring evaluates whether the thing still performs as expected as products, exposures, clients and conditions change.

What has shifted since 2011 is the acknowledgement that these look different for different methods. The guidance says that while evaluating theoretical construction may matter for some models, other assessments — interpretability measures, or benchmarking against other models — may be more practical for others. It also notes that where a model's design relies substantially on expert judgment, quantitative outcomes analysis helps evaluate the quality of that judgment. That sentence is the one to hold on to when someone claims a judgment-based method cannot be tested.

Separately, and much older, the OCC's handbook expects the rating process to be validated independently, in addition to whatever the examiners do, regardless of what software is in it. That duty predates any tool you might buy and does not transfer with the purchase.

What a back-test can and cannot prove about a new tool

A back-test checks whether the grades anticipated what happened, and the OCC's handbook expects banks to run one on their rating definitions and to change the definitions when the test says they are wrong.

It then splits the method by rating system. Where a system quantifies ratings as default probabilities or expected loss, back-tests should show that those probabilities and loss rates are largely confirmed by experience. Where a system is not tied to statistical probabilities — which describes most commercial 1–9 scales — the bank should instead be able to show that credits with more severe ratings exhibit higher defaults and losses, that the system rank-orders risk, and that it aggregates pools of similarly risky loans using an objective measure.

That second standard is reachable with data a bank already has, and it is the one most commercial lenders should be testing against. It is also the honest reason a bank cannot back-test a tool it installed last quarter: rank-ordering needs outcomes, and outcomes take years. In the meantime the testable thing is agreement — does the tool's grade match what a qualified reviewer concludes from the same file — which is a different claim and should be described as one. How to build the back-test itself, and how few defaults a commercial book gives it to work with, is in default rates by credit rating; where the grades come from is in the 1–9 scale, grade by grade.

Who sets the grade when the software proposes one?

A person, if the purchase is set up properly. Software can propose a grade; whether it may assign one is a question your credit policy answers, and the safe answer is that the grade of record changes only through a person, a named process and a record of who and why. The supervisory position supports that without needing to mention software at all: the interagency guidance on credit risk review systems makes accurate and timely ratings the foundation of the whole review system and builds everything else on review by qualified and independent people. The wider case for where agents stop, in rating work generally, is made in AI in credit risk.

What changes with a reading tool is the quality of the proposal. A suggestion that arrives with a reason for each rating factor, a citation for each reason, and an explicit statement of why the grade is not one notch better and not one notch worse is a different artefact from a score. It can be argued with, and the argument happens on the page rather than about the method.

What a suggested grade looks like when it has to show its work

Testing a tool that reads rather than scores

A scorecard is tested on a population. A reader is tested on documents, and the test plan looks more like an audit than a statistics exercise. Run it over a set of files whose grades a qualified reviewer has independently concluded, and measure three separate things rather than one.

Three measures worth separating. Grade agreement — how often the tool's suggestion matches a reviewer's independent conclusion, and by how many notches when it does not. Citation accuracy — how often the page cited actually says what the tool claims. And recall — what the tool failed to surface from a file a reviewer found. A product that scores well on the first and badly on the second is the dangerous case, because it is right for reasons nobody can check.

The evidence pack to ask for before you sign

Ask for artefacts, not assurances, and ask for them to be produced on your files rather than the vendor's.

Where the accuracy bar actually sits

No guidance sets a required accuracy for a rating tool, and no honest vendor will quote one for your portfolio. There is, however, a published figure for when an examiner starts pulling on the thread. The OCC's handbook tells examiners that when they discover significant risk rating inaccuracies — generally more than 5 percent of the number of credits reviewed, or 3 percent of the dollar amount — they must investigate the root causes and decide whether to widen their own sample.

Read it as a design constraint rather than a benchmark. A grading process whose errors sit above those levels will cost the bank a wider examination and a harder conversation about its allowance and its capital. A product evaluation that cannot say what its error rate was on your files, by number and by dollars, has not told you the thing the examiner will measure.

The other half of the constraint is direction. Errors that understate risk are the ones that matter, which is why a pilot should report the two directions separately rather than netting them into a single agreement percentage. The same asymmetry shows up in the board's own numbers, in the classified assets to capital ratio.

What is configurable, and what should never be

The last thing to test before signing is which parts of the method the bank controls. In this solution the configurable surface is the policy surface: the rating scale and its definitions, how often every loan is read, the size of disagreement that sends a loan to a reviewer, the loans that always go to a person whatever the system thinks, the lender's response clock, who settles a disagreement, the re-appraisal trigger and the cooling-off period after a reviewer moves out of lending. Every change is versioned and on the audit trail.

The settings a bank's credit policy owns, not the vendor

What should never be configurable is the boundary. The agents do not change a grade of record under any setting; a reviewer sets the review grade and the grade of record moves only when the challenge with the lender is settled. A reviewer who keeps the lender's grade against the suggestion may do so with a written reason, which goes to internal audit and is listed in the board report. We do not publish an accuracy figure for the suggestions and we are not claiming any external validation of them: those are things a bank measures on its own files, with the pilot described above. To see the grades, the citations and the settings together, start from Credit Risk Review.

Questions people ask

Does credit risk rating software need model validation?

If it meets your bank's definition of a model, yes, and the duty is yours even when the product is a vendor's. If it is built on generative or agentic AI, the April 2026 guidance puts it outside its own scope, and your bank's governance has to set the testing. Where the tool is a model, the revised guidance expects a bank to understand a vendor model's conceptual soundness, design, development data and performance, and to conduct ongoing monitoring and outcomes analysis itself, acknowledging that proprietary code may never be shared. If the tool falls under the exclusion for deterministic rule-based processes, your policy decides what testing applies instead — and the OCC's separate expectation that the risk rating process be independently validated still stands.

What is the difference between a rating scorecard and a rating engine?

A scorecard is a fitted relationship: inputs in, score out, derived from a development sample. An engine applies rules someone wrote, usually straight from the credit policy, and can tell you which rule produced the answer. The commercial consequence is that a scorecard brings a model lifecycle and an engine brings change control, and the two cost very different amounts to live with.

Does SR 26-2 apply to a community bank?

Mostly not, by its own terms. It names banking organisations above $30 billion in total assets as the ones it is most relevant to, and says that models used by smaller organisations are generally subject to internal risk management practices appropriate to their size and risk profile. It adds that it may still be relevant to a smaller organisation with significant model risk. Either way, a smaller bank's own model risk policy is what binds it, and most policies written against the 2011 guidance need updating now that it has been superseded.

What evidence should a rating tool produce for an examiner?

A rationale for each grade in the bank's own scale language, an openable citation behind each factual claim, a record of every override with its reason, proof that no reviewer assessed a credit they approved, the bank's back-test results over time, and a change history for every rule, threshold and scale definition. The first four should be available from day one; the fifth needs outcomes and therefore needs years.

Can software change a grade of record?

It should not, and a buyer should test that it cannot rather than accept that it will not. Ask to see the configuration that enforces it, then ask what the product does when an administrator tries. In this solution the agents suggest; a loan review officer sets the review grade; the grade of record changes only when the challenge with the lender is settled, with the decision recorded.

Is a spreadsheet that assigns grades a model?

Usually not under the guidance's own wording, which excludes simple arithmetic calculations such as those found within spreadsheets, along with deterministic rule-based processes with no statistical, economic or financial theory behind them. That is not a reason to leave it ungoverned: spreadsheets that assign grades still need version control, testing against the policy they implement, and a named owner, and most banks' policies cover them under end-user computing rather than under model risk.