If you originate or evaluate covered mortgage applications as a financial institution, Regulation C requires you to collect specified HMDA fields, record them quarterly, and submit an electronically certified loan/application register by March 1. The single most important operational control is continuous data integrity between your point-of-sale system and your loan origination system. Assign an authorized representative now and confirm your submission pipeline before the fourth quarter closes.
TL;DR:
- Loan volume thresholds are calculated based on the two previous calendar years, meaning institutions exceeding these in any of those years must report even if they are below thresholds currently.
- Reporting deadlines require recording data within 30 days after quarter-end and submitting the complete, certified report by March 1, with non-compliance risking penalties.
- The most error-prone HMDA fields include census tract, applicant demographics, action-taken codes, and pricing data, all of which need extra QA attention.
- A strong compliance management system involves clear roles, quarterly audits, validated data feeds, and reliable source mapping to ensure data accuracy and readiness.
- Examiners assess overall CMS strength more than individual errors, favoring documented processes, regular staff training, and automated reconciliation to demonstrate ongoing compliance.
Table of Contents
- What HMDA Compliance Reporting Actually Covers
- Who Must File: A Checklist to Decide If a Loan Is Reportable
- The LAR Fields and Deadlines That Actually Matter
- Where Brokerages Go Wrong: Common HMDA Data Errors
- How to Operationalize Your Compliance Reporting Program
- What Examiners Expect From Your Compliance Management System
- Where to Verify the Rules Yourself
- A Founder's Take on Continuous Compliance
- Get Audit-Ready Without the Manual Grind
- Sources
- FAQ
What HMDA Compliance Reporting Actually Covers
Mortgage compliance reporting under the Home Mortgage Disclosure Act exists to answer one question regulators have asked since 1975: is credit flowing fairly across neighborhoods and applicant groups? Regulation C turns that question into a data mandate. It requires covered institutions to collect, record, and submit detailed information on nearly every mortgage application and origination they touch during the year.
The statute serves three overlapping purposes. It gives regulators and the public visibility into whether lenders are meeting the credit needs of the communities they serve. It supports the Community Reinvestment Act evaluation process for banks and thrifts. And it feeds the fair lending detection models that examiners at the CFPB and the Federal Reserve run against your loan data every year, looking for pricing or denial patterns that correlate with race, ethnicity, or geography.
Whether you're covered comes down to two separate tests, and both have to be true.
- Institutional coverage: you meet the definition of a "financial institution" under Regulation C, which turns on asset size for depository institutions and loan-volume thresholds for non-depository lenders and mortgage brokers.
- Transactional coverage: the loan or application in question is a covered loan, meaning a closed-end mortgage, open-end line of credit, or home improvement loan secured by a dwelling, and it isn't on the regulation's short exclusion list (temporary financing, certain agricultural-purpose loans, and a handful of other categories).
Loan volume drives most of the confusion. An institution that originated fewer than a specified threshold of closed-end mortgage loans or open-end lines of credit in each of the two preceding calendar years generally falls below the reporting threshold for that product type. Cross the threshold in either category and you're pulled into reporting for that loan type, even if you stay below it for the other.
Partial exemptions complicate this further. Certain insured depository institutions and credit unions that meet CRA rating and asset-size conditions can skip a subset of the data fields, roughly the demographic pricing details added in the 2015 rule update, while still filing the core LAR. Brokers and independent non-depository lenders almost never qualify for these partial exemptions; they apply mainly to small, well-rated banks and credit unions. If you're a broker assuming an exemption applies to you because a bank down the street mentioned one, verify it against your own institution type before you build a reporting plan around it.
Who Must File: A Checklist to Decide If a Loan Is Reportable
Every loan compliance tracking decision boils down to running two tests in sequence, and skipping the order is where teams get into trouble.
- Confirm entity-level coverage. Determine whether your organization meets the Regulation C definition of a financial institution for the calendar year in question. Depository institutions look at asset size as of the prior December 31. Non-depository institutions, including most mortgage brokers, look at loan-volume thresholds and whether they have a physical office in a metropolitan statistical area or made a minimum number of covered loans there.
- Confirm transaction-level coverage. For each application in your pipeline, ask whether it's a closed-end mortgage or open-end line of credit secured by a dwelling, and whether it falls on the exclusion list. Business-purpose loans, construction-only loans, and certain temporary bridge financing typically fall outside scope.
- Confirm action taken. HMDA doesn't just capture funded loans. Originations, purchases of loans from another institution, application denials, approvals not accepted by the applicant, withdrawals, and files closed for incompleteness all generate a reportable record with its own action-taken code.
- Apply partial exemption tests, if relevant. If your institution is a bank or credit union that might qualify for a partial exemption, check both the CRA rating condition and the loan-volume condition for the two preceding calendar years before assuming any fields can be dropped.
- Document the multi-entity decision rule. When more than one institution touches a transaction (a broker takes the application, a wholesale lender underwrites and funds), decide and document which one reports the origination. The rule generally turns on which entity made the credit decision before closing versus which one purchased the loan afterward, and examiners expect to see that logic preserved in the loan file, according to Federal Reserve guidance on HMDA reporting.pdf).
Loan-volume counting trips up more brokerages than any other part of this checklist. The thresholds look at the two preceding calendar years, not the current one, which means a slow year doesn't retroactively excuse you from reporting on a strong year that already crossed the line. A shop that closed 30 closed-end loans in 2024 and 22 in 2025 is still covered for 2026 reporting, because it exceeded the 25-loan threshold in at least one of the two preceding years. Build your threshold check into your annual compliance calendar rather than reassessing it only when someone asks.
For brokers working with multiple wholesale lenders, the multi-entity question deserves its own line item in your file review. If your agreements with different lenders assign reporting responsibility inconsistently, an examiner sampling files across lenders will notice the pattern before you do.

The LAR Fields and Deadlines That Actually Matter
Regulation C specifies dozens of data points for the loan/application register, but a handful of fields generate most of the errors examiners flag. Knowing which ones are genuinely tricky, versus which ones are simple lookups, is what separates a clean LAR from a remediation project.
Fields that deserve extra QA attention:
- Universal Loan Identifier (ULI): a unique, algorithmically checkable identifier tied to your institution's legal entity identifier. Get the check-digit calculation wrong and every downstream system that keys off the ULI, including your own reconciliation workbook, breaks quietly.
- NULI (non-universal loan identifier): used only in narrow circumstances; confusing it with the standard ULI format is a common vendor-mapping mistake.
- Census tract: must reflect the property location as of the date the application was received, not the date of closing, which matters when a deal drags on across a tract boundary reassignment.
- Action taken and action-taken date: six possible codes, and the difference between "application withdrawn" and "file closed for incompleteness" changes which fields are even required.
- Applicant demographic information: race, ethnicity, and sex, collected via visual observation, surname, or self-report depending on channel, with strict rules on when collection is voluntary versus mandatory.
- Pricing fields: rate spread, APR, total loan costs, and discount points, most of which are pulled automatically from closing disclosure data if your systems are properly integrated, and manually reconstructed at high error risk if they aren't.
- Automated underwriting system (AUS) result and identifier: frequently mismapped when a lender's LOS logs a different AUS name than what appears on the model's approved list.
Fast fact: Regulation C requires institutions to record LAR data within 30 calendar days after the end of the calendar quarter in which final action was taken, according to 12 CFR Part 1003. That quarterly cadence is what turns HMDA compliance reporting requirements from a once-a-year scramble into a manageable, ongoing task.
The quarterly recording rule is the part of Regulation C that most brokerages underuse. Instead of treating HMDA as a January project, the regulation expects you to update your register within 30 days of each quarter's close throughout the year. Institutions that originated at least 60,000 covered loans and lines of credit combined in the preceding calendar year face a shorter quarterly recording window and additional expectations, since their volume makes stale data a bigger systemic risk.
The annual submission deadline is fixed and unforgiving: your complete, certified LAR is due electronically by March 1 following the calendar year being reported, filed through the FFIEC HMDA Platform. An authorized representative of your institution, someone with the authority to bind the organization, must certify that the data is accurate to the best of their knowledge before submission. The CFPB's HMDA reporting resources require you to retain a copy of the submitted LAR for at least three years, and retain the underlying loan-level data supporting each entry for longer under your institution's general recordkeeping obligations.
A few operational edge cases catch teams off guard every cycle. If March 1 lands on a weekend, the platform's submission window doesn't extend automatically. Confirm the actual filing calendar each year rather than assuming a grace period. Purchased loans get reported by the purchasing institution using its own action-taken code, separate from how the originating institution reported the same loan. And when a loan closes through table funding or a similar arrangement, the multi-entity documentation described earlier is what will save you when an examiner asks why two institutions' LARs don't obviously match up on the same transaction.
Where Brokerages Go Wrong: Common HMDA Data Errors
Mortgage compliance audits rarely uncover one catastrophic failure. They uncover the same small handful of recurring field errors, magnified across hundreds of loan files, that together look like a pattern to an examiner even when each individual mistake looks minor to the loan officer who made it.
The most frequent field-level problems cluster around a short list:
- Census tract mismatches, usually from geocoding tools that use the closing address instead of the property address captured at application.
- Race and ethnicity miscoding, particularly around the disaggregated subcategories added in recent rule updates, which loan officers frequently skip or mis-map from legacy POS dropdown fields.
- Action-taken code errors, especially the line between "denied" and "withdrawn" when a borrower stops responding mid-underwriting.
- APR and rate-spread calculation errors, which surface when pricing data is manually re-entered instead of pulled directly from the closing disclosure.
- Duplicate or malformed ULIs, typically a symptom of a POS-to-LOS handoff that doesn't validate the check digit before the loan moves downstream.
Underneath those field errors sit process causes that show up in loan compliance tracking reviews far more than any single data-entry mistake. Manual rekeying between systems that don't talk to each other is the biggest one. Every time a human retypes a value from your POS into your LOS, you've created a new opportunity for a transposed digit or a dropped field. POS-to-LOS mapping gaps, where a field exists in one system but has no corresponding field, or the wrong corresponding field, in the other, are the second biggest. Weak vendor management is the third: if a third-party origination platform changes its export format and nobody on your compliance team notices until the annual LAR build, you've inherited a data quality problem you didn't create and won't catch in time.
CFPB examiners don't review every loan file with equal weight. Supervision priorities lean toward the strength of your overall Compliance Management System, consumer complaint trends tied to your institution, and systemic patterns in your HMDA data that suggest a control failure rather than an isolated typo. A single miscoded census tract in an otherwise clean file rarely triggers a finding. The same error repeated across dozens of files from one branch or one loan officer usually does.
Pro Tip: Run a monthly matched-sample review pulling 10 to 15 files at random and tracing every reportable field back to its source document. Catching a systemic mapping error in March costs you an afternoon. Catching the same error in the following January's LAR build costs you a full data remediation project.
Regulation C's bona fide error provision offers some protection, but it's narrower than most brokers assume. An error resulting from a good faith clerical mistake, despite maintained procedures reasonably designed to avoid errors, generally won't itself trigger enforcement. It does not excuse a pattern of errors traceable to a missing or broken control, and it never substitutes for having a functioning compliance program in the first place.
How to Operationalize Your Compliance Reporting Program
Turning HMDA reporting standards into a system your team can run without heroics every February takes six concrete moves.
- Map POS to LOS to LAR and name a single source of truth. Every reportable field should have one authoritative origin system. When two systems disagree, the mapping document should say, without ambiguity, which one wins.
- Define roles with a simple RACI. Assign a data steward who owns field-level accuracy, an authorized representative who holds certification authority, an IT owner responsible for system integrations, and a QA reviewer independent of loan production.
- Set a quarterly internal audit cadence tied to the 30-day recording rule. Sample a defined percentage of files each quarter, trace every field to its source document, and log corrections before they compound into the annual build.
- Automate validation rules at the field and cross-field level. A field-level rule catches an impossible value, like a census tract that doesn't exist. A cross-field rule catches a logical inconsistency, like an action-taken code of "originated" paired with a missing rate spread.
- Build a vendor oversight checklist for every third-party data feed. Require change notifications before a vendor updates an export format, and contractually obligate data accuracy warranties from any platform feeding your LAR.
- Run the March 1 submission as a rehearsed event, not a fire drill. Dry-run the FFIEC upload at least once in January using the prior year's format, confirm your authorized representative's certification credentials are active, and have a documented backup plan if your primary submitter is unavailable that week.
A workable RACI for a mid-size brokerage looks something like this in practice:
- Data steward: owns field accuracy and monthly sample reviews.
- Authorized representative: certifies the annual submission and signs off on quarterly reconciliation summaries.
- IT/systems owner: maintains the POS to LOS integration and flags vendor format changes.
- QA reviewer: independently audits a sample of files each quarter, separate from the team that originated them.
One technique worth adopting directly: keep a continuously updated reconciliation workbook keyed by ULI, where every LAR row links to a verifiable entry in your loan file index. Reconcile the totals at each quarter's close, and during heavy origination months, run a matched-sample loan file review at least monthly rather than waiting for the quarterly cycle to surface a growing gap. Centralizing that data collection across your LOS, POS, and CRM shortens the audit trail considerably and cuts the manual reconciliation burden that otherwise piles up right before the year-end LAR build.
Pro Tip: Treat your quarterly reconciliation like a mini version of the annual submission, complete with a written sign-off from your data steward. Teams that only reconcile once a year are, in effect, running one high-stakes audit instead of four low-stakes ones.
For a fuller walkthrough of mapping FFIEC field requirements to your LAR, our detailed HMDA reporting guide breaks down the mapping exercise step by step. If your internal audit process needs a starting framework, our compliance audit checklist covers file-sampling methodology in more depth than fits here.
What Examiners Expect From Your Compliance Management System
HMDA data quality doesn't exist in isolation from the rest of your regulatory obligations. Examiners read your LAR as one data point inside a broader Compliance Management System review that also touches RESPA disclosure timing, TILA pricing disclosures, and how your institution handles consumer complaints. A CMS with strong board oversight, documented policies, regular staff training, active monitoring, and a real corrective-action process tends to earn more benefit of the doubt on isolated data errors than a CMS that exists mainly on paper.
Examiners weigh the strength of a firm's overall compliance management system heavily. A well-documented CMS with automated reconciliations can produce a more favorable supervisory outcome even when isolated data errors surface during the review, according to the CFPB's supervision and examination manual.
That single insight should reshape how you think about mortgage regulation reporting. It's not just about getting every field right. It's about being able to show, with evidence, that your process is designed to catch and correct errors when they happen.
A functioning CMS built around HMDA readiness includes a few concrete artifacts examiners will ask for by name:
- A roles matrix documenting who owns each stage of data collection, review, and certification.
- An evidence index linking each quarter's reconciliation summary to the underlying loan files it covered.
- A training log showing when loan officers and processors last received HMDA field-coding training, and what changed since the last session.
Building that evidence trail from scratch under deadline pressure is exactly the problem that pushed Omar Khamisa, who spent more than two decades working as a processor, underwriter, and loan originator before founding 1 Solution Mortgage Software, to design compliance tracking directly into the platform rather than bolting it on afterward. A platform that logs field-level changes and role activity automatically as loans move through the pipeline builds most of that evidence index for you, without a separate manual tracking project. For more on what examiners look for in broker-specific CMS design, see our guide to mortgage regulatory compliance for brokers.
Where to Verify the Rules Yourself
Everything in this article traces back to a small set of primary sources, and you should bookmark them rather than relying on secondhand summaries when a specific filing question comes up.
- CFPB HMDA reporting requirements: the clearest starting point for submission deadlines, certification rules, and general reporting obligations.
- 12 CFR Part 1003 (Regulation C): the actual regulatory text governing every field definition, threshold, and exemption discussed here.
- FFIEC HMDA filing platform and technical specifications: where you'll actually submit your LAR and validate file formatting before March 1.
- CFPB supervision and examination manual: the source for understanding how examiners structure a review and what they weigh most heavily.
If you're preparing for a filing deadline, start with the FFIEC platform's specifications. If you're preparing for an exam, start with the supervision manual. For a broader compliance program structure beyond HMDA specifically, our compliance management guide walks through how these pieces fit together across your full regulatory footprint.
A Founder's Take on Continuous Compliance
Most brokerages treat HMDA as a February fire drill because that's how their systems are built, not because the regulation demands it. Regulation C's quarterly recording rule is a gift most firms never unwrap. It's practically begging you to spread the work across the year instead of compressing it into six weeks of dread.
The firms that handle this well don't have better compliance officers. They have better plumbing. When your POS, LOS, and CRM all feed the same reconciliation record instead of three disconnected spreadsheets, the annual LAR build stops being a project and becomes a formality. That shift matters more than any individual field-coding rule, because it changes what an examiner sees when they walk in the door: a firm with a system, not a firm improvising under pressure.
I built 1 Solution Mortgage Software around that belief, because I watched too many good brokerages get dinged not for bad intentions but for bad infrastructure. Fair lending analysis depends on clean data. Clean data depends on systems that don't make your team choose between speed and accuracy. Fix the plumbing, and the compliance follows.
— Omar Khamisa
Get Audit-Ready Without the Manual Grind
This platform is built to close the exact gap that causes most HMDA findings: the disconnect between your point-of-sale intake and your loan origination system. Because the platform runs POS, LOS, CRM, and compliance tracking on one connected system rather than stitching together separate tools, every reportable field gets captured once, at the source, instead of rekeyed multiple times before it reaches your LAR.
That single-system design is what makes quarterly audits and the March 1 certification manageable instead of stressful, highlighting clearly who manages your loan. Role-based workflows let your data steward, your authorized representative, and your QA reviewer each see exactly what they're responsible for, with an evidence trail that builds itself as loans move through the pipeline rather than getting reconstructed after the fact. Reporting exports are built to align with the LAR fields Regulation C requires, so your quarterly reconciliation pulls from consistent source data used for annual submission.
If you're tired of rebuilding your compliance evidence from scratch every filing season, see how the platform handles it firsthand. Explore 1 Solution Mortgage Software and book a demo to walk through your own POS-to-LAR mapping before your next reporting deadline.
Sources
- Home mortgage disclosure reporting requirements (HMDA)
- 12 CFR Part 1003 — Home Mortgage Disclosure (Regulation C)
- CFPB supervision and examination full manual
FAQ
What does mortgage compliance mean?
Mortgage compliance means operating within the federal and state laws governing mortgage lending, including HMDA data collection under Regulation C, TILA pricing disclosures, and RESPA settlement rules, and being able to document that adherence during an examination.
What triggers HMDA reporting?
HMDA reporting is triggered when your institution meets the Regulation C definition of a financial institution, based on asset size or loan-volume thresholds, and you originate, purchase, or take action on a covered loan secured by a dwelling.
What is the 3-7-3 rule for a mortgage?
The "3-7-3 rule" refers to a Truth in Lending Act disclosure timing sequence rather than an HMDA requirement: lenders must provide the Loan Estimate within 3 business days of application, wait several business days before closing on first disclosures, and provide a revised disclosure at least 3 business days before closing if terms change.
Who is exempt from HMDA reporting?
Institutions that fall below the applicable asset-size or loan-volume thresholds in the two preceding calendar years aren't covered at all, and certain small, highly rated insured depositories and credit unions may qualify for a partial exemption from a subset of data fields, though most independent mortgage brokers don't meet that partial-exemption criteria.

