Security

Budget Factor — last updated August 9, 2026

This page summarizes how Budget Factor protects your financial data. We're a small, early-stage team, so this is a plain-language account of what's actually in place today — not a compliance certification. If you have a question we haven't answered here, or want to report a security concern, contact us using the details below.

Encryption

• All traffic between the app and our servers is encrypted in transit (TLS).
• Your data is encrypted at rest by our database provider, Supabase.

Data isolation

Every table in our database enforces row-level security: the database itself, not just application code, guarantees that a query can only ever return your household's data — never anyone else's. This is enabled on every table, for every user, with no exceptions.

By default your household is just you. If you choose to share your budget with someone — a spouse or partner — you send them a single-use invite code, and from then on you both see and can change the same budget, transactions, and connected banks. Nobody can join your household without a code you generated, codes expire after 72 hours, and either of you can leave at any time. Neither member can remove the other.

Access control

Access to production data is enforced at the database level: every table is protected by Postgres Row-Level Security, scoped to each user's own account, so one user's request can never read or write another user's financial data. Two tables that hold bank-connection credentials have Row-Level Security enabled with zero policies granted to authenticated users — they are reachable only by server-side functions running under a separate, elevated database role, never by the client app directly. API keys and secrets are stored exclusively as server-side secrets and are never included in the client app. Access to the underlying infrastructure is currently limited to a single founder, with account access itself protected by optional TOTP-based two-factor authentication. See our full Access Control Policy for detail.

Bank connections

Bank connections go through Plaid. You log in to your bank on Plaid's own screen — your bank credentials are never seen by, or available to, Budget Factor. What we receive afterward is a Plaid access token, which is:

• Stored only on our server, in a database table with no client access at all — not even indirectly through your own account.
• Only ever readable by the small set of backend functions that need it to sync your transactions.
• Never sent to, or stored on, your phone or browser.

If you share your budget with someone, bank connections are shared too: a bank either of you connects is visible to, and can be disconnected by, both of you. The access token itself remains server-only for both members.

Receipt photos

If you scan a receipt, the photo is sent to our server, read once by an AI model to extract the line items, and then discarded. We don't keep a copy — only the extracted text (merchant, items, amounts) is stored.

Account security

Two-factor authentication (TOTP, via an authenticator app) is available for every account. It's optional today, but once you turn it on, your password alone is no longer enough to sign in — a code from your authenticator app is required every time. You can enable it from Settings.

What we don't do

• We don't sell your data or share it with data brokers.
• We don't use your financial data for advertising.
• We don't store bank credentials — Plaid handles that entirely.

Where we are today

We don't yet have a formal, independently audited information security program or certification (e.g. SOC 2) — this is a new business, and that's an honest gap rather than something we're claiming to have. The practices above are real and in place today; they're just not yet backed by third-party audit. We'll update this page as that changes.

Incident response

If a security issue is identified — whether reported externally or found internally — it's triaged and handled directly by the founder: confirming and reproducing the issue, shipping a fix, and, where account access or data may have been affected, notifying impacted users by email. There's no formal on-call rotation or SLA today given the size of the team, but every report gets a direct human response, not a ticket queue.

Reporting a concern

If you believe you've found a security issue, please email us directly rather than filing a public report: davejensen175@gmail.com

See also our Privacy Policy.