Loading...
compliance

HMDA Reportability Determination Checklist

Use this HMDA Reportability Determination Checklist to decide whether a loan or application belongs in your Regulation C reporting file. It walks through coverage, threshold testing, exclusions, and the final reportability decision with a documented rationale.

Trusted by frontline teams 15 years of frontline software AI customization in seconds

Built for: Banks · Credit Unions · Mortgage Lenders · Nonbank Lenders

Overview

This HMDA Reportability Determination Checklist is a decision tool for identifying whether a transaction belongs in your HMDA reporting population under Regulation C. It is built to capture the facts that matter most: the loan or application identifier, the date, the property type, the institution's current threshold status, whether the credit is dwelling-secured, whether an exclusion applies, and the final reportability decision with a documented rationale.

Use it when a file could be covered but the answer is not obvious, such as a dwelling-secured application with incomplete documentation, an open-end line of credit, a borderline institution threshold issue, or a transaction that may fall into an exclusion. It is also useful as a quality control step before submission, during internal audit testing, or when a reviewer needs to confirm why a file was included or excluded.

Do not use this checklist as a substitute for legal interpretation in highly unusual cases, such as product structures that do not map cleanly to standard mortgage categories, files with missing collateral evidence, or transactions requiring formal escalation. If the institution's threshold status is uncertain, or if the action taken cannot be supported from the file, the checklist should flag the issue for compliance review rather than forcing a quick answer. The goal is a defensible determination, not just a completed form.

Standards & compliance context

  • This checklist supports HMDA reporting decisions under Regulation C by documenting coverage, exclusions, and final reportability determinations.
  • The threshold section aligns with institution-level HMDA applicability testing, which should be based on current origination data and the applicable reporting year.
  • The coverage screening helps distinguish reportable dwelling-secured credit from transactions excluded under the HMDA framework and related agency guidance.
  • For institutions subject to broader compliance programs, the checklist can be paired with internal controls used under ISO 9001-style quality review or enterprise compliance testing.
  • If a transaction touches fair lending, mortgage servicing, or consumer disclosure workflows, the checklist should be retained as part of the institution's audit trail and review evidence.

General regulatory context for orientation only — verify current requirements with counsel or the relevant agency before relying on this template for compliance.

What's inside this template

Transaction Identification

This section captures the basic file facts needed to evaluate HMDA status before any coverage decision is made.

  • Loan/application identifier recorded (weight 2.0)
  • Application date or origination date recorded (critical · weight 2.0)
  • Applicant property type identified (critical · weight 3.0)
  • Transaction file contains sufficient documentation to evaluate HMDA status (weight 3.0)

Institution Coverage Threshold

This section confirms whether the institution is even subject to the relevant HMDA reporting threshold for the year in question.

  • Closed-end mortgage originations threshold met for applicable reporting year (critical · weight 5.0)
  • Open-end line of credit originations threshold met for applicable reporting year (critical · weight 5.0)
  • Applicable threshold documented for the institution (critical · weight 5.0)
  • Threshold determination supported by recent origination data (critical · weight 5.0)

Covered Loan or Application Screening

This section tests the transaction against dwelling-secured coverage rules, exclusions, and reportable action types.

  • Transaction is a loan or application for dwelling-secured credit (critical · weight 8.0)
  • Transaction is excluded from HMDA coverage based on Regulation C exclusions (weight 7.0)
  • Transaction is a covered closed-end mortgage loan or open-end line of credit (critical · weight 8.0)
  • Action taken is reportable under HMDA (critical · weight 7.0)

Reportability Decision and Rationale

This section records the final conclusion and the specific reason the file was included or excluded so the decision can be defended later.

  • Final HMDA reportability determination completed (critical · weight 8.0)
  • Rationale cites the specific coverage rule or exclusion applied (critical · weight 7.0)
  • Any exception, ambiguity, or escalation documented (weight 5.0)
  • Compliance review or second-level approval obtained when needed (weight 5.0)

How to use this template

  1. 1. Record the transaction identifier, application or origination date, property type, and the source documents needed to evaluate HMDA status.
  2. 2. Confirm the institution's applicable closed-end or open-end threshold for the reporting year and attach the recent origination data used to support that determination.
  3. 3. Screen the file for dwelling-secured credit, then test whether the transaction is excluded from HMDA coverage under your Regulation C interpretation guide.
  4. 4. Mark whether the transaction is a covered closed-end mortgage loan or open-end line of credit and document the action taken for applications that were denied, withdrawn, or otherwise resolved.
  5. 5. Complete the final reportability decision, cite the specific coverage rule or exclusion relied on, and note any ambiguity, exception, or escalation.
  6. 6. Route borderline files for compliance review or second-level approval and retain the checklist with the loan file or HMDA workpapers.

Best practices

  • Use the checklist at the point of review, not after the file has already been coded, so missing facts can still be resolved from the source documents.
  • Document the exact reason a transaction is excluded rather than writing a generic non-reportable note.
  • Keep the institution threshold support tied to the same reporting year as the decision so the coverage test is traceable.
  • Flag open-end lines of credit and dwelling-secured applications for extra review because they are frequent sources of HMDA errors.
  • Require second-level approval for ambiguous files, especially when the collateral, purpose, or action taken is not clearly supported.
  • Retain screenshots, system extracts, or origination reports that support the threshold determination and the final decision.
  • Standardize the wording for common exclusions so reviewers do not create inconsistent rationales across similar files.

What this template typically catches

Issues teams running this template most often surface in practice:

Missing or incomplete documentation showing whether the credit was secured by a dwelling.
Threshold support based on stale origination counts or the wrong reporting year.
A transaction coded as non-reportable without a cited exclusion or coverage rule.
Open-end lines of credit that were not separately screened for HMDA applicability.
Applications with unclear action taken that were not escalated for review.
Files where the property type was not identified clearly enough to support the decision.
Inconsistent treatment of similar products across branches or lending channels.

Common use cases

Mortgage Compliance Analyst Reviewing Borderline Files
A compliance analyst uses the checklist to decide whether a mixed-purpose or incomplete mortgage file belongs in the HMDA submission. The structured rationale helps the analyst explain the decision during internal testing or regulator review.
Mortgage Operations Team Running Pre-Submission QC
An operations team applies the checklist to a batch of loans before year-end reporting to catch missing reportable files and misclassified exclusions. This reduces rework by surfacing issues while source documents are still easy to retrieve.
Credit Union Compliance Manager Testing Threshold Status
A compliance manager documents whether the credit union meets the applicable closed-end or open-end threshold for the reporting year. The checklist preserves the data used for the threshold test so the institution can defend its coverage position later.
Internal Auditor Sampling HMDA Decisions
An internal auditor uses the checklist to verify that reportable and non-reportable decisions were made consistently across sampled files. The audit trail makes it easier to trace the conclusion back to the rule or exclusion applied.

Frequently asked questions

What does this checklist determine?

It helps you decide whether a transaction is reportable under HMDA Regulation C. The checklist covers institution threshold testing, whether the file is a dwelling-secured loan or application, whether an exclusion applies, and whether the final action is reportable. It is meant to produce a documented yes/no determination with a clear rationale.

Who should complete the checklist?

It is usually completed by compliance, lending operations, or a HMDA reporting analyst who understands the institution's reporting profile. A second-level reviewer or compliance manager should sign off when the transaction is unusual, incomplete, or close to a coverage threshold. The person completing it should have access to the loan file and the institution's current origination counts.

How often should this be used?

Use it for each application or origination that could fall within HMDA scope, especially when the product type, purpose, or collateral is unclear. It is also useful during monthly or quarterly quality control reviews to catch missed reportable files before year-end submission. Institutions often use it as part of their ongoing HMDA file review process rather than only at reporting time.

Does this checklist replace the need to know Regulation C?

No. It is a decision aid, not a substitute for the underlying rule set in Regulation C and your institution's HMDA procedures. The checklist works best when paired with internal policy, product mapping, and a current interpretation guide for covered and excluded transactions. It should be updated when your product mix or reporting threshold status changes.

What kinds of transactions are commonly missed?

Common misses include dwelling-secured credit that was treated as non-HMDA because the file was incomplete, applications with unclear action taken, and products that changed status after underwriting or closing. Open-end lines of credit and transactions near the institution threshold are also frequent problem areas. The checklist is designed to surface those edge cases before they become reporting errors.

How does this help with compliance reviews?

It creates a consistent record of how the reportability decision was made, including the rule or exclusion relied on. That makes internal testing, audit review, and regulator questions easier to answer because the file shows both the conclusion and the reasoning. It also helps demonstrate that ambiguous cases were escalated instead of being decided informally.

Can this be customized for our institution's products?

Yes. You can add product-specific prompts for construction-to-permanent loans, HELOCs, business-purpose dwelling-secured credit, or portfolio products that create recurring questions. Many institutions also add fields for reviewer name, source system, and links to policy references so the checklist fits their reporting workflow.

How is this different from an ad hoc review in the loan file?

An ad hoc review often leaves the decision buried in email or a comment field, which makes it hard to reproduce later. This checklist standardizes the sequence: identify the transaction, test institution coverage, screen for covered loan/application status, and record the final determination. That structure reduces missed steps and makes the review easier to audit.

Go deeper on the topic

Related concepts
  • Predictive scheduling laws — also called fair workweek laws or secure scheduling — require employers in covered industries to publish employee schedules...
  • Overtime calculation is the process of applying federal, state, local, and contractual rules to hours worked to determine the correct pay — including...
  • A near-miss is an event that could have caused injury or damage but didn't — a slip that didn't fall, a load that shifted but didn't drop, a machine that...
  • Lockout/tagout (LOTO) is the procedure for controlling hazardous energy — electrical, hydraulic, pneumatic, mechanical, thermal, chemical — before...
Related guides

Ready to use this template?

Get started with MangoApps and use HMDA Reportability Determination Checklist with your team — pricing built for small business.

Ask AI Product Advisor

Hi! I'm the MangoApps Product Advisor. I can help you with:

  • Understanding our 40+ workplace apps
  • Finding the right solution for your needs
  • Answering questions about pricing and features
  • Pointing you to free tools you can try right now

What would you like to know?