Privacy Policy Attorney Review — getraxx.com — 2026-05-27

Status: research-only. This document does NOT constitute legal or tax advice. Before filing or acting, consult a privacy attorney licensed in California, familiar with CPRA/CCPA, GLBA/Reg P, FTC Section 5, and US state privacy laws. Last updated: 2026-05-27. Sources as of that date — verify freshness.

Drive filing: MooseQuest Legal / Privacy Policy Attorney Review — getraxx.com — 2026-05-27.md Prepared for: Matthew Crosby (initial triage) or a CPRA/privacy specialist referral. Reviewed file: frontend/getraxx-landing/src/pages/legal/PrivacyPolicy.jsx (post-PR #2839 merge)

TL;DR

The Privacy Policy as live at getraxx.com/privacy is a good-faith draft with two forward-looking date commitments (Section 8: Q3 2026 deletion tool; Section 6: cookie banner "in development") that should be softened before public waitlist collection begins. The 30-day email-change-notice commitment in Section 13 requires confirming that Postmark transactional sends are operationally ready to fire that notice — current pre-launch posture is digest-only. Three structural items (entity name qualifier, physical mailing address, privacy@ email routing) need operator confirmation before the attorney sign-off meeting. The policy does correctly reflect EU/Quebec geo-block, names MooseQuest LLC as data controller, routes DSRs to support@raxx.app, and contains no broker-name leaks.

Findings

Finding 1 (HIGH) — Section 8: "A self-service deletion tool is planned for 2026-Q3"

Exact text in policy (line 577–579):

"During our initial launch period, requests are processed manually. A self-service deletion tool is planned for 2026-Q3 (see issue #1686 for the manual DSR operating procedure)."

Why it is risky:

Under FTC Section 5 of the FTC Act (15 U.S.C. § 45), a company that makes a specific promise in its privacy policy about future capabilities and fails to deliver is exposed to an "unfair or deceptive act or practice" enforcement action. The FTC's 2024 annual Privacy and Data Security Update (linked below) documents enforcement actions specifically premised on misrepresentations in privacy policies. Courts and regulators treat privacy policy statements as enforceable promises — the TermsFeed/contract-risk analysis (linked below) documents courts increasingly applying contract-enforcement principles to broken privacy-policy commitments.

The specific risk: "2026-Q3" is an eight-week window from the date of this review. If the self-service deletion tool slips into Q4 2026 or 2027 (a realistic product outcome for a pre-revenue startup), this published statement becomes a documented broken promise. A CPRA-eligible user (once Raxx crosses the 100k-consumer threshold) or a California AG sweep could cite this text.

Additionally, issue #1686 is referenced publicly in the policy. GitHub issue references in a live privacy policy create a discovery artifact — an adversarial party can retrieve the issue history and use it to establish that Raxx knew the deletion tool was not yet built when the policy was published.

Recommended rewrite options (for attorney to choose between):

Option A (remove date entirely):

"During our initial launch period, requests are processed manually. We are building a self-service deletion tool; we will update this policy and notify registered users when it becomes available."

Option B (capability-based, no date):

"During our initial launch period, requests are processed manually by emailing privacy@raxx.app. A self-service deletion tool is on our development roadmap; we will announce its availability via email to registered users."

Option C (vague timeline only):

"During our initial launch period, requests are processed manually. We are developing in-product tools to make this process more convenient and will update this policy when they are available."

Attorney question: Which framing best balances consumer expectation-setting with avoiding an enforceable date commitment, given Raxx's current CPRA applicability status (voluntary, not mandatory)?

Also: Remove the GitHub issue #1686 reference from the live policy. Internal development tracking references create unnecessary discovery artifacts in a published legal document.

Finding 2 (HIGH) — Section 6: "Automated opt-out banner in development"

Exact text in policy (line 476–477, cookie table row):

"Yes — contact privacy@raxx.app to opt out. Automated opt-out banner in development"

Exact text in Section 6 body (lines 488–491):

"A cookie consent banner (issue #590) is in development and will provide in-product controls for analytics cookies. Until that banner is live, you can opt out of analytics by contacting privacy@raxx.app."

Why it is risky:

Same FTC Section 5 framework as Finding 1. "In development" creates an implied commitment. If issue #590 is deprioritized or deferred post-launch (common), the policy continues to tell users a control mechanism "is in development" that never materializes.

Again, referencing issue #590 publicly creates a discovery artifact — the issue history (scope, delays, deprioritization decisions) would be available to any adversarial party researching a CPRA complaint or FTC inquiry.

The FTC's guidance on privacy-policy accuracy (see sources below) is explicit that statements about opt-out mechanisms must reflect what is currently functional, not what is planned.

Recommended rewrite options:

Option A (remove development reference, keep manual opt-out):

"Yes — contact privacy@raxx.app to opt out."

Option B (note current mechanism only):

"Yes — email privacy@raxx.app with subject 'Analytics Opt-Out' and we will disable analytics collection for your account within 5 business days."

In both the cookie table row and the Section 6 body paragraph, remove the reference to issue #590 and the "in development" framing. Replace with current functional capability only.

Attorney question: Does the manual email-based opt-out mechanism satisfy any applicable opt-out requirement for analytics cookies under current US law given Raxx's US-only, non-CPRA-mandatory posture? If Raxx is not subject to CPRA, is there any federal requirement (FTC guidance on cookie consent)?

Finding 3 (HIGH) — Section 13: 30-day email change-notice commitment

Exact text in policy (lines 720–724):

"We will notify registered users of material changes by email and/or by a prominent notice on the platform at least 30 days before those changes take effect."

Why it is risky:

This is structurally sound CPRA/GDPR-aligned language. The risk is operational, not textual: can Raxx actually fire a policy-change email to all registered users on a 30-day cadence?

Per project memory feedback_pre_launch_digest_notifications, routine CI/Slack pings are batched into a daily digest. Postmark was approved out of sandbox (per project_postmark_approved) as of 2026-05-09. However, a mass transactional send to all registered users for a privacy-policy change is a different operational pattern from the current support-queue and alert paths. The question is whether the user-communication infrastructure (Postmark + email list management) is in place to fulfill this commitment before Raxx accepts any registered users.

This is a process question, not a rewrite question. Attorney should confirm:

1. Is the "and/or prominent notice on the platform" clause sufficient fallback if email send capacity is not operational for all registered users? (The "and/or" gives operational flexibility — retain it.)
2. Is 30 days the minimum required by CPRA Section 1798.135 or GDPR Article 13(3)? Or is this a self-imposed commitment that could be shortened to 15 days without affecting compliance posture?
3. If Raxx is voluntarily extending CPRA rights (not mandatory), is it bound to the same 30-day standard, or is any advance-notice period acceptable?

Primary source: Cal. Civ. Code § 1798.135 (CPRA right-to-opt-out notice requirements) at https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=1798.135.

Note: The "and/or prominent notice on the platform" language provides an alternative delivery channel. Retain this. Do NOT rewrite to "email only" — that closes off the fallback and converts a soft operational question into a hard broken promise if the email send fails.

Finding 4 (MEDIUM) — Section 1: Entity name qualifier creates ongoing ambiguity

Exact text in policy (lines 229–233):

"LLC formation is in progress as of the effective date of this policy; the entity name will be confirmed on the Pennsylvania Department of State certificate of organization once issued."

Issue:

Per project memory project_llc_formation_decisions, MooseQuest LLC is formed (locked 2026-05-12). If the Certificate of Organization has been issued by the PA Department of State, this qualifier is outdated and implies the entity is still pending. An outdated "in progress" qualifier in an effective privacy policy is a minor accuracy issue under FTC Section 5 and could confuse DSR processing (who is the data controller?).

Recommended action:

Operator should confirm: has the PA Department of State issued the Certificate of Organization? If yes, replace the qualifier sentence with:

"MooseQuest LLC is a Pennsylvania limited liability company registered with the Pennsylvania Department of State."

If the certificate has not yet been issued, the qualifier is accurate and should remain until formation is complete. Attorney should confirm the operator's current formation status at the meeting.

Finding 5 (MEDIUM) — Section 14: Physical mailing address placeholder

Exact text in policy (lines 735–736):

"Mailing address: MooseQuest LLC, Pennsylvania (specific mailing address to be added upon LLC formation completion)"

Issue:

This placeholder creates two problems: (1) it is factually incomplete, which reduces the policy's credibility as a published document; (2) some state privacy laws and FTC guidance require a disclosed mailing address for DSR submission (in addition to email). Cal. Civ. Code § 1798.130(a)(1) requires businesses subject to CCPA/CPRA to provide at least two methods for consumers to submit requests, including a mailing address. Raxx is voluntarily extending CPRA rights — attorney should confirm whether the voluntary extension carries the same mailing-address disclosure obligation.

Recommended action:

Before the policy goes live for waitlist collection: 1. Confirm MooseQuest LLC's registered agent address (Northwest Registered Agent, per formation records) is appropriate to list as the mailing address, or use a PO Box. 2. Replace the placeholder with the actual address.

Attorney question: Is a registered agent address appropriate to list as the CPRA/FTC mailing address for DSR submissions, or does Raxx need a separate physical or PO Box address?

Finding 6 (LOW) — Effective date vs. last-updated date discrepancy

Exact text in policy (lines 204–207):

"Effective date: 2026-05-23 UTC | Last updated: 2026-05-13 UTC"

Issue:

The effective date (2026-05-23 UTC) is 10 days after the last-updated date (2026-05-13 UTC). This is a common practice (publishing in advance of the effective date) and is not inherently problematic. However, it means the policy was purportedly effective on 2026-05-23 UTC but the "Last Updated" date predates that. When rewrites are made per the above findings, both dates should be updated to reflect the actual revision date.

Recommended action: After attorney sign-off and before any rewrites are deployed, update both "Effective date" and "Last updated" to the actual date of attorney-reviewed revision.

Finding 7 (LOW) — privacy@ email alias not confirmed to be operational

Text in policy: privacy@raxx.app appears 7 times as the primary contact for privacy requests, DSRs, analytics opt-out, children's privacy, and security disclosures.

Issue: Per project memory project_email_addresses, the confirmed sender addresses are no-reply@, support@, and ops@. privacy@raxx.app is referenced in the policy but operator should confirm: (a) is this alias provisioned? (b) does it route to the FreeScout ticket queue (support@) or to a separate inbox? (c) is there an SLA or documented response process for this address?

This is an operational confirm, not a legal rewrite. But if privacy@raxx.app bounces or is unmonitored, a DSR submitted to it would go unanswered — which is itself a CPRA violation risk for any voluntary right Raxx has extended.

Cross-check Results

EU/Quebec geo-block consistency — PASS

Section 1 (line 243–248) and Section 9 (lines 595–614) both clearly state that: - EU/EEA signups are blocked at account creation - Quebec signups are blocked at account creation - Policy explicitly states "this policy does not govern residents of those regions because we do not knowingly accept them as users"

This is consistent with project_eu_geoblock_decision and project_quebec_geoblock_decision. No misrepresentation of EU/Quebec user acceptance. PASS.

Data controller named correctly — PASS with caveat

Section 1 names "MooseQuest LLC" as the legal entity. The entity holds and processes user data. "Raxx" and "Raxx Platform" are the trade names. This is consistent with project_llc_formation_decisions. The caveat is Finding 4 above — the "in progress" qualifier needs updating once the certificate is issued.

Contact email for DSRs — PASS

Section 8 (line 573) directs DSRs to privacy@raxx.app. Section 14 lists both privacy@raxx.app (privacy requests) and support@raxx.app (general support). No personal email addresses appear anywhere in the policy. This is correct per project_email_addresses. PASS — subject to Finding 7 (confirm privacy@ is operational).

Broker-name leaks — PASS

Section 4 describes broker connection through "a regulated aggregator" and "your broker, accessed via a regulated aggregator." Section 5 refers to "a regulated broker aggregator service." No vendor names (Alpaca, SnapTrade) appear anywhere in the policy. PASS per feedback_no_backend_branding.

Forward-looking language audit (beyond three flagged items) — THREE ADDITIONAL ITEMS

Beyond Findings 1 and 2, the following forward-looking phrases appear:

FLF-1 (LOW): Section 10 (lines 655–661):

"If Raxx's service model evolves such that it becomes subject to the Gramm-Leach-Bliley Act as a financial institution... We will assess that question with counsel and update this policy accordingly."

This is acceptable hedging language — "if...evolves" and "will assess" are conditional on a future state. No specific date or feature commitment. ACCEPTABLE AS-IS.

FLF-2 (LOW): DraftBanner component (lines 174–179):

"Substantive changes may be made before 2026-06-30 UTC following review by a licensed privacy attorney."

This is a banner flagging the draft status. Once the attorney review is complete and the banner is removed, this is no longer an issue. However, if the attorney review takes longer than 2026-06-30 UTC, the banner's date commitment becomes inaccurate. Attorney should confirm the review timeline.

FLF-3 (LOW): Section 9 (line 612):

"If you believe your signup was incorrectly blocked, contact support@raxx.app."

This implies a review process exists for blocked signups. If Raxx's policy is to never create accounts for residents of blocked regions (which Section 9 also states), this sentence creates a potentially misleading implication of appealability. Attorney should confirm: is there a legitimate use case for reviewing blocked signups (e.g., a US resident traveling in the EU), and if so, is the current process documented?

Summary Table for Attorney Meeting

Questions for the attorney (privacy/CPRA specialist)

P1. For Findings 1 and 2: Which rewrite option (A, B, or C for Finding 1; A or B for Finding 2) best minimizes enforcement risk while preserving good-faith consumer disclosure?

P2. For Finding 3: Does the voluntary extension of CPRA rights bind Raxx to the same notice mechanics (30-day advance email) as a mandatory CPRA-covered business? If not, what is the minimum enforceable standard?

P3. Is the DraftBanner component — which explicitly states the policy is "a draft" and that "substantive changes may be made" — sufficient to limit reliance claims by users who used the platform during the draft period? Or does the "effective date: 2026-05-23 UTC" create full reliance regardless of the banner?

P4. The policy references GitHub issue numbers (#1686, #590) in the published text. Does this create any discovery or evidentiary exposure? Recommendation: whether to remove all internal issue references before final publication.

P5. Section 10 cites a "good-faith self-determination (signed 2026-05-13 UTC)" that Raxx does not meet CCPA/CPRA applicability thresholds. Is a signed internal memorandum sufficient documentation for this determination? If Raxx grows to meet thresholds, is this determination document material in any way?

P6. Section 11 cites Cal. Civ. Code § 1798.150 (private right of action for data breach). Is it advisable to cite this statute proactively in the policy? Does citation constitute an acknowledgment that Raxx is subject to CCPA/CPRA data-breach provisions, or is this simply informational?

P7. The policy covers both getraxx.com (landing/waitlist) and raxx.app (the trading platform). At the waitlist stage (FLAG_WAITLIST_DATASTORE not yet flipped), the only data collected is email addresses for waitlist signup. Does a single unified Privacy Policy covering both surfaces create any coverage-mismatch risk during the period when only the waitlist is live?

Recommended professional

Primary: Privacy attorney licensed in California, familiar with CPRA/CCPA, FTC Section 5, and US state privacy laws (not Matthew Crosby — his practice is IP and trademark; this review requires a separate privacy/consumer-protection specialist).

Secondary confirm: Matthew Crosby can confirm that the policy does not create any trademark-related representations that conflict with the pending RAXX trademark strategy.

Estimated cost: Privacy-policy review by a solo CPRA-specialist or boutique: $1,500–$4,000 flat for review and redline (unsourced estimate — confirm with counsel). If the attorney also drafts the Terms of Service (Section F, questions-for-attorney.md), expect $3,000–$8,000 combined (unsourced — confirm). Litigation-boutique rates ($400–$700/hr) would put a 5-hour review at $2,000–$3,500.

Policy deployment gate

Can the policy be approved AS-IS and the waitlist flag flipped immediately?

No. At minimum, the following must be completed before FLAG_WAITLIST_DATASTORE is flipped:

1. Finding 5: Physical mailing address placeholder must be replaced with an actual address.
2. Finding 7: Confirm privacy@raxx.app is provisioned and routed.
3. Finding 4: Confirm "LLC formation in progress" qualifier is updated if the PA certificate has been issued.
4. Findings 1 + 2: Attorney sign-off on forward-looking language rewrite OR explicit attorney confirmation that the current language is acceptable given Raxx's pre-CPRA-threshold status.

Items 1–3 are operator actions, not attorney decisions. Items 1 and 3 are less than one hour of work once the underlying facts are confirmed. Finding 2 (removing issue references and "in development" language) is a 15-minute code change.

If Kristerpher can confirm the LLC is formed and the mailing address is available, and privacy@ is provisioned, the policy can be ready for attorney final review within 24–48 hours of those confirms.

Sources

• Cal. Civ. Code § 1798.130 (CPRA DSR response timeframes): https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=1798.130.

• Cal. Civ. Code § 1798.135 (CPRA right-to-opt-out notice): https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=1798.135.

• Cal. Code Regs. Tit. 11, § 7021 (timelines for responding to delete/correct/know requests): https://www.law.cornell.edu/regulations/california/11-CCR-7021

• FTC Privacy and Data Security Enforcement (primary): https://www.ftc.gov/news-events/topics/protecting-consumer-privacy-security/privacy-security-enforcement

• FTC 2024 Privacy and Data Security Update (PDF — Blackbaud, Avast, InMarket enforcement): https://www.ftc.gov/system/files/ftc_gov/pdf/2024.03.21-PrivacyandDataSecurityUpdate-508.pdf

• IAPP — CPRA right to delete operational impacts: https://iapp.org/news/a/top-10-operational-impacts-of-the-cpra-part-8-rights-to-delete-no-retaliation-and-childrens-privacy

• TermsFeed — privacy policy as enforceable contract risk: https://www.termsfeed.com/blog/privacy-policy-contract-risk/

• California AG CCPA page (primary enforcement authority): https://www.oag.ca.gov/privacy/ccpa

• CPPA first enforcement advisory (2024): https://www.wilmerhale.com/en/insights/blogs/wilmerhale-privacy-and-cybersecurity-law/20240410-california-privacy-protection-agency-issues-first-ever-enforcement-advisory

• FTC Section 5 data retention standalone unfairness (Blackbaud): https://perkinscoie.com/insights/update/ftc-brings-first-standalone-section-5-unfairness-claims-unreasonable-data-retention

• PA Dept of State — LLC formation (formation status reference): https://www.dos.pa.gov/BusinessCharities/Business/RegistrationForms/Pages/default.aspx

Before acting on this document, consult a privacy attorney licensed in California and familiar with CPRA/CCPA, FTC Section 5, and US state privacy laws. This document is preparation material for that consultation, not a substitute for it.