HMDA Data Reporting: How to File Without Costly Errors

The usual advice on HMDA data reporting is to start early and clean up the file before submission. That's not enough. A filing team can correct every visible exception and still submit an incomplete population, misclassify purchased loans, or feed duplicate records into management dashboards.

Executives should treat HMDA as a recurring governance process and a market-intelligence asset, with separate controls for each purpose. Compliance needs a reproducible record of reportable activity. Business leaders need comparable lending measures, reliable institution identifiers, and clear limits on what public mortgage data can establish.

HMDA Coverage Thresholds and Deadlines

A bank or credit union files annually when it meets the applicable institutional and transaction coverage requirements, and larger reporters also face quarterly obligations. Management should approve that determination before the reporting year begins, not when the compliance team starts assembling the submission.

Don't carry a prior-year threshold determination forward without checking the governing rule. Coverage rules can change, and a threshold summary is not a substitute for a documented legal applicability review. In particular, the closed-end volume threshold requires verification against current Regulation C before anyone uses it to exclude an institution from reporting.

HMDA Obligations by Threshold, Deadline and Effect

The following operating checklist should sit within the bank's broader regulatory reporting requirements, with compliance responsible for confirming current applicability.

Obligation	Threshold or rule	Deadline	What it changes
Closed-end mortgage coverage	Confirm the current closed-end threshold for each of the two prior calendar years. Do not rely on the former 100-loan threshold without legal verification.	Annual file due March 1 of the following year	Counted separately from open-end lines
Open-end line of credit coverage	Generally, 200 open-end lines of credit in each of the two prior calendar years, subject to other coverage criteria	Annual file due March 1 of the following year	Can cover one product line and not the other
Quarterly reporting	At least 60,000 combined applications and covered loans in the prior year, excluding purchased covered loans	Within 60 calendar days after each of the first three quarter-ends	Adds three quarterly submissions; the annual file still applies
Data points per covered application	Up to 110	Part of both annual and quarterly files	Includes loan purpose, action, amount, property location, pricing and demographics

Product counts need separate treatment. Combining closed-end mortgages and open-end lines into a single institutional total can produce the wrong coverage conclusion. Purchased loans also require careful handling because their treatment in the quarterly volume test differs from their treatment in the reportable population.

Consider a hypothetical regional bank with 75,000 reportable applications and covered loans, after excluding purchased covered loans from the quarterly threshold calculation. Management should budget for recurring submissions as well as annual reconciliation, rather than assigning the work to a seasonal filing team.

Board question: Which product lines count toward each coverage test, and who has checked the underlying counts against the applicable reporting-year rule?

Require a signed coverage memorandum, supporting extracts, and an explanation of exclusions. A spreadsheet showing a total is not sufficient evidence of a sound coverage decision.

How to Build a Defensible HMDA Pipeline

HMDA starts with scope, not with the file. The submission is the final output of decisions about coverage, transaction classification, source documentation, transformation logic, and exceptions.

The CFPB's HMDA reporting FAQs explain the reporting framework, including that a covered application can require up to 110 data points. The operational implication is straightforward: every reportable value needs an identifiable source and a controlled path into the Loan/Application Register, or LAR.

Build Controls Around the Reporting Population

1. Approve scope for the reporting year. Have compliance document the applicable institutional criteria and review the preceding calendar years' product counts. Retain the counting methodology so an independent reviewer can reproduce the conclusion.

2. Identify every covered transaction. Build the population from covered applications, originations, and purchased loans, then apply the appropriate Universal Loan Identifier, or ULI, controls. Don't generate identifiers independently in downstream spreadsheets, where inconsistent formats can separate records that belong together.

3. Map source fields into the LAR. Identify the system of record for loan purpose, action, amount, property location, pricing, property value, and applicant demographics. Where systems disagree, assign an authoritative source and an escalation owner instead of letting the extraction query make an undocumented choice.

4. Validate before platform submission. Run field-level checks and cross-field rules inside the bank's pipeline. The team should detect an impossible code combination during routine processing, not discover it while working against the filing deadline.

5. Resolve exceptions at their source. Record the original value, corrected value, supporting document, reviewer, and reason for correction. Suppressing an exception without fixing its cause only transfers the same work to the next reporting cycle.

6. Reconcile population and outcomes. Compare source-system totals with the register by product and action, then explain every difference. Aggregate agreement alone can conceal offsetting omissions and duplicates.

7. Obtain accountable certification. A knowledgeable officer should approve accuracy and completeness after reviewing reconciliation and exception evidence. Certification shouldn't depend on an email stating that the file looks ready.

Investigate the Gap Before Certifying

Suppose a credit union's origination system contains 12,500 applications, but its preliminary register contains 12,410. The resulting 90-record gap is a hypothetical reconciliation exception, not an acceptable tolerance.

Trace the missing population through extraction filters, action-date logic, product exclusions, and failed transformations. Some records may legitimately fall outside HMDA scope, but the team must demonstrate that conclusion record by record before certification.

Control design matters more than the software brand. Use immutable raw extracts, versioned transformation logic, and targeted sampling of denied, withdrawn, purchased, and originated transactions. Retaining the original extract lets reviewers distinguish an upstream correction from a downstream mapping change.

A practical approach to building data pipelines also separates development, approval, and production deployment. A filing analyst shouldn't be able to change classification logic without review just because a deadline is approaching.

The deliverable is a written workflow with a named owner for every step, documented handoffs, and retained evidence. Automation makes that workflow repeatable. It doesn't replace responsibility for deciding what belongs in the file.

Validation Gates That Stop a Bad Filing

A successful upload is not an accepted filing. It proves that the platform received a file, not that the institution completed validation, addressed required edits, and certified the submission.

The HMDA Platform API documentation identifies status 5 as formatting errors, status 8 as completed syntactical and validity analysis without those errors, and status 9 as unresolved edits that prevent the filing process from proceeding. Directors should ask which stage management has reached, not whether someone clicked upload.

Separate Technical Success From Filing Readiness

Treat syntactical, validity, quality, and macro edits as distinct review categories. Some failures require correcting a value; others require investigation and an appropriate confirmation. A zero-open-edit target means every required edit has been addressed, not that analysts have forced every unusual but accurate value to look ordinary.

Review these internal measures monthly:

• First-pass validity rate: How much of the file clears initial technical validation without repair?
• Edit density: How many exceptions arise relative to the register's size?
• Median remediation time: How long do owners take to resolve exceptions?
• Recurring-error share: Which source systems repeatedly create the same problem?

For a hypothetical bank with 18,000 LAR rows and 270 first-pass edits, edit density is 15 per 1,000 rows. If one source system produces 60% of those edits, management should assign the corrective action upstream rather than add filing-team overtime.

Fix the Cause, Not Just the Export

Classify failures into formatting, missingness, invalid codes, conditional-field violations, and cross-record consistency problems. Prior-year institution identifier mismatches deserve particular attention because an otherwise plausible record can still be inconsistent with the institution's reporting history.

The FFIEC filing overview specifies a pipe-delimited text file and warns against adding leading zeros merely to force field length. A spreadsheet can display apparently correct values while concealing altered identifiers, incorrect field order, or delimiter problems.

BatchData's explanation of validation provides useful context on how to prevent costly real estate data errors, particularly when property information passes between systems. For HMDA, however, the bank's approved rules and platform results remain the filing controls.

Close the gate with documented platform status and sign-off, not with a clean-looking spreadsheet.

Running Quarterly Filings Without Double Counting

Quarterly filers need a production calendar, not a compressed version of the annual cleanup exercise. Each release requires a stable reporting population, controlled changes, and a clear distinction between a regulatory submission and the internal dataset used for management reporting.

Under the FFIEC's quarterly filing guide, submissions are due within 60 calendar days after quarter-end, with the stated first-quarter deadline of May 30. Applying that interval produces August 29 for the second quarter and November 29 for the third quarter.

Control the Action-Date Window

Assign transactions by Action Taken Date, not extraction date, dashboard load date, or the date an employee finishes reviewing the file. Maintain separate fields for the transaction's reporting period and the submission version that contains it.

The FFIEC's supplemental guide for quarterly filers permits cumulative submissions and requires census-tract boundaries effective January 1 of the reported calendar year. Those choices create analytical responsibilities: cumulative files need deduplication, and geographic comparisons need a consistent boundary basis.

A hypothetical annual workload of 75,000 reportable records averages 18,750 per quarter, or 6,250 per month. That's a planning average, not a forecast of seasonal mortgage activity.

If analysts append a cumulative second-quarter file to a dashboard that already contains the first-quarter file, they count earlier activity again. Use institution, application identifier, and action date to identify the transaction, then apply explicit replacement rules for corrected versions.

Give Each Release an Owner

Control-calendar item	Accountable owner	Evidence before release
Reporting-period assignment	HMDA operations	Action-date exception report
Submission preparation	Regulatory reporting	Approved file version and release log
Source reconciliation	Data engineering	Explained differences against origination counts
Filing approval	Certifying officer	Completed review and submission evidence

Monitor late-entered actions separately. An action recorded after the quarter closes may still belong to that closed quarter if its actual action date falls there; the team needs an escalation and correction procedure, not an informal decision to push it forward.

A redrawn tract can also change a geographic comparison without a corresponding change in lending. Keep boundary versions with the analytical dataset so executives can distinguish business movement from a mapping change.

Turning HMDA Data Into Market Decisions Without Misreading It

HMDA shows where reported mortgage activity occurred. It doesn't establish borrower profitability, lender capacity, or the commercial attractiveness of a prospect. Executives should use it to identify questions worth investigating, then test those questions against financial performance, product mix, local demographics, and the bank's own economics.

The CFPB's public-data release describes approximately 4,768 filers and warns that loan amount and applicant income have no upper limit and may contain outliers. An apparent affluent-borrower concentration may therefore reflect extreme values rather than a repeatable business segment.

Common HMDA Misreadings and the Check Before Acting

Signal	Likely misreading	Check before acting
Concentration in high-income borrowers	An affluent segment worth targeting	Look for outlier income values, since applicant income has no upper limit
Rising application counts	Rising demand	Compare with originations and denials, because applications can rise while approvals fall
Low volume in a census tract	An underserved opportunity	Compare with peer volume, tract demographics and competitor activity; weak demand can look similar
A few very large loan amounts	A jumbo-lending niche	Check for outliers and confirm whether the loans were purchased or originated
Year-over-year drop in a county	Lost market share	Check census-tract boundary changes effective at the start of the reporting year and changes in the filer population

Applications and completed lending are different measures. The CFPB's historical HMDA data describe 22.7 million home-loan applications from 4,475 institutions in 2020, illustrating the scale at which denominator choices affect comparisons.

An application increase can coexist with weaker conversion. A lender may attract more inquiries while completing fewer loans, so sales leaders should review the application-to-origination relationship before declaring that a competitor has expanded successfully.

Public files also contain privacy modifications. They're suitable for market analysis, but they aren't a complete customer or prospect universe, and analysts shouldn't attempt to reverse those modifications through speculative matching.

Protect the Analytical Layer

The most damaging mistakes often occur after filing acceptance, when teams standardize and combine datasets.

• Collapsed missing-value categories: Keep not applicable, not provided, and genuinely missing values distinct. Combining them can manufacture demographic, denial, or pricing differences.
• Overwritten regulatory codes: Store reported and normalized values side by side. Analysts need convenience without sacrificing the audit trail.
• Name-based CRM matching: Use controlled institution identifiers and appropriate transaction identifiers where available. Public HMDA data doesn't provide a dependable borrower-name prospecting key.
• Purchased loans counted as originations: Tag acquisition activity separately before estimating production capacity.
• Unstable institution identifiers: Maintain a versioned crosswalk for mergers, identifier changes, and historical comparisons.

Suppose a bank's CRM dashboard appears to show 14% share growth in a county. In this hypothetical example, analysts discover that a join duplicated 1,100 applications, and the apparent gain disappears after correction.

That result isn't a small reporting adjustment. It changes whether management should invest in sales coverage, revise competitive assumptions, or investigate an apparent market-share loss elsewhere.

Decision rule: Don't turn a geographic signal into a target list until someone can explain the denominator, transaction type, peer group, and matching logic.

For peer testing, Visbanking's Bank Intelligence and Action System combines HMDA with call reports and NCUA 5300 data, while Bank Performance supports comparisons across 4,600+ institutions. Use that broader context within a disciplined HMDA data analysis process, alongside internal profitability and capacity measures.

Assign Owners Before Your Next Deadline

Directors don't need to inspect every LAR field. They do need evidence that management has assigned responsibility for coverage, reconciliation, exception resolution, submission, and the downstream use of reported data.

The strongest briefing is an ownership report with unresolved decisions, aging exceptions, and documented approvals. A statement that the team is on track tells the board little about whether management can reproduce the file or defend its completeness.

Questions Management Should Be Ready to Answer

• Who owns the coverage test? Ask for the underlying closed-end and open-end counts, current-rule review, and approval of exclusions.
• Who owns the quarterly calendar? Confirm that preparation, review, remediation, and certification have internal deadlines before the regulatory deadline.
• Who approves the final gate? Require compliance and data engineering to sign off on addressed edits and reconciliation to origination-system counts.
• Who acts on recurring defects? Ask who reviews first-pass validity and source-system error patterns, what triggers escalation, and when a permanent fix is due.

If an answer is unclear, the process isn't yet governed. Assign a person, decision right, required evidence, and escalation path rather than adding another shared mailbox.

Use Bank Intelligence alerts through email, Slack, or CRM to route material volume changes to an accountable reviewer. Alerts should trigger investigation, not automatically label a change as growth, risk, or an underserved-market opportunity.

For the next executive review, pull the peer HMDA origination benchmark for the bank's largest county. Require management to explain the peer selection, purchased-loan treatment, geographic basis, and source reconciliation before recommending action.

---

Visbanking offers peer benchmarking and integrated banking data to connect HMDA activity with institutional performance and local market conditions. Visit Visbanking to explore the data and build a county-level origination comparison for your next management or board review.