Security & privacy

Zero-knowledge by construction.

A place to discuss someone's whole financial life has to be private. Each client's data is encrypted on their device with a key derived from a master password we never see. The server stores ciphertext only. No one at Atrium can decrypt a transaction, a balance or a note. Neither can a court order that compels us to try.

For an FCA-regulated firm, that makes data handling far simpler to explain to clients.

A tended glasshouse interior, light streaming through arched glass onto established planting — The glass keeps the climate. The keys stay with the gardener.

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 Atrium can decrypt it. Neither can a court order that compels us to try.

The promise, in one sentence

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

Every record — transactions, balances, retailers, retirement assumptions, account names, notes — is encrypted on the client before it crosses the network. The decryption key never leaves the client. 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. The client's 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 the client controls. A 24-word phrase they write down at signup reconstructs the master key without involving Atrium. 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.

Records are encrypted on the client, 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.

Atrium 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 Atrium prevents

Database breach. A full dump returns ciphertext blobs only.
Compromised employee. An Atrium 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 Atrium can't prevent

Compromised client device. Malware on the user's laptop or phone with the session unlocked can read what the user can read.
Master password shared with attacker. If a client is phished into handing over their 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

FCA-aligned. Consumer Duty-ready. GDPR by design.

Atrium was built for UK advice firms from the start. The regulatory posture comes straight out of the architecture.

FCA & Consumer Duty

Atrium's whole-household view directly supports Consumer Duty's "consumer understanding" outcome — clients see their financial life clearly, not just their portfolio. Audit-quality activity logs available to your compliance team.

GDPR

Data minimisation is structural: we cannot store more than we can read. Subject access requests return the encrypted record set plus any decryption support your firm chooses to provide. Right-to-erasure is a single API call.

MiFID II reporting

Reporting export hooks designed for the formats your back-office team already produces. White-labelled per firm; data extracted via your firm's authenticated bridge, not ours.

UK data residency

All Atrium infrastructure runs in UK regions. No data crosses borders unless your firm explicitly enables an international integration. In a shared atrium, zero-knowledge means even a neighbouring firm's data is unreadable; in your own atrium, you also get single-tenant physical isolation.

Independent audit

Coming Soon SOC 2 Type II and ISO 27001 audits scheduled for completion ahead of general availability. We'll publish reports on request to firms in active evaluation.

Penetration testing

Coming Soon Annual third-party penetration tests, with summary reports available under NDA to firms with active deployments.

How Atrium differs

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

moneyinfo, Plannr, Wealthcraft and the rest assume the vendor can read the data — it's how their integrations, reports and AI features work. Atrium 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

Atrium

Typical vendor

Can the vendor read client 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 client data?

✓ Not readably

In principle, yes

Where does data live?

✓ UK regions only

Often mixed / unclear

Server-side AI on client data?

Not possible (deliberate)

✓ Possible — including by accident

The last row is the real trade-off: server-side AI that needs plaintext can't run on Atrium. We do AI on the client instead, local-first, so the data never crosses the network unencrypted. For most firms that's the right shape.

Have a security or compliance team?

We'll meet them on the demo call.

Bring your IT lead, your compliance officer, your DPO — we'll walk through the architecture, hand over the threat model, and answer the technical questions head-on. NDAs available on request.

Book a security walk-through →