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 range from simple data entry mistakes to logic conflicts between fields that need careful analysis to resolve. After helping institutions file HMDA data for nearly four decades we see the same ones appear again and again, and the pattern behind most of them is not carelessness but a mapping between an origination system and the LAR that was defined once and never revisited.

Here is how to identify and fix the ten most common HMDA edit check errors before they delay your submission. Every edit number below is quoted from the FFIEC Filing Instructions Guide for 2026, which is linked at the end.

Understanding HMDA Edit Check Types

The Filing Instructions Guide groups edits into three kinds, and knowing which kind you are looking at decides how urgently you have to act. Syntactical edits, numbered with an S, test the structure of the file itself, and there are only four of them; a file carrying one will not process at all. Validity edits, numbered with a V, test whether a value is one the field is permitted to take or whether two fields form an allowed combination, and they are equally mandatory: 109 of the 172 edits in the 2026 guide are validity edits, which is why most of a filing season is spent here. Quality edits, numbered with a Q, flag values that are unusual but may well be correct. A quality edit is a question rather than a defect, and the right response is often to verify the record, document why it stands, and leave it unchanged.

The 10 Most Common HMDA Edit Check Errors

1. V625: Why Is My Census Tract Invalid?

V625 requires Census Tract to be an eleven-digit number or NA, never blank, and where a number is given it must be a tract the Census Bureau actually defines. Almost none of what this edit catches is typing. The usual cause is geocoding against a stale boundary file: tract boundaries are redrawn at each decennial census, so a tool still carrying the previous vintage returns codes that were valid last cycle and are not now. The second most common cause is a spreadsheet or export that strips a leading zero and leaves a ten-digit tract behind, which fails the format test rather than the lookup. Re-geocode the property address with a compliance-grade engine referencing the current Census Bureau TIGER file for the filing year, and make sure the field is stored as text anywhere it passes through a spreadsheet. If a property genuinely has no tract, report NA rather than leaving the field empty, because blank is not the same answer.

2. V657: When Must Rate Spread Be Reported as NA?

V657 requires Rate Spread to be a number, Exempt or NA and never blank, and most of what it catches is conditional rather than arithmetic. Where Action Taken is 3, 4, 5, 6 or 7 — denied, withdrawn, file closed for incompleteness, purchased, or preapproval request denied — Rate Spread must be NA or Exempt rather than a computed figure. Institutions trip this when an origination system calculates a spread for every application regardless of outcome and the value is carried through to the LAR unchanged. The arithmetic fails less often, but when it does the cause is usually the wrong APOR table for the loan's term and rate type, or a lock date referenced against the wrong week. Check the spread against the current APOR tables using the FFIEC rate spread calculator or software with the tables built in, and then check the action-taken condition separately, because a correctly calculated spread on a denied application is still an edit.

3. V619: What Makes an Action Taken Date Invalid?

V619 makes three demands at once. Action Taken Date must be a valid date in YYYYMMDD format and cannot be blank; it must fall inside the reporting year; and where Action Taken is 1, 2, 3, 4, 5, 7 or 8 it must be on or after the Application Date. The third is the one that catches people, because it is a relationship between two fields rather than a property of one, so an import that maps both dates correctly in isolation can still produce an action date preceding the application it belongs to. The other frequent causes are a loan actioned in January that belongs to the prior year's file, and a date arriving as MM/DD/YYYY from a system that formats for human readers rather than for submission. Verify the format on import, confirm every action date sits inside the reporting year, and compare action date against application date across the whole file rather than sampling it.

4. V654, Q606 and Q629: Why Is Income Flagged When the Figure Looks Right?

Income is tested by one validity edit and two quality edits, and they fail for different reasons. V654 requires Income to be a positive or negative integer rounded to the nearest thousand, or NA, never blank, and it must be NA where Multifamily Affordable Units carries a number. Units are where this usually goes wrong: income is reported in thousands, so $85,000 is entered as 85, and a file carrying the full dollar figure will pass a format check while failing everything that reads it. Q606 asks you to confirm that any income reported as a number is generally below $10 million, entered as 10000 — that threshold is the condition as written in the 2026 Filing Instructions Guide edit tables, not a rule of thumb. Q629 works the other way and flags an unexpected NA: where Action Taken is 1, 2, 3, 4, 5, 7 or 8, Total Units is four or fewer and Loan Purpose is 1, 2 or 4, income generally should not be NA. Report the gross annual income actually relied on in the credit decision, in thousands; where income genuinely was not relied on, NA is the correct answer and the quality edit is satisfied by documenting why.

5. V608, V609, S306 and Q600: What Makes a ULI Fail?

Four edits guard the loan identifier and each catches a different failure. V608 is format: a ULI is alphanumeric, at least 23 characters and no more than 45, and cannot be blank, while a NULI is between 1 and 22 characters and cannot be NA, Exempt, 1111 or blank. V609 is the check digit, and it fires when the final two characters do not reconcile with the rest of the identifier, which in practice means the ULI was transcribed or re-keyed somewhere instead of being generated. S306 is one of the four syntactical edits and rejects a duplicate ULI on any record where Action Taken is 1. Q600 raises the softer version of the same question, a duplicate ULI or NULI anywhere in the file. The 23-character floor exists because a ULI begins with your institution's 20-character LEI and adds up to 23 further characters plus a check digit. Generate identifiers in software rather than by hand, and run the duplicate check across the whole file before submission, because a duplicate is invisible when you look at records one at a time.

6. V626 and V627: Why Do County and Census Tract Disagree?

These two test the county rather than the tract. V626 requires County to be a five-digit FIPS code or NA and never blank, which the same leading-zero loss that breaks census tracts will also break, since a large share of county FIPS codes begin with a zero. V627 is the combination edit and the more useful of the pair: where County and Census Tract are both reported as something other than NA, the first five digits of the census tract must match the reported five-digit county FIPS code. That check exists because the two fields are frequently populated from different sources, one from a geocoder and one from the loan file, so a property near a county line can produce two individually valid values that contradict each other. Geocode both fields from the same address in the same pass so they cannot diverge, and treat any record where they still disagree as an address problem rather than a coding problem.

7. V612 and V616: Why Does Preapproval Conflict With Loan Purpose?

V612 requires Loan Purpose to equal 1, 2, 31, 32, 4 or 5 and never be blank, and adds one conditional worth knowing: where Preapproval equals 1, Loan Purpose must equal 1. That pairing catches preapproval requests recorded against a refinance or home improvement purpose, which the reporting rules do not contemplate, and it is usually a workflow artefact rather than a data error. V616 is simpler and requires Occupancy Type to equal 1, 2 or 3. Files fail it when an origination system carries a fourth internal category, such as a second-home flag handled separately from investment property, and the mapping down to HMDA's three values was never defined. Both are worth resolving at the source rather than in the LAR, because a mapping gap that produced one invalid value this year will produce more next year.

8. V628–V634 and V635–V641: Why Do Ethnicity and Race Fields Come Back Invalid?

Ethnicity is tested by V628 through V634 and race by V635 through V641. They are separate fields with separate code lists and separate rules, and conflating them is itself a common source of failures. V628 requires Ethnicity of Applicant or Borrower: 1 to equal 1, 11, 12, 13, 14, 2, 3 or 4, and it cannot be left blank unless a free-form ethnicity is supplied instead; V635 does the same job for race across its own longer list. Most failures here are not a refusal to collect the data but a system storing an aggregated value where the LAR expects the detailed one, or leaving the field empty where an applicant did not provide it. There is a code for information not provided, and blank is not it. For applications taken in person where the applicant declines to provide the information, Regulation C requires it to be recorded on the basis of visual observation or surname, so those records still carry a value rather than an empty field.

9. V669, V670 and V671: Why Does a Denial Reason Conflict With Action Taken?

V669 sets the permitted values: Reason for Denial: 1 must equal 1111 or a number from 1 to 10 and cannot be blank, with the second, third and fourth reasons following their own rules. V670 generates most of the work, because it ties the field to Action Taken in both directions at once. Where Action Taken is 3 or 7, denied or preapproval request denied, Reason for Denial: 1 must be 1111 or a number from 1 to 9; and where Reason for Denial: 1 is a number from 1 to 9, Action Taken must be 3 or 7. The mirror image also holds, so where Action Taken is 1, 2, 4, 5, 6 or 8, Reason for Denial: 1 must be 1111 or 10. V671 covers the free-form field, which has to be completed when a reason of 9, Other, is reported. Populate denial reasons only on denied and preapproval-denied records, and never let one carry through from an internal system onto a withdrawn or approved file.

10. V617, V688 and Q623: Why Do Loan Amount and Property Value Trigger Quality Edits?

V617 requires Loan Amount to be a number greater than or equal to zero and never blank. V688 requires Property Value to be a number greater than zero, Exempt or NA, never blank, and it must be NA or Exempt where Action Taken is 4 or 5, withdrawn or file closed for incompleteness, because there is no value to report on a file that never reached that stage. Q623 is the quality edit that reads as a ratio problem: where Total Units is four or fewer and Income is $200,000 or less, reported as 200, Loan Amount generally should be under $2,000,000. All three of those figures are the Q623 condition values from the 2026 Filing Instructions Guide, quoted rather than approximated. When Q623 fires across many records at once the cause is almost always a unit mismatch, with one of the two fields in dollars and the other in thousands. Note that loan amount and property value are reported in dollars while income is reported in thousands, which is exactly the trap. Use the appraised value relied on at origination rather than an assessed value, and for open-end credit report the credit limit rather than the initial draw.

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

When Should You Run Your First Edit Check?

Do not wait until February to run your first edit check. Testing the data monthly through the year turns a filing-season crisis into routine maintenance, because the errors that take longest to fix are systemic ones in the mapping between your origination system and the LAR, and those produce the same failure on every record they touch. Found in March, that means re-working a full year of loans against a deadline. Found in April, it means one configuration change and nothing else.

Is Consumer-Grade Geocoding Good Enough for HMDA?

Consumer-grade tools will geocode an address, but they do not guarantee an FFIEC-compliant census tract assignment, and the difference only becomes visible when V625 or V627 fires on a file you were about to submit. Geocoding for compliance means the current TIGER vintage for the filing year, a documented match rate, and a defined behaviour for the addresses the engine cannot resolve, rather than a best guess returned silently alongside the ones it could.

Where Do Most Edit Check Errors Actually Originate?

Most edit check errors originate in the loan origination system rather than in the LAR itself, which is why fixing them in the submission file is repair work rather than a solution. Work with your LOS vendor so the HMDA fields are captured correctly at the point of application, and pay particular attention to the fields with internal categories that do not map one-to-one onto HMDA's code lists, since those are where a silent mapping gap can sit for a whole year before anyone sees it.

What Should You Record for a Quality Edit You Leave Unchanged?

For quality edits you verify and leave unchanged, record why the data is correct at the time you check it, not months later from memory. Quality edits are questions, and an examiner may ask the same question about the same unusual pattern at your next compliance review; a contemporaneous note answers it in a sentence. Comply DataMine can build a submission audit report that documents exactly which edits you reviewed and why you concluded each one stood.

Get Help Before the Deadline

If you are fighting persistent edit check errors, do not wait until the last week of February. Compliance software automates the geocoding, the rate spread calculation and the edit validation itself, which removes the largest categories of error before they reach the file rather than after. Contact us for a demo to see how Comply can help you submit error-free HMDA data on time, every year.

Source

Filing Instructions Guide for HMDA data collected in 2026, Federal Financial Institutions Examination Council and Consumer Financial Protection Bureau. ffiec.cfpb.gov/documentation/fig/2026/overview. Every edit number, permitted value and condition quoted above was read from the edit tables on that page on 1 September 2026, where the 2026 guide lists 172 edits in total: 4 syntactical, 109 validity and 59 quality. Edit numbers change between annual editions of the guide, so check the edition for your own filing year before relying on any number here. If you believe a reading on this page is wrong, tell us — we would rather fix it than be cited incorrectly.