Security

Live broker connections run through SnapTrade, a SOC 2 Type II audited financial-data aggregator, or through a broker's own OAuth flow where one exists. In both cases you authenticate with your broker — on the broker's domain or inside SnapTrade's credential interface — and we receive a scoped, read-only access token. Your brokerage username and password never touch Trade with Trust servers, and there is nowhere in our codebase or database schema to store them.

The token scope is reading: trade history, open positions, and account metadata. It does not authorize placing orders, canceling orders, transferring cash, initiating withdrawals, or changing anything on the account. This is enforced by the broker's authorization layer, not by our good behavior — there is no code path in our application that could request a broader scope, and a hypothetical compromise of our systems could not be turned into unauthorized trading.

You can revoke access at any time, from either side. Disconnecting in Trade with Trust deletes the connection and stops all future syncs. You can also revoke the authorization directly from your broker or SnapTrade's portal, independently of us — the connection dies even if our servers are unreachable.

Any account that connects a brokerage is required to enroll a second factor — either a TOTP authenticator app or one-time codes delivered by email. Admin accounts are always required to use two-factor, with no exceptions. All sign-ins are additionally protected by bot screening (Cloudflare Turnstile).

Sensitive operations — connecting or reconnecting a broker, changing security settings, administrative actions — require step-up verification even inside an already-authenticated session. Possession of a stolen session cookie alone is not sufficient to perform them.

Administrative functions are gated harder than user functions: they require the admin role plus an AAL2 session, meaning a TOTP verification performed in the current session. Email codes do not satisfy the admin gate, and every privileged action is checked server-side — the admin screens being hidden in the UI is cosmetic, not the enforcement.

Every table in our database is protected by row-level security enforced by Postgres itself, below the application layer. A bug in application code cannot read or write another user's private rows, because the database — not the app — evaluates who owns each row on every query.

The verified-trading record is protected the same way. Database triggers physically reject writes that would mark a trade from a paper (simulated) brokerage account as verified, rewrite a conversation's participants, or move a message between senders. These are not application-level checks that a new code path could forget to call; they are constraints the database applies to every write, including writes made with elevated credentials.

The practical consequence: a verified number on a profile cannot be edited by the trader, by another user, or by us through any application code path. Verified P&L is computed on the fly from broker-sourced rows — there is no separately stored 'reported' figure to adjust. The only way to change a verified record is to change what actually happened at the broker.

You control how your P&L is displayed to others: dollars, percentage, or percentile/relative. The choice is enforced where the data is assembled, on the server — not by hiding numbers in the browser after they've been sent.

The enforcement covers derived figures, not just the raw field. In percentile mode, per-trade entry and exit prices are omitted from the payload entirely, because a price combined with a known percentage return is the dollar amount. Fields that would let a viewer recompute a hidden value never leave the server.

Personally identifying data — legal name, account numbers, cash balances, deposits, withdrawals — is never rendered on any profile and never returned by any public endpoint. The public profile is served through a dedicated database view that structurally cannot expose columns outside its definition, even if application code asks for them.

Automated security scanning runs on every release, covering row-level-security coverage, exposed data, and dependency vulnerabilities. Findings that affect user data are treated as same-day fixes.

All traffic is encrypted in transit (TLS), and data is encrypted at rest by the managed database platform. Automated database backups are maintained by the platform provider.

Privileged operations are audited: admin actions that touch another user's account (for example, MFA recovery) write an audit-log row with the actor, target, and reason. Break-glass procedures that bypass the audited path are documented and require a manually written audit entry.