Mortgage underwriting conditions and condition-clearing records for underwriting agents

What a condition-clearing record has to capture

A usable record links one condition to its trigger, its evidence, its decision history and the policy that governed it. Most loan-origination systems store conditions as a list on the loan with a status field, but the training value sits in the transitions between statuses, not in the final "cleared" flag.

Conditions usually fall into three timing buckets: prior to docs (PTD), prior to closing (PTC) and prior to funding (PTF). Many originate from automated underwriting: Fannie Mae's Desktop Underwriter (DU) returns its minimum documentation requirements in the Verification Messages/Approval Conditions section of the findings report [7], and those requirements vary with the risk factors in each loan file. Freddie Mac's Loan Product Advisor (LPA) plays the same role for loans underwritten to Freddie Mac. Underwriters then add manual conditions, and lenders may require more documentation than DU asks for, which is exactly where lender overlays show up in the data.

A condition-clearing agent typically does four jobs: classify incoming documents, match them to open conditions, decide whether the evidence satisfies the condition, and draft the clearing or rejection note. Each job needs a different slice of the record, so ask for all of them at once rather than buying documents and decisions separately.

The fields that make conditions data trainable

The trainable unit is a condition with its full cycle history, keyed to stable document and loan identifiers. Specify the schema before talking volume.

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "loan_ref": "L-7f3a91",
  "condition_id": "C-0412",
  "condition_text": "Provide most recent 2 months' statements for checking account ending XXXX; source large deposit of $X on MM/DD.",
  "category": "assets",
  "timing": "PTC",
  "origin": "AUS",
  "aus_engine": "DU",
  "aus_message_ref": "verification_message_hashed_id",
  "aus_recommendation_at_trigger": "Approve/Eligible",
  "created_at": "2025-03-04T15:12:00Z",
  "policy_version": {"investor_guide": "Selling Guide as of 2025-02-05", "overlay": "lender_overlay_v14"},
  "cycles": [
    {"cycle": 1, "doc_ids": ["D-221"], "doc_types": ["bank_statement"], "decision": "rejected",
     "reason_code": "MISSING_PAGES", "note": "Statement page 3 of 4 missing.", "reviewer_role": "underwriter"},
    {"cycle": 2, "doc_ids": ["D-221", "D-240", "D-241"], "doc_types": ["bank_statement", "letter_of_explanation", "transfer_record"],
     "decision": "cleared", "reason_code": null, "note": "Deposit sourced to transfer from verified savings.", "reviewer_role": "underwriter"}
  ],
  "cycle_count": 2,
  "hours_to_clear": 52.5,
  "final_status": "cleared"
}

Four details in that record carry most of the value:

• Origin and AUS reference. Separating AUS-generated from manual conditions lets you measure whether the agent handles overlays, not just GSE boilerplate. Keep the findings message identifier so you can rebuild what DU or LPA actually asked for.
• Rejection reason codes. Suspense and rejection reasons ("missing pages", "stale dated", "name mismatch", "unsourced deposit", "unsigned") are the hardest negatives your model will see. A dataset with only cleared conditions trains an approver.
• Document linkage. Each cycle should list the exact document IDs reviewed, with page-level references when the LOS supports them, so you can build document-to-condition matching pairs.
• Policy version. Clearing decisions are judgments under a specific guide and overlay. Investor guidance changes regularly, and DU release notes periodically change findings messages, so ship the version in force for each loan.

For the application data the conditions refer to, standardized structures help: the redesigned URLA (Form 1003) [1] and the ULAD data mapping maintained under the Uniform Mortgage Data Program [2] give you consistent field names for income, assets and liabilities that conditions reference. The loan documents themselves are a separate purchase covered on the underwriting files page.

How AUS findings and manual conditions differ as training signal

AUS conditions are predictable and largely public in their logic, while manual conditions encode a lender's private risk judgment, so the two need different handling. The DU findings report summarizes the recommendation and eligibility of the casefile and groups messages by type, with some messages appearing only on certain recommendations.

Potential red flag messages in DU are a separate category: they do not change the recommendation and their absence does not mean the data was accepted [7]. If your agent treats the findings report as ground truth, it will miss what underwriters catch manually, and it will over-trust a clean report. Label red-flag-driven conditions distinctly so you can evaluate the agent on them.

Public investor guides work well as a retrieval corpus: a clearing agent can cite the Selling Guide section that defines an acceptable document. Lender overlays, credit policy memos and condition libraries are proprietary, so they arrive only with the supplier's permission and should be licensed explicitly alongside the decision records.

Rights, privacy and fair-lending constraints buyers should plan for

Condition files are dense with nonpublic personal information, so de-identification and use limits shape what you can buy and how you can use it. Under the Gramm-Leach-Bliley Act, the FTC explains that a recipient of NPI steps into the shoes of the originating institution, and the reuse and redisclosure limits bind the recipient even if it is not itself a financial institution [3]. Regulation P limits a recipient that obtained NPI under an exception to using it in the ordinary course of business for the purpose it was received [4].

In practice, plan for borrower names, SSNs, account numbers, property addresses and employer names to be removed or replaced, including inside condition text and underwriter notes, where free text often repeats them ("Provide VOE from [employer] for [borrower]"). Ask how the supplier tokenizes values so that the same account number maps to the same token across a condition and its documents; otherwise document matching breaks.

Two downstream rules matter for evaluation design. Regulation B requires creditors to give specific reasons for adverse action [5], so if an agent's notes ever feed denial reasons, you need reason codes that map cleanly to explainable categories. As of October 2026, Colorado SB26-189 requires developers of automated decision-making technology that materially influences a consequential decision to give deployers technical documentation from January 1, 2027 [6]; vendors selling clearing agents to lenders should keep training-data provenance documentation ready. The privacy guide for de-identified training data covers methods in more detail.

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

Buyer checklist for a condition-clearing data request

A precise request names the condition scope, the decision history depth and the policy context you need. Use this as a starting template when you describe data to suppliers.

Illustrative example: invented to show structure; it does not describe an available dataset.

Evaluating a condition-clearing agent with real decisions

Real clear and reject decisions make a strong held-out benchmark, provided you split by loan and by time rather than by condition. Splitting by condition leaks: two conditions on the same loan share documents and borrower context.

Useful metrics include document-to-condition match precision at the page level, clear/reject agreement with the underwriter on the final cycle, false-clear rate on conditions that were rejected at least once, and note quality judged against the underwriter's actual note. Hold out a later time window to test whether the agent survives a guide or overlay update. The approach mirrors other outcome-labeled evaluation data, and the rationale-capture issues overlap with decision records with rationale.

Common failure modes to test for: stale documents accepted because the agent ignores statement dates, name-variant mismatches across documents, conditions cleared on a letter of explanation where policy requires third-party verification, and agents that clear duplicates of a condition already waived.

How this differs from nearby mortgage and underwriting data

Condition clearing sits between origination documents and the final credit decision, so it overlaps with, but is not the same as, adjacent datasets. Insurance-side judgment is covered under insurance underwriting decision rationale, and post-closing borrower work lives in mortgage servicing and loss-mitigation records.

Multi-step workflow traces from loan-origination systems, where an agent's actions matter as much as the decision, fit the workflow task histories page. For a broader view of the vertical, see mortgage operations buyers and the industry-specific operational data hub.

Sourcing condition-clearing records through SourceX

SourceX sources operational datasets from US companies on request and manages the commercial process, including the license; nothing is held in stock and a request does not guarantee a match. You describe the condition data you need, and SourceX looks for US businesses that hold it, with every release approved by the supplying company. Each dataset is reviewed for ownership and consents, personal details such as names and account numbers are removed or replaced before delivery, and the method is recorded. Start by describing your condition-clearing data needs.

Request mortgage underwriting conditions data

If you are building a condition-clearing agent or an evaluation set for an underwriting assistant, describe the condition types, AUS coverage and decision history you need. SourceX works through Find, Assess, Agree, Transact and Manage, and every dataset is delivered under a license that defines records, uses, term and delivery. Tell us what you need on the buyers page.