The gap between recorded data and correct data is where most HMDA reporting effort goes. A single mis-keyed rate or an outdated census tract can turn a routine filing into an examination finding.
This article walks through what HMDA data is, how it travels from a loan application to the register that gets submitted, and why data quality, when not assisted by Ask Kaia, is the part of the process that tends to consume the most time.
What HMDA Data Is and Why It Is Collected
HMDA data is the set of standardized information that covered lenders record and report about mortgage applications and originations. The Home Mortgage Disclosure Act, enacted in 1975, established the reporting regime, and Regulation C is the rule that implements it.
Rulemaking authority for HMDA moved to the Consumer Financial Protection Bureau under the Dodd-Frank Act, and the CFPB now maintains the regulation and the public data.
HMDA information helps the public and regulators see whether financial institutions are serving the housing credit needs of their communities, informs how public investment is distributed, and supports the identification of possible discriminatory lending patterns.
For the reader assembling a register, HMDA data becomes part of a national dataset that the CFPB publishes each year, and the quality of your entries is part of how your institution's lending record reads.
Learn more about Ask Kaia’s HMDA compliance testing agent here.
From Origination to the Loan/Application Register
HMDA data collection is a lifecycle process. A record begins when an application comes in and continues to accumulate detail as the file moves through underwriting, pricing, and a final action. The register entry should reflect the applicant, the property, the loan terms, the action taken, and, where applicable, pricing information.Whether an institution must report at all depends on coverage tests in Regulation C. Key factors include:
- Loan volume
- Asset-size
- Location
Loan-activity criteria, and the asset threshold is adjusted annually. Determining coverage is a judgment that shifts as thresholds move (part of the broader discipline of managing regulatory change).
Covered institutions assemble their entries into the Loan/Application Register. The register carries dozens of data fields per loan, spanning applicant and borrower information, property details, loan characteristics, and the action taken.
Reporters file the prior year's data through the FFIEC's HMDA Platform, with an annual submission deadline of March 1 following the calendar year the data covers.
Where HMDA Data-Quality Errors Come From
Most HMDA data quality problems come from ordinary friction in how the data is captured and moved. For example, errors when applicant details are keyed by hand, or when loan origination systems, pricing engines, and the reporting tool do not share a single source of truth.
Certain fields generate a higher share of trouble, and include instances where:
- Geocoding and census tract entries go stale or get mismatched
- Rate-spread and APR-related fields depend on calculations that are sensitive to the loan's terms and timing
- Action-taken codes and denial reason codes are not lined up with what happened to the file
- Data is not attributed correctly in files with multiple applicants
Automated edit checks in the submission platform catch a meaningful portion of these issues before a file is accepted. However, they cannot confirm that a technically valid entry is the true entry. Those are the errors that survive to the filing.
A Quick-Reference Table of Common LAR Error Types
The table below maps common HMDA data error types across the register, what typically causes each one, why it matters, and how a testing pass tends to surface it.
| Data field or area | Typical error | Why it matters | How testing surfaces it |
|---|---|---|---|
| Geocoding / census tract | Stale or mismatched tract for the property | Distorts geographic and fair-lending analysis | Cross-checks address against current tract data and flags mismatches |
| Rate spread / APR fields | Calculation or timing error | Misstates loan pricing in the public data | Recomputes expected values and flags outliers |
| Action taken / denial reason | Code does not match the file outcome | Misrepresents approvals, denials, and terms | Compares codes against decision records for consistency |
| Applicant / co-applicant data | Misattributed or transposed entries | Skews demographic and decision analysis | Checks attribution across multiple-applicant files |
| Loan amount / property value | Keyed or unit errors | Produces implausible ratios and outliers | Range and ratio checks isolate improbable figures |
The fix for each of these depends on comparing the register against a source of truth.
Why Pre-Submission Testing and Scrubbing Matter
Testing HMDA data before submission is cheaper than correcting it afterward. Resubmission consumes staff time, and repeated errors can raise questions about the controls behind the numbers.
Data quality also carries fair-lending weight. Because HMDA data feeds analysis of who receives credit and on what terms, inaccurate entries can create the appearance of a pattern that does not exist, or obscure one that does.
Scrubbing the register is the practical response. A structured pre-submission pass re-checks the high-risk fields, compares entries against source records, and isolates the outliers that warrant a second look.
How AI-Assisted Testing Supports LAR Review
AI-assisted testing supports HMDA data review by doing the repetitive comparison work at scale and routing the judgment calls to a person. A testing workflow can re-check geocoding, recompute expected pricing values, compare action codes against decision records, and surface the entries that look inconsistent.
Kaia, our AI compliance assistant, is one implementation of this pattern applied to HMDA data. In a testing role, Kaia can validate register entries against source data, flag anomalies in the high-risk fields, and organize edit-check results so a reviewer sees the exceptions rather than the whole file.
The assistant flags and organizes, while a compliance analyst confirms the correction and owns the decision. An audit trail records what was checked, what was flagged, and how each exception was resolved, which supports both internal governance and the continuous controls monitoring an examiner expects to see.
Used this way, AI handles the volume and the consistency checks while accountability for the filing stays with the institution.
Frequently Asked Questions
Who must report HMDA data?
Whether an institution must report depends on coverage tests in Regulation C, including loan volume, asset size, location, and loan-activity criteria. On volume, the closed-end threshold is 25 covered loans in each of the two preceding calendar years, and the open-end line-of-credit threshold is 200 in each of the two preceding years. The asset-size threshold is adjusted annually, so coverage should be confirmed against current figures.
What is the HMDA LAR?
The HMDA LAR, or Loan/Application Register, is the structured file covered institutions use to report their mortgage data. It carries dozens of data fields per loan, covering applicant and borrower information, property details, loan characteristics, and the action taken. Reporters submit the prior year's register through the FFIEC's HMDA Platform, and the register is the document that edit checks and examiners review.
What are common HMDA data errors?
Common HMDA data errors include stale or mismatched geocoding and census tracts, rate-spread and APR calculation problems, action-taken or denial reason codes that do not match the file outcome, and misattributed entries in multiple-applicant files. Many stem from manual entry or from systems that do not share a single source of truth.
A structured pre-submission testing pass, with AI handling the volume and a reviewer owning the judgment, is a practical way to achieve correct data output.
Learn how Ask Kaia can assist your organization’s compliance team in gaining clarity on regulatory changes.
Request Demo- Policy Drafting
- Compliance Automation
- Audit Trails
- Regulatory Intelligence