Security & privacy

Zero-knowledge by construction.

A place that holds your whole financial life has to be private. Your data is encrypted on your device with a key derived from a master password we never see. The server stores ciphertext only. No one at Tessera can decrypt a transaction, a balance or a note. Neither can a court order that compels us to try.

It's also what puts you in control of who sees your picture — including which AI you point at it. Because the decryption happens on your device, your data never leaves it in the clear, even to us.

A tended glasshouse interior, light streaming through arched glass onto established planting
The key stays on your device. Nothing leaves it in the clear.
ON THIS DEVICE
“Pension pot reached £412,900 this quarter”
Argon2id · XChaCha20-Poly1305
WHAT THE SERVER STORES
x9f3a·c1e8·77b2·04dd·ae91·5c26·b8f0·1e43·92ab·6d07·f3c9·8a51·20be·d67f·4b1c·e902·7a38·c5d4·0f66·91e2

No one at Tessera can decrypt it. Neither can a court order that compels us to try.

The promise, in one sentence

If Tessera's database leaked tomorrow, the attacker would have nothing readable.

Every record — transactions, balances, retailers, retirement assumptions, account names, notes — is encrypted on your device before it crosses the network. The decryption key never leaves your device. The server holds ciphertext and authentication metadata; nothing else.

What we hold

  • Opaque encrypted record blobs
  • Argon2id salt + parameters
  • Public key for sealed-box invitations
  • Account auth metadata (email, last-login)

What we don't hold

  • The master password
  • Any derived key
  • Any plaintext data
  • The ability to read any record, anywhere

What that means in practice

  • Forgotten master password = lost data, by design
  • Subpoena returns ciphertext only
  • Insider compromise = nothing readable
  • Server move & restore = data still encrypted

The cryptography

Standard, audited libsodium primitives, used the way the docs intend.

There's no bespoke cryptography here and nothing home-grown — just well-understood modern algorithms, composed the way the libsodium documentation recommends.

Argon2id
Key derivation. Memory-hard, side-channel resistant. Your master password is stretched to a 256-bit key with parameters calibrated per device, so phone, laptop and desktop each spend about a second deriving the key. A brute-force attacker spends prohibitively more.
XChaCha20
-Poly1305
Symmetric encryption. Authenticated, 192-bit extended-nonce variant. Every record gets a fresh random nonce; tampering is detected on decrypt; replay protection is per-record.
X25519 sealed boxes
Cross-device sharing. A new device fetches the encrypted master key sealed to its public key by an existing logged-in device. The server passes the sealed envelope but can't open it.
BIP-39 mnemonic
Recovery you control. A 24-word phrase you write down at signup reconstructs the master key without involving Tessera. Lose both the password and the phrase and the data is mathematically unrecoverable, including by us.
libsodium
One audited library. Every primitive comes from libsodium-wrappers-sumo — nothing hand-rolled anywhere in the codebase.
CLIENT DEVICE NETWORK TESSERA SERVER Master pwd + Argon2id 256-bit key (stays here) Plain record + XChaCha20 -Poly1305 cipher.blob Stored as-is 0x8f3a1c… unreadable no decryption · · · · · TLS on top, in transit.
Records are encrypted on your device, before TLS applies at all. TLS is the outer layer; the encryption underneath is what actually protects the data.

Threat model

Where the wall holds. Where it doesn't.

Tessera defends against the kinds of breach that make the news. It can't defend against everything — the columns below set out exactly where the line falls.

What Tessera prevents

  • Database breach. A full dump returns ciphertext blobs only.
  • Compromised employee. A Tessera engineer with full server access cannot read a single record.
  • Subpoena / lawful intercept. We have nothing decryptable to hand over.
  • Cloud-provider compromise. AWS/Azure/GCP cannot read what we cannot read.
  • Man-in-the-middle. TLS + end-to-end encryption mean intercepted traffic is twice-protected.
  • Server-side malware. Persistent compromise of the API server reveals only ciphertext.

What Tessera can't prevent

  • Compromised device. Malware on your laptop or phone with the session unlocked can read what you can read.
  • Master password shared with attacker. If you're phished into handing over your password, no architecture can help.
  • Forgotten password and lost recovery phrase. The data is mathematically unrecoverable, including by us. That's the deliberate cost of no one else holding the key.
  • Side-channel on the user's device. Screen capture, keylogger, shoulder surf — outside the platform's reach.

Compliance & data protection

UK data residency. GDPR by design. Zero-knowledge underneath.

The posture comes straight out of the architecture: because we can't read your data, most of the hard questions answer themselves.

UK GDPR

Data minimisation is structural: we cannot store more than we can read. A subject access request returns your encrypted record set — you hold the key that decrypts it. Right-to-erasure is a single request.

UK data residency

All Tessera infrastructure runs in UK regions. Your data doesn't cross borders unless you explicitly enable an international integration.

Zero-knowledge by default

The whole model rests on encryption you control. We hold ciphertext and nothing else — the threat model above sets out exactly where that line falls.

Independent audit

Coming Soon SOC 2 Type II and ISO 27001 audits scheduled for completion ahead of general availability.

Penetration testing

Coming Soon Annual third-party penetration tests, with summary reports published as they complete.

For advisers

Inviting an adviser in? The same architecture supports their Consumer Duty, SM&CR and MiFID II obligations — with data extracted via an authenticated bridge you control, never ours. More on the advisers page.

How Tessera differs

Zero-knowledge is the structural feature the data-hungry can't match.

Most money apps and aggregators assume the vendor can read your data — it's how their reports, ads and AI features work. Tessera starts from the opposite assumption. That makes a few features harder for us to build, and a few of ours impossible for them to copy.

Question
Tessera
Typical money app
Can the vendor read your transactions?
✓ No, ever
Yes — that's the model
If subpoenaed, does the vendor have data to hand over?
✓ Only ciphertext
Yes — full plaintext
Could a rogue employee export your data?
✓ Not readably
In principle, yes
Where does data live?
✓ UK regions only
Often mixed / unclear
Server-side AI on your data?
Not possible (deliberate)
✓ Possible — including by accident

The last row is the real trade-off, and it's deliberate: server-side AI that needs plaintext can't run on Tessera. We do AI on your device instead, local-first, so your data never crosses the network unencrypted — which is exactly what lets you point your own AI at your real numbers. Your data, any AI, none of it leaked.

Private by construction

Start a picture only you can read.

Create your account, and everything you bring in is encrypted on your device before it ever reaches us. No one at Tessera can read it — that's the whole point.

Create your account