Data Privacy and Sovereignty: Fraud Prevention That Can't Read Your Customers' Data

Why are third-party vendors the fastest-growing breach vector?

Because attackers have learned that the vendor is the softer path to the data. The pattern is now familiar: a single file-transfer vulnerability cascading to 2,700+ organizations and roughly 93 million people; roughly 165 customer environments at a major cloud data platform breached via stolen credentials while the platform itself was never compromised; an identity provider's support-system compromise reaching 134 of its customers through stolen session tokens.

The takeaway isn't “pick more careful vendors.” It's that data minimization is the only security control that fails safe. If a vendor never holds decryptable PII, breaching that vendor yields ciphertext, not identities — and the blast radius collapses to encrypted blobs sitting on infrastructure you own. You can't leak what you can't read.

What does “the vendor can't read your data” actually mean?

Most vendors describe privacy as “encrypted at rest and in transit.” That's table stakes — and it's vendor-decryptable encryption: the keys sit next to the data, so a deep enough compromise reads both. A genuinely different model rests on four design decisions, each shrinking what an attacker, a rogue insider, or a legal demand served on the vendor can obtain:

Encrypt inside your perimeter, before the vendor receives it.

Sensitive data is encrypted on your own CDN edge the moment it's captured, using Hybrid Public Key Encryption (HPKE, RFC 9180) — the modern standard that also underpins TLS Encrypted Client Hello. The edge encrypts to a public key; the matching private key stays locked away. A compromised edge cannot read past traffic.

Make it searchable without making it readable.

Fraud investigation needs search, so each identifier is transformed by a one-way elliptic-curve process into an anonymized token that supports exact-match search but is irreversible and rainbow-table resistant. Only that token reaches the vendor — never the raw value.

Store it in your cloud; you own the data.

Encrypted PII is written directly from your edge into a storage bucket you own and control, in any region you choose. The cleartext never touches the vendor's SaaS, and you can read your own data without calling the vendor at all.

Decrypt only in the browser.

When an authorized analyst views PII, decryption happens inside their browser — never on a vendor server. Plaintext PII exists only inside the analyst's browser tab.

How does in-browser decryption work?

The idea rests on one detail of how HPKE is built: every encrypted record is really two pieces — a small encapsulated key and the encrypted body. To recover plaintext you need the encapsulated key, the private key, and the body, all in one place. In-browser decryption deliberately never lets those meet.

The vendor's key service uses the private key to turn the encapsulated key into a single-use session key — but it never receives the encrypted body, so it can never produce plaintext. The browser holds the encrypted body and receives the session key — but it never receives the private key, only a disposable key for the one record on screen. Split that way, no single party can reconstruct your customer's data, and the half the vendor holds never includes the data at all.

Every record is sealed with its own fresh, single-use key, so one leaked key exposes exactly one record. Every step is gated by a signed permission token, with the most sensitive categories — passport, PAN, biometric, health — behind a separate claim, available to humans only. And the final decrypt uses the browser's own audited WebCrypto AES-256-GCM, not hand-rolled JavaScript cryptography.

Does this satisfy GDPR, HIPAA, and data-residency requirements?

The architecture lines up, control for control, with the regulatory tests legal and compliance teams already apply. For cross-border transfers, EDPB guidance following Schrems II recognizes strong encryption as an effective transfer safeguard provided the vendor never holds the keys — ciphertext stored in your region, with keys you can hold yourself, is a textbook fit. GDPR Article 32 names encryption and pseudonymization as appropriate security measures.

Nearly every US state breach-notification law includes an encryption safe harbor, and HIPAA treats properly encrypted health data held by a keyless “no-view” provider as outside an “unsecured breach.” For financial firms, DORA holds you accountable for third-party ICT concentration risk — a vendor that never holds decryptable PII materially shrinks that surface. Applicability always depends on your data, jurisdictions, and configuration, so validate with counsel — but the mapping is direct.

The blast-radius test

The clearest way to evaluate any data-privacy architecture is adversarial: assume the vendor is fully breached tomorrow. What does the attacker walk away with?

At a typical fraud or data vendor: a database of customer PII the vendor's own systems can decrypt. One stolen credential or server compromise means mass PII exfiltration, breach notifications, regulatory exposure, brand damage — the pattern behind every headline third-party breach.

Under this architecture: an anonymized, one-way-hashed index, plus encrypted blobs in your own cloud that the vendor's services can't read and can't decrypt. The attacker's take is ciphertext and irreversible hashes. Nothing re-identifiable.

Every other security control degrades under a determined enough attacker. Data minimization is the one control that fails safe.

Get the full solution brief

The complete Data Privacy & Sovereignty brief includes the full write-path and read-path architecture diagrams, the key-custody model showing who can decrypt and who provably cannot, the API Outpost deployment for server-to-server integrations, the compliance mapping with sources, and the cryptographic specifications.

Download the Darwinium Data Privacy & Sovereignty solution brief to see the architecture in detail.

Frequently Asked Questions

What is data sovereignty in fraud prevention?

Data sovereignty means your customer data stays under your ownership, in your cloud, in the region you choose — subject to your jurisdiction's laws rather than your vendor's. In fraud prevention, it means the platform analyzes risk using anonymized signals while encrypted PII never leaves infrastructure you control.

What is HPKE (RFC 9180)?

Hybrid Public Key Encryption is an IETF standard that combines public-key encapsulation with authenticated symmetric encryption. Data is encrypted to a public key at the point of capture, while the private key needed to decrypt stays locked away — so the system doing the encrypting can never read what it encrypted.

What is in-browser decryption?

A zero-knowledge read path where encrypted records are fetched directly from the customer's own storage and decrypted inside an authorized analyst's browser. The vendor's servers derive a single-use key but never receive the encrypted data, so plaintext never exists on vendor infrastructure.

Does encryption exempt a breach from notification requirements?

Most US state breach-notification laws include an encryption safe harbor: if stolen data was encrypted and the key wasn't also taken, notification generally isn't triggered. HIPAA similarly treats properly encrypted health data as not an “unsecured breach.” Specifics vary by statute and circumstance, so confirm with counsel.