How Stile handles your data

Product-spec paragraph (compliance-approved)

Stile receives the document image and selfie at session start. OCR, barcode cross-reference, liveness, and face match run server-side; the response is a signed webhook containing an eligibility signal and a session ID. Source images and biometric templates are retained according to the per-account retention configuration — the default is delete-on-completion, with optional configurable retention windows for chargeback or fraud-investigation lookback. Customer-controlled keys (CMEK) and SOC 2 Type I certification are roadmapped for Q3-Q4 2026.

Encryption posture

All API and admin traffic is encrypted with TLS 1.3 in transit. Stored documents and biometric templates are encrypted with AES-256 at rest. Customer-controlled keys (CMEK) — encryption keys held by the merchant rather than by Stile — are roadmapped for Q3-Q4 2026 alongside SOC 2 Type I.

Retention semantics

Retention is configurable per account. The default is delete-on-completion: source images and biometric templates are discarded once the verification session resolves and the signed webhook is delivered. Merchants who need lookback for chargeback dispute resolution or fraud-investigation review can configure a retention window — measured in days, not months — bound to the merchant's contractual obligations. The eligibility signal and session-ID audit pointer are retained on a longer horizon to support audit trails; the underlying biometric and document artifacts are not.

Data-minimization architecture

The merchant's product code receives the eligibility decision (pass / fail / age tier / jurisdiction resolved) in the signed webhook. The merchant does not receive the raw document fields, the biometric template, the date of birth, or the source image in the default configuration. Reducing the surface that crosses the integration boundary reduces the merchant's compliance and breach exposure on their side, and Stile's exposure on ours. Related: PII walks through the legal scope and the practical handling rules.

Jurisdictional posture

Data-handling architecture is aligned with GDPR Articles 5, 17, and 25 (data minimization, right-to-erasure, privacy by design). This is architectural alignment, not a certification — Stile is not GDPR-certified by an external body, and no such certification exists for processors of GDPR's scope. Per-jurisdiction handling is configured per the merchant's residency and the user's jurisdiction at session time. The US state compliance hub tracks state-by-state coverage; international scope is a per-contract conversation today.

Certifications — achieved versus roadmapped

Buyer-diligence reviewers want a clean answer to which certifications Stile holds today versus which are roadmapped. The honest answer:

Achieved today: TLS 1.3 in transit, AES-256 at rest, WCAG 2.2 AA on marketing-site routes, GDPR-architectural alignment as described above.

In progress (Q3-Q4 2026): SOC 2 Type I audit underway with certification expected in the back half of 2026; Customer-controlled keys (CMEK) — encryption keys held by the merchant rather than Stile — roadmapped for the same window.

Not claimed: Type II SOC 2 reporting is not certified and is not claimed. ISO 27001 is not certified. PCI DSS is not in scope (Stile does not handle payment data). HIPAA is not in scope. If a specific certification gates your evaluation, raise it before contracting and we will tell you the actual status, including what's underway and what isn't on the roadmap.