HMDA Plus: What It Actually Changed in the LAR Workflow

The short version. If you have been told HMDA Plus is coming, the date is wrong by about a decade. It is the industry nickname for the expansion the CFPB proposed in 2014 and finalised on 15 October 2015, and most of it took effect on 1 January 2018. It is not a proposal you need to prepare for. It is the reason your LAR looks the way it does now.

That matters more than a correction, because a good deal of the material still circulating about it is written in the future tense. If your process was built after 2018 you inherited the outcome without seeing the transition; if it was built before, some of the workarounds from that first filing season are probably still in it. Either way the useful question is not what HMDA Plus proposed. It is what it did to the workflow, and which of those effects are still costing you a resubmission.

What “HMDA Plus” actually refers to

The Dodd-Frank Act moved rulemaking authority for HMDA to the CFPB and directed it to expand the data collected. The Bureau published its proposal in 2014 and issued the final rule on 15 October 2015, published in the Federal Register on 28 October 2015, with most provisions effective 1 January 2018. The rule and its amendment history are on the CFPB's own page for Regulation C, the Home Mortgage Disclosure Act.

“HMDA Plus” was never the rule's name. It was shorthand used while the expansion was pending, which is exactly why articles using it tend to date from that period and to describe the changes as forthcoming. Read anything on the subject with its publication date visible.

Three structural things came out of it, and all three are live today: the data set got substantially larger; coverage changed, bringing dwelling-secured open-end lines of credit into scope on the same footing as closed-end loans; and the institutional coverage tests were reworked so that whether you file at all is a threshold question you re-answer, not a permanent status.

What your register actually holds now

The authoritative field list is not a vendor's summary; it is the FFIEC Filing Instructions Guide, published annually. The 2026 Filing Instructions Guide, released October 2025 for data collected in 2026, defines a Loan/Application Register of 110 data fields, plus the transmittal sheet.

The number is worth sitting with, because the workflow consequence of the expansion was never the count on its own. It was where in the business the new fields live. A pre-2018 register was largely assembled from things the filing system already knew. A modern one is not.

The consequence nobody warns you about: the data moved upstream

This is the first of the effects that outlasted the transition, and it is the one that quietly decides how painful your filing season is.

Fields such as the applicant's credit score and the model that produced it, debt-to-income ratio, combined loan-to-value, property value, the automated underwriting system used and the result it returned, and the reasons for denial are not derivable at the filing step. They are facts about a decision, captured at the moment the decision was made, or not captured at all. No amount of care in the submission software reconstructs a credit score that nobody wrote down in March.

The practical effect is that HMDA stopped being a year-end reporting exercise and became a data-capture requirement sitting inside origination. Filing became the step where you find out whether origination did its job. Teams that still treat the LAR as something assembled in the first quarter are the ones who spend that quarter chasing files rather than checking them.

If you want a single diagnostic: ask how many of your current edit failures can be resolved by someone looking at a spreadsheet, versus how many require someone to open the loan file. A high proportion of the second kind means the capture problem is upstream of you.

What changed in the edit-check pass, and why a valid record can still fail

The second lasting effect is the shape of the edits themselves. A larger field set does not simply mean more field-level checks. It means far more relational ones — edits that compare fields to each other rather than testing a value in isolation.

A record can be individually correct in all 110 positions and still fail, because the failure is in the relationship: a loan amount against a property value, an action-taken code against the dates around it, a lien status against a loan type, an exemption claimed in one field that the rest of the record contradicts. The Filing Instructions Guide sets these out in its edit specifications, and the FFIEC organises them by severity so a filer can tell what blocks a submission from what merely invites a question.

Two things follow, and neither is obvious from a field list:

• Ownership of a failure changed. A syntactical or validity failure is usually a data problem and a data person can clear it. A relational failure is frequently a business-facts problem, and clearing it means someone who can read the file deciding what actually happened. Routing every edit failure to the same queue is why some of them sit there.
• “Not applicable”, blank and exempt are three different answers. The expansion introduced a great many conditional fields, and the conditions are where resubmissions come from. A field that is legitimately NA on one record is a hard failure on the next, depending on values elsewhere in the same row.

We have written up the failures that recur most often, with the fix for each, in how to fix the ten most common HMDA edit check errors.

Geocoding did not get easier because the rest got bigger

The third effect is one that surprises people who think of geocoding as a solved sub-task. Every reportable record still needs its census tract, county, state and MSA/MD, and those four fields are judged for correctness the same as any other. Expanding coverage to open-end lines of credit did not relax that; it added records to the population that needs it.

It also added records whose address data is often weaker. An address that resolves only to a ZIP centroid is not merely less precise — at tract level it is frequently the wrong answer, and a tract-level error is a different filing. This is the same precision hierarchy that governs proxy work, which we set out in how BISG proxy works and where it fails, and it is why we publish how we measure geocoding accuracy rather than quoting a match rate. A match rate counts how many addresses got an answer. It says nothing about how many got the right one.

What to ask your core provider, in the order that gets useful answers

Most of the questions worth asking are about capture and lineage rather than about reporting, because reporting is the easy half.

1. Which of the 110 fields does the origination system capture natively, and which are entered by hand later? The hand-entered set is your risk register.
2. When a value is corrected after the fact, what happens to the original? If the system overwrites rather than versions, you cannot show an examiner what you knew and when.
3. Can you re-run the edit pass against partial-year data before the filing window? A quarterly dry run finds capture gaps while the files are still fresh enough to fix.
4. Where does the geocode come from, at what precision, and is it stored with the record? A geocode obtained at filing time and not retained cannot be reproduced.
5. What is the path for a record the system will not let you correct? Every filer eventually meets one.

Where this stands today

The 2015 rule has been in force since 2018 and has been amended since, principally around reporting thresholds. As of August 2026 the CFPB's Regulation C page lists no further pending expansion of the data set; the current year's HMDA rulemaking activity is the routine annual adjustment to the asset-size exemption threshold, effective January 2026.

So the honest answer to “what would HMDA Plus change in our workflow” is that it already changed it, and the question worth asking instead is whether your process was rebuilt around the change or patched to survive it. The tell is where your effort goes during filing season. If it goes on assembling data, the workflow is still pre-2018.

RATA has run HMDA and CRA submissions for banks and credit unions continuously since 1987, through that transition and every amendment since. Comply HMDA/CRA/SBL runs the FFIEC edit checks against your data before the filing window rather than during it, and compliance-grade geocoding handles the four geography fields at the precision the tract-level answer requires.