Data Processing
Last updated 6 August 2026
A technical description of what happens to data inside Signalvexa — what is stored, what leaves the server, what protects it, and who counts as a processor.
1. Roles
Signalvexa is self-hosted software. Whoever runs the instance is the controller — they decide why and how data is processed and hold the database. The external services listed in section 4 act as processors or independent controllers for the limited data they receive.
2. Lawful bases
- Contract — creating and running your account, and producing the analyses you request.
- Legitimate interests — rate limiting, session integrity, and abuse prevention.
- Consent — the acceptance recorded through the banner, withdrawable by clearing site data.
3. What is processed and stored
- users — id, email, scrypt password hash, created and last-seen timestamps.
- verifications — email, purpose, HMAC-hashed code, attempt count, expiry. Deleted on use or expiry.
- conversations and messages — your prompts, the reports produced, and their timestamps.
Market data, headlines, and coin metadata are cached in server memory only. They are public information and are not linked to any account.
4. Transfers out
- Email provider — receives your email address and a verification code in order to deliver it. The only personal data that leaves the server.
- Anthropic (optional) — if enabled, receives the finished analysis: asset name, prices, indicator values and factor scores. It does not receive your email, account id, or prompt history.
- Binance, CoinGecko, news RSS feeds — receive only the server’s own requests for public data. No user data is attached.
Depending on which providers the operator configures, these transfers may leave your country or region. Check with the operator for the specifics of their deployment.
5. Security measures
- Passwords hashed with scrypt (N=16384) and a per-account random salt, compared in constant time.
- Sessions carried in a signed, HttpOnly JWT cookie bound to the current password, so a password change revokes every existing session.
- Verification codes stored only as an HMAC hash, expiring in 10 minutes, limited to 5 attempts, and single-use.
- Rate limiting on every authentication endpoint and on analysis, by IP and by account.
- Email delivered over TLS 1.2 or higher; credentials read from the environment and never committed.
- Password reset never reveals whether an address has an account.
6. Retention and deletion
Account and analysis records persist until deleted. Deleting an account removes its conversations and messages by cascade. Verification rows are pruned automatically. Deletion removes the rows from the live database immediately; the operator’s backup retention governs how long copies survive in snapshots — ask them.
7. Breach handling
There is no automated breach-notification pipeline in the software. The operator is responsible for monitoring, for notifying affected users, and for meeting any regulatory deadline that applies to them.
This document has not been reviewed by a lawyer
It accurately describes what the Signalvexa software does today, and is written to be a useful starting point — but it is not legal advice and has not been checked against GDPR, UK GDPR, CCPA or any other regime. Have counsel review it before relying on it in production or collecting data from real users.