Converge Privacy Policy

1. Operator and contact

The operator identified in this document is responsible for processing within Converge. Converge is the service name and does not replace the operator’s legal identity. The contact for data requests is intentionally blank in this draft.

Exchanges and other independent recipients also process data under their own rules. This policy does not replace their privacy notices.

2. Data processed

Account and security data include email, account ID, password hash, email verification status, session records, two-factor settings, trusted-device records, a separate security phrase hash and security events. Do not send passwords, one-time codes or secrets to support.

Connected exchanges may provide connection labels, encrypted API credentials, permission checks, balances, positions, orders, fills, fees, funding and activity history. The scope depends on enabled features and exchange availability.

Subscriptions and USDT payments involve the plan, access period, invoice reference, network, receiving address, amount, transaction hash, status and verification time. Payment review does not require a wallet seed phrase or private key.

Requests and optional features may involve support messages and replies, data requests, and a Telegram chat ID and notification preferences when Telegram is linked. Document versions and acceptance records are also stored.

Technical data include session and security cookies, browser preferences, application events and errors. Network infrastructure may process IP addresses and connection information. The full contents of external infrastructure logs have not yet been confirmed for this draft.

3. Purposes and legal bases

Necessary account and requested-feature processing supports registration, authentication, access, payment handling, confirmed instructions and reconciliation. Its basis must follow the contract and applicable law.

Specific legal duties may require records for accounting, requests or legal demands. Account protection, abuse investigation and protection of rights require a necessity and user-rights assessment where that basis is permitted by applicable law.

Where a purpose requires consent, a separate informed user action is needed. Accepting the terms and reading this policy do not constitute blanket consent for every purpose. Declining an optional purpose must not enable it automatically.

A requested feature may be unavailable without its necessary data: an ordinary account needs an email address, and reading a connected exchange account needs API credentials.

4. Exchange credentials and security

API credentials are stored encrypted and decrypted by the application on the server to sign requests. An authorized administrator with server access and the decryption key can technically access them. Encryption does not make such access impossible.

Account protections include password hashing, access controls and additional security features. No safeguard guarantees that compromise cannot occur. Restrict API permissions, do not grant external withdrawals, and use a separate subaccount where available. Revoke keys directly on the exchange.

5. Recipients and providers

Your selected exchange receives account queries and trading instructions. Where a payment provider is used, it receives information necessary for the invoice. In the reviewed NOWPayments integration, requests include a random order reference, plan, amount and currency, with no email or exchange API credentials. The actual payment channel must be identified at checkout.

When enabled, the mail provider receives the recipient address and service email; Telegram receives the chat ID and selected notification content. Network, server and backup providers may process necessary information. The reviewed network design includes the Tuna tunnel.

Team access should be limited to support, security and operations needs. Disclosure in response to a lawful authority request requires an applicable basis and a necessary scope.

The complete list of provider legal entities, roles, countries and retention periods is not yet filled in. A technical integration name does not confirm a contract or processing country.

6. Processing locations

According to the service owner, the main database is located in the Russian Federation. Locations of all backups, logs, replicas and external-provider processing still require confirmation. This draft does not claim that all processing stays within one country.

International access and selected external features may involve transfers between countries. Relevant bases, restrictions and safeguards must be established before each applicable transfer. This draft does not claim that unverified contractual safeguards or authorizations are in place.

7. Cookies and browser storage

Essential cookies support sign-in, demo access, trusted browsers and short-lived sensitive-action confirmation. In the reviewed version, main sessions and trusted-browser records last up to 30 days, demo sessions up to 30 minutes and sensitive-action confirmation up to 5 minutes. Sign-out and revocation can end access earlier.

Favorite instruments and interface preferences may be saved in the browser. Removing cookies or disabling storage may require a new sign-in and reset preferences.

No connected advertising pixels or external web analytics were identified in the reviewed application. Accepting these documents does not authorize optional tracking: provide separate information and user choice before enabling it where required. External tunnel and other provider practices need separate review.

8. Retention and backups

Data should be kept only to the extent and for the period needed for a specific purpose or legal duty. Approved category-specific periods and the maximum backup retention period are intentionally unfilled in this draft.

In the reviewed version, a maintenance process removes expired access data, but account, operation and request history has no general automatic deletion deadline. Successfully disconnecting an exchange removes active credentials from the live database; it does not remove all history and backup copies.

Keeping particular records for accounting or legal claims needs its own basis, restricted access and a review period. Converge cannot erase public blockchain records or records independently held by exchanges.

Live-database deletion does not confirm erasure from every backup. Backup expiry and suppression of erased records during restoration still need approval and testing. Immediate destruction of all copies is not promised.

9. Access, correction and erasure

Subject to applicable law, you may request access, correction, erasure, restriction, consent withdrawal, objection or portability, and complain to the competent supervisory authority.

My data provides a web-application export excluding passwords, API credentials and access codes. Separate Telegram history and exchange-held records are outside that export. Correction and erasure requests can be registered for manual review.

Submitting a request does not close positions, cancel orders or revoke exchange keys. Check open exposure and permissions separately before stopping use. A reply in the account does not itself confirm completed erasure.

Proportionate account-ownership checks may be required to prevent unauthorized requests. A public channel for requests without account access is still unfilled. Response and execution deadlines depend on the request and applicable law; no single deadline is imposed for all requests.

10. Changes and language

Each policy version has its own identifier and date. Material changes to purposes or processing conditions require updated information and separate consent where necessary. A new version does not convert a past acceptance into consent for new purposes.

Russian and English texts are prepared for the same draft version. Applicable mandatory requirements remain relevant if the texts diverge; no prevailing language has been selected in this draft.