The HMDA key data fields are the 37 of the 110 fields on the loan/application register (LAR) that the Federal Reserve, the FDIC and the OCC designated for examiners to test first. Each is tested the same way: the examiner pulls the loan file and compares the register value with the page it should have come from. So every key field is a claim about one page. The action taken date is a claim about the adverse action notice, income about the underwriter's worksheet, property value about the valuation the credit decision relied on. Many of the errors examiners cite are not typing slips but values taken from the wrong page, or from the right page at the wrong moment.
This page maps each key field to its source document, with the tolerance examiners allow and the usual way it goes wrong. It is the reference a data reviewer works from and a trainer teaches from. It is also the map that Botminds' HMDA and 1071 Data Validation runs on: agents that check every reportable field on every record against the loan file before the register is filed, and show the HMDA data manager only the fields that disagree.
The register, the key fields, and the little slack examiners give
110
data fields on each row of the 2026 HMDA loan/application register
FFIEC Filing Instructions Guide
37
of them designated key fields, tested first by the Federal Reserve, FDIC and OCC
Federal Reserve CA 18-9
21
key fields a partially exempt institution still collects and reports
same designation
4
fields where examiners tolerate any difference at all; every other field must match exactly
FFIEC transaction testing guidelines
Why do examiners test 37 of the 110 HMDA fields first?
Because three agencies agreed in 2018 that those 37 matter most to the analyses HMDA data feeds, weighing in part how often lenders had got them wrong. The Board, the FDIC and the OCC define key fields as "those data fields considered to be most important to ensuring the integrity of analyses of overall HMDA data". In choosing them, the agencies say they "took into account the likelihood that a data field would be reported correctly based on past examination experience" (Designated HMDA Key Data Fields). The list is partly a list of the fields examiners have learned to distrust.
The 37 cover the loan's identity and outcome, the property's location, the applicants' demographics, age and income, and the underwriting and pricing terms the 2015 amendments to Regulation C added. For an institution eligible for the EGRRCPA partial exemption, 21 of the 37 apply: the pricing, credit score, ratio and AUS fields drop away, while dates, amounts, action taken, census tract, demographics, age, income, lien status and units stay.
Two cautions before treating the list as the whole job. The designation is the Board's, the FDIC's and the OCC's; the CFPB and the NCUA are not parties to it. And the interagency FFIEC transaction testing guidelines say plainly that "all data fields within the sample may be reviewed". Rate spread, denial reasons and total loan costs are not key fields, yet they carry no tolerance and an examiner may still review them. A useful map covers the 37 and those three.
The stakes are not abstract. In 2022, collection errors under Regulation C §1003.4(a) were 239 of the 402 consumer-compliance violations the Federal Reserve cited at state member banks, 59.4% of the total (Consumer Compliance Outlook). The FDIC cited 72 HMDA violations in 2025, and 82% of them fell under the same section (FDIC Supervisory Highlights, March 2026). How a sample of those errors becomes an order to correct a field across the whole register is what an examiner counts as an error, set out on its own page.
The map: each HMDA key field, the document it comes from, and its tolerance
Read across a row to find where a field's value lives (the filled dot) and where a reviewer confirms it (the ring). Read the colour for the slack an examiner allows. Three patterns stand out. The application carries the identity and demographic fields. Every field whose definition in Regulation C says "relied on" lives in underwriting, not on the application. And the dates live on documents the borrower received, not in the origination system's status history.
The 37 HMDA key fields, mapped to the loan file
The map is not a new idea. The Federal Reserve's own sound-practice advice suggests worksheets with "references on where to find information in the loan file", such as where to find verified gross income for each loan type. The same article draws the line that matters for review:
Develop an autonomous verification process to review source documents; do not rely on information on HMDA worksheets.
Federal Reserve, Consumer Compliance Outlook, 2023
A check that compares the register with a worksheet, or with the origination system the register was built from, compares a value with itself. Only the source page can disagree. That is how a field-to-page check looks on screen in HMDA and 1071 Data Validation, on a fictional sample lender, Kestrel Valley Bank, used to demonstrate the solution:
HMDA and 1071 Data Validation draws each field to its page
What do examiners forgive? Four tolerances, and everything else exact
The FFIEC guidelines tell examiners not to count four kinds of difference as errors when they tally a field against the resubmission threshold. Every other field, including all the demographic, pricing and decision fields, has to match the file exactly. Their own example: if the file shows June 4 as the application date, June 1 and June 7 are not errors, May 31 and June 8 are.
The four HMDA tolerances, field by field
Not counted as an error: Three calendar days or less from the date received or the date on the application form.
Still counted as an error: Four calendar days or more from the date in the file.
Not counted as an error: Three calendar days or less.
Still counted as an error: Any difference, however small, that moves the record into the wrong calendar year.
Not counted as an error: $1,000 or less in the loan amount or the amount applied for.
Still counted as an error: More than $1,000, such as the amount applied for reported on an origination.
Not counted as an error: Rounding to the nearest thousand.
Still counted as an error: Any other difference, including income stated by the borrower instead of income relied on.
Not counted as an error: Nothing.
Still counted as an error: Any mismatch with the file. The six ethnicity fields for one applicant count as one field group, the eight race fields as another.
Tolerance is not a pass. The same guidelines let examiners require changes to "policies, procedures, audit processes" for errors that are capable of repetition, "even if the errors fall within the tolerances". A register that is routinely two days late on action taken dates is inside tolerance and still a finding waiting to happen.
Which date is the HMDA action taken date? It depends on the outcome
Regulation C's commentary gives a different rule for each outcome, and most allow a choice between two dates as long as the lender is "generally consistent". The error to watch for is not a wrong choice between permitted dates but a date that is not on the list at all.
Action taken date: what Regulation C allows, and the page to check
What Regulation C allows: Closing or account-opening date; the date of initial disbursement if later; for construction-permanent loans, the conversion date.
The page to check: The signed note and Closing Disclosure. The year is always the year of closing.
What Regulation C allows: Any reasonable date: the approval date, the deadline to accept, or the date the file closed.
The page to check: The approval or commitment letter, under the approach your procedure names.
What Regulation C allows: The date the action was taken, or the date the notice was sent.
The page to check: The signed credit decision or the adverse action notice, whichever your procedure picks.
What Regulation C allows: The date the express withdrawal was received, or the date on a written withdrawal.
The page to check: The withdrawal letter or the logged call, not the date the file was archived.
What Regulation C allows: The date the action was taken, or the date the notice was sent.
The page to check: The notice of incompleteness under Regulation B.
What Regulation C allows: The date of purchase.
The page to check: The purchase advice or settlement statement.
Take the sample lender's denied purchase application from the screen above. The register holds 03/14/2026. That is the day the origination system moved the file to Suspended for missing conditions. The credit decision was signed on 03/20, and the adverse action notice is dated and mailed 03/21. Regulation C would accept either of the later two; the lender's written procedure names the notice date. The status date is neither, and at six and seven days away it is outside the tolerance whichever date the procedure picks.
The page the action taken date is a claim about
The Suspended-status trap is worth a reviewer's suspicion wherever a system writes a date automatically. When one office files most of its denials this way, it stops being a record problem and becomes a process problem: the case study of the Suspended status date at one branch follows that thread.
Two smaller date rules catch people. The tolerance never rescues a date that crosses a year end: an application denied on December 30 and reported on January 2 is in the wrong register. And the application date may be the date received or the date on the form, but Regulation C expects one approach used consistently, at least within a division or a category of loans.
Income, DTI, CLTV and property value: report what the underwriter relied on
Five key data points are defined by what the lender relied on in making the credit decision: income, debt-to-income ratio, combined loan-to-value ratio, property value and credit score. Their values live in underwriting, and the application is the wrong page for every one of them.
Income is where examiners find it most plainly. The Federal Reserve cited lenders for "reporting the gross income the borrower provided rather than the income the institution relied upon". Regulation C's commentary is specific: a bonus is reported "to the extent relied upon", and income the lender does not rely on, such as commission earned for less than 12 months under its guidelines, is left out (Consumer Compliance Outlook). The value is reported in thousands, with $500 rounding up, so $35,500 is reported as 36.
On the sample record the register reports income of 148. The underwriter's worksheet shows $9,250 a month of base salary and $2,000 from the co-borrower, and excludes a $13,000 annual bonus for lack of a two-year history: $135,000 relied on. The register's own 47% debt-to-income ratio was computed on $135,000, which is a cross-check any reviewer can run: a DTI that only works with a different income is a signal that one of the two is wrong.
Income relied on comes from the worksheet, not the application
The other relied-on fields follow the same logic. Property value is the value the lender used for the loan-to-value calculation: the appraisal usually, the purchase price if that is what the underwriter used, and with several valuations on file, the one relied on. DTI and CLTV are the ratios relied on; if the lender computed them twice, under its own and an investor's guidelines, it reports the one used for the decision. All three are "not applicable" when the file was withdrawn or closed for incompleteness before a decision, even if the ratio had already been calculated (Regulation C commentary).
Loan amount sits on the note, not the application, for an origination: the amount to be repaid on the legal obligation. For a denial, a withdrawal or an incomplete file it is the amount applied for; after an accepted counteroffer, the amount granted. Credit score has its own trap: the Federal Reserve saw lenders report the credit bureau as the scoring model, "TransUnion" instead of a model code such as "FICO Risk Score Classic 04".
Pricing fields come from the Closing Disclosure, and rate spread has to be recomputed
Interest rate, loan term, origination charges, discount points and lender credits are key fields, and all of them are printed on the Closing Disclosure. The Federal Reserve found errors in discount points and lender credits "when staff manually entered the data", for example a $5,000 lender credit keyed as $500, and recommends populating them from the origination system rather than by hand. A reviewer still compares the register with the final, signed disclosure, because a corrected disclosure given to the borrower before the end of the quarter in which the loan closed changes the reportable figure for total loan costs.
Rate spread is not a key field, but it has no tolerance and it cannot be read off any page. It is the difference between the loan's APR and the average prime offer rate (APOR) for a comparable transaction on the date the rate was set. Recomputing it means getting five inputs right.
Five inputs to recompute an HMDA rate spread
- The APR, from the disclosure
The annual percentage rate as disclosed under Regulation Z, from the final Closing Disclosure for a closed-end loan.
- Fixed or variable
The amortization type picks the APOR table. A fixed loan priced on the adjustable-rate table is the mismatch to look for.
- The comparable term
Maturity for a fixed loan; the initial fixed-rate period for a variable one. Round to the nearest whole year; exactly halfway takes the shorter term.
- The rate-set date
The last date the rate was set before final action: the lock date, or the re-lock date after a float-down or an expired lock. Not the application date.
- Whether it is NA
Not applicable for denials, withdrawals, incomplete files, purchased loans, assumptions, reverse mortgages and loans not subject to Regulation Z. Approved but not accepted still reports a spread.
Census tract: the address, the geocoder and the year's boundaries
Census tract is the key field that is derived rather than read from a document: the property address, from the application or the appraisal, is geocoded to state, county and tract. Regulation C requires the boundaries and codes "in effect on January 1 of the calendar year" the register covers, so a geocoder working from an out-of-date census vintage can be wrong on records near a changed boundary.
Regulation C singles census tract out: an incorrect tract is deemed a bona fide error, not a violation, "provided that the financial institution maintains procedures reasonably adapted to avoid such an error" (§1003.6(b)(2)). The protection depends on the procedure existing. Re-geocoding every address against the current year's boundaries and comparing the result with the register is one such procedure. For an application denied or withdrawn before the property was known, the tract is "not applicable".
Ethnicity, race, sex and age: one form, counted as field groups
The demographic key fields all come from one place: the demographic information section the applicant completes, or the lender's record of what it observed. The application also carries the date of birth behind each age field. Two rules shape how these fields are tested. Under the FFIEC guidelines, the six ethnicity fields for an applicant count as one field group and the eight race fields as another, so one wrong code anywhere in the group is one error. The fields that record whether the information was collected by visual observation or surname are counted separately.
Collection follows Appendix B to Regulation C. When an application is taken in person and the applicant declines to give the information, the lender must collect it on the basis of visual observation or surname and report that it did so. A quieter error is easy to miss: the applicant completed the demographic form online and nobody keyed it, so the register says "not provided" while the file says otherwise. That is the break on a second sample record, and it is why the solution routes every ethnicity, race or sex correction to a second reviewer before it stands.
Action taken and denial reasons: the decision in the lender's own words
Action taken is a key field and denial reasons are not, but they come from the same two documents, the signed credit decision and the notice sent to the applicant, and they are best checked together. The commentary's rule on conditional approvals settles most disputes about the code:
- Underwriting or creditworthiness conditions not met: report a denial.
- More information requested with a written notice of incompleteness, and no response in time: file closed for incompleteness.
- Only customary closing conditions (clear title, survey, termite inspection) not met: approved but not accepted.
- The applicant expressly withdraws before the underwriting conditions are satisfied: withdrawn; after they are satisfied: approved but not accepted.
Denial reasons are the principal reasons, up to four. If the lender used the Regulation B model adverse action form or a similar form, the register reports the reasons stated on that form. That makes the notice the source of truth: on the sample record, "excessive obligations in relation to income" on the notice matches debt-to-income on the register. A reason carried over from an earlier decision, before an appraisal or a counteroffer changed it, is the pattern to watch for.
How HMDA and 1071 Data Validation checks every key field against the file
The map above is exactly what software needs to check a register, and it is what a person cannot apply to every record by hand. HMDA and 1071 Data Validation applies it to all of them. For each record it notes which fields apply to that outcome, finds the document and page each value comes from, recomputes rate spread and census tract, applies the examiners' tolerances and the lender's own procedure, and writes up every disagreement with both values, the rule and the page.
One record, every field, with the page it came from
The agents read; people decide. The agents never change the register or the origination system, and if a value has no source page the field is marked "no source" rather than guessed. The data manager corrects a break and signs it with a reason, or keeps the register value and says why. Ethnicity, race and sex changes need a second reviewer. The examiners' tolerances can be tightened in the settings, never loosened. How each of the six agents works, and what each is forbidden to do, is in the agents' own page, and the same field-to-page discipline carries over to small-business data in Section 1071 under the 2026 rule, where the revenue that decides coverage can turn on a tax return. To see the map running on a register, start from HMDA and 1071 Data Validation.
Questions people ask
What are the 37 HMDA key data fields?
ULI; application date; loan type; loan purpose; occupancy type; loan amount; action taken; action taken date; census tract; ethnicity field 1 for applicant and co-applicant; race fields 1 and 2 for each; sex and age for each; income; lien status; credit score for each; origination charges; discount points; lender credits; interest rate; debt-to-income ratio; combined loan-to-value ratio; loan term; property value; manufactured home secured property type; total units; AUS result 1; reverse mortgage; open-end line of credit; and business or commercial purpose.
Which key fields does a partially exempt bank still report?
Twenty-one: application date, loan type, loan purpose, occupancy, loan amount, action taken and its date, census tract, the eight ethnicity, race and sex key fields, age for each applicant, income, lien status and total units. The other sixteen, among them the ULI and the pricing, credit score, ratio, term, property value and AUS fields, are optional data under the partial exemption.
Is rate spread a HMDA key field?
No. It is not on the 2018 key-field list, and neither are denial reasons or total loan costs. But examiners may review any field, none of the three has a tolerance, and rate spread is easy to compute from the wrong APOR table or the wrong date.
How many HMDA data fields are there?
The 2026 filing format has 110 data fields per record, from the record identifier to business or commercial purpose, and the FFIEC says the required fields have not changed from the 2025 collection. They come from the 38 numbered paragraphs of Regulation C's §1003.4(a); many paragraphs expand into several fields, such as one for each race an applicant gives. Which of them apply to a record depends on its action taken: a denial has no rate spread.
Are there key data fields for Section 1071 small-business data?
No list like HMDA's has been published, but the rule itself sets a per-field test. Appendix F of the revised Regulation B treats errors as bona fide only while a random sample of 79 records, for a register of 1,000 to 100,000 applications, holds fewer than four in any one data field. Every field counts, so a practice register should start with the ones that decide coverage, such as gross annual revenue, and work outward.