1. Information MuktID may use
The basic journey starts with the mobile number you choose to verify. MuktID may also handle OTP-verification status, short-lived session information, search queries derived from your authorised inputs, exposure-result URLs and cleanup status.
If you voluntarily use Deep Scan, you may add name, email ID, city and organisation as matching context. Those details are intended to improve relevance and reduce false matches.
2. Why we use it
- to verify control of the mobile number;
- to perform exposure searches you request;
- to improve matching and reduce false positives;
- to organise direct routes, removal requests and Action Required items;
- to protect the service against fraud, abuse and misuse;
- to respond to support, privacy and grievance requests.
3. Email ID and optional Deep Scan context
Providing an email ID does not automatically make the email a removal target. By default, it may be used only as matching context around the verified mobile number.
If the user separately chooses to check email exposure, MuktID may include the email as an additional search target. The user should always be able to understand which data is being used as context and which data is being actively checked for exposure.
4. Service providers, security and retention
MuktID may rely on service providers for OTP delivery, public-web search, hosting, security and communications. Only information reasonably necessary for the relevant function should be shared.
The production service should use encrypted transport, server-side secrets, access controls, abuse protection, rate limiting and appropriate logging. Short-lived verification sessions should expire automatically. Persistent scan or monitoring history should be stored only when the user chooses such functionality and with clear retention controls.
5. What MuktID does not control
MuktID does not control independent websites, private databases, closed platforms or legally required public records. A source may impose its own OTP, login, CAPTCHA, verification or lawful-retention requirement.
Preparing or sending a removal request is not the same as confirmed deletion. MuktID should mark a result as removed only after reliable evidence supports that status.
6. Your privacy choices
Users should be able to request access, correction or deletion of information controlled by MuktID, subject to applicable operational and legal requirements. A request concerning information controlled by another website may need to be handled through that website's own process.
7. Raising a grievance
You may raise a grievance about MuktID's privacy handling, incorrect workflow status, suspected misuse, security concerns, a cleanup action that appears wrong, or a request relating to information controlled by MuktID.
Provide only the information reasonably necessary to identify the issue. Do not send passwords, banking credentials, third-party OTPs or unnecessary identity documents.
8. Support and AI-assisted help
MuktID will publish its official support email and support channels before public launch. An AI-assisted support layer may later help explain exposures, summarise source requirements, prepare removal requests and triage support issues.