Bridge Trading — Broker Credential Handling Disclosure

Notice to Reader (this version)

This disclosure describes exactly how Bridge Trading interacts with the credentials that connect your Broker Account to our Service. It supplements Section 8 of the Terms of Service ("Authorized Broker-Account Use") and is incorporated into the Terms by reference.

This is a v0 working draft prepared by the founder. The technical details described below reflect our security architecture as of 2026-05-21. We will update this document if the architecture changes.

1. Why This Disclosure Exists

To execute Copy Trade orders on your behalf, Bridge Trading needs some form of authorization to submit orders to your Broker. The form that authorization takes depends on what your Broker supports:

• Some Brokers (notably retail brokerages like Charles Schwab, Fidelity, Robinhood, and Interactive Brokers) support OAuth-style delegated authorization. With these Brokers, Bridge Trading never sees your Broker password — you authorize us through the Broker's own login page, and we receive a revocable, scoped token.

• Some Brokers (notably proprietary trading firms — Apex Trader Funding, TopstepX, and Tradovate in its prop-firm-connected configuration) do not support OAuth. With these Brokers, the only way to integrate is to store your Broker credentials (username, password, and any session tokens) on our side.

This disclosure tells you, in plain English, what Bridge Trading does with your credentials in each case, what the realistic threat model is if our credential store were breached, and what your rights are.

2. The Four Connection Paths

2.1 Path A — Encrypted credential storage

This path applies to: Apex Trader Funding evaluation and PA accounts, TopstepX evaluation and funded accounts, Tradovate (when used with a prop-firm relationship), and any other Broker for which OAuth is not currently available.

What happens when you connect:

1. You enter your Broker username and password into Bridge Trading's connection screen.
2. Bridge Trading encrypts the credentials immediately using Fernet (an authenticated symmetric encryption scheme implementing AES-128-CBC with HMAC-SHA256 over the ciphertext, as standardized by the Python cryptography library).
3. The encryption key is per-customer — different for every customer — and is derived at use-time via HKDF-SHA256 from (a) a master salt held only in our key management service (currently Doppler, with planned migration to AWS Key Management Service pre-public-launch), and (b) your internal customer identifier. The per-customer derivation means that a database leak alone is insufficient to recover any customer's credentials: an attacker would additionally require the master salt held in the key management service.
4. The encrypted credentials are stored in our database. The unencrypted credentials are not stored anywhere.
5. When Bridge Trading needs to submit an order on your behalf, the encrypted credentials are decrypted in-process at the moment of order submission, used to authenticate to your Broker's API, and then discarded from memory.
6. At no point are the decrypted credentials written to disk, written to a log file, sent to any third party, or stored in any backup.

Important honest disclosure about the threat model:

The per-customer key derivation provides defense in depth, not zero-knowledge encryption. Specifically: Bridge Trading's server processes can derive any customer's key (from the master salt plus the customer's user identifier) whenever a copy-trade dispatch fires for that customer. This is necessary because copy-trade signals can arrive while you are not actively logged in, and orders may need to be placed against your broker on your behalf during that time.

What this means in practice: - An attacker who steals only the encrypted credential blobs from a database backup cannot decrypt them, because they lack the master salt. - An attacker who additionally compromises the key management service (Doppler / future KMS) could derive any customer's key and decrypt their credentials. - A Bridge Trading employee or contractor with production server access could, in principle, decrypt credentials. Access to the production environment and the key management service is restricted to a minimal number of authorized personnel, and all access is audited. - A future Phase 3 enhancement will explore deriving the per-customer key from material that requires your active session (so Bridge could not decrypt your credentials without you being logged in). This is not the current state.

What Bridge Trading sees:

• The credentials you submit, only at the moment of submission (to encrypt them).
• The encrypted credentials, at rest.
• The decrypted credentials, only inside the process submitting an order to your Broker, only for the duration of that order submission.

What Bridge Trading does NOT see:

• Your bank account password.
• Any other credentials you may have at the same or related institutions.
• Any decrypted credentials persisted to disk.

2.2 Path B — OAuth-based connection (where supported by the Broker)

This path applies to: tastytrade (futures, futures options, equities, equity options), and any other Broker that offers a developer OAuth flow that supports order submission.

What happens when you connect:

1. You click "Connect [Broker Name]" in Bridge Trading.
2. Bridge Trading redirects you to your Broker's own login page.
3. You log in directly with your Broker — Bridge Trading never sees your password.
4. The Broker asks you to authorize Bridge Trading to access your account (typically with scopes like "read positions," "submit orders," "read order history").
5. Upon authorization, the Broker issues Bridge Trading a scoped access token. This token: - Only grants the specific permissions the Broker shows you on the authorization screen; - Is revocable at any time, either from your Broker's account-settings page or from Bridge Trading's connection-management page; - Typically has an expiration (commonly 30-90 days) and is refreshed using a separate refresh token issued at the same time.
6. Bridge Trading stores the access token (encrypted) and the refresh token (encrypted), both governed by the same encryption scheme described in Section 2.1.

Why this is safer than Path A:

• We never see your Broker password. If our database is breached, the attacker has only a scoped token — not the credentials needed to take other actions against your Broker account.
• Tokens are revocable independently of Bridge Trading. If you log into your Broker and revoke the Bridge Trading connection, Bridge Trading cannot submit further orders even if our database is breached.
• Tokens are scoped. Even with a stolen token, the attacker can only do what the original scope allows.

2.3 Path C — Brokerage-aggregator OAuth (via SnapTrade)

This path applies to: retail brokerages including (but not limited to) Charles Schwab, Fidelity Investments, Robinhood, Interactive Brokers, Webull, E*TRADE, Vanguard, and others supported by SnapTrade.

What happens when you connect:

1. You click "Connect Retail Broker" in Bridge Trading.
2. Bridge Trading redirects you to SnapTrade, a SOC 2 Type II-audited brokerage-aggregation service.
3. SnapTrade walks you through the connection flow for your specific Broker, typically using that Broker's own OAuth flow.
4. SnapTrade — not Bridge Trading — holds your Broker credentials or OAuth tokens.
5. SnapTrade issues Bridge Trading a SnapTrade-specific user reference and a scoped trading authorization.
6. When Bridge Trading needs to submit an order on your behalf, we call SnapTrade's API, which translates and forwards the order to your Broker.

What Bridge Trading sees:

• A SnapTrade user reference (a UUID).
• Order acknowledgments, fill prices, position summaries (as returned by your Broker through SnapTrade).

What Bridge Trading does NOT see:

• Your retail Broker password — ever.
• Your retail Broker OAuth tokens — they're held by SnapTrade.

This path effectively delegates the entire credential-handling responsibility to SnapTrade. SnapTrade's privacy and security posture is described in their own policy at https://snaptrade.com/privacy.

2.4 Path D — No connection (when no supported path exists)

This path applies to: any Broker that is not currently supported by Path A, B, or C.

What happens:

• You may still subscribe to Bridge Trading for research and signal access only.
• You receive signals in the Service dashboard, in email digests, or via notification.
• Bridge Trading does not submit orders on your behalf.
• You may use your own webhook-based execution layer (for example, PickMyTrade, TradersPost, CrossTrade) at your own contractual relationship with that vendor. Bridge Trading is not party to that relationship.

Why we offer this path:

We considered building Bridge Trading to accept any Broker credentials via screen-scraping or unofficial automation, but that approach would (a) be inherently more fragile than official integrations, (b) potentially violate the relevant Broker's terms of service, and (c) leave us holding more credential types than we want to be responsible for. We instead chose to support a limited list of officially-supported Brokers via OAuth or aggregator OAuth where possible, and to limit Path A (encrypted credential storage) to Brokers where the realistic threat model is acceptable (see Section 3).

3. Threat Model — What Could Actually Go Wrong

We are required by good faith to tell you what happens, in the realistic worst case, if our credential storage system is breached. We do not promise this will never happen. We do promise that we have designed Bridge Trading specifically to limit the consequences.

3.1 If Path A credentials were breached

If an attacker obtained the decrypted credentials for one or more Path A Broker Accounts (Apex PA / TopstepX / Tradovate prop-connected accounts):

The attacker could:

• Log in to the Broker Account.
• View open positions, account balance, and recent activity.
• Submit orders, including orders that violate the Prop Firm's daily-loss limit, trailing-drawdown rule, or position-size limit. Submitting such an order would typically cause the Prop Firm to close the account (sometimes within minutes via automated risk systems).

The attacker COULD NOT:

• Withdraw money from the account. Prop Firm Accounts have no withdrawal pathway accessible through the trading login. Payouts are made via a separately-authenticated request flow that requires the Prop Firm to verify the trader's identity and pay out to a bank account on file with the Prop Firm. An attacker with just the trading credentials cannot redirect payouts to a different bank.
• Access your personal cash, your bank account, or any retail brokerage account. The Path A credentials are scoped to the specific Prop Firm Broker Account. They are not the same credentials as any other account you have.
• Change the payout-target bank account. Prop Firms typically require an additional verification step (driver's license, ID match, KYC re-confirmation) to change payout destinations.

The realistic worst-case dollar exposure:

• The cost of replacing the Prop Firm evaluation if you want to re-qualify for another funded account. This is typically $300 to $1,000 per Prop Firm.
• Any pending but un-paid payout that you would have received from the destroyed account. Prop Firms typically pay in $5,000-$10,000 tranches, and there is usually a queue of pending payout that has not yet been requested.
• Time and effort to re-establish a funded account with the same Prop Firm or a different one, if you choose to do so.

The realistic worst-case dollar exposure does NOT include:

• The full value of the Prop Firm's allocated capital ($50,000 to $300,000 typically). That capital belongs to the Prop Firm, not to you, and is not at risk in your personal balance sheet.
• Your personal bank balance, savings, or investments.
• Any retail brokerage account.

This threat model is provided as a good-faith disclosure of the risk you are accepting by connecting a Path A Broker Account. We do not warrant that no other downstream consequences could result. The threat model is the realistic typical case, not the absolute upper bound.

3.2 If Path B credentials were breached

If an attacker obtained the encrypted OAuth tokens for one or more Path B Broker Accounts:

The attacker could:

• Use the scoped token to submit orders within the scope authorized at connection time.
• View account information visible within the scope.

The attacker COULD NOT:

• Change the scope of the token.
• Use the token to log in to your Broker's website or change your Broker password.
• Persist access after you revoke the token from your Broker's account settings.

Mitigation: if you suspect compromise, log into your Broker, revoke the Bridge Trading connection, then change your Broker password. The compromised token immediately becomes useless.

3.3 If Path C tokens were breached

If an attacker obtained Bridge Trading's SnapTrade access references for one or more customers:

The attacker could:

• Submit orders within the scope granted to Bridge Trading by SnapTrade for that customer.

The attacker COULD NOT:

• Access the underlying Broker credentials (those are held by SnapTrade, not by us).
• Access the underlying OAuth tokens (those are held by SnapTrade).

Mitigation: SnapTrade and Bridge Trading both have the ability to revoke a customer's access independently. You can disconnect from Bridge Trading's settings panel and from SnapTrade's settings panel independently.

4. Operational Security Commitments

In addition to the architectural controls described in Section 2, Bridge Trading commits to the following operational practices:

4.1 Key management

• The master salt used to derive per-customer encryption keys for Path A credentials is stored in a separate key-management service, not co-located with the encrypted credentials in our database.
• The master salt is rotated annually at minimum, and immediately upon any suspected compromise. Rotation requires re-encrypting all stored credentials with the new derivation, which is a deliberate, audited operation.
• Customer-specific derived keys are not stored; they are recomputed from master-key + customer-ID at decrypt time.

4.2 Access controls

• No Bridge Trading employee, contractor, or third-party vendor has standing access to decrypted Broker credentials.
• Production database access is restricted to a small number of named individuals, each with their own authentication, multi-factor authentication, and audit-logged sessions.
• Access for legitimate operational reasons (debugging a failed order submission, responding to a customer support ticket) is logged and reviewed quarterly.

4.3 Audit logging

• Every decrypt event is logged with: timestamp, customer ID (encrypted), purpose (order-submission ID), and result (success / failure). The logs do not contain the decrypted value.
• Audit logs are retained for seven (7) years per the Terms of Service Section 14.

4.4 No backups of disconnected credentials

• When you disconnect a Broker Account, the encrypted credentials are deleted from the production database within twenty-four (24) hours.
• Database backups are encrypted at rest. We do not maintain off-line, restorable backups of disconnected credentials.

4.5 Subprocessor diligence

• We use a SOC 2 Type II-audited secrets management vendor (Doppler) for the storage of the master key material.
• We will migrate to AWS Key Management Service (an FIPS 140-2 Level 2 validated HSM-backed service) pre-public-launch, or shortly thereafter.
• We have selected SnapTrade as our brokerage-aggregator for Path C specifically because of their SOC 2 Type II audit and their published security posture.

4.6 Vulnerability response

• We monitor disclosed vulnerabilities in our key dependencies.
• We commit to patching critical security vulnerabilities in customer-facing dependencies within seventy-two (72) hours of public disclosure, or sooner if exploitation is observed.
• We accept responsible-disclosure security reports at [email protected].

5. Your Rights and Choices

5.1 Right to choose your connection path

For Brokers where multiple paths are supported (for example, tastytrade can technically be connected via either Path B or via PickMyTrade as a webhook destination), you choose the path during connection. Bridge Trading defaults to the path with the least credential exposure (Path B over Path A over Path C in that order of preference).

5.2 Right to disconnect immediately

You may disconnect any Broker Account from your Bridge Trading dashboard at any time. Upon disconnect:

• Path A: encrypted credentials deleted from our database within 24 hours.
• Path B: OAuth tokens revoked at the Broker; Bridge Trading's stored copy deleted within 24 hours.
• Path C: SnapTrade access revoked; SnapTrade reference reference deleted from Bridge Trading within 24 hours.

After disconnect, Bridge Trading does not retain any operational ability to submit orders on your behalf for that Broker Account. Audit logs of past order activity are retained per the seven-year retention rule.

5.3 Right to revoke from the Broker side

For Path B and Path C, you may also revoke Bridge Trading's access from your Broker's or SnapTrade's account-settings page directly, without involving Bridge Trading. This is the recommended action if you ever suspect that your Bridge Trading account has been compromised.

5.4 Right to use Path D

If you do not wish for Bridge Trading to hold any form of Broker credential or token — even encrypted Path A credentials or scoped Path B/C tokens — you may subscribe under Path D (signal access only) and use your own external execution layer.

5.5 Right to be notified of changes

If we change the architecture described in this document in a way that materially affects the threat model (for example, if we add a new Broker that requires a new connection path, or if we change the encryption scheme used in Path A), we will notify you by email at least thirty (30) days before the change takes effect.

6. Breach Notification

If we become aware of a security incident that has resulted in, or that we reasonably believe has resulted in, the unauthorized access to or disclosure of your Broker credentials or OAuth tokens, we will:

(a) Notify you within seventy-two (72) hours of confirmation of the incident, at the email address associated with your Bridge Trading account.

(b) Notify your Broker (or, for Path C, SnapTrade) to support credential rotation, token revocation, and account monitoring.

(c) Provide you with: a description of the incident, the categories of credentials affected, the steps we are taking to remediate, the steps you should consider taking, and a contact point for questions.

(d) Comply with applicable state data-breach notification laws in addition to this commitment.

7. What This Disclosure Does Not Cover

This disclosure addresses how Bridge Trading handles credentials you provide to connect a Broker Account. It does not address:

• Your responsibility to choose a strong, unique Broker password (your responsibility);
• Your responsibility to enable multi-factor authentication on your Broker (your responsibility);
• Your responsibility to monitor your Broker account for unauthorized activity (your responsibility);
• The security practices of your Broker, your Prop Firm, SnapTrade, or any other third-party service in the order-execution chain (their responsibility).

If you become aware of unauthorized activity in your Broker Account, your first call should be to your Broker, not to Bridge Trading. Your Broker has the authority to freeze the account, reset credentials, and reverse unauthorized transactions where possible.

8. Contact

Questions about this disclosure or about a specific connection on your account: [email protected]

Responsible-disclosure security reports: [email protected]

Suspected security incident affecting your account: [email protected], and include "URGENT" in the subject line.

[Bridge Trading LLC] Attn: Security [REGISTERED_AGENT_ADDRESS — TBD]

This document is a v0 working draft prepared by the founder. It has not yet been reviewed by counsel and is not effective until lawyer-approved and posted with a confirmed Effective Date.