Most finance apps put “we respect your privacy” somewhere in a settings menu, next to a 4,000-word policy nobody reads. We wanted to write something different: a plain explanation of what Amunta actually does with your data, verified against the app’s own source code rather than against a marketing brief.
The default: nothing leaves your phone
Amunta’s ledger — expenses, income, debts, invoices, budgets, reports — is stored in a local database on your device. There is no sign-up screen, no email field, no phone number required to start using the app. You open it, and it works.
Amunta contains no advertising trackers, Google Analytics or Facebook SDK. Limited anonymous technical diagnostics may be sent to improve stability; they contain no amounts, financial records, contacts or photos and cannot identify you as a person.
A PIN lock is available if you want one. When you set a PIN, the app stores a SHA-256 hash of it, not the PIN itself — the same approach used for password storage on any system that takes security seriously. If someone got access to the raw app data, they wouldn’t find your PIN sitting in a file.
The optional part: sharing a ledger with someone else
Amunta also lets two people link their accounts — useful if you and a partner, a roommate, or a business contact want to share a running tab without each of you re-entering the same transaction. This is opt-in. The base app never asks for it.
When you do turn it on, here’s exactly what happens, because we think “exactly what happens” is a more honest answer than “we take your privacy seriously.”
To get a network ID (it looks like SF-XXXXXXX), your phone generates a cryptographic key pair and sends a registration request containing three things: the public key, your selected currency, and a flag indicating the app tier. That’s the entire payload. No name. No phone number. No email address. If you’ve typed a phone number or email into the app elsewhere, those stay in local storage on your device — they aren’t part of this request.
What encryption actually means here
Once two people are linked, shared transactions sync between their phones through a relay server. This is where “end-to-end encrypted” either means something specific or it’s just a phrase. In Amunta’s case, it’s specific:
- Each device has a key pair. When sending a transaction to a linked contact, the two public keys are combined using X25519 elliptic-curve key exchange to produce a shared secret.
- That shared secret is run through HKDF-SHA256 to derive a stable encryption key.
- The transaction data is encrypted with AES-256-GCM before it ever leaves the device.
The private key never travels anywhere. It’s generated on-device, stored in the device’s secure storage, and used locally to do the math that produces the shared secret. It is not sent to the relay, not sent to the other person, not recoverable from anything that crosses the network.
The part most “encrypted” claims leave out
Here’s where we want to be more careful than most apps bother to be. The relay server that passes messages between linked devices cannot read what’s inside them — the content is AES-256-GCM ciphertext, and the relay doesn’t hold the key. But the relay does see routing information: which network ID sent a message, which network ID it’s addressed to, and when it was sent. That’s unavoidable in any system where a server has to deliver a message to the right recipient — it’s the same tradeoff Signal and similar systems make.
The relay also doesn’t keep the message as an archive. The encrypted payload is held only until the receiving device confirms it arrived and was processed, then it’s deleted for good. If it’s never delivered, or the confirmation never comes back, it expires and is deleted automatically after 24 hours.
So the accurate sentence is: the relay can see who is talking to whom and when, but not what was said. Anyone claiming a synced feature where the server sees literally nothing is usually describing something that doesn’t route messages at all, or being imprecise about what “nothing” means.
Why this matters more than a privacy policy
A privacy policy is a promise about behavior. It can change, get reinterpreted, or simply not match what the code does. What we’ve described above isn’t a promise — it’s what the architecture makes possible or impossible. The app can’t send your contact list to a server it never talks to. It can’t leak transaction contents through a channel that only ever carries ciphertext. The PIN can’t be extracted as plaintext from a hash.
That’s the difference we think is worth caring about: not whether an app says the right things about privacy, but whether its actual design leaves room for the wrong things to happen.