SP TRADE

Privacy Policy

A code-based description of information stored in the browser, processed on the server, or sent to an external provider. Controller details and retention periods still need to be completed.

Document status: transparency draft · Updated August 5, 2026 · No binding effective date has been set

What is verified and what remains open

The technical description is based on SP TRADE's active code. The operating entity, official address, registration details, privacy contact, governing law, and retention policy have not been provided, so they are not presented as facts.

1. Information in your browser

  • Trading journal: Trades, prices, fees, dates, setups, and notes are stored in localStorage on the current device.
  • Interface preferences: Reduced motion and larger text preferences are stored in localStorage.
  • Bot Builder chat: The on-screen history is held only in page memory and is not written to the application database in the current implementation.

Clearing browser data or moving to another device may remove this local information.

2. Information processed by the SP TRADE server

  • Account: When authentication is enabled, the system processes an email address, profile details, permission roles, authentication, and sessions.
  • Analysis and portfolio: A symbol, asset selection, and answers to three questions are sent to server routes to create a result; the current code does not store them in a user table.
  • Blog: Articles, drafts, and publishing runs are stored in PostgreSQL.
  • Rate limiting: The source address of a chat request is used as a temporary in-memory key for request limits.

3. External providers

Market queries are sent to Yahoo Finance and Bybit adapters. Bot Builder chat is sent to the active model provider through Vercel AI Gateway or directly to Google Generative AI, depending on deployment configuration. Google sign-in and verification/reset email are enabled only when configured.

The active hosting provider, processing location, and final provider list require verification in production.

4. Cookies and sessions

Authentication uses technical cookies to maintain a session. The code configures a session for up to seven days and refreshes it every twelve hours. Cookie names, their actual production duration, and possible cookies from sign-in providers have not yet been verified for a final policy.

5. Purposes, security, and deletion

Information is used to operate accounts and tools, generate results, provide security, limit usage, and run the blog. Admin permissions and authentication controls exist, but no system is completely secure. A complete account-deletion process, backup and log retention, and legal exceptions have not yet been documented for a final policy.