Privacy Policy

We retain only the data required to operate the service, including:

• Account data: username, email, account preferences, and optional profile details.
• Authentication data: secure login/logout tokens, session time, and device or browser metadata for account protection.
• Service usage data: selected symbols, ranges, dashboard preferences, and interaction history with analysis tools.
• Notification and messaging data: notifications, private conversations, and read-state information needed for a consistent user experience.

• Core service delivery: displaying analysis, reports, history, and personalized capabilities.
• Account security: detecting suspicious access, controlling sessions, and reducing abuse risk.
• Technical stability: debugging, error monitoring, and improving API and frontend performance.
• Legal obligations: retaining the minimum operational data required for technical or legal accountability.

In production, communications are protected with the following controls:

• Mandatory HTTPS: insecure traffic is redirected to the secure version and HSTS is enabled.
• Secure authentication cookies: authentication cookies are managed with HttpOnly, Secure, and SameSite controls.
• Controlled CORS and CSRF: allowed origins are restricted and CSRF flow is enforced for sensitive actions.

Our goal is to protect sensitive data in transit against interception and tampering, while only allowing access through trusted paths.

Exchange API keys and secrets are never stored as plain text. Before storage, they are protected with Envelope Encryption (v2): the secret is encrypted with AES-256-GCM and the data-encryption key is wrapped through OCI Vault KMS.

• Encrypted storage: sensitive values remain encrypted at rest and can only be read through authorized server-side flows.
• KMS-managed keys: DEK unwrap operations are handled by OCI KMS, and the KMS key itself is not stored in the application database.
• Security separation: the application keeps ciphertext and required metadata only, while key-material access stays under OCI IAM and policy control.
• No full-key display: the UI only shows masked values or fingerprints for identification.
• Access control: keys are limited to the owning account and authorized internal services and are not sold or disclosed to third parties.
• Secure deletion: removing an exchange connection or deleting an account also removes stored key material from the operational system.

Using oci_kms reduces the risk of holding raw key material directly inside the application, but final security still depends on IAM controls, runtime isolation, monitoring, and sound operational policy.

In the current version, API credentials are validated during exchange connection setup and permission metadata such as can_trade or permissions may be read. Final enforcement, however, is still performed by the exchange itself.

• Minimum required access: enable only the permissions needed to read account state and execute trades.
• Disable withdrawals: do not enable withdrawal permission unless there is a highly controlled operational reason.
• Network restriction: if the exchange supports it, enable IP whitelisting to reduce key misuse risk.

To operate trading services, synchronize state, and provide reporting, some trading data is stored, such as symbol, quantity, price, order status, exchange order identifiers, and operational event logs.

• Storage scope: order, position, and trading-log data are retained for operational processing, auditability, and reporting.
• AI training: private user trading logs are not currently used as training or fine-tuning data for market-analysis models.
• Retention cycle: some operational logs may be pruned on shorter cycles for system health, and full account deletion triggers removal of dependent data.

If our data policy changes in the future with respect to model training, that change will be announced clearly on this page before rollout.

• Password storage: passwords are stored as one-way hashes using Django-standard mechanisms and cannot be recovered as plain text.
• Strong password policy: similarity checks, minimum length, common-password checks, and numeric-only restrictions are enforced during registration and password change.
• Refresh token rotation: refresh tokens rotate on renewal and previous tokens are blacklisted.
• Anti brute-force: rate limiting and captcha protections are applied on login and registration paths under suspicious conditions.

To help secure accounts, login sessions are recorded with limited metadata such as IP address, browser, and device type so active sessions can be reviewed and unwanted access can be terminated.

Server-side logout, logout from all devices, and token invalidation are supported as part of the session-control model.

• Format and content validation: only allowed formats are accepted and the actual file content is also verified.
• Size limits: upload-size limits are enforced to reduce abuse risk.
• Safe file naming: uploaded file names are replaced with random identifiers so the original user filename is not exposed in storage paths.

We do not sell personal data. Sharing happens only to the extent required to provide the service, such as infrastructure, database, email, or OAuth providers, and only within the minimum scope necessary for operation.

When using services such as Google Login or Telegram, access remains limited to the defined authentication or notification flow.

Our retention model is effectively based on user request. Your account data remains active while the account is active unless you request deletion.

A user can request full account deletion at any time. After the process is confirmed, account-related profile and service data are removed from operational flows except for any minimum records that must be kept for legal reasons.

This service is designed and operated according to core GDPR principles including data minimization, transparency of processing, technical security, restricted access, and responsiveness to user requests about personal data.

Alignment in this page refers to operational adherence to GDPR principles and does not by itself imply an independent formal certification from a third party.

• Right of access: users can request clarity about the personal data retained about them.
• Right of rectification: inaccurate or outdated information can be corrected.
• Right to erasure: users can request full deletion of the account and related data.
• Right to restrict processing: where applicable, users can request restriction of processing.

• Edit information: you can update your profile information.
• Session control: you can sign out or terminate unwanted active sessions.
• Privacy requests: for deletion, correction, or data-access requests, use the available support channels.

This policy may be updated over time in response to technical, security, or legal changes. The latest version will always be published on this page.

This text is intended for operational transparency and does not replace specialist legal advice.