Photo Verification Policy
Reading note. This Policy explains how photo verification works, what the verified badge means, and what happens on failure, retry, review, and appeal. The biometric detail (templates, storage, deletion, consent) is owned by the Biometric Information Policy (/legal/biometric-data).
1. Purpose
Purpose. To explain how Tirvea confirms that the person using an account is the live person shown in the account's profile photographs, and what the resulting verified badge means. Photo verification reduces impersonation and fake profiles.
2. Scope
Purpose. To state what this Policy covers. It covers photo verification (liveness and facial comparison using AWS). It does not cover identity verification through documents (Stripe Identity), which is covered by the Identity Verification Policy (/legal/identity-verification), or the biometric handling, which is owned by the Biometric Information Policy (/legal/biometric-data).
3. Verification Workflow
Purpose. To give the overall flow. Photo verification: (1) starts a verification session; (2) captures a live selfie; (3) runs a liveness check; (4) compares your live capture against your reference face; (5) produces an internal outcome; and (6) issues, withholds, or suspends the verified badge accordingly. A risk assessment can route a case to manual review at any point.
4. Verification Session
Purpose. To explain the session. Verification runs through a short-lived session keyed to your verification flow, account, and environment, with a time-to-live. Expired, already-consumed, or invalidated sessions are refused, so a session cannot be reused or replayed.
5. Selfie Verification
Purpose. To explain the live capture. You complete a live selfie capture during the session. The capture is used for the liveness check and the facial comparison; short capture media exists only transiently in the provider's environment and is not retained by Tirvea (Biometric Information Policy, /legal/biometric-data).
6. Liveness
Purpose. To explain the liveness check. An AWS Face Liveness check confirms a real, live person is present, to prevent spoofing with a photo, mask, or screen. Liveness requires your active biometric consent; without it, the check does not run.
7. Face Matching
Purpose. To explain the comparison. AWS Rekognition compares your live capture against your reference face and returns a calibrated similarity. That similarity is mapped by policy thresholds (set per provider) into a band - such as match, uncertain, or no match - which drives the outcome. The raw similarity is never shown to users. A face-match provider must be configured for matching to run.
8. Confidence and Risk Scoring
Purpose. To explain scoring and risk. Two things inform the outcome: the match band (from the similarity thresholds, §7) and a risk band from the verification risk engine (low, medium, high, or critical). A critical risk band blocks automatic verification and forces manual review (§15). These signals are internal; the risk engine outputs only a band and normalised signal names (Trust & Safety Policy, /legal/trust-safety, and AI Moderation Policy, /legal/ai-moderation).
9. Verification Outcomes
Purpose. To explain outcomes, without exposing internals. Verification produces an internal outcome and reason code that are never made public; public surfaces show only whether an account is verified. Outcomes include a successful match (badge issued), a different-person result (badge suspended, §11), an AI or manipulation-risk result (badge withheld, appealable, §17), and a provider-unavailable result (previous badge kept, retried, §14).
10. Badge Issuance
Purpose. To explain the badge. A successful verification issues a verified badge that other members can see. The badge is a simple boolean indicator; it does not reveal your images, your similarity score, or any reason code. It reflects only current, valid verification.
11. Badge Revocation
Purpose. To explain revocation and suspension. The badge is suspended where a check indicates a different person, and revoked and cleared where verification is invalidated, found wrongful on review, or your biometric consent is withdrawn; on revocation the associated biometric reference is deleted (Biometric Information Policy, /legal/biometric-data) and, where relevant, the account state is handled under the Account Suspension Policy (/legal/account-suspension).
12. Verification Failure
Purpose. To explain what happens on failure. If liveness or the face match does not pass, verification does not succeed and the badge is not issued (or is suspended, §11). A failure that is a genuine mismatch is distinguished from a provider outage (§14), which is not treated as a failure. You can retry (§13), and you can appeal a consequential decision (§17).
13. Retry
Purpose. To explain retry. You can retry verification. Attempts are counted, and a retry re-uses the same valid liveness session where possible. Retries are subject to rate limiting to protect the Service. A hard maximum-attempts cap is not fixed in this draft. [Legal review required before publication - confirm whether a maximum-attempts cap is required.]
14. Provider Outages
Purpose. To explain resilience. If a verification provider is unavailable, this is treated as a provider problem, not a mismatch: your previous badge is kept and the check is retried, rather than recording a rejection. This ensures an outage does not wrongly remove a member's verified status.
15. Manual Review
Purpose. To explain human review. A verification can be routed to human review - for example, when the risk band is critical (§8) or a binding needs confirmation. During review, an account may be placed in a photo-review-required state in which new uploads are blocked until review clears. Reviewers act on outcomes and references, not on stored images or scores.
16. Verification Expiration
Purpose. To explain expiry. The verified badge does not expire on a fixed calendar in the current implementation. The underlying biometric reference is rotated periodically as described in the Biometric Information Policy (/legal/biometric-data), but there is no scheduled re-verification period. [Legal review required before publication - confirm whether a re-verification period is required.]
17. Appeals
Purpose. To explain how to challenge an outcome. If verification is withheld, suspended, or revoked and you believe that is wrong, you can re-attempt verification and, where a decision affects your account, appeal under the Appeals Policy (/legal/appeals). An appeal against an automated outcome is reviewed by a person.
18. Security
Purpose. To explain protection. Verification is protected by the safeguards in the Security Policy (/legal/security) and Biometric Information Policy (/legal/biometric-data): EU-region processing, opaque references, and no storage of images, geometry, or similarity scores in our systems or logs. Sessions are short-lived and single-use.
19. Privacy
Purpose. To connect to privacy. How verification data is processed is described in the Privacy Policy (/legal/privacy) and Biometric Information Policy (/legal/biometric-data); retention and deletion are governed by the Data Retention Policy (/legal/data-retention) and Biometric Information Policy. Only a boolean badge is public; internal outcomes and scores are not disclosed.
20. Children
Purpose. To confirm the adults-only position. Tirvea is strictly for adults (18+). Verification supports keeping the community adult and genuine; child-safety matters are governed by the Child Safety Policy (/legal/child-safety).
21. Updates
Purpose. To explain changes. We update this Policy to reflect changes in the verification workflow or the law - including if we introduce a re-verification period or a maximum-attempts cap. We update the "Last Updated" date and take reasonable steps to communicate material changes.
22. Contact
Purpose. To tell you how to reach us about photo verification.
- Data Controller: WiseWave Limited (Company Number 762171)
- Registered office: 39 Cooley Park, Dundalk, Co. Louth, A91 AP2V, Ireland
- Email: info@tirvea.com
For the biometric handling, see the Biometric Information Policy (/legal/biometric-data); for identity verification, the Identity Verification Policy (/legal/identity-verification); for appeals, the Appeals Policy (/legal/appeals).