The bar Rule 10 sets
Section 9 of the Act requires Data Fiduciaries to obtain verifiable parental consent before processing the personal data of children (anyone under 18). Rule 10 specifies what 'verifiable' means — and the answer is: a reliable mechanism to confirm both that the consenting individual is a parent AND that they consent.
Self-declared age gates ('Are you 18 or over?') do not meet this bar. They were never sufficient under any privacy regime that takes children's data seriously, and they certainly don't meet Rule 10.
Why this is hard
The technical problem: how do you verify parental status of someone you've never met, on a device that may be the child's? The legal problem: parental consent isn't enough — you must also avoid 'tracking, behavioural monitoring or targeted advertising' of children, regardless of consent.
Four architectures we've seen work
1. DigiLocker-mediated
The parent authenticates via DigiLocker, providing identity proof and age. Their declaration of relationship to the child is captured. This is the cleanest approach for Indian users — DigiLocker has high trust, the identity is government-issued, the friction is acceptable. Recommended as primary path.
2. Aadhaar offline KYC
The parent shares an Aadhaar offline KYC artefact (PDF or QR), which establishes their identity. Combined with a declaration of parenthood, this satisfies Rule 10. Friction is moderate; technical integration is well-documented.
3. Payment-instrument verification
The parent makes a token transaction (₹1, refunded) from a verified payment instrument linked to their PAN. This proves adult identity (KYC at the bank) and consent. Useful for paid services where payment is happening anyway.
4. Document-upload + manual review
The parent uploads ID and a relationship document (school records, passport with parent name, etc.). Manual review by a trained team. High friction, high cost — only viable for low-volume premium services.
The 'no behavioural targeting' rule
Section 9 prohibits tracking, behavioural monitoring or targeted advertising of children. This is absolute, not consent-curable. Even with parental consent, you cannot:
- Run behavioural-personalisation engines on a child user's session
- Send retargeting messages based on their browsing
- Build lookalike audiences from child user data
- Use heatmaps that capture child user behaviour
The implementation: hard-disable analytics SDKs, marketing pixels, and personalisation engines for users identified as under-18. Add child-segment exclusions to all marketing systems. This is a substantial engineering project — start it now.
The age-transition problem
When a user turns 18, consent shifts from parent-mediated to direct. Your data model must support this. Mature implementations:
- Track user age and trigger re-consent at 18
- Offer the user (now adult) the choice to retain or delete their childhood data
- Lift behavioural-targeting restrictions
- Notify parents of the transition (if they've been managing the account)
Few EdTech platforms in India have built this. It's the next frontier.