The HMDA action taken date is the date a lender reports for the final action on an application: for a denial, either the date the decision was made or the date the notice was sent; for an origination, generally the closing date. A date more than three days off counts as an error in an examiner's sample, and when the same field goes wrong again and again, the cause is usually a step in the loan process rather than a slip. The way to reduce those errors for good is to find that step and change it, then prove on the next quarter's records that the error stopped. Correcting the register before filing is necessary, but it is the same work every year if the step stays as it is. Root cause analysis needs one thing a sample scrub rarely has: error counts by field, branch and loan officer across every record, with the records themselves attached, so the people who own the process can see the pattern and the evidence at once.
Every lender that reports under the Home Mortgage Disclosure Act files a loan/application register (LAR) in which each application carries dozens of fields that must match the loan file, and examiners test a random sample of them against the files. Errors in that data topped the Federal Reserve's list of cited consumer violations in 2022, when over 59% of all the violations it cited involved inaccurate collection of residential mortgage data. Botminds' HMDA and 1071 Data Validation checks every reportable field on every record against the page in the loan file it comes from, before filing, and counts what it finds by field, branch and officer. That count is where this case starts.
Take a sample bank's 2026 register as it runs through the solution. Kestrel Valley Bank is fictional: $6.8 billion in assets, mortgage branches plus an online mortgage center, and 5,318 records from January to September. So are its people and borrowers. The mechanics are the ones every HMDA team lives with.
One field, one branch, one status: the finding in four numbers
127
action-taken-date errors as first entered, bank-wide, January to September
41of 127
were at Eastgate, a branch with 16% of the records
38of 41
held the date the file was moved to Suspended, not the date of the decision
4days or more
from that date to the decision (up to 12), against a 3-day examiner tolerance
The finding: Eastgate holds 32% of the action-taken-date errors on 16% of the records
One branch stands out in one field. Eastgate has 862 of the bank's 5,318 records, 16%, yet 41 of the 127 action-taken-date errors, 32%. Its error rate in the field is 4.8%. The other five, including the online center, sit between 1.9% and 2.0%, so tightly grouped that the difference at Eastgate cannot be put down to chance or volume.
Action-taken-date errors as first entered, by branch
The number that makes this a finding rather than a complaint is the one that does not move. Eastgate is an ordinary branch on every other field. Its income error rate is the bank's typical 3.0%; its rate spread, demographic, property value and census tract rates sit inside or below the range of the other branches. If Eastgate's processors were simply careless, the errors would show up across the row. They show up in one cell.
Eastgate is ordinary on every field but one
Eastgate: 4.8%
The other five: 1.9% to 2.0%
Eastgate: 3.0%
The other five: 3.0% to 4.0%
Eastgate: 1.5%
The other five: 1.4% to 2.1%
Eastgate: 0.9%
The other five: 0.9% to 1.6%
Eastgate: 0.9%
The other five: 0.8% to 1.2%
Eastgate: 0.6%
The other five: 0.7% to 1.1%
Eastgate: 0.6%
The other five: 0.4% to 0.5%
A field-by-branch grid like this is cheap to read and expensive to build by hand. It needs an error decision on every field of every record, kept as first entered rather than after correction, because a register scrubbed to zero before filing tells you nothing about where errors come from. The solution keeps both counts: errors as the fields were first entered, and the ones still open.
The evidence: 41 records, and what 38 of them have in common
The error-rate monitor does not stop at the rate. It reads the 41 Eastgate records and compares, for each one, the register date with the dated events in the loan file: the status history in the origination system, the signed credit decision and the adverse action notice. In 38 of the 41, the register holds the date the file was moved to Suspended for missing conditions. The decision came 4 to 12 days later.
The Ellery application shows the pattern on one record. Marcus and Dana Ellery applied on 24 February for a $412,000 home purchase through Eastgate and were denied for debt-to-income. The register holds 14 March. That is the day the origination system moved the file to Suspended. The underwriter signed the credit decision on 20 March, and the adverse action notice is dated and mailed 21 March.
The Ellery record: register date on the left, the loan file's dates on the right
The panel names the cause on the record itself: the register holds the Suspended status date. Across the branch, that one sentence is true 38 times.
Three of the 41 do not fit. They are wrong for other reasons and are corrected one at a time like any other break. A finding that claimed all 41 would be easier to write and harder to trust. The one that went to operations says 38, and attaches all 41 so the reader can check.
Is the action taken date the decision date or the notice date? Either, but never a status
Regulation C asks for the date of the action taken. For a denied application, or a file closed for incompleteness, the commentary allows either the date the action was taken or the date the notice was sent to the applicant. Kestrel Valley's procedure picks the notice date. Moving a file to Suspended while conditions are outstanding is neither. It is a workflow state, and nothing has yet been decided.
The examiners' tolerance is what turns this habit into a guaranteed exam error. The FFIEC transaction testing guidelines do not count a difference of three calendar days or less in the action taken date, provided it does not move the record into the wrong calendar year. Every one of the 38 gaps is at least four days. Not one of them would be forgiven, and it would not matter which of the two dates the bank's procedure chose: on the Ellery file, 14 March is six days from the decision and seven from the notice.
Why the Suspended date always lands outside the tolerance
Why would a register take the first date? The Suspended status is the first date-stamped event that ends a file's active life in the origination system, and on a denial that later goes through a decision memo and a mailed notice, it may be the only status change with a clean date attached. An extract or a processor that reads "the date this file stopped moving" gets 14 March. The decision and the notice live in documents, not in the status history. Only someone, or something, that opens the documents sees the later dates.
The guidelines treat this kind of error as more than a count. Even below the resubmission threshold, and even inside the tolerances, examiners may direct changes to an institution's procedures:
"…to prevent the reoccurrence of errors identified within the sample that are—absent such changes—capable of repetition."
FFIEC HMDA Examiner Transaction Testing Guidelines, paragraph 11
An error that comes from a status step is capable of repetition by definition. It will recur on every Eastgate denial that passes through Suspended until someone changes the step.
Withdrawn, incomplete or conditionally approved: which action taken date to report?
Decide the action first, because the action decides which dates are allowed. Most action-taken-date errors that survive a scrub are not typing mistakes; they are files where the reported action was wrong, or where a date from one stage of the file was paired with the action from another. Regulation C's commentary sets out the action, and then the date, for each way an application can end.
The action decides the date: what Regulation C allows for each outcome
| How the file ended | Action to report | Dates allowed |
|---|---|---|
| Closed and funded | Originated | Closing or account-opening date; initial disbursement if later. Always reported in the year of closing. |
| Credit decision to deny | Denied | The date of the decision, or the date the notice was sent. |
| Applicant withdrew before any decision | Withdrawn | The date the express withdrawal was received, or the date on a written withdrawal. |
| Notice of incompleteness sent, no reply in time | Closed for incompleteness (or denied, if an adverse action notice followed) | The date the action was taken, or the date the notice was sent. |
| Approved subject to underwriting conditions that were not met | Denied | As for any denial: decision date or notice date. |
| Approved subject only to customary closing conditions, not met | Approved but not accepted | Any reasonable date: approval, deadline to accept, or file closed, used consistently. |
| Counteroffer declined or ignored | Denied, on the terms originally requested | As for any denial. |
| Still pending on 31 December | Not reported this year | Reported in the year final action is taken. |
The conditional approval rows are where status-driven dates do the most damage. A file moved to Suspended "for missing conditions" is often, in Regulation C's terms, an application approved subject to conditions, and what it becomes depends on which conditions are missing. If they are underwriting or creditworthiness conditions, such as verified income, a satisfactory appraisal or a debt-to-income ratio, and they are not met, the action is a denial. If the lender asked for the missing information in a written notice of incompleteness under Regulation B and the applicant did not answer in time, it is a file closed for incompleteness. If only customary closing conditions remain, such as clear title or a survey, it is approved but not accepted. None of the three outcomes is dated by the day the file stalled.
Two checks catch most of the rest. The year must be right: the examiners' three-day tolerance does not apply where a date difference puts the record in the wrong calendar year, so a stalled December file dated into January, or the reverse, is an error however close the dates are. And the mix must be plausible: the 2026 filing guide's macro-quality edits expect no more than 15% of entries to report approved but not accepted and no more than 30% to report withdrawn, so a lender that files stalled applications under either code will meet the edits before it meets the examiner.
Why a sample scrub does not see a branch pattern
A sample is built to estimate an error rate, not to locate one. On this register, an examiner's 79-record sample would contain about 13 Eastgate files, and at Eastgate's rate, on average fewer than one Eastgate action-taken-date error. A quarterly scrub of 300 files would turn up two or three a quarter, scattered across officers and months, each one looking like an isolated slip that someone fixed.
That arithmetic is the whole case for counting every record. Forty-one errors on one branch are a pattern; two or three a quarter are noise. Whether the sample would trigger a resubmission is a separate question, covered in how examiners test HMDA data and what the odds are; on this sample register, the action taken date alone carries an estimated 12-in-100 chance of reaching four errors in an examiner's sample. Sample scrub, rules engine, or every field against the file compares the three methods directly.
The field-by-branch grid that surfaced the pattern
The conversation: "Could officers leave the status until the decision is signed?"
The finding went to the person who owns the step, not to the people who made the entries. Renata Okafor, the bank's HMDA data manager, sent it to Priya Nandakumar, loan operations lead at Eastgate, with the 41 records and their adverse action notices attached. The message is three sentences long and ends in a question.
A root-cause finding, sent with its records
The question form is deliberate. Compliance can see that the date is wrong and where it comes from; it cannot see why Eastgate's officers move files to Suspended earlier than the rest of the bank, or what else the status may drive, such as pipeline reports, condition tracking or turn-time measures. The loan operations lead can. Her own line in the sample is the brief for every finding: "Tell me which step creates the error and I'll change it."
There are at least four ways to answer the question, and they are not equally good.
Four ways to answer the finding, and what each leaves open
What it fixes: This year's register, record by record.
What it leaves open: Next year's 41. The error rate as first entered never moves, and examiners can ask why a known, repeatable error was not addressed.
What it fixes: Any part of the problem that is a misunderstanding of what the field means.
What it leaves open: A system stamp. If the register reads the status date, a well-trained officer still produces the wrong date by using the status as designed.
What it fixes: The 38: the first date-stamped event becomes the decision itself.
What it leaves open: Whatever else the status was for. If pipeline reporting relies on it, the branch loses a signal, which is why the decision belongs to operations.
What it fixes: Every branch, every denial, whatever officers do with the status.
What it leaves open: Nothing for this field, if the notice date is captured reliably in the system. It is a change to the extract or the origination system, so it takes longer to land.
The fix, and the control that proves it held
A root cause is closed when the error rate at the step falls and stays down, not when the change is announced. Because the solution checks new and changed records every night, the evidence that the fix held builds without a separate audit. The control has three parts:
- The rate as first entered, by month. Eastgate's action-taken-date rate on records entered after the change, against the 1.9% to 2.0% the other branches show. Corrected registers hide the signal; first-entered counts do not.
- The share carrying the Suspended date. The finding's own measure, 38 of 41, should fall toward zero. If the rate falls but the remaining errors still hold the status date, the change was partial; if the rate stays high and the cause changes, something else is going on.
- The other branches. A fix to the extract moves every branch at once. A fix to Eastgate's practice should move Eastgate alone. Either way, the grid shows which one happened.
The sample register ends in September, so this case has no after-the-fix month to show, and no figure here should be read as a result. What a lender would watch is set out above: the first full month of new denials after the change, then the quarter-end run. What a working fix is worth, in hours and in exam exposure, is worked through in the cost of HMDA data errors and the ROI of checking every record.
A root cause analysis playbook for any HMDA field
The Eastgate case generalises. Most recurring HMDA errors have a step behind them that writes the wrong value the same way every time: a status, a template, a table, a form that was never keyed. The Federal Reserve's own list of sound practices names standard procedures for the application date and the action taken date among the first places to look. The table below pairs the error as an examiner sees it with the step that usually produces it, for the fields where the solution most often writes up a cause.
Each common HMDA error has a step behind it
How the error shows up: The register holds a date days before the decision or the notice.
The step that usually makes it: A status change (Suspended) or the decision memo date read in place of the action or notice date.
How the error shows up: Income higher than the underwriter relied on.
The step that usually makes it: Net keyed instead of gross, or bonus and overtime included that the income worksheet excluded.
How the error shows up: A spread that does not recompute from the APR.
The step that usually makes it: The adjustable-rate APOR table used for a fixed loan, or the application date used instead of the lock date.
How the error shows up: "Not provided" when the applicant answered.
The step that usually makes it: An online demographic form completed by the applicant and never keyed into the system.
How the error shows up: A value that does not match the appraisal.
The step that usually makes it: The purchase contract price carried into the field.
How the error shows up: A tract that no longer exists or has moved.
The step that usually makes it: Geocoding against the prior census vintage.
How the error shows up: A figure that differs from the final disclosure.
The step that usually makes it: Section D taken from the Loan Estimate instead of the Closing Disclosure.
From error to step to control, in six moves
- Count errors as first entered, on every record.
A corrected register or a sample cannot show where errors come from. Keep the first-entered value for every field that broke.
- Cut the counts by field, branch and officer.
Look for a cell that stands out against an otherwise ordinary row and column. One branch high on one field points to a step; one branch high on every field points to something else.
- Read the records behind the cell.
Compare each wrong value with every dated or sourced event in the file until most of them share one explanation. State how many do, and leave the rest as individual breaks.
- Name the step, not the people.
Write the finding as "the register holds the Suspended date", not "officers enter the wrong date". The first can be changed; the second invites a defence.
- Send it to the owner of the step, with the records.
A question with evidence attached gets a process change. A rate without records gets a training reminder.
- Measure the next month as first entered.
Close the finding only when the rate and the cause share both fall, and keep the field on the nightly check either way.
What not to do: officer league tables without the records
The tempting shortcut is a ranking of loan officers by error count. On this register it would mislead. The cause is a status that every Eastgate officer uses on a denial, so a league table would mostly rank who handled the most denials, and hand them a problem they did not create and cannot fix alone.
Officer-level counts are still worth keeping, for the opposite case: an error confined to one person's files, on several fields, is a training need, and the records show which fields. The rule the solution follows is the right one for any team: no cause is named without the records behind it. A rate tells you where to look. Only the records tell you what you found, and they are what the owner of the step needs in order to act. How the error-rate monitor and the other agents divide that work, and what each may never do, is set out in inside agentic HMDA validation.
Questions people ask
What is the action taken date for a denied HMDA application?
Under Regulation C, a lender reports either the date the denial was decided or the date the adverse action notice was sent. A date when the file changed status, such as Suspended for missing conditions, is neither. A written procedure should pick one of the two allowed dates; the sample bank here uses the notice date.
What is the action taken date for an originated loan?
Generally the closing or account-opening date. If funds are disbursed later, the lender may use the date of initial disbursement, and for a construction-permanent loan it may use the date the loan converts to permanent financing. Whatever date is used, the origination belongs to the register for the year the loan closed.
Do errors inside the 3-day tolerance still matter?
They are not counted toward the resubmission threshold, but the FFIEC guidelines let examiners direct procedural changes for repeatable errors even when they fall inside the tolerances. A pattern of dates one to three days off can have the same kind of cause as one four to twelve days off, with a shorter delay that hides it from the count.
How do you write an HMDA corrective action plan for a recurring error?
Start from the finding: the field, where it concentrates, the share of records that share one cause, and the records themselves. Then name the step that will change, who owns it, the date it changes, and the measure that will show it held, which is the rate as first entered on records after that date.
Is an application still pending at year end reported?
No. Regulation C's commentary says an application still pending on 31 December is not reported for that year; it goes on the register for the year in which final action is taken. An extract that dates stalled files at year end to force them onto the register creates exactly the status-date error this case describes.
Should root cause findings go to compliance or to operations?
To whoever owns the step that makes the error, which for most HMDA fields is loan operations, underwriting or the team that runs the origination system. Compliance keeps the evidence and checks the next quarter; operations makes the change.