Security & privacy
Financial software earns trust by being precise. Here is the current state of this website and the commitments planned for the product.
SolvMoney is a front-end demonstration. No accounts are active and no financial data is collected.
This site has no backend, no database and no user accounts. There is nothing to connect, nothing to store and no financial records in existence. The dashboard you can interact with runs entirely in your browser on sample data shipped with the page.
The site loads no third-party analytics, no advertising pixels and no session-recording tools. It sets no cookies and no identifiers, so there is no behavioural profile to build, sell or leak.
The sign-up, sign-in, password-reset and contact forms are front-end prototypes. They validate input in your browser to demonstrate the states, and they submit nowhere. Each one says so on the page rather than implying a message was received.
No payment provider is connected. The checkout page shows the intended flow and never asks for a card number, so there is no cardholder data involved at any point.
Pages are served over HTTPS with HSTS, and the application sets X-Content-Type-Options, X-Frame-Options, a strict Referrer-Policy and a restrictive Permissions-Policy. These are configured in the application itself and travel with any deployment.
The authentication and checkout routes are marked noindex and excluded from the sitemap, so they are not surfaced in search results.
These gaps matter for a finance product. They will be revisited before any live account or payment feature is launched.
SolvMoney holds no SOC 2 report, no ISO 27001 certificate, no PCI DSS attestation and no regulatory authorisation. There is no product in production to audit yet. When an audit is completed, the report's scope and date will be published here — not a badge.
A third-party security assessment is planned before any account connection or payment feature goes live. None has been carried out, so none is claimed.
Nothing is stored, so there is nothing to describe. Once persistence exists, this page will state the specific mechanisms in use — at rest, in transit, and for anything held in a managed service — rather than the phrase 'bank-level security', which means nothing.
Account aggregation will be delegated to a licensed provider. Until one is contracted and configured, no institution coverage, sync frequency or data-handling term can be described accurately.
What the assistant would send, where it would be processed and how long it would be retained all depend on that choice. Those details will be published before the feature ships, and the assistant will be opt-in.
These are design commitments, not a claim that the future product has already implemented them.
Account authorisation will happen with the financial data provider. SolvMoney will receive a revocable access token and never the username, password or one-time code for your bank.
Every read of financial data will be checked server-side against the requesting user, not filtered in the browser. A client that asks for a record it does not own gets a not-found, not a filtered list.
Provider keys, signing secrets and payment credentials are read from the environment on the server only, and never shipped in a client bundle. This website already follows that rule: it contains no keys because it needs none.
We will store the minimum needed for the features you use. Data that only exists to enable an optional feature will be collected only when you enable it, and removed when you turn it off.
Household access and external tool connections will be granted per person or per tool, with a visible scope, a visible list of what currently has access, and a revoke control that takes effect immediately.
You will be able to export your data in a portable format and delete your account and its records from within the product, without emailing anyone to ask.
Failures will return generic messages to the client and keep detail in server logs, so error handling never becomes a way to enumerate accounts or read other people's records.
Authentication, password recovery and export endpoints will be rate limited, and repeated failures will be throttled rather than answered at full speed.
The privacy policy explains what the demo does and does not collect.