Support Autoreply Legal Posture — support@raxx.app

Status: research-only. This document does NOT constitute legal or tax advice. Before acting on any recommendation here, consult a business/IP attorney licensed in your operating jurisdiction (Matthew Crosby for IP framing; securities counsel once engaged for FINRA/SEC perimeter questions). Last updated: 2026-05-04. Sources as of that date — verify freshness before filing or launch.

TL;DR (3 sentences)

An autoreply from support@raxx.app is a low-risk transactional communication, but three specific phrasing choices carry real legal surface area: (1) a response-time promise reads as a binding representation under US contract law if it is specific and unconditional; (2) a pre-launch platform with no published Terms of Service or Privacy Policy has GDPR Article 13 exposure if EU residents email in; (3) FINRA Rule 2210 and the SEC's "investment adviser" definition are likely not triggered by an autoreply alone, but a "not investment advice" disclaimer in the footer is cheap insurance and matches industry norm.

The biggest near-term action item: get a Terms of Service and Privacy Policy published before launch — both are cited in the GDPR and CAN-SPAM analysis below and their absence is the single largest gap.

Q1 — "Not investment advice" disclaimer: required or precautionary?

Facts

• The SEC defines an "investment adviser" under the Investment Advisers Act of 1940 as any person who, for compensation, engages in the business of advising others on securities. An automated support acknowledgment email that contains no securities recommendations does not meet any prong of the "ABCs" test (Advice, Business, Compensation). Source: 15 U.S.C. §80b-2(a)(11); https://www.sec.gov/rules-regulations/statutes-regulations/investment-advisers-act-1940

• FINRA Rule 2210 governs "communications with the public" by FINRA member firms. Raxx is not currently a FINRA member. The rule would not apply directly unless Raxx becomes a registered broker-dealer or is associated with one. Source: https://www.finra.org/rules-guidance/rulebook/finra-rules/2210 However: FINRA's AI/automated-communication guidance (2021 examination report and RN 25-07) notes that even non-members can face enforcement action if their communications are deceptive or constitute unlicensed investment advice. Source: https://www.finra.org/rules-guidance/notices/25-07

• FTC truth-in-advertising rules apply to all commercial communications. A misleading financial representation in an autoreply could, in theory, be construed as a deceptive act under FTC Act Section 5 if it implies an endorsement, guarantee, or personalized recommendation. The risk from a plain "Your ticket has been received" autoreply is negligible, but the risk increases if the autoreply body language could be read as responsive to the content of the inbound email. Source: https://www.ftc.gov/business-guidance/advertising-marketing/advertising-marketing-basics

• Industry norm: TrendSpider, Saxo, TradingView, Warrior Trading, and CrossTrade all carry "not investment advice / not financial advice" language in their footers and legal pages. It is standard boilerplate for any trading-adjacent tool regardless of regulatory status. Sources: https://trendspider.com/data-disclaimers/, https://www.home.saxo/en-gb/legal/disclaimer/saxo-disclaimer, https://www.tradingview.com/disclaimer/

Risk assessment (research framing — not legal opinion)

A generic autoreply ("We received your message — we'll get back to you soon") does not constitute investment advice. The theoretical risk is that a user sends an email asking "should I buy this stock?" and the autoreply, by virtue of being a response from a trading platform, is later argued to be implicit validation of the query. This risk is extremely low in practice, but a one-line disclaimer in the footer eliminates it entirely at zero cost.

Recommendation for counsel: Ask Matthew Crosby whether Raxx's "tool + automation, no personalized recommendations" positioning is sufficient to keep it outside the investment-adviser definition permanently, or whether any planned AI features (e.g., pattern-match suggestions surfaced to the user) could cause Raxx to re-enter the advisory definition and therefore require a more formal disclaimer regime.

Q2 — Email as an unencrypted channel: disclosure

Facts

• SMTP email in transit is not end-to-end encrypted. TLS (Transport Layer Security) encrypts the hop between mail servers but does not protect messages at rest on mail servers or in the recipient's mailbox. This is the standard technical posture of virtually all commercial email.

• The FTC Safeguards Rule (16 CFR Part 314), amended effective 2024-05-13, requires non-banking financial institutions to implement safeguards for customer information and to notify the FTC within 30 days of a breach affecting ≥500 consumers. The rule does not require an email-channel disclosure warning in support communications, but it does require Raxx to have a written information-security program if Raxx meets the definition of a "financial institution" under Gramm-Leach-Bliley. Source: https://www.ftc.gov/business-guidance/resources/ftc-safeguards-rule-what-your-business-needs-know Source: https://www.ftc.gov/business-guidance/blog/2024/05/safeguards-rule-notification-requirement-now-effect

• Whether Raxx qualifies as a "financial institution" under GLBA/Safeguards depends on whether it "provides financial products or services" including "investment advice." This is an open question that requires securities counsel to answer definitively (see Q1 above). If Raxx is a pure software tool and explicitly not advisory, GLBA coverage is uncertain — unsourced, confirm with securities counsel.

• SEC Regulation S-P (17 CFR Part 248) requires registered investment advisers and broker-dealers to protect customer financial information and to deliver a privacy notice. Raxx is currently unregistered — Reg S-P does not apply directly. But if registration is ever required, Reg S-P would mandate both a privacy notice and procedural safeguards. Source: https://www.sec.gov/rules/final/34-42974.htm

• Industry norm for fintech SaaS: support autoreplies routinely include a line such as "Please do not send account passwords or sensitive financial information via email." This is not legally required for Raxx's current status, but it is: (a) good security hygiene, (b) a signal to users that Raxx takes security seriously, and (c) protective against a user who later claims they emailed credentials and Raxx was responsible for the compromise.

What to include

A single line is sufficient and standard: "For your security, do not include account passwords or financial credentials in email."

Q3 — SLA-as-promise: "1 business day" response time

Facts

• Under US common law and the Uniform Electronic Transactions Act (UETA), emails can form binding contracts if they contain offer, acceptance, consideration, and mutual intent to be bound. UETA is enacted in 49 states plus DC; the federal E-SIGN Act covers the one remaining state. Source: https://www.uniformlaws.org/committees/community-home?CommunityKey=2c04b76c-2b7d-4399-977e-d5876ba7e034

• The critical factor for an autoreply is whether it manifests "intent to be bound." Courts applying common-law contract analysis look for: (1) definiteness of terms, (2) consideration (what the promisee gave in exchange), and (3) mutual assent. An autoreply saying "we respond within 1 business day" is an unconditional, specific, and definite representation. Multiple law-practice articles note that such a statement in a commercial email context is "at minimum a representation" and "potentially a contractual promise depending on context." Sources: https://www.bolanlawgroup.com/blog/2021/march/do-emails-create-legally-binding-contracts-/ https://www.katzlawgroup.com/at-what-point-does-an-email-become-a-binding-contract

• The counterargument: consideration is absent in most support-email relationships until the user has actually entered into a paid subscription agreement with Raxx. Pre-purchase, the "contract" argument is weak because there is no exchange of value. Post-purchase, the user has paid for a service; a stated SLA in a support email could be read as part of the service agreement.

• The safer path (confirmed by SLA-contract literature): use aspirational/hedged language rather than a hard commitment. Phrases such as "we aim to respond within 1 business day" or "typical response time is 1 business day" introduce a reasonableness standard that is far harder to hold as a contractual breach. "We will respond within 1 business day" is riskier than "we typically respond within 1 business day." Source: https://elrolaw.com/blog/contract-disputes-involving-service-level-agreements-slas-are-they-enforceable-or-not/

• The FTC angle: if Raxx publishes a response-time commitment and systematically fails to meet it, the FTC could treat this as a deceptive representation under FTC Act Section 5 in a consumer context, separate from contract enforcement. Source: https://www.ftc.gov/business-guidance/advertising-marketing/advertising-marketing-basics

Recommendation for counsel

Ask Matthew Crosby (or a contracts attorney) to review the proposed SLA language in the autoreply against the subscription agreement once drafted, to confirm the two instruments are not in conflict. Once a Terms of Service is published, the ToS likely governs and the autoreply becomes subordinate — but that subordination needs to be explicit in the ToS.

Q4 — GDPR: does the autoreply trigger a disclosure obligation?

Facts

• GDPR has extraterritorial reach. It applies to any organization outside the EU that "offers goods or services" to EU residents or "monitors" EU residents' behavior. If a single EU resident emails support@raxx.app, Raxx is processing their personal data (email address, name in signature, content of the message) and GDPR applies to that processing act. Source: GDPR Article 3(2); https://gdpr-info.eu/art-3-gdpr/

• GDPR Article 13 requires that, at the time personal data is collected from a data subject, the data controller provides: (1) identity and contact details of the controller, (2) purposes and legal basis for processing, (3) legitimate interests (if used as the lawful basis), (4) data retention period, (5) data subject rights (access, erasure, portability, objection), (6) right to lodge complaints with a supervisory authority. Source: https://gdpr-info.eu/art-13-gdpr/

• The lawful basis for processing an inbound support email is almost certainly "legitimate interests" (Article 6(1)(f)) — responding to a user's request is a legitimate business interest and the user would reasonably expect it. You do not need consent to send a transactional autoreply. Source: https://gdpr.eu/article-6-how-to-process-personal-data-legally/

• The Article 13 obligation can be satisfied by: (a) including a brief disclosure in the autoreply itself, OR (b) linking to a published Privacy Policy that contains the required information. Option (b) is the cleaner approach and the industry norm.

• If Raxx has no published Privacy Policy at the time an EU user emails, the autoreply alone does not satisfy Article 13. A link to a published policy resolves this; the absence of a policy is the gap to close.

• California Consumer Privacy Act (CCPA): CCPA thresholds are annual gross revenue over $25M, personal data of 100,000+ consumers, or deriving 50%+ of revenue from selling personal data. Raxx does not currently meet any threshold. The autoreply does not trigger a CCPA disclosure obligation at current scale. This posture should be re-evaluated at launch or first paid customer. Source: Cal. Civ. Code §1798.140; https://oag.ca.gov/privacy/ccpa

What this means for the autoreply

The autoreply footer should include a link to the Privacy Policy once it is published. Until the Privacy Policy is published, the footer should include a minimal inline disclosure (see recommended boilerplate below). This is the minimum protective posture before launch for any EU-addressable email channel.

Q5 — Industry norms for trading-platform support autoreplies

Facts and patterns observed

Based on review of public disclaimers from TrendSpider, Saxo, TradingView, CrossTrade, and Warrior Trading, the following elements appear in virtually all trading-platform support and email footers:

1. "Not investment/financial advice" language — universal
2. Link to Terms of Service — universal for any live/paid platform
3. Link to Privacy Policy — universal
4. Confidentiality notice for email content — common (especially broker-dealers, less common for pure SaaS tools)
5. Email-security warning (no credentials by email) — common in fintech
6. Response-time aspiration with hedging language ("we aim to") — common
7. No hard SLA commitment without a full support agreement — typical for SMB SaaS

For a pre-launch platform with no ToS/Privacy Policy, the autoreply is operating with below-industry-norm disclosure posture. The gap is not the autoreply itself; the gap is the missing published policies.

Decision matrix: pre-launch vs. deferrable

CAN-SPAM note: if the autoreply contains any commercial content (promotional language, product features, calls to action), it becomes a "commercial message" under CAN-SPAM and must include a physical mailing address and unsubscribe mechanism. A pure transactional acknowledgment ("We received your message") is exempt. Raxx should keep the autoreply strictly transactional until a ToS + Privacy Policy are live. Source: https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business

Recommended footer boilerplate (max 4 lines)

Raxx does not provide investment, financial, or tax advice. This email is an automated
acknowledgment — not a recommendation. For your security, do not include account
passwords or credentials in email. We aim to respond within 1 business day.
[Privacy Policy: https://raxx.app/privacy] [Terms: https://raxx.app/terms]

Notes on this block: - Line 1-2: covers the investment-advice risk (Q1) and sets expectation framing. - Line 3: email-channel security disclosure (Q2). - Line 4: aspirational SLA — "we aim to" not "we will" (Q3). - Final line: Privacy Policy + ToS links satisfy GDPR Art. 13 + CCPA + industry norm (Q4, Q5). Replace with actual published URLs at launch. Until policies are live, substitute the inline GDPR disclosure below.

Interim GDPR disclosure until Privacy Policy is published:

Your email address and message are processed by Raxx to respond to your inquiry.
We do not sell your data. Questions: support@raxx.app.

Timing / deadlines

• No statutory hard deadline on the autoreply copy itself.
• Privacy Policy and Terms of Service should be drafted and published before any paid subscription is accepted. This is the operative deadline that makes the above GDPR and SLA issues moot.
• FTC Safeguards Rule (breach notification) is already in effect as of 2024-05-13. If Raxx meets the GLBA "financial institution" definition, a written information-security program is required now, not at launch.
• GDPR does not have a "pre-launch grace period." The moment an EU resident emails Raxx, the Article 13 obligation attaches.

Questions for Matthew Crosby (IP attorney — engaged)

1. Does Raxx's positioning as a "trading tool / automation layer" (no personalized recommendations, user-defined rules only) keep it outside the SEC investment-adviser definition under the "ABCs test"? If any planned AI feature (pattern suggestions, auto-alert on earnings events) could cause re-entry, what specific line should Raxx not cross?
2. Should the "not investment advice" disclaimer be drafted by Matthew, or is the generic boilerplate sufficient for an IP/brand attorney's review scope?
3. Once a Terms of Service is drafted, does the ToS need to explicitly state that support autoresponses are not investment advice and are not part of any advisory relationship?
4. Should Raxx's support-email autoreply include a confidentiality legend (standard in attorney and financial-services email) or is that overkill for a SaaS support queue?

Questions for securities counsel (pending hire)

1. Does Raxx's paper-first + live-mode-opt-in trading tool model require any registration with the SEC or FINRA in any capacity (investment adviser, broker-dealer, trading platform, ATS)?
2. Does the autoreply from support@raxx.app — purely transactional, no recommendations — constitute a "communication with the public" subject to FINRA Rule 2210 if Raxx is not a FINRA member?
3. If Raxx integrates with a broker (Alpaca, SnapTrade BYOB) and routes orders, does that integration change the regulatory classification of Raxx's communications?
4. At what point does adding AI-generated explanations or alerts (e.g., "this trade fired because X rule matched") cross the line into investment advice under SEC or FINRA standards?

Questions for a contracts/business attorney (if not covered by Matthew Crosby)

1. Review the proposed autoreply SLA language: does "we aim to respond within 1 business day" create any enforceable obligation once a subscription agreement is in place?
2. Once a Terms of Service is published, should it explicitly subordinate all support-email communications (including autoreplies) to the ToS?
3. Is a CAN-SPAM physical address required in Raxx's autoreply if the message contains no promotional content?

Jurisdiction flags

• Federal (US): SEC Investment Advisers Act, FTC Act Section 5, CAN-SPAM, E-SIGN Act, GLBA / FTC Safeguards Rule. All apply regardless of state of formation.
• EU (all member states): GDPR Article 3(2) extraterritorial reach triggers the moment an EU resident emails. No EU physical presence required.
• UK: UK GDPR (post-Brexit) mirrors EU GDPR for data subjects in Great Britain. Same Article 13 obligations apply.
• California: CCPA does not apply at current scale. Re-evaluate at 100k records or $25M revenue threshold.
• Pennsylvania (likely home state): No state-specific email marketing law that alters the federal CAN-SPAM analysis. Pennsylvania Wiretapping Act (18 Pa. C.S. §5703) applies to interception of communications, not to transactional email — no impact here. Unsourced — confirm with PA-licensed attorney.

Sources

• SEC Investment Advisers Act of 1940: https://www.sec.gov/rules-regulations/statutes-regulations/investment-advisers-act-1940
• FINRA Rule 2210 (Communications with the Public): https://www.finra.org/rules-guidance/rulebook/finra-rules/2210
• FINRA Regulatory Notice 25-07 (AI in communications): https://www.finra.org/rules-guidance/notices/25-07
• FINRA 2021 Examination Report — Communications with the Public: https://www.finra.org/rules-guidance/guidance/reports/2021-finras-examination-and-risk-monitoring-program/communications-with-public
• FTC CAN-SPAM Act Compliance Guide: https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business
• FTC Advertising and Marketing Basics: https://www.ftc.gov/business-guidance/advertising-marketing/advertising-marketing-basics
• FTC Safeguards Rule — What Businesses Need to Know: https://www.ftc.gov/business-guidance/resources/ftc-safeguards-rule-what-your-business-needs-know
• FTC Safeguards Rule — breach notification in effect 2024-05-13: https://www.ftc.gov/business-guidance/blog/2024/05/safeguards-rule-notification-requirement-now-effect
• GLBA at the FTC: https://www.ftc.gov/business-guidance/privacy-security/gramm-leach-bliley-act
• GDPR Article 3 (territorial scope): https://gdpr-info.eu/art-3-gdpr/
• GDPR Article 6 (lawful basis): https://gdpr.eu/article-6-how-to-process-personal-data-legally/
• GDPR Article 13 (information to be provided at time of collection): https://gdpr-info.eu/art-13-gdpr/
• GDPR transactional email + legitimate interests — TermsFeed: https://www.termsfeed.com/blog/gdpr-transactional-emails/
• GDPR transactional email — SocketLabs: https://www.socketlabs.com/blog/transactional-email-gdpr/
• CCPA — California Attorney General: https://oag.ca.gov/privacy/ccpa
• SEC Internet Investment Adviser rule — SEC.gov (2024): https://www.sec.gov/newsroom/press-releases/2024-42
• Email as binding contract — Bolan Law Group: https://www.bolanlawgroup.com/blog/2021/march/do-emails-create-legally-binding-contracts-/
• Email as binding contract — Katz Law Group: https://www.katzlawgroup.com/at-what-point-does-an-email-become-a-binding-contract
• SLA enforceability — Edelboim Lieberman: https://elrolaw.com/blog/contract-disputes-involving-service-level-agreements-slas-are-they-enforceable-or-not/
• TrendSpider data disclaimers (industry norm): https://trendspider.com/data-disclaimers/
• Saxo disclaimer (industry norm): https://www.home.saxo/en-gb/legal/disclaimer/saxo-disclaimer
• TradingView disclaimer (industry norm): https://www.tradingview.com/disclaimer/
• Secure email for financial services — BeyondEncryption: https://www.beyondencryption.com/blog/secure-email-for-financial-services