Trust & safety

Security. Proofs over vaults.

Checkify is designed to minimise unnecessary identity-data exposure, using device-first and privacy-minimising processing where supported so businesses can receive the proof they need without automatically becoming custodians of underlying identity documents.

Security controls Responsible disclosure

This page describes our security approach at a high level. Exact controls may vary by deployment and integration requirements.

Security principles

Minimise data custody

Default to proofs (e.g., “Over 18”) rather than raw personal data. Users must explicitly consent to any data sharing.

Strong authentication

Device-bound identities, biometric/PIN protection, and time-limited tokens reduce account takeover and replay risk.

Defense in depth

Layered controls across device storage, cryptography, transport security, server protections, and auditability.

Built for privacy-first verification

Key controls

1) Device-first storage

Sensitive verification information is designed to be stored on the user's device by default where supported.
Protected using OS secure storage and device lock mechanisms.
Access gated by PIN and biometric checks where supported.

2) Cryptography & integrity

Requests and responses are signed to make them tamper-evident.
Time-limited requests reduce replay risk.
Reference IDs enable traceability without exposing unnecessary data.

3) Transport security

Traffic encrypted in transit (TLS) for app, API, and dashboard flows.
Token scopes and short lifetimes reduce exposure if intercepted.
Strict request validation and server-side verification of signatures.

4) Authentication & authorization

JWT-based sessions for APIs and business dashboard access.
Role-based access for business actions (e.g., create requests, view logs).
Business actions tied to a verified user identity.

5) Audit-ready logging

Events include timestamps, outcomes, and references to requests/responses.
Designed for investigations and compliance reporting.
Logs avoid unnecessary personal data wherever possible.

6) Platform hardening

Rate limiting and abuse prevention on sensitive endpoints.
Monitoring and alerting for unusual activity.
Regular dependency updates and security review of critical flows.

Selective disclosure (what businesses can request) Businesses can request specific proofs (e.g., age threshold, residency, eligibility) and optionally request specific data points. Users see the full request and must explicitly consent before anything is shared. Checkify is designed to support proof-first flows to minimise data exposure.

Threats we design against

Replay & QR abuse

Expiring requests, server verification, and signed payloads reduce the value of copied/forwarded codes.

Account takeover

Device-bound identity + biometric/PIN checks + short-lived tokens help prevent unauthorized access.

Data over-collection

Proof-first flows and explicit consent reduce the likelihood of sensitive data being stored where it's not needed.

Security FAQ

Do you store personal data on your servers?

Checkify is designed around device-first and privacy-minimising processing where supported. Where server-side data is required for operational reasons (for example audit events or request references), we minimise personal data and focus on proofs and metadata.

Can a business request specific user details?

Yes—businesses can request specific proofs and, if needed, specific data points. Users review every request and must explicitly consent before anything is shared.

How do you prevent tampering?

Requests and responses are designed to be cryptographically verifiable, time-limited, and validated by the receiver. This makes tampering detectable and reduces replay value.

Responsible disclosure

If you believe you've found a security vulnerability, please report it responsibly. We'll review reports promptly and work with you to validate and remediate issues.

How to report

Email: security@checkify.me (recommended)
Include steps to reproduce, impact, and any supporting evidence
Please avoid accessing or modifying real user data

What happens next

We acknowledge receipt and triage the report
We validate, fix, and deploy mitigations as appropriate
We can coordinate public disclosure timing if needed