Skip to content

Industry-specific operational data

Mortgage servicing and loss-mitigation records for borrower-assistance AI

Quick answer

Mortgage servicing data for AI means post-closing records: hardship intake, loss-mitigation applications and their document checklists, completeness notices, evaluation and decision letters with program and reason codes, appeals, notices of error, requests for information, and servicing call notes. Buy them as linked case files keyed to Reg X milestones, with investor program and decision date on every outcome, hardship narratives redacted beyond basic PII, and a documented basis under Regulation P for the supplier to license borrower data at all.

By SourceX Editorial · Updated

What counts as servicing and loss-mitigation data

Servicing data is everything a servicer creates after the loan boards, which makes it a different corpus from origination files. Underwriting conditions, the 1003 and closing packages belong to the mortgage underwriting conditions and condition-clearing records guide; this page covers what happens once a borrower falls behind, calls in, disputes a charge or asks for help. The useful unit is the borrower episode, not the single document.

A complete loss-mitigation episode typically spans these record types:

  • Hardship intake: call notes, web-form submissions and the borrower's hardship letter or affidavit, including stated reason (income loss, medical, divorce, disaster, death of a borrower).
  • Application package: the servicer's borrower response package, income documents, bank statements, tax transcripts authorization (IRS Form 4506-C), and a received-document log with dates.
  • Completeness notices: the written notice listing missing items, and follow-up outreach.
  • Evaluation and decision: the waterfall run (forbearance, repayment plan, payment deferral, modification, partial claim, short sale, deed-in-lieu), the outcome, and denial reasons per option.
  • Appeal and post-decision: appeal letters, independent review outcome, trial-period payment history and permanent modification booking.
  • Correspondence outside loss mitigation: notices of error, requests for information and complaints, often arriving in the same mailroom queue.
  • Servicing call data: recordings or transcripts, after-call work notes and disposition codes from the servicing contact center.

Most of this lives in a servicing system of record (for example, ICE's MSP platform or similar cores), a loss-mitigation workflow tool, a document imaging system and a contact-center platform. Expect joins across three to five systems, and ask the supplier which system holds the authoritative decision.

Reg X milestones as built-in labels

Regulation X turns a loss-mitigation file into a timeline with legally defined events, which is why these records make strong supervised and evaluation data. Section 1024.41 (12 CFR 1024.41) requires a servicer that receives an application 45 or more days before a foreclosure sale to review it for completeness and send written notice of what is missing within five business days [6]. It then sets evaluation duties for complete applications, appeal rights tied to how far out the sale is [6], and limits on moving foreclosure forward while a complete application is pending, often called dual-tracking limits.

Each of those duties creates a timestamp and a document you can label: application received, acknowledgment sent, application complete, evaluation notice sent, appeal received, appeal decided, foreclosure referral held or released. A completeness-checker model can be trained against the missing-items lists, and an agent's next-step suggestions can be scored against the milestone that actually followed. Ask for every date in the episode, not just the decision date, because day-count errors are the failure mode regulators and borrowers notice first.

Two cautions apply. Section 1024.41 does not oblige a servicer to offer any particular option, so a denial in the data reflects investor rules and the servicer's own requirements, not a regulatory entitlement. And as of October 2026, check the current eCFR text and the Federal Register for amendments to the loss-mitigation provisions before encoding deadlines into labels or evaluation rubrics.

Notices of error and requests for information as a correspondence class

Notices of error and requests for information form a ready-made classification target because the regulation defines them by content, not by title. A notice of error is a written notice that includes the borrower's name, enough to identify the account, and the error the borrower believes occurred. A request for information is defined the same way around the information requested, and a servicer need not treat a request for a payoff balance as a request for information.

The official commentary says a servicer should not rely solely on the borrower's own description to decide whether a letter is a notice of error, a request for information, or both. That makes the servicer's final classification, not the letter's heading, the label to buy. A letter titled "Notice of Error" that only asks for an escrow history is a request for information; a single letter may be both.

For a correspondence classifier, ask the supplier for:

  • the scanned letter or email, plus the OCR text the servicer used;
  • the servicer's classification (NOE, RFI, both, neither, complaint, QWR);
  • the specific error category asserted (for example, misapplied payment, escrow, fees, force-placed insurance, loss-mitigation handling);
  • acknowledgment and response dates, and whether the servicer found an error and corrected it;
  • whether the letter arrived at the designated address or through another channel.

Complaints routed through regulators overlap with this class; the bank complaint records guide covers root-cause labeling for that channel.

Decision labels and the investor waterfall

Loan modification decision data is only useful if every outcome carries the investor program and the guideline version in force on the decision date. Fannie Mae and Freddie Mac servicing guides, FHA requirements and VA guidance each define their own waterfall and eligibility rules, and they change over time. A denial for "excessive forbearance" in one program year may be an approval in another.

Capture these fields for every evaluated option, not just the final one: investor or insurer, program name, guideline effective date, option evaluated, eligible yes or no, reason code, net present value result where used, and the proposed terms. A model trained on outcomes without program and date learns a blend of rules no servicer actually applied. For agent builders, the reasoning behind each step matters as much as the result; see decision records with rationale for what to request.

Outcome fields in servicing systems are not automatically reliable labels. Booked modifications can differ from approved terms after trial-period failures, and reason codes are sometimes defaulted by workflow tools. Sample-check them against decision letters using the approach in verifying outcome labels in operational records.

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

{
  "episode_id": "LM-EP-000417",
  "loan_ref": "tokenized:9f2c71",
  "investor": "GSE_A",
  "program": "flex_modification",
  "guideline_effective_date": "2025-03-01",
  "hardship_reason": "income_reduction",
  "hardship_narrative": "[REDACTED_MEDICAL] ... reduced hours since [DATE_SHIFTED]",
  "milestones": {
    "application_received": "2025-06-02",
    "incompleteness_notice_sent": "2025-06-06",
    "missing_items": ["two_recent_paystubs", "signed_4506C"],
    "application_complete": "2025-06-20",
    "evaluation_notice_sent": "2025-07-11",
    "appeal_received": null
  },
  "options_evaluated": [
    {"option": "repayment_plan", "eligible": false, "reason_code": "payment_exceeds_capacity"},
    {"option": "payment_deferral", "eligible": false, "reason_code": "delinquency_too_long"},
    {"option": "modification", "eligible": true, "terms": {"term_months": 480, "rate_type": "fixed"}}
  ],
  "final_outcome": "trial_plan_offered",
  "trial_payments_made": 3,
  "booked_permanent": true,
  "foreclosure_status_during_review": "referral_on_hold",
  "linked_correspondence": ["NOE-22841"],
  "linked_calls": ["CALL-55102", "CALL-55377"]
}

Hardship narratives and borrower privacy

Hardship letters and call notes routinely contain health, family, employment and immigration details, so treat them as sensitive content that needs redaction beyond names and account numbers. A medical hardship narrative can identify a condition, a death in the family or a disability. In some states that content may fall within consumer health data definitions, such as Washington's, which covers information that identifies past, present or future physical or mental health status [3]. That act also exempts personal information governed by the Gramm-Leach-Bliley Act, so have counsel confirm whether a state health-data law reaches the specific records.

Ask suppliers how they handle free text specifically. Named-entity tools such as Presidio help detect PII, but the project itself cautions that it will not find all sensitive information [4]. Good practice combines detection, category-level masking (for example, [REDACTED_MEDICAL] rather than deletion), date shifting that preserves intervals between milestones, and a human-reviewed sample with a recorded error rate. Property addresses, parcel numbers and loan numbers are quasi-identifiers here; tokenize them consistently so episodes still join.

Call audio carries voiceprints and spoken account details. If you need servicing call data, see call center audio datasets and the guide to after-call work notes and disposition codes. Collections-stage calls follow different rules; the debt collection conversation data guide covers them.

Licensing basis: GLBA, Regulation P and servicing contracts

The hardest question in a servicing data deal is whether the supplier is permitted to license borrower data at all. Servicing files are nonpublic personal information under the Gramm-Leach-Bliley Act. Regulation P limits how a recipient of NPI from a nonaffiliated financial institution may reuse and redisclose it; where the data came in under an exception, use is limited to the ordinary course of business for the purpose it was received [1]. The FTC's business guidance walks through the two cases, received under an exception or not [2].

That matters because subservicers hold data on behalf of owners and investors, and their servicing agreements may restrict secondary use. Before diligence goes further, ask for:

  1. who owns the servicing rights and whether the supplier is a servicer or a subservicer;
  2. the servicing or subservicing agreement clauses on data use and confidentiality;
  3. the privacy notice borrowers received and whether it supports this disclosure;
  4. the de-identification standard applied and who attested to it;
  5. any state law overlays (health data, biometrics for call audio, state privacy acts);
  6. investor or insurer restrictions on data derived from their loans.

If you plan to deploy a model that influences loss-mitigation decisions, also track automated decision-making laws. As of October 2026, Colorado's SB26-189 replaced the 2024 Colorado AI Act, with core obligations, including developer documentation for technology that materially influences consequential decisions, starting January 1, 2027 [5]. Your training-data documentation will feed those disclosures, so keep provenance records from the start. For the broader picture across financial records, read the guide to licensing financial services records.

Buyer checklist for a servicing records request

A good request names the episode structure, the label fields, the redaction standard and the licensing basis up front. Use this checklist to scope it.

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

AreaWhat to specifyWhy it matters
UnitBorrower episode with linked documents, calls and correspondenceAgents and checkers need context, not isolated letters
MilestonesEvery Reg X event date, not just the decisionCompleteness and timeline models are scored on dates
Decision fieldsInvestor, program, guideline date, each option evaluated, reason codesWaterfall logic changes by program and over time
Correspondence labelsServicer's NOE/RFI/both/neither classification and error categoryBorrower titles are unreliable labels
Outcome truthBooked terms and trial-plan results, sampled against lettersSystem outcome fields drift from what was actually decided
Free textCategory masking, date shifting, recorded sample error rateHardship narratives hold health and family details
CoverageDelinquency stages, investor mix, date range, statesAvoid a model that only knows one program era
RightsServicing agreement terms, privacy notice, Regulation P basisSubservicers may not be able to license at all
Evaluation splitHeld-out episodes by time periodTests whether the model survives guideline changes

For evaluation design using these outcomes as ground truth, see outcome-labeled evaluation data. Buyers comparing other regulated-industry corpora can start from the industry-specific operational data hub, and the mortgage operations buyer page describes how SourceX approaches this sector.

How SourceX sources servicing records

SourceX sources operational datasets from US companies on request rather than from stock, so a servicing records request starts with a description of the data and its intended use, not a catalog pick. The process runs Find, Assess (the data and its licensing permissions), Agree (pricing and allowed uses in a license), Transact and Manage, and nothing is contracted until a supplier agrees. Every dataset is rights-reviewed for ownership and consents, personal details are removed or replaced before delivery with the method recorded and a sample checked, and delivery runs through private, access-controlled workflows only after an executed agreement. No method of redaction is perfect, and a request does not guarantee a match. You can describe your servicing data needs to SourceX for teams anywhere.

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

Request mortgage servicing data for your AI team

Describe the loss-mitigation files, correspondence or call data you need, and SourceX will look for US businesses that hold it and handle licensing and ongoing purchases. Every release is approved by the supplying company and delivered under a license that defines records, uses, term and delivery. Start a buyer request.

Sources

  1. Consumer Financial Protection Bureau, "12 CFR 1016.11 - Limits on redisclosure and reuse of information (Regulation P)". https://www.consumerfinance.gov/rules-policy/regulations/1016/11/
  2. Federal Trade Commission, "How To Comply with the Privacy of Consumer Financial Information Rule of the Gramm-Leach-Bliley Act". https://www.ftc.gov/business-guidance/resources/how-comply-privacy-consumer-financial-information-rule-gramm-leach-bliley-act
  3. Washington State Legislature, "Chapter 19.373 RCW - Washington My Health My Data Act". https://app.leg.wa.gov/RCW/default.aspx?cite=19.373&full=true
  4. Microsoft (microsoft/presidio project), "Presidio - Data Protection API". https://pkg.go.dev/github.com/microsoft/presidio
  5. Colorado General Assembly, "SB26-189 Automated Decision-Making Technology" (2026). https://leg.colorado.gov/bills/sb26-189
  6. Electronic Code of Federal Regulations (eCFR), "12 CFR 1024.41 - Loss mitigation procedures". https://www.ecfr.gov/current/title-12/chapter-X/part-1024/subpart-C/section-1024.41

Tell us what your models need

Share scope, volume, language, format, timing and licensing requirements.

Request data