Security

Money Actually reads your financial data and never moves your money. There is no transfer function in this application, so no attacker who compromises it can move funds. What they could see is your account history, and the rest of this page is about preventing that.

We describe mechanisms rather than adjectives. Where a control is partial, it says so.

1. Bank credentials never reach us

Connections are made through Plaid Inc. You authenticate directly with your bank, and for most institutions that happens on the bank’s own domain via OAuth. Money Actually never receives, stores, or transmits your banking username or password. What we hold is an access token that permits read-only retrieval, and that token is encrypted at rest with AES-256-GCM under a key held outside the database.

2. Your data is separated from everyone else’s, twice

The application reads your identity only from a cryptographically signed session cookie, never from a parameter in the request. That is the primary boundary.

Behind it, the database enforces the same rule independently. Every table carrying user data has row-level security, evaluated by a database role that is not permitted to bypass it, with the identity scoped to a single transaction. A query that fails to establish who is asking returns zero rows rather than everything. Cross-tenant references are additionally impossible by schema: the foreign keys are composite, so a record cannot point at another person’s data even in principle.

This is verified rather than asserted. A test suite runs cross-tenant attacks twice, once with the protection disabled to confirm the attack genuinely works, and once with it on.

3. Accounts

• Passwords are hashed with scrypt using a per-user salt, and compared in constant time. We cannot read your password.
• Two-factor authentication (TOTP) is available in Settings, with ten single-use recovery codes issued at enrolment.
• Signing in with a second factor enrolled issues only a short-lived half-session; the real session begins after the code is verified.
• Authentication endpoints are rate limited.
• Google and Apple sign-in are supported, where the second factor belongs to that provider.

Stated plainly: two-factor authentication is offered, not required. Forcing enrolment would lock out anyone who did not complete it. We recommend turning it on.

4. Transport and browser hardening

• HTTPS everywhere, with HSTS set to two years including subdomains.
• The database is encrypted at rest with AES-256 by our database provider, Neon, and the connection to it uses TLS. The layer described in section 1 sits on top of that, under a key of our own.
• A Content Security Policy with a per-request nonce: a script this app did not put on the page does not execute, and network connections are limited to this origin and Plaid, so injected code has nowhere to send data.
• Framing is denied outright, which removes clickjacking.
• Form submissions and the document base URI are locked to this origin.
• Camera, microphone, geolocation and payment browser APIs are switched off at the header level; the app has no use for any of them.

5. Vulnerability management

Dependencies are scanned continuously, and the build fails on any high or critical advisory rather than merely reporting it. Published response times: critical within 3 days, high within 7, moderate within 30.

6. Access to production

One person operates this service. Every administrative console reached to do so requires multi-factor authentication. Credentials live in encrypted environment storage and are never committed to the repository. Access is reviewed on a quarterly schedule.

7. Your control over the data

• Disconnect any bank at any time; that connection is revoked at Plaid immediately.
• Delete your account from within the app. Plaid connections are removed at Plaid first, which revokes the ongoing grant, before local records are erased.
• Export your transactions as CSV whenever you want.
• See and revoke every app you have connected through Plaid, not only this one, at my.plaid.com.

8. AI, and only when you ask

AI only when you ask. Nothing is sent unless you type a question to Slip, and you can turn Slip off.

• The only place an AI model is used is Slip’s question box. Nothing runs in the background, on a schedule, or when you open a page. Categorization and recurring detection run on our servers without any model.
• The first question stops and asks for your OK before anything is sent. The OK is recorded on your account, and the server refuses a question from an account without it.
• A question sends your question and a summary of your figures to Anthropic: balances, what you owe, spending by category, budgets, recent monthly totals and your last 40 transactions. Never your name, email address, or an account or card number.
• The model can only write a reply. It has no tools and cannot change anything in your account, and nothing in this product can move money.
• Every dollar figure in a reply is checked against the figures that were sent. A reply quoting any other amount is thrown away before you see it.
• We keep no record of what you asked or what Slip answered, and errors are logged without the question or any figure in it.
• Hide Slip in Settings and the question box goes with it.

Anthropic handles what it receives under its own privacy policy, and the full list of what is sent is in section 5 of our privacy policy.

9. Reporting a vulnerability

If you find a security problem, email support@moneyactually.app with enough detail to reproduce it. We will confirm receipt within three business days. Please do not access, alter or retain data belonging to another person while investigating, and give us a reasonable chance to fix the issue before publishing it. Good-faith research reported this way is welcome and will not be met with legal action.