End-to-end encryption, explained with your finances
July 25, 2026
A postcard can be read by anyone who carries it. A sealed letter, only by the person who receives it.
Almost every finance app sends postcards. They promise not to read them, and perhaps they comply. But a promise is a policy, and policies change: with a new owner, a new business model, or a bad day.
End-to-end encryption is the sealed letter. It is not a promise; it is a property of the architecture.
What “end to end” means
Most services encrypt your data at two moments: while it travels and while it rests on the server. That sounds good, and it is. But in both cases the server holds the key: it decrypts your data to work with it, and whoever controls the server can read it.
End to end means something else: the key is created on your devices and never leaves them. Your data is encrypted before it departs and only decrypted when it reaches you. The server stores sealed envelopes it transports and keeps without being able to open.
The difference is not technical. It is about power: who can, not who promises.
Applied to your finances
In an end-to-end encrypted finance app, your amounts, names, notes and concepts become ciphertext inside your device. What travels and what is stored is unreadable to the provider.
That has a consequence that surprises people: the server cannot add. It cannot calculate your net worth, or your totals, or detect patterns in your spending. All of those calculations have to happen where the key is: on your device.
And it has another consequence, more important: nobody can monetize what they cannot read. There are no spending profiles to sell and no “aggregated, anonymized data” to share, because there is no data to aggregate.
What changes in practice
In a breach, an attacker finds sealed envelopes. Without your keys, your figures stay unreadable.
Against curiosity, an employee with database access sees ciphertext. Trust stops depending on the virtue of people you have never met.
In the business model, the architecture decides before the market does: an app that cannot read your data cannot live off it. It has to live off serving you.
And in the trade-off, which also exists: if you lose your passphrase and your recovery key, nobody can restore your data. Nobody means nobody. It is the exact price of nobody else being able to open it.
Four questions for any finance app
If an app is going to hold your financial life, it deserves four questions:
- Who holds the keys? If the answer includes the provider, your data is a postcard.
- What exactly does the server see? The honest answer is never “nothing”. Metadata, dates, record types: ask for the concrete list.
- What would happen in a breach? Not whether it can happen, but what would be exposed when it does.
- How is it financed? If you are not paying, it is worth understanding who is, and with what.
A serious app answers all four without discomfort.
Prisvera is built on this architecture. On the security page we answer those four questions, including the honest list of what our servers can see, because honesty is part of security too.