Security

enMoney holds a household's whole financial picture, which is worth more to an attacker than any single account statement. This page says what protects it, who can read it, and — at the bottom — what is not true yet. It is written so you can check it rather than trust it.

Database — PostgreSQL on Supabase, encrypted at rest, reached only over TLS.

Separation between accounts — Every table carries row-level security keyed to your user id, enforced by the database rather than by application code. A query that forgets to filter by user returns nothing instead of returning someone else. Shared access exists only where you create it — a partner you invite, or an accountant link you generate.

Uploaded documents — Receipts, payslips and statements sit in private storage, never world-readable. The app hands your browser a signed link that expires in an hour; there is no public URL to guess or to leak in a referrer. Broker and fund statements imported on the Investments page are not stored at all — they are parsed in memory and dropped, and only the transactions survive. That is true whether the file was read by our own code or, for a PDF format we do not recognise, by Gemini.

Backups — Taken nightly, encrypted, and — the part most backup claims leave out — restored on a schedule to prove they can be. A backup nobody has ever restored is a hope, not a backup.

enMoney reads holdings and trades so it can check them against what you have imported. It has no code path that places an order or moves money, and it never asks for a payment instrument.

Interactive Brokers — A Flex Web Service token, which is read-only by design — reports out, nothing in.

Groww — The read APIs enMoney calls are the free tier. Placing orders through Groww requires a separate paid trading subscription that enMoney does not use and does not ask you to buy. If you hold that subscription for your own reasons, the credential's reach widens on Groww's side — which is a reason the secret is encrypted the way it is below, not a thing this app will ever do.

Credentials at rest — Broker credentials are sealed with AES-256-GCM under a key held in the application environment and never written to the database. Anyone holding a stolen database dump — or a leaked database key — gets ciphertext. The authenticated mode means a tampered value fails loudly instead of decrypting into something unpredictable.

Notes kept in the Family Vault are encrypted in your browser with AES-256-GCM, under a key derived from a password that never leaves your device. We cannot read them — not on request, not under a subpoena, not by accident. The flip side is the honest one: lose that password and the notes are gone, because there is no copy of the key to recover them with.

You can require a code from your phone on top of your password. It is optional — enMoney will not force an authenticator app on you — and it is enforced where it counts rather than only on screen: the check sits beside the sign-in check on every request, so a session that has not satisfied the factor cannot read your data through the app, the iPhone app, or anything else talking to the same interface.

Recovery codes — Turning it on gives you ten single-use codes, shown once and stored only as hashes. Redeeming one switches two-factor off so you can set it up again on a new phone — it does not quietly let a stranger in past the factor. That means a recovery code is worth exactly as much as your authenticator: keep them somewhere a thief would not look.

You are told when it is switched off — Whenever two-factor stops protecting your account — a recovery code spent, or the factor removed by us — the address on the account gets an email saying so within seconds. If that was not you, you find out straight away rather than at your next sign-in.

If you lose both — We can remove the factor from your account. That takes a conversation in which you are asked for things an email account does not contain, it waits a day unless we know you by voice, it is written to an audit log, and it triggers the notice above. It is the deliberate weak point of any second factor — the way past it is a person, not a flaw — so expect to be asked to prove the account is yours, and to wait.

Other users, never — that is what the row-level rules above are for. But an app whose operator claims to be locked out of the database is describing a product that could not be supported or repaired, so here is the true version: the people who run enMoney hold administrative access to the production database, used for operating the service — investigating a fault you report, running migrations, fixing a corrupted import. That access is not used to browse your finances, and it stops at the Family Vault, which is encrypted against us as well. Actions taken against an account through the admin tools — suspending it, resetting a password, deleting it — are written to an audit log. Direct database access is not logged that way, which is why the list of people holding it is as short as it is.

Anyone who tells you their hosted product's staff categorically cannot see your data is either running end-to-end encryption over the whole product — which this is not, outside the vault — or is not being straight with you.

These are the only ones. Each is here because a feature needs it.

Supabase — Database, authentication and file storage.

Vercel — Hosting for the application itself.

Google Gemini — Reads uploaded documents to pull out dates, amounts and merchants. Receipts, payslips, bank and property statements go through it, and so does a broker statement in a PDF format we have not written a reader for — the import says so on screen when it happens, and you approve every row before it is saved. CSV and Excel imports, and the broker PDFs we do recognise, are read by our own code and never leave our servers. This is the one that deserves a second look before you upload a bank statement, and it is disclosed in the privacy policy rather than buried. Documents are sent for that extraction and for nothing else. Gemini also answers Ask enMoney: when you ask a question, it and the figures looked up to answer it (balances, loans, properties, salary, super) go to Google for that one answer. Nothing is sent unless you ask, and the conversation is not kept.

Ollama (until 20 October 2026) — The AI service Ask enMoney used before Gemini, and still may until that date while we move off it. It receives the same question and figures Gemini would, for the same one answer. After 20 October it is gone from this list.

Market data providers — Prices for what you hold — a ticker, never who holds it.

Stripe — Payments for the subscription. You type your card on Stripe's own page; the card number never reaches our servers, and we keep only your plan, renewal date and Stripe's reference for it. Stripe never sees your financial data.

Resend — Transactional email: invitations and alerts. No marketing list, no newsletter, no third-party analytics.

There are no advertising networks, no tracking pixels, and no page-view or click analytics anywhere in the product. Your data is never sold or shared for anyone else's purposes.

Accountant links are generated by you, expire on a date you set, carry only the financial year and the people you chose, and can be revoked before they expire. Nobody can be added to a household without accepting an invitation themselves, and only the person who created a household can be its owner. A partner you invite sees what you granted and nothing else. Nothing is shared by default.

Receipts are private per receipt, not per household: a partner sees a deduction only after you share that specific one, and unsharing takes back both the record and the attached bill. You can opt in to sharing each new receipt as it is added, which is off unless you turn it on and never reaches back over what you recorded before.

Your own data goes the other way too — Settings → Data exports your portfolio, trades, bank transactions and receipts as CSV, with no request to us and no waiting period.

Referral links are how an existing user invites someone they know. Each one is made by that user, works once, and expires after 30 days. The person who opens it sees the sender's first name only if the sender chose to show it, and nothing else of theirs. The sender is never told whether the link was used — not a list, not a count that changes. We record who referred whom, which is visible to the people who run enMoney, and to no one else.

Ask us and the account is deleted: every row keyed to you is removed by database cascade, and uploaded files are swept from storage in the same operation, after a short cooling-off window in case the request was a mistake. It is irreversible by design — there is no soft-deleted copy left behind for us to hold. Encrypted nightly backups age out on their own retention schedule.

The reason to read this section first is that most security pages do not have one.

No third-party audit — No SOC 2, no ISO 27001, no external penetration test. Claiming otherwise would be easy and unverifiable, so: not yet.

Deletion is not yet self-serve — You ask, we run it. A button in settings is coming.

Encryption key rotation — Broker credentials are encrypted, but there is no key-versioning scheme yet, so rotating that key means every user reconnects their broker. Fine at today's size; it gets built before it isn't.

Report it to support@enmoney.app and you will get a human reply. Report in good faith and we will not pursue you for it. If a breach ever affects your data, we will tell you what happened and what was reached — directly, not through a change to this page.