Clustered 3 filings across 2 jurisdictions · filing window Jan 8, 2024 → Mar 12, 2024. View entity profile → Other incidents for this victim →
incident inc_3f8c7eaf82f648a4 · merge_method human · confidence 100%
Discovered → first regulatory filing
Gap between first leak claim and first regulatory filing
Materiality determination to SEC 8-K filing
Time between earliest and latest filing
Not recorded for this incident
Discovery variance · Materiality delta — needs two dated filings.
FEDERAL
Leak Site · SEC 8-K
Earliest sighting first · deep chronology in Litigation Timeline
Jan 4, 2024
When the intrusion reportedly occurred, per the linked filings
Jan 4, 2024
Reported by SEC 8-K filing
Jan 4, 2024
Registrant determined the incident material — starts the SEC 4-business-day clock
loanDepot, Inc. disclosed on Form 8-K (Item 8.01) a cybersecurity incident affecting certain systems. Unauthorized third-party activity included access to Company systems and the encryption of data. The Company contained the incident, shut down certain systems, engaged cybersecurity experts, and notified regulators and law enforcement. Investigation is ongoing; materiality assessment continuing.
LoanDepot, is an Irvine, California-based nonbank holding company which sells mortgage and non-mortgage lending products.
loanDepot, Inc. filed an amended 8-K (Amendment No. 2) regarding a cybersecurity incident it has contained. The company identified unauthorized access to sensitive personal information, impacting up to 16.9 million individuals. The company is notifying affected individuals and offering free credit monitoring. The incident is expected to result in $12-17 million in Q1 2024 expenses, net of insurance. Law enforcement and regulatory engagement continues.
Affected (this filing): 16,900,000
About this clustering
DisclosureLens links filings into incidents through layered matchers: deterministic rules (same source document, multistate filings of one breach, tight-window same-victim pairs), a weighted-similarity scorer for cross-source candidates, and an operator review queue for everything uncertain. Each link records its own method and confidence — shown per filing in the timeline below. The system defaults to NOT merging when uncertain, because a false merge (collapsing two unrelated breaches) is more harmful than a false split (showing related filings separately); uncertain pairs route to human review instead of auto-merging. Filing summaries shown in the timeline are AI-generated extracts — verify each against its linked source.