What this install stores about you
Account rows in users: username, email, display name, status, and a bcrypt password hash. No date of birth, no phone number, no location, no payment data — the software has no use for them.
Preferences in user_preferences.prefs_json and notification_settings: theme, density, poll interval, digest cadence, quiet hours.
Work you create: watchlists, alerts, bots, strategies, backtests, reports, journal entries, books and orders. These live in tables keyed by your user id and are only ever read back through a permission check on that id.
Sessions, logs and hashes
Session rows keep an id, user agent, last activity and a hash of the remote address — the raw address is not written, so the table alone cannot identify a network location.
audit_logs keeps actions that matter (sign-in, permission denials, token issue and revoke, every admin write) with the same hashed origin and the target row it touched.
security_events keeps failures — sign-in attempts, rate limiter strikes, session fingerprint mismatches — so an operator can see abuse without profiling visitors.
Product analytics
The install records first-party usage counters (which page, which feature, how long a request took, which symbol was opened) in analytics_events, so the Features panel can say what is used.
There is no third-party analytics script, no advertising pixel and no external font or CDN request in any page: the CSS and JavaScript are local files under public/assets/.
Analytics can be switched off by the operator with app.analytics = 0, which stops writes and shows an empty state instead of a chart.
Questions you ask the assistant
Questions and answers are stored in ai_messages with the list of tables the answer read, so a reply can be checked later rather than re-derived from memory.
No prompt leaves this server. The built-in explainer queries the database and quotes rows; there is no call to an external model service, and none can be enabled by a page.
Feedback you give (ai_feedback) is stored against the row you rated and changes nothing about that row.
Secrets and encryption
Provider API keys are encrypted at rest with the material in config/keys.php; the plaintext is never written to the database, never returned by an API and never printed by the admin screens, which drop any column matching password, token, hash, secret or api_key.
API tokens are stored as SHA-256 hashes and shown once at issue time. Rotating a credential keeps the previous key so older rows stay decryptable, which is recorded as previous in the key file.
Password recovery is not offered because the hash cannot be reversed: an operator resets the account and flags it for change.
Retention, export, deletion
There is no cloud copy. Retention is whatever this server does: exports in storage/exports stay until deleted, logs rotate on the schedule in Admin → Settings.
Your own rows are readable from the pages that own them, and the account page lists sessions, tokens and audit entries. Export endpoints produce CSV from the same queries the grid uses.
Deleting an account is an admin action. It removes rows you own in tables that declare an owner, keeps the audit trail, and cannot be undone; ask the operator to anonymise instead if history must be preserved.
What would change this notice
Enabling a mail transport adds message metadata (address, subject, delivery result). Enabling a live quote provider sends only the symbols you have scheduled and never your identity.
The operator is responsible for publishing a jurisdiction-appropriate notice; this text describes the software as written, which is the only thing the code can guarantee.