A year of your transactions is a more honest record of your life than most journals. It shows where you were and when, who you sat across from at dinner, what you were worried about in March, the month things got tight, the week you finally gave more than you’d planned to. Every budgeting app is holding some version of that record about you right now, and the question worth asking isn’t whether it’s encrypted. It’s who holds the key.

Most apps will tell you your data is “encrypted at rest,” which is both true and less meaningful than it sounds. Encrypted at rest means the company scrambled your data before storing it and kept the key to unscramble it. The lock is real, but they’re the ones holding the key, so a curious employee or a subpoena or a breach that reaches that key is all it takes for the lock to open. Your data was never really out of their reach. It was behind a door they could always open.

I didn’t want to be able to open that door. So the goal I set for Carlo’s encryption was easy to state and harder to build: I shouldn’t be able to read your data even if I wanted to, or even if someone made me. The industry term for this is end-to-end encryption, and the plain version is that the only person who can unlock your data is you.

Here’s how it works, first as a picture and then as the real thing.

The lockbox

Imagine your data lives in a safe. Every transaction, every note, every photo, every Sunday reflection is locked away separately inside it, and a single key opens all of them. Call it the safe key.

You could just carry the safe key around, but a safe key is awkward to live with. Since that one key locked every record separately, changing it would mean unlocking and re-locking each one, which for a year of data is slow and risky. So instead of carrying the safe key, you do something smarter: you put it inside a small lockbox, and you lock the lockbox. The thing that opens the lockbox is a separate key, and that one is your master key. It never touches your data. All it does is open the lockbox that holds the safe key.

That’s the whole design. Carlo holds the locked lockbox, you hold the master key, and the lockbox can sit on a server all day without giving anything away, because the only thing inside it is another key that the server has no way to open.

The same thing, technically

The safe is your data, encrypted field by field with AES-256-GCM, the same algorithm Signal, Apple, and most modern secure messaging rely on. Rather than scrambling the whole database into one blob, Carlo encrypts each sensitive field on its own — an approach called field-level encryption — so the amount, the payee, the note, the photo, and the reflection are each stored as ciphertext that’s meaningless without the key.

The safe key is what I call the DEK, the data encryption key. It’s 32 random bytes generated for you and only you, and it’s the thing that actually encrypts and decrypts your transactions.

The lockbox is that DEK wrapped — meaning encrypted — by your master key. This wrapped version is the only form of the key that lives on the server, and on its own it does nothing.

The master key is another 32 random bytes, and it’s the part that makes the whole thing honest, because it never lives on the server at all. It lives in your own iCloud Drive on iPhone, or your Google Drive on Android, in a small file that only your account can reach. You also get a copy during setup, either as a QR code or as twelve words you can write down, whichever you prefer, and that copy is your master key in a form you can hold in your hand. Carlo never sees it, never stores it, and never has it.

So when the server is sitting there holding your encrypted data alongside your wrapped DEK, what it’s really holding is a locked safe and a locked lockbox and nothing at all that opens either one.

Those two things — the encrypted fields and the wrapped DEK — are also what travels over the wire when your phone syncs, and they’re protected on two levels. The connection to the server runs over HTTPS, so the whole exchange is wrapped in transport encryption, the same layer that secures any reputable service. Underneath that, the sensitive parts are already ciphertext before they ever leave the server, so even if the transport layer were somehow stripped away, what crossed the wire would still be a locked safe and a locked lockbox rather than anything readable. For most apps that transport layer is the only thing standing between your data and an eavesdropper, whereas here it’s a second precaution rather than the only one.

There’s one more piece, and it’s about speed rather than secrecy. Once your phone has opened the lockbox a single time and has the safe key in hand, it keeps that key in the phone’s secure storage — the iOS Keychain or the Android Keystore — so the app doesn’t have to repeat the whole ritual every time you open it. The key stays in your pocket, on your device, protected by your device, and it clears when you sign out.

Why two keys instead of one

The two-key arrangement looks like extra work, and it earns its keep in two ways.

The first is that it lets you change your master key without disturbing your data. If you ever suspect your recovery backup has been seen, you make a new master key and lock the safe key inside a new lockbox. The safe key itself never changed, so every transaction you’ve ever logged stays valid and nothing has to be re-encrypted.

The second is for later. When Carlo eventually lets two people share a budget, both of them will need to read the same shared safe, but neither should be able to control the other’s recovery. The lockbox pattern handles this without any mess, because the same safe key can go into two different lockboxes, each one opened by a different person’s master key, so the data is shared while control stays separate. I built the foundation for that now so there’s nothing to tear up later.

What this feels like on a new phone

You get a new iPhone and install Carlo, and you sign in. Behind the scenes, the app looks in your iCloud Drive, finds your key file, reads your master key, pulls the wrapped DEK from the server, opens it, and starts showing you your transactions. You see a moment of loading and then your data, and you were never asked to do anything, because your master key was already where it belongs, with you.

If you’re moving from iPhone to Android, your old key file is in iCloud while your new phone is looking in Google Drive, where there’s nothing yet, so Carlo asks you for your recovery backup instead. You type the twelve words or scan the code, the app rebuilds your master key, writes it to your Google Drive so the phone works automatically from then on, and unlocks your data. This is the one moment that backup earns its keep.

What this does and doesn’t protect

I try to be honest about the edges, because privacy claims that pretend to be absolute are usually hiding something.

End-to-end encryption means that a breach of the database hands an attacker locked safes and locked lockboxes, and a subpoena produces the same. I can’t hand over what I can’t open, and I made sure I can’t open it, which is the part that’s genuinely true and genuinely rare in this category.

What it doesn’t do is remove every party from the picture. Your master key sits in your iCloud or Google Drive, which means you’re trusting Apple or Google with that file, the same trust you already extend to them for your photos and your documents. That’s a different boundary than trusting me, and for most people a more comfortable one, but it isn’t nothing, and I’m not going to pretend it is.

There’s one feature worth naming here, since it’s the exception to the encrypted-storage story. Voice entry has to send your spoken transaction off the device to be transcribed and parsed into fields, so it follows a different path with its own privacy design rather than the one described above. I wrote about how that works separately, here.

There’s also a real cost to being the only one who holds the key. If you lose your recovery backup and you also lose access to your cloud storage, I can’t get your data back, because there’s no reset link I can send you. A reset link would mean I had a way in, and the entire point is that I don’t. Real privacy and a company-held safety net are the same feature pointed in opposite directions, and I chose the one that’s actually yours, which is why I’ll ask you to keep your recovery backup somewhere secure, whether that’s the QR code or the twelve words.

The cryptography isn’t really the point. The point is the thing underneath it, which is that your financial life is the most revealing record you keep, and it should answer to you and to no one else, including the person who built the place you keep it.