EBEB Payments

Privacy

Updated: 9 October 2026

Draft document β€” operator and company details are not yet defined. This does not establish readiness to launch financial services.

1. Project and operator

EB Payments is a demo project. The legal operator, registered address and privacy contact have not yet been specified. This document is a draft. The operator must identify itself and define actual processors, retention periods and applicable processing grounds before public launch.

2. Data used

Account data includes names, username, avatar, email, password hash, country, optional phone and preferences. Google sign-in uses a Google identifier and profile. Demo age access uses the supplied date of birth and email confirmation; document review is separate. Security data includes an encrypted 2FA secret, hashed recovery codes and session version. Demo balances, positions, activity, referral attribution and virtual rewards are recorded. Support stores tickets, messages and uploaded files, including photos, videos and documents. Servers may process IP addresses and technical logs.

3. Purposes

Data supports the account, requested demo features, security and support. The operator must assess and document the appropriate processing grounds. Choosing an external component does not grant blanket permission for unrelated processing. No licensed payment or brokerage service is being provided in the demo.

4. Providers

Google sign-in loads when selected. TradingView loads only when the chart is requested. Google Cloud translation receives only public interface text. Real payment integrations are disabled. Hosting, database and email providers depend on deployment; the operator must publish their details and international transfer arrangements before launch.

5. Protection and retention

Passwords and recovery codes are hashed; authenticator secrets are encrypted with a server key. Sessions are stored in the browser. Ticket files are available through authenticated downloads only to the ticket owner and authorized support. Upload only what is needed for support. Retention periods for accounts, files, activity and backups still need to be defined by the operator.

6. Requests

You may submit applicable personal-data access, correction, deletion and other requests through support. The operator must provide an accessible privacy contact for people without accounts and identify the competent supervisory authority after its jurisdiction is established. This draft does not replace those operational details.

7. Required information

Names, email and sign-in information are required for registration. Phone is optional and SMS verification is not required. Email and a date of birth showing age 18+ are required for demo operations. This age declaration is not documentary identity verification. Document review, if requested, is a separate process.

8. Changes

The operator must update this document when purposes, providers, retention or rights change and communicate material changes. Before public launch, it must align the policy with the actual service.

9. Security reviews and administrator access

If unusual activity, suspicious transfers or possible account compromise is identified, authorised administrators may review the relevant account details, identity documents, operation and top-up history, support correspondence and recorded activity. They may request an explanation or documents in an in-app support ticket, suspend access or request reverification. A human reviews these decisions; you may request a review through support or ebpayments.support@gmail.com. Administrator decisions and authenticated API access are recorded with the actor, target, route, time and outcome. Request bodies, passwords, login codes, tokens and 2FA secrets are not included in this log or displayed in the administrator panel. Activity logs are retained for up to 180 days and expired entries are removed at API startup; security cases and financial records follow the separate retention rules to be defined by the operator. Reviews are limited to what is necessary for account and fraud protection. The operator must assess and document the applicable legal basis and legitimate interests before public launch; this clause does not authorise unrestricted access or establish a legal obligation that does not apply to the operator.

Account tools and security notices

We store session identifiers, reported browser data and activity dates to list and revoke sessions; reset links are stored as hashes and expire in 15 minutes. In-app notices record the event type and a destination link. Saved recipient labels and addresses, demo requests and rate alerts are stored for your account. Sharing a request makes its amount, currency, note, status, expiry and public username visible to anyone with its link. Do not include personal documents in request notes. Expired reset records older than one day, sessions expired more than 30 days ago and notices older than 90 days are cleaned on server startup. Other retention periods remain subject to the operator’s launch review.