Your broker evidence should only be used to explain your account.

TradeGospel processes trading history, account context and private reports to produce post-trade diagnosis and improvement tracking. This policy is written for the current product boundary and requires legal review before unrestricted public launch.

Effective date 6 July 2026

This page describes intended production handling for private trading evidence in the current TradeGospel package.

Core principle Your evidence is not public by default.

Uploading broker files does not authorise public identity, public score, advertising use or unrelated model training.

Account dataIdentity and session records

Email, authentication state, sessions, audit records and support metadata keep the account usable and secure.

Trading contextAccount labels and market profile

Jurisdiction, currency, timezone, account type, asset classes and trading styles help TRS interpret evidence safely.

Broker evidenceReports, statements and ledgers

Files may contain trades, balances, fees, timestamps, account identifiers and cash movements.

ReportsPrivate TRS diagnosis

Generated findings, limitations, evidence receipts and repair cycles are stored as private account history.

SupportReview requests

Support messages may include broker names, report identifiers and issue descriptions needed to investigate a problem.

OperationsTechnical logs

Limited logs may be used for abuse prevention, reliability, security investigation and error diagnosis.

Why information is processed

TradeGospel processes information to authenticate users, classify and validate evidence, reconstruct trading activity, generate evidence-linked TRS findings, maintain private report history, operate improvement cycles, prevent abuse, investigate errors and provide support.

Evidence boundaries

Files can include trade history, account references, balances, charges, broker timestamps, contract-note data and cash movements. Evidence is account-scoped and is not published merely because it has been uploaded.

Public credibility requires a separate product flow.

Any future public trader identity, public reliability badge or public score must require separate user authorisation and separate publication controls.

Protected PDF passwords

A document password entered for a locked statement or contract note is intended to be used only while opening the selected document in the processing task. It should not be stored in the database, object storage, dashboard, report or audit history.

Users should never provide broker-login passwords or one-time login codes to TradeGospel support.

Service providers and transfers

Cloud, database, object-storage, monitoring, email and support providers may process limited information on TradeGospel's behalf. Production deployment must document selected providers, data regions, contractual safeguards and subprocessors before launch in jurisdictions that require them.

Retention and deletion

The application includes account metadata export, evidence-package deletion and whole-account deletion controls. Whole-account deletion attempts to remove stored evidence and report artifacts before deleting database records, and fails closed if storage deletion cannot be completed.

Backups need a published schedule.

Production backup expiry, legal-retention windows and restoration procedures must be documented because backup copies may not disappear at the exact moment a primary record is deleted.

Your choices

Choose which accounts and records to upload.
Correct account context before analysis.
Delete evidence packages where product controls allow it.
Request whole-account deletion.
Ask for support review when evidence reconstruction looks wrong.

Privacy rights and controller obligations vary by jurisdiction. TradeGospel must publish the responsible legal entity, complaint route and jurisdiction-specific notices before accepting unrestricted users in regulated regions.