Forbidden Finance · Security & privacy
Subscriptions, not surveillance
We make money when you pay for the product — never by selling your data, showing you ads, or building advertising profiles. In HTTP, 403 means Forbidden: that's our answer to "who can see my money?" Forbidden Finance is built by a security professional with a penetration-testing background, and this page is written the way we'd want a vendor to write it for us: concretely, with the trade-offs included.
Encryption that assumes the worst
Disk-level "encryption at rest" protects against stolen hardware, not a leaked database. We designed for the uglier scenario.
Your bank credentials never touch our servers
Bank connections run through regulated, bank-grade aggregation partners. Your credentials are entered with them, encrypted end-to-end by them, and never stored by us — we receive read-only account and transaction data. All connections are encrypted in transit via TLS, and sensitive credentials like bank tokens are encrypted with AES-256-GCM before storage.
Encrypted per account, inside the database
The sensitive fields of your financial data — transaction amounts, descriptions, and merchant names; account names and balances; investment holdings — are sealed under encryption keys unique to your account before they are written to our database. The keys live in a separate, dedicated key service, so a database copy on its own reveals structure, not your money.
Isolated at the database level
Every row of your data is bound to your account, and PostgreSQL row-level security enforces that boundary inside the database engine itself — not just in application code. Household sharing works through explicit, per-account grants you control.
Deleting your account destroys the keys
Account deletion starts a 30-day recovery window. When it ends, your data is permanently deleted and your account's encryption keys are destroyed — which renders the encrypted data unreadable everywhere it exists, including in our backups.
What that design means when something goes wrong
In an app that stores amounts readable in the database, one SQL-injection bug, one stolen backup, or one leaked credential exposes everything — "encryption at rest" protects the disk, not a live database connection. In Forbidden Finance, that same attacker gets ciphertext. Reading your financial data requires compromising the database and the separate key service that holds your account's keys: a full infrastructure compromise, not one lucky bug.
There's a reason most budgeting apps don't work this way: once amounts are encrypted at the column level, the database can no longer sum, filter, or aggregate them. So we do it the hard way — rows are decrypted in memory and the math happens there, on every report and every budget screen. It costs us engineering complexity and compute. We think your balances are worth it.
Sign-in built for this decade
We support passkeys for passwordless sign-in, authenticator-app (TOTP) multi-factor, and biometric unlock on mobile. You can review and revoke active sessions at any time, and Privacy Mode hides balances when someone's looking over your shoulder.
Analytics you actually consented to
The marketing site runs consent-gated, pageview-only analytics — nothing loads until you say yes. Inside the app there are no third-party ad trackers and no data brokers, on any tier. The full list of vendors that process any user data is public on our Sub-Processor List.
Sharing that doesn't overshare
Partner and household 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 of you also keeps a private budget of your own. Grants are explicit and revocable: sharing is something you do, not something that happens to you.
Your data, your exit
A privacy promise you can't leave with isn't a promise. Every tier — including Free — can export a complete archive of transactions, budgets, and account data, and account deletion is self-serve: a 30-day recovery window, then permanent deletion and key destruction. The details live in our Privacy Policy.
Security questions
No. We don't sell your data, we don't share it with advertisers, and we don't build behavioral profiles for third parties. Our business model is subscriptions, not surveillance — if we ever had to "make it up on data," the product would have failed at its one job.
No. Bank credentials are entered with a regulated aggregation partner — the same category of infrastructure that powers apps like Venmo and Coinbase — and are never stored on our servers. We receive read-only account and transaction data, not your login.
An attacker with database access — a SQL-injection bug, a stolen backup, a leaked credential — gets ciphertext for the sensitive fields, because your financial values are sealed under per-account keys held in a separate key service. Actually reading your data would require compromising the database AND the key service together: a full infrastructure compromise, not one lucky bug. That is the scenario this architecture was built around.
Not in day-to-day operations: financial values sit encrypted in the database, and decryption happens to serve you the app. When a support issue genuinely requires looking at your account, access is temporary and tied to your troubleshooting request — not a standing ability to browse anyone's transactions.
You get a 30-day recovery window in case you change your mind. After that, your data is permanently deleted and your account's encryption keys are destroyed, which renders the encrypted data unreadable everywhere it exists — including in our backups.
Yes, on every tier — the full export isn't gated behind a paid plan. Request an export in Settings and you'll receive a complete archive of your transactions, budgets, and account data.
Email security@403fin.io. Reports go straight to the founding team; we'd rather hear about it twice than not at all.