An application scores into the middle band. It goes to an underwriter. She reads the file, spots something the scorecard missed and approves it. 9 months later the account is in collections. Somebody asks why it was written. The model has a version number. The override has a note. 

Model risk management is how a lender controls the harm that comes from a model being wrong, or from a model being used wrongly. Supervisors treat both as model risk. Most programs still stop at the model itself, and in the middle band it is a person who makes the call. 

Where model risk management loses the thread 

Automated decisioning does not remove judgment from lending. It concentrates it. 

Rules settle the clear approvals and the clear declines. What reaches a person is what the rules could not. This is the gray band, where a score is too low to approve outright and too high to decline. It is a small share of applications and a much larger share of the accounts that eventually go bad. 

The review step is doing real work. A person catching what a scorecard could not weigh is a control, not a workaround. It is the reason the gray band exists. 

The risk is not that the underwriter was wrong. It is that nobody can tell, months later, whether she followed policy or worked around it. The platform recorded the outcome. It did not record the basis. So the team validating the model checks the decisions the model made alone, and never checks the ones a person changed. 

What the rule actually asks for 

Regulation B, written by the Consumer Financial Protection Bureau (CFPB), governs how lenders explain a credit decision. It is more specific here than most governance programs are. 

If a lender declines on a score, the reasons it gives must relate only to what the system scored. If a person made the call instead, the reasons must relate to what that person actually reviewed. And when a score leaves an application in the gray band and a person then declines it, the Bureau's official interpretations to Regulation B are explicit. The reasons given "must come from both components of the system." 

Read that as an operations problem rather than a legal one. For any single application, a lender has to say what the score produced and what the reviewer read. If the second half exists only as a note, the decline letter is being written from memory. The same question sits underneath credit risk management software for auto lenders. 


Figure. One overridden decision, and what the file can answer afterwards. 

Compliance without overhead is a capture problem 

Most of what governance costs is reconstruction, not recording. 

The expensive way approves the exception in a queue and puts the reasoning in a note. A year later somebody rebuilds the story from emails. The cheap way records it while the decision is being made. The file then names which rule the application failed, what the reviewer read, who approved it and the coded reason. 

None of that slows the decision down, because it is captured while the reviewer works. It also changes what an auditor can do. Instead of asking for a sample of files to read, they can ask for every override approved above a set limit last quarter and get a list back the same day. The team validating the model gets the same thing. They can compare how the overridden accounts performed against the ones the model decided on its own, which is a test they cannot run today. 

What this means for lending leaders 

  • Watch the applications a scorecard cannot settle, because a small number of them cause a large share of the losses 
  • Give decline reasons drawn from both the scored half and the human half of the decision, which means recording the review as data rather than as a note 
  • Record the reasoning while the decision is being made, so an auditor can pull a list of overrides instead of asking for a sample of files 

Frequently asked questions 

Does model risk management cover manual overrides? 

Most programs scope it to building, validating and monitoring the model. The human review that follows sits outside. That gap is where these decisions lose their audit trail, and it widens as more of the clean volume is automated. 

How many reasons should a decline carry? 

Regulation B sets no number. Its official interpretations say that giving more than four reasons is not likely to help the applicant. What matters is that each reason accurately describes a factor the lender actually used. 

You cannot explain a decision the system did not record 

Explainability is usually treated as a modeling problem. Pick a technique somebody can describe and the job looks done. Once a person is in the loop it becomes a recording problem instead. The model can be perfectly clear and the decision still impossible to explain. The part that changed the answer was a person, and nobody wrote down what they saw. 

In Transcend Finance for automotive finance that review sits as configurable internal controls and multi-level approval. It lives on the same origination record as the automated decision, with the platform audit trail underneath. If you are looking at your own override queue and wondering what it would tell an examiner, we are happy to compare notes. 

Related blogs