Bridge Trading — Broker Credential Handling Disclosure

Version: 1.1 (incorporates Eversheds Sutherland review — ES Comments 7.28.26 / A. Allen 8.03.26) Last Updated: 2026-08-05 Effective: 2026-07-29

This disclosure describes how Bridge Trading interacts with the credentials that connect your Broker Account to our Service. This disclosure contains important information about cybersecurity risks, regulatory considerations, and your responsibilities. You should read it carefully and consult with your own advisors before providing any Broker credentials to Bridge Trading.

The technical details described below reflect our security architecture as of the Last Updated date above. We will update this document if the information becomes materially inaccurate.

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 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. No Broker connection offered in the current release uses this path — it is documented here for completeness and in case a non-OAuth Broker is supported in a later release.

You acknowledge that certain Brokers may prohibit third-party storage of account credentials in their terms of service or customer agreements. Bridge Trading does not independently verify whether your Broker permits credential storage by third parties. If you provide credentials for a Broker that prohibits such storage, you may be in violation of your Broker agreement and your Broker may terminate your account, reverse transactions, or take other adverse action. Bridge Trading is not responsible for any consequences arising from your violation of your Broker's terms.

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: any Broker for which OAuth is not available. No currently supported Broker connection uses this path.

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 authenticated symmetric encryption (currently AES with HMAC authentication). The specific encryption implementation may change as security standards evolve; any material change to the encryption architecture will be disclosed pursuant to Section 5.5.
3. The encryption key is per-customer, meaning a different key is used for every customer. The encryption key is derived at use-time using a cryptographic key derivation function from (a) master key material held only in a separately-administered key management service (not co-located with the encrypted credentials), 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 key material held in the key management service. The specific key management service provider may change; any material change will be disclosed pursuant to Section 5.5.
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.

Important disclosure about the threat model:

Bridge Trading's server processes can derive any customer's key (from the master key material plus the customer's user identifier) whenever an order submission is required for that customer. This architecture allows copy-trade signals to be executed while you are not actively logged in.

Implications: An attacker who obtains only the encrypted credential data from a database backup cannot decrypt it without also obtaining the master key material. An attacker who additionally compromises the key management service 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 authorized personnel, and all access is logged. Bridge Trading may in the future implement a key derivation method that requires your active session for decryption; this is not the current architecture.

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 (equities and 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 does not have visibility to your password when using the OAuth-based method.
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: (a) only grants the specific permissions the Broker shows you on the authorization screen; (b) is revocable at any time, either from your Broker's account-settings page or from Bridge Trading's connection-management page; (c) 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.

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 when using this method:

• A SnapTrade user reference code (referred to as a universally unique identifier ("UUID")).
• Order acknowledgments, fill prices, position summaries (as returned by your Broker through SnapTrade).

What Bridge Trading does NOT see:

• Your retail Broker password.
• 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:

Bridge Trading supports Broker connections only through official integration methods (OAuth or aggregator OAuth) where available. Bridge Trading does not use screen-scraping or unofficial automation to access Broker accounts.

IMPORTANT LEGAL CONSIDERATION: Certain brokerage platforms explicitly prohibit third-party credential storage, screen-scraping, or automated access in their terms of service. While Bridge Trading uses OAuth and aggregator connections where available, you remain solely responsible for confirming that your use of Bridge Trading complies with your Broker's terms of service. Violation of Broker terms may result in account termination, reversal of transactions, or other adverse consequences for which Bridge Trading bears no responsibility.

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. The following threat model is provided for informational purposes and does not constitute a guarantee of any specific security outcome. Actual security incidents may involve vectors or consequences not described below.

3.1 If Path A credentials were breached

No currently supported Broker connection uses Path A, so no customer credentials are held under this path today. If Path A is ever offered for a specific Broker, the following threat model would apply, and this disclosure would be updated with Broker-specific detail before that connection is made available:

The attacker could:

• Log in to the affected Broker Account.
• View open positions, account balance, and recent activity.
• Submit orders that damage the account, including orders that violate the Broker's risk rules for the account.

The attacker COULD NOT:

• Withdraw money from the account where the Broker's withdrawal flow requires separate, identity-verified authorization to a bank account already on file with the Broker.
• Access your personal cash, your bank account, or any other brokerage account. Path A credentials are scoped to the specific Broker Account. They are not the same credentials as any other account you have.

The realistic worst-case dollar exposure is trading losses inflicted inside the affected Broker Account before the connection is severed and the credentials are rotated, plus the time and effort to re-establish the account.

This threat model is provided as a good-faith disclosure. 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.

IMPORTANT: The threat model above does not address regulatory consequences. A breach of Broker credentials may trigger reporting obligations under SEC Regulation S-P, state data breach notification laws (including California, New York, and Massachusetts requirements), and potentially FINRA rules. Depending on the circumstances, you may also have reporting obligations to your Broker or other parties. Bridge Trading's breach notification under Section 6 does not satisfy your independent legal obligations.

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 key material 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 key material 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 material + customer identifier at decrypt time.

4.2 Access controls

• Production database access is restricted to designated authorized individuals, each with their own authentication, multi-factor authentication, and audit-logged sessions.
• Bridge Trading reviews access rights 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.

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.
• Notwithstanding the foregoing deletion commitments, Bridge Trading may be required to retain certain credential-related information pursuant to legal process, regulatory examination, or litigation hold. In such cases, retention will continue for the duration of the legal requirement, and the information will be deleted promptly upon expiration of the retention obligation.

4.5 Subprocessor diligence

• The master key material is stored separately from the encrypted credentials and maintained in password management software with a vendor subject to a SOC 2 Type II audit.
• Bridge Trading may migrate to an HSM-backed key management service in the future. Any material change to the key management architecture will be disclosed pursuant to Section 5.5.
• The broker-aggregator used for Path C connections is subject to a SOC 2 Type II audit.

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 are deleted from our database.
• Path B: The Broker is responsible for revoking OAuth tokens. Bridge Trading deletes stored OAuth tokens.
• Path C: SnapTrade access revoked; SnapTrade 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, including documentation 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. If you suspect your Bridge Trading account has been compromised, you are responsible for revoking Bridge Trading account credentials and notifying us immediately.

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 security of your credentials, we will notify you by email at least thirty (30) days before the change takes effect. A change is material if it: (a) introduces a new connection path that stores or processes your Broker credentials differently than described in Section 2; (b) changes the encryption algorithm, key derivation method, or key management architecture used to protect stored credentials; (c) adds a new category of subprocessor with access to credential data; or (d) changes the circumstances under which Bridge Trading personnel can access decrypted credentials.

6. Breach Notification

If we become aware that a breach in security has occurred resulting in unauthorized access to a customer information system maintained by Bridge Trading or a service provider, 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) Comply with all applicable federal and state data breach notification requirements, including state data breach notification laws.

This notification does not constitute legal advice. Depending on your jurisdiction and the nature of the incident, you may have independent notification obligations. You should consult with your own legal counsel regarding your obligations following a security incident.

7. User Requirements

This disclosure addresses how Bridge Trading handles credentials you provide to connect a Broker Account. You are responsible for implementing security controls consistent with industry best practices, including but not limited to the following:

• Using a strong, unique password for your Broker account that is not reused across other services;
• Enabling multi-factor authentication on your Broker account and on any email account used for Broker password recovery;
• Monitoring your Broker account for unauthorized activity, including reviewing transaction confirmations, account statements, and login notifications;
• Understanding the security practices, policies, and procedures of your Broker, any brokerage aggregator, or any other third-party service in the order-execution chain;
• Keeping your devices, operating systems, and browsers updated with the latest security patches;
• Avoiding accessing your Broker account or the Service from unsecured networks or shared devices.

Bridge Trading disclaims any and all liability for unauthorized access, trading losses, account compromise, data breach, or any other harm or damages of any kind resulting from your failure to adhere to the requirements described above. If you become aware of unauthorized activity in your Broker Account, contact your Broker immediately. Your Broker has the authority to freeze your account, reset credentials, and reverse unauthorized transactions where possible. You should contact your Broker before contacting Bridge Trading in such circumstances.

8. Contact

Bridge Trading Technologies LLC — 426 Waterford Drive, Cartersville, Georgia 30120

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 Technologies LLC Attn: Security