AI for HMDA compliance: six agents, and what each may never do

AI for HMDA compliance, done properly, means checking every reportable field on every loan/application register (LAR) line against the page in the loan file it came from, with the examiners’ tolerances applied, before the register is filed. That is hard because a register of a few thousand applications holds hundreds of thousands of field values, the sources are scattered across the many documents in each loan file, and examiners test against the file, not against the system of record. Botminds’ HMDA and 1071 Data Validation exists to do that check on every line rather than a sample, and to hand people only the fields that disagree.

It does the work with six specialist AI agents rather than one model. A register reader works out which fields apply, a loan file reader finds each field’s source page, a rate spread and geocode checker recomputes the two fields that must be computed, a field matcher compares with tolerances, a filing edit runner runs the FFIEC edits, and an error-rate monitor counts what was found. Each agent has one thing it may never do. People make every change to the register.

Why HMDA validation needs six agents, not one AI model

Because the check is six different jobs with six different ways of failing, and a single model doing all of them can fail silently at any one. Reading a LAR row, finding a page in a 200-page file, recomputing a rate spread, judging a difference, running a published edit set and counting errors draw on different inputs and need different kinds of rigour.

The worst failure in this work is a plausible value. A model asked to “check the income” that cannot find the underwriter’s worksheet will often find a number somewhere else in the file, and the check passes on the wrong evidence. Split the work, and the agent that reads the file is not the agent that judges it, so a value with no source page arrives at the matcher marked “no source” instead of disguised as a match. It is the maker–checker separation lending already applies to people, applied to software.

The split also matches how the examiner works. The FFIEC HMDA Examiner Transaction Testing Guidelines compare the LAR with the loan file field by field, and for a register of 501 to 100,000 lines four errors in one field among a sample of 79 mean that field is corrected and resubmitted across the whole register. The examiner is counting field-level disagreements with the file, so that is the unit each agent works in. When the CFPB sued Freedom Mortgage in 2023, it alleged that 51 errors found in an initial review of 159 files led to a resubmission correcting 35 different data fields, over 174,000 entries touching nearly 20 percent of the company’s applications. Errors at that scale come from processes, not from one bad file.

Do regulators allow AI in HMDA compliance?

Yes: no rule forbids it, and the regulators use it themselves on the same kind of task. What no rule changes is who answers for the data. Regulation C still requires an authorized representative with knowledge of the data to certify the register’s accuracy and completeness, and the bona fide error defence still depends on “procedures reasonably adapted to avoid such an error”. An AI check is one of those procedures, not a substitute for the person who signs.

The supervisors’ own use is the closest precedent. The GAO found that NCUA, the CFTC and the Federal Reserve use AI to help detect errors or outliers in data submitted by financial institutions; NCUA predicts Call Report values, flags those outside the predicted range and asks the credit union to review and correct them. That is the pattern this page describes, pointed the other way: the lender’s agents flag, the lender’s people decide.

The expectations come from existing frameworks rather than an AI rule. The Treasury’s 2024 report recommends that firms check AI use cases “for compliance with existing laws and regulations before deployment” and periodically re-evaluate them. In May 2026 the Federal Reserve’s Vice Chair for Supervision said banks “are relying on existing risk-management frameworks to guide their use of AI”, and that the Fed, OCC and FDIC had amended their model risk guidance to clarify that it does not apply to generative or agentic AI. For an HMDA check, that puts the weight on outcome testing the bank designs itself, set out in how to validate an AI model that checks HMDA data.

The register reader: which HMDA fields apply to this application

The register reader decides what “every field” means for each application before anything is compared. It reads new and changed applications nightly from the mortgage and commercial origination systems, one row per application, and builds each row in the federal filing format.

The number of fields that apply depends on what happened to the application. In the solution’s sample register, a denied purchase carries 86 applicable fields, an originated loan 94 and a withdrawal 61. A denial has no rate spread to report; a withdrawal has no property value relied on. Getting this wrong in either direction is costly: checking a field that does not apply produces false breaks, and skipping one that does leaves an error for the examiner to find.

Its limit is the simplest of the six and the one an IT architect asks about first: it is read-only on the origination systems. It never writes back to the loan origination system, and nothing downstream does either. Corrections live on the register, signed by a person, and a finding about the upstream process goes to the people who own it.

The loan file reader: a source page for every field, or “no source”

The loan file reader finds, for each field, the one document and page that is the source of truth, and extracts the value exactly as it appears there. That is most of the manual work it replaces: the hours a reviewer spends opening loan files in several systems to find the right page.

Take a sample application from the solution’s fictional lender, Kestrel Valley Bank: Marcus and Dana Ellery’s $412,000 home purchase, denied for debt-to-income. The loan file reader opened 31 documents and 212 pages and found a source page for all 86 applicable fields. The sources it works from are the ones an examiner would pull: the application, the credit decision, the adverse action notice, the Closing Disclosure, the appraisal, the rate lock, the underwriter’s income worksheet, the demographic addendum and, for small-business applications, the tax return. Which page each field comes from is set out field by field in the map of HMDA key fields to their source documents.

The choice of page is often the whole question. Income is the gross annual income the lender relied on, so its source is the underwriter’s worksheet, not the application. The action taken date for a denial is, under this bank’s procedure, the date on the adverse action notice, not the date a status changed in the origination system. Property value comes from the appraisal, not the purchase contract.

Its limit: it never guesses. When it cannot find a value, the field is marked “no source” and goes to a person as a gap, which is itself a finding, because a field with no support in the file is one the examiner cannot verify either.

All 86 fields on one denied application, each with the document it was checked against

The rate spread and geocode checker: recompute, don’t trust

Two HMDA fields cannot be checked by looking them up, because no page in the file holds the right answer: rate spread and census tract. The checker recomputes both and hands the matcher a value to compare.

Rate spread under Regulation C is the difference between the loan’s APR and the average prime offer rate (APOR) for a comparable transaction as of the date the rate was set. The common errors are mechanical: the adjustable-rate APOR table used for a fixed loan, or the application date used instead of the lock date. The checker takes the APR and the lock date from the file, picks the table for the loan type, and recomputes. Its limit is a rule of the regulation itself: it never reports a rate spread where Regulation C says NA, as for the Ellery denial.

Census tract is geocoded from the property address and compared with the register. The usual failure is a tract taken from a prior census vintage. Regulation C treats an incorrect tract as a bona fide error only if the institution maintains procedures reasonably adapted to avoid it (12 CFR 1003.6(b)(2)), so a recorded, independent geocode on every application is the procedure, not an extra. The Ellery address resolves to tract 42041011802, which matches.

The field matcher: FFIEC tolerances and your HMDA procedure as rules

The field matcher compares each register value with its source and decides one of three things: match, difference within tolerance, or break. It is the only agent that judges, and it judges by written rules: the examiners’ tolerances and the bank’s own HMDA procedure.

The tolerances come from the transaction testing guidelines. They list four allowances, and every other field must agree exactly. The matcher applies them as the examiner would, which matters in both directions: a one-day difference in the application date is not an error and should not consume a reviewer’s time, while a seven-day difference in the action taken date is, however reasonable it looks.

The bank’s procedure supplies the rest. Kestrel Valley’s sample procedure says a denial is reported on the date of the adverse action notice, that income is the gross income relied on from the underwriting worksheet, and that rate spread is recomputed from the lock date. Each is a setting the bank owns, each change applies from the next run, and each is kept as a new version of the rules, so an examiner can see which rule a given break was judged under. The tolerances can only be tightened; the screen refuses anything looser than the examiners allow.

The matcher’s rules are the bank’s settings, and the examiners’ tolerances are a ceiling

When a field breaks, the matcher writes it up so that a person can decide in one look, without reopening the file.

One break, written up: $148,000 on the register, $135,000 relied on

The matcher’s limit is that it never edits. It can say the register is wrong and show why; it cannot change a value. Across the sample lender’s third quarter, 1,846 applications produced 214 breaks: 37 were differences within tolerance, closed with a note, and 177 needed a person.

The filing edit runner and the error-rate monitor: valid is not accurate

A register can pass every FFIEC filing edit and still fail transaction testing, because the edits check the register against itself and the examiner checks it against the file. The last two agents cover both: one runs the edits, the other measures what the file check found.

The filing edit runner

The 2026 Filing Instructions Guide defines four types of edit. Syntactical edits check format and filing year; validity edits check that each field holds a valid value; both must be fixed before the register can be submitted. Quality edits flag values that are unusual for a field or a combination of fields, and macro-quality edits flag a register whose overall pattern is unusual; for both, the filer either corrects the values or confirms they are accurate. The runner runs all four on the corrected register and drafts the explanations.

Quality edits are where a person’s confirmation matters, since the value is often true. On the sample register all 5,318 lines passed the syntactical and validity edits, macro-quality passed, and three quality edits needed a person: an applicant aged 92, a 7.12 rate spread on a second-lien home equity loan, and a $1,640,000 loan on a one-to-four-unit property. Each was confirmed against its page. The runner’s limit is that it never files: the register goes to the compliance testing manager for sign-off, and a person submits it.

The edits run on the corrected register; the unusual-but-true values are confirmed by a person

The error-rate monitor

The monitor counts errors as first entered, before anyone corrected them, by field, branch and loan officer, and turns those counts into the question an examiner’s sample will answer: would 79 randomly drawn applications contain four errors in any one field? On the sample register as first entered, the screen’s cautious estimate is 37 in 100, which counts every field across all 79 files; run through the examiner’s full two-stage rule, it is about 29 in 100. How both are computed from the published sample sizes and thresholds is the subject of how examiners test HMDA data.

The monitor also looks for causes, under its own limit: it never names a cause without the applications behind it. On the sample register, one branch carried 41 of the year’s 127 action-taken-date errors, and in 38 of those 41 the register held the date the file was moved to a Suspended status, four to twelve days before the credit decision. The finding went to that branch’s loan operations lead with all 41 applications attached. The guidelines give examiners the power to direct changes to procedures for errors capable of repetition even below the resubmission threshold, so a cause found and fixed before the exam is worth more than the corrections themselves. The branch case is told in full in the root-cause case study.

The line no agent crosses: read-only, no edits, no filing

Each agent has one limit of its own, and three limits bind all six: no agent changes a value on the register, confirms a demographic correction, or signs off the register for filing. Those are the decisions an examiner holds a named person accountable for, so they stay with named people.

The decisions people keep are concrete. The HMDA data manager either corrects a break and signs it with a reason, or keeps the register value and signs a reason for that, such as “the document is wrong, a corrected copy is requested”; a kept value is shown to the compliance testing manager at sign-off. Every correction keeps its before, after, evidence page, reason, signer and time, and the list exports for the examiner.

Demographic fields get a second person for a reason the enforcement record makes plain. In 2023 the CFPB ordered Bank of America to pay a $12,000,000 civil money penalty after finding that some loan officers recorded “information not provided” without asking applicants for their race, ethnicity and sex. Those fields are what fair-lending analysis of HMDA data rests on, so no correction to ethnicity, race or sex stands until a second reviewer confirms it.

For an architecture review, two further properties matter. The register reader is read-only on the origination systems, and a register value changes only through a correction a named person signs with a reason. And agent findings and human decisions are recorded separately, so the audit trail can always say which a given change was.

One HMDA application’s run, step by step

Followed end to end, the Ellery application shows how the six divide the work and where it stops for a person. The run reads the row, opens the file, recomputes, matches, and then waits.

The two breaks are the instructive part. The register holds 03/14/2026 as the action taken date: the day the origination system moved the file to Suspended for missing conditions. The credit decision was signed on 03/20 and the adverse action notice is dated 03/21/2026. Seven days is outside the tolerance, and the bank’s procedure reports a denial on the notice date, so the matcher breaks the line and cites both the procedure and the notice page. The income break is the bonus: $148,000 on the register, $135,000 relied on by the underwriter.

Neither break is corrected by an agent. The data manager opens each, reads the page, corrects both and signs each with a reason; the application is then clean, and the quarter’s open breaks fall from 48 to 46. The application date, one day off the signed application, never reached her at all.

The run log ends where the agents’ authority does: “waiting for” a named person

Read the last line. The run does not end in “corrected”; it ends with two corrections waiting for the data manager’s signature.

What should a bank ask before using AI for HMDA compliance?

Ask how each way an AI check can fail is caught, because the failures are specific and each one has a control a vendor can show. A general claim of accuracy answers none of them. The table pairs the five failure modes we see in this work with the control that answers each, and with what to ask to see on one of your own records.

Two limits belong in the answer as well, because no AI removes them. A field check sees only the records it is given, so applications that never reached the register still need reconciling against the pipeline. And where a fact was never written down, such as a demographic question that was not asked on a phone call, no page in the file can settle it: the control there is monitoring how often each officer records “not provided”, which the error-rate monitor counts by officer and branch.

The same agents run, unchanged in shape, on a practice register for Section 1071 small-business lending, whose compliance date under the CFPB’s revised rule is 1 January 2028. There the loan file reader’s critical page is often a business tax return, because verified gross annual revenue decides whether an application is covered at all; the practice register is covered in Section 1071 readiness under the 2026 rule.

Questions people ask

Does the AI change our HMDA data?

No agent changes the register or the origination system. A register value changes only through a correction a named person signs with a reason; otherwise the value is kept with a signed reason.

What happens when the agent cannot find a value in the loan file?

The field is marked “no source” and routed to a person. The loan file reader is not permitted to infer a value from elsewhere in the file, because a field the file cannot support is one an examiner cannot verify.

How do we know the agents are finding the errors?

By testing them the way model risk would test any model: seeded errors, measured detection and false alarms, and a check of source coverage. That framework is set out in how to measure HMDA validation accuracy.

Does checking every field replace the pre-filing edits?

No; it runs them too. The FFIEC edits prove the register is internally consistent and are required to submit, but they do not compare a value with the loan file, which is what an examiner does.

Will AI replace the HMDA data manager?

No; it changes the job from finding errors to deciding them. In the sample quarter the agents raised 214 breaks on 1,846 applications and closed 37 as within tolerance; the other 177 needed a person to correct and sign, or to keep the value with a reason. The certification, the demographic second review and the sign-off stay with named people.

What does an AI HMDA check need from the bank?

Three things it already has: the written HMDA procedure, a read-only register extract from the origination systems, and access to the loan files. The procedure matters most, because each rule that decides a reported value, such as which date a denial is reported on, becomes a setting the matcher cites in every break. The sequence is in our HMDA reporting software buyer’s plan.