End-to-end encryption in expense splitting apps: a practical guide

Most expense splitting apps store your trip data — who paid for what, with whom, where and when — in plain readable form on their servers. This is fine if you trust the operator forever. It is less fine if the operator suffers a breach, is acquired, changes its privacy policy, or is compelled by a court order to hand over your trip ledger. End-to-end encryption (E2EE) is the technical answer to that risk: the data is encrypted on your device before it reaches the server, and the server stores opaque ciphertext that even the operator cannot read. The catch: E2EE in 2026 is still rare in the expense splitting category, and the privacy claims of the major apps are easy to misread. This guide is the practical version.

“E2EE is the kind of feature that doesn’t matter until it does. The moment you realise your trip data — names, amounts, locations — is sitting in plaintext inside a company’s database, you can’t unsee it.” — Albert Ripol, founder of TripCount

What E2EE actually means

End-to-end encryption is a precise technical claim. It says:

1. The encryption key is generated and held by you (or by your group), not by the service.
2. Data is encrypted on your device before it is transmitted to the server.
3. The server stores ciphertext only — bytes it cannot decrypt without the key.
4. Decryption happens on the receiving device of another group member who has the key.

If any of these is missing, it isn’t E2EE. The most common confusion: “encrypted at rest” or “encrypted in transit” are both useful and both far weaker than E2EE. Encrypted at rest just means the operator’s database files are encrypted on disk — but the application reading those files holds the key, so the operator can decrypt your data at will. Encrypted in transit (HTTPS) only protects the bytes between your phone and the server; once they arrive, the server reads them in cleartext.

Some apps describe themselves as “secure” or “GDPR-compliant” without claiming E2EE. Those terms refer to different (and weaker) properties. A GDPR-compliant service has data-protection processes; it does not necessarily hide your data from itself.

What E2EE buys you (and what it doesn’t)

E2EE protects against:

• Cloud breaches — when an attacker exfiltrates the operator’s database, they get ciphertext, not your expense ledger.
• Insider abuse — a staff member with database access cannot read your trip.
• Compelled disclosure — court orders requesting “all of [user]‘s data” return ciphertext only.
• Operator changes — acquisitions or privacy policy revisions cannot retroactively expose data that was already encrypted with keys the operator never held.

E2EE does NOT protect against:

• A compromised device — if your phone is rooted or you’ve installed malicious software, the local decryption key is exposed.
• Bad password / weak key derivation — if the encryption key is derived from a four-digit PIN, the search space is small enough to brute-force.
• Metadata — even when content is encrypted, the operator typically knows that a trip exists, who its members are, when expenses are added and how frequently — because that’s required for sync and notifications. Pure-anonymous expense splitting is possible but rare.
• Social engineering — if you share the trip link or invite the wrong person, E2EE doesn’t help.

The honest summary: E2EE is necessary but not sufficient for privacy. It removes one big category of risk (the operator) and leaves others (the device, the group composition, the metadata) for you to think about separately.

How to read the privacy claims of major expense apps in 2026

Below is a rough audit of the privacy claims of each major app, based on their published documentation as of May 2026. We list the category of privacy posture, not a score, because the category captures what actually matters.

App	Encrypted at rest	HTTPS in transit	E2EE expenses	E2EE photos	E2EE receipts	Notes
TripCount	yes	yes	yes (AES-GCM)	yes	yes (post-OCR)	EU-hosted (Hetzner Frankfurt)
Splitwise	yes	yes	no	no	no (US-hosted)	GDPR addendum for EU users
Tricount	yes	yes	not advertised	not advertised	not advertised	Bunq-owned, EU-hosted
Settle Up	yes	yes	no	n/a (no photos)	n/a	EU-hosted (Czech)
Splid	yes	yes	no	n/a	n/a	EU-hosted (German)
Spliit	depends on host	yes	no (hosted version)	n/a	n/a	self-hosted = depends on you
Sesterce	yes	yes	no	n/a	n/a	EU-hosted (French)

Two patterns to notice:

1. Most apps stop at encrypted-at-rest + HTTPS. This is the industry default and not bad. It does mean the operator can read your data when needed (technically and legally).
2. TripCount is the outlier on E2EE for expenses. This is a deliberate design choice and one I’d rather not be the only player on. If a competitor ships E2EE next year, I’ll celebrate it — the category is better served when multiple apps treat trip data as sensitive.

What TripCount does specifically

TripCount uses per-trip envelope keys with AES-GCM. Concretely:

1. When you create a trip, your device generates a random envelope key (K_trip).
2. K_trip is wrapped (encrypted) under each member’s public key when they join the trip — every member gets their own copy, decryptable only with their private key.
3. Expense data — payer, amount, currency, line items, photos of receipts — is encrypted with K_trip on your device with AES-GCM¹ before being sent to the server.
4. The server stores opaque ciphertext. When another member’s device fetches the expense, the server returns ciphertext; the member’s device unwraps K_trip with their private key and decrypts the expense locally.
5. The OCR pipeline is the one place data leaves the trust boundary — receipts have to be sent in cleartext to OpenAI Vision for line-item extraction. After OCR completes, the photo and extracted line items are re-encrypted before storage; the cleartext lifetime is roughly the OCR API roundtrip. Documented at /ai-transparency.

The integration test suite asserts on every CI run that no plaintext expense data appears in any stored artifact — a regression test for the property “we cannot read your trip even by accident”.

What’s still on the roadmap:

• Zero-knowledge — today we hold escrowed copies of envelope keys as a backup against device loss. The 2026 roadmap target is to remove the escrow so even we cannot help you recover a trip if every member loses their key.
• Verified third-party audit — currently the encryption claims are documented and testable but not externally audited. An audit is on the roadmap once the user base is large enough to justify it.

How to think about E2EE for your group

Three questions to ask yourself when choosing an expense app:

1. Is the trip data sensitive enough that operator access bothers you? For “split lunch with two friends” the answer is probably no. For “$8,000 family trip with three currencies and a tax-deductible business component” the answer might be yes.
2. Are you sharing trips with people who care about privacy? If even one member of the group cares, the whole group inherits that constraint — you can’t selectively encrypt one person’s view of a shared trip.
3. What’s your fallback if the operator changes? Operators get acquired, change pricing, deprecate features, fail. E2EE limits the blast radius of any of these events.

If your answers are “no / no / I’ll deal with it”, any of the apps in the table above will work. If they’re “yes”, TripCount is the option that makes E2EE the default for expense data in 2026. The TripCount vs Splitwise comparison and TripCount vs Tricount comparison cover the rest of the trade-offs.

FAQ

Q: Is end-to-end encryption necessary for an expense splitting app? A: Strictly speaking, no — most apps work fine without it. But it removes a meaningful class of risk (operator breach or compelled disclosure) at minimal usability cost. The trade-off has become “free” enough in 2026 that it’s hard to argue against E2EE if a vendor is willing to build it.

Q: How is TripCount’s E2EE verified? A: The integration test suite verifies on every CI build that no plaintext expense data leaks into stored artifacts. Source documentation is at /ai-transparency. An external audit is on the roadmap.

Q: Why don’t more expense apps offer E2EE? A: Three reasons. (1) Most apps were built before E2EE became a mainstream user expectation. (2) E2EE breaks server-side features like full-text search, in-app suggestions and analytics. (3) Key recovery is genuinely hard to design — the “lost phone” case has to be solved before you can ship E2EE confidently.

Q: Does end-to-end encryption affect performance? A: Negligibly on modern phones. AES-GCM is implemented in hardware (AES-NI on Intel, ARMv8 crypto extensions on phones) — the encryption overhead is well under a millisecond per expense. Network round-trip dominates the user-perceived latency.

Q: Can the server still read trip names or member lists? A: In TripCount today: yes for trip names and member email addresses (these need to be readable for invites and notifications); no for expense content. The category-wide pattern is similar — metadata privacy is harder and rarer than content privacy.

---

Footnotes

1. AES-GCM is the authenticated encryption mode recommended by NIST SP 800-38D (2007). It combines confidentiality (AES-CTR) with integrity (GMAC) in a single primitive, with hardware acceleration on every smartphone shipped in the last decade. ↩