# 2. Account Verification

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*

---

## 2. Account Verification

### 2.1 Email Verification
**What it does:** Confirms that a registering user actually controls the email address they provided, by sending a verification link (or code) to that address and requiring it to be used before the account is fully activated. This prevents fake or typo'd email addresses, ensures password-reset and notification channels work, and is a prerequisite for full account functionality.

**Sub-features:**
- Verification email with a single-use, time-limited link (e.g., 24 hours) sent at registration
- Verification code alternative (enter a code from the email) for clients where links are inconvenient (e.g., mobile)
- Resend verification with cooldown and a maximum resend count
- Expired-link handling: clear "link expired" message with a resend option
- Account state during verification: limited functionality (e.g., can log in but with a persistent "verify your email" banner and restricted actions)
- Verification completion: account marked verified, banner removed, full functionality unlocked, event logged
- Admin view: list of unverified accounts with registration date, for follow-up
- Automatic expiry: accounts unverified after a policy period (e.g., 7 days) are deactivated with a notification
- Logging of all verification events (sent, clicked, verified, expired, resent)

**Super Administrator User Journey:**
1. Super Admin opens System Settings → Account Policy → Email Verification and reviews the current settings: link validity 24 hours, max 3 resends, unverified accounts deactivated after 7 days.
2. Adjusts the deactivation period to 14 days to reduce churn from users who register but verify late, and saves.
3. Super Admin opens the user directory and applies the "Unverified email" filter to see all accounts awaiting verification, sorted by registration date.
4. Reviews the oldest entries: several accounts are approaching the deactivation window. Super Admin notes that a marketing campaign drove registrations, so the volume is expected.
5. For a specific user who reported not receiving the email, Super Admin opens the account record, checks the verification event log (sent at registration, one resend), and triggers an admin resend from the record.
6. The user confirms verification; the account's status changes to "Verified" in the directory, and the event is logged.
7. At the end of the window, the system deactivates the remaining unverified accounts automatically; Super Admin reviews the deactivation batch in the activity log and confirms the count matches expectations.
8. Super Admin reviews the verification funnel in the dashboard: registration → email sent → verified, to monitor the drop-off rate over time.

**Rules & Edge Cases:**
- The verification link is single-use and bound to the account; clicking it from a different account context or after verification shows an appropriate "already verified" or "invalid" message.
- Resends are rate-limited to prevent email abuse; exceeding the maximum requires a support-assisted resend.
- A verified email that is later changed by the user triggers a fresh verification of the new address (the account re-enters the limited state for the new address).
- Deactivation of long-unverified accounts is reversible: if the user re-verifies within the retention window, the account is restored with its data intact.
- All verification events are logged and visible in the account's activity history.
- Verification is required before certain actions (e.g., purchasing a membership, receiving OTP-based logins to that email) per policy configuration.

### 2.2 Phone Number Verification via OTP
**What it does:** Confirms that a registering user controls the phone number they provided by sending an OTP via SMS (with voice-call fallback where supported) and requiring it to be entered correctly. A verified phone enables SMS-based OTP login, 2FA, and reliable account recovery, and is required for account activation per policy.

**Sub-features:**
- OTP sent via SMS to the registered number at registration (and on number change)
- 6-digit code with validity window (e.g., 5 minutes) and attempt limit (e.g., 5)
- Resend with cooldown (e.g., 30–60 seconds) and maximum resend count
- Country-code-aware number entry with format validation per region
- Voice-call OTP fallback where SMS delivery fails or is unavailable
- Verification completion: number marked verified, enabling SMS-dependent features, event logged
- Number change flow: re-verification required when a user updates their phone number (with identity check)
- Admin view: list of accounts with unverified or failed phone verification
- Delivery-failure handling: carrier failures, invalid numbers, and throttling each produce distinct outcomes
- Logging of all OTP issuances, verifications, failures, and delivery outcomes

**Super Administrator User Journey:**
1. Super Admin opens System Settings → Account Policy → Phone Verification and reviews settings: 5-minute validity, 5 attempts, 3 resends, voice-call fallback enabled.
2. Super Admin opens the user directory, filters by "Phone unverified", and reviews the list with registration dates and last OTP attempt outcomes.
3. A cluster of accounts shows repeated "delivery failed" outcomes from one carrier region. Super Admin opens the delivery-failure report, confirms the pattern is carrier-side, and notes it for the communications provider review.
4. For an individual user stuck at verification, Super Admin opens the account record, reviews the OTP event log (issued, expired, resent twice), and triggers an admin resend using the voice-call channel.
5. The user completes verification; the account's phone status changes to "Verified" and SMS login/2FA become available for that user.
6. A user requests a phone number change. The change flow requires verifying the new number with an OTP and confirming identity (current password or existing verified channel) before the number is swapped.
7. Super Admin reviews the number-change audit entries to confirm each change had both identity verification and new-number verification recorded.
8. Super Admin monitors the verification funnel (registered → OTP sent → verified) in the dashboard to track conversion and spot regional delivery issues early.

**Rules & Edge Cases:**
- The OTP is single-use and expires; wrong attempts beyond the limit require a fresh issuance.
- A phone number can be bound to only one active account; registering a second account with a verified number is blocked (prevents abuse and aids recovery).
- Number changes always require verifying the new number and confirming identity on an existing trusted channel; a user with no other verified channel uses the support-assisted path.
- SMS delivery failures (carrier throttling, invalid number, no credit) produce a retry path with the voice-call fallback where enabled.
- Resends are rate-limited per number and per account to prevent SMS pumping abuse.
- All verification events are logged with channel, outcome, and timestamp; delivery failures are separately reportable.
- Verification is a prerequisite for SMS-based login and SMS-based 2FA; until verified, those options are unavailable for the user.

### 2.3 Age Verification
**What it does:** Ensures that users meet the minimum age requirement to use the platform (or specific parts of it) by capturing date of birth at registration and verifying it, with age-appropriate gating for features that are restricted to adults. For an education platform serving minors, this also determines which consent and safeguarding flows apply (see 2.4).

**Sub-features:**
- Date-of-birth capture at registration with format validation and plausibility checks (not in the future, within a sane range)
- Minimum-age policy configuration (e.g., 13+ for self-registration; certain features 18+)
- Age-band classification: minor vs. adult, driving which consent and feature-gating rules apply
- Feature gating: age-restricted features hidden or locked for users below the threshold, with a clear message
- Age re-verification: if age is disputed or corrected, an admin-assisted verification process with evidence
- Parental routing: users below the self-registration threshold are routed to the parental consent flow (see 2.4)
- Admin view: age-band distribution of the user base and list of accounts with unconfirmed age
- Logging of age capture, corrections, and verification events

**Super Administrator User Journey:**
1. Super Admin opens System Settings → Account Policy → Age Policy and confirms the thresholds: self-registration allowed from age 13; features marked "18+" (e.g., payment methods management) restricted to adults.
2. Reviews the age-band distribution in the user directory: the platform serves a large minor population, so the parental consent coverage is critical.
3. Super Admin applies the "Age unconfirmed" filter to find accounts that registered without a complete date of birth (e.g., via a social login that did not provide it).
4. For each such account, the user is prompted on next login to complete their date of birth before continuing (a blocking prompt with the privacy explanation).
5. A user claims their date of birth was entered incorrectly. They raise a support request; Super Admin (or the assigned support admin) opens the request, reviews the evidence provided (e.g., a government ID per the verification standard), and updates the record.
6. The age correction is audit-logged with the before/after values, the evidence reference, and the acting admin.
7. If the correction changes the user's age band (e.g., from minor to adult), the system updates the applicable consent requirements and feature access automatically, and the user is notified of the change.
8. Super Admin reviews the age-gating audit log to confirm no 18+ feature was accessed by a minor account, as part of the periodic safeguarding review.

**Rules & Edge Cases:**
- Age is determined from the date of birth on record; the system does not re-derive age from other signals.
- A user below the self-registration minimum cannot complete registration independently; the flow routes to a parent/guardian (see 2.4).
- Age-restricted features are enforced server-side; hiding them in the UI is a convenience, not the control.
- Age corrections require admin-assisted verification with evidence; users cannot self-edit their date of birth after registration without going through the correction flow.
- The age band drives consent requirements: minors require parental consent (see 2.4); adults consent for themselves.
- All age-related events (capture, correction, verification) are audit-logged.
- Where local law sets a higher minimum age than the platform default, the stricter threshold applies per the compliance configuration.

### 2.4 Parental Consent Verification for Minors
**What it does:** For users who are minors, verifies that a parent or legal guardian has reviewed and consented to the minor's use of the platform. The flow identifies the guardian, verifies the guardian's identity and authority, captures the guardian's informed consent (covering data processing of the minor's data, communications, and any payments), and links the consent to the minor's account. This is a safeguarding and compliance requirement for an education platform serving children.

**Sub-features:**
- Guardian identification: parent/guardian relationship captured at the minor's registration
- Guardian identity verification: guardian verifies their own identity (email/phone OTP, and document verification where policy requires)
- Guardian authority confirmation: attestation of legal guardianship, with document evidence where policy requires
- Informed consent capture: guardian reviews and accepts a minor-specific consent document (data processing, communications, payments, safeguarding policies)
- Consent record: linked to the minor's account, with version, timestamp, and guardian identity
- Ongoing consent: guardian can review and withdraw consent; withdrawal triggers the account handling policy (pause or close the minor's account)
- Payment authorization: for paid memberships, the guardian's consent covers billing, and payment methods are managed by the guardian
- Admin view: list of minor accounts with consent status (pending, active, withdrawn, expiring)
- Re-consent on material policy changes, mirroring the adult consent flow (see 9.1)
- Full audit logging of the consent lifecycle

**Super Administrator User Journey:**
1. Super Admin opens System Settings → Account Policy → Minor Consent and reviews the configuration: consent document version, verification standard (OTP + attestation, or OTP + document), and the withdrawal handling policy.
2. A minor attempts to register. The registration flow detects the age band and routes to the parental consent step: the minor provides a guardian's name, relationship, and a guardian email/phone.
3. The system sends a consent request to the guardian's channel. The guardian follows the link, verifies their identity (OTP to their phone), confirms their relationship to the minor, and reviews the minor-specific consent document.
4. The guardian accepts; the consent record is created and linked to the minor's account. The minor's account moves from "pending consent" to "active", and the minor can now use the platform within the minor-applicable feature set.
5. Super Admin opens the user directory, filters by "Minor — consent pending", and reviews the queue: accounts waiting on guardian response, with days-pending.
6. For accounts pending beyond the policy window (e.g., 14 days), the system has sent reminder notices; Super Admin reviews the reminder log and, for the still-pending accounts, the system deactivates them per policy (reversible if the guardian consents later within the retention window).
7. A guardian requests to withdraw consent. The withdrawal is recorded, and per policy the minor's account is paused: the minor is notified, active sessions end, and the subscription (if any) is cancelled with refund handling per policy.
8. Super Admin reviews the consent audit trail: each minor account shows the consent event, version, guardian verification method, and any withdrawal, supporting the safeguarding review.

**Rules & Edge Cases:**
- A minor's account cannot be fully active without a verified guardian consent on record; the account remains in a limited/pending state until then.
- Guardian identity verification is mandatory; a consent from an unverified channel is not accepted.
- One guardian can be linked to multiple minor accounts (e.g., siblings), each with its own consent record.
- Withdrawal of consent is honored per the handling policy (pause or close); it is not ignored or delayed, and the minor is notified.
- Payments for a minor's membership require the guardian's consent to cover billing; a minor cannot independently add a payment method.
- Consent documents are versioned; a material change triggers re-consent from guardians, mirroring the adult re-consent flow.
- All consent lifecycle events (request, verification, acceptance, withdrawal, re-consent) are audit-logged with the guardian identity (as recorded) and timestamps.
- Where local child-protection law imposes stricter requirements than the platform default, the stricter standard applies per the compliance configuration.