Identity theft & disputes
Four different complaints can hide inside one sentence from a borrower, and each carries its own deadline, restriction, evidence, and proof that it was answered.
“This is not mine,” “your balance is wrong,” “send validation,” and “you furnished the wrong status” are not one generic complaint. One interaction may contain several signals, and LendEasy creates linked matters so each obligation keeps its own policy, deadline, evidence, and closure criteria.
Five signals, five different obligations
The middle column is what has to be answered before anything else can be decided, and no two rows ask the same question. Classifying by sentiment — the borrower is unhappy about the balance — collapses five obligations into one and quietly drops four:
| Signal | Operational question | Typical immediate control |
|---|---|---|
| Debt dispute | Which part of liability, amount, or ownership is contested? | Mark scope; apply configured collection review. |
| Validation request | What information must be provided, and by when? | Track request timing and response eligibility. |
| Furnishing dispute | Which furnished field, period, and destination are disputed? | Preserve source file and investigation deadline. |
| Identity-theft claim | Which account or transactions are alleged fraudulent? | Apply configured fraud/contact/furnishing protections. |
| Payment or balance error | Which intent, return, allocation, charge, or effective date differs? | Open reconciliation and preserve transaction evidence. |
The platform’s rule library can model the FDCPA/Regulation F and FCRA/Regulation V where applicable. Counsel-approved configuration determines scope; the case title is not a legal conclusion.
Protection lands before the investigation starts
Interim restrictions and deadlines are applied as soon as the allegation is classified, before anyone has decided whether it is right. An investigation takes days, and a borrower who says an account is not theirs should not be pursued for it while the answer is being worked out.
The evidence chain behind a finding
A finding is defended by whoever reads the file next, often long after the person who wrote it has moved on. So the chain is assembled from records rather than recollection:
customer allegation / bureau notice
├─ identity and authority verification
├─ contract and disclosure snapshot
├─ payment, return, allocation, and charge timelines
├─ statements and delivered communications
├─ furnished values and acceptance records
├─ restrictions and contact decisions
└─ finding → corrections → response evidenceThe document agent classifies the evidence and extracts the disputed values; the case copilot assembles the differences with its sources cited. The finding is recorded by a person wherever the configured policy reserves it. Neither can invent a missing payment or close a statutory obligation. It cannot invent a missing payment or close a statutory obligation.
Closure is blocked while anything is owed
Deadline calculation records jurisdiction, rule version, trigger event, received time, calendar, extensions, and pause conditions — a due date with no working shown cannot be defended when a borrower says it was missed. The system blocks closure while a required investigation, correction, response, or delivery artifact remains open.
A corrected loan balance, furnishing record, or identity restriction changes through its owning governed API. The dispute case references those result IDs rather than writing financial or reporting state itself, so the correction a borrower was promised and the correction the ledger actually holds are the same record.
Delivering the response
Outbound response still requires an eligible channel and appropriate identity/authority assurance. If electronic delivery is not permitted, the obligation remains open or follows configured alternate delivery. A drafted letter that nobody could lawfully send is a case marked answered and a borrower still waiting — the obligation is the delivery, not the paragraph.