Your financial data is sensitive. We take its protection seriously. The measures described on this page reflect the security controls built into our platform.
All systems operationalYour information is protected at every layer
Sensitive personal and financial fields are encrypted at the individual field level using Fernet symmetric encryption (AES-128-CBC with HMAC-SHA256). This means even if someone gained access to our database, protected information would be unreadable ciphertext.
Your password is never stored — not even in encrypted form. Instead, we use bcrypt, a deliberately slow, adaptive hashing algorithm designed specifically for passwords. Even we cannot recover your password; we can only verify it.
All connections to Wealth365 are encrypted with TLS (HTTPS). Session cookies are flagged as Secure, meaning they are never transmitted over unencrypted connections.
Strict controls to protect your account from unauthorised access
Sessions use HttpOnly cookies (inaccessible to JavaScript), SameSite=Lax (prevents cross-site request attacks), and are transmitted only over HTTPS.
Sessions are configured with an 8-hour lifetime and a 30-minute idle timeout — if you step away from your computer, your session expires automatically. Concurrent session limits prevent unauthorised reuse of credentials.
Key endpoints are rate-limited to prevent brute-force attacks, credential stuffing, and abuse. Different tiers apply to different areas of the application, with dedicated throttling on login and registration.
After repeated failed login attempts, accounts are temporarily locked to prevent brute-force password guessing. Users are notified and can recover through the password reset flow.
Defence in depth across the application layer
Standard forms and authenticated API requests require a valid CSRF token. This prevents malicious websites from performing actions on your behalf if you happen to visit them while logged in. Token-authenticated endpoints (e.g. webhooks) use their own verification.
Security-relevant and key account actions are recorded in an append-only audit log with a 7-year archival policy. This supports GDPR subject access requests and regulatory compliance.
Registration and sensitive forms employ honeypot fields, timing analysis, and disposable email detection to prevent automated abuse without degrading the user experience.
Errors and slow requests are forwarded to Sentry so we can catch regressions before they spread. A redaction layer runs on every event before transmission: request bodies on plan, account and auth endpoints are stripped, query strings on token-bearing routes are dropped, cookies and authorisation headers are removed, and any field whose name matches our sensitive-key list (password, email, date of birth, NI number, account/sort code, plan-data dictionaries, balances, holdings, goals, etc.) is replaced with [Filtered]. Only stack traces, route names and timing data leave the server. Browser-sent Content-Security-Policy violation reports are received in-house — query strings and fragments are stripped from every URL field before the report is grouped on our internal reliability dashboard, so the policy can be tightened without leaking what page a user was on when the violation fired.
send_default_pii=False and a custom before_send scrubber in services/observability.py. Health-check transactions are excluded from sampling. CSP violations are persisted via the in-house /csp-report sink (typed config in services/csp_config.py) and surfaced on the operator reliability dashboard.
Every piece of data is validated before it enters the system
API endpoints only accept recognised field names. Unknown keys are rejected before processing, preventing injection of unexpected data into your financial plan.
Financial values are validated for correct types (numbers, dates, percentages) and sensible ranges. This prevents corrupt data from entering calculations and producing misleading projections.
User-generated text is escaped before rendering to prevent cross-site scripting (XSS) attacks. Template output is auto-escaped by default, and server-side sanitisation removes dangerous markup.
Your money and your data handled with care
All payment processing is handled by Stripe, a PCI-DSS Level 1 certified provider. Your card number, CVV, and billing details are submitted directly to Stripe — they never touch our servers. We only receive a confirmation token.
We comply with the UK General Data Protection Regulation. Your data is processed lawfully, minimised to what is necessary, and you can request access, correction, or deletion at any time. See our Privacy Policy for full details on data handling.
Honest disclosure about hosting location and cross-border data protections
Wealth365's production application and database are currently hosted on Replit, Inc. infrastructure in their North America region (United States). Your account data and financial planning information are stored and processed in the US, with the UK→US transfer covered by the Article 46 safeguard described in the next card.
Development environments also run in Replit's North America region (a Replit platform constraint). Development environments must never contain real client data.
Planned future migration: moving production to Replit's European Union region is a planned future objective. Until that migration is complete, the position above is the current and authoritative one.
The transfer of personal data from the UK to Replit's US infrastructure is governed by the UK Addendum to the EU Standard Contractual Clauses / UK International Data Transfer Agreement (IDTA) under our Data Processing Agreement, as approved by the ICO under Article 46 UK GDPR. The IDTA requires Replit to protect your data to a standard equivalent to UK GDPR.
On top of the contractual and adequacy-based protections, these technical measures reduce the risk of unauthorised access to your data in transit or at rest:
Your UK GDPR rights include the right to ask us for a copy of the safeguards that govern any transfer of your data outside the UK, the right to request that processing be restricted, and the right to ask us to delete your data.
How quickly we can recover your data, and how often we prove the recovery actually works
The backup pipeline takes a full logical backup of the production PostgreSQL database each night with pg_dump, encrypts it with a recipient-only GPG public key, and uploads it to Hetzner Object Storage in the EU region. Backups are stored outside our primary hosting provider's blast radius, so a provider-level incident cannot destroy both the live database and its only copy.
We publish concrete, operator-committed targets for how much data could be lost and how long a full recovery would take. These are the numbers our internal reliability dashboard tracks against once off-platform backups are wired up — not aspirational figures.
pg_restore, and the smoke-test pass described in our internal DR runbook.The implemented rehearsal downloads the most recent encrypted backup from Hetzner, decrypts it, and restores it into an isolated scratch database. It runs row-count sanity checks against every table the live application declares, confirms the Alembic schema head in the restored copy matches the deployed application, and decrypts a sample of Fernet-encrypted fields to prove the current encryption key still works against the backup ciphertext. If the rehearsal does not succeed at least once per 8 days, the dashboard tile flips to "Rehearsal overdue" and the on-call operator is paged.
pg_restore, row-count windows, Alembic head match, and Fernet decrypt of sampled encrypted fields. Active once operator provisioning is complete.
The FIELD_ENCRYPTION_KEY that protects Fernet-encrypted fields at rest is stored in Replit Secrets, never in source control, never in logs, and never in Sentry events. Access is restricted to named operations engineers. The application refuses to boot if the key is missing or fails its entropy check. The backup GPG keypair's private half is held offline (never in the production environment) by the same restricted access list, so a compromise of the Hetzner bucket alone cannot yield readable data — the offline private key is always required.
Our tax engine is continuously verified against HMRC rules
Every calculation in our tax engine — income tax, National Insurance, capital gains, dividends, pension allowances, and more — is verified by an automated test suite that runs against known UK tax rules and HMRC thresholds.
Our test suite covers the areas that matter most for your financial plan:
If you discover a security vulnerability, we encourage responsible disclosure. Please report it to security@wealth365.co.uk. We appreciate researchers who give us the opportunity to address issues before public disclosure.
Our security.txt file follows RFC 9116 standards for security contact information.
Your financial future, protected by real security measures. Not just promises.
Start Your Free Trial