Account lock, the platform-side brake.

Most locks release on resubmission of KYC documents or a call to customer care. The platform’s customer-care page has the contact details; the documents are the reader’s KYC files.

A 7-day rule

Most platforms resolve account locks within 7 days. The lock is not permanent; it is precautionary and resolves with the right action.

A escalation path

If the lock does not release within 7 days, escalate to the platform’s regulator (MeitY, PROG Act 2025, or the relevant state regulator). The regulator’s contact details are on the platform’s responsible-play page.

The lock is rare; the discipline is to avoid the conditions that trigger it.

Stable login location

Avoid logging in from widely varying IPs within a short window. The platform reads this as account takeover.

Stable withdrawal recipient

Withdraw to the same bank account and UPI ID as the KYC documents. Name mismatches trigger locks.

The platform's risk system reviews every login, every deposit and every withdrawal against a short list of signals. Most locks are triggered by one of four signals; the desk walks through each so a reader can recognise the lock before it happens.

KYC mismatch is the most common trigger. A reader whose PAN card does not match the KYC name, or whose bank account name does not match the PAN card, will hit a lock on the first withdrawal above the KYC threshold. The fix is to update the KYC documents; the lock releases within seven days of the correct resubmission.

Multi-account detection is the second most common trigger. Two accounts on the same device, with the same UPI handle, or with overlapping bank accounts will trigger a lock on the second account. The platform's terms typically prohibit multi-account play; the lock is precautionary until the reader can demonstrate the second account is legitimate.

Suspicious withdrawal patterns are the third most common trigger. A reader who deposits small amounts and immediately requests a large withdrawal will trigger a lock. The platform's risk system reads the pattern as a stolen-card or mule scenario; the fix is to submit a written explanation to customer care.

Long dormancy followed by a sudden large deposit is the fourth most common trigger. The platform reads the pattern as account takeover. The fix is to verify the registered email and phone, and to submit a recent address proof.

The desk's advice for a reader who has been locked is to send a structured customer-care note. A structured note is faster to process and reduces the back-and-forth that delays resolution.

Open the note with the registered email, the registered phone number, and the lock reference from the banner or the registration email. State the date the lock was noticed. Attach the most recent KYC documents: PAN card, address proof, and a cancelled cheque or first page of the bank statement.

State the action the reader has taken since the lock was noticed. If the reader has updated the KYC, state the timestamp of the update. If the reader has not yet updated, state the intended update. The platform's customer-care team reads the action items and ticks them off; the lock releases as each item resolves.

What not to send

Do not send a long complaint, a screenshot of the lock banner, or a request for compensation. Customer-care escalations of this kind take longer to resolve. The desk's recommendation is to send the structured note, wait for the customer-care ticket number, and follow up with the ticket number at seven-day intervals.

When to escalate

Escalate to the platform's regulator (MeitY, PROG Act 2025, or the state regulator) if the lock does not release within seven days after the customer-care ticket has been acknowledged with the right documents. The regulator's contact details are on the platform's responsible-play page. The desk does not handle escalations directly; the desk publishes this note for the reader's reference.

Login from a stable location. Logging in from widely varying IPs inside a short window is read by the platform's risk system as account takeover. A reader who travels can declare the travel to customer care before the trip and avoid the lock.

Withdraw to the same bank account and UPI handle that the KYC documents name. A name mismatch on the destination account is the most common cause of a lock at the first large withdrawal. The fix is to update the KYC documents before requesting a large withdrawal.

Verify the registered email and phone after every password change. A reader whose registered email has changed without a verification step will hit a lock on the next withdrawal. The fix is to verify both the email and the phone through the platform's account settings page.

Avoid multi-account play. Two accounts on the same device, the same UPI handle, or the same bank account will trigger a lock on the second account. The fix is to play from a single account.

Match deposit and withdrawal patterns. A reader who deposits small and requests a large withdrawal will trigger the risk system's pattern detector. The fix is to keep the deposit and withdrawal amounts within a sensible ratio.

Read the platform's KYC threshold before requesting a large withdrawal. The threshold is published on the platform's KYC page; the desk does not paraphrase the number because the number changes.

Document every customer-care interaction. A reader who keeps a record of the ticket number, the date and the resolution will resolve a future lock faster. The desk recommends a simple spreadsheet: ticket number, date, summary, status.

A locked account does not delete the reader's balance. The platform holds the balance until the lock releases; the reader's chips and the reader's deposit history are preserved. A reader who logs in on a locked account sees the banner, the email confirmation, and the path to customer care. The reader cannot withdraw or play; the reader can read the banner and follow the documented steps.

Reading the banner

The banner names the reason for the lock. Common reasons are KYC mismatch, multi-account detection, suspicious withdrawal pattern, and dormancy followed by large deposit. Each reason has a documented resolution path; the desk's advice is to read the banner carefully and to follow the path that matches the reader's situation.

Logging back in

The reader can log in to a locked account. The login does not bypass the lock; the lock remains until the resolution path completes. The reader's task is to complete the resolution path, not to find a way around the lock.

Account recovery after a long lock

A reader who has not logged in for a long period may see a lock on the next login, even without any of the triggers listed above. The lock is precautionary: the platform reads a long dormancy as a candidate for account takeover. The fix is to verify the registered email and phone, and to submit a recent address proof. The lock typically releases within seven days of the resubmission.

The platform records every lock event with a timestamp and a reason code. The reason code is the platform's internal classification; it maps to the four triggers listed earlier in this article. A reader who has been locked can request the reason code from customer care; the platform will share the reason code without sharing the internal rule logic. The reason code is enough for the reader to know which resolution path applies.

The audit trail also records the customer-care ticket number, the documents submitted, the timestamp of each submission and the timestamp of the lock release. The trail is preserved for the platform's regulator (MeitY, PROG Act 2025, or the state regulator). The reader can request a copy of the trail through a customer-care ticket; the platform's compliance team will share the trail with the reader.

How long the trail is preserved

The trail is preserved for the duration required by the regulator. Indian platforms typically preserve the trail for five to seven years. The reader's access to the trail is governed by the platform's data-retention policy and the regulator's rules.

What the trail does not contain

The trail does not contain the platform's internal risk model, the platform's threshold values, or any other reader's lock data. The desk's view is that the trail is sufficient for the reader's purposes; the platform's internal risk model is the platform's intellectual property.