Use the FFIEC's "A Guide to HMDA Reporting: Getting It Right!" alongside the Filing Instructions Guide (FIG) as your two anchor documents, with Regulation C governing every substantive requirement between them. Three actions matter most right now: confirm your institutional coverage status, run your loan application register (LAR) against current FIG edits before you touch the submission portal, and lock your calendar around the March 1 filing deadline for the prior calendar year’s data.
Immediate next steps for this filing cycle:
- Verify coverage using both the depository and nondepository tests, including any partial exemption eligibility.
- Run a full FIG-edit simulation on your LAR file to catch blocking errors before submission.
- Submit through the HMDA Platform and retain the signed certification along with your final edit report.
Automate Regulatory Model Risk Governance
Examine models against 32 qualitative criteria and resolve risk Tiers with pre-deployment checklists per OCC 2011-12 guidelines.
Collection happens continuously throughout the calendar year; filing happens once, and the clock does not pause for internal sign-off delays.
Table of Contents
- Who Must Report Under HMDA Reporting Requirements
- What to Collect: Reportable Transactions and Data Fields
- How to File: FIG, File Specs, and the HMDA Platform
- Data Validation: Clearing Edits Before You Certify
- Practical Compliance Checklist and Where Automation Fits
- Handling HMDA Reporting Through Mergers and Acquisitions
- Privacy and Confidentiality in HMDA Data Reporting
- Correcting or Amending Previously Submitted HMDA Data
- Penalties and Risks of Inaccurate HMDA Reporting
- Primary Agency Documents and Submission Portals
- What Most Institutions Get Wrong About HMDA Compliance
- A Faster Path Through HMDA Filing Season
- Sources
Who Must Report Under HMDA Reporting Requirements
Coverage hinges on two separate tests, and missing either one is how institutions end up filing when they shouldn't, or skipping a filing they owed. Depository institutions (banks, savings associations, credit unions) trigger coverage based on asset size, federally related loan activity, and a closed-end or open-end loan-volume threshold measured over the two preceding calendar years. Nondepository institutions face a different test built around loan origination volume and the percentage of their business tied to mortgage lending, with no asset-size component at all.
Partial exemptions complicate the picture further. Institutions that meet specific volume thresholds can skip certain data points, but that exemption depends on the same two-year lookback used for coverage, not a static one-time determination. An institution that qualified for a partial exemption last year isn't automatically exempt this year.
Run this sequence before you assume your status:
- Pull total assets and loan origination counts for the prior two calendar years.
- Apply the depository or nondepository coverage test as applicable to your charter type.
- Check partial exemption thresholds separately, since coverage and exemption are two distinct calculations.
- Document the determination in writing for your compliance file, not just in an email thread.
Pro Tip: Re-run your coverage test every January, even if nothing about your institution "feels" different. Loan volume creeps, mergers happen, and a threshold you cleared comfortably two years ago can quietly become a problem.
What to Collect: Reportable Transactions and Data Fields
Covered transactions include closed-end mortgage loans and open-end lines of credit secured by a dwelling, whether originated, purchased, or in some cases merely applied for and withdrawn or denied. Common exclusions include temporary financing, construction-only loans in certain structures, and loans below the applicable dollar or transaction-volume thresholds for open-end credit.
The LAR itself demands a dense set of fields, and getting any one of them wrong tends to cascade into edit failures downstream:
- Applicant and co-applicant demographic data (ethnicity, race, sex, age)
- Action taken and the date of that action
- Loan purpose, amount, and property type, including whether the property is a manufactured home or multifamily dwelling
- Pricing data, including rate spread and total loan costs where applicable
- Automated underwriting system (AUS) results and specific denial or approval reasons
Required data fields for 2026 didn't change materially from the prior year, according to the current FIG, which is good news for institutions that already have stable data mapping in place. Demographic fields carry particular sensitivity: applicants can decline to provide race, ethnicity, and sex, and your system must record that refusal accurately rather than leaving the field blank or guessing based on visual observation or surname. Retain source documentation for every collected field, since examiners will ask to trace LAR entries back to loan file evidence.
How to File: FIG, File Specs, and the HMDA Platform
The FIG isn't a companion document you skim once. It's the definitive technical rulebook, specifying every valid value, every field's exact format, and the pipe-delimited text structure your LAR file must follow before the HMDA Platform will accept it. Agency guidance is explicit that the Guide explains what to report while the FIG governs how to report it, and treating them as interchangeable is a common source of avoidable resubmissions.
Follow this sequence when preparing your submission:
- Export your LAR from your loan origination system in the pipe-delimited format the FIG specifies field by field.
- Validate every coded field (loan purpose, action taken, denial reason) against the FIG's valid-value tables, not your system's internal codes.
- Upload the file to the HMDA Platform and review the automated edit report it generates.
- Certify the submission once all blocking edits are resolved and the data reflects your institution's actual lending activity.
- Retain the platform's confirmation and edit report as your certification record.
Formatting errors that trip up filers most often: mismatched delimiters from spreadsheet exports, truncated census tract codes, and denial-reason fields left blank when action taken indicates a denial.
Pro Tip: Open your LAR file in a plain text editor before uploading, not just Excel. Spreadsheet programs love to "fix" leading zeros and reformat dates in ways that silently break the FIG's exact field specifications.
Data Validation: Clearing Edits Before You Certify
The HMDA Platform's edit report splits into two categories that demand different responses. Blocking (syntax and validity) edits must be resolved before the platform accepts your submission at all. Quality and macro edits are advisory. They flag statistically unusual patterns, like an outlier interest rate or an improbable income relative to loan amount, but they don't prevent filing if you've reviewed and can justify the discrepancy.
Build your pre-file validation around these checks:
- Geocode every property address against FFIEC's census and geocoding tools to confirm census tract accuracy, since geocoding mismatches are one of the most frequent edit triggers.
- Run income and loan-amount plausibility checks to catch data entry errors before the platform's macro edits do.
- Cross-reference required-value fields against the current FIG's valid-value tables, not last year's cached version.
- Reconcile your LAR record count against your origination system's total closed-end and open-end volume for the period.
Document every resolved edit, including the explanation for any advisory flag you chose not to change. Examiners reviewing your HMDA file will want to see that quality edits were investigated, not just dismissed.
One tight declarative point worth repeating to your team: an unresolved blocking edit stops your filing cold, while an unresolved quality edit only stops your credibility with examiners if you can't explain it later.
| Point | Details |
|---|---|
| Blocking edits halt filing | The HMDA Platform won't accept a LAR until every syntax and validity edit is cleared. |
| Quality edits need documentation | Advisory flags don't block submission but require a written justification on file. |
| Geocoding drives most errors | Address-to-census-tract mismatches are among the most common edit triggers. |
Practical Compliance Checklist and Where Automation Fits
Mapping FFIEC and CFPB guidance to daily operations comes down to six repeatable steps, and most filing failures trace back to skipping one of them under year-end time pressure.
- Run the institutional coverage test and document the determination.
- Inventory every system that touches loan origination data, including third-party AUS platforms.
- Map each required FIG field to its system of record, not to a spreadsheet someone maintains manually.
- Simulate FIG edits locally against your LAR draft before it ever reaches the HMDA Platform.
- Correct flagged records and document the resolution for each.
- Submit, certify, and archive the platform's confirmation and edit report.
Automation earns its place at three specific points in that sequence: geocoding validation against current census boundaries, enforcement of FIG valid-value tables before export, and edit simulation that flags blocking errors while you can still fix them cheaply. Manual spot-checks on a 40,000-record LAR simply can't catch what a systematic pre-submission edit pass will.
Riskinmind's platform is built around exactly this kind of pre-submission automation and regulatory reporting workflow support, and compliance teams researching how these steps connect to broader reporting infrastructure can review our financial institution compliance process guide for the operational context.
Pro Tip: Simulate FIG edits at least two weeks before your internal deadline, not two days before the regulatory one. Resolving a blocking edit on a Tuesday afternoon is routine; resolving forty of them the night before March 1 is how institutions end up filing late.
Handling HMDA Reporting Through Mergers and Acquisitions
Mergers and acquisitions create one of the messiest HMDA scenarios compliance officers face, largely because coverage determinations, LAR ownership, and reporting periods don't automatically transfer cleanly. When one institution acquires another mid-year, the surviving institution generally assumes reporting responsibility for the acquired entity's covered loans originated before the transaction closed, but the specific treatment depends on the legal structure of the deal and whether the acquired institution's charter survives.
The practical challenge is data continuity. Acquired institutions often run different loan origination systems, use different internal field codes, and may have inconsistent geocoding practices. Before you can file a combined LAR, you need to reconcile two data schemas into one that matches current FIG specifications, which means mapping the acquired institution's fields to your own system of record rather than simply appending their export to yours.
Coverage status itself can shift the year of a merger. A newly combined institution's asset size and loan volume may cross a threshold that neither predecessor institution hit independently, triggering coverage where none previously existed. Run the coverage test fresh, using combined figures, rather than assuming the acquiring institution's prior status carries forward unchanged.
Timing matters too. If the transaction closes mid-year, determine which entity is responsible for filing the stub period, and get that determination in writing well before your internal deadline. Waiting until January to sort out who owns the acquired institution's fourth-quarter LAR data is a common and entirely avoidable scramble.
Privacy and Confidentiality in HMDA Data Reporting
HMDA data collection puts compliance teams in an unusual position: they're required to collect sensitive demographic information, including race, ethnicity, and sex, while simultaneously protecting applicants from having that same data misused internally. The regulation resolves this tension through a strict separation requirement, often called the "firewall," which restricts underwriting and pricing personnel from accessing demographic fields during the credit decision itself.
In practice, this means your loan origination system needs role-based access controls that keep demographic data visible to compliance and reporting functions while walling it off from underwriters making the actual credit decision. An institution that lets loan officers see race and ethnicity fields while reviewing an application isn't just creating fair-lending risk. It's undermining the entire purpose of the data-collection firewall Regulation C is built around.
Public disclosure adds another layer. The CFPB publishes modified LAR data annually, and certain fields get excluded, rounded, or randomized specifically to prevent re-identification of individual applicants, particularly in low-volume census tracts where a handful of records could otherwise be traced back to a specific borrower. Institutions don't control that redaction process directly, but understanding it helps when applicants or advocacy groups ask why certain figures in the public dataset look approximate rather than exact.
Internally, retain demographic data with the same access logging you'd apply to any protected personal information, and make sure your data retention schedule for HMDA records aligns with your broader recordkeeping policy rather than sitting as an orphaned exception.
Correcting or Amending Previously Submitted HMDA Data
Errors discovered after submission aren't rare, and the correction process is more structured than many compliance officers expect. If you identify an error before your annual certification is finalized, you can typically correct it through a straightforward resubmission on the HMDA Platform, which will regenerate the edit report against your updated file.
The harder cases involve errors discovered after certification, sometimes during a subsequent exam or an internal audit months later. In those situations, the resubmission still runs through the same platform mechanism, but you'll need to document why the correction is necessary, what specifically changed, and how the error occurred in the first place. Examiners reviewing a late correction want to see that your institution caught the problem through its own controls, not because a regulator flagged it first.
Materiality matters here. A handful of corrected census tract codes affecting a small percentage of your LAR is a routine fix. Systemic errors, like a mapping mistake that mis-coded loan purpose across an entire product line, point to a control weakness that examiners will want addressed at the process level, not just patched at the data level.
Keep a running log of every post-certification correction, including the date discovered, the root cause, and the resubmission confirmation. That log becomes your best evidence during the next exam cycle that your data governance actually works, rather than a claim you're making without backup. Institutions that treat corrections as isolated, undocumented fixes tend to face harder questions the second or third time an error surfaces.
Penalties and Risks of Inaccurate HMDA Reporting
Inaccurate or late HMDA reporting carries consequences that extend well beyond a stern letter from your regulator. Civil money penalties are the most direct exposure, and prudential regulators have discretion to assess them based on the severity, pattern, and duration of the reporting failure, with larger institutions and repeat errors typically facing steeper scrutiny.
Beyond formal penalties, inaccurate HMDA data creates fair-lending exposure that compounds over time. Regulators and researchers use HMDA data to identify potential redlining or disparate-treatment patterns, and systematically flawed data, whether from bad geocoding, miscoded denial reasons, or inconsistent demographic collection, can produce false signals that trigger a fair-lending exam an institution didn't otherwise deserve. Conversely, genuine disparities can get masked by sloppy data, delaying a problem an institution actually needs to fix.
Examiners also weigh HMDA accuracy as a proxy for the overall strength of an institution's compliance management system. A LAR riddled with resolvable errors suggests weak internal controls broadly, not just a narrow HMDA problem, and that impression tends to color the entire exam, including areas that have nothing directly to do with mortgage disclosure.
Reputational risk rounds out the picture. HMDA data is public, and journalists, advocacy groups, and competitors all use it. An institution that files data later shown to be materially wrong, especially around demographic or pricing fields, faces a credibility problem that's harder to repair than the underlying data error itself. The most reliable protection against all of these outcomes is the same discipline this guide has walked through: resolve blocking edits before filing, document every judgment call, and treat coverage and correction determinations as decisions worth writing down.
Accurate HMDA reporting depends on running institutional coverage tests correctly, validating every LAR field against current FIG specifications, and resolving blocking edits before certification.
| Point | Details |
|---|---|
| Confirm coverage annually | Loan volume and asset thresholds shift year to year, so re-run the coverage test each cycle. |
| Treat Guide and FIG as separate tools | The FFIEC Guide explains coverage; the FIG governs the exact technical filing specifications. |
| Resolve blocking edits first | The HMDA Platform won't accept a submission until validity edits clear, regardless of deadline pressure. |
| Document mergers and corrections | Write down coverage changes after M&A and log every post-certification correction with its root cause. |
| Automate pre-submission checks | Platforms like Riskinmind simulate FIG edits and geocoding validation before filing to cut resubmission risk. |
Primary Agency Documents and Submission Portals
Start with the FFIEC Guide for coverage questions and the FIG for filing mechanics.
- A Guide to HMDA Reporting: Getting It Right! (FFIEC)
- Filing Instructions Guide (technical specs)
- CFPB HMDA filing resources
- Federal Reserve supervisory letter
What Most Institutions Get Wrong About HMDA Compliance
The conventional advice on HMDA compliance treats it as a once-a-year filing event, something you handle in a concentrated push each February. That framing is backwards, and it's the reason so many institutions end up resolving preventable edits under deadline pressure. HMDA compliance is a data governance discipline that runs continuously through the calendar year. The filing deadline just happens to be when your yearlong data quality gets graded all at once.
The more useful judgment call this guide supports: geocoding and field-mapping errors, not demographic data collection, are where most institutions lose the most time. Compliance teams spend disproportionate energy worrying about sensitive demographic fields, understandably, but the edits that actually block filings tend to trace back to census tract mismatches and coded-value errors that better upstream validation would have caught months earlier.
If you prioritize one thing this year, prioritize pre-submission edit simulation over last-minute manual review. A LAR checked continuously against FIG valid values as data accumulates beats a LAR reviewed exhaustively once, right before the deadline, every time.
— Raj
A Faster Path Through HMDA Filing Season
Riskinmind gives compliance teams what a spreadsheet-and-checklist workflow can't: continuous, automated validation against current FIG standards instead of a single frantic review before the deadline. Institutions relying on manual geocoding checks and periodic spot audits catch errors late, often after they've already compounded across thousands of LAR records.
Riskinmind's loan application tools ingest origination data continuously and flag field-mapping issues, geocoding mismatches, and FIG valid-value errors as records are created, not months later during your pre-submission scramble. For institutions managing HMDA reporting alongside broader portfolio monitoring, the platform's peer benchmarking tools also help compliance and portfolio teams contextualize lending patterns the way examiners and public HMDA data eventually will.
If your team is still reconciling coverage tests and edit reports by hand each filing season, book a demo with Riskinmind to see how automated pre-submission validation fits into your existing loan origination workflow before your next filing deadline arrives.
This article is general information, not a substitute for advice from a qualified financial advisor. Consult a qualified financial professional about your own circumstances before acting on anything here.
Sources
- 2026 FIG (Filing Instructions Guide) | HMDA Documentation
- A Guide to HMDA Reporting: Getting It Right! | FFIEC
- Home mortgage disclosure reporting requirements (HMDA) | CFPB
- Revised “A Guide to HMDA Reporting: Getting It Right!” | Federal Reserve