August 8, 2026 · 5 min read
Zero-retention, not zero-knowledge — what that distinction actually means
Two different privacy promises get used interchangeably in fintech marketing. They are not the same promise, and the difference is the whole point.
“We take your privacy seriously” is printed on the login page of nearly every financial app that has ever sold access to your transaction data. The words are cheap. What matters is the architecture underneath them — and there are really only two architectures that matter here: zero-knowledge and zero-retention. Most products are neither. It’s worth knowing which one you’re actually getting.
Zero-knowledge
A zero-knowledge system is built so the provider mathematically cannot read your data — even if they wanted to, even under subpoena, even if their servers are fully compromised. The data is encrypted with a key only you hold, before it ever leaves your device. This is a strong, specific, verifiable guarantee, and very few consumer financial products actually build it: it’s expensive, and it makes ordinary conveniences (server-side search, sync without a passphrase prompt) much harder.
Zero-retention
A zero-retention system processes your data to do useful work — compute your net worth, run a tax projection — but doesn’t keep a copy once that work is done. The provider technically *could* read your data while it’s in memory doing the computation. It just doesn’t keep it afterward. That’s a weaker guarantee than zero-knowledge, and an honest product says so plainly instead of borrowing zero-knowledge’s language for a zero-retention system.
Where FullyNetted sits today
Self-hosted and run locally, your data never leaves your machine at all — the strongest position, not because of clever cryptography but because there’s no server in the loop to trust in the first place. If you ever run a hosted instance instead, that’s zero-retention: your session computes your dashboard and your tax estimate, then the server holds nothing once you’re done. Bank-connection tokens and AI provider keys are encrypted at rest in the database either way. Whole-file passphrase encryption at rest is on the roadmap, not shipped yet — and until it ships, nothing here will claim otherwise.
The distinction isn’t pedantic. It’s the difference between “trust our promise” and “trust the math.”