HMDA Data Integrity for AI-Driven Loan Origination: The Reg C LAR Fields, the Resubmission Threshold, and the Audit File That Survives

The Filing Most Lenders Underestimate

Home Mortgage Disclosure Act reporting is the part of the mortgage compliance stack institutions consistently underestimate, because the LAR (Loan/Application Register) sits behind a once-a-year submission deadline and feels like reporting plumbing rather than active compliance. The CFPB's posture has been the opposite since the 2015 final rule expanded the LAR from twenty-three fields to over a hundred, and the agency's HMDA examination procedures treat LAR accuracy as a leading indicator of broader origination-process problems. The CFPB has imposed civil money penalties for HMDA reporting errors on multiple institutions and has set a resubmission threshold that requires re-filing when sampled error rates cross a low percentage on a single field. The threshold and the data-validation tooling the agency publishes are the operational reality the AI workflow has to clear.

We build the agent that handles application intake on mortgage origination platforms. A meaningful share of the 110 reportable LAR fields are populated by the agent from the consumer's conversation, from the documents the consumer submits, and from the upstream systems the agent calls into. The architecture below is the one that produces a LAR the institution can submit clean on the March 1 deadline and the audit file that the next exam will ask for.

What Reg C Actually Asks the LAR to Show

12 CFR 1003 requires a covered institution to collect, record, and report data on applications for, originations of, and purchases of covered loans, on an institution-wide loan-by-loan basis. The data points are at 12 CFR 1003.4(a) and the institution-level submission requirements at 1003.5. The HMDA Filing Instructions Guide (FIG) for the relevant filing year is the operational specification the LAR is built against, and the FIG updates annually with the regulatory year's data definitions.

The institution that misses the volume threshold for Reg C reporting in either of the two preceding calendar years is exempt, and the rural-and-low-volume exemptions narrow the scope further for smaller institutions. The institutions we work with are well above the threshold and report under the full data point regime. The exemptions are a narrow slice of the market and a more rapidly shrinking one, because the CFPB's intent is broad coverage and the institutions whose volume is in the gray zone tend to plan their compliance program around the assumption that they will be covered.

The data points sit in three families. Applicant and co-applicant demographics, including the government monitoring information (GMI) fields for ethnicity, race, sex, and age, which the Regulation C appendix B prescribes the collection procedure for. Loan and application characteristics, including the loan amount, the loan term, the interest rate, the rate-spread, the total points and fees, the lender credits, the prepayment-penalty period, the loan purpose, the lien status, and the property characteristics. Outcome data, including the action taken, the action-taken date, the denial reasons if applicable, the originated-and-purchased flags, and the AUS used and result. The agent participates in populating fields across all three families, and the integrity of each field requires a different architecture.

The Demographic Fields and the Voice-Channel Collection Problem

The GMI fields are the regulatory third rail. The Regulation C requirement at Appendix B is that the institution offer the applicant the opportunity to provide ethnicity, race, and sex information, that the institution accept the applicant's voluntary refusal to provide it, and that the institution observe and report the information based on visual observation or surname if the applicant does not provide it and the application is taken in person. The voice and online channel scripting under HMDA Appendix B amendments accepts the applicant's response or refusal but does not allow visual-observation reporting, because the loan officer cannot observe an applicant the loan officer never sees.

The agent that takes the application on a voice or text channel offers the GMI questions in the rule's prescribed form, accepts the applicant's election, and codes the response into the LAR. The agent does not infer demographics from the applicant's name, voice, or other signals. The temptation to do so is not subtle, and the validator stops the agent from any response generation that touches inferred demographic categorization. We have written separately on the fair-lending program that runs disparate-impact analysis on the resulting LAR; the integrity of the analysis depends entirely on the integrity of the GMI fields, and any inference contamination at intake propagates through to the analysis and produces conclusions the institution cannot stand behind.

The Reg C rules around "information not provided" coding for online and mail applications are precise. The applicant who declined to provide the information on a covered application is coded one way; the applicant who provided some categories and not others is coded category by category. The agent's intake script and the LAR field population logic have to handle the partial-response case correctly, and we instrument the agent to log the consumer's actual words for each demographic question alongside the coded field value, so the LAR's integrity is reconstructible from the conversation transcript and not just from the field value the system stored.

The Rate Spread and the Section That Catches the Errors

The rate-spread field is the one that most consistently produces resubmission findings on examination, because the calculation depends on the APR, the Average Prime Offer Rate (APOR) for the relevant date and term, and a specific calculation methodology the FIG specifies. The rate-spread is the APR minus the APOR, the APOR is taken from the FFIEC rate-spread calculator for the closing date or the application date depending on which field, and the calculation has rounding and term-mapping conventions that the FIG documents precisely.

The agent that quotes a rate during conversation, captures rate-lock information, and feeds the loan-origination system the data that eventually populates the APR field has to keep the data points clean enough for the rate-spread calculation to produce the correct answer. A rate quoted in conversation that is not in the rate field the LAR pulls from, an APR that is calculated on the wrong loan amount because the loan amount was updated mid-application without the APR refresh, or a term that the LAR represents in months when the system stored in years, each produces a rate-spread error that propagates to the LAR and the CFPB's data-validation tooling catches.

The architecture we run logs the rate, the loan amount, the term, the APR, the lock date, the application date, and the closing date in the agent's per-application provenance file. The provenance file is the audit trail the rate-spread calculation runs against, and the rate-spread is recomputed at LAR generation time rather than at the moment any single field changed during the loan life cycle, because intermediate calculations during the loan's active period are not what the LAR reports. The CFPB's LAR formatting tool validates the file against the FIG's formats before submission, and the institutions whose internal validation runs the same checks before submission are the institutions whose submissions do not fail the validator on the first pass.

The Action Taken and the Action-Taken-Date Field

The action-taken field at 1003.4(a)(8) reports what happened to the application: originated, approved-not-accepted, denied, withdrawn by applicant, application closed for incompleteness, purchased loan, preapproval-request-denied, or preapproval-request-approved-but-not-accepted. The action-taken-date is the date the action was taken. The two fields together are central to the LAR's purpose because the institution's denial rates, withdrawal rates, and approval rates by demographic group are the data the CFPB analyzes for disparate impact.

The AI agent's role in the action-taken field is significant because the agent has visibility into the moments the action was taken. The withdrawal by applicant is the action most consistently misclassified across the industry. The applicant who stopped responding to outreach is not, under the rule, a withdrawal unless the institution can document an affirmative withdrawal communication. The institutions that code unresponsive applicants as withdrawals to clean up their pipeline are coding cases as withdrawals that the CFPB will read as constructive denials, and the disparity analysis the CFPB runs on the data does not credit the institution's choice of label.

We instrument the agent to log the specific consumer statement that produced any withdrawal classification, with the timestamp and the channel. The withdrawal-by-applicant code requires the consumer's affirmative request to withdraw or a similar express statement; absent that, the case is coded "application closed for incompleteness" with the incompleteness reason or, if the institution made an adverse credit decision, "denied" with the denial reasons. The agent's classification at the moment of action is auditable to the conversation that produced it, and the LAR record is reconcilable to the underlying file rather than to the institution's pipeline-management labels.

The action-taken date is the date of the final action, not the date the loan officer entered the action in the LOS. The rule is specific because the date drives several downstream calculations including the rate-spread APOR lookup. The agent records the actual date of the action separately from the LOS entry date and the LAR pulls from the action date. An institution whose LOS conflates the two and whose AI workflow does not surface the difference is an institution whose LAR will produce action-date errors clustered around long weekends and holidays.

The Denial Reasons and the ECOA Coordination

The denial-reasons fields at 1003.4(a)(16) are reported when the action taken is "denied" or "preapproval request denied," and the institution reports up to four denial reasons drawn from the FIG's enumerated list. The denial-reason taxonomy on the LAR is similar to but not identical to the denial-reason taxonomy on the Regulation B adverse-action notice, and the institution has to reconcile the two so the LAR and the adverse-action notice do not contradict each other on the same loan.

The agent that drafts the adverse-action notice from the institution's underwriting outcome is also feeding the LAR denial-reasons field. We have the agent source both from the same authoritative reason set, with the LAR codes and the ECOA notice language both derived from one underlying reason taxonomy maintained in the institution's underwriting policy. An institution whose LAR shows "debt-to-income ratio" as the denial reason and whose adverse-action notice to the same consumer shows "credit history" is an institution whose first fair-lending review will produce a finding before anyone evaluates the substance of the denial.

The "credit application incomplete" and "other" codes are the codes the CFPB looks at most closely because they are the codes institutions use to avoid committing to a specific reason. An LAR that uses "other" disproportionately or that uses "credit application incomplete" on cases where the application appears substantively complete in the file is an LAR the examiner will sample heavily. The agent's denial-reason coding is the moment to write a specific reason supported by the underwriting evidence, and the institution that resists the tendency to default to "other" at the agent layer is the institution whose denial-reasons distribution is defensible.

The AUS, the AUS Result, and the Data Loop

The Automated Underwriting System fields at 1003.4(a)(35) report the AUS used (Desktop Underwriter, Loan Product Advisor, Guaranteed Underwriting System, Total Mortgage Scorecard, internal proprietary system, or "other") and the AUS result the institution used in the credit decision. The reporting requirement is that the institution report the system that was used and the result that was relied on, not necessarily the most recent result the system produced.

The agent that handles application processing usually orchestrates multiple AUS runs as the application develops: initial submission, revised submission after document collection, final submission before disclosure. The LAR has to pull the version that was used in the credit decision, which is typically the last run before the action was taken. We log every AUS submission with the timestamp, the version, the result, and the conditions, and the LAR generation pulls the last submission preceding the action date. An institution whose LAR pulls the AUS result that happened to be in the LOS at LAR-generation time is an institution whose LAR may report a different result than the one that drove the decision, particularly on loans where late-stage re-runs occurred after the action date for portfolio-management or QC purposes.

A separate problem is the institution that runs a proprietary AI scoring model alongside the third-party AUS and uses the proprietary model to override the AUS recommendation. The LAR reporting at the AUS field has to reflect the system the institution actually relied on, which may be the proprietary model rather than the AUS. The institutions we work with that have this pattern report the AUS used and the AUS result and report the proprietary system separately if applicable, and the documentation in the loan file makes the override visible. An institution whose LAR reports "Desktop Underwriter Approve/Eligible" on a loan the underwriter overrode based on a proprietary model the LAR does not name is an institution whose data does not reflect the actual decision process and whose disparate-impact analysis will produce conclusions disconnected from the underlying decisions.

The Resubmission Threshold the CFPB Holds Institutions To

The CFPB's HMDA examination procedures and the agency's resubmission guidance establish the threshold above which an institution is required to scrub and resubmit its LAR. The thresholds are field-specific and broadly the rule is that an error rate above a percentage of sampled entries on a single field triggers the resubmission. The thresholds for some fields (the demographic data, the GMI fields, the action-taken field) are lower than for others, and a sampled error rate above five percent on a single critical field is the kind of finding that produces a resubmission requirement.

The resubmission is not just the operational pain of re-filing. The resubmission is a public record of LAR data-quality problems that the agency and the public will read against the institution's fair-lending posture and against its broader compliance management. An institution that has resubmitted on demographic data in the past two cycles will have a harder fair-lending exam than an institution whose LAR has been clean.

The validation we run at LAR generation reproduces the CFPB's sampled-error analysis methodology against the institution's full LAR and reports field-by-field error rates against the institution's internal targets, which are set well below the resubmission threshold. An error rate at two percent on a field is not a resubmission risk; it is an early indicator that the field's data-flow has a systematic problem the institution can fix during the year rather than at the submission deadline. The AI agent's field-population logic feeds into this validation, and the validation feeds back into agent-side improvements during the year.

The Field-Provenance File the Agent Produces

The architecture that survives the next exam keeps a field-by-field provenance record for each loan. The provenance file records the field name, the value reported on the LAR, the data source that produced the value (the agent's intake conversation, the consumer's uploaded document, the AUS response, the LOS calculation), the timestamp the value was last updated, the user or system that updated it, and any override history. The file is built into the loan record rather than into the LAR generation pipeline, because the provenance has to survive after the LAR is filed and the loan moves to servicing.

A loan with the provenance file present is a loan the examiner can reconstruct end-to-end. The examiner asks "where did the action-taken date come from on this loan," and the file answers "the agent classified the action at 2026-03-14 18:42 UTC when the consumer said 'we want to put this on hold,' the underwriter confirmed the withdrawal classification at 2026-03-14 19:15 UTC, and the action-taken-date pulled from the underwriter's confirmation timestamp." The institution that produces this provenance per loan is the institution whose LAR data integrity does not need to be defended on faith.

The LAR itself does not carry the provenance; the LAR is what the FIG specifies. The provenance is in the loan-level record retention that the institution maintains under 12 CFR 1003.5(d), which requires retention of the LAR for three years and of the underlying loan file for the same period. The institutions we work with treat the provenance file as part of the underlying loan file and retain it for the full retention period.

The Modified LAR and Public-Facing Data

The CFPB publishes a modified LAR annually that strips certain fields to protect borrower privacy and makes the rest public. The public modified LAR is the dataset that journalists, advocates, and competitors use to analyze institutional behavior, and it is the dataset that produces media stories on disparate-impact patterns. The institution whose LAR has data-integrity problems will have those problems visible in the modified LAR's public release, and the public-relations and reputational dimension of HMDA reporting is the dimension institutions sometimes forget when they focus only on the resubmission threshold.

We treat the modified LAR as the institution's published statement about its lending. The institutions we work with run pre-publication analysis against the modified LAR to identify the patterns the public dataset will reveal, to ensure the patterns are explainable, and to confirm the institution's fair-lending posture is reflected accurately in the data. A pattern that surprises the institution at publication is a pattern that will surprise the institution's stakeholders less favorably.

The Cross-Walk to ECOA, Fair Housing, and the State Examiner

The HMDA data is the dataset on which the CFPB, the federal banking agencies, HUD, the DOJ, and the state attorneys general run disparate-impact and disparate-treatment analysis under ECOA, the Fair Housing Act, and the state-level fair-lending statutes. The data integrity question and the substantive fair-lending question run in parallel. An institution with clean HMDA data and a substantively fair lending program produces a defensible fair-lending posture. An institution with messy HMDA data and the same substantively fair program produces a posture where the data-quality issues become the wedge regulators use to question the substantive program.

We have written separately on the fair-lending testing program the institutions we serve run on top of the HMDA data. The testing requires accurate HMDA data as the input; the LAR's integrity is the precondition. An institution that builds the fair-lending program without first fixing the LAR pipeline is an institution that is testing against unreliable data and that will discover the reliability problem at the worst possible moment, which is usually after the data has already been published.

The state-level dimension matters because several states (New York, Massachusetts, California, Texas, Illinois) maintain state-level mortgage examination programs that pull the HMDA data into the state exam, often with state-specific overlay analysis. The Massachusetts DOB and the New York DFS are both active on state-level fair-lending analysis using HMDA data, and the institution's LAR is the foundation for both the federal and the state-level analyses.

How the LAR Generation Runs in Practice

The LAR generation we run for our customers is a per-quarter pipeline that produces a draft LAR, runs the institution's internal validation against the FIG specifications and against the CFPB's resubmission-threshold benchmarks, and produces an exception report the institution's HMDA team works through. The exception report lists each field where the validation flagged a potential issue, the loans involved, the underlying data, and the recommended correction. The correction flows back through the loan record and through the agent's field-population logic if the issue's root cause was upstream.

The annual submission then runs against a final clean LAR that the institution's HMDA team has signed off on field by field. The submission goes through the HMDA Platform and the platform's data validation runs the FIG checks before the file is accepted. A submission that fails the platform's validation is one the institution corrects and resubmits before the deadline.

The post-submission monitoring tracks the CFPB's published data on aggregate institutional performance and identifies any patterns where the institution's data diverges from peer institutions in ways that may produce examiner attention. The patterns are not necessarily problems; they may reflect the institution's portfolio mix or geography. The point of the monitoring is for the institution to have an explanation prepared before the examiner asks.

The Failure Mode We Engineered Against

The pattern that produced the worst outcome on the first program we ran this against was an institution whose AUS was reporting Approve/Eligible on the LAR for a population of loans where the underwriter had documented overrides because of an income calculation the AUS got wrong on self-employed borrowers. The LAR field said the AUS approved the loans; the underlying loan files showed the underwriter approved the loans on a basis that differed from the AUS recommendation. The disparate-impact analysis the CFPB ran on the LAR data produced findings on a basis that did not reflect the underwriter's actual analysis, and the institution spent two cycles defending an analysis that, on the underlying decisions, was defensible.

What we changed is that the LAR field on AUS reflects the AUS the institution actually relied on, which on these loans was the underwriter's override decision and the supporting analysis. The LAR now reports "internal proprietary system" with the override result on the loans where the AUS's recommendation was not the basis of the decision. The fair-lending analysis on the new LAR reflects the institution's actual decision process, and the conversations with the agency moved from defending the data to defending the substantive policy. The conversation about the substantive policy is the conversation the institution can win on the merits, because the policy was sound and the documentation supports it. The conversation about the data was the conversation that obscured the merits.

The other change is that the agent's intake script for self-employed borrowers explicitly captures the data points the AUS often gets wrong, and the underwriter's override path is documented at the moment of override rather than reconstructed later. The provenance file for these loans now shows the AUS recommendation, the override decision, the supporting evidence, and the LAR field population, and the file is the institution's defense in the next exam cycle.

The Cost of Treating This Casually

A LAR with material data-integrity problems produces several costs the institution does not always price correctly. The direct cost of the resubmission is moderate. The cost of the next exam, which will be longer and more searching, is larger. The cost of the fair-lending analysis that has to be run on questionable data and the cost of defending it are substantial. The reputational cost of the public modified LAR carrying patterns the institution cannot explain is the cost that materializes in board meetings and in lender-of-choice decisions by referral sources. The cost of the consent order that follows a finding of systemic LAR data integrity problems is the cost institutions remember.

The architecture above is not expensive to build relative to those costs. The LAR pipeline runs on data the institution already has, with validation that reproduces the CFPB's published methodology. The provenance file is the kind of artifact the institution would want to have anyway for its own quality control. The institution that runs the architecture treats HMDA reporting as the operational discipline it is. The institution that does not run it is building toward the next cycle of resubmission and toward the next exam that will read the resubmission against the institution.

We have written on the adverse-action notice machinery that coordinates with the LAR denial-reasons field, the fair-lending program that consumes the LAR data, and the model-risk discipline that the AUS-and-proprietary-model override pattern sits inside. HMDA is the data layer underneath all of them, and the institution that gets the data layer right gets the layers above it right by extension. The institution that gets the data layer wrong has to defend the layers above on a foundation that will not hold.