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.
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.
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/
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.
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.
A single line is sufficient and standard: "For your security, do not include account passwords or financial credentials in email."
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
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.
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
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.
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:
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.
| Protection | Include pre-launch? | Effort | Risk if omitted | Defer to v1.1? |
|---|---|---|---|---|
| "Not investment/financial advice" 1-liner | YES — now | Zero (1 line) | Low but nonzero; industry norm | No |
| Email security warning (no credentials) | YES — now | Zero (1 line) | Low; reputational | No |
| Hedged SLA language ("we aim to") | YES — use hedged phrasing only | Zero (word choice) | Moderate; contract exposure if specific | No |
| Privacy Policy link in footer | YES — at launch | Medium (draft policy) | GDPR exposure for EU users | Only if no EU users pre-launch |
| Terms of Service link in footer | YES — at launch | Medium (draft ToS) | Contract ambiguity with paid users | Only if no paid users pre-launch |
| GDPR inline mini-disclosure (until PP published) | YES — interim | Low (2 sentences) | GDPR Art. 13 gap | Replace with PP link at launch |
| Full FINRA/SEC disclaimer block | NO — not yet warranted | Medium | N/A at current status | Revisit if Raxx becomes FINRA member |
| Reg S-P privacy notice | NO — not triggered | High | N/A unless registered | Revisit if SEC registration required |
| CAN-SPAM opt-out footer | CONDITIONAL — only if autoreply is also commercial | Low | FTC penalty if commercial msg | Confirm: is autoreply purely transactional? |
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
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.
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?https://www.sec.gov/rules-regulations/statutes-regulations/investment-advisers-act-1940https://www.finra.org/rules-guidance/rulebook/finra-rules/2210https://www.finra.org/rules-guidance/notices/25-07https://www.finra.org/rules-guidance/guidance/reports/2021-finras-examination-and-risk-monitoring-program/communications-with-publichttps://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-businesshttps://www.ftc.gov/business-guidance/advertising-marketing/advertising-marketing-basicshttps://www.ftc.gov/business-guidance/resources/ftc-safeguards-rule-what-your-business-needs-knowhttps://www.ftc.gov/business-guidance/blog/2024/05/safeguards-rule-notification-requirement-now-effecthttps://www.ftc.gov/business-guidance/privacy-security/gramm-leach-bliley-acthttps://gdpr-info.eu/art-3-gdpr/https://gdpr.eu/article-6-how-to-process-personal-data-legally/https://gdpr-info.eu/art-13-gdpr/https://www.termsfeed.com/blog/gdpr-transactional-emails/https://www.socketlabs.com/blog/transactional-email-gdpr/https://oag.ca.gov/privacy/ccpahttps://www.sec.gov/newsroom/press-releases/2024-42https://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-contracthttps://elrolaw.com/blog/contract-disputes-involving-service-level-agreements-slas-are-they-enforceable-or-not/https://trendspider.com/data-disclaimers/https://www.home.saxo/en-gb/legal/disclaimer/saxo-disclaimerhttps://www.tradingview.com/disclaimer/https://www.beyondencryption.com/blog/secure-email-for-financial-services