HMDA Data Scrubbing: Preparing Your LAR for Annual Submission
6/17/2026
This is the operational companion to our guide on HMDA reporting requirements, which covers coverage, the data points, and how the data is used. This one covers a narrower question: how to get the register clean before March 1.
The distinction matters because HMDA failures are almost never failures of understanding. Institutions know what the fields mean. The register is wrong because the data was captured wrong nine months earlier by someone with no reason to think about it.
Why Scrubbing in February Does Not Work
The annual pattern at most institutions: pull the LAR in January, run the edits, spend three weeks correcting, submit, and repeat next year with the same errors.
Three reasons this fails.
The errors are already fixed in place. An application date recorded as the file assignment date cannot be corrected in February without going back to the file. Multiply by four hundred applications and the correction becomes a project.
The people who created the errors never learn. Corrections made centrally, silently, in February, produce identical errors the following year — because the loan officer who entered the wrong income figure was never told.
There is no time left for the analysis that matters. By the time the data is clean, March 1 is close, and the fair lending review that should inform management decisions becomes a compliance formality performed after submission.
The alternative is quarterly scrubbing: four reviews of a hundred records rather than one review of four hundred, with feedback reaching origination while the habit is still forming.
The Edit Categories
The HMDA Platform applies edits in tiers, and they mean different things.
Syntactical edits identify structural problems with the file itself — format, record counts, field lengths. The file cannot be processed until these clear.
Validity edits identify values that are not permissible for a field, such as a code that does not exist. These must be corrected.
Quality edits identify values that are permissible but unusual — an income figure far outside the typical range, a loan amount inconsistent with the property value, a rate spread that looks implausible. These may be correct, and each requires either correction or a documented verification.
Macro quality edits identify patterns across the file rather than individual records — for instance, an unusually high proportion of a particular action taken code.
The discipline that separates clean submissions from merely accepted ones is investigating quality and macro edits rather than confirming them. A quality edit is the system observing that something is atypical for an institution like yours. It is wrong often enough to be dismissed and right often enough that dismissing it wholesale guarantees errors reach the public file.
The Fields That Break Most Often
Dates. Application date recorded as the date the file was assigned, keyed, or opened in the system rather than the date the application was received. Action taken date recorded as the date the decision was entered rather than the date it was made.
Action taken. The distinction between denied, withdrawn, and file closed for incompleteness. A file closed for incompleteness requires that a written notice of incompleteness was sent and the applicant did not respond within the stated period. If a credit decision was made on available information, it is a denial. Miscoding here directly distorts denial rates, which is the headline fair lending metric.
Geocoding. Errors originate in address entry — abbreviations, missing unit numbers, transposed digits — and propagate into census tract, county, and state fields. Geocoding against a normalized address at entry prevents nearly all of it.
Income. Gross versus net applied inconsistently, or the figure updated during underwriting without updating the reportable field. The reported income should be the income relied upon in the credit decision.
Denial reasons. These must match the adverse action notice actually sent to the applicant. Divergence between the notice and the LAR is a finding twice over — a HMDA error and evidence that the stated reason may not be the real one.
Rate spread. Calculation errors from the wrong index, the wrong date, or a misidentified transaction type.
Government monitoring information. Left blank on in-person applications, where the institution must note ethnicity, race, and sex by visual observation or surname if the applicant declines to self-identify. Also, disaggregated categories collapsed into aggregates, which is a data error rather than a simplification.
Property value and loan-to-value inputs, particularly where a revised appraisal was received and only one field was updated.
A Quarterly Process
Pull the year-to-date register at each quarter end.
Run the same edits the Platform runs — most vendors provide this, and it can be scripted against the published edit specifications.
Correct at the source, not just in the register. If an application date is wrong, correct the record in the origination system so the next extract is right and so the file matches.
Categorize errors by type and by originator, and report them back. This single step is what stops recurrence: a loan officer who receives a short note showing three date errors on their files corrects the habit; one who never hears anything does not.
Sample manually beyond the edits. Pull ten files and compare the LAR record to the actual documents. Edits catch implausible values; they do not catch a plausible value that is simply wrong, and manual sampling is the only thing that does.
The Pre-Submission Fair Lending Review
Before submitting, run the analysis an examiner will run on the same data.
Denial and approval rates by prohibited-basis group, by product, compared to prior years and to available peer data. Pricing outcomes where applicable. Withdrawal and incompleteness rates, which reveal differences in the assistance applicants received rather than in the decisions made. Geographic distribution against demographics, which is the redlining picture.
Where an outlier appears, perform comparative file review before submission rather than after. Two outcomes are possible and both are valuable: the disparity is a data error, which you can still correct, or it is real, which management should learn about from you rather than from an examiner reading public data.
Institutions that skip this step are choosing to be surprised by their own numbers.
Documentation
Retain, with the submission: the final register, the edit reports with resolutions, the documented explanations for quality edits confirmed as correct, the sampling results, the fair lending analysis, the management review and approval, and the submission confirmation.
The explanations matter beyond this year. The same quality edits fire annually for structural reasons — a product mix, a market, a business model — and reconstructing the reasoning each year is wasted effort.
Who Should Own It
Split the ownership deliberately.
Field-level accuracy belongs to origination, with validation at entry and error rates reported back to the people creating them. Compliance cannot fix an application date recorded wrong four months ago.
Coverage determination, edit resolution, submission, and the fair lending analysis belong to compliance.
Both need a named individual, and the two need a standing quarterly conversation rather than an annual handoff. Institutions where compliance silently corrects origination's errors have a permanent, invisible defect rate.
Structured coverage is available through our HMDA compliance training and the HMDA — Home Mortgage Disclosure Act course.
What Happens After Submission
The work is not finished at the March deadline, and two post-submission activities are worth building into the calendar.
Resubmission risk. Examiners test HMDA accuracy by sampling the submitted register against loan files, and error rates above applicable thresholds can require the institution to correct and resubmit the entire register — a substantial and public undertaking. The sampling an institution performs on itself is the best predictor of how that examination goes, which is another argument for manual file-to-record comparison beyond the automated edits.
The data becomes public. Once released, the institution's lending patterns are available to community organizations, journalists, competitors, and prospective acquirers, alongside peer comparisons. Institutions that have run their own analysis know what the public data shows about them and can explain it. Those that have not sometimes learn about a disparity from a community group's letter, which is a considerably worse way to encounter it.
A short internal briefing after submission — what the data shows, how it compares to prior years and peers, and what if anything the institution intends to do — takes an hour and ensures that management is not the last group to see its own lending picture.
Automating What Should Not Be Manual
Most HMDA scrubbing effort is spent on errors that a validation rule would have prevented, and the highest-return work an institution can do is move checks from February to the point of entry.
Address normalization and geocoding at entry. The origination system should normalize the address against a postal standard and return the census tract when the address is saved, not months later during extraction. This single change eliminates the largest category of HMDA errors, and it also improves appraisal ordering, flood determination, and CRA analysis, which is why it is usually easier to justify than a HMDA-specific project.
Field-level validation on dates. A rule preventing an application date later than the action taken date, or an action taken date in the future, catches transposition immediately. A rule flagging an application date more than a few days after the earliest document in the file catches the more insidious error of recording the assignment date.
Cross-field consistency checks. Denial reason populated when action taken is not a denial. Rate spread present on a transaction type that should not carry one. Property value absent where the loan type requires it. Each of these is a two-line rule and a recurring finding.
Mandatory government monitoring information for in-person channels. The system should not permit an in-person application to be completed with those fields blank, since the regulation requires observation-based collection when the applicant declines.
A standing quarterly extract that runs the published edit specifications automatically and emails the results to the compliance owner and to each originator with errors on their files.
The argument for funding this is straightforward and worth making to management in these terms: the alternative is paying compliance staff to correct the same errors every February indefinitely, while carrying resubmission risk and publishing data the institution has not verified. Validation at entry is cheaper in the first year.
Frequently Asked Questions
When is the HMDA LAR due?
The annual submission is generally due by March 1 for the preceding calendar year, filed through the HMDA Platform, with institutions above a high volume threshold also filing quarterly. Because data quality is determined by what was captured throughout the year, the work that produces a clean submission happens well before the deadline.
What is the difference between validity and quality edits?
Validity edits identify values that are not permissible for a field and must be corrected before the file is accepted. Quality edits identify values that are permissible but unusual for an institution of that profile, requiring either correction or a documented verification. Macro quality edits identify patterns across the whole file rather than individual records.
Why scrub quarterly rather than annually?
Because errors cannot be corrected in February without returning to files created months earlier, because centrally correcting them silently means the people creating them never stop, and because a January scrub leaves no time for the fair lending analysis that should inform management before the data becomes public. Four reviews of a hundred records beat one review of four hundred.
Which HMDA fields have the highest error rates?
Application and action taken dates, action taken codes — particularly the distinction between denied and file closed for incompleteness — geocoding driven by address entry errors, income applied inconsistently as gross or net, denial reasons that do not match the adverse action notice sent, rate spread calculation, and government monitoring information left blank on in-person applications.
What should the pre-submission fair lending review cover?
Denial and approval rates by prohibited-basis group and product against prior years and peers, pricing outcomes, withdrawal and incompleteness rates which reveal differences in applicant assistance, and geographic distribution against demographics. Outliers should be followed with comparative file review before submission, while a data error can still be corrected.
What is resubmission risk?
Examiners sample the submitted register against loan files, and error rates above applicable thresholds can require correcting and resubmitting the entire register. An institution's own manual file-to-record sampling is the best available predictor of that outcome, which is why automated edits alone are insufficient — they catch implausible values, not plausible values that happen to be wrong.
