Who Can Actually Read Your Money? A Budgeting App Security Teardown

The Question Worth Asking

A database backup is not dramatic. It does not wear a black hoodie. It does not type in green letters. It sits in object storage with a timestamped name, looking bored and harmless, until the wrong person has a copy.

That is the budgeting-app security question I care about: if someone walks out with a copy of the database, can they read your money?

Not your password. Not your bank password. Your money: transaction amounts, merchants, balances, holdings, debts, account names, the little trail of ordinary life that makes a budget useful and weirdly intimate. Rent. Payroll. Therapy. Kids. The subscription you keep meaning to cancel. The grocery store you only visit when you are trying to become a different person.

Most security pages answer a smaller question. They say the data is encrypted at rest. That can be true and still not answer the backup question. “Bank-level security” is worse. It is a phrase, not a control. Banks get breached. Some also have excellent security teams. Both things can fit in the same sentence without the universe tearing.

So this is the teardown: what YNAB publishes, what Monarch publishes, and what Forbidden Finance says about its own design at our security page and security docs. Nobody here is guessing at anyone’s architecture. We can only go on what each company publishes, ours included.

TL;DR

• Encrypted at rest can mean the disk is protected, while database rows are still readable to the running app.
• Forbidden Finance seals financial fields under per-account keys, so a stolen database copy is useless without also breaking into the separate key service.
• Monarch has the audit badge we do not; we publish a database-design answer their page does not describe.

What Encrypted At Rest Actually Protects You From

“Encrypted at rest” sounds like the end of the conversation because the words are good words. Encrypted. Rest. Very calm. Put them beside a lock icon and the compliance mist rolls in.

The problem is that encryption has layers. OWASP breaks storage encryption into places like the application, database, filesystem, and hardware, and says the right layer depends on the threat model. That last phrase is the whole game. If your threat model is stolen hardware, disk or hardware encryption is doing useful work. If your threat model is a remote compromise of the server, that same layer does not magically save you.

A normal app process needs to read the data. If the database engine, filesystem, or disk decrypts data transparently for that process, then a valid database query can still return readable values. That is not a scandal. It is how a lot of systems work. It is also why “encrypted at rest” is not the same as “a copied database is useless.”

Think of it as the difference between a locked filing cabinet and a form where the salary field is written in cipher text before it ever reaches the cabinet. If someone steals the cabinet, the lock matters. If someone gets the office key and photocopies the forms, the lock is having a quiet day.

For a budgeting app, the interesting fields are not abstract. They are amounts, merchants, descriptions, balances, holdings, and liabilities. If those fields exist in plaintext columns, then a leaked backup or one ugly SQL-read bug can expose them. If those fields are sealed before storage under keys that are not in the database, a database copy reveals structure and ciphertext, not the money.

That is the disk-versus-row distinction. It is not a purity contest. It is a design choice with trade-offs.

What YNAB And Monarch Publish

YNAB and Monarch are serious products. Plenty of people use them happily, and this is not an attempt to turn personal finance software into a cage match. The honest thing is to read their own pages and stop there.

YNAB says, “We use industry standard data encryption at rest and in transit.” The same page says YNAB “does not view or store your bank credentials” and describes bank connections through financial data aggregation specialists, including OAuth where the bank supports it.

Monarch says, “All data is covered at rest and in transit.” It also publishes a second-factor detail: “One-time passcodes (OTP) when logging in from unrecognized devices.” On audit, Monarch says “Independent auditors have verified” its security standards, which is the SOC 2 statement on the page.

Now the part that costs us something to write. Monarch is SOC 2 audited. Forbidden Finance is not, and we hold no ISO 27001 certificate either.

That gap is a money gap rather than a philosophical one. A Type II audit runs well into five figures before an auditor tests a single control, and at our size that is a quarter of roadmap instead of a line item. So we did the next most useful thing and built to the controls the audit asks about. Per-account encryption is in the product partly because it answers the access-control criteria an auditor would go looking for. When we are big enough that the audit is an expense rather than a trade-off, we will go and get it. Until then we would rather describe the design and let you check it than imply an assurance nobody has given us.

One thing worth being exact about, because it cuts against us as easily as for us: SOC 2 does not require any of this. A company can hold a clean Type II report and still keep every transaction amount in a plain database column. The audit asks whether an organization does what it says it does, not whether it encrypted your grocery bill. None of the audited security pages we read say which way they went, because nothing obliges them to say. That silence is the whole reason this comparison is worth running.

SOC 2 is a real attestation over controls at a service organization, relevant to areas like security, availability, processing integrity, confidentiality, and privacy. It is valuable, expensive, and useful for buyers who need third-party assurance. It is not, by itself, an answer to whether customer financial fields are encrypted per account inside the database. Different question. Different evidence.

So the fair summary is this: Monarch has an attestation Forbidden Finance does not have. Forbidden Finance has a stored-data design that YNAB and Monarch do not describe on their published security pages. You get to weigh both. That is much better than pretending one column of a comparison table can contain a religion.

Sign-In: The Second Factor Nobody Makes Optional

Stolen credentials are not exotic. Verizon’s 2025 DBIR credential-stuffing research says compromised credentials were an initial access vector in 22% of breaches reviewed in that report, and its SSO-log analysis found credential stuffing made up a median 19% of daily authentication attempts. That is not a scare statistic. It is Tuesday for anything with a login box.

In Forbidden Finance, password sign-in always requires a second factor. There is no password-only sign-in and no opt-out. The available factors are passkeys using FIDO2/WebAuthn, authenticator-app TOTP, and hardware security keys using U2F. If you have enrolled none of those, an emailed one-time code is required instead. The fallback is another factor, not a trapdoor with better lighting.

Passkeys matter here because the FIDO Alliance describes passkeys as phishing-resistant and built on public-key cryptography. In practical terms, a fake login page cannot ask your passkey to sign in to the real site, because the cryptographic ceremony is bound to the site. Passwords are gossip. Passkeys are picky.

The caveat is important. Signing in with Google, Microsoft, or Apple is different. That hands the second factor to their account-security settings, on their side, not ours. If you use social sign-in, your second factor is as strong as the one you set up with them.

Mobile biometric unlock is also not magic. It gets you back into the app without retyping a password, but it sits over an existing session. It is convenience over a session, not a replacement for login credentials.

Sessions are visible and revocable: you can list everywhere you are signed in and end any of them from another device. The web app also signs you out on its own after a short idle stretch. Privacy Mode blurs every monetary amount on the dashboard with one tap, which is useful in the very advanced threat model known as “someone behind you at lunch.”

Encryption Per Account, And The Cost Of Doing It

Forbidden Finance seals sensitive financial fields under encryption keys unique to each account before those fields are written to the database. The keys live in a separate, dedicated key service. A database copy by itself reveals structure, sealed blobs, and key references. It does not reveal your transaction amounts, merchant names, descriptions, account balances, investment holdings, or liability balances.

This is the kind of claim that should be boringly inspectable, so here it is: the transactions table has no plaintext amount column, no merchant column, and no plaintext description column. They do not exist. Not hidden. Not politely discouraged. Absent.

This is not end-to-end encryption. It is not zero-knowledge encryption. Forbidden Finance can unseal your data while your account is live, which is what lets the app show you your own numbers on a new device without making you carry a key around like a tiny treasurer. The design is aimed at a different failure mode: a stolen database copy, a leaked backup, or a bug that reads rows it should not.

Which raises the fair question: if Forbidden Finance can unseal your data, what stops someone here from reading it?

A grant that only you can give. Staff cannot pull your financial data or your keys on their own. Support access has to be requested by a named person, with a reason and a case reference you can read, and it sits inert until you approve it. You choose how long it lasts. You can end it early, and it expires on its own if you forget. Every request, approval, refusal and revocation lands in an audit trail.

None of that is a policy document, which is the part that matters. The grant is re-checked on every single call before anything is decrypted, and the credential that authorizes the read is scoped to one account and measured in seconds. Ordinary staff credentials, on their own, decrypt nothing.

OWASP is blunt that key-management systems add protection and also add complexity and administrative overhead. Correct. This is why most budgeting apps do not work this way. Once amounts are encrypted at the column level, the database can no longer sum, filter, or aggregate them. PostgreSQL cannot add ciphertext into a budget report and call it a month.

So Forbidden Finance decrypts rows in memory and does the arithmetic there, on every report and every budget screen. It costs compute. It complicates engineering. It makes ordinary product work less convenient. We pay that tax because the alternative is keeping the juiciest fields readable where a database query can reach them.

There is another database boundary too: PostgreSQL row-level security binds every row to an account and enforces that boundary inside the database engine, not just in application code. Hundreds of policies, across every table that holds customer data. Row-level security is not a substitute for encryption, and the reason is worth stating: it governs queries against a live database, and a stolen backup file is not a query. That is precisely why the encryption sits underneath it.

Deletion has a similar shape. Account deletion starts a 30-day recovery window. When it ends, the data is permanently deleted and the account’s encryption keys are destroyed, rendering the encrypted data unreadable everywhere it exists, including backups. A row delete cannot reach every backup. Key destruction can.

If you like envelope budgeting because the boundary is visible, the same design instinct shows up in The Envelope Method, Modernized: Cash-Stuffing for People Who Don’t Use Cash. Boundaries are not just for spending categories. They are for data too.

Sharing Without Over-Sharing

Household budgeting is where privacy slogans usually go to have a small accident. Real couples and families do not fit one permission model. Some people share everything. Some share rent, groceries, and the kid’s braces while keeping gifts, therapy, or personal spending private. Grown-up software should survive grown-up boundaries.

Forbidden Finance sharing does not hand over your key. For each shared row, that row’s data key is re-wrapped under the recipient’s own key and stored as an explicit, individual grant. The recipient decrypts with their key, not yours.

That sounds small until you compare it to the lazy model: copy the data into a shared space, broaden a role, and hope nobody regrets it. In Forbidden Finance, sharing is opt-in per account. You choose exactly which accounts each person sees, and nothing else crosses over. You share a budget to work on together, and each person keeps a private budget of their own.

Grants are explicit and revocable. Sharing is something you do, not something that happens to you.

This is the money version of a good relationship boundary. If you are working through the human side, The ‘Money Date’ Script: 30 Minutes a Week That Will Change Your Marriage is about the conversation. This section is about making sure the database does not silently decide the conversation for you.

The New One: Letting An AI Assistant See Some Of Your Money, Not All Of It

Forbidden Finance now has a public REST API and a hosted MCP server on the Premium tier. Either one lets you connect an application, or an AI assistant, to your own account.

The same database-copy question moves one layer out: if you give an assistant access, what can it actually read?

Authorization uses OAuth 2.1 authorization-code with PKCE. Access tokens are opaque and stored only as SHA-256 hashes, not signed tokens handed out for later inspection. There are 16 scopes, and the consent screen shows exactly what an application asked for. Read scopes are pre-checked. Write scopes are not.

Writes require two switches. A connection needs a write scope and a separate per-connection “allow changes” opt-in. Widening what a connection can do requires re-consenting. This is boring on purpose. Boring consent is good consent.

The more interesting piece is field-level redaction. Beyond scopes, you can withhold 17 individual fields from a given connection: merchant name, description, amount, tags, check number, external reference, account name, account number mask, balance, institution, connection error message, holding name and ticker, holding value, liability name, liability balance, goal name, and goal description.

That means an assistant can be allowed to see category-level spending without merchant names, or transactions without amounts. It also means the system has to care about inference, because arithmetic is rude. If you hide transaction amounts or account balances, Forbidden Finance automatically disables surfaces that would leak those values back by math, such as net worth and insights.

Account exclusion is designed the same way. An excluded account returns a response byte-identical to one for an account that does not exist. Not “access denied,” which would confirm it exists. Nonexistent and excluded look the same.

Refresh tokens rotate and are single-use. If an old refresh token is replayed, every token on that connection is revoked and the user is notified. Connections can be revoked instantly from the app. Data shared with a partner is structurally unreachable through the API: an assistant sees only the account holder’s own data, never a partner’s, regardless of scopes.

This matters if you use net-worth views or planning tools. How to Calculate Your Real Net Worth (and What the Number Actually Tells You) is useful precisely because the number is revealing. A good API treats that revelation as something you consent to, not as a side effect of asking a chatbot to summarize your month.

What We Still Do Not Have

Here is the part security marketing usually saves for a PDF, or never says unless sales is trapped on a call.

Forbidden Finance is not SOC 2 certified. It is not ISO 27001 certified. Controls are built and documented with a future audit in mind, but no audit has been performed and no observation window has begun. An independent, human-led penetration test is scheduled ahead of full launch. It has not happened yet.

The founder has a professional penetration-testing background. That is useful. It is a reason to expect good instincts, sharper threat models, and fewer embarrassing defaults. It is not third-party verification. “Built by a pentester” is a starting point, not an assurance. Please do not let anyone sell you vibes in a blazer.

Monarch’s SOC 2 statement matters. AICPA describes SOC 2 reports as assurance about service-organization controls relevant to the trust services categories. That is a real answer to the control question. It is not the same answer as per-account column encryption of stored financial fields. A reader deserves both answers side by side.

Forbidden Finance also publishes its Privacy Policy and sub-processor list. The business model is subscriptions, not advertising. There is no advertising SDK in the app, no advertising identifiers collected, no data brokers, and no sale or sharing for cross-context behavioral advertising as those terms are defined under CCPA/CPRA. Marketing-site analytics are consent-gated and pageview-only. Inside the app, there are no third-party ad trackers on any tier. Every tier, including Free, can export a complete archive of transactions, budgets, and account data. Account deletion is self-serve.

That connects back to Why We Built Forbidden Finance: A Personal Finance App That Doesn’t Shame You. Privacy is not a decorative feature for people with something to hide. It is part of making financial software that does not turn your life into a targeting profile or a lecture.

The 403 joke is that forbidden means forbidden. On a normal page, that is wordplay. On a security page, it becomes a design requirement.

So ask every budgeting app the backup question. Ask us too. If someone copies the database, can they read your money? If the answer is a paragraph about encrypted disks, keep asking. The real answer lives lower down, where the rows are.