Self-Hosted KYC vs Cloud KYC:
Privacy, Cost, and Control

The Cloud KYC Default

If you search "KYC API" today, you'll find Onfido, Jumio, Veriff, Sumsub, and a dozen others. They all work roughly the same way: your application collects an ID photo and a selfie, sends them to the provider's cloud infrastructure, their servers run face matching and document verification, and you get back a result — passed, failed, or needs review.

The integration is straightforward. Drop in an SDK or iframe, call an API, handle the webhook. Most providers offer a polished dashboard, compliance documentation, and support teams. For a product manager evaluating options, it's the path of least resistance. Ship in a week, deal with compliance later.

But there's a detail buried in every cloud KYC architecture diagram that rarely gets the attention it deserves: your users' faces and identity documents are processed on someone else's servers. Their biometric data — the mathematical representation of their face, the high-resolution image of their passport — transits a network you don't control, is decoded in memory you can't inspect, and is processed by models running on hardware you'll never see.

For a long time, this was the only option. Running your own face recognition pipeline required a team of ML engineers, GPU clusters, and months of development. The cloud providers solved a genuinely hard problem, and the trade-off felt acceptable.

That trade-off has changed. Open-source models have caught up. ONNX Runtime runs inference on commodity CPUs. INT8 quantization makes it fast enough for production. The question is no longer can you run identity verification on your own infrastructure — it's whether the cloud default still makes sense for your use case.

The Problem with Sending Faces to the Cloud

Biometric data isn't like a shipping address or an email. You can change your password. You can get a new credit card number. You cannot change your face. A biometric data breach is permanent and irrevocable. That's why regulators treat it differently — and why the architecture of your KYC pipeline matters more than most teams realize.

GDPR Article 28 requires that data controllers (you) only use processors (your KYC provider) that provide "sufficient guarantees" about data protection. But it goes deeper: when your KYC provider sends photos to a cloud AI service for face matching, that cloud service is a sub-processor. You now have a chain of custody that looks like this:

Your app (controller)
  → KYC provider (processor)
    → AWS Rekognition (sub-processor)
      → AWS internal infrastructure (sub-sub-processor?)
        → Data retention policies you've never read

Each link in that chain is a liability surface. Each has its own data processing agreement, its own retention policy, its own incident response procedure. Under GDPR, you — the controller — are responsible for all of them. Under Brazil's LGPD and India's DPDPA, the obligations are similar: you must know where personal data goes, who processes it, and under what terms.

Then there's data residency. The EU's Schrems II ruling invalidated the Privacy Shield framework and made cross-border data transfers legally precarious. If your users are in Germany but your KYC provider routes face matching through a US-based cloud API, you may have an Article 44 violation. India's data localization requirements under the DPDPA are even stricter for certain categories of data. Brazil requires that data subjects be informed of international transfers.

None of this means cloud KYC providers are acting in bad faith. Most have solid security teams and legitimate data processing agreements. The point is structural: every additional processor in the chain is an additional risk surface, an additional compliance obligation, and an additional entity that has seen your users' faces. If the architecture can avoid that chain entirely, it should.

What Self-Hosted KYC Means

Self-hosted KYC means running the entire identity verification pipeline — face detection, face matching, document OCR, MRZ extraction, anti-spoofing, fraud detection — on infrastructure you own or control. No photos leave your servers. No biometric data transits a third party's network. The ML models run locally, the data stays local, and you control every aspect of retention, encryption, and deletion.

In practice, this means Docker containers running ONNX models on your own hardware. The key technologies that make this viable in 2026:

FaceVault's architecture is built on exactly this stack. We don't use any cloud AI APIs. Every neural network — ArcFace for face matching, OnnxTR for OCR, Depth Anything for liveness, MediaPipe for face detection — runs locally via ONNX Runtime. The data flow for a verification is:

User's device
  → Your server (TLS 1.3)
    → Local face detection (ONNX)
    → Local face matching (ONNX)
    → Local OCR + MRZ (ONNX + PassportEye)
    → Local anti-spoofing (multi-signal fusion)
    → Local document fraud analysis
  → Result (never left the server)

Zero third parties. Zero sub-processors. Zero cross-border data transfers. The photo arrives, gets processed, gets encrypted at rest, and eventually gets purged — all on the same machine.

The Real Cost Comparison

The cost structure of cloud KYC and self-hosted KYC are fundamentally different. Cloud KYC is a variable cost that scales linearly with volume. Self-hosted KYC is a fixed cost that gets cheaper per verification as volume increases. Understanding where the lines cross is critical for making the right decision.

The break-even point depends on your cloud provider's per-verification price, but it's typically in the 500 – 1,000 verifications per month range. Below that, cloud is often cheaper when you factor in the engineering time to deploy and maintain a self-hosted solution. Above that, self-hosted wins — and the gap widens rapidly.

At 10,000 verifications per month, a cloud KYC provider charging $1.50 per check costs you $15,000/month. A self-hosted solution on a $200/month dedicated server handles the same volume for $200/month. That's $177,600 per year in savings. At enterprise scale, the numbers become absurd.

Privacy Architecture: How FaceVault Does It

Self-hosted KYC is only as private as the implementation. Running models locally is the foundation, but a complete privacy architecture requires encryption, key management, access control, and data lifecycle enforcement. Here's how FaceVault layers these controls:

When Cloud KYC Makes Sense

It would be dishonest to pretend self-hosted is always the right answer. Cloud KYC exists for good reasons, and there are legitimate scenarios where it's the better choice:

The honest answer is: cloud KYC is easier for small teams with low volume and no privacy-sensitive users. If that describes you today, start with a cloud provider. You can always migrate to self-hosted later when volume grows or regulatory requirements tighten. The important thing is understanding the trade-offs you're making, not pretending they don't exist.

When Self-Hosted KYC Wins

Self-hosted isn't for everyone. But for the scenarios where it matters, it matters a lot:

The Hybrid Approach

There's a false binary in the "cloud vs self-hosted" debate. Most teams don't actually want to run their own Kubernetes cluster with ML models. They want the privacy benefits of self-hosted without the operational burden. This is where a hybrid approach — or more precisely, an API-hosted service built on self-hosted principles — fills the gap.

FaceVault's model works like this:

This gives most teams the best of both worlds: the convenience of an API integration (no ML ops, no infrastructure management) with the privacy guarantees of a self-hosted solution (no cloud sub-processors, encryption at rest, data sovereignty). The only third party in the chain is FaceVault — and we're transparent about exactly what we do with the data, how it's encrypted, and when it's purged.

For teams that need absolute control — air-gapped networks, government classified environments, or compliance frameworks that prohibit any external processor — the self-hosted deployment option exists. Same Docker containers, same ONNX models, your hardware, your network, your rules.

Migration Checklist

If you're currently using a cloud KYC provider and considering a move to self-hosted, here's what the migration involves. This isn't trivial, but it's well-defined work with a clear end state.

Making the Decision

Here's the framework, distilled:

The question isn't "is self-hosted better?" in the abstract. It's "does the privacy, cost, and control benefit of self-hosted KYC outweigh the operational simplicity of cloud KYC for your specific situation?" For many teams, the answer is yes — especially as regulatory pressure around biometric data continues to tighten globally.

The trend is clear. The EU AI Act classifies biometric identification as high-risk. India's DPDPA requires data localization for sensitive data. Brazil's LGPD imposes strict consent requirements for biometric processing. Illinois' BIPA has generated over $5 billion in settlements. Every year, the regulatory bar for handling face data gets higher. Self-hosted KYC — or at minimum, KYC with no cloud sub-processors — is increasingly the path of least regulatory friction.

Start with the question regulators will eventually ask: "Where are your users' faces processed, who has access, and can you prove it?" If your current architecture can answer that cleanly, you're in good shape. If it can't, it might be time to consider a different approach.