Security
Pre-launchWhat we do, and what we don't claim.
This page lists only properties verifiable in the product's code. You will find no certification here, because we hold none to date.
What you won't see on this page
Deliberately absent, for want of being true today:
- No ISO 27001, SOC 2 or PCI DSS certification — we hold none.
- No "approved by banks" badge and no partner institution logo.
- No mention of "end-to-end encryption": that is not the product's technical model.
- No user counts, app-store ratings or testimonials.
The day any of these becomes true and verifiable, it will appear here with its evidence.
What we do, and what we don't claim.
- Household isolation
The isolation unit is the household, not the user. Every financial row — accounts, cards, transactions, recurring debits, subscriptions, alerts, reports, merchant memory — carries its household identifier as a foreign key, with cascading deletion. Nothing attached to a household is readable from another one.
— Verified by an integration test: a user cannot read another household's rows, even given the exact identifier.
- Access controls
Every financial query is carried by an authenticated access and validated server-side, on every read and every write — not only at the entrance to a page. The business role in the household and the platform role are two distinct fields in two distinct tables: administering the platform confers no authority over a household, and owning a household confers no platform privilege.
— httpOnly cookie sessions, mandatory email verification, rate limiting on authentication endpoints.
- Redacted logs
The logger masks sensitive values before writing: amounts, labels, emails, account identifiers, tokens. An import error records the import identifier, never the file contents.
— Behaviour covered by tests.
- AI boundaries
The figures shown come from deterministic engines, not from a language model: the same question asked twice gives the same result. To date, no financial data is sent to an external language model. The assistant explicitly declines questions it cannot resolve rather than inventing an answer.
— Throughout the product, a bank fact — immutable — is distinguished from an interpretation, which is uncertain and marked as such.
- Imported files
Size capped, types allow-listed, empty files refused. A statement is stored under an opaque key, never under its original filename, in a directory of its own and outside the code repository. A fingerprint is computed to recognise duplicates.
— Per-user rate limiting on uploads.
- Deleting your data
Account deletion requires email confirmation, and the attached financial data disappears with the household by cascade — there is no path that leaves orphan rows. A redacted audit log, carrying no financial data, keeps the trace of security events.
— Cascade guaranteed at the database schema level, not by application convention.
- Errors and headers
An unexpected error renders a localised generic page: neither stack trace nor internal detail reaches the browser. Security headers are set globally and the server signature is disabled.
— Application error codes mapped to safe HTTP responses.
Known limits, tracked, not hidden
An honest product also publishes what isn't done yet:
- Rate limiting is in process memory: a multi-instance production will need a shared store.
- Two-factor authentication is not enabled yet.
- Production email delivery and file storage remain to be finalised on the infrastructure side.
- No real Open Banking connection is live: the layer exists, no institution is wired to it.
A security question?
Write to us rather than wait: we would rather fix things early.
Security contact address to be published with the commercial launch.
The next charge you don't understand, you'll know what it is.
Access opens gradually. Sign up and tell us your bank: we will write to you when your turn comes.