
Close the account, withdraw the balance, wait out the cooling-off window
Account deletion on khelo bet24 is self-serve and final. The wallet must be at ₹0 before closure; the cooling-off window (default seven days) lets the reader cancel; after the window, the data deletion follows the published retention policy. The route names the steps in the order the wallet screen presents them, and points to /privacy/ for the retention policy.
Five steps from request to confirmation
Open settings
Inside the lobby, tap Settings → Account → Delete account.
Wallet at zero
The wallet must be at ₹0. Withdraw any cash balance or wait for active bets to settle.
Request closure
Tap Request closure; an OTP confirms the request.
Cooling-off window
The cooling-off window lets you cancel the request. The default is 7 days.
Final confirmation
After the cooling-off window, the account closes; data deletion follows the published retention policy.
What the route asks the reader to clean before closure
The cookies panel on /cookies/ is the editorial reference for the cookies the lobby writes during the session.
The cookies panel on /cookies/ documents the cookies the lobby writes during the session. The closure request does not clear the cookies on the reader's browser; the reader clears them locally if desired.
The data deletion follows the published retention policy on /privacy/. The retention policy is what the route asserts when the data leaves the live systems.
What is deleted and what is retained
| Data class | Treatment | Notes |
|---|---|---|
| Account profile | Deleted at closure | Mobile, KYC identity, address |
| KYC documents | Deleted at closure | Aadhaar/PAN, bank statement, selfie |
| Transaction history | Anonymised after retention | Aggregated for AML |
| AML records | Retained for the statutory period | See /privacy/ |
| Aggregated analytics | Retained, no PII | No personally identifiable data |
| Backups | Rotated on the standard schedule | Removed at rotation end |
The privacy surface the reader interacts with
The privacy card on the wallet screen exposes the responsible-play, marketing and cookie toggles the route references.
The privacy card on the wallet screen exposes three toggles: marketing consent (revoked on deletion), responsible-play settings (carried over to the exclusion period), and the cookie preferences (cleared locally by the reader).
The route asserts the toggles exist and links to /cookies/, /privacy/ and /responsible-play/ for the substantive policy text.
The cases where the inbox form comes before the self-serve path
Three cases route to the support inbox form on /contact/ before the self-serve closure path:
- The wallet holds a non-zero balance the reader cannot withdraw (a pending withdrawal, a settled bet awaiting payout, a Daily Race credit).
- An active bet has not yet settled and the reader wants the bet to ride out.
- The mobile number on file is no longer reachable and the OTP step cannot run.
In all three, the inbox form is the documented formal channel. The self-serve closure path is blocked until the case is closed.
The cooling-off and retention windows
Routes that answer the next question
Privacy
The retention policy the deletion follows.
Cookies
The cookies the lobby writes during the session.
Responsible play
Self-exclusion as an alternative to deletion.
Contact
The support inbox form for closure blockers.
Five deletion questions before the first tap
Can I delete the account with a non-zero wallet?
How long is the cooling-off window?
Is the deletion reversible?
What is retained after deletion?
Can I self-exclude instead?
How the seven-day window behaves
The cooling-off window is the safety valve between the closure request and the final confirmation. The default is seven days; the reader can shorten or extend it from 24 hours to 30 days.
Request
The reader taps Request closure; an OTP confirms the request.
Window opens
The seven-day window starts. The reader can cancel from the same screen.
Reminder
An SMS and an in-app notification fire at 24 hours and 1 hour before closure.
Cancellation
The reader can cancel the request at any point during the window. The cancellation re-opens the account.
Closure
At window end, the account closes and the data deletion follows the published retention policy.
When to take a cooldown instead of deleting
Self-exclusion and deletion solve different problems. Self-exclusion is reversible at the end of the stated period; deletion is final after the cooling-off window.
| Path | Reversible | Data deleted | When to use |
|---|---|---|---|
| Self-exclusion | Yes, at end of period | No | Temporary break (6 months to 5 years) |
| Cooldown | Yes, at end of window | No | Short break (24h to 6 weeks) |
| Deletion | No, after cooling-off | Per retention policy | Permanent exit |
Three data classes, three retention rules
The data deletion on khelo bet24 follows the published retention policy on /privacy/. The policy covers three data classes, each with a different retention rule. The classes are described below in the order the privacy policy presents them.
Account profile and KYC documents. Deleted at closure. The deletion removes the mobile number, the KYC identity (Aadhaar or PAN), the address, the bank match document and the live selfie. The deletion is final after the cooling-off window; the data does not return to the live systems.
Anti-money-laundering records. Retained for the statutory period. AML records are aggregated transaction records the operator is required to retain under anti-money-laundering regulation. The records are retained in anonymised form; the KYC identity is removed but the transaction patterns are kept.
Aggregated analytics. Retained with no personally identifiable data. Aggregated analytics are the read-only counters the operator uses to monitor the lobby. The counters do not carry PII; they are retained indefinitely.
Backups. Rotated on the standard schedule. The operator's backup rotation is a separate lifecycle from the live systems. Data is removed at the end of the rotation cycle, not at the moment of the closure request.
| Data class | Treatment | When |
|---|---|---|
| Account profile | Deleted at closure | After cooling-off window |
| KYC documents | Deleted at closure | After cooling-off window |
| AML records | Retained for statutory period | Anonymised |
| Aggregated analytics | Retained indefinitely | No PII |
| Backups | Rotated on schedule | Removed at rotation end |
The retention policy is the substantive answer to the question "what is deleted and what is retained". The deletion route points to /privacy/ for the full text; the route itself states the three classes and the three rules in short form.
The safety valve between request and final closure
The cooling-off window exists to prevent reactive closure. A reader who taps Request closure in the heat of a bad session is not in a state to make a permanent decision about the account. The cooling-off window gives the reader seven days (default) to cancel the request and return to the lobby.
The cooling-off window is configurable from 24 hours to 30 days. The default is seven days because seven days is long enough to break the reactive state but short enough that the reader does not feel trapped. The reminder fires at 24 hours and 1 hour before closure, by SMS and in-app notification.
The cooling-off window is the safety valve. The deletion path is final after the window closes. The reader can cancel the request at any point during the window; the cancellation re-opens the account with the same KYC and the same balance.
The cooling-off window is the difference between deletion and reactive deletion. The window is the editorial reference's commitment to the reader that the deletion is not impulsive. The reminder cadence is the commitment that the reader is not surprised by the closure.
Which lever fits which situation
Self-exclusion and deletion solve different problems. Self-exclusion is reversible at the end of the stated period; deletion is final after the cooling-off window. The right lever depends on what the reader wants the post-decision state to be.
Pick self-exclusion when the reader wants a longer break (six months to five years) but expects to return to the lobby at the end of the period. Self-exclusion locks the account for the period, revokes marketing consent for the same period, and requires a fresh KYC and a 24-hour reflection window at re-entry. The lockout is reversible at the end of the period; the data is not deleted.
Pick cooldown when the reader wants a short break (24 hours to six weeks) and expects to return to the lobby at the end of the window. The login page accepts credentials but the lobby remains locked. The wallet is read-only and withdrawal remains available.
Pick deletion when the reader wants to exit the lobby permanently. The closure request opens a seven-day cooling-off window (default). After the window, the account closes and the data deletion follows the published retention policy on /privacy/. Anti-money-laundering records are retained for the statutory period; aggregated analytics are retained with no PII. The deletion is final.
| Lever | Reversible | Data deleted | When to use |
|---|---|---|---|
| Cooldown | Yes (window end) | No | Short break (24h to 6 weeks) |
| Self-exclusion | Yes (period end) | No | Longer break (6 months to 5 years) |
| Deletion | No (after cooling-off) | Per retention policy | Permanent exit |
The three levers are not interchangeable. A reader who picks deletion when they wanted a break will not be able to return to the lobby at the end of the cooling-off window. A reader who picks self-exclusion when they wanted deletion will see the account re-open at the end of the period. The right lever is the one that matches the reader's intent.
Open the lobby
The path is self-serve. The retention policy is on /privacy/. The cooling-off window lets the reader cancel before the closure becomes final.