Raxx · internal docs

internal · gated

Questions for the attorney — first consult

Use this document as your consult agenda. Take it into the meeting; the background and primary sources are already staged in the sibling research docs so the attorney can jump straight to the judgment calls.

Consult structure

First consult typically runs 60–90 minutes and should cover: (a) entity choice + state of formation, (b) trademark posture (MOOSEQUEST + Raxx), (c) IP-assignment plan, (d) engagement + fee structure going forward.

A) Engagement and fee framing (ask first)

  1. What's your hourly rate, and do you offer flat-fee packages for entity formation + founder agreements + trademark assignment?
  2. Can you represent me on both entity formation AND trademark matters, or does trademark work need a separate practitioner registered with the USPTO?
  3. Do you use any client portal (Clio, MyCase)? Preferred comms channel?
  4. Do you handle the FinCEN BOI report (Corporate Transparency Act) as part of formation, or is that a separate scope?
  5. Do you handle Delaware formations + foreign qualification if I form in DE and operate elsewhere, or do you refer Delaware work out?

B) Entity structure + state of formation

(Background: entity-structure.md, state-of-formation.md.)

  1. For a solo-founder pre-revenue SaaS (options-trading retail tooling) in [home state — to be filled in], do you recommend a single-member LLC, an LLC with S-Corp election, or a Delaware C-Corp? Why?
  2. If we form in my home state, are there any home-state-specific traps (charging-order weakness, single-member LLC veil-piercing concerns, publication requirements) I should plan for?
  3. If we form in Delaware or Wyoming while operating in [home state], is foreign qualification in [home state] mandatory for a remote SaaS? What specific activity triggers the "transacting business" test in [home state]?
  4. Should I have a holding LLC for IP and an operating LLC for revenue now, or is that overkill pre-revenue? What's the breakeven point where it becomes worthwhile?
  5. If I might raise angel / VC capital in 12–24 months, should I form as a Delaware C-Corp now to start the QSBS § 1202 five-year holding-period clock? Or is it cleaner to form as an LLC and convert later?
  6. Any reason to use a Series LLC or an Umbrella LLC structure here?

C) Trademark — MOOSEQUEST status + strategy

(Background: trademark-moosequest.md.)

  1. I'll pull the MOOSEQUEST record from USPTO TSDR before we talk — here it is: [attach pulled record showing serial, registration number, status, classes, filing and registration dates, owner of record, register]. Is the registration currently in good standing?
  2. Are there any defects in the current MOOSEQUEST filing (over-broad ID of goods/services, weak specimens, unrecorded ownership change) that I should correct before the next §8 or §§8+9 window?
  3. When should I file the next maintenance filing, and what's your fee (separate from USPTO filing fees per trademark-moosequest.md)?
  4. Should MOOSEQUEST be assigned to the future Raxx LLC, or kept in my personal name and licensed to the entity? What are the tax, asset-protection, and estate-planning implications of each path?
  5. If we assign, can you draft the assignment (with goodwill) and handle ETAS recordation?

D) Trademark — Raxx new filing

  1. Can you run a formal clearance search on RAXX in IC 009, IC 036, IC 041, and IC 042? Fee?
  2. Given Raxx is pre-launch, do you recommend a §1(b) intent-to-use filing now, or waiting for a §1(a) use-based filing post-launch? Tradeoffs (cost, speed, priority date, extension fees)?
  3. What's the right class strategy — file in one class and expand later, or file in all relevant classes at once?
  4. Any concern that "Raxx" reads close to existing marks in financial services, fintech, or software? If so, brand-pivot cost/benefit before filing?

E) IP assignment + founder agreements

  1. All Raxx work to date (code, designs, trademarks, brand) was done by me personally before entity formation. Do I need a founder's IP-assignment agreement transferring that pre-formation work into the new entity on day 1? Can you draft one?
  2. If I retain any contractors (even short-term), what IP-assignment clauses should be in their contracts by default?
  3. Any open-source licensing obligations I should audit in the Raxx codebase before it transfers to the entity? (Likely not attorney scope directly, but flag if you see issues.)

F) Contracts and policies (for the roadmap, not necessarily this consult)

  1. Who drafts Raxx's Terms of Service, Privacy Policy, and Subscription Agreement? Do you have a SaaS package?
  2. GDPR and CCPA posture for a US-based SaaS with some international users — do we need a data-processing addendum template, and when?
  3. Any financial-services disclaimer language required on a retail-facing options-trading tool? Is Raxx a trading tool that triggers FINRA / SEC considerations, or is it firmly an analytical tool outside that regulatory perimeter? (This may be outside the attorney's scope — may need a securities attorney.)

H) Data licensing (added 2026-04-23) — historical options-chain data for MBT backtester

(Background: docs/data-science/historical-options-data-vendors.md. Priority: HIGH — this is the hard blocker flagged in markov-fit-analysis.md before any backtest work begins.)

Context: Raxx's MBT paper-trading engine includes a mbt.run_backtest function. Users trigger backtests on the server; the backtest consumes historical options chain data internally and returns computed results (P&L, win rate, drawdown) to the user. No raw options chain data is passed through to or stored by the user. The underlying data candidates are ORATS (historical API) and potentially Databento (OPRA).

  1. OPRA non-display use classification. OPRA charges a $1,500/mo redistributor fee for anyone who displays OPRA data to third parties. If Raxx's MBT backtester uses historical options chain data server-side only — computing results, never transmitting raw chain data to users — does this qualify as "non-display use" under OPRA's fee schedule, avoiding the redistribution fee? Primary source to review: https://www.opraplan.com/faqs and https://www.marketdata.app/education/options/opra-fees/

  2. ORATS enterprise terms review. ORATS's standard retail API terms state "internal business purposes only" and prohibit distribution/redistribution to third parties, with a single-user license. Review ORATS's enterprise/commercial agreement (obtainable by contacting ORATS sales). Specific questions: (a) Does running backtests on behalf of paying users (server-side computation, results returned to users) constitute "redistribution" or "internal use" under ORATS's terms? (b) Does caching ORATS data in Raxx's database for repeated backtest access constitute redistribution? (c) Does surfacing regime-state signals derived from ORATS IV data (e.g., a regime-probability score shown in Antlers) constitute redistribution of the underlying data? Primary source: https://orats.com/terms-conditions

  3. Polygon.io enterprise vs. standard terms. Polygon.io's standard plan terms explicitly prohibit "business or commercial purposes" and redistribution. Review their enterprise/business tier agreement. Is the enterprise tier's scope sufficient for Raxx's server-side backtest use case, and what are the governing terms for "display use only" vs. computational use? Primary source: https://polygon.io/legal/market-data-terms-of-service

  4. Alpaca redistribution scope. Alpaca support documentation states data cannot be "redistributed for business purposes." Does Raxx's use of Alpaca options chain data to simulate fills in MBT's real-time paper-trading engine (server-side, never passed to users as raw data) constitute "redistribution" under Alpaca's definition, or is it covered by the subscription as a typical API consumer? Primary source: https://alpaca.markets/support/redistribute-alpaca-api

  5. EU data transfer flag. If Raxx onboards EU users in the future, does the data-vendor relationship (ORATS or Databento) require a GDPR Article 46 transfer mechanism (standard contractual clauses) in addition to the commercial license?

Priority for this consult: H1 and H2 are the highest-priority questions from this section. H1 determines whether the entire backtest architecture is viable under OPRA rules. H2 determines whether ORATS is the right vendor.

(Background: docs/business/2026-05-04-support-autoreply-legal-posture.md. Priority: MEDIUM — needed before launch; not a blocker for pre-launch testing.)

Context: Raxx's support queue (support@raxx.app) fires an automated acknowledgment to any inbound email. The autoreply will include a disclaimer footer. The platform has no published Terms of Service or Privacy Policy as of 2026-05-04. These questions should be addressed before the first paid subscription is accepted.

  1. SEC investment-adviser perimeter. Does Raxx's positioning — automation layer, user-defined rules, no personalized recommendations — keep it outside the SEC investment-adviser definition under the Advisers Act ABCs test? If any planned feature (AI-surfaced pattern suggestions, earnings-event alerts, regime indicators) could cause re-entry into the advisory definition, what is the specific line Raxx should not cross without a formal opinion?

  2. "Not investment advice" disclaimer adequacy. Is the following footer language sufficient to rebut any claim that the autoreply constitutes investment advice: "Raxx does not provide investment, financial, or tax advice. This email is an automated acknowledgment — not a recommendation." Or should this be more specific (reference to Investment Advisers Act, mention of no SEC registration, etc.)?

  3. SLA language review. Does "we aim to respond within 1 business day" in the autoreply create any enforceable obligation once a subscription agreement is signed? Should the Terms of Service explicitly subordinate all support communications to the ToS?

  4. ToS + Privacy Policy drafting scope. Can you draft both the Terms of Service and Privacy Policy for a SaaS trading-tools platform at a flat fee? What must the Privacy Policy include to satisfy both GDPR Article 13 and CCPA Section 1798.100?

  5. CAN-SPAM physical address. Does Raxx's support autoreply — which contains no promotional content — require a physical mailing address and unsubscribe mechanism under the CAN-SPAM Act? Or does the "transactional or relationship message" exemption apply cleanly?

  6. Confidentiality legend. Should the autoreply include an email confidentiality notice ("This email may contain confidential information…")? Is that protective or purely theatrical for a SaaS support queue?

Priority for this consult: I1 (investment-adviser perimeter) and I4 (ToS/Privacy Policy drafting scope) are the highest-priority questions in this section. I1 has implications for the entire product roadmap. I4 is the shortest path to closing the GDPR gap.

J) GitHub org creation before LLC formation — authority, IP, and DBA (added 2026-05-06)

(Background: docs/legal/research/github-org-pre-llc-2026-05-06.md. Priority: HIGH — J1 and J2 should be resolved before the repo transfer from MooseQuest/TradeMasterAPI to raxx-app/TradeMasterAPI is treated as permanent. J3 may have a 40-day hard deadline — see Timing section of that doc.)

Context: On 2026-05-06, Kristerpher created a GitHub organization (raxx-app, https://github.com/raxx-app) on the GitHub Team plan ($4/user/month), entering "Raxx" as the business name and accepting GitHub's Customer Agreement attestation ("I hereby accept the GitHub Customer Agreement on behalf of my organization and confirm that I have the authority to do so") — before any LLC or corporation named "Raxx" is filed with any state. The next step is transferring MooseQuest/TradeMasterAPI to raxx-app/TradeMasterAPI.

  1. Authority attestation risk. Kristerpher accepted GitHub's Customer Agreement attestation on behalf of "Raxx" before any Raxx entity legally exists. Does this attestation create personal liability exposure? Does it create a contract-formation defect (i.e., is the agreement void or voidable because one named "party" has no legal existence)? What — if anything — should be done to correct the record once Raxx LLC is formed?

  2. IP chain of title — org transfer mechanics. When Raxx LLC is formed, what is the cleanest documented path to: (a) transfer GitHub org ownership from Kristerpher's personal control to the LLC, and (b) ensure the IP assignment to the LLC (code, designs, trademarks) is consistent with and contemporaneous to the GH org ownership change? Is a founder IP-assignment agreement + org ownership transfer sufficient, or is a bill of sale or additional instrument needed?

  3. DBA / fictitious name risk — California. California Business and Professions Code §17910 requires a fictitious business name filing within 40 days when a sole proprietor transacts business under a name not containing their legal surname. Kristerpher spends ~4 months/year in California. By entering "Raxx" as the GitHub org business name and using the org for commercial development activity while in CA, has the CA DBA filing window opened? If so, which county clerk is correct, and what is the newspaper-publication requirement? Primary source: https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=BPC&sectionNum=17910.

  4. DBA / fictitious name risk — Pennsylvania. Does the same scenario trigger a PA fictitious name registration? What is the fee and process, and does it interact with or precede LLC formation?

  5. Trademark owner matching. USPTO Reg. 7779396 records a specific owner. The GitHub org now publicly names "Raxx" as the business. Once Raxx LLC is formed, should the ETAS trademark assignment from the current owner of record to Raxx LLC be executed before the LLC is publicly associated with the raxx-app org (e.g., on getraxx.com), or is the sequence flexible? What is the risk of operating publicly under a mark whose ETAS assignment has not yet been recorded?

  6. GitHub ToS interaction with securities-adjacent code. Raxx's private repos contain Raptor (backend) and MQ-A (algo layer), which are adjacent to securities-execution tooling. Does the GitHub Data Protection Agreement's data-controller / data-processor framing create any obligation for Raxx as data controller once the GH org houses production code that processes user trade data? Any GitHub ToS clause that would restrict housing such code in a private org repo? Primary sources: https://github.com/customer-terms/github-data-protection-agreement and https://docs.github.com/en/site-policy/github-terms/github-corporate-terms-of-service

Priority for this consult: J1 and J2 are highest priority — resolve before the repo transfer is made permanent. J3 may have a hard deadline of approx. 2026-06-15 (40 days from 2026-05-06) under Cal. BPC §17910 — flag this date at the top of the consult.

K) RAXX trademark §2(d) conflict — Crosby signal 2026-05-05 (added 2026-05-06)

(Background: docs/legal/research/raxx-tm-conflict-analysis-2026-05-06.md, docs/legal/research/ramp-payment-solutions-raxx-ownership-2026-04-30.md. Priority: HIGH — Matthew Crosby replied 2026-05-05 18:13 UTC signaling that the proposed identification amendment does not materially reduce §2(d) risk. Decision required before filing or pivoting.)

Context: The cited RAXX registration (Reg. 7779396, Ramp Payment Solutions LLC, Class 36) covers broad payment-processing and financial-transaction services. Crosby confirmed the USPTO will analyze the cited registration's identification text — not the registrant's actual commerce (bar/restaurant POS in Wisconsin) — when assessing likelihood of confusion under TMEP § 1207.01(a)(iii). Raxx's tightened identification (options trading software, Classes 9 and 42) is in different classes but the financial-technology surface overlap may still trigger a §2(d) refusal. The GitHub org github.com/raxx-app (business name "Raxx") was created 2026-05-05 UTC, increasing brand investment in RAXX. No trademark application has yet been filed.

  1. §2(d) probability assessment. Given the cited registration's full identification text (provided in Crosby's 2026-05-05 letter), what is your current assessment of likelihood-of-confusion probability for our application as filed with the tightened description? Is this "likely OA / winnable response" or "near-certain OA / outcome uncertain"? What is the probability of successful registration after OA response?

  2. §14 cancellation vulnerability. Is Reg. 7779396 vulnerable to cancellation under 15 U.S.C. § 1064? (a) Pull the TSDR file wrapper on Serial 97826727 — does the specimen actually support the breadth of the identification, particularly "financial transaction services" and "online payment platform"? (b) What is the exact registration date of Reg. 7779396, and is the 5-year incontestability window still open? (c) Given that Ramp Payment Solutions appears to be actively using the mark (raxxpay.com, active annual DFI filings), is a non-use cancellation petition viable?

  3. Coexistence agreement feasibility. Should we proactively approach Ramp Payment Solutions LLC (CEO: Pam Koski, raxxpay.com) about a consent/coexistence agreement? What is the realistic probability they would consent given their profile (small regional Wisconsin MSP, no identified IP counsel, no TTAB history)? What leverage do we have, and what might they ask for?

  4. Office action cost + timeline. If we file and receive a §2(d) OA, what is the realistic attorney-fee budget for OA response through final disposition? What is the timeline from filing to registration assuming one OA round? Two OA rounds?

  5. Brand pivot threshold. At what point does the §2(d) risk and expected contest cost exceed the cost of a brand pivot? The operator has created github.com/raxx-app (2026-05-05 UTC), holds raxx.app and getraxx.com, and has a growing codebase under the Raxx name. What is your recommendation on the pivot-vs-fight decision at this brand investment level?

  6. GitHub org interaction with conflict analysis. Does the creation of github.com/raxx-app (business name "Raxx," 2026-05-05 UTC) affect the channels-of-trade distinction argument in any way that is useful for a potential OA response? Does it establish or support a date-of-use record worth documenting?

Priority: K1 and K2 are the highest-priority questions in this section. K1 determines whether to file at all; K2 determines whether the cited registration itself can be removed. These questions should be addressed in the next communication with Crosby before any filing decision is made.

L) i18n launch language — securities law + language-compliance questions (added 2026-05-09)

(Background: docs/legal/research/i18n-launch-language-research-2026-05-09.md. Priority: CRITICAL — v1 launch is 2026-05-23 UTC. Quebec deadline has already passed. Resolve L1 before any Canadian signups are accepted.)

Context: Raxx is evaluating which languages to support at v1 launch (2026-05-23 UTC) and in the 60–90 days following. The platform accepts retail users and provides structured options-trading automation, backtest results, and signal-layer analysis. The research doc at the path above covers all 14 target markets. This section flags the questions that require licensed-counsel determination.

  1. Quebec French — geo-block vs. French parity (CRITICAL — pre-launch). Quebec Bill 96 / Law 14 commercial document obligations entered force June 1, 2025 (ToS contracts of adhesion online: July 11, 2024). If Raxx currently has any Quebec-resident users or will passively accept Canadian signups without geographic restriction, is the French obligation already active? Is a geo-block at signup sufficient to eliminate the obligation until French parity is ready? What constitutes a legally effective geo-block under Quebec law (IP restriction, billing-address restriction, explicit attestation)? Primary sources: RSQ c C-11 (Charter of the French Language); Law 14 (Bill 96); https://www.quebec.ca/en/government/policies-orientations/french-language/modernization-charter-french-language

  2. SEC investment-adviser perimeter — non-US users. If Raxx accepts users from UK, Australia, Singapore, or Canada (post-v1), does serving non-US users change the SEC investment-adviser registration analysis? Does the extraterritorial reach of the IA Act apply to a US-domiciled platform with foreign retail users?

  3. UK financial promotion. Does Raxx's current product — backtested strategy results, options trade signals, iron condor automation — constitute a "financial promotion" under FSMA 2000 Section 21 if communicated to UK residents? If so, what is the most efficient path to FCA authorized-person approval or exemption before any UK marketing?

  4. SEC Marketing Rule — backtested performance. Raxx's backtest engine produces historical performance results for user-defined strategies. Under Rule 206(4)-1(d)(2), backtested performance in advertisements requires specific disclosures. Does presenting backtested results within the product UI (not in marketing materials) trigger the Marketing Rule? If Raxx is not a registered investment adviser, does Rule 206(4)-1 apply at all, and what is the applicable disclosure standard for backtested performance in customer-facing product interfaces? Primary source: https://www.sec.gov/files/rules/final/2020/ia-5653.pdf

  5. Australia AFSL — "financial product advice" classification. Does Raxx's signal-layer output (regime indicators, strategy automation, earnings-event alerts) constitute "financial product advice" under Corporations Act 2001 (Cth) s 766B? If yes, an Australian Financial Services Licence (AFSL) is required before accepting Australian retail clients. Obtain an opinion from AU-licensed securities counsel.

  6. California Spanish-language disclosure. California has Spanish-language disclosure requirements for certain financial products under California Financing Law (DFPI). Do any of Raxx's product categories (investment advisory tools, subscription software for financial decisions, options automation) fall within the DFPI's Spanish-language disclosure mandate? Primary source: https://dfpi.ca.gov/regulated-industries/california-financing-law/

  7. MiFID II prescribed investor warnings — obtain exact text. For Germany (BaFin), France (AMF), Spain (CNMV), and Netherlands (AFM): obtain the current prescribed investor-warning text that Raxx would be required to display for retail clients in each jurisdiction. This text is needed before any EU-market translation work begins.

Attorney type needed for this section: L1 = Quebec-admitted attorney (Barreau du Québec member) or Quebec-specialist at a national firm. L2–L4 = US securities attorney with IA Act expertise. L3 = UK-licensed FCA specialist. L5 = AU-licensed securities counsel. L7 = EU-licensed MiFID II specialist (each NCA jurisdiction).

Priority for this consult: L1 is pre-launch critical (2026-05-23 UTC is 14 days away). L4 (backtested performance disclosure) should be resolved before any user sees backtest output in production. L2, L3, L5 can follow in the first 60-day post-launch window if non-US marketing has not yet begun.

(Background: docs/business/legal-research/customer-tax-features-legal-posture-2026-05-20.md. Priority: HIGH — these questions gate the entire tax-feature product roadmap. Resolve O1 and O4 before any tax-adjacent feature ships to production customers.)

Attorney type needed: tax attorney with fintech and Investment Advisers Act background. This is a different specialty from the trademark/formation attorney doing sections A–K. Candidate firms are listed in §10.1 of the background doc. Duane Morris (Philadelphia) and Faegre Drinker (Philadelphia) are the highest-priority contacts given PA domicile and documented robo-adviser / Investment Advisers Act experience.

O1. Investment Advisers Act perimeter for data-display tax features. Does surfacing wash-sale warnings, §1256 contract tags, holding-period indicators, and unrealized-gain-by-lot information — without executing any trades, making personalized recommendations, or taking discretion over assets — keep Raxx outside the §202(a)(11) definition of "investment adviser"? What is the specific product behavior that crosses the line, stated precisely enough that an engineering team can build to it?

O2. Cross-account wash-sale gap disclosure — duty to warn. Raxx can only detect wash sales in connected accounts. IRS § 1091 applies across spousal accounts and IRA/Roth IRA accounts that Raxx cannot see. Does surfacing within-account wash-sale detection create any affirmative duty to disclose the limitation for unconnected accounts? Is the disclaimer language in §9.2 of the background doc sufficient, or is a more specific disclosure required?

O3. §1256 auto-tagging — reliance on third-party qualified-board list. If Raxx tags a contract as "§1256 qualifying" based on the EY annual qualified-board list and that tag is incorrect for a given customer's situation, what is Raxx's liability exposure? Does a "appears to qualify — verify with your broker and tax professional" framing limit that exposure, or is there a stronger safe-harbor structure?

O4. User-directed lot preference vs. specific-lot recommendation — where is the line? If the product allows a user to set a preference ("minimize short-term gains") and then shows which specific lot would be selected given that preference — is that materially different from recommending a specific lot? Does the user's prior stated preference protect Raxx from an "advice" characterization, or does surfacing a specific lot in a specific moment cross the line regardless of the preference UI?

O5. Automated tax-loss harvesting execution — minimum registration threshold. If Raxx ever adds a feature that automatically sells a losing position and buys a correlated substitute (classic TLH): what SEC registration would be required? Is there any standing-instruction structure that keeps Raxx below the RIA threshold? What precedent exists from non-RIA platforms that execute user-defined tax-optimization rules without discretionary management?

O6. Disclaimer placement adequacy under Investment Advisers Act. Is proximate-to-data disclaimer language (§9 of background doc) sufficient, or must the disclaimer appear in a signed client agreement, a Form ADV equivalent, or a registered disclosure document? What placement standard do registered fintech investment advisers use as a baseline?

Priority for this consult: O1 and O4 are the highest-priority questions — they gate every tax-adjacent feature in the product backlog. O2 and O3 are high priority and should be resolved before any wash-sale or §1256 feature ships. O5 and O6 can follow in the first 60-day post-launch window if automated TLH is not in v1 scope.

Questions by priority

Must answer this consult: - B1, B2, B3 (entity + state) - C1, C2, C4 (MOOSEQUEST status + assignment) - E1 (founder IP assignment) - H1, H2 (data licensing — hard blocker for MBT backtester) - J1, J2 (GH org authority attestation + IP chain of title — resolve before repo transfer) - K1, K2 (RAXX §2(d) probability + §14 cancellation vulnerability — URGENT) - L1 (Quebec geo-block vs. French parity — PRE-LAUNCH CRITICAL, 2026-05-23 UTC) - L4 (SEC Marketing Rule — backtested performance disclosure in product UI) - O1 (IA Act perimeter for data-display tax features — gates entire tax feature roadmap) - O4 (user-directed lot preference vs. specific-lot recommendation — gates lot display feature)

Has potential hard deadline (approx. 2026-06-15): - J3 (CA DBA filing — 40 days from 2026-05-06 under Cal. BPC §17910)

Would be valuable: - A1–A5 (engagement terms) - D1, D2 (Raxx clearance + filing timing) - F3 (securities perimeter) - H3, H4 (Polygon + Alpaca licensing scope) - I1, I4 (investment-adviser perimeter + ToS/PP drafting scope) - J4, J5 (PA DBA + trademark sequence) - K3, K4 (coexistence agreement + OA cost/timeline) - L2 (SEC IA Act extraterritorial reach for non-US retail users) - L6 (CA Spanish-language disclosure applicability) - O2, O3 (cross-account wash-sale gap disclosure; §1256 tagging liability)

Can defer to follow-up (60-day post-launch window): - B4, B5, B6 (holding structure, QSBS, Series LLC) - D3, D4 (Raxx class strategy, brand-pivot analysis) - E2 (contractor IP template) - F1, F2 (SaaS contracts, GDPR / CCPA) - H5 (EU data transfer flag — only relevant if EU users onboarded) - I2, I3, I5, I6 (disclaimer text, SLA language, CAN-SPAM, confidentiality legend) - J6 (GitHub ToS / DPA interaction with securities-adjacent code) - K5, K6 (pivot threshold + GH org interaction) - L3 (UK financial promotion / FCA — only if UK marketing begins) - L5 (AU AFSL classification — only if Australian marketing begins) - L7 (MiFID II prescribed warnings — only if EU expansion is confirmed) - O5 (automated TLH execution registration — only if TLH execution is in scope) - O6 (disclaimer placement adequacy — can be resolved alongside ToS drafting in F1)

This document is preparation material only. The attorney's answers — not this document — are the actionable output.

P) Marketing compliance — dual-audience positioning for getraxx.com (added 2026-05-27)

(Background: docs/business/raxx-marketing-compliance-brief-2026-05-27.md. Priority: HIGH — these questions must be resolved before any public-facing marketing targeting newcomers/beginners is published. The footer disclaimer and backtest mock disclaimer are pre-launch blockers.)

Attorney type needed for this section: consumer-protection attorney with FTC Section 5 experience AND Pennsylvania UTPCPL experience. This is a different specialty from Matthew Crosby (trademark/IP). Candidate firms given PA domicile and documented consumer-financial-services practice: - Duane Morris LLP (Philadelphia) — documented fintech + consumer protection - Ballard Spahr LLP (Philadelphia) — consumer financial services practice - Eckert Seamans Cherin & Mellott LLC (Pittsburgh/Philadelphia) — published directly on the 2021 PA UTPCPL strict-liability shift

P1. Footer disclaimer adequacy — PA UTPCPL and FTC Section 5. Is the following footer language sufficient for a PA-domiciled, US-nationally-marketed trading-tools SaaS under the 2021 Gregg v. Ameriprise strict-liability standard?

"Raxx is a trade-management and process-enforcement tool. Raxx does not provide investment advice, financial advice, or recommendations to buy or sell any security. MooseQuest LLC is not a registered investment adviser. Use of Raxx does not constitute an advisory relationship. Trading involves risk of loss. Past backtest results do not predict future performance."

Or should it be more specific: cite 73 P.S. § 201 et seq., disclaim SEC registration explicitly, reference the Investment Advisers Act? What does a compliant footer look like for a platform at Raxx's product stage?

P2. "Break into trading" and similar newcomer-audience copy — FTC substantiation standard. If the landing page uses any framing that implies Raxx helps newcomers start trading (e.g., "build your trading discipline before your first live dollar moves"), what is the specific FTC substantiation standard Raxx must be able to meet if a complaint were filed? Does Raxx need affirmative evidence that its tool helps trading discipline before publishing this framing, or is the process-focus (not outcome-focus) sufficient to avoid the substantiation requirement? Primary source: FTC Section 5 (15 U.S.C. § 45).

P3. Backtest mock in hero section — disclaimer adequacy. The current hero section includes a product mock showing "+34.2% total return" and other hypothetical backtest statistics. This mock is not labeled as hypothetical or illustrative in the current code. Before any public launch: (a) Does this constitute a "performance claim" requiring a proximate disclaimer under FTC deceptive advertising standards? (b) What is the minimum disclaimer language required proximate to the mock? (c) Should the numbers be replaced with placeholder labels ("XX.X%") rather than specific hypothetical values? Primary source: SEC Marketing Rule spirit (Rule 206(4)-1(d)): https://www.sec.gov/files/rules/final/2020/ia-5653.pdf

P4. Testimonial SOP — when Raxx has customers. Before the first customer testimonial is published anywhere (landing page, social media, press materials): (a) What is the required disclosure when a testimonial shows trading results or process improvements that are atypical? (b) Is "Results not typical. Individual results will vary." sufficient, or must Raxx show the distribution of typical results? (c) What must be disclosed if a testimonial comes from a beta user who received free access? Primary source: FTC Endorsement Guides (16 C.F.R. Part 255, revised 2023): https://www.ftc.gov/system/files/ftc_gov/pdf/p204500_endorsement_guides_in_2023.pdf

P5. Solicitor framework — BYOB broker-connection model. Raxx connects to the user's existing broker (Alpaca, IBKR, etc.) with no referral fee or revenue sharing with any broker. Does this connection flow require any disclosure to the user? If Raxx ever enters a revenue-sharing arrangement with a broker, at what point does the solicitor framework under the SEC Marketing Rule apply, and what disclosures are required? Primary source: SEC Marketing Rule final rule: https://www.sec.gov/files/rules/final/2020/ia-5653.pdf

P6. §202(a)(11) "inanimate tool" posture — verbal opinion vs. formal opinion. Raxx's current product (user-defined rules, retrospective results only, no AI-selected recommendations, no trade execution by Raxx) appears to sit outside the §202(a)(11) definition of "investment adviser" under the "inanimate tool" line of SEC no-action guidance (FPL 1994, SunAmerica 2001). Is a verbal attorney opinion sufficient to document this posture, or should Raxx seek a formal written opinion letter before launch? What would a formal opinion cost and how long would it take?

Priority for attorney consult: P1 and P3 are pre-launch blockers — the footer disclaimer and backtest mock disclaimer should be in place before getraxx.com is publicly marketed. P2 and P4 should be resolved before any newcomer-audience marketing campaign or testimonials are published. P5 and P6 can follow in the first 60-day post-launch window if the broker-connection model and §202(a)(11) posture remain unchanged.

Q) Shape 1 — Personal Sentiment Journal: Advisers Act + FINRA + FTC questions (added 2026-06-05)

(Background: docs/legal/research/shape-1-personal-sentiment-journal-compliance-2026-06-05.md. Priority: HIGH — Q1 and Q3 must be resolved before Shape 1 ships to any paid user. Q2 and Q5 gate any label-suggestion or auto-tagging feature design.)

Attorney type for Q1–Q6: Same securities attorney engagement as P6 (§202(a)(11) inanimate-tool opinion). These questions are incremental to the P6 scope — confirm whether they fit within the same engagement or require an addendum.

Attorney type for Q7–Q9: Privacy attorney with CCPA/CPRA and GDPR background. Separate engagement from the securities attorney.

Context: Shape 1 is a personal sentiment journal where the user labels their own emotional state before and after trades (e.g., Bullish / Bearish / Disciplined / Panicked), and can filter their own backtest results by those labels. No data is aggregated across users. No recommendation is made. User-asserted data only.

Q1. §202(a)(11) opinion — Shape 1 scope confirmation. The existing P6 question covers the §202(a)(11) inanimate-tool framing for Raxx broadly. Confirm the analysis extends to Shape 1 specifically: (a) does accepting user-supplied emotional labels before and after trades, and returning filtered historical results showing how the user's own trades performed when they reported those labels, satisfy Prong A (advice concerning securities) of the ABCs test? (b) Is there any aspect of label-storage-and-retrieval that creates "advice concerning securities," given that the output is entirely historical and exclusively the user's own data? (c) Is a formal written opinion necessary, or is a verbal confirmation memo sufficient for Shape 1?

Q2. Auto-classification erosion — line-drawing. At what specific point does Raxx's label-suggestion or auto-tagging behavior cross from neutral UI design into providing "advice concerning securities" under §202(a)(11)? Specifically: (a) Is a blank "select your state" field with user-supplied label options unambiguously clean? (b) Does a "most users who felt X in similar conditions selected Y" suggestion tooltip cross the line? (c) Does auto-tagging from behavioral signals (time-in-position, P/L sign) cross the line? If so, is there a safe-harbor framing (e.g., "behavioral tag — not a sentiment label — shown separately from user-asserted labels")?

Q3. Marketing Rule inapplicability + FTC §5 standard for in-app backtest filter. Confirm that Marketing Rule 206(4)-1 does not apply to Raxx's in-app backtest-filter display showing a user their own sentiment-labeled historical results because (a) Raxx is not a registered investment adviser, and (b) an in-app display to an authenticated user of their own data is not an "advertisement." What is the residual FTC §5 exposure from the same display, and what disclaimer placement standard applies under FTC §5 (rather than the Marketing Rule) to a user-own-data historical filter shown within an authenticated session?

Q4. FINRA non-applicability — confirm and scope. Raxx is not a FINRA member and does not execute trades directly. Confirm: (a) FINRA Rules 2210 and 2360 do not apply to Raxx's in-app sentiment-journal communications or sentiment-filter results displays; (b) if a Raxx user is a registered representative at a FINRA member firm and uses Raxx's sentiment journal in connection with their firm's business, what — if anything — does Raxx need to disclose or accommodate in its Terms of Service or user-facing copy? (c) Does Raxx's API connection to the user's broker account via an aggregator create any FINRA member-firm nexus?

Q5. §206 anti-fraud exposure — label-suggestion UI design. If Raxx implements any label-suggestion feature — pre-populated defaults, "did you mean X?" prompts, or AI-generated label recommendations based on prior behavior — does that feature create exposure under Advisers Act §206(1) or §206(2) on the theory that influencing how the user labels their trades, in a way that affects how they interpret their own performance history, is a deceptive or manipulative practice? What is the minimum safe design that preserves the user-assertion principle while still allowing a useful UX (e.g., a recent-history shortcut showing the user's own last three labels)?

Q6. Endorsement Guides / testimonial threshold — screenshots of sentiment-filtered results. At what point does a screenshot of a user's own sentiment-filtered results become subject to FTC Endorsement Guides (16 C.F.R. Part 255, 2023 revision) and/or FTC §5 deceptive-advertising standards when used in: (a) a paid testimonial on the Raxx marketing page; (b) an organic user-shared post on social media; (c) a case study linked from the Raxx landing page? What disclosure is required in each scenario?

Q7 (Privacy attorney). CPRA Sensitive PI classification — user-asserted emotion labels. Do user-asserted emotion labels (not inferred by the platform) fall within the "psychological trends" Sensitive Personal Information category under CPRA §1798.140(ae)? What is the right-to-limit-use obligation (§1798.121) if they do? Does the answer change if labels are associated with financial transaction records (trade outcomes)? Does the California AG's March 2022 interpretation of "inferences" under CCPA affect this analysis — specifically, does data the user provided become an "inference" when used in a profile filter?

Q8 (Privacy attorney). In-flow consent adequacy for label collection. Is a one-time in-flow notice (displayed at first use of the pre-trade label UI, requiring positive acknowledgment before proceeding, not a pop-under or modal that can be skipped) sufficient to satisfy: (a) FTC §5 notice-and-choice principles for a non-CCPA-mandatory business; (b) any CPRA §1798.121 right-to-limit-use disclosure requirement if labels are Sensitive PI; (c) the "at or before collection" timing requirement? Or does Raxx need a separately signed consent document for this data category, distinct from the Terms of Service?

Q9 (Privacy attorney). GDPR Art. 17 — relocating user and sentiment labels. Raxx geo-blocks EU signups. If a US-enrolled user relocates to the EU after enrollment and has emotion labels stored in Raxx, does Art. 17 apply to those labels upon relocation? (a) What is the practical mechanism for honoring an Art. 17 erasure request from a relocating user, given that Raxx is a US company with an EU geo-block and no EU representative? (b) Does the relocating-user scenario reopen the Art. 27 EU-representative question that we believed was resolved by the geo-block decision? (c) Should the DSR operating procedure (#1686) explicitly include a "former US user now in EU" request category?

Priority for Shape 1 attorney work:

Must resolve before Shape 1 ships to any paid user: - Q1 (§202(a)(11) Shape 1 confirmation) - Q3 (Marketing Rule inapplicability + FTC §5 standard — gates the backtest filter page) - Q7 (CPRA SPI classification — gates the privacy policy update) - Q8 (in-flow consent adequacy — gates the UI flow)

Must resolve before any label-suggestion or auto-tag feature is designed: - Q2 (auto-classification line-drawing) - Q5 (§206 anti-fraud label-suggestion exposure)

Resolve before any customer testimonials using sentiment results: - Q6 (Endorsement Guides / testimonial threshold)

Resolve before first verified EU-resident DSR request is received: - Q9 (GDPR Art. 17 relocating user)

FINRA confirmation (low-urgency, document-for-the-record): - Q4 (FINRA non-applicability)

Estimated cost for Shape 1 attorney questions: - Securities attorney (Q1–Q6): $3,375–$6,600 (7.5–11 hours at $450–$600/h senior associate rate) - Privacy attorney (Q7–Q9): $1,575–$3,500 (4.5–7 hours at $350–$500/h) - Total Shape 1 marginal cost: $4,950–$10,100 (Lower than full D-scope because Q1 is incremental to P6; Q4 is short; privacy questions are bounded to one feature and one data category.)

Background research: docs/legal/research/shape-1-personal-sentiment-journal-compliance-2026-06-05.md