Privacy, plainly.

Voice and video calls use WebRTC after a mutual connection, verification, a separate invitation and acceptance. Camera and microphone media is transmitted between the participants through the configured relay path when needed; Sarkari Matrimony does not record or store call audio or video. The application retains only bounded consent, status, timing, duration and temporary signaling records needed to operate and secure the call.

The in-app Notification Centre stores grouped event metadata for mutual matches, messages, photo-permission changes, verification and payment-review updates, and voice or video invitations. It does not duplicate message bodies. Generic push payloads contain no member name, message text, review decision, payment detail or profile detail. Delivery uses a bounded retry queue and per-account limits so a temporary provider failure does not silently lose an update or create a notification flood.

Sarkari Matrimony is an independent matrimonial platform. It is not a Government of India, state government, public-sector or departmental website.

This service is not offered to account holders under 18 and does not permit profiles for children. The account holder's private 18+ attestation is recorded separately from a represented profile subject's age and, for a family-managed profile, that adult's permission. New profiles require a self-declared age of at least 18 for a woman and at least 21 for a man. These gates are platform eligibility checks, not proof of age or legal eligibility to marry.

A credible concern may hide or pause the profile and restrict contact while a human reviews it. Specifically, a signed-in eligible member's underage report stores the relevant profile or selected-message snapshot and immediately places the reported profile in a reversible precautionary quarantine. Discovery, contact, photo permissions, Voice Connect, verification and new profile-linked payments remain unavailable while the priority human review is open. The report alone is not published, does not lower Behaviour Trust, and is not treated as guilt or an automatic ban. An audited human no-action or overturned decision may restore an otherwise eligible profile; a confirmed ineligibility keeps it hidden. Information may be deleted, preserved for a safety investigation, or disclosed to an authorised authority when appropriate and lawfully required. See the Safety centre for in-product and official reporting routes.

For a profile managed for another adult, Sarkari Matrimony records whether and when the signed-in account holder attested that the adult knows about the profile and gave permission to create and manage it, plus any later withdrawal. This is the account holder's statement, not independent verification of that adult's consent.

The account holder can withdraw the attestation from the dashboard, which immediately pauses the profile. Recording permission again and resuming the profile are separate actions.

• Account information: Google sign-in is configured to request only the openid and profile scopes, not Google's email permission. Google can return a stable account identifier and basic profile fields under those scopes. Sarkari Matrimony keeps only the stable identifier and account name in the member database and discards other returned profile fields. If Google returns an email claim or grants an unexpected scope, sign-in fails rather than accepting that response. No member mailbox is stored, returned to the admin console or used for routine or marketing messages. If you contact support yourself, the team may reply through the channel you provide.
• Optional private contact: no number is requested at sign-up or onboarding and there is no phone OTP step. A signed-in member may later save one self-entered, unverified Indian mobile number in the separate encrypted vault described below. Members must not place contact details in a profile or ordinary chat.
• Profile information: reviewed English fields and summaries created from what you choose to share, including name, age, city, height, work details, family context and preferences.
• Optional sensitive choices: religion, community or caste identity and partner preference only when the member explicitly provides them. “Any religion/community/caste” and “prefer not to say” remain valid choices. The service must not infer these facts from surname, photograph, language, location or another proxy.
• Optional accessibility context: a self-declared disability choice, broad accessibility context, practical accommodation needs and partner support preferences only when a member chooses to provide them. These are matching-only by default, never inferred from a photo, name, job, location, language or writing style, and never reduce trust or verification status.
• Kundali outlook: whether kundali matching matters to the member, when they choose to state it. This is a compatibility preference, not a claim that the platform guarantees an astrological result.
• Photos and role-based verification evidence: profile photos taken through the in-app front-camera flow; a private live selfie and identity document when you choose verification; and, only for a profile claiming current government service, one selected current work record plus an optional official public HTTPS or DigiLocker issued-document reference. A non-working profile is not asked for salary, employer or job evidence.
• Location: device location only after permission. Coordinates are rounded before database storage and other members receive an approximate distance band, not a map pin.
• Communications: interests, mutual matches, in-app messages and Voice Connect session records where those features are available.
• Optional push registration: only after the signed-in member taps to enable alerts, the service stores that device's browser push endpoint, its public subscription encryption/authentication keys, optional provider expiry and delivery-health timestamps. These values are used only to alert that device about mutual matches, incoming messages, photo-permission changes, verification or payment-review updates, and voice or video invitations; they are not used for advertising or matchmaking.
• Safety and abuse-prevention records: report and block records, an authorised snapshot of the exact reported message, narrow message-signal codes, temporary rate-limit buckets and one-way fingerprints derived from some longer messages to recognise repeated outreach. A fingerprint is not another readable copy of the message. A message stopped before sending because it requests secret credentials is not stored as a chat message; the safety event keeps minimal metadata such as the reason code and, where available, its fingerprint.
• Payments: when a manual verification fee applies, the locked amount, unique payment reference, member-entered UPI transaction reference and payment time, review status and any correction note. For optional calling plans, local order reference, purpose, INR amount, Razorpay order/payment/refund references, status and reconciliation events. Sarkari Matrimony does not store card numbers, CVV, UPI PINs or bank-login credentials.

The private selfie and identity document are used only to let an authorised human compare the profile subject with the stated identity. Government-work evidence is used only to review the current government-service claim. Members choose one relevant evidence type: service ID, recent government payslip, posting or transfer order, appointment or joining letter, current service certificate, official HRMS or department directory record, or another current government-issued work record.

A full Aadhaar number is never required; members who use Aadhaar should use a masked copy where available. An official HTTPS link or DigiLocker issued-document URI is optional, is not fetched automatically and never creates automatic approval. An uploaded file said to be from DigiLocker is not treated as equivalent to an issued document merely because of that label. In-app camera metadata records the route used, but browser capture is not cryptographic proof of the image's origin.

Information is used to create and manage profiles, apply member-selected match controls, calculate explainable compatibility, perform human verification, open chat after mutual interest, operate optional privacy features, prevent misuse and support payment reconciliation. Google's stable identifier is used for return access and its account name seeds the member name; email access is not requested.

When push is enabled, the browser or operating-system push service receives the opaque delivery endpoint and an encrypted, generic event payload. Sarkari Matrimony uses that payload only to announce the broad event class: a mutual match, message, photo-permission change, verification or payment-review update, or voice or video invitation. It does not contain a member's name, display name, message text, review decision, payment reference or detail, profile detail, private contact detail or document information. The authenticated dashboard remains the source of truth.

Trust and compatibility are separate. The Trust Passport shows human-reviewed evidence confidence separately from an account-level Behaviour Trust score. Verification Strength begins with a baseline derived from recorded human evidence findings. A reviewer cannot raise it, but may apply an auditable lower cap with a structured reason when the evidence warrants greater caution. A numeric threshold alone does not approve verification; the review must also establish an issuer/source or issuer security feature. Members see only the resulting score, label and meaning; detailed review findings and any internal cap reason remain restricted to authorised operations and audit records. Missing profile details should not be treated as negative character evidence. Religion, community or caste, disability, health, location, income and partner preferences never raise or lower Behaviour Trust.

Profile creation accepts typed English. Exact name and age are entered in separate typed steps. Residence, exact government post, department or organisation, service taxonomy and posting are resolved inside Sarkari Matrimony. Optional religion, caste/community, disability or accessibility, health, kundali, birth details and income also stay in dedicated local controls. None of these fields is included in an external profile-language request. Profile photos, verification documents, account sign-in details and member chats are never included.

The original typed conversation may remain temporarily in an unfinished private draft so the member can resume and correct it. After successful activation, that raw draft is deleted and the operational profile retains the reviewed structured meaning rather than the member's exact sentences. Completing language processing does not publish a draft: nothing from it is shown to other members until the profile owner reviews and approves the finished profile, and matching-only fields remain private after activation.

Named language processors: the short notice beside story Submit explains that submitting records the current notice version and may send only a privacy-filtered part of the non-sensitive English story to DeepSeek. The permitted context is limited to hobbies, routine, food habits, temperament, communication and family values, relationship expectations and partner qualities. The server removes or withholds all other clauses and fails closed to local processing when that limited story cannot be separated safely. DeepSeek's response is only an editable proposal; local validation and the member's review remain authoritative. A member can withdraw future profile-story processing from the controls below, after which profile drafting stays local unless they deliberately re-enable it.

Profile drafting does not offer microphone recording, browser speech recognition or server transcription. Members type and edit the English text themselves before submitting it. This does not affect the separate, invitation-based private audio and video calling feature described above.

The named processor operates under its own terms and infrastructure. Its processing location may differ from Sarkari Matrimony's server location; the service does not represent that the route is India-only. The application records the purpose, current notice version, affirmative story Submit and server time as a minimal event. The current code applies no separate automatic expiry to that event. Withdrawing prevents future sends for that purpose, but cannot recall a request already completed or shorten a processor's own retention where its terms permit retention.

Other specialized processors may support Google sign-in, secure in-app audio or video relay and payment checkout when those features are enabled. Each receives only the information needed for that feature under its own terms.

Narrow activity checks may recognise a request for money or secret credentials, pressure for a phone number or exact location, unusually high new-contact activity, or a repeated long opening. These checks run within the Sarkari Matrimony application. Private member-to-member chats are not sent to an external generative-AI provider for fraud scoring or moderation.

Behaviour Trust begins at a neutral “building history” level. Limited points may be added for account history and genuine two-way conversations. Recent blocked credential requests, repeated outreach pauses, the same safety pattern across several conversations, a threshold of independent post-match blocks, human-confirmed conduct findings and audited account restrictions can reduce it. A block from someone who never had a mutual match with the account is excluded. Signals expire from the calculation after stated windows except where an active restriction applies.

A report affects the score only after human review confirms a conduct violation. One block, pending reports and an investigation handoff do not create a numerical penalty. Reports enter a restricted queue, and only a separate human finding after evidence review becomes a confirmed-report factor. Automated pattern factors remain labelled as automated rather than human findings. The owner can see an aggregate explanation and request human reconsideration through the current route on the Contact page. If a human reconsideration overturns a finding or suspension, that linked factor stops affecting the score immediately; a served suspension remains in the stated time window.

Published profile facts and profile-visible signals can be shown to signed-in members. A member's private Match Intent—including required and preferred location, religion, community/caste, height, kundali, salary, department and lifestyle criteria—is used for ranking but is not shown to candidate profiles. Signals marked matching-only are not printed as public profile facts. Profile-photo access follows its stored visibility setting.

The real profile name is kept for the profile owner and authorised verification or safety administration. Other members see an optional member-chosen display name or a neutral member code. A display name must be different from the real name and cannot contain contact details, job or rank claims, or words that falsely suggest verification or platform authority. Only after both profiles are verified, mutually matched and each has sent at least one message may either person separately reveal their own real name to that one match. This never reveals the other person's name and never changes discovery or other conversations. The person can stop displaying it later, although information another person has already seen cannot be made unseen. Changing the real name, withdrawing profile-subject permission, pausing or restricting a profile or account, ending the match, or blocking the other member cancels the existing sharing choice; it does not return automatically later.

A signed-in member may see another profile's Behaviour Trust number, history label and up to three broad reasons. The profile owner receives a more detailed aggregate breakdown. Neither view reveals a reporter or blocker, exact private evidence, message wording or a contact list. A pending report alone is never published as a finding. Behaviour Trust describes only observed in-app conduct and is never presented as proof of character, identity or safety.

When an activity threshold is met or a human reviewer escalates a concern, a current or prospective contact may also see a limited safety prompt such as “Recently messaged 20+ profiles.” Pending reports alone do not create that prompt. The prompt does not reveal the reporting member, private report details, exact message text or a contact list, and it is not presented as a finding of fraud.

A disability self-disclosure or a shared-lived-experience preference never activates disability-based discovery by itself. Both profile owners must separately opt in to shared-lived-experience discovery; either owner can revoke that consent, and private disability status is not used as the membership test.

Verification evidence is not displayed on a member profile. It is available only through the restricted human-review workflow. Members communicate through controlled in-app chat and optional private in-app audio or video calls. Each verified match separately controls real-name and photo access; neither permission exposes the other member's choice.

Account and profile data are stored in the application database. Uploaded media is stored either on a dedicated persistent private server volume or in private S3-compatible object storage such as Cloudflare R2. Temporary or ordinary application-container paths are not accepted for production media. A browser receives media only through an authenticated Sarkari Matrimony route after the relevant access checks; the service does not expose a filesystem path, bucket URL or presigned object URL. Access controls, restricted credentials, signed-in checks and HTTPS reduce exposure. No online service can promise absolute security.

Raw verification photos and documents are available in the live service only while staged or under human review. Immediately after the final human decision they are blocked from further viewing and the service promptly deletes the live object from its primary store. The member can also delete any reviewed live file from the dashboard. Deleting reviewed files does not remove an approved verification badge; the human decision remains. After live-file deletion, only the file hash, evidence role and type, capture-route label, timestamps, structured human finding and minimal audit metadata remain for badge explanation, fraud prevention and dispute handling. Deleting evidence before a decision withdraws the pending case. Do not send documents through an ordinary email or chat channel.

An encrypted or otherwise isolated disaster-recovery copy may still contain media that was deleted from the live service for no more than 30 calendar days after live deletion. Recovery copies are not connected to the product and are unavailable to members, matches, verification reviewers and ordinary support access. They may be used only for controlled disaster recovery, expire or are securely destroyed on the documented rotation, and any deletion records must be reapplied before a recovery environment is reopened.

A push registration remains while alerts are enabled on that device. It is removed when the member turns alerts off, explicitly signs out on that device, permanently deletes the account, the browser supplies an expiry that passes, or the push provider reports that the registration is gone. Other signed-in devices keep their own registrations. Pending deliveries use bounded backoff and expire after a limited retry window. Delivery records retain only event class, delivery state, attempt count, timestamps and a short error category; provider error bodies are not stored. The server's VAPID private signing key is an environment secret and is never stored in a member row or sent to the browser.

An unfinished raw profile conversation and its import-recovery receipt are deleted after 30 days of inactivity. A member can delete the draft sooner, and successful activation removes its raw conversation. One-time account-deletion challenges expire at their displayed time; expired session rows are removed after a seven-day operational grace period; WebRTC signaling payloads are removed within three hours; temporary profile-change previews expire within 30 minutes and applied previews are removed within 24 hours. Chat deduplication fingerprints expire after 30 days, while automated chat-safety flags and events expire after 90 days. Consent decisions, human verification decisions, submitted safety reports, payment/refund records and other records needed for safety, disputes or legal obligations follow their separately stated purpose instead of these short temporary periods.

The dashboard provides a portable JSON export for the signed-in account. It contains the member's own account, profiles, private preferences and facts, media metadata, verification decisions, billing records, relationship history, sent message text, interest and match history, photo requests, Voice Connect history, push-device registration metadata, blocks created by the member, reports submitted by the member and relevant safety-event metadata. Push delivery endpoints and subscription keys, incoming message bodies, other profiles' private fields, reports made by someone else, reporter identities, blocks created by someone else, raw evidence snapshots, WebRTC signaling payloads, raw photo and evidence binaries, storage keys, session tokens, authentication subjects and security fingerprints are excluded.

A signed-in member can start permanent account deletion from Privacy Controls. The service issues a short-lived confirmation challenge and requires the displayed phrase exactly. On confirmation, every session is revoked, push registrations are deleted, profiles disappear from discovery, matches and chat access are severed, private drafts and structured matching data are erased, and deletion of live profile photos plus verification evidence begins in the primary store. A durable queue retries a failed primary-store deletion with bounded backoff. The service shows deletion as complete only after that queue is empty; until then it says that secure file cleanup is still in progress. This cannot be undone through the product. Isolated disaster-recovery copies follow the maximum 30-calendar-day rotation described above and cannot be browsed or restored for ordinary product use.

The account identity is pseudonymised instead of being kept as a usable sign-in. Minimal payment and refund records may remain while required for accounting, reconciliation, disputes, chargebacks or applicable legal obligations. A narrow one-way identity fingerprint, human-confirmed fraud reason and erasure audit may remain where needed to prevent a permanently banned identity from simply re-registering. These exceptions do not retain raw profile photos, verification evidence files, Match Intent, private facts, chat access or a readable authentication identifier in the live product. Retained records are not used for matchmaking or marketing and should be deleted when the applicable need ends.

• Choose, change or clear a private display name that is different from the real profile name used for verification.
• After a verified two-way conversation, reveal your own real name to that one match, or stop displaying it later.
• Turn push alerts on for a device only after an explicit tap, or turn them off again from the dashboard.
• Withdraw future limited profile-story processing.
• Skip optional community and accessibility information or choose “prefer not to say.”
• Review and remove private matching signals before activation.
• Edit or discard typed profile text before submitting it for structuring.
• Delete an unfinished private draft and its saved conversation.
• Decline location permission and continue with city-level matching.
• Use the service without providing a phone number or WhatsApp. If the optional post-onboarding vault is enabled, save or delete one self-entered number and separately grant or revoke access for each eligible match.
• Pause a profile or delete uploaded profile photos through available account controls.
• Delete staged verification evidence to withdraw the case, or permanently delete reviewed evidence without losing the recorded badge.
• Download a portable copy of the signed-in account from dashboard Privacy Controls.
• Permanently delete the account from dashboard Privacy Controls after a short-lived explicit confirmation.
• Request correction or further privacy help through the current support route listed on the Contact page.

Some minimal records may need to be retained for security, payment reconciliation, fraud prevention or legal obligations as described above.

No number is requested during sign-up, onboarding or matching, and there is no phone OTP step. A signed-in adult member may later save one self-entered Indian mobile number. The separate vault stores AES-256-GCM authenticated ciphertext, a random IV, authentication tag, non-secret key-version marker, country code, last four digits, self-entered status and timestamps. The dedicated encryption key stays in server configuration and is not reused for sessions, backups, payments or AI. If the feature or key is unavailable, saving, decrypting and sharing fail closed.

The number is excluded from public profiles, discovery, matching, AI requests, push alerts and ordinary chat. The owner normally sees only a masked value. After a real mutual match, verification of both profiles and at least one in-app message from each person, the owner may explicitly grant that one match access. Each direction is separate and recorded with grant and revocation timestamps. Replacing or deleting the number revokes every active grant; account, profile, match or block changes make access unavailable and permissions do not return automatically. Revocation cannot make a number already seen by another person unseen. A portable owner export includes the saved number and the owner's grant history; permanent account deletion removes the vault and sharing records.

Sarkari Matrimony uses first-party cookies for private draft recovery, sign-in security and authenticated sessions. These are functional cookies, not advertising trackers.

Last updated: 29 August 2026. Material changes will be dated on this page. Important changes affecting existing members should also be communicated inside the service.