Identity verification for guardian consent of minor students

What schools ask of guardian checks

An online school, a tutoring platform and a language course for teenagers may all meet the same moment at the start, but only in some cases. The rule quoted below applies where consent is the legal basis for processing a child's data and the service is offered directly to the child. It does not make parental consent a condition of every enrolment of a minor, and it does not cover processing that rests on another legal basis. Where it applies, a child below the age set in the country has their data processed lawfully only if an adult with parental responsibility gives or authorises the consent, and the service must make reasonable efforts to verify that. A tick box that says "my parent agrees" is not evidence of anything. The school needs a record that a particular adult, with a particular document, took the step.

The identity check does one part of this job. It establishes who the adult is. It does not establish the relationship between the adult and the child, and it does not decide what the law of your country requires. Those remain with the school and its adviser. What the check can do is replace a claim with a record.

• Verify the adult who consents with a document and a live face, on their own phone.
• Verify a student of the right age in a separate session, when your design asks for it.
• Read the guardian's name from the document so the school can compare it with the name in its own record.
• Keep the session log for the school to show what was checked and when.
• Choose how long the personal data is kept.

The flow

1. Enrolment. The family fills in the enrolment form in the school's own system, and the system sees that the student is below the age that needs a guardian. This rule is yours.
2. Links. Your backend creates a session for the guardian and sends a one-time link, or the guardian scans a QR code to move from a desktop to a phone. When your design also verifies a student, it creates a second session with its own link.
3. Questionnaire. The guardian enters name, birth date, contacts and the custom fields you need, such as the student's enrolment number, before the KYC starts.
4. Document. The guardian photographs a passport, national ID card, driver's licence or residence permit. The document is read and checked for fraud.
5. Selfie and liveness. The selfie is matched to the document portrait and active liveness confirms a live person.
6. Student, where the age fits. A student can complete a session of their own with the age window of the scenario, which is configurable from 16 to 100. A younger child does not complete one, and the guardian's session carries the check.
7. Consent. The school's own system records the consent and links the guardian's session to the student's record. The platform reads no relationship between the two.
8. Return. When the guardian comes back for another child or another year, a returning user is compared with a stored reference face.
9. Data. Retention is a setting you choose per scenario, and erasure on request is available through the API.

Where this differs from the education page

The education page is about the student: enrolment with a document, duplicate applicants, whole cohorts. This page is about a different person, the adult behind a minor, and about a different question. The first is whether the student is who they say they are. The second is whether somebody who can answer for the student has really answered. The two checks can run side by side in the same school, with the same modules, for different people.

Modules used

• Document verification, face verification and liveness.
• Questionnaire and QR hand-off with one-time links.
• Age check for the student's own session.
• Dashboard for the session log.
• REST API and webhooks to link the result to the student record.
• Data controls for retention and erasure.

Regulatory frame

One European Union text: Regulation (EU) 2016/679, the General Data Protection Regulation, in the Official Journal text. Article 8 concerns a child's consent in relation to information society services.

• Article 8(1) provides that, where consent is the legal basis and the offer of information society services is made directly to a child, the processing of the personal data of a child is lawful where the child is at least 16 years old, and where the child is below the age of 16 years, only if and to the extent that consent is given or authorised by the holder of parental responsibility over the child.
• It allows Member States to provide by law for a lower age for those purposes, provided that such lower age is not below 13 years.
• Article 8(2) requires the controller to make reasonable efforts to verify in such cases that consent is given or authorised by the holder of parental responsibility over the child, taking into consideration available technology.
• Article 8(3) provides that paragraph 1 does not affect the general contract law of Member States, such as the rules on the validity, formation or effect of a contract in relation to a child.

This block describes the text, not our service. For information; not legal advice.

Sources

• Regulation (EU) 2016/679 of the European Parliament and of the Council on the protection of natural persons with regard to the processing of personal data, Official Journal text, fetched 26 October 2026.

Next

Try the interactive tour, read about the age check or see the education flow.