Table of contents
Most mortgage file errors are small at the point of entry and expensive at the point of discovery. A transposed date of birth, a missing middle name, or an asset account typed into the wrong field can trigger a re-underwrite. The borrower may not notice until a closing document arrives with the wrong legal name. A monthly audit catches these mistakes while they are still cheap to fix.
The audit is not a full compliance review. It is a targeted check of the fields that flow into disclosures, underwriting, and closing. It samples files that have recently moved to underwriting and compares the loan origination system with the source documents. The result is a count of errors by field and by processor. This guide describes a practical audit that a team can run in an hour.
Choose the fields that cause the most rework
Start with the fields that appear on multiple documents and are hard to change later. Legal name, date of birth, Social Security number, marital status, and current address belong on the list. Add income type, employer name, asset account type, and property address. These fields drive eligibility, disclosures, and title work.
Do not audit every field in the system. A long checklist will produce a shallow review and a team that dreads the exercise. Choose eight to twelve high-consequence fields and check them carefully. Add a field when a real error causes a delay, not because it exists in the system.
Separate borrower-entered data from processor-entered data. The audit should identify where the error originated so the fix can target the right step. A borrower typo may need a better form, while a processor typo may need a second check. The distinction prevents the team from blaming the wrong part of the process.
Sample across processors and loan types
Use a sample that covers each processor and the main loan types the team handles. A sample of ten files from one processor will not show whether the issue is individual or systemic. A rotating sample over three months gives a fairer picture without auditing every file. Keep the selection rule simple enough that a different auditor could repeat it next month.
Include files from different channels and lenders. A purchase file from a retail lender and a refinance from a credit union may have different data requirements. The sample should reflect the mix the team actually processes. If one channel is excluded, the audit may miss its most common error.
Record the sample method so the next audit can repeat it. Note the date range, the number of files, and the selection rule. A repeatable method makes the trend meaningful. A convenience sample of whatever was open on Friday is not a trend.
Compare the system against the source document
The audit should compare each field with the document that supports it. Check the legal name against the government ID, the income against the pay stubs, and the asset balance against the statement. Do not compare the system against another screen that was typed from the same source. That only confirms consistency, not accuracy.
Mark each field as correct, incorrect, or unsupported. An unsupported field has no document behind it, even if the value looks plausible. Unsupported data is a finding because it cannot be defended in a review. The auditor should note the missing document and the field it affects.
Use a short evidence note for each error. Record the field, the system value, the source value, and the document page. A screenshot is optional, but a written reference is required. The note should be specific enough that a processor can fix the field without redoing the audit.
Classify the cause before assigning a fix
Group errors by cause: borrower entry, processor entry, system import, or unclear source document. A system import error may need a mapping change, while a processor entry error may need training or a second check. A borrower entry error may need a clearer form or a validation rule. The cause determines the fix.
Look for repeated errors in the same field. If the employer name is wrong in four files, the problem may be a field that is too short or a dropdown that does not match the pay stub. If the property address is wrong across channels, the problem may be an address autocomplete that accepts a partial match. A pattern is more useful than a single correction.
Do not treat every error as a performance issue. A processor working with a blurry document or an unusual name may make a reasonable choice that turns out wrong. The audit should separate a judgment call from a careless entry. The response should match the cause.
Feed the findings back into the workflow
Give each finding an owner and a due date. The owner may be the processor, the team lead, or the person who manages the intake form. Fix the file first, then fix the cause. A finding that is corrected in the file but not in the process will return next month.
Add a second check at the point where the error is most costly. If legal names are often wrong at disclosure, add a name check before the disclosure is generated. If asset values are often wrong at underwriting, add a balance check during document review. The check should be short and specific.
Update the onboarding materials with the most common errors. New processors should practice the checks on sample files before they work live. The loan processing support team can build the practice set from anonymized findings. A new person who knows the traps avoids most of them.
Report the audit in a way the team can use
Report the number of files sampled, the number of fields checked, and the error rate by field. Show the trend against the previous month. A single error rate without a trend is easy to dismiss. A field that improves or worsens tells the team where to focus.
Avoid ranking individuals in the shared report. Share individual results privately when coaching is needed. The team report should focus on fields, causes, and fixes. A blame-oriented report encourages people to hide errors rather than report them.
Close the report with two actions for the next month. One action should fix a process, and one should verify that the fix worked. Assign an owner and a date to each. The mortgage operations support lead can review the actions in the monthly operations meeting.
Keep the audit small enough to survive
A monthly audit is sustainable when it takes about an hour and produces a short report. If the audit grows into a multi-day project, it will be postponed during busy weeks. Protect the scope and the schedule. A small audit that runs every month is more valuable than a perfect audit that runs once.
Review the audit itself every quarter. Ask whether the fields still match the errors the team sees and whether the sample is still representative. Remove a field that no longer matters and add one that has become risky. The audit should evolve with the file.
The Federal Financial Institutions Examination Council's HMDA resources show how data accuracy affects reporting and fair lending review. A borrower data audit supports that broader control environment. It also gives the processing team a practical way to catch errors before they reach underwriting. Keep the audit scoped to fields that affect a borrower decision, and document the sample so the result can be compared over time.