Last User Data Retention and Deletion Policy
Policy version: 3.2
Effective date: October 31, 2026
Operator: Elysian Studios LLC ("Last," "we," "us")
Privacy contact: [email protected]
Privacy request: https://lastdating.app/privacy-rights.html
Privacy Policy: https://lastdating.app/privacy.html
Biometric Retention and Destruction Schedule: https://lastdating.app/biometric-schedule.html
Website Waitlist Privacy Notice: https://lastdating.app/waitlist-privacy.html
If this Policy conflicts with the Privacy Policy, the Privacy Policy controls. Applicable law controls where it requires a shorter period, different process, or preservation.
1. Retention principles
Last applies the following principles:
- Each major data category has a disclosed purpose and a retention period or retention criterion.
- Direct identifiers, precise location, photos, verification data, and report evidence are not retained longer than reasonably necessary for their disclosed purpose, subject to specific safety/legal rules.
- Production account data is separated from restricted analytics/research data.
- Identity-severed or pseudonymous research data is not described as anonymous.
- For a standard account, the production-to-research mapping is destroyed at hard deletion.
- No deterministic derivative of the production user identifier survives as a research join key.
- Independent sanction-registry and repeated-abuse phone/device HMACs, and the vested-referral marker, are enforcement/anti-abuse records, not research join keys, and survive only for their own applicable lifetime.
- Legal-preservation holds are narrow and documented rather than indefinite general retention.
- Critical deletion operations use receipts/failure monitoring so Last does not silently represent deletion as complete when it failed.
- The encrypted verification reference Last holds for photo binding follows the separate Biometric Retention and Destruction Schedule; provider-held identity-verification material follows that Schedule and the provider deletion/redaction lifecycle.
2. Retention schedule
| Data category | Typical active / operative retention | Deletion or post-account treatment |
|---|---|---|
| Website waitlist / Beta application: nonselected or waiting, with its source code and label | Until 180 days after the latest of submission, the latest affirmative consent refresh given before that deadline, and any invitation sent to it, unless the invitation is redeemed first | Hard-delete together with its source at that deadline; a narrow documented legal hold keeps it only while the hold lasts, anything overdue is deleted on release, and a signup kept past its deadline by a hold is withdrawn |
| Website waitlist / Beta application: withdrawn | Up to 30 days after a verified Remove Me/withdrawal request | Delete within 30 days unless a narrow legal hold applies; the unredeemed invitation is revoked at once, and the signup is never invited, linked, or counted again |
| Selected waitlist / Beta application | Until 180 days after the latest of submission, the latest affirmative consent refresh, and any invitation sent to it; once the invitation is redeemed, until the earliest of the account completing registration, the account's hard deletion, or 180 days after redemption | On redemption the signup's source code and label are copied to the account, which keeps them until the account is hard-deleted under the standard account-deletion rules (Section 3); the signup is hard-deleted at the earliest trigger in the middle column, and a signup linked to an account by phone match is also hard-deleted when that account is hard-deleted |
| Website waitlist: network-address rate-limit code (a one-way code derived from the address, the UTC date and a secret value, with its time window and submission count; the address itself is never stored) | Up to about three hours after the submission | Deleted by the hourly sweep once older than two hours |
| Website waitlist: diagnostic codes (a code and a time; no address or contact detail) | 90 days | Deleted by the hourly sweep |
| Website waitlist: privacy-request records (request kind, verification reference, received and completed times; no contact detail) and the request correspondence | 24 months after the request is completed (the specific period for these requests; it governs over the general inbound-email row below) | Delete |
| Website source links: cookie in the visitor's browser (the link's code, the time it was set, a random value and a check value made by the waitlist database) | 30 days after it is set, unless the visitor deletes it sooner | Expires in the browser |
| Website source links: random value of a link cookie used by a waitlist submission (no other detail) | 31 days after the submission | Deleted by the hourly sweep |
| Website source links: network-address rate-limit code for link visits (a one-way code derived from the address, the UTC date and a secret value, with its time window and visit count; the address itself is never stored) | Up to about three hours after the visit | Deleted by the hourly sweep once older than two hours |
| Website source links: totals of visits, submissions and invitations sent, by link, stage, gender (submissions and invitations only), broad region and calendar month (no contact detail and no reference to a submission) | Indefinite | Retained as historical aggregate counts; not reduced when a submission is deleted |
| Beta Participation Agreement acceptance evidence | For the agreement term plus the applicable contract/dispute/audit need | Delete when the legal/audit purpose expires |
| Beta Feedback: production-linked raw text | While the account remains active and as needed for Beta/product analysis | Delete raw production-linked feedback at hard deletion; only an approved scrubbed/redacted/derived representation may survive under the identity-severed research rules |
| Beta Feedback: population-safe aggregates | Indefinite if population-safe and no person-level mapping remains | Retain as historical aggregate artifacts |
| Private username | While the account is active and through the 60-day recoverable deletion period | Delete at standard hard deletion, subject only to legally required audit/security records |
| Former username reservation | 3 calendar months after a username change | Release back to the namespace after the reservation period unless another valid reservation/security basis applies |
| Password verifier / credential state | While needed for authentication; replaced on password change/recovery | Destroy with the production auth account at hard deletion; raw passwords/reset secrets are not retained as application data |
| Verified phone number | While active and through the 60-day recoverable deletion period | Delete plaintext/account linkage at standard hard deletion; independent keyed phone-abuse records may survive only for the separate repeated-abuse ledger/blacklist lifetime |
| Display name and production profile | While active | Remove from ordinary peer surfaces at deletion request; delete at hard deletion |
| Legal name and exact DOB in restricted identity store | While active and through the 60-day recoverable deletion period as needed for identity, recovery, fraud, and enforcement | Delete production/account copy at hard deletion; independent sanction-registry HMACs may survive only for the sanction lifetime |
| Account-level primary identity HMAC | While active and through the 60-day pending-deletion recovery period | Destroy with production identity mapping at hard deletion; it is not retained as a research join key |
| Sanction-registry primary + fallback identity HMACs | For the life of the corresponding access-locking sanction | Expire when a finite sanction no longer applies; a permanent-sanction record may remain with the permanent sanction |
| Vested-referral marker (keyed identity HMAC under a dedicated key) | For the life of the referral program | Survives standard hard deletion; contains no plaintext identity, account ID, or research ID; deleted with a confirmed minor's account and when Last permanently ends the referral program |
| Legal acceptance record (keyed identity HMAC under a dedicated key; Terms, Privacy Policy and dispute-notice versions accepted with notice-text hashes and timestamps; arbitration opt-out status; account-creation and hard-deletion timestamps) | While the account exists (not erased by Reset Account) and 4 years after hard deletion | Survives standard hard deletion and a verified statutory deletion request (legal-claims exception) for 4 years, then deleted; pseudonymous, not anonymous; contains no name, phone, device identifier, account ID, or research ID; opt-out status updated on a verified opt-out received within the 30-day window after deletion; used only to establish or defend legal claims; never a research join key; deleted with a confirmed minor's account |
| Phone repeated-abuse strike evidence / keyed phone HMAC | Qualifying strikes inside a rolling 5-year window | Retain only as needed to enforce the rolling window and any active blacklist; no plaintext phone is required in the ledger |
| Phone blacklist | 5 years after the threshold-triggering qualifying strike; a new qualifying strike while active extends expiry to 5 years from the latest qualifying strike | Delete/expire after the applicable blacklist period unless another independent lawful basis applies |
| Device repeated-abuse strike evidence / keyed device identifier | Qualifying strikes inside a rolling 5-year window | Retain only as needed to enforce the rolling window and any active blacklist |
| Device blacklist | 5 years after the threshold-triggering qualifying strike; a new qualifying strike while active extends expiry to 5 years from the latest qualifying strike | Delete/expire after the applicable blacklist period unless another independent lawful basis applies |
| Underage access-locking sanction record | 10 calendar years under the current sanction rule | Expire at the end of the applicable sanction unless another lawful preservation basis applies |
| Permanent scam/advertising/fraud-account/bot sanction record | For the permanent sanction lifetime | Retain the minimum restricted enforcement record needed to enforce the permanent sanction |
| Stripe Identity verification references/status/timestamps | While active and through the recovery period as needed | Delete/redact provider references through the applicable provider lifecycle at hard deletion, subject to narrow preservation obligations |
| Government-ID / Stripe identity-verification images | Provider-hosted under the Stripe verification lifecycle | Last directs redaction/deletion under the applicable provider process after permitted fields are copied, subject to the Biometric Schedule and narrow preservation duties |
| Fresh recovery selfie / recovery verification material | Transient provider-hosted recovery event | Last does not create a separate recovery-selfie copy; provider material is redacted/deleted under the ordinary provider lifecycle after the authorized comparison/use |
| Full-middle-name exception birth-certificate image | Transient, only for the exception decision | Destroy/delete after the exception decision; retain only the minimum audit receipt, unless a narrow legal-preservation obligation applies |
| Encrypted first-party verification-reference image and binding receipts | While needed for active identity/photo binding, recovery, security, and audit purposes | Delete the encrypted reference and production-linked binding records at Reset Account or hard deletion under the Biometric Consent and Retention/Destruction Schedule; transient comparison embeddings/templates/landmarks/crops are not retained |
| Profile photos / photo storage objects | While active and approved; removed photos only until physical deletion completes | Delete removed/rejected objects under the photo-deletion process; delete remaining production photo objects at hard deletion |
| Precise coordinates and detailed location history | While needed for matching, access, safety, date/location processing, and location-lock rules | Delete at standard hard deletion; precise coordinates do not enter post-delete research |
| Date-purpose location | Processed only for the scheduled-date purpose from T-2h through T+30m around the authoritative scheduled start, plus only the minimum follow-on time needed to finalize attendance/safety records | Delete or reduce when that date-purpose need ends; post-delete research may retain only authorized non-precise outcome/metadata, not precise coordinates |
| Coarse market/locality/county/state/country or equivalent generalized region | While active and in applicable analytics/research | May survive standard hard deletion under a random research ID, subject to rarity/generalization controls |
| Gender, sexuality, and genders sought | While active and through the recovery period | Delete production linkage at hard deletion; approved identity-severed values may survive under a random research ID |
| Generalized age band | Derived/used while active for product/research; permitted bands are 18-20, 21-25, then five-year bands | May survive standard hard deletion under a random research ID |
| Optional structured profile/filter fields | While active | Delete production values at hard deletion; authorized values active at deletion may survive under a random research ID |
| Religion selection | While active as an optional curated profile/filter value | Delete production value at hard deletion; if included in the approved optional-structured research set, only the identity-severed value may survive under the random research ID |
| Bio | While active | Delete at standard hard deletion; bio does not survive in the research plane |
| Optional free text other than bio | While active | Delete raw original at hard deletion; only an approved scrubbed/redacted/derived representation may survive in restricted research |
| Sexual-interest / kink selections | While active until individually removed | Production values delete at hard deletion; authorized values still active at deletion may survive under a random research ID; removed values are not resurrected by later deletion |
| Ordinary private-message plaintext | Not received or retained by Last in ordinary E2EE messaging | Participant-revealed report evidence is handled separately |
| E2EE message ciphertext: ordinary active thread | While needed to provide messaging | Governed by the severance rules below and hard deletion |
| Universal post-severance archive presentation | Exactly 14 calendar days from the authoritative severance timestamp, subject to the viewer's own account-access state | The generic read-only archive disappears at day 14 for every severance cause; this UI deadline is not itself a promise that all ciphertext is destroyed at that instant |
| Ordinary unmatch / system-unmatch ciphertext without report/block deletion trigger | May remain after the 14-day UI archive to support a later lawful rematch, where applicable retention and device-key rules still permit | Delete on a later applicable ciphertext-deletion trigger or account hard deletion; no promise that prior history remains recoverable |
| Active-block thread without report | While needed for the 14-day locked archive and until the block has remained active for 14 consecutive report-free days, subject to any live/paused filing right | Delete ciphertext after the applicable 14-consecutive-report-free-day condition; unblock before execution cancels that scheduled deletion; unblock after deletion cannot restore history |
| Report-triggered thread ciphertext | Through the uniform 14-day archive/report opportunity and any still-live/paused filing right | Delete original report-thread ciphertext after the applicable report/archive/filing-right need ends, unless another independent legal hold applies |
| Report evidence selected by a participant | Through moderation review, appeal, dispute/safety handling, and any narrow legal-preservation period | Delete when the applicable review/legal purpose ends |
| Narrow former-participant filing-right ciphertext after hard deletion | Only when Last itself paused a former participant's still-live filing window | Retain only the minimum E2EE ciphertext + non-content routing metadata for the remaining resumed filing interval; delete when that right/evidence-processing need ends; deleted account mapping/keys do not survive |
| Message metadata: participants/relationship identifiers, timing, counts, read/delivery state, ciphertext length and derived measures | While active and for applicable analytics/safety/product operation | Approved non-content metadata may survive standard hard deletion under a random research ID; production linkage is destroyed |
| iOS screenshot system events for matched profile/chat surfaces | While needed to render the system notice and support applicable safety/audit/product purposes | Delete production linkage under account/thread lifecycle; only specifically approved non-content research/event data may survive if included in the research allowlist |
| Unanswered sent Like | Up to 30 calendar days unless the recipient decides sooner | Live pair state expires under the product rule; historical interaction/expiry data may remain in approved research/analytics |
| Historical impressions, served-profile receipts, swipes, likes, passes, maybes, Super Likes, reveal events, decisions, and like-expiry events | While active and for applicable analytics | Approved event history may survive standard hard deletion under a random research ID |
| Matches / unmatches / severance lifecycle | While active and for applicable analytics | Approved lifecycle data may survive standard hard deletion under a random research ID |
| Admission / waitlist / discovery events | While needed for active operations and applicable analytics | Approved events may survive standard hard deletion under a random research ID; direct production linkage is destroyed |
| Participation/conduct / visibility events and internal decision-support logs | While needed for active enforcement, audit, safety, and model/product evaluation | Production linkage is deleted at hard deletion except independent sanction records; only expressly approved identity-severed research fields may survive |
| Push tokens | While active and needed for delivery | Revoke at deletion request and delete at hard deletion |
| Trusted-device / session state | While needed for authentication/security | Revoked on recovery/ban as applicable; production state deleted at hard deletion |
| Crash / structured error / performance diagnostics | Risk-based period appropriate to troubleshooting, security, and product reliability | Delete, aggregate, or identity-sever after the purpose expires |
| Support tickets / appeals / feedback | While needed to respond, adjudicate, audit, or analyze the issue | Delete direct identifiers when no longer needed; approved redacted/derived research fields may survive if separately authorized |
| Ordinary Delete Account structured exit reason | From deletion request through the recovery lifecycle; distinguish requested deletion from recovered request and completed hard deletion | For a standard account that hard-deletes, the structured reason may survive under the random research ID as a Delete-event/outcome label; survey-exempt deletions retain a distinct exempt code rather than an imputed reason |
| Delete Account free-text explanation | During the pending/recovery lifecycle as needed for product analysis | Raw text deletes at hard deletion; only an approved scrubbed/redacted/derived representation may survive in restricted research |
| Pair-level Last-match relationship outcome | Where a user selects that they are staying with the person they matched with in Last | May be represented as a restricted pair-level outcome label associated with the applicable match research record after identity severance; raw explanation text is not shared |
| Premium contract-copy email and cancellation binding record | While needed for contract delivery, cancellation/refund, audit, and legally required recordkeeping | Delete or minimize when the legal/accounting/dispute purpose expires; cancellation token is restricted and not a peer/research identifier |
| Premium cancellation email receipt and refund job records | Through cancellation/refund completion plus applicable legal, accounting, dispute, and audit periods | Retain the minimum receipt needed to prove timeliness, processing, refund/revocation outcome, and any exception handling |
| Inbound support/privacy/DMCA/legal email text and routing records | Through the lifecycle of the underlying request/case plus any applicable legal, security, dispute, or audit need | Delete or minimize when that purpose expires; attachments follow their own data-class rules and are not sent to the AI model |
| Automated email classification/reply logs | Through the associated support/process lifecycle plus the minimum security/audit period needed to prove routing and exactly-once handling | Delete or minimize when the operational/audit purpose expires; no independent research retention is created by the log |
| Website support-chat logs (time, question text, reply length, one-way code derived from the network address and a secret value; no name, account or contact field other than what the visitor typed) | About 90 days | Entries older than 90 days are removed each day |
| Automatic-renewal express-consent evidence | At least 3 years or 1 year after the subscription terminates, whichever is longer, or longer if law requires | Delete after the applicable legal/audit period expires |
| Annual automatic-renewal and California service-provider notice logs | Through the period reasonably necessary to prove required notice delivery | Delete after the legal/audit purpose expires |
| Purchase / entitlement / transaction records | While active plus app-store, tax, accounting, fraud, chargeback, and legal requirements | Delete provider/account identifiers at hard deletion except records legally required to be retained |
| Auto-renewal acknowledgment/contract-copy evidence | For the period required by applicable law/platform policy | Delete when the applicable legal, dispute, audit, and accounting purpose expires |
| Security / access / credential-change audit events | Risk-based period appropriate to the security purpose | Delete or aggregate after the security purpose expires unless an incident/legal hold applies; former username reservation itself lasts 3 months |
| Population aggregates / published historical metrics | Indefinite if independently aggregated and not mapped back to a person | Retain as versioned historical artifacts |
3. Standard account deletion
Day 0: deletion request
For an ordinary standard account, requesting Delete Account begins the 60-day recoverable deletion lifecycle:
- the profile is removed from ordinary peer/member-facing surfaces;
- active matches are severed and queue/pair state is updated under the ordinary product rules;
- the same cause-neutral 14-day locked archive/report opportunity applies to former counterparts;
- push tokens are revoked;
- ordinary sessions are terminated or restricted as required by the applicable deletion flow;
- applicable subscription-cancellation processing is initiated or the user is directed to the applicable app-store cancellation path; and
- the Service displays the scheduled permanent-deletion date.
Deleting the app or logging out does not start account deletion.
Days 0-60: recovery period
During the recovery period:
- the account is not available for ordinary dating use;
- the account-level primary identity HMAC remains solely as part of the recoverable production identity state;
- recovery requires the current applicable recovery process, including a fresh Stripe Identity verification on every recovery;
- automated recovery requires any two of private username, current password, and registered-phone possession, plus the fresh verified-identity match;
- one-or-zero-factor recovery requires the fresh verification plus the authorized human comparison against the existing verified photo/selfie set;
- successful recovery cancels the pending deletion; and
- prior E2EE plaintext on a new device remains dependent on the required retained/restored device key or applicable backup.
A statutory privacy request may follow a different legal deadline or scope. Applicable law controls.
Day 60: hard deletion
At standard hard deletion, Last permanently removes the production account and direct linkage to the categories listed in the Privacy Policy, including the production auth/account mapping, identifiers, profile, photos, precise location, production verification references, provider/account identifiers subject to legal-record exceptions, device/push state, Last-held account encryption material, ordinary production relationship surfaces, raw optional free text, and the production-to-research mapping.
The production account cannot be restored after hard deletion.
4. Standard Partial Delete / Identity-Severed Retention
Ordinary standard accounts use Partial Delete / Identity-Severed Retention at hard deletion.
After destroying the production-to-research mapping, Last may retain only the approved research categories under an independently generated cryptographically random research-only identifier. The current allowlist includes:
- gender code;
- sexuality / genders sought;
- generalized age band;
- coarse region subject to rarity controls;
- sexual-interest/kink selections active and authorized at deletion;
- authorized structured profile/filter values active at deletion;
- scrubbed/redacted/derived optional free-text representations other than bio;
- profile impressions/position and served-surface receipts;
- swipes, likes, passes, maybes where applicable, Super Likes, reveal events, decisions, and like-expiry history;
- match/unmatch/severance lifecycle;
- non-content message counts/timing and response/match-duration metadata;
- approved block/report category and outcome information;
- admission, waitlist, discovery, Reset, and Delete events; and
- approved quality, safety, participation, and outcome labels.
The retained research row does not contain the deleted person's production account identifier, name, contact information, exact DOB, ordinary production-linked exact age, precise coordinates, photos, bio, biometric template, verification images, ordinary message plaintext/ciphertext, or a deterministic production-derived join key.
The retained row is not represented as anonymous. Access is restricted and audited. Rare combinations may be generalized, bucketed, suppressed, or excluded from applicable exports/training datasets as needed.
Under the current product rule, approved identity-severed research records and independently accumulated population aggregates do not have an automatic expiration unless applicable law or a later adopted policy requires one.
5. Reset Account is not deletion
Reset Account is a product-state reset, not a privacy erasure request and not a substitute for Delete Account.
Reset may clear current profile/discovery/match product state while preserving information needed for authentication, verified identity/duplicate prevention, subscription entitlements, active sanctions, blocks/reports/evidence, security/audit records, historical analytics, and encrypted thread history under the applicable retention rules.
Reset is blocked while a governing suspension or ban is active. Delete Account remains available through the restricted account-management surface.
6. Reporting, severance, and E2EE retention summary
The 14-day post-severance rule is a presentation/report-filing window, not a blanket 14-day ciphertext-destruction promise.
- Every severance of an existing match/thread uses the same 14-day cause-neutral locked/read-only archive presentation.
- Either former participant with an unused report right may use the applicable report-evidence flow during the filing window.
- If Last itself prevents access to the report flow, that participant's filing time pauses and later resumes from the unused remainder; the generic archive does not reopen after its normal day-14 boundary.
- Ordinary-unmatch ciphertext may remain after day 14 for possible lawful rematch while the published encrypted-thread retention rule remains active.
- An active block without report uses the 14-consecutive-report-free-day ciphertext-deletion rule while the block remains active, subject to a live/paused filing right.
- Report-triggered original ciphertext is ultimately deleted after the report/archive/filing-right process, while selected report evidence is separately retained only for the moderation/appeal/legal purpose.
- Hard deletion normally deletes ordinary thread ciphertext, subject only to the narrow former-participant filing-right exception described above.
7. Provider and biometric deletion
Last does not use this Policy as a substitute for the separate Biometric Retention and Destruction Schedule.
8. Legal preservation and privacy-rights requests
A narrow documented legal-preservation hold may delay deletion only for information reasonably necessary for the protected legal, safety, security, moderation, or dispute purpose.
An in-app Delete Account request and a statutory privacy-rights request are not necessarily the same process. Where applicable law requires a different response deadline, deletion scope, restriction, or exception, the legal requirement controls. Last does not use the 60-day product recovery window to delay a verified statutory request beyond an applicable legal deadline.
9. Changes to this Policy
Last may update this Policy when product behavior, providers, legal obligations, or retention practices change. The version and effective date above identify the applicable publication. Before Last publishes a material change, it reconciles that change with the Privacy Policy, Terms of Use, Biometric Schedule, Website Waitlist Privacy Notice, Premium documents, and its deletion and retention controls.