How to Fix the 10 Most Common HMDA Edit Check Errors

Every year, thousands of financial institutions rush to meet the March 1 HMDA filing deadline—and every year, edit check errors slow them down. These validation failures can range from simple data entry mistakes to complex logic conflicts that require careful analysis to resolve.

After helping institutions file HMDA data for nearly four decades, we've seen the same errors appear again and again. Here's how to identify and fix the 10 most common HMDA edit check errors before they delay your submission.

Understanding HMDA Edit Check Types

Before diving into specific errors, it's important to understand the three types of HMDA edit checks:

• Syntax Edits: Verify data format and structure. These must be corrected before submission.
• Validity Edits: Confirm values fall within acceptable ranges. Also mandatory to fix.
• Quality Edits: Flag unusual but potentially valid data. May require verification but not necessarily correction.

The 10 Most Common HMDA Edit Check Errors

1. Invalid Census Tract (V628, V629)

The Problem: The census tract code doesn't exist in the Census Bureau's TIGER database, or it's formatted incorrectly.

Common Causes:

• Using outdated census tract codes (boundaries change every 10 years)
• Geocoding with non-compliance-grade tools
• Manual data entry errors
• Missing leading zeros

The Fix: Re-geocode the property address using compliance-grade geocoding that references the current Census Bureau TIGER file. Ensure your geocoding tool is updated for the current filing year.

2. Rate Spread Calculation Errors (V692, V693)

The Problem: The reported rate spread doesn't match the calculated difference between your loan's APR and the applicable APOR.

Common Causes:

• Using the wrong APOR table (fixed vs adjustable)
• Incorrect lock date reference
• Rounding errors
• Missing rate spread when required

The Fix: Before filing, check the rate spread against the current APOR tables using the FFIEC's official calculator or software with the tables built in. Verify you're using the correct loan term and rate type. Rate spread should be reported to two decimal places.

3. Invalid Action Taken Date (V615, V616)

The Problem: The action taken date is outside the reporting year, before the application date, or formatted incorrectly.

Common Causes:

• Date format errors (YYYYMMDD required)
• Reporting loans from the wrong calendar year
• Action date before application received date

The Fix: Verify all dates are in YYYYMMDD format. Ensure the action taken date falls within the reporting period and occurs on or after the application date. Check your data import mapping.

4. Income Inconsistencies (Q631, Q632)

The Problem: Reported income appears unusually high or low relative to the loan amount, or is missing when required.

Common Causes:

• Reporting gross vs net income incorrectly
• Including non-applicant income
• Data entry in wrong units (dollars vs thousands)
• Leaving income blank when it should be "NA"

The Fix: Report gross annual income in thousands of dollars (rounded). If income wasn't relied upon in the credit decision, report "NA" rather than leaving blank. Verify the DTI ratio makes sense.

5. Missing or Invalid ULI (S300, V696)

The Problem: The Universal Loan Identifier is missing, duplicated, incorrectly formatted, or doesn't include your LEI.

Common Causes:

• ULI doesn't start with your 20-character LEI
• Duplicate ULIs in your file
• Invalid check digit
• ULI exceeds 45 characters

The Fix: Ensure every ULI begins with your institution's LEI, followed by a unique identifier of up to 23 characters, plus a valid check digit. Use software that auto-generates compliant ULIs.

6. Property Location Mismatches (V626, V627)

The Problem: The state, county, and census tract codes don't align geographically.

Common Causes:

• Manual geocoding errors
• Mixing up similar addresses in different states
• Using county name instead of FIPS code

The Fix: Re-geocode the property address. Verify the state FIPS (2 digits), county FIPS (3 digits), and census tract (6 digits) all correspond to the same location. Use batch geocoding for consistency.

7. Loan Purpose and Occupancy Conflicts (Q633)

The Problem: The combination of loan purpose, occupancy type, and other fields doesn't make logical sense.

Common Causes:

• Investment property marked as home improvement
• Cash-out refinance coded as rate/term refinance
• Second home with non-matching lien status

The Fix: Review the business logic of each flagged loan. Verify that loan purpose, occupancy, property type, and lien status create a valid combination. Update any miscoded fields.

8. Ethnicity and Race Reporting Errors (V650-V654)

The Problem: Demographic data is missing, incorrectly aggregated, or uses invalid codes.

Common Causes:

• Using old demographic codes (pre-2018 format)
• Missing co-applicant data
• Visual observation not flagged when applicable
• Confusing ethnicity and race fields

The Fix: Use current HMDA demographic codes. Report "Information not provided" when applicants decline. Flag visual observation or surname-based identification when applicable.

9. Denial Reason Conflicts (V670, V671)

The Problem: Denial reasons are reported for approved loans, or missing/invalid for denied applications.

Common Causes:

• Denial reason reported for Action Taken = 1 (originated)
• No denial reason for Action Taken = 3 (denied)
• Using invalid denial reason codes

The Fix: Only report denial reasons when Action Taken = 3 (denied). Use valid denial reason codes (1-9 or 1111). Report up to four reasons per denied application.

10. Loan Amount vs Property Value Ratios (Q634)

The Problem: The loan-to-value ratio calculated from your data appears unrealistic.

Common Causes:

• Property value in dollars, loan amount in thousands (or vice versa)
• Using assessed value instead of appraised value
• Combined loan amount for refinances
• HELOC credit limit vs initial draw amount confusion

The Fix: Verify both loan amount and property value are reported in the same units. Use the appraised value at origination. For open-end credit, report the credit limit.

These are the same errors Comply HMDA/CRA catches automatically before you ever submit -- see how Comply catches these edits before submission.

Best Practices for Edit Check Success

Run Edit Checks Early and Often

Don't wait until February to run your first edit check. Test your data monthly throughout the year to catch systemic issues early when they're easier to fix.

Use Compliance-Grade Software

Consumer-grade tools may geocode addresses, but they don't guarantee FFIEC-compliant census tract assignments. Use software specifically designed for regulatory compliance.

Maintain Clean Source Data

Most edit check errors originate from your loan origination system. Work with your LOS vendor to ensure HMDA fields are captured correctly at the point of application.

Document Your Verification Process

For quality edits that you verify and leave unchanged, document why the data is correct. Examiners may ask about unusual patterns during your next compliance review. Comply DataMine can help you build a submission audit report that documents exactly which edits you reviewed and why.

Get Help Before the Deadline

If you're struggling with persistent edit check errors, don't wait until the last week of February. Professional compliance software can automate geocoding, rate spread calculations, and edit check validation—eliminating the most common errors before they occur.

Contact us for a demo to see how Comply can help you submit error-free HMDA data on time, every year.