Inside HMDA scrub season: four desks, one register, and why February hurts

An HMDA data team spends most of the year proving that a register agrees with the loan files behind it. Every mortgage application a covered lender acts on becomes a row in the loan/application register (LAR), each row carries dozens of reportable fields, and each field is owed to a page somewhere in the file: the application, the credit decision, the adverse action notice, the Closing Disclosure, the appraisal, the income worksheet. The register is due to the lender's federal regulator by 1 March, and examiners later test it by pulling files and checking fields against them. The "scrub" is the team's own version of that test, run before the examiner does.

It is hard because it does not scale. A reviewer checks one field at a time against a document found by hand, so teams check a sample each quarter and save the rest for January and February. Botminds' HMDA and 1071 Data Validation exists for that gap: agents read the register and the loan file, draw every field to its source page, apply the examiners' tolerances, and show people only the fields that disagree. This page follows the four people who own the work through a quarter, and what changes at each desk.

What is an HMDA data scrub, and who does it?

An HMDA scrub is a review of the loan/application register against the loan files, field by field, to find values that disagree with their source before the register is filed. Federal Reserve examiners describe it as sound practice: "comparing the data collected with the data in the source files", which, depending on volume, "may involve testing through sampling". In most lenders it belongs to four roles, whatever their titles: a data manager who owns the register, one or more data reviewers who compare fields with files, the loan operations people whose systems and habits create the values, and a compliance testing manager who signs off before filing. Regulation C asks for a further signature at the end: "an authorized representative of the financial institution with knowledge of the data submitted shall certify to the accuracy and completeness" of the annual register.

The scrub is not the filing edits. The FFIEC's HMDA Platform runs syntactical, validity, quality and macro-quality edits, and every edit must be addressed before a register can be submitted. Those edits test whether the register is well formed and plausible. They cannot tell that an income of 148 should have been 135, because both are valid values. Only the file can.

That is also what the examiner tests. Under the FFIEC's transaction testing guidelines, examiners verify sampled LAR entries "against the corresponding loan files", and "differences that are not adequately explained should be identified as errors". HMDA errors are routine findings. Regulation C data errors made up 59.4 percent of all consumer compliance violations the Federal Reserve cited in 2022, and 38.2 percent in 2024. In 2025 the FDIC cited 72 HMDA violations, one of its five most cited laws, and 82 percent of them concerned required data fields.

Because HMDA data serve numerous important purposes, validating the accuracy of HMDA data is a key element of the Agencies’ supervisory activities.

FFIEC HMDA Examiner Transaction Testing Guidelines

The HMDA calendar: why the work bunches in January and February

The work bunches because 1 March is the only date in the year that is final. Regulation C requires each quarter's applications to be recorded on the register within 30 calendar days of the quarter's end, and a lender that makes a good-faith effort to do so is protected for data that are still wrong, provided it corrects them before it files. The annual register is due by 1 March. Lenders with 60,000 or more applications and loans also file quarterly, within 60 days of each of the first three quarter ends.

So the year's checking tends to happen twice: a light pass on a sample after each quarter, and a heavy one in January and February, when the fourth quarter is fresh, every earlier sample's misses are still in the register, and the deadline is fixed. Year-end leaves no slack. The action-taken-date tolerance examiners allow does not stretch across a year end, so a December decision reported in January is a register-year error, not a near miss.

The sample is a product of the calendar, not a choice of method: what is not opened after a quarter waits for January. The exam math explains why that matters: an examiner does not need to find many errors in one field to order the whole field corrected and resubmitted.

How do you scrub HMDA data? Five passes, in order

A good scrub runs from the register's completeness down to the single field, so that each pass works on data the previous pass has already cleaned. Done in this order, the expensive pass, reading the loan file, is spent only on records that are on the register, well formed and correctly classified.

Which records get the fourth pass is the scrub's real decision. Sampling at random estimates an error rate; sampling by risk finds more errors per hour. The records worth over-sampling are denials and withdrawals, where dates and reasons depend on documents rather than system stamps; new branches, products and loan officers; and any field an earlier exam or scrub found wrong. Whatever the method, keep the field counts as first found, because a register corrected to zero says nothing about where next quarter's errors will come from.

The HMDA data manager: "I can check 300 files a quarter"

The data manager owns the register and decides what is wrong with it, so her real constraint is how many files the team can open. Take a sample lender as it runs through the solution: Kestrel Valley Bank, a fictional $6.8 billion bank with six mortgage branches and an online mortgage center, whose 2026 register holds 5,318 records by the end of September. Its data manager, Renata Okafor, puts the problem in one line: "I can check 300 files a quarter. The examiner only needs to find four bad ones." Her third quarter alone produced 1,846 records.

In the solution, the quarter-end run reads all 1,846 records, about 86 fields each, against their loan files. It finds 214 fields that disagree with their source. Thirty-seven of those sit inside the examiners' tolerances (an application date one day off, say), so the agents close them with a note and do not count them as errors. The other 177 go to a person.

Each one arrives as a decision, not a search. On a denied home purchase for Marcus and Dana Ellery, the register's action taken date is 03/14/2026, the day the origination system moved the file to Suspended; the adverse action notice is dated 21 March. Seven days is outside the three-day tolerance. The bank's own procedure says a denial is reported on the notice date, so Renata corrects it, gives her reason and signs. Income on the same record says 148; the underwriter's worksheet relied on 135, because a $13,000 bonus with under two years' history was excluded. She corrects that too.

HMDA and 1071 Data Validation, the data manager's view: a clean record

Each line runs from a register field to the document and page it was checked against; the amber dashed line is the one-day application date difference, inside tolerance.

What changes for the data manager is coverage, not authority. The agents never change the register or the origination system; a value changes only when she signs a correction with a reason, or stays as entered when she signs a reason for keeping it. Her quarter is spent on 177 judgments, each with both values and the page in front of her, instead of 300 searches and whatever January leaves.

The data reviewer: half the time is finding the right page

A reviewer's day is mostly navigation. To check one field, a reviewer finds the record, opens the loan file in the document system, finds the right document among dozens, finds the page, reads the value and compares it with the register, often across three systems. The sample bank's reviewer, Tomás Herrera, says half his time goes on finding the page. On the Ellery file alone, the agents opened 31 documents and 212 pages to find a source page for each of its 86 fields.

With the solution, the reviewer works a queue instead. Every open break shows the record, field, register value, loan-file value, source page, branch, loan officer and how long it has been open, ranked by exam weight: the fields closest to the resubmission threshold come first. The field-to-page map that a reviewer carries in their head becomes the solution's starting point.

The reviewer's queue: every open break with its source page

One part of the reviewer's job gets more important, not less: the second review on demographics. Ethnicity, race and sex are the fields fair lending analysis rests on, and the FFIEC counts the six ethnicity fields or eight race fields for an applicant as one data field group, with no tolerance. A common break is a form completed online but never keyed, so the register says "not provided" when the applicant answered. In the solution, no such correction stands on one signature.

Loan operations: hearing about errors months later

Loan operations creates most HMDA values, and hears about the wrong ones last. Federal Reserve examiners trace many errors to the point of entry: "manual entry can increase the risk of institutions improperly reporting data fields", along with income reported as stated rather than as relied on. A processor who closes out a status or keys an income figure in March may learn it was wrong the following February, one file at a time, when the scrub sends the record back. By then the habit has produced the same error on dozens of files. The sample bank's Eastgate operations lead, Priya Nandakumar, asks for something specific: "Tell me which step creates the error and I'll change it."

Checking every record makes that possible, because patterns only show up on the whole population. In the sample bank, the error-rate monitor counts errors as first entered by field, branch and loan officer. Eastgate carries 41 of the year's 127 action-taken-date errors: 32 percent of those errors on 16 percent of the records. The monitor reads the 41 and finds that 38 carry the date the file was moved to Suspended, with the decision 4 to 12 days later. The Eastgate case study follows that finding through.

A root-cause finding, sent with its records

Examiners care about this too. The transaction testing guidelines let them direct changes to "policies, procedures, audit processes" to prevent errors that are capable of repetition, even when the errors stay below the resubmission threshold. A finding that names the step and the records is the evidence that a lender found and fixed the cause itself.

The compliance testing manager: what to see before signing off

The compliance testing manager signs off the register before it is filed, so what he needs is evidence, not reassurance. The sample bank's Glen Whitaker states it plainly: "Show me every change, who made it and the page it came from." In most teams that evidence lives in spreadsheets kept by the reviewers, and it is assembled after the fact if an examiner asks.

In the solution, the register reaches him only after the filing edits have run on the corrected data. On the sample register, the syntactical and validity edits find nothing on 5,318 records, the macro-quality edits pass, and three quality edits flag values that are unusual but true (an applicant aged 92, a rate spread of 7.12 on a second-lien home equity loan, a $1.64 million loan on a one-to-four unit property), each confirmed against its page. Whatever is still open is visible to him at sign-off, and anything exported unresolved goes out as entered: the solution does not hide it.

Filing edits run, quality edits confirmed, waiting for sign-off

Whether he can trust a check run by agents is a fair question, and a different one from whether the register is right. The page on measuring HMDA validation accuracy sets out how model risk and internal audit can test it.

The same quarter with every record checked

With every record checked overnight, the quarter's review time moves from searching to deciding. For one quarter's register review at a mid-size lender, we estimate the work falls from about 22 reviewer-days, done by hand on a sample, to about 3.5 with the solution, on every record. Most of the reduction is in finding the page and comparing fields one at a time.

The days that remain are the ones that need a person: the agents read, compare, recompute and count, and stop where a decision begins.

The calendar changes shape too. With the check running nightly on new and changed records and in full at each quarter end, a break is found the night after the record reaches the register, while the file is still fresh and the loan officer still remembers it. January and February hold what is left to decide, the edits and the sign-off, rather than the year's backlog.

What each person keeps, and what they hand over

Each of the four keeps the decisions and signatures that carry their accountability, and hands the agents the mechanical part of their week. Nobody's role disappears; each one moves toward the part of the job only that person can do.

The same team will carry a second register from 2028. Under the CFPB's revised Section 1071 rule, published on 1 May 2026, lenders with at least 1,000 covered small-business originations in each of the two preceding years start collecting small-business lending data on 1 January 2028, and the solution runs the same field-to-file check on a practice 1071 register so the team can rehearse before it counts. The Section 1071 readiness page covers who is in scope.

Questions people ask

What does an HMDA analyst do day to day?

An HMDA analyst or data reviewer compares the fields on the loan/application register with the documents in the loan file, records differences, researches them with underwriting and operations, and prepares corrections. Around quarter ends and in January and February they also work the filing edits and support the year-end scrub.

How long does an HMDA scrub take?

It depends on register size and how much of it is checked. By hand, a reviewer handles one field and one document at a time, which is why most teams check a sample each quarter. By our estimate for a mid-size lender, one quarter's review takes about 22 reviewer-days on a sample, and about 3.5 with every record checked by agents.

Who is responsible for HMDA data accuracy?

The institution is, and Regulation C requires an authorized representative with knowledge of the data to certify its accuracy and completeness when the annual register is filed. In practice, accuracy is shared: loan operations creates the values, the data team checks them, and compliance testing signs off before filing.

Should HMDA data be scrubbed quarterly?

Quarterly filers have no choice: for 2026 data their first three quarters are due 1 June, 31 August and 30 November, and the annual file resubmits those quarters with any corrections. For everyone else a quarterly pass is cheaper than a February one, because the files are recent and the people who made each decision are still at their desks. The aim is a quarter checked in full, not another sample.

What should an HMDA scrub checklist include?

For each record: every reportable field against the document your procedure names as its source, the FFIEC tolerances and no others, rate spread recomputed rather than copied, the census tract geocoded for the right year, and the action taken matched to the file's real outcome. For the register: applications reconciled to the pipeline, errors counted by field rather than by file, and every correction signed with its page.

Is passing the HMDA filing edits enough?

No. The edits test format, valid values and plausibility within the register itself. An examiner tests the register against the loan file, and a value can pass every edit and still disagree with its source document.