This page explains what data the product needs, what remains local in the browser, what may be sent to the server, and how Alvo is being prepared for a responsible production launch.
Updated 23 August 2026
Short version
V1 works as decision support and does not submit orders to XMtrade/PXS.
Short version
V1 works as decision support and does not submit orders to XMtrade/PXS.
CSV files are read in the browser; the current version does not store the original file on the server.
AI briefs and audit events may process trading parameters, date, prices, and technical request metadata.
The controller identity and privacy contact are published; before paid access, retention periods, party roles, and any required DPA/SCC still need approval.
01
Who is responsible
The data controller is the registered Ukrainian sole proprietor that operates Alvo; the exact registered identity and address are published at /en/imprint. Privacy requests can be sent to [email protected].
02
Data we process
We may process interface preferences, language, theme, strategy parameters, BESS assumptions, trade date, hourly prices, calculation output, audit events, technical request headers, and data the user voluntarily imports or sends through the API.
03
Why this data is needed
Data is used to load market prices, build a recommended plan, generate an AI explanation, run risk checks, export CSV files, support PWA behavior, secure the API, apply rate limits, and maintain an action log.
04
What stays local
Language, theme, density, strategy parameters, and BESS settings are stored in browser localStorage; for signed-in accounts, the current strategy and saved profiles can also sync to Alvo tenant storage. CSV import is parsed by client-side code, and the workspace then uses normalized hourly values.
05
Transfer and storage
API requests may contain prices, settings, trade date, and audit metadata. Account data, tenant profiles, demo requests, and audit events may be stored server-side; retention and deletion periods for commercial access still need approval.
06
User rights
Requests to access, correct, delete, restrict, or object to personal data processing can be sent to [email protected]. Before paid access, the response timetable and identity-verification procedure still need approval.
07
Security
Alvo uses server-side payload validation, API security headers, rate limiting, no-store API responses, and data minimization. Integration secrets, keys, and production credentials must not be stored in the browser.
08
International transfers and vendors
Alvo uses cloud subprocessors in the EU and the United States; current roles, data categories, and international-transfer mechanisms are published on the DPA and Sub-processors pages. Adding a provider requires updating that register and assessing the applicable transfer mechanism.
Short version
Production readiness checklist
The controller identity and privacy contact are published; before paid access, retention periods, party roles, and any required DPA/SCC still need approval.
Alvo and customer controller or processor roles for the specific pilot.
Retention and deletion periods for audit events, API logs, demo requests, and support inquiries.
Response timetable and identity verification for data-subject requests.
A countersigned DPA/SCC where required and a current subprocessor register.
Cookie and analytics consent if third-party analytics is added.
Need an operational review?
The current sole-proprietor details are published. Before paid access, this policy still needs counsel review against the real data architecture and pilot agreement.
