Policy overview
This Data Policy describes Toni's operating rules for sensitive verification data. Toni maintains results for reuse when they satisfy a platform's requirements, and gives partners approved claims instead of raw ID photos or biometric images.
1. Data Classification
- Restricted data includes government ID images, document numbers, face/liveness evidence, biometric templates when applicable, fraud signals, and manual review notes.
- Confidential data includes account contact details, business and representative information, provider references, verification outcomes, partner connections, signed assertions, and billing or support records.
- Partner-shareable data is limited by approved scopes: partner-app-scoped identifier, verification status and relevant check results, and email or profile name where requested and approved.
2. Data Minimization
Toni should collect the minimum fields needed to verify identity, review businesses, secure the account, satisfy consent, support audits, and operate the service. Partner integrations should request scopes, and Toni should deny or narrow claims that are not necessary for the partner's stated use case.
3. Raw Evidence Handling
Didit processes raw ID documents and face/liveness captures in its verification flow. Toni's partner assertions exclude those images. Toni retains operational account, business, verification, consent, and audit records, not only cryptographic hashes.
4. Retention Rules
- Verification result records, consent logs, audit events, and partner assertions may be retained to prove what Toni verified and shared.
- Raw document and face/liveness evidence should have shorter retention windows than result records unless fraud review, dispute handling, law, provider rules, or regulatory duties require longer retention.
- Existing verification results are reusable only when they satisfy the requesting platform's configured checks and freshness requirements.
5. Access Controls
Access to restricted data should require least privilege, role-based authorization, strong authentication, audit logging, and operational need. Manual reviewers should see only the evidence needed to resolve the assigned case, and administrative access should be monitored.
6. Vendor and Provider Data
Didit supplies identity verification and Stripe processes payments. Provider-held evidence and payment records follow separate retention processes. Toni coordinates applicable data requests; completing a verification or revoking a connection is not itself a provider deletion request.
7. Partner Claims and Scopes
- Partners should receive signed, scoped claims rather than raw evidence.
- Each partner should use a partner-scoped Toni user ID so one partner cannot correlate a user across the Toni network without authorization.
- Claims should include timestamps, status, scopes, issuer, audience, expiration, and verification level where applicable.
8. Deletion, Revocation, and Correction
When a user requests deletion or correction, Toni should verify the requester, evaluate legal exceptions, revoke or update partner-sharing records where appropriate, and keep limited audit records when necessary to prevent fraud, comply with law, or prove prior consent.
9. Security Monitoring and Incident Response
Toni should monitor suspicious activity, failed verification patterns, credential abuse, partner misuse, administrative access, and data export events. Security incidents should be triaged, contained, investigated, documented, and communicated according to applicable legal and contractual requirements.
10. Governance
Toni should maintain data inventories, provider inventories, retention schedules, access reviews, audit-log review, policy updates, and partner compliance reviews as the platform grows.