Building Privacy-First KYC:
Why We Delete Your Face

The Uncomfortable Truth About KYC Data

Here's something that should bother you more than it probably does: when you scan your passport for a crypto exchange, a neobank, or a fintech app, there's a very good chance your face, your document, and your personal details are sitting on a server somewhere. Indefinitely. Maybe encrypted. Maybe not. You'll never know.

The KYC industry has a dirty secret. Most providers retain biometric data far longer than they need to — sometimes forever. They call it "audit requirements" or "regulatory compliance." And sure, some of that is real. But a lot of it is just inertia. Nobody sat down and asked: do we actually need to keep this person's face photo six months after we verified them?

I've been building FaceVault for months now, and tonight, after hours of running our final security audit and tightening every bolt I could find, I keep coming back to the same thought: the most secure data is data you don't have.

Verify, Then Forget

Here's the core idea behind FaceVault, and honestly it's embarrassingly simple: confirm the person is who they say they are, then get rid of the evidence.

Think about it like a bouncer at a club. They check your ID, they look at your face, they nod and let you in. They don't photocopy your driving licence and file it in a cabinet out back. They don't need to. The verification happened. The answer was yes or no. That's all that matters.

FaceVault works the same way. A user uploads their ID, takes a selfie with built-in liveness detection. Our AI pipeline compares the faces, extracts the document data, returns a result. Then — and this is the part that makes us different — we start counting down to deletion.

The verification result — the pass/fail, the match score, the extracted name and date of birth — that stays in the database as an audit record. But the photos? The actual biometric data? Gone. Truly gone. Not moved to cold storage. Not "soft deleted." os.remove(), shutil.rmtree(), overwritten in the database with None.

Auto-Purge: Your Photos Have an Expiry Date

I'm going to show you the actual code, because I think it matters. When people tell you they "delete your data," you should be able to verify that claim. Here's what runs every night at 3am UTC on our server:

async def purge_expired_sessions(db: AsyncSession) -> int:
    now = datetime.now(timezone.utc)

    # Find every session past its retention deadline
    result = await db.execute(
        select(VerificationSession).where(
            and_(
                VerificationSession.retained_until <= now,
                VerificationSession.status != "purged",
            )
        )
    )

    for session in sessions:
        # Delete every photo file from disk
        for path_attr in ("id_photo_path", "selfie_photo_path",
                          "liveness_photo_path"):
            photo_path = getattr(session, path_attr)
            if photo_path and os.path.exists(full_path):
                os.remove(full_path)
            setattr(session, path_attr, None)  # Clear DB reference

        # Nuke the entire session directory
        shutil.rmtree(session_dir, ignore_errors=True)
        session.status = "purged"

    await db.commit()
    return count

There's no "are you sure?" prompt. No grace period. No recycle bin. When the retention deadline passes, the photos are deleted from disk and the database paths are set to None. The session directory itself is removed. It's not a flag flip — it's actual file deletion.

And here's the thing that took me a while to get right: we send email warnings before deletion. Two days before, and again one day before. Because maybe you need that session data for a dispute, or a compliance review, or a support ticket. We give you time. But when the clock runs out, it runs out.

Developers can also delete sessions immediately through the API or the dashboard. Don't need it? Kill it now. Don't wait for the timer.

Hashing Everything That Moves

Early in development, we stored API keys with SHA-256 hashing — standard practice. But during our pre-launch security audit, I realised we weren't applying that same rigour everywhere. Verification link tokens? Plaintext. Session tokens? Plaintext. If someone ever got read access to the database — SQL injection, leaked backup, compromised server — they'd have every active token.

The window of exposure would be small (tokens expire), but it's still a window I don't want open. So we applied the same pattern across the board before going live: hash before storage, compare hashes on lookup.

# When creating a verification link:
raw_token = secrets.token_hex(32)        # 64 hex chars
token_hash = sha256(raw_token)           # Stored in DB
token_prefix = raw_token[:8]             # For human identification

# Return raw_token to the developer ONCE.
# We never see it again.

# When someone uses the link:
incoming_hash = sha256(request.token)
link = db.query(token_hash == incoming_hash)  # Compare hashes

The developer gets the raw token exactly once, when the link is created. After that, we only store the hash. If the database leaks, an attacker gets a pile of SHA-256 hashes — which are useless. They can't reverse them into working tokens.

We now hash three things: API keys (fv_live_ prefix), verification link tokens, and session auth tokens. If our database ever shows up on a paste site — which, god forbid — none of those secrets are usable.

The localStorage Moment That Kept Me Up

When I first built the developer dashboard, I did what every React JWT tutorial tells you: stored tokens in localStorage. Access token, refresh token, right there. It works. It's easy. Half the internet does this.

But during our security review, I sat down and really thought about it. And the more I thought, the less I liked it. Because localStorage is one XSS vulnerability away from total account compromise.

Here's the problem: any JavaScript running on your page can read localStorage. If an attacker finds an XSS hole — an unsanitised input, a malicious third-party script, anything — they can grab both tokens with two lines of code:

// Any XSS payload can do this:
const access = localStorage.getItem('fv_access_token');
const refresh = localStorage.getItem('fv_refresh_token');
// Send to attacker's server. Game over.

With the refresh token, the attacker can mint new access tokens for 7 days. They own the account until the refresh token expires or the developer changes their password.

So before launch, I ripped it out. All of it. Tokens now live in httpOnly cookies.

def _set_auth_cookies(response, access_token, refresh_token):
    response.set_cookie(
        "fv_access",
        access_token,
        httponly=True,       # JavaScript cannot read this
        secure=True,         # HTTPS only
        samesite="lax",      # CSRF protection
        domain=".facevault.id",
        path="/",
        max_age=3600,        # 1 hour
    )
    response.set_cookie(
        "fv_refresh",
        refresh_token,
        httponly=True,
        secure=True,
        samesite="lax",
        domain=".facevault.id",
        path="/api/v1/auth",  # Only sent to auth endpoints
        max_age=604800,       # 7 days
    )

Three things make this dramatically more secure:

Was this a fun migration at midnight? No. Did it require changing every fetch call to include credentials: 'include'? Yes. Was it worth it? Absolutely. Some things you don't cut corners on just because the deadline is close.

Photos That Can't Be Stolen

Let me walk you through how a face photo travels through FaceVault, because I think the journey tells the story better than any privacy policy could.

return Response(
    content=webp_bytes,           # Converted from JPEG, EXIF stripped
    media_type="image/webp",
    headers={
        "Cache-Control": "private, no-store",
        "Content-Disposition": "inline",
    },
)

The original JPEG never leaves the server. What you see in the dashboard is a lossy, metadata-stripped, cache-disabled WebP preview that exists only in your browser's memory for as long as the tab is open.

Locking the Front Door

When you're deep in building an auth system, it's easy to focus on the happy path: does login work? Do tokens validate? Does TOTP verify? But the security audit forced me to think like an attacker. And the first question an attacker asks is: what happens if I try a million passwords?

That's the thing about building a product — you know the right things to do, you plan to do them, but the "plumbing" gets deprioritised while you're focused on making the core product work. Our pre-launch audit was specifically about catching those gaps before they ever see production traffic.

Here's what we built into the auth layer:

# Track failed attempts per developer email
if not verify_password(body.password, developer.password_hash):
    developer.failed_login_attempts += 1
    if developer.failed_login_attempts >= 5:
        developer.locked_until = now + timedelta(minutes=15)
    await db.commit()
    raise HTTPException(401, "Invalid email or password")

# Successful login: reset everything
developer.failed_login_attempts = 0
developer.locked_until = None

Notice the error message: "Invalid email or password." Not "Invalid password" or "User not found." Generic responses prevent email enumeration. An attacker can't tell whether they have the right email and wrong password, or the wrong email entirely.

GDPR: Not Just a Checkbox

I'll admit something. When I first read the GDPR, my eyes glazed over somewhere around Article 17. It's dense. It's legal. It's written by people who use the phrase "data controller" like it's a job title everyone understands.

But the more I built FaceVault, the more I realised the GDPR isn't just bureaucratic overhead. It's a pretty good blueprint for how you should handle personal data if you actually give a damn about the people behind the data. Here's how we align:

Being Honest About What We Store

I think a lot of privacy pages are kind of misleading. They tell you what they don't do, but they never tell you what they do. So let me be painfully explicit.

That last one is important. The 512-dimensional ArcFace embedding — the mathematical representation of someone's face — is computed during the /complete call, used for comparison, and then discarded. It never touches the database. It never touches disk. It lives in memory for the duration of the request, and then it's gone.