Reference

Legal terms for your account

This page sets out how access, account data, cookies, and request handling work on sattak.

IndiaLocal lawAccount dataCookie settings
sattak Legal terms for your account
REQUEST CHANNELS

Ways to send legal requests

Use one of the paths below when you need access help, a correction, or a closure request.

Dashboard form Send the request from the form inside your account.
Email desk If you prefer email, write from your registered address so we can verify identity…
Live thread For an active account issue, start the same request in chat so every reply…
DATA AND ACCESS

How we handle data and access

We handle legal data here is narrow: we collect what is needed to run your account, keep sessions active, answer requests, and meet retention duties that apply in your region.

Data purpose

We keep account details, request logs, and transaction traces only for the legal purpose they serve. Once that purpose ends, we reduce or remove what we no longer need, unless a rule asks us to retain it longer for audit or dispute handling.

Cookie use

Cookies remember your session, language choice, and form state. They also help us see whether a request was sent twice or a login came from a new device, so we can handle the account safely and cut down on duplicate steps.

Access checks

Before we make any change, we confirm the account holder through registered contact details or a fresh verification step. That stops someone else from asking for a change on your behalf without permission, even if they know part of the account details.

Retention window

We keep some logs for audit, tax, dispute handling, and anti-abuse purposes when the law requires it. Other data is held only as long as the active account needs it, then removed or reduced once the retention duty ends.

Change requests

You can ask for correction, deletion, or access through support. We check the request against the account trail, then act or refuse only when a legal reason requires us to keep the record or keep part of it for a longer period.

Escalation path

If you think a request was handled wrongly, ask for escalation in the same thread. We keep the previous replies with the case so the next agent can pick it up without losing context, and you do not have to restart.

Questions on rights and access

These answers explain how access works, what data we keep, and how you can ask for changes. We keep the process tied to your account so the right person can act on it, and we only follow through where local law permits. If your request needs more detail, our support thread keeps the conversation in one place.

Access depends on local law. If the law permits use in your region, you can proceed; if it does not, we do not open the account flow for that location or ask you to bypass the rule.

We keep the account details, login logs, cookies linked to your session, and request history needed to run the account and meet retention duties. We keep only what has a clear legal purpose and remove the rest when that purpose ends.

Send the request from your dashboard or registered email address, explain what needs changing, and attach any proof you have. We match it to your profile before making a change and reply with the result in writing.

When a permitted transaction appears in your account, we may store the route used, such as UPI, Paytm, PhonePe, or Google Pay, plus time stamps and status, so the record stays complete and easy to trace later.

We keep some records only while your account needs them, and other records longer when tax, audit, dispute, or legal retention duties require it. When the duty ends, we trim what we can and reduce what must stay.

Only the verified account holder, or someone legally authorised to act for you, can ask for access, correction, or closure. We confirm identity before we carry out the request, and we do not take action on a doubtful request.

Use the support form, email desk, or live thread from your account. That keeps the request tied to the right profile and helps us respond with one clear case trail, one reply path, and one stored outcome.