Table of contents

Loan setup looks simple until a wrong field sends a file down the wrong path. The borrower name, property address, loan amount, occupancy, and program code feed every later decision. A sampling rule gives the team a repeatable way to catch setup errors before they reach underwriting. The rule should be simple enough that a reviewer can explain it without opening a policy manual.

Decide what must be checked every time

Start with the fields that change the file's route or the borrower's cost. A wrong loan amount can change pricing, and a wrong occupancy can change eligibility. A missing property type can send the file to the wrong guideline. List these critical fields and treat them as a separate check from general data entry.

Not every field deserves the same attention. A typo in an internal note is annoying, while a wrong social security number is serious. Rank the fields by the harm an error would cause and the effort needed to detect it. The ranking tells the reviewer where to spend the sample.

Choose a sample size the team can sustain

A sample that is too small cannot detect a rising error rate, and a sample that is too large gets skipped. Pick a fixed number per reviewer per week and keep it stable when volume changes. If volume doubles, the sample can stay fixed because the goal is a signal, not a census. A fixed sample also makes the error rate comparable from month to month, even when volume swings.

Write the rule in plain language. For example, review ten files per reviewer each week, including at least two files from each active channel. If the team has fewer than ten files, review all of them. A simple rule is easier to audit than a percentage that nobody can reproduce.

Select files at random, not by convenience

The easiest files to review are usually the cleanest ones, so convenience sampling hides the errors that matter. Use a random list from the file system or rotate through the queue in a fixed order. Record the selection method so a later reviewer can repeat it. If the system cannot produce a random list, use a fixed interval through the queue and record the starting point.

Stratify the sample when the work is not uniform. Include files from each lender, each loan program, and each assistant if the volume allows. A lender with a new overlay may produce more setup errors, and a stratified sample will show that pattern. The report should state which groups were included.

Define an error before counting it

An error is a field that is wrong, missing, or inconsistent with the source document. A field that is blank because the source is blank is not automatically an error. Write the distinction down and give examples. Reviewers who use different definitions will produce a trend that looks real but is only noise.

Separate critical, major, and minor errors. A critical error changes eligibility, pricing, or the closing date. A major error requires rework but does not change the outcome. A minor error is a formatting or note issue. Report the categories separately so the team can prioritize the fix.

Check reviewer agreement

Ask two reviewers to score the same small set of files and compare the results. Agreement will never be perfect, but a large gap means the rule is unclear. Discuss the disagreements and update the examples. Keep the examples in the shared guide so the next reviewer sees them.

The mortgage operations support lead can own the agreement check each quarter. A quarterly check is enough when the rule is stable, and more often when a new lender or program is added. The goal is a shared standard, not a perfect score. When the reviewers disagree, keep the example that caused the split and add it to the next training session.

Tie each error to an action

An error count without an owner becomes a complaint. For each error category, name the person who will fix the process and the date of the next check. A field that is often blank may need a required field in the intake form. A field that is often wrong may need a source-document check before entry.

Use the sample to test the fix. If the error rate does not fall after the change, the diagnosis may be wrong. Maybe the source document is unclear, or maybe the assistant is not receiving the update. The sample gives the team a way to test the explanation instead of assuming it.

Increase the sample when the risk rises

A stable sample is useful until something changes. A new lender, a new loan program, or a new assistant is a reason to increase the sample for a short period. Set a trigger in advance so the decision is not made in the middle of a busy week. For example, double the sample for the first two weeks after a new overlay.

The loan processing support team should also increase the sample after a critical error reaches underwriting. The point is not to punish the reviewer. The point is to learn whether the error is isolated or part of a pattern. A short review of the critical error with the team can reveal whether the source document or the entry step failed.

Report the result in one page

Show the sample size, the error rate by category, the top three error types, and the actions with owners. Add a short note on what changed since the last report. Avoid a long narrative that hides the numbers. The reader should be able to see whether the process is improving.

The CFPB's Regulation Z is a useful reference for the disclosure fields that carry legal timing. Not every setup field has that weight, but the ones that do deserve a named check. A quality sample is only useful when the team agrees on which mistakes matter most. Name the fields that carry legal timing, then check them on every file rather than only in the sample.