HMDA reporting software: what to ask, and how to go live

HMDA reporting software compiles, checks and files the loan/application register, and the part that decides an exam is the check: proving that each field matches the loan file behind it before the register is filed. That is hard because a register carries dozens of reportable fields per application, drawn from a dozen different documents. Botminds' HMDA and 1071 Data Validation does that check on every field of every record: agents trace each register value to the page it came from, apply the examiners' tolerances and your written procedure, and show your team only the fields that break, while people decide and sign every change. Implementing it needs your HMDA procedure, your register extract and a sample of loan files. The safest way in is a back-test on a quarter your team has already scrubbed, then four checkpoints, then nightly runs. How long that takes depends mostly on how quickly your team settles the back-test differences, not on the software, so this plan is written as checkpoints rather than a promised number of weeks.

What should HMDA reporting software do? Five jobs, and the one that finds errors

It should carry the register from the origination system to a certified filing: compile it, geocode it, check it against the loan file, run the filing edits and leave a record an examiner can read. The third is the job that decides whether an examiner's sample finds four errors in one field, and it is the one to test hardest.

Where this solution fits is the third and fourth jobs and the evidence behind the fifth. It does not replace your origination system or file for you: it reads the extract and the loan file documents, checks every field, runs the edits on the corrected register, and exports the register in the FFIEC pipe-delimited format with its corrections log, for a person to file after sign-off. Applications that never reached the extract are outside what a field check can see, so the reconciliation to the pipeline stays with your HMDA management process.

What questions should you ask an HMDA software vendor?

Ask for evidence on your own records, not a description. The ten questions below separate a product that checks the register against itself from one that checks it against the file, and they surface the costs that sit outside the licence. The Federal Reserve's Vice Chair for Supervision asked the same kind of question of the industry in 2026: "How should we consider third-party risk-management expectations for vendor-provided AI tools or partnerships?" (speech, 1 May 2026). Your third-party risk team will ask it of you.

What do you need to implement HMDA data validation software?

Three inputs and the names of the people who sign. Almost all of it already exists in a lender that files a register: the procedure is the document your examiners read, the extract comes from the origination systems that already feed your filing, and the loan files sit where your reviewers open them today. The work in the first stage is choosing the right versions, not creating anything.

Pick the sample with care. A sample of clean originations proves little. The typical breaks sit elsewhere: a denial reported on a status-change date instead of the notice date, income that counts a bonus the underwriter excluded, a rate spread computed against the wrong APOR table or date, a demographic form completed online but never keyed. If your last scrub flagged a problem field, such as income relied on or the action taken date for denials, make sure the sample carries enough of those records to test it.

How do you test HMDA software before you buy it? Back-test a quarter you scrubbed

Run it on a quarter your team has already worked, because that is the only first run you can score. On a quarter your team has already worked, you know which records held errors and what the right values were, so every break the agents raise can be checked against an answer you trust, and every error your team found can be looked for in the agents' output. A first run on a live quarter gives you a list of breaks and no way to tell what it missed.

The back-test also shows your procedure's gaps before they matter. When the agents flag a value your reviewers accepted, one of three things is true: the reviewer missed an error, the procedure says something the settings do not yet carry, or the source document itself was wrong. Sorting each difference into one of those three is the substance of the second checkpoint, and it is the step that most decides how fast the rest goes.

Take a sample bank's denied home-purchase application as it runs through the solution. The register reader finds 86 applicable fields; the loan file reader opens 31 documents and 212 pages and finds a source page for all 86; the matcher closes one difference as within tolerance and breaks two. One break is the action taken date: the register holds the day the file was moved to "Suspended", seven days before the adverse action notice. If your scrub of that quarter caught it, the back-test confirms the agents see what your people see. If it did not, you have learned something about your scrub.

What a back-test shows on one record: every step, before anyone decides

The four checkpoints before HMDA validation goes live

Each checkpoint is a measurement with a pass condition and a named person who decides. None is a checkbox that passes because the step was done. The pass conditions below are a starting proposal; your compliance testing manager may set them tighter, and the evidence each one produces is the same evidence model risk and internal audit will ask for, as set out on the page on how to measure an agent's accuracy on HMDA data.

Checkpoint 2 is not a recall percentage to beat. A back-test sample is small, and a single missed error on a key field matters more than a high average. Treat any unexplained miss as a stop: find why the agents did not raise it, fix the setting or the document type, and re-run those records before moving on.

Turning your HMDA procedure into settings

Every rule in your procedure that decides a reported value becomes a setting, and the setting carries the rule's section number so that a break can quote it. Changes apply from the next run and are kept as a new rule version, which gives the compliance testing manager one place to approve how the register is checked, and gives an examiner a record of which rules were in force for which run.

The examiners' tolerances are the outer limit. Under the FFIEC transaction testing guidelines, a difference of three calendar days or less in the application date or the action taken date, $1,000 or less in the loan amount, and rounding to the nearest thousand in income relied on are not counted as errors; the action-taken-date allowance does not apply where the difference puts data in the wrong calendar year. The solution starts at those limits and lets you tighten them, never loosen them. A lender whose procedure holds the action taken date to the exact day can set that; no one can set four days.

The settings screen: tolerances that only tighten, and each field's source

The first full run: what changes for the team in the first quarter

After the checkpoints, the solution checks the open register in full, and the team's work changes shape. Reviewers stop pulling a sample and comparing one field at a time across systems; they work a queue of breaks, each showing the register value, the loan file value, the rule and the page. The data manager's job moves from finding errors to deciding them. Anyone who will act on a break should be in the room for checkpoint 4, because that is where the new habits are learned on real records.

The first full run produces a backlog, and that is expected. In the same sample bank's third-quarter run of 1,846 records, the matcher found 214 breaks: 37 closed as within tolerance with a note, and 177 that needed a person. Plan reviewer time for that first queue; it is the largest single block of human work in the rollout, and it falls in stage 4, not in the weeks before filing.

Two habits need explicit teaching. The first is the kept value: when the document is wrong, or a later document supports the register, the right decision is to keep the register value and say why, and that reason is shown to the compliance testing manager at sign-off. A team that only ever corrects is not reviewing. The second is the root-cause finding. When one branch carries a disproportionate share of one field's errors, the finding goes to the person who runs that branch's process, with the records behind it, and the fix happens upstream rather than in the register.

Checkpoint 4 ends here: filing edits run, quality edits confirmed, register sent for sign-off

Regulation C asks that an authorized representative with knowledge of the data certify its accuracy and completeness when the annual register is filed. A corrections list in which every change has its page and its signer is what lets that person sign from evidence rather than assurance. The filing edits still run before sign-off: the solution runs the FFIEC syntactical, validity, quality and macro-quality edits on the corrected register and drafts explanations, a person confirms each quality edit, and the register is filed by a person after the compliance testing manager has signed it off.

When to go live: the filing calendar sets the deadline

Go live early enough that the full run before your next deadline is the solution's, not your old scrub's. The annual register is due by 1 March for the year before. A lender that reported at least 60,000 covered loans and applications, excluding purchased loans, in the preceding year also files within 60 calendar days after the end of each of the first three quarters. For those quarterly filers, nightly runs should be in place before a quarter closes, so the quarter-end run and its breaks land inside the 60-day window rather than across it.

Starting mid-year is normal, and it changes one thing: the first full run covers the year to date, so it will raise breaks on records your team already scrubbed and some it has not. Read the first error counts with that in mind. They describe the register as it stands after your earlier scrubs, not as it was first entered, so the baseline for counting errors at source starts with records entered after go-live. In the sample bank, the year-to-date register held 5,318 records from January to September when its third-quarter run finished.

Adding the Section 1071 practice register

The same field match runs on small-business applications, and a practice register is worth starting before the rule bites. Under the CFPB's revised small-business lending rule, published on 1 May 2026, the compliance date is 1 January 2028, coverage is limited to lenders with at least 1,000 covered originations in each of two consecutive years, a small business is one with gross annual revenue of $1 million or less, and the first full year of data is submitted by 1 June 2029. Coverage is decided by origination counts, so a lender near the line is counting now.

The practice track needs the same three inputs: your 1071 procedure, the commercial origination extract and a sample of application files. It has its own sharp edge. Revenue decides whether an application belongs on the register at all, and when the verified revenue on a tax return differs from the owner's estimate, the setting decides which one counts. In the sample bank's third quarter, nine of 412 practice applications had verified revenue above $1 million and were removed from the register, each removal signed. The rule itself, and how to prepare for it, are on the page on Section 1071 under the 2026 rule.

What to measure at 30, 60 and 90 days

Measure whether the agents are reading your files, whether people are deciding well, and whether the register is getting better where errors start. The first two tell you the rollout worked; the third is the reason to have done it.

Keep "within tolerance" separate from "error" in every count you report; a register with many small date differences inside three days is not a register with many errors. Keep errors as first entered separate from errors still open; the first measures your origination process, the second measures your review. The exam odds the solution estimates are a model built on your own error counts, and are worth tracking as a trend rather than quoting as a result. Which of these to report to management, and how to put a value on them, is the subject of the page on the cost of HMDA data errors and the return on checking every record.

Questions people ask

How long does it take to implement HMDA validation software?

The plan is a sequence of checkpoints rather than a fixed number of weeks. What sets the pace is how quickly the inputs are assembled, how many back-test differences need a decision, and how much reviewer time is protected for the first full run. You can see the first stage on your own data by running HMDA and 1071 Data Validation on a sample of your register.

Do we pause our current scrub while we implement?

No. The back-test runs on a quarter you have already scrubbed, so the current process carries on until checkpoint 4 has passed. Retire the old scrub only once the first full run's breaks have been worked and signed.

Does the solution change our origination system?

No. The agents read the register extract and the loan file documents and never write to the system of record. A change to the register happens only through a signed correction with a reason, and the corrected register is exported in the FFIEC pipe-delimited format for filing.

Does HMDA reporting software connect to our loan origination system?

It should read from it, not write to it. What it needs is a register extract and access to the document store where the loan files sit, and both should be named by system before a contract is signed, because a document type the software never receives shows up as a field it cannot check.

Who certifies the register when software has checked it?

The same person as before. Regulation C requires an authorized representative with knowledge of the data to certify its accuracy and completeness, and no software changes that. What changes is the evidence: a corrections list in which every change carries its page, its reason and its signer.

Is HMDA software worth it for a small reporter?

It depends on volume. The CFPB's 2015 estimate put the annual cost of HMDA reporting at about $2,500 for a lender with 50 records, and an insured bank or credit union that originated fewer than 500 closed-end loans in each of the two preceding years is partially exempt from many fields. At that scale a hand check of every file may cost less; the case for software grows with the register.