HMDA data validation software: scrub, rules engine or file match?

HMDA data validation software does one of two very different jobs, and a buyer should know which before comparing prices. Most of it is a rules engine: the FFIEC filing edits, logic checks and reconciliation with the loan origination system, which cover every record but only ask whether the register agrees with itself. Asample scrub, done in-house or bought from a consultant, compares register fields with the loan file, which is the right test, but on a fraction of the records. Matching every field against the filecovers every record with the examiner's own test. Botminds' HMDA and 1071 Data Validation uses agents to do the third: each field drawn to its page in the loan file, with people deciding every correction.

The choice matters because the loan/application register is large and the examiner reads it a different way. For 2025, 4,782 institutions reported HMDA data (FFIEC, June 2026), some 13.5 million records in all (FFIEC HMDA data browser). Examiners pull a random sample, open the loan files and count disagreements. On a register of 501 to 100,000 entries they start with 35 files and go to 79 if a field shows two errors; four errors in one field among the 79, and that field is corrected across the whole register and resubmitted. The figure below sorts errors the way an examiner does: by whether they pass the edits and whether they match the file.

How do you validate HMDA data? Valid and accurate are two different tests

HMDA data can be valid without being accurate. Valid means the register passes the FFIEC filing edits; accurate means each value matches the loan file. The edits are built into the HMDA Platform and come in four kinds (FFIEC Filing Instructions Guide, 2026). Syntactical edits check the file's format and filing year. Validity edits check "whether there are valid values in each data field". Quality edits check whether fields, alone or in combination, "conform to expected values", and macro-quality edits check the register as a whole: no more than 30% of entries withdrawn, for example. The 2026 guide lists more than 180 of them. A register cannot be submitted until every syntactical and validity edit is fixed and every quality flag is fixed or confirmed.

None of those edits opens a loan file, and opening the file is the whole of the examiner's test. The FFIEC's transaction testing guidelines tell examiners to "verify the accuracy of the data in the entries in the HMDA LAR sample(s) against the corresponding loan files", and to record as errors the differences the institution cannot explain (FFIEC Examiner Transaction Testing Guidelines). The person who certifies the filing certifies "the accuracy and completeness of data submitted" (12 CFR 1003.5(a)(1)(i)), and a clean edit report does not show that.

The gap shows up in exam results. HMDA data collection has been the violation Federal Reserve examiners cite most often in each of the last three years they have published, and the FDIC's most common HMDA finding is the same: required data fields reported wrongly.

What is sold as HMDA data validation software? Four kinds of product

Four kinds of product are sold under the label, and each one is one of the three methods underneath. Knowing which one you are looking at tells you, before any demonstration, which errors it can find: a product that never opens a loan document cannot find a wrong value that is consistent with the origination system, however many rules it runs.

HMDA management software compiles the register from the origination system, geocodes addresses, formats the pipe-delimited file and runs the FFIEC edits before the HMDA Platform does. The Federal Reserve's examiners note that "some financial institutions use their loan origination software to determine geocodes, while others use data collection software to compile the entire Loan Application Register" (Consumer Compliance Outlook, 2023). This is method 2, and part of it is free: the HMDA Platform runs every edit at submission, and Regulation C's commentary names the Bureau's own geocoding tool as an example of a procedure "reasonably adapted to avoid errors" in census tract (12 CFR 1003.6(b), comment 6(b)-2). What a buyer pays for is running those checks earlier, every day, with a workflow around them.

Document-capture tools with comparison rules classify loan documents, extract values by optical character recognition and compare them with the register through a fixed rule per field. They do open the file, which puts them closer to the examiner's test. The questions are which document each rule treats as the source and what happens when two documents disagree. Income is the usual trap: Fed examiners report lenders entering the gross income the borrower stated rather than the income the lender relied on, so a rule that reads the application instead of the underwriter's worksheet will confirm the error it should catch.

Scrub services are people, in-house or from an audit or advisory firm, comparing a sample of files with the register: method 1, with an independent eye. Agents that trace each field to its page are method 3: they find the source document the procedure names, recompute rate spread and census tract, apply the tolerances and hand a person only the disagreements to decide. That last category is where Botminds' HMDA and 1071 Data Validation sits.

Method 1: the sample scrub checks the right thing on too few records

A hand scrub is the only traditional method that uses the examiner's source of truth. A reviewer pulls a set of files, opens the application, the credit decision, the Closing Disclosure and the rest, and compares them with the register one field at a time. Done well, it finds exactly the errors an examiner would. Its limit is arithmetic: finding the right page for each of dozens of fields is slow, so the scrub covers a sample, and most of the work lands in the weeks before the 1 March deadline. Inside HMDA scrub season follows those weeks desk by desk.

A sample estimates an error rate; it does not correct a register. Washington Federal's internal audit of its 2016 register found errors in 40 of 100 files. The CFPB's own review of the next year's register found 58 errors in 27 of 84 files, and after the bank corrected and resubmitted it, 21 errors in 13 of 81 files were still there (CFPB consent order, 2020). Each review measured the problem accurately. No review found an error in a file it did not open, and on a register of more than 7,000 loans a year, that is where most of the errors were.

Put numbers on it with a sample bank's third quarter. Take Kestrel Valley Bank, a fictional lender, as its register runs through Botminds' HMDA and 1071 Data Validation: 1,846 records in the quarter, and 177 field breaks that needed a person. A data manager who can check 300 files a quarter, as the bank's does, sees about one record in six. If she picks at random, she can expect to meet about 29 of the 177 breaks and to leave the other 148 in the register.

Method 2: edits, logic rules and LOS reconciliation check every record against itself

A rules engine sees every record but never sees the file. It runs the FFIEC edits early and often, adds the institution's own logic rules (a co-applicant's ethnicity reported where there is no co-applicant, a rate spread reported on a denial) and reconciles the register with the loan origination system so that nothing is lost between the two. That is valuable work. It catches keying errors, broken extracts, impossible combinations and the share of a code drifting out of range, and it does so continuously.

What it cannot catch is a value that is wrong but well formed and consistent with its neighbours, because the register and the origination system are usually the same data twice. If the system holds the wrong date, the reconciliation agrees with it. The Federal Reserve's examiners make the point directly in their list of sound practices: "Develop an autonomous verification process to review source documents; do not rely on information on HMDA worksheets" (Consumer Compliance Outlook, 2023).

Rules do find patterns, as long as someone keeps running them. Bank of America monitored, month by month, how often each loan officer recorded that an applicant chose not to give race or ethnicity, and its "information not provided" rate fell from 13% to 6%. It stopped the report in 2016, and the rate climbed to 17% by early 2020. A review then found 113 loan officers who had recorded "not provided" on every application they took over three months. The CFPB fined the bank $12 million (CFPB consent order, 2023). Every one of those records passed the edits: "not provided" is a valid code. Some could not have been caught from the file either: the question was never asked, on phone calls the bank did not record until 2021.

Method 3: every field against its page in the loan file

The third method runs the examiner's test on every record. For each reportable field it finds the document and page that is the source of truth: the adverse action notice for a denial date, the underwriter's income worksheet for income relied on, the Closing Disclosure for loan costs, the rate lock and the APOR table for rate spread, the demographic addendum for ethnicity, race and sex. It compares the register value with that page and applies the FFIEC tolerances: three calendar days on the application and action taken dates (not across a year end), $1,000 on loan amount, rounding on income, and none on rate spread, demographics or denial reasons. Differences inside tolerance are closed, not counted. The field-to-page map sets out where each key field comes from and how it usually goes wrong.

By hand this is the scrub again, and the reason the scrub samples. A single denied purchase in the sample register carries 86 applicable fields spread across 31 documents and 212 pages. In Botminds' HMDA and 1071 Data Validation, agents do the finding and comparing: in the sample quarter they found a source page for all 86 of the Ellery record's fields and drew each to it, about 86 checks a record across 1,846 records. A person sees only the fields that break, each beside the page that disagrees, and decides what happens to it.

Every field drawn to the page it came from

The strip above the record counts the quarter: 1,846 records and 158,756 field checks. The panel on the right shows both values, the procedure rule and the page, and leaves the choice to correct or keep the value to the data manager.

Matching against the file has limits of its own. It checks the records it is given, so applications that never reached the register still need a reconciliation against the pipeline: examiners can order a resubmission for omitted applications alone. And where the truth was never written down, as in the Bank of America phone calls, no page can settle it. That is why the third method sits on top of the other two rather than replacing them.

One record, three methods: the Ellery application

The Ellery application shows the difference on a single record. Marcus and Dana Ellery applied on 24 February 2026 for a $412,000 home purchase at the bank's Eastgate branch and were denied for debt-to-income. The register as first entered holds two values that are wrong and look right.

The sample scrub finds both breaks, if it pulls this file. With 300 of 1,846 files reviewed, the chance is about one in six. The rules engine passes both. 03/14/2026 is a well-formed date after the application date, in the right year, and it is exactly what the origination system holds, so reconciliation agrees. $148,000 is a plausible income for a $412,000 purchase. The contradiction is in the register (its own debt-to-income ratio of 47% was computed on $135,000), but the register does not carry monthly debts, so no edit can see it. A custom rule could catch the date only if the system held the notice date in a field the rule could read.

The field match finds both, with their pages. The data manager corrects each one and signs it with a reason, and the record rejoins the register clean.

The edits ask whether a value is possible. The examiner asks whether it is true. A register can pass the first test on every record and fail the second four times in one field.

What each method costs, and what each leaves to the examiner

The methods differ most in what they leave for the examiner to find. Coverage is the plainest way to see it: of the records on the register, how many had their fields compared with the loan file before the examiner arrived?

The examiner's sample is small, but it is enough to order a resubmission when errors are common. On the sample register as first entered, our model of the FFIEC procedure gives about a 37 in 100 chance that one 79-record sample finds four errors in at least one field. With every record checked and only the still-open breaks left, the same model gives under 1 in 100. Both figures are estimates on fictional data, and the second assumes the check finds every error; how examiners test HMDA data works through the model field by field.

The cost of a miss is public. After the CFPB found 51 errors in an initial review of 159 files from Freedom Mortgage's 2020 register, the company resubmitted and corrected errors in 35 fields, more than 174,000 data entries affecting nearly 20% of its applications (CFPB, October 2023). The proposed order that followed carried a $3.95 million penalty and required the company to audit, test and correct its HMDA data regularly (CFPB, June 2024).

Hours follow the same split. Most of a hand review's time goes on finding the page, not on judging what is on it. The estimate below, for one quarter's review at a mid-size lender, shows where the days go when a person does the finding and when agents do.

What each method leaves behind matters as much as what it finds. Regulation C treats an unintentional error as a bona fide error, not a violation, only if it "occurred despite the maintenance of procedures reasonably adapted to avoid such an error" (12 CFR 1003.6(b)). A sample scrub leaves work papers on the files it reviewed. A rules engine leaves edit reports. A field match leaves a correction for every error it found, with the value before and after, the page, the reason and the person who signed it.

The edits still run, after the file has been checked

HMDA scrub service or HMDA software: which is better?

Neither, on its own: the three work best as layers, each with its own job. The edits are mandatory, and running them early saves a February scramble. Pattern rules on code rates belong in monthly monitoring, as the Bank of America case shows. Matching every field against the file is what keeps the examiner's sample from finding four errors. And a small human sample still has a job: checking the checker, which is how model risk and internal audit can test an automated review before they rely on it.

The same choice is coming for small-business data. The CFPB's revised Section 1071 rule takes effect for the largest small-business lenders on 1 January 2028 (Federal Register, 1 May 2026). The lenders that build their 1071 checks against the credit file from the start will not have to replace a scrub later. Section 1071 under the 2026 rule covers who is covered and how to run a practice register first.

What should HMDA data validation software check? Eight questions for the demonstration

It should check what the examiner checks: each reportable field against the document your procedure names as its source, under the FFIEC tolerances and no looser, on every record, with a named person deciding each change. The eight questions below turn that into things a vendor can show on screen. Ask to see each one on a record of yours, not on the vendor's sample.

The strongest test is a back-test: give the product a quarter your team has already scrubbed, with your scrub results held back, and count what it finds that you found, what it finds that you missed, and what it misses. Our plan for choosing and implementing HMDA reporting software sets out that test and the checkpoints after it. How the agents in the third method divide the work, and what each is never allowed to do, is on the HMDA and 1071 Data Validation page.

What does HMDA data validation software cost, against the work it replaces?

List prices are rarely published, so the useful comparison is with the work the software takes over, priced in your own hours. The CFPB's model of HMDA operations breaks the job into 18 component tasks, from "transcribing data" and "resolving reportability questions" to geocoding, "standard annual edit and internal checks", internal audits and "examination preparation and examination assistance" (HMDA final rule, Federal Register, 2015). Edit software takes over the edits and the geocoding. Checking against the file takes over the most expensive part of internal checks and audit: finding the page.

Price the hours with your own wage rates. For a reference point, compliance officers in credit intermediation earned a mean of $39.57 an hour in May 2023 (Bureau of Labor Statistics). On our estimate of 22 review days a quarter by hand against 3.5 with agents finding the pages, the difference is about 148 hours a quarter, roughly $5,900 in wages before benefits at that rate. That is our arithmetic on an estimate for a mid-size lender, and it is the smaller term: one field-wide resubmission, or the penalty that can follow a repeat, outweighs years of review hours. HMDA penalties and the cost of data errors builds the full return, term by term.

Four things move the price of any product in this market: the number of records, the number of document types it must read, the work to connect it to your origination system and document store, and whether Section 1071 data is in scope. Budget for two costs that sit outside the licence: the IT work to provide a read-only extract and document access, and the time model risk or internal audit will spend validating a tool that decides what counts as an error.

Questions people ask

What is an HMDA scrub?

An HMDA scrub is a review of loan/application register entries against the loan files, usually on a sample and usually before the 1 March filing deadline. Lenders run them in-house or buy them from audit and advisory firms. Its strength is that it uses the same source of truth as the examiner; its weakness is that it reaches only the files it pulls.

If our register passes all the HMDA Platform edits, is the data accurate?

Not necessarily. The edits test format, valid values, expected combinations and register-wide shares. They cannot tell whether an action taken date matches the adverse action notice or whether income matches the income relied on, and those are the comparisons examiners make in transaction testing.

How many files should an HMDA scrub review?

Enough to estimate your error rate per field with confidence, which means at least the examiner's own sample: 79 records for a register of 501 to 100,000 entries. But a sample only tells you how many errors there are. Correcting them needs every record checked, by people or by agents.

Should we outsource the HMDA scrub?

An outside scrub brings experienced reviewers and an independent view, which is worth having once a year. Ask the same questions of it as of any method: which records it covers, which page it checks each field against, and what record of each correction it leaves for the examiner.

What is the difference between HMDA validity and quality edits?

A validity edit fails a value that cannot be right, such as a code outside the list, and the register cannot be submitted until it is fixed. A quality edit flags a value that is possible but unusual, and the filer may confirm it instead of changing it. Macro-quality edits test the whole register: the 2026 filing guide expects, for example, no more than 15% of entries to report "approved but not accepted" and no more than 20% to report income under $10,000.

Does HMDA data validation software cover Section 1071 data?

It should, if you expect to report: the revised rule's first full year of small-business data is collected in 2028 and filed by 1 June 2029. The method carries over unchanged, since each 1071 data point also has a source document, from the application to the tax return that verifies gross annual revenue. Ask any vendor to show a 1071 record checked against its file, not only a HMDA one.