Consent framework

This page describes exactly how consent works on VerifyBG, in enough detail that a compliance reviewer can check our claims rather than take them on trust.

The rule

No personal data about a subject is retrieved from any source until that subject has signed a consent record. This is enforced server-side on every processing request. A request that has no consent record attached is refused with an error, regardless of what the browser sends.

What the subject is shown before signing

• Their own name, as entered by the requester.
• Who is requesting the check.
• The stated purpose, if the requester gave one.
• An itemised list of every category of check that will run.
• That refusing means no check runs and no data is collected.
• That data is deleted automatically after 30 days.
• That name-based matching can produce false matches, and that they can withdraw consent or raise a concern later from /my-data.
• Which checks are a format test rather than a registry lookup, and which sources are not connected and so will not be looked up.

What is recorded when they sign

The full legal name they type, the exact timestamp, their IP address, their browser user agent, and the version of the consent text they were shown. The consent text version is stored so that we can always reconstruct precisely what a given person agreed to, even after the wording changes later.

Signature strength, stated honestly

Consent can be captured in three ways, and every record permanently states which one was used. They are never presented as equivalent.

• DigiLocker. Where it is connected, the subject can sign in with MeriPehchaan, the government identity service, and authorise the release of their details from their own DigiLocker. The name on the record is issued rather than typed, and it is then compared with the details the requester supplied. Offered as a choice, and required only where the requester has asked for it.
• Email one-time code verified. The subject types their full legal name, confirms explicitly, and enters a six-digit code sent to the email address the requester recorded. This proves control of that address. The code is generated with a cryptographic random source, stored only as a SHA-256 hash, expires in ten minutes, and locks after five incorrect attempts. This is the default whenever an email address is available.
• Typed signature. Name plus explicit confirmation, bound to a timestamp, IP address and device type, with no independent identity check. Offered only when no email address is available or the subject cannot access it, and clearly labelled as the weaker form everywhere it appears.

Neither is an Aadhaar-authenticated eSign, and we do not describe either as one anywhere in this product. Aadhaar eSign integration is planned. Because strength is recorded per signature rather than assumed platform-wide, adding it later will not retroactively upgrade or obscure how any earlier consent was actually obtained.

Independently verifiable

Every consent produces a Certificate of Consent carrying a permanent reference and a QR code. Anyone holding it can confirm it is genuine at verifybg.in/verify/[reference], with no account and no relationship with us. A machine-readable endpoint at /api/verify/[reference] returns the same answer and, importantly, a real HTTP 404 for a reference that was never issued, so an automated check cannot be fooled by a fabricated certificate.

Verification deliberately discloses the consent and its scope, never the findings of any check. Proving that consent lawfully exists and revealing what a background check returned are different acts, and only the first is safe to expose to whoever holds a reference.

Consent records remain verifiable after the underlying personal data is deleted at the end of the retention window. The record then confirms that consent existed and what it covered, without continuing to assert who it was about.

Separation of links

What is recorded as signer context: the name typed, the exact timestamp, IP address, browser user agent, a coarse device description parsed from it, and the timezone the browser reports. Location is deliberately not collected. A consent form has no need for a person's whereabouts, and gathering it merely because it is technically possible would fail the data minimisation the DPDP Act requires.

The consent link and the finished report are protected by different tokens. Holding a consent link never grants access to a completed report, and a report share link cannot be used to sign consent. Report share links additionally expire after seven days and can be revoked at any time by the account holder.

Withdrawal

A subject withdraws consent themselves at verifybg.in/my-data: they confirm their email address with a one-time code and withdraw from the record, as easily as they gave it. A withdrawal that reaches us another way, through our contact page or a reply to the consent email, is recorded by an administrator along with how we satisfied ourselves it came from the subject.

From that moment the consent stops authorising anything: our servers refuse to run any further check, issue or share a report, or take payment against it; any share link is switched off; the requester and any integrating partner are told; and the personal data is brought forward for deletion on the next daily purge.

The consent record itself is not erased. That record is what evidences the earlier processing was lawful at the time it happened, and destroying it would weaken the subject's position rather than protect it. After withdrawal the record continues to verify, and states plainly that consent was given and has since been withdrawn.

Audit trail

Every consent signature, every check completion, every report view or download, and every dispute is written to an append-only audit log. The application never edits or deletes an entry. The one change ever made is the retention sweep removing a subject's personal details (IP address, device, and any text they wrote) from entries once their data is deleted, and that sweep logs itself.