Data policy · Zoza Auth

What we store. What we don't. For how long. Full stop.

Zoza Auth is structurally a low-data product: the entire cryptographic protocol is designed so the server sees as little as possible. This page is the honest enumeration — not a 40-page PDF full of "may include" — of every byte we put in a database and how it dies.

What we keep

💼 Identity-adjacent (retained 90 days)

app_id — the bank's customer app identifier.
user_id — the bank's label for the user, opaque to us.
device_id — the bank's label for the device ("iphone_15_pro").
device_name — user-facing label for the registered device.
public_key — the device's Curve25519 public half.

📓 Operational (retained 90 days)

challenge_id, nonce, context, metadata.
status: pending / approved / denied / expired.
issued_at, expires_at, used_at.
Audit rows (see audit policy).

What we don’t

🚫 Never stored, ever

The user's private key — it stays in Secure Enclave / Android Keystore.
The DH proof — verified once, then garbage-collected.
Biometric templates — never reach Zoza; they gate the device's Keystore locally.
User phone number, email, Aadhaar, PAN, bank account balance, transaction amount — none of this is in our design.
Device location / IP geo — we record submitter_ip for apply-form abuse triage only, not for per-auth operation.

🔒 Kept server-side but never in plaintext

Customer bank API key — only SHA-256 hash is stored; raw key shown once at issuance.
Customer bank webhook key — same pattern.
Customer bank's app server private key — at rest in the Fly volume Postgres, protected by disk encryption at the Fly layer. Roadmap: threshold-split across regions.

Retention ladder

Live operational data (devices, issued challenges): as long as the challenge is live + referenced; after resolution, retained for up to 90 days for dispute-resolution per RBI SBS-2021 paragraph 4.3.
Audit rows: 90 days on our side; customer banks are strongly recommended to scrape into their own SIEM for longer retention.
Applications (pending / approved / rejected): indefinite while the customer relationship is live; purged 12 months after offboarding upon request.
Backups: Fly-volume snapshots rotated at 7 / 30 / 365 day intervals. Oldest snapshot automatically destroyed beyond 365 days.

DPDP + RBI alignment

Zoza Auth is designed to fit inside the India DPDP-2023 + RBI SBS-2021 regulatory frame:

DPDP Section 4 — "lawful purpose with consent": Zoza is the processor; the data fiduciary is the customer bank. Consent flows through the bank's own T&Cs, not Zoza's.
DPDP Section 8 — "data minimisation": we collect the bare minimum to operate the protocol. Public keys + opaque IDs + timestamps. See "What we don't".
DPDP Section 11 — "data breach notification": 72h-to-fiduciary SLA enshrined in our bounty incident process.
RBI SBS-2021 paragraph 4.3 — "customer-complaint auditability": 90 days retention of challenge metadata, API to fetch.
RBI SBS-2021 paragraph 7.1 — "cryptographic control": Curve25519 + HKDF-SHA256 are NIST-aligned and accepted under RBI cryptographic controls.

Requesting deletion

For end-users: your request must go through your bank, because Zoza is the processor. The bank calls DELETE /v1/devices/{id} on our API. We mark the device inactive immediately; the public key is purged at 30 days; the audit trail rolls off at 90 days.

For customer banks ("right to be forgotten" at the B2B level): email legal@zoza.world or file via zoza-admin. We will offboard within 30 days: disable keys, suspend app, and destroy all device public keys + audit rows older than the 90-day retention. A signed certificate of destruction is provided.