Security & Privacy

The short, plain-English version

Can the team running this site see my financial data?

No — not by ordinary means. Your balances, valuations, incomes, date of birth and (optional) account numbers / sort codes, are encrypted before they're written to the database. If the developer opens the database directly, they see scrambled ciphertext, not your money. Decoding it needs a separate secret key that lives in a different, locked-down system.

The honest caveat: encryption protects against database theft, leaked backups, and casual browsing from the development team. A determined site administrator who deliberately combined the database and the key could decrypt — that's true of every hosted service.

What about my password?

Your password is never stored. We only keep a one-way mathematical fingerprint (a BCrypt hash). Nobody, including the developer, can recover it — the only option if you forget it is to reset it via your email.

Can I add a second factor?

Yes. You can turn on optional two-factor authentication from your Profile page. Once enabled, signing in needs both your password and a 6-digit code emailed to you. It's off by default — opt in when you want it.

Could someone else's family see my data?

No. Each family is walled off in the application code, so logging in as a member of family A never returns any data belonging to family B.

Is the connection safe?

Yes. All traffic between your browser and the server uses HTTPS — the same encryption your bank uses. The browser is told to refuse to talk to this site over plain HTTP.

What if I change my mind?

You can delete your family and every piece of data it contains, permanently, from Settings → Danger Zone. There is no "soft delete" — the rows are gone.

What happens to documents I upload to the Import Wizard?

They are read once and thrown away. Uploaded files are never saved into the database and are not kept on the server after the import finishes.

Being straight with you about the part that matters: the contents of the documents you upload are sent to Anthropic, the company behind the Claude AI, because that is what reads them. If you would rather no third party ever saw a particular statement, don't put it through the wizard — enter that account by hand, or use the plain Excel import instead. Both do the same job without leaving the server.

What the AI is also told is deliberately minimal: a list of the names of things you already have, so it can tell a new account from one you have already recorded. That list carries names only — no balances, no valuations, no account numbers or sort codes.

What comes back — the records it found, merged with your existing data — is encrypted at rest like everything else, and deleted automatically a day later. None of it touches your real financial records until you have opened the spreadsheet, checked it, and chosen to load it in yourself.

Is my data sold or shared?

Data is never sold. Nothing leaves the server except (a) the emails and texts the app sends you, (b) anything sent to the optional AI advisor feature, and (c) the documents you choose to put through the Import Wizard, as described above. All three are things you opt into.

Want the full technical detail? Jump to the deep dive ↓

Full security posture (technical detail)

For readers who want the technical detail behind the claims above.

Encryption at rest

• Financially identifying values — anything that says how much money you have, what an account is, or who you personally are (PPI) — are encrypted before being written to the database. A direct database read returns ciphertext, not values.
• The encryption uses an industry-standard authenticated cipher (AES-256 in GCM mode) with a fresh random initialisation vector per value, so identical plaintexts never produce identical ciphertexts.

Key management

• The encryption key is held in a managed secrets store in our cloud environment and fetched only at process start-up. It is never present in source control, environment variables, container images, or backups.

Encryption in transit

• HTTPS is required for every connection; plain-HTTP requests are redirected or refused.
• The site is published with an HSTS policy (Strict-Transport-Security) so that once your browser has visited once, it will refuse to connect over plain HTTP, even if a network attacker rewrites the URL.

Authentication

• Passwords are stored only as a slow, salted one-way hash (BCrypt). Plaintext passwords are never stored or logged.
• Repeated failed logins trigger both per-account lockout and per-source rate limiting, slowing brute-force attempts to the point of impracticality.
• Email-verification and password-reset links are single-use, short-lived, and use a two-step click-to-confirm pattern so that link-preview scanners can't accidentally burn the token.
• Optional two-factor authentication is available per account. When enabled, a successful password check triggers a 6-digit one-time code delivered by email; the session is only fully authenticated once the code is verified. Codes are stored as BCrypt hashes, expire after 10 minutes, allow at most 5 attempts, and enforce a 60-second resend cooldown.
• Users can mark a browser as trusted for 30 days to skip the second-factor prompt on that device. The trust marker is an HttpOnly, Secure, SameSite=Strict cookie scoped to the login path, stored on the server only as a SHA-256 hash, and individually revocable from the Profile page.

Sessions

• Short server-side idle timeout — you'll be logged out automatically after a period of inactivity.
• Session cookies are marked HttpOnly, Secure, and SameSite=Strict — inaccessible to JavaScript, never sent over plain HTTP, and not sent on cross-site requests, which neutralises most session-stealing techniques.
• Changing your password invalidates every other active session for your account.

CSRF

Every state-changing request must carry a synchroniser token tied to the user's session. Requests without a valid token are rejected before reaching any business logic, so a malicious site cannot make your browser submit a request to ours on your behalf.

Content Security Policy & HTTP headers

• A strict Content Security Policy restricts the browser to loading scripts and styles only from this site — no third-party scripts, no inline JavaScript. This is one of the strongest defences against cross-site scripting.
• Standard hardening headers are sent on every response: clickjacking protection (frame-ancestors 'none' / X-Frame-Options: DENY), MIME-sniff protection (X-Content-Type-Options: nosniff), and HSTS as above.
• Output from the optional AI feature is sanitised before it touches the page, so even a hostile model response cannot inject script.

Data isolation

Every database query made by the application is scoped to the authenticated user's family. There is no API path that returns rows belonging to a different family, and the schema's foreign-key relationships enforce the same boundary at the storage layer.

Import Wizard — document handling

• Accepted types are decided by content, not by filename. Every upload is identified from its magic bytes and the extension must agree with what was found; a renamed executable, an HTML file called .txt, or a ZIP that is not a spreadsheet are all rejected before anything reads them. Archives are additionally checked for zip-bomb shapes.
• Uploads are never persisted. Files are held in memory for the length of the run and then discarded — nothing is written to the database. For completeness: an upload larger than a megabyte is buffered by the web server to a temporary file while it transfers, which the server deletes when the request completes.
• Document content is sent to Anthropic (the provider of the Claude AI) to be read. Spreadsheets, Word documents and text files are converted to plain text on our server first; PDFs and images are forwarded as-is, with images downscaled. This is the one part of the feature where data leaves the server, and it is why the wizard is optional — the hand-driven Excel import does the same job without it.
• The context sent alongside is minimised. So it can distinguish a new record from an existing one, the AI receives an index of your existing records containing identifying names only — account, institution, person, asset and debt names. No balances, valuations, account numbers, sort codes or dates of birth are included.
• The result is encrypted and short-lived. The merged rows and the report are stored encrypted at rest with the same AES-256-GCM scheme as the rest of your data, and a scheduled sweep deletes them after 24 hours (configurable by the operator). Original filenames are encrypted too, since a name like “pension – 2026.pdf” is itself disclosive.
• The AI cannot write to your records. It has no database access. Its entire output is a spreadsheet you download, review and choose to load through the existing Restore flow — so every AI-derived figure passes a human before it becomes your data.
• The audit log records that an import ran, how many files it covered and its job reference — never the filenames or their contents.

Backups & recovery

• An encrypted snapshot of the database is taken automatically every night and stored in a private, access-restricted bucket in our cloud environment.
• You can also export your own data to Excel at any time from the Backup & Restore page, and re-import it.

Operational guardrails

• Privileged events — backups, restores, family deletions, administrative actions — are written to an append-only audit log so unusual activity is visible after the fact.

What the operator can see, honestly

Encryption protects the data — names, money, everything personal. It does not (and cannot) hide the fact that you have an account. The operator can see:

• Your email address (used as your username) and your assigned role.
• When you signed up, when you last logged in, and from which IP address.
• Audit-log entries describing the type of action — e.g. "a user restored a backup at time Y" or "a user deleted their family". Any values associated with the action are themselves stored encrypted.
• Application error reports, which may include the URL you were on but not the sensitive field values submitted on it.

What the operator cannot see by reading the database is everything that identifies you as a person or describes your money: your first name, surname, phone number and family name; the names, dates of birth, tax bands, financial goals and notes of anyone in your family; and every account, asset, debt, valuation, balance, interest rate, charge, income and pension figure. All of those columns are ciphertext at rest without the key.