We built TruMint so we can't read your data. Here's the proof.

23 July 2026 · 8 min read · TruMint

Every finance app tells you the same thing: “bank-level security.” It usually means TLS in transit and disk encryption at rest — both worth having, and both beside the point. In that model the company can still read everything. Every employee with production access, every leaked credential, every subpoena, every acquirer of the business inherits full plaintext access to your net worth, your spending, your tax history.

We think a personal finance product should be held to a stronger standard, and we built TruMint to meet it: the people who operate TruMint cannot decrypt your data. Not “won’t.” Cannot. This post explains the architecture that makes the claim true, the uncomfortable part we had to fix to get there, and — because honesty is the whole point — exactly where the boundaries of the claim sit.

Envelope encryption, per person

Every TruMint user has their own data-encryption key. Before any sensitive value reaches the database — an amount, a holding, a description, a tax figure, a National Insurance number — it is encrypted with your key. What the database stores is ciphertext. A breach of the database, or of a database backup, yields unreadable bytes, per user, each requiring a different key.

Your key is itself encrypted (“wrapped”) by a master key that never leaves a hardware-backed key-management service in London. Nobody — including us — can export that master key. Software can only ask the vault to unwrap a user key, and the vault decides who is allowed to ask.

Exactly one identity may decrypt

The list of principals allowed to use the master key has exactly one entry: the production service that renders your dashboard. It authenticates by workload identity — the platform proves which service is calling. There is no key file on any server, laptop, or CI runner. A stolen credential from anywhere else in our infrastructure gets the same answer a stranger would: permission denied.

Decryption is also fail-closed. If a decrypt fails, the request errors — the system never silently returns ciphertext or an empty value. There is no code path where “couldn’t decrypt” degrades into “show whatever we have.”

The uncomfortable part: locking out the founder

Here is the part most security pages skip. On any cloud platform, the human who owns the account starts with implicit rights to everything — including key management. Encryption that the owner can quietly bypass is a policy, not a property. For months, that was our honest residual risk: the architecture kept everyone out except the one person with the root of the cloud account.

So we removed that too. TruMint’s cloud accounts now sit under an organisation with a deny policy — a rule that overrides every other permission, including the owner’s — barring every human identity from using the master key. The only principal the deny policy exempts is the production service. When the founder tries to decrypt user data with full owner credentials, the platform refuses. We tested it. It fails, by design.

And because a policy you can silently edit is barely a policy, the key infrastructure is alarmed: any attempt to change who may use the master key — or to disable or destroy it — fires an alert to us in real time. Re-granting human access isn’t a quiet toggle; it would be a visible, logged, alerted event.

Files get the same treatment

The documents you upload — P60s, bank statements, broker exports — are envelope-encrypted the same way before they touch storage, bound to your identity and the file’s location so ciphertext can’t be swapped between users. Uploaded files are consumed server-side only; there are no public download links to leak.

What this means in practice

• Someone breaches the database: they get per-user ciphertext, not your finances.
• An employee (today, the founder) goes rogue or is phished: their credentials cannot decrypt user data.
• A backup, log pipeline, or analytics store leaks: sensitive fields in it are ciphertext.
• We are compelled to hand over stored data: what we can hand over is what we can read — see the boundaries below.

The honest boundaries

A claim like this is only worth making if we also tell you where it stops.

• Some metadata stays queryable. Identifiers, dates and type enums are not encrypted — the database must filter and sort by them. Amounts, names, descriptions and balances are. We keep the plaintext set to fields that don’t reveal your financial position.
• The server sees plaintext in memory while working for you. TruMint computes your tax and insights server-side, so the production service must decrypt while processing your request. This is not end-to-end encryption like a password manager — a product that computes Section 104 pools for you cannot be. What we’ve built is the strongest claim compatible with doing that work: only the service, only at runtime, never a human.
• We can still delete. Not being able to read your data doesn’t mean we can’t manage it. Deleting your account destroys your data — and your wrapped key with it.

That’s the proof, at the level of architecture. The mechanisms — per-user envelope encryption, single-principal key access, an owner-proof deny policy, alerting on any change — are all standard, verifiable cloud-platform primitives; nothing here depends on trusting our good intentions. It depends on configuration that we would have to visibly, auditably break.