At a glance
- Automated post-closing QC can check every closed loan instead of a sample, but full coverage of checks isn't the same as full automation of the reviewer's judgment.
- A defect-triage matrix — defect type, severity, auto-detect confidence, owner, and response SLA — routes findings instead of leaving them in one first-in, first-out queue.
- The QC reviewer confirms or overrides every suggested severity and decides what happens next; that's the organization's own operating choice, not a rule this article sets.
- Findings feed back to origination through defect trending and a reporting cadence your QC program defines, not by a system editing underwriting files directly.
Can AI review 100% of closed loans?
Mortgage post-closing QC automation can run its checks against every closed loan in a pool, not only a sample — that is the sense in which it can review the full population. The alternative is a sampling program, where reviewers select and read a subset of files in full and extrapolate the findings to the rest of the pool. Which model a QC program uses is an operating choice for QC leadership, not something the tooling decides on its own.
At least one vendor in this space markets full-population QC — checking every loan, not a sample — directly; others market speed or accuracy instead. Read each claim carefully, because coverage of checks and automation of sign-off are two different things. The table below quotes what four vendors' own documentation says, each attributed, dated where a date is shown, and labeled as a vendor claim rather than an independent result.
| Vendor | What their own documentation says | How to read it |
|---|---|---|
| TRUE | “AI review for loans makes it possible to perform 100% QC across portfolios in hours, rather than sampling small percentages.” [1] | A vendor claim about coverage: every loan gets the same automated checks. It doesn't say auditor sign-off is automated too. |
| Infrrd | Describes its platform as “allowing any audit QC to be completed in half the usual time” [2] (dated May 24, 2024). | A vendor claim about elapsed time, not a coverage or defect-detection rate, and not benchmarked against an independent baseline here. |
| Areal | For its Copilot Agent, which it says “handles almost all closing tasks automatically,” states “99% accuracy on critical fields” and that “98.8% of the work never reaches a person” [3]. | Both figures describe the same closing-task Copilot Agent, not post-closing QC specifically, and no field list or test set is shown alongside either figure here. |
| Dark Matter Technologies | Describes its post-close product as built to “reduce time to review files and minimized errors” [4]. | A directional vendor claim; no specific percentage or rate is attached. |
None of this is an independent audit finding, and the table isn't a ranking. In TRUE's wording, “full” means every loan gets the same automated checks, not that the reviewer's sign-off is automated. Whether that replaces or supplements your sampling program is a decision for QC leadership, not a default the tooling sets.
Moving from a sample to full-population checks changes reviewer workload, because every loan can now produce a candidate finding, not only the ones in the sample. A simple way to size that: if checks surface N candidate findings per 100 loans and a disposition takes M minutes per finding, total disposition time is roughly N × M minutes per 100 loans. Compare that with the review time your current sample takes. N and M are numbers only your own pilot can supply.
The defect-triage workflow
A defect-triage workflow turns what an automated check finds into something a QC team can act on, instead of a flat list in review order. It classifies each finding, routes it to the right owner, attaches a response expectation, and records the reviewer's disposition.
- Detect
An automated check compares the closed file against the documents, the application, and the lender's own rules, and produces a candidate finding with a confidence level.
- Classify
The finding is tagged with a defect type and a suggested severity, using the matrix below as a starting structure.
- Route
The finding goes to the named owner for that defect type — QC reviewer, post-closing lead, underwriting manager, or compliance — not a shared inbox.
- Apply a response expectation
A response SLA attaches to the finding based on its severity, so higher-severity items don't sit behind routine ones.
- Reviewer disposition
The owner confirms the defect, corrects the severity, marks it a false positive, or escalates it; the system doesn't close a finding on its own.
- Record
The finding, its severity, who decided it, and the reason are kept together, feeding later reporting and feedback steps.
What does an auditor still decide in automated QC?
The auditor decides whether what an automated check found actually supports or undermines the underwriting decision — that judgment doesn't move just because the extraction and comparison steps behind it are automated. In practice, that means checking whether the application, the underwriting documents behind credit, income and assets, and the decision itself still hold together as a file.
- Confirming, correcting, or overriding the severity a system suggests for any given defect.
- Deciding whether a flagged discrepancy is a true defect or a false positive, and recording the reason.
- Choosing the remediation path for a confirmed defect — a data correction, a document request, a resubmission, or a self-report.
- Signing off on the file before it moves into monthly reporting.
Keeping those four calls with a named reviewer is this article's own operating recommendation, not a rule stated here.
How should QC defects be triaged by severity?
This article classifies each finding by defect category and severity level. The matrix below is this article's own starting structure for that classification, not a copy of anyone's existing tiers — set your own thresholds with QC leadership, and adjust as findings accumulate.
| Defect type | Severity | Auto-detect confidence | Owner | Response SLA |
|---|---|---|---|---|
| Missing or expired closing document | Major | High — presence/absence is a reliable check | Post-closing lead | 2 business days |
| Income or asset figure inconsistent across documents | Major | Medium — depends on document quality | QC reviewer | 3 business days |
| Data mismatch between the loan file and source documents (e.g., a name, SSN, or address) | Critical | High for exact-match fields | QC reviewer | 1 business day |
| Appraisal or collateral exhibit missing or unresolved | Major | Medium | Underwriting manager | 3 business days |
| Underwriting decision not clearly supported by the file | Critical | Low — needs reviewer judgment | QC reviewer | 1 business day |
| Item coded as a compliance-related defect | Critical | Low — routed for review, not auto-resolved | Compliance | 1 business day |
| Formatting or clerical inconsistency with no bearing on eligibility | Minor | High | Post-closing lead | Next reporting cycle |
Treat “auto-detect confidence” as a routing signal, not a verdict: a high-confidence detection still gets a reviewer's disposition, and a low-confidence one gets priority attention precisely because the system can't resolve it alone. The severity column is a suggestion; the section above covers who sets it.
How do QC findings feed back to origination?
Findings feed back to origination through reporting, not through the QC system editing production files. We recommend communicating confirmed defects to the responsible department or business unit, and trending each defect type over at least three months, so a single bad month doesn't drive a process change on its own.
- Aggregate
Roll confirmed defects up by type and severity, using the same categories the triage matrix assigns.
- Trend
Track each defect type over at least three months before treating a change as a pattern.
- Find the root cause
For defect types that persist, trace them back to a specific document type, channel, branch, or underwriting step.
- Feed it upstream
Share confirmed, trending defects with origination, processing, or underwriting management — the QC function reports; it doesn't edit their files.
- Re-test
After a corrective step, watch that defect type's rate next cycle to see whether it actually moved.
What evidence should a QC automation keep?
For every finding, keep enough to reconstruct the decision later without relying on anyone's memory: the source documents compared, what didn't match and where, the system's confidence, the reviewer's disposition, their stated reason, and a timestamp. A reverification step — comparing a document obtained after closing against the one used at origination — only means something later if both versions, and the comparison, are kept, not just the conclusion.
- The original document and field value, and the reverified or compared value, kept side by side rather than overwritten.
- The defect type and severity assigned, and whether a person confirmed, corrected, or overrode either one.
- The reviewer's identity and stated reason for the disposition, not just the outcome.
- A timestamp and a rule or check version, so a finding can be tied to the exact logic that produced it.
- The downstream action taken — correction, resubmission, self-report, or no action — and who decided it.
When this doesn't apply
- Your post-closing volume is small enough that a QC reviewer already sees every file without a sampling program to reconsider.
- Your QC program's scope and written policy aren't settled yet — settle those first; they shape what the workflow checks.
- Your defect categories and severity definitions aren't written down anywhere your QC team agrees on. Write them down before automating around them.
- The goal is to remove the reviewer's sign-off rather than to triage their queue. That's a different kind of change, with a different risk profile, and it isn't what this workflow does.
Where to start: a first scoped workflow
- Pick one scope
Start with one loan product and one or two investor relationships, not your whole population.
- Write the taxonomy first
Agree defect types and severity tiers with QC leadership before building any check against them.
- Shadow-run it
Run checks against already-reviewed closed files and compare suggested severity to what reviewers actually decided.
- Measure agreement, not just detection
Track how often reviewers accept, correct, or override the suggested severity — that gap shows where the matrix needs adjusting.
- Go live with routing and SLAs attached
Turn on the workflow only once findings are already routing to the right owner with a response expectation, not as a bare list.
- Review the taxonomy quarterly
Defect trending and the shadow-run gap are both inputs to revising severity tiers and thresholds, not a one-time setup.
Frequently asked questions
Does AI review every closed loan, not just a sample?
It can run the same automated checks against every closed loan instead of a sample, which is one meaning of full coverage. That's different from automating the reviewer's job: a person still confirms each finding, decides severity where it isn't clear-cut, and signs off before anything reaches reporting, whatever share of loans the checks themselves covered.
What does an auditor still decide in automated QC?
The auditor decides whether a flagged item is a true defect or a false positive, confirms or corrects its severity, chooses the remediation path, and signs off before the file moves into reporting. Automated checks produce candidate findings with a confidence level; deciding what a finding means for the file stays a human judgment.
How should QC defects be triaged by severity?
Classify each finding by defect type and suggested severity, route it to a named owner for that type, and attach a response expectation scaled to severity, using a matrix like the one in this article as a starting point. Treat the system's severity as a suggestion the reviewer confirms or corrects, not a final verdict.
How do QC findings feed back to origination?
Confirmed defects are aggregated by type and trended over at least three months, then shared with origination, processing, or underwriting management once a pattern — not a single month's noise — is visible. The QC function reports the pattern and its root cause; it doesn't edit production files directly, and the next reporting cycle shows whether a fix actually worked.
What evidence should a QC automation keep?
Keep the original and reverified document values side by side, the defect type and severity assigned, whether a reviewer confirmed or overrode it and their stated reason, a timestamp and check version, and the downstream action taken. That's enough for someone who wasn't in the room to reconstruct why a finding was decided the way it was.
Related reading
- Document review with human approval covers the evidence-linked extraction and reviewer sign-off pattern this workflow adapts for post-closing files.
- Loan underwriting document workflow covers the equivalent preparation and check pattern earlier in the loan lifecycle, before closing.
- Human-in-the-loop AI governance covers how to decide which calls stay with a person more generally, beyond QC.
- Our industry page on how AI agents fit across mortgage origination, closing, and servicing maps post-closing QC against the other workflows in the loan lifecycle.
- AI agent implementation describes how a workflow like this is scoped, tested, and handed over.
- 360° AI Blueprint helps rank a QC automation build against other candidates in your operation.
More in Lending operations
How to Automate Borrowing Base Certificate Review: The Checks to Run Before Availability Is Approved
A check table and tie-out checklist for how to automate borrowing base certificate review: ineligibles, advance rates, and what stays a human decision.
Financial ServicesCross-Document Validation in Loan Files: Rules That Catch Income and Identity Mismatches
A cross-document validation rule table for loan files: how pay stubs, W-2s, tax returns, and bank deposits should be compared, with tolerances and routing.
Loan Covenant Monitoring Automation: Build, Buy or Layer an AI Agent on Your Portfolio System
Loan covenant monitoring automation: compare buying point software, extending your LMS, or building a custom agent, with a covenant test register template.
Financial Services