Credit risk management software, as most banks already run it, scores applicants, monitors a portfolio's performance against targets, and flags when a segment's delinquency or default rate drifts from where it should be. What it does not usually do is explain why a specific loan, or a specific vintage, already went bad — that is a narrower, backward-looking question, and it is the one Botminds' Early Payment Default Review is built to answer. The two are not competing purchases. A monitoring system says the rate moved; a root-cause review says which of fraud, a credit miss, an onboarding error or hardship moved it, and sends the fix to the person who owns it.
The examples below come from the product's own fictional sample vintage — Lanternfield Bank, August, 87 early defaults, including a credit rule, CP-26-07, traced back to a debt-to-income cap raised six weeks earlier. The regulatory context comes from the OCC, Fannie Mae's own servicing guide and the Federal Reserve, linked where it appears.
What "credit risk management software" usually covers, and what it leaves out
Most of what is sold under the credit risk management label does one or more of three things: scores an applicant at origination, monitors a funded portfolio's performance against risk-appetite targets, and reports exceptions when a policy rule was overridden. All three are forward-facing or in-the-moment — they tell a credit risk team what the portfolio looks like now, or what risk a new application carries, compared with a plan set earlier. None of the three, on their own, is built to re-read a loan file after the fact and say which of several possible causes actually explains why it defaulted early. That gap is not a flaw in monitoring software; it is simply a different job, done by a different kind of review.
Why "the rate went up" is a monitoring answer, not a root-cause answer
On the sample vintage, the monitoring answer is a single number: 1.81% of August's loans went 30 days late on their first payment, against 1.06% for the six vintages before. That number is accurate, immediately available, and, on its own, almost useless for deciding what to do next. The rise could be a fraud ring, a credit policy that let in riskier borrowers than intended, the bank's own onboarding breaking autopay for a batch of borrowers, or a cluster of genuine hardship — and a vintage chart draws no line between them.
On this vintage, it was three of the four at once: fraud, 34 loans, 19 of them one ring through a single lead partner's sub-source; credit, 29, of which 21 were approved only after a debt-to-income cap was raised; onboarding, 16, of which 13 had autopay never saved by a recent app release; and hardship, 8. A monitoring system that reports 1.81% has told a credit risk committee that something changed. It has not told them whether to call the fraud team, the policy team, loan servicing, or nobody at all.
Where early payment default review fits next to policy exception tracking
The closest existing piece of a bank's stack to this kind of review is usually policy exception tracking — the record of every loan approved outside standard underwriting criteria, by how much and under whose authority. Early payment default review extends that same discipline one step further: it does not just record that an exception was made, it traces whether the exception, once a loan defaults, turns out to be the cause. CP-26-07, on the sample vintage, is exactly that extension at work — not a one-off override on a single file, but a rule change that widened an entire band, replayed against the loans it let in and the early defaults that followed.
Where early payment default review sits in a credit risk stack
| Layer | What it already does | What early payment default review adds |
|---|---|---|
| Origination scoring | Scores an applicant and applies underwriting policy at the point of decision | Nothing — EPD review starts after a loan has already funded and gone 30 days late |
| Portfolio monitoring | Tracks default and delinquency rates against risk-appetite targets, by vintage or segment | Explains a rate move by cause, instead of leaving it as one number |
| Policy exception tracking | Records loans approved outside standard criteria, and by how much | Traces whether a specific exception, or a rule change, is the cause once loans default |
| This review | Re-reads every early default, proposes a cause, drafts the fix for its owner | The layer that answers why, and routes the answer to fraud, credit policy, servicing or a partner |
What examiners expect a bank's policy exception process to look like
Policy exceptions are not incidental detail to an examiner; the OCC's Comptroller's Handbook treats them as a core measure of whether a bank's lending is under control. "Policy exception volumes and analysis should be a normal part of board and senior management reporting. Policy compliance is a useful risk management tool, and examiners should view adherence to the exceptions process as an important internal control," the handbook states (OCC, Retail Lending).
The OCC's own three categories of retail lending policy exception
1
Credit policy — loan-to-value, debt-to-income, pricing, verification
2
Credit scoring — high- and low-side overrides
3
Documentation — application, transaction information, collateral
"Exception monitoring reports should include sufficient detail for meaningful analysis of exceptions overall and by type," the same handbook adds. A monthly exception volume report satisfies the letter of that; a report that also says which exceptions, once their loans came due, turned out to predict an early default satisfies the spirit of it. Fannie Mae's own servicing guide describes a parallel discipline on the agency side: "Fannie Mae may review mortgage loans it has purchased or securitized (including those with early payment defaults, those that have been foreclosed, as well as any other mortgage loan)," using "a statistically valid approach in selecting a random sample of new mortgage loan deliveries for review," augmented "with targeted, discretionary sampling" (Fannie Mae Servicing Guide, A2-4-01). Early payment default review is the same instinct — reviewing what has already been purchased or funded against what actually went wrong — applied without the sampling limit.
How this fits with fair-lending review before any credit policy change
Where this review touches a live credit rule, it has to pass through the same review any credit policy change does. On the sample vintage, the credit rule tracer's proposal to tighten CP-26-07's debt-to-income cap to 42% with a residual-income floor is explicitly routed through fair-lending review before the credit risk committee ever sees it — the agent "never changes a rule," and the product's own governance description states that "every proposed credit rule change is tested for disparate impact first, and the credit risk committee decides." That sequencing matters specifically because a root-cause tool that finds a pattern in who defaults early is one step away from recommending a policy that could have a disparate impact on a protected class if the recommendation skips that review.
"Well-run banks generally handle exceptions in a structured and disciplined manner to promote sound operations as well as compliance with applicable laws and regulations, including those related to consumer protection and fair lending."
Office of the Comptroller of the Currency, Comptroller's Handbook, Retail Lending
What to check before adding another system to an already full stack
A credit risk stack that already has origination scoring, portfolio monitoring and exception tracking does not obviously need a fourth system, and the honest first question is whether the gap this guide describes is actually unaddressed today or already covered by a process that simply is not labeled "root-cause review." A bank whose sampled manual review already reliably catches rings, traces rule changes and finds its own onboarding errors has less to gain from adding a new system than one whose sampled review reaches only a fraction of the files — on the sample vintage, we assume a hand review of about 25 of the 87 — and leaves the rest a number.
Ongoing monitoring software against a backward-looking root-cause review
Portfolio monitoring: Is this segment’s rate within appetite, and how has it moved?
Early payment default review: Why did this specific vintage’s rate move — which cause, which loans?
Portfolio monitoring: Continuously, as loans fund and perform
Early payment default review: The day a loan crosses the early-default line, on every file, not a sample
Portfolio monitoring: A rate, a trend line, a threshold breach
Early payment default review: A proposed cause per loan, with evidence, routed to the owner who fixes it
Portfolio monitoring: The credit risk committee, tracking appetite
Early payment default review: The analyst, fraud manager, policy manager and servicing head who each act on one slice
Who signs off on what, once the pieces are in place
With a monitoring layer, a policy exception process and a root-cause review each doing their own job, the sign-off chain on the sample vintage runs through five seats: the credit risk analyst confirms every proposed cause; the fraud strategy manager accepts the fix that closes a ring; the credit policy manager takes an amended rule to the committee after fair-lending review; the head of loan servicing accepts the fix for the bank's own onboarding errors; and the Consumer Credit Risk Director signs the monthly report that ties the three findings together for the committee. No system in that chain confirms, changes or sends anything on its own — each step is a named person's decision, with the evidence that led to it attached.
One rule, replayed before anyone proposes changing it
What a 90-day evaluation of a tool like this should actually test
A fair evaluation runs the tool against a bank's own recent vintage, in parallel with the existing sampled review, and measures three things over roughly a quarter: how many of the sampled review's own findings the tool reproduces, what it finds that the sampled review missed, and how long each proposed cause takes to reach a confirmed, routed fix compared with the current process. The specific numbers on the sample vintage — 79 of 87 causes eligible for bulk confirmation at 90% confidence or more, a 5-business-day review clock, 1 minute 52 seconds for six agents to re-read all 87 files — are demonstrated results on the product's own fictional data, not a guarantee of what any bank's own 90-day pilot will show; they are the shape of what a pilot should be measuring, not the number it should expect to match.
What to check before adding this to an already full stack
- Does your current sampled review already catch rings, rule drift and onboarding errors?
If it reliably does, on every vintage, the gap this layer fills may already be closed by process rather than software.
- What share of early defaults does your sampled review actually reach?
For the sample vintage we assume 25 of 87, our estimate of a hand review. A bank running a smaller sample against a larger book has a bigger unmeasured gap.
- Is fair-lending review already wired into every credit rule proposal, from any source?
A root-cause tool that finds patterns in who defaults is one step from a policy recommendation; that step has to apply regardless of where the recommendation came from.
- Who would own each of the four fix types — fraud, credit, onboarding, hardship — today?
If a seat does not already exist for one of them, adding the tool surfaces an organizational gap as much as a software one.
- Can it run in parallel with your current process for a full quarter before anything changes?
A 90-day side-by-side comparison, on your own files, is the only fair test of whether it adds coverage or just adds a system.
What any new system touching credit decisions sits under, ultimately, is the same model-risk and third-party-risk discipline a bank already applies elsewhere: the April 2026 interagency model risk guidance, which "highlights sound principles for effective model risk management" scaled to a bank's size and complexity (SR 26-2), applies to any model the tool runs, and the OCC's third-party guidance applies "commensurate with the bank's risk profile and complexity as well as the criticality of the activity" (OCC Bulletin 2023-17) regardless of which category of credit risk software is being evaluated.
Your rules, not the vendor's — and versioned
What a vendor's limits actually look like in practice, and the questions worth putting to any of them before relying on this layer, is covered in what to ask an AI fraud detection vendor before you sign, and how this approach compares against a sampled review and a rules engine on the same vintage is set out in fraud detection software for banks, compared. To see the rule trace and the settings together, start from Early Payment Default Review.
Questions people ask
Is early payment default review a replacement for credit risk management software?
No. Portfolio monitoring and origination scoring answer forward-facing questions — is this segment within appetite, should this application be approved. Early payment default review answers a narrower, backward-looking one — why did this already-funded loan default early — and the two are meant to run together, not substitute for each other.
What are the three categories of credit policy exception, by the OCC's own handbook?
Credit policy (loan-to-value, debt-to-income, pricing, verification), credit scoring (high- and low-side overrides), and documentation (application, transaction information, collateral perfection or valuation). The OCC expects exception volumes in each to be a normal part of board and senior management reporting.
How does credit risk management software usually track policy exceptions?
Typically by recording each override against standard underwriting criteria, by category and dollar or transaction volume, with periodic reporting to the board. What most tracking stops short of is tracing whether a specific exception, once its loan defaults, is the actual cause — the step a root-cause review adds.
Does a tool like this need fair-lending review before changing a credit rule?
Yes, and in a well-governed design the tool itself should never change the rule at all. Any proposed change should pass fair-lending review for disparate impact before a credit risk committee ever considers it, with the tool's role limited to proposing and replaying the change, not approving it.
What should a 90-day pilot of credit risk root-cause software test?
Run it in parallel with your existing sampled review on real recent vintages: how many of the sampled review's own findings it reproduces, what it finds that the sampled review missed, and how long it takes to go from a flagged early default to a confirmed, routed fix compared with the current process.
Who should own the fix once a root-cause tool finds the cause of an early default?
It depends on the cause: fraud typically goes to a fraud strategy function, a credit miss to the credit policy owner, an onboarding error to loan servicing, and a partner-channel pattern to whoever manages that relationship. A tool that proposes a cause without routing it to a named owner has only done half the job.