# AUTHORITY REGISTER P8 — who has stood where we stand, and what the brokers say
## Consolidated register · federal, plus Washington State where a track reaches it

**Commissioned:** 7 September 2026 · **Delivered:** 7 September 2026 · **Frozen on delivery.**
**Builds on:** AUTHORITY REGISTER P7 (frozen 5 September 2026). **P8 does not supersede P7.** P7 remains the operative register for everything P8 does not touch. P8 is additive: six new research tracks plus one follow-up, and a delta list that says where the Target Architecture and the Legal Position move.
**Read first, and read before this document:** Target Architecture (Foundation, v1, 2026-09-05) and Legal Position (Foundation, v1, 2026-09-05). Both were read in full before the tracks were commissioned.

**What P8 was for.** P1–P7 looked for authorities that reach this configuration. P8 had a different job: **who has lived in this position, what happened to them, and what the brokers themselves say about it.** Survivors are evidence too — if the absence of enforcement is documented rather than assumed.

**No legal conclusions are offered anywhere in this document.** Entries are marked ADVERSE, SUPPORT or NEUTRAL against the question they touch, with a level 1–5. Where the material is silent, the silence is reported with the search that established it.

**Scope of effort.** Eight analysts, eight sub-registers, roughly 400 distinct primary documents fetched and read, and every load-bearing quote re-verified against its source file by the analyst who reported it.

---

## The three questions

**Q1 · Adviser characterization.** Is a timed signal about a specific security, fired by a rule the member wrote and asked to be told about, advice for compensation?

**Q2 · Broker characterization.** Is software that composes an order from the member's own policy and transmits it under the member's own key, after the member's own act, "effecting transactions for the account of others"?

**Q3 · Customer instruction.** Is the member's per-order act, followed by transmission under his own credentials, treated as the member's own instruction rather than discretionary authority exercised by another person?

---

# READ THIS FIRST — the findings that move the position

**1 · Q3's open question is answered, and it is answered by six brokers saying the same thing in six separately drafted contracts.**
R2.4 and guardrail 15 each carry an express Open: *the member's broker's account and API terms must confirm that an order transmitted under the member's own credentials after that act is treated as the member's own instruction.* Six brokers were read. All six answer yes, in deeming language, and **the test is uniformly whose credentials carried the order** — never who composed it, never whether a human reviewed it, never whether the software was automated.

> **Schwab**, Electronic Services Agreement §12: "You will be responsible for all orders entered through and under your Access Information, and any orders so received by Schwab **will be deemed to have been received from you**."
> **Interactive Brokers**, Client Agreement ¶4 (form 3203, 10 Jan 2025): "**Use of Client's credentials to effect any action will constitute conclusive evidence that IBKR may treat such action as authorized.**"
> **tastytrade**, Customer Agreement §4: "Any orders communicated to tastytrade's platform with your user login information **will be considered to have been sent and authorized by you**."
> **Alpaca**, Customer Agreement §16(e)(7): "I represent that I am **solely responsible for and have authorized** any orders or instructions … originating from … My PINs."
> **Fidelity**, Terms of Use: "Fidelity shall not be under any duty to inquire as to the authority or propriety of any instructions given to Fidelity by You **or by a person who has logged on using Your access credentials**."
> **E*TRADE**, API Developer License Agreement §4.9, by negative implication: an order **is** authorized where it rests on "a discrete, contemporaneous, and specific instruction provided by the applicable End User … for that particular order."

P7 recorded that no located SEC letter, release or staff guidance addresses whose credentials a software vendor uses. The brokers' own terms do address it, unanimously. **Six independently drafted contracts converging on one test is worth more than any one of them.**

**2 · But the brokers answer two questions, not one, and the configuration is built for only one of them.**
Every broker separates **attribution** (whose order is it) from **permission** (may that software connect at all), and the answers are independent. Attribution was never in doubt at any of them. Permission is where the exposure sits, and **no consent architecture reaches it.**

| Broker | Gate on third-party software |
|---|---|
| Alpaca (own-key Trading API) | **None located.** Locally-run algorithms are an expressly disclosed ordinary mode of use. |
| Interactive Brokers | Third parties offering automated trading solutions are **expected to hold registration**, or supply a legal opinion. |
| E*TRADE | Vendor key tier; no registration required, but **review criteria unpublished** and Legal sits on the gate. |
| Schwab | Only web browsers or applications "**formally approved by Schwab in writing**" (ESA §14), satisfied via Developer Program registration and review. |
| tastytrade | Prior written approval for software not "**developed and owned by you**" (API TOS §2(3)(f)). |
| Fidelity | Prohibited absent express written approval, "**even if instructed to do so by an authorized user**" — and no retail trading API exists at all. |

**Fidelity's clause is the one to note.** It is drafted to make consent irrelevant: it bites on the nature of the access mechanism and the commercial character of the entity, and forecloses the authorized-user argument in terms. Fidelity is not an available broker for this configuration; the clause matters as evidence of where industry drafting is heading.

And **the design work all lands on attribution.** Member-owned fields, the approval surface, the permission ladder, the journal — no broker's terms condition attribution on any of it. The one feature that does the work under every instrument read is the narrowest and least celebrated: **the key lives only with the member.**

**3 · E*TRADE — the first supported broker — added a clause between 9 May and 7 September 2026 that makes the per-order tap the whole of the defence, and prohibits standing execution outright.**
API Developer License Agreement **§4.9**: "Developer shall not implement, use, permit the use of, or design the Application … to engage in Algorithmic or Automated Order Generation … Each order submitted through the API must be based on a **discrete, contemporaneous, and specific instruction** provided by the applicable End User … **for that particular order**. Any order submitted in violation of this Section shall be **deemed unauthorized**." §4.8's only alternative is a power of attorney.

**§1.19** defines the banned category as "any logic, code, feature, rule set, model, **signal**, trigger, process, workflow, or functionality … that directly or indirectly generates, initiates, routes, submits, **modifies, cancels, or manages** an order through the API **without a discrete, contemporaneous, and affirmative instruction for that specific order provided by the End User**."

Three consequences, and only the first is comfortable:
- **The qualifier saves per-order V1.** On the sentence's own grammar, the eleven-noun genus list is governed by the "without" clause; both limbs must be met. A human-tapped signal is outside it.
- **The qualifier is the only limiting element.** The engine/runtime separation, the member's authorship of the rule, local installation and member-only credentials **do no work at all** under §1.19. The tap is the entire defence.
- **"Modifies, cancels, or manages" newly catches the price-and-time envelope.** E*TRADE's API has no in-place amend: a re-peg requires `change/preview` + `change/place`, and E*TRADE's own field description calls the result "the order ID of the order that is **replacing** a prior order." An automated re-peg is a new order, and §4.9 demands a contemporaneous specific instruction for that particular order. The **end-of-day sweep** is caught the same way. "Contemporaneous" appears three times in the agreement and **is never defined.** This is the part of the design that has been hung on FINRA Rule 3260(d)(1) — a rule E*TRADE's contract does not know about.

§11.8, which is **identical in both live versions**, settles which governs: "The most current version of the Agreement will supersede all previous versions" — no notice, no version marker, the trigger is publication.

**4 · The trusted authorization surface buys evidentiary quality, not legal characteristic — and controlling it is, in the case law, a liability to be neutralised rather than a credential earned.**
Across 50 CourtListener queries, four eCFR parts, seven Federal Register full texts, six FINRA notices, four FINRA rules and seven attribution decisions read from official court PDFs, **no instrument and no decision was located in which the identity of the party that rendered the screen was a factor in deciding whose act it was.** Not a null-search artefact: in *GoodLeap v. Garza* (Tex. App. 2025) a court was handed the strongest imaginable whose-device facts — a signature on "a tablet provided by the salesmen", in a language the signer could not read, where he "could really only see boxes and lines to mark the screen" — and **expressly reserved** the efficacy question rather than build a surface rule on it.

What carries attribution, ranked by the authority behind each: **(1) actual authority**, **(2) credentials and identifiers**, (3) a security procedure, (4) the record, (5) the party who acted — which carries *responsibility*, not attribution — and **(6) the rendering surface: nothing.**

And then the inversion the commission did not anticipate. The attribution cases *do* ask a whose-system question; it runs the opposite way. They ask **whether the party now asserting the act could have produced it itself.** *Banister* failed attribution because the employer's HR manager "had the ability and motive to access [the] onboarding account"; *Garcia* failed because the record "did not show that **only** Garcia could have placed the electronic signature"; *Aerotek* won because the credentials were "**all unknown to Aerotek**" and "Once a candidate submitted his application, Aerotek **could not modify its contents**."

A runtime that renders the surface, holds the trade credentials and mints the record that later proves what the member did sits in *Banister*'s losing posture unless it can **prove lock-out of all three**. The ingredients are already in the design. **The value comes from the lock-out, not from the ownership** — and a runtime-owned surface whose operator retains any capacity to mint or alter an instruction record is, on this line of cases, worse than no special surface at all.

**5 · On Q1, the argument should move off authorship and onto content — because that is where Commission-level support now exists, and authorship still has none.**
Track 5 answers 01-23's open word. **"More" is personalization × specificity, not prominence.** The most aggressive presentation *permitted* is 01-23 n.14's "stock of the week": a list of **one**, chosen by the firm on its own undisclosed criteria, carrying an evaluative superlative, expressly "highlight[ing] a particular security", and actively pushed — permitted because it was customer-requested and not tailored to the individual. The least aggressive *crossing* has no emphasis at all and crosses on personalized inputs producing named securities. **The permitted case is more aggressive on every presentational axis.**

Newly confirmed at Commission level: ***In re David Lerner Associates***, Rel. 34-105556 (27 May 2026) — a plain template listing three to five named securities was a recommendation because "individually tailored … to a specific customer" and it "reasonably would influence an investor to trade a particular security." **Five disclaimers, including a rewrite from "suggested investments" to "examples of potential investments", all failed together.**

And the strongest single passage found anywhere in P8 for Q1, in the Commission's own words: at **88 FR 53975** the Commission described an investor-signed-up-for, investor-**customizable** alert keyed to the securities on the investor's own watch list as having "generally been viewed as **outside the scope of 'recommendations'**", cited NTM 01-23 twice for it, **proposed a new rule to capture such communications — and that rule was withdrawn on 17 June 2025** (90 FR 25531). The Commission thought it needed new rulemaking to reach a customer-configured alert, and it does not have it.

**The unresolved variable is the `side` field.** The Commission's example is an alert about news *affecting* a security, not a buy/sell direction. NTM 01-23's price-point holding is expressly "without more", and no located authority says whether a side is "more."

**6 · The user-configuration defence has never succeeded on adviser status — but the answer splits by question, and the whole commodities line must be marked down before any of it is carried across.**

**On adviser status: no.** Across federal courts, SEC administrative proceedings and Commission opinions, CFTC enforcement and staff letters, NFA, FINRA rules and state listings, **no tribunal has ever accepted "the user configured it" as an answer.** The sharpest rejection located anywhere is new: ***Rome v. Mandel***, 405 P.3d 387 (Colo. App. 2016), where the follower could **exclude named securities** and **cap position size** — and the court held the tailoring question **"immaterial"** (¶40).

*Rome* is distinguishable, but only on the fact the court actually relied on: Ditto Trade executed "**without need for further instruction or approval**" and followers were "**often not aware of the trades until after they have occurred**." The configuration inverts both. **What it cannot take from *Rome* is any comfort from the member's own exclusions and caps — that follower had both, and they were called immaterial.**

**On broker status: yes, twice — but not on a configuration theory.** *SEC v. Coinbase* (Wallet) and *Risley* both went the defendant's way on **user control at the moment of trade**: the user held the keys and made each decision. That is a different proposition from "the user configured it in advance", and it is the proposition the configuration's per-order design actually matches.

**And the correction that matters most, because it reaches P8's own headline adverse authority.** ***Commodity Trend Service v. CFTC***, 233 F.3d 981, 988 (7th Cir. 2000), verified verbatim:

> "the CEA has a broader scope than the IAA… **bona fide publishers are not IAs even if their entire business concerns giving impersonal securities trading advice**… By contrast, the CEA exempts publishers from the definition of CTA only if their giving of advice… is solely incidental… Impersonal publishers such as CTS… are included within the definition of CTA, **even though an analogous publisher would be excluded from the definition of IA**."

***Donelson*, *Hall*, *R&W*, *Taucher* and *Vartuli* are all CEA cases**, resting on a statutory asymmetry that does not exist in the Advisers Act. **What survives transplantation into Q1 is *Donelson*'s factual demonstration that per-trade confirmation did no work. What does not survive is any inference from CTA status to adviser status.** That is a material markdown of five of the register's most-cited adverse authorities, and it was found by a track looking for adverse material.

*Donelson* remains the reason the per-order tap cannot be asked to carry Q1: **the customer confirmed every trade and it counted for nothing**, and the Seventh Circuit held that "[e]ven if *Taucher* or *AVCO* drew a line between personal and impersonal advice, **the text of the statute does not**." The configuration distinguishes it on **content** and on **compensation**, not on user control. But it is a commodities case, and *Commodity Trend Service* says what that costs it here.

One further correction to P7's own register: ***Pirate Investor*** (4th Cir. 2009) reads ***Terry's Tips*** — cited unqualified in P7 and in the Legal Position — as an **auto-trading** case. That puts it materially further from the configuration than its bare citation suggests.

Against all of it, the closest favourable text, found on independent verification: the **Rule 4.14(a)(9) adopting release**, 65 FR 12938 (10 Mar. 2000), Example C — where a user's own indicated preference determines which advice he receives, the advice is not "tailored" because "the CTA is **merely allowing its clients to select which advisory services they wish to purchase**." A Commission rulemaking document, in force. It is also an exemption from *registration* for persons who *are* CTAs, it is CEA, and **the Advisers Act has no counterpart.**

**7 · The survivors are real evidence, and the nearest commercial analogue registered.**
Sixteen products carried through a full documented search protocol. Eight enforcement orders found across five names. **Exactly one is about broker or adviser status** — *In re eToro USA LLC*, Rel. 34-101001 (12 Sep 2024). It rests on six factors and **all six are absent from the configuration**: custody of customer funds; eToro holding the private keys; a fixed per-transaction fee; routing to an affiliate; daily netting; and acting "as their agent." The other seven are crypto interest products, identity-theft-program, off-channel communications, Form CRS, §5 fund offering, and CFTC supervision. Each is labelled in the register as not being evidence on Q1/Q2/Q3.

The silence is documented for SEC AP/LR (48 respondent names × 2 listings, with a verified empty-vs-populated discriminator), Washington DFI (every year page 2002–2024 plus the 2025–26 index, with a working control), CFTC (61 listing pages, with a control), BrokerCheck, IAPD and EDGAR full-text. It is **not** documented for FINRA disciplinary actions (Cloudflare wall) or NFA BASIC, and no silence is claimed for those.

**Two results cut against the comfort.** First, **Composer** — the nearest commercial analogue, with user-authored rules, a flat subscription fee and nothing else, connecting to the user's own account at a third-party broker — was **a registered investment adviser on the first archived day it existed**, told the SEC its service was portfolio management rather than publication, and reported $46.7m discretionary across 2,948 accounts and **$0 non-discretionary**. Flat-fee subscription economics did not keep a user-authored-rules platform out of adviser registration. Second, **no located product pairs a per-order approval surface with an unaffiliated vendor and the user's own credentials.** TradeStation has the per-order ladder but its software and broker are affiliates; every other unaffiliated survivor runs unattended. **The configuration is more conservative than every unaffiliated survivor found — and correspondingly, it is novel rather than proven.**

**7b · And no private litigant has ever put a vendor's status statement in issue either.**
Track 2's documented silence covers regulators. A follow-up closed the other half. Five private suits naming survivor vendors as parties were traced to their dockets, and **not one pleads, argues or decides adviser status, broker-dealer status, registration, or a vendor disclaimer.** Where full text was scanned, "broker-dealer", "investment adviser", "registered", "registration", "Exchange Act", "Advisers Act", "CFTC" and "FINRA" all count **zero**.

***Cantero v. TradeStation Technologies*** — the one that mattered, because it is a suit against the **software entity** whose own disclosure declares it "not a financial services company" — is **an unpaid-overtime wage case.** FLSA, nature of suit 710, cause 29:0201, employer and officers sued in the ordinary employer-liability pattern; mediated, settled, dismissed with prejudice in five months, no merits opinion. **That sentence has never been tested by anyone, in any forum.**

The others are the same story in different clothes. *Monegro v. Trade Ideas* is one of 160 templated website-accessibility complaints filed by a single plaintiff in eleven months, sweeping sites indiscriminately; it carries no view about Trade Ideas at all. *Gurung v. MetaQuotes* — the only merits opinion among them — is a fraud victim suing over what fraudsters did on the vendor's platform, pleaded as **RICO and fraud, not registration**, and decided on the EULA's forum clause. Two near-misses were caught before they became findings: MetaQuotes is a **plaintiff** in its other federal matters, and TradeStation appears elsewhere as a plaintiff and as custodian of a forfeiture res.

**Four of the five name the software entity and none names the regulated affiliate** — which is the shape one would expect if the software layer were where the commercial friction lives and the status question simply never arises. One remains open: *Alpha Futures v. NinjaTrader Group*, N.D. Ill. 1:26-cv-08846, whose complaint was not retrieved. It costs $1.20 on PACER, or nothing at all under the $30 quarterly waiver.

**Method note for the register.** The **FJC Integrated Database** — the Administrative Office's own docket dataset — is unwalled and should be the first stop for nature-of-suit questions, ahead of CourtListener and Justia. And a correction to Track 2's own claim: *Cantero* is not the only suit against a software entity; Fed. Cir. 18-1443 is a second, a patent matter.

**8 · Standing mode: a regulator has already been asked for exactly what the standing track proposes, and refused — and the design's central intuition has separately been made twice and rejected both times.**

**The finding that governs the whole track is Rel. 34-49883 at 7 (17 June 2004).** Commenters asked that the written instruction which lifts Rule 3260(d)(1)'s day limit be allowed to take the form of "**general 'standing' instructions, rather than issuing written instructions on an order-by-order basis. NASD declined to adopt this position.**" The standard the regulator held to is **trade-specific**. The configuration does not distinguish it.

The rest of the track sorts the same way:

- ***Michael Pino***, Rel. 34-74903 (7 May 2015): the respondent argued he "simply tried '**to sell something based on a strategy that's been well in place, that to me is not discretion**.'" The Commission held that "**a customer's approval of a general strategy does not meet the requirements of the 'time and price discretion' exception**", and located the definiteness requirement on **the customer's grant**, not on the resulting order. *Murphy* (2013) and *Sathianathan* (2006) are to the same effect. **Per-order V1 distinguishes this cleanly** — the member is consulted before every execution, which is exactly what Pino failed to do. **Standing mode does not distinguish it on the reasoning at all.**
- **The IAA standing-letter-of-authorization letter** (SEC staff, 21 Feb 2017): the requester argued expressly that a *bounded* standing authorization differs in kind from an open one, contrasting it with trustee discretion and "a full power of attorney … or broad discretionary authority." The staff answered: "**We disagree.**" Writing, bounds, revocability and an agency framing were all present and all held insufficient. **That is the standing-mode intuition, verbatim, and the staff rejected it.**
- **Rule 3260(d)(1) is day-limited**: time-and-price authority runs "**only until the end of the business day** on which the customer granted such discretion, absent a specific, written contrary indication **signed and dated by the customer**." A standing authority is by definition not day-limited. The only escape is a signed, dated customer writing — and Rel. 34-49883 is the document in which the regulator was asked to let that writing be a standing instrument and said no. The day limit is lifted **only for institutional accounts** under Rule 4512(c). *(This is the second authority in the register whose otherwise-apposite relief is gated on institutional status; S3 Matching Technologies was the first, and FINRA Rule 2111(b) is the third. Where the rules do accommodate machine-mediated latitude, they do it for institutions.)*
- **The per-order / standing split is remarkably clean across the whole track.** *DiPaola*'s current test — discretion is trading "without first receiving approval for the trades" — is a line **per-order V1 sits safely on**. Standing mode fails that test, fails RN 16-21's "linked router" parenthetical, fails the auto-trading alert's permission axis, and fails Rel. 34-49883 — **all by the same single feature: the absence of a per-order human act.**
- **On who may be the grantee, there is no authority either way** — but the drafting chain is uniform and traceable. FINRA Rule 3260(b): "a stated **individual** or individuals." 17 C.F.R. §240.17a-3(a)(17)(ii): "the dated signature of **each natural person** to whom discretionary authority was granted." Adopting release 34-44992 **n.21 sources that wording expressly to NYSE Rule 408 and NASD Rule 2510(b)** — the federal rule inherited the human-grantee assumption rather than reasoning to it. A grant to a program breaches no express prohibition; it produces an instrument for which the federal recordkeeping rule **has no field**.
- **A supportive end does exist, and it is a Commission rule rather than a staff letter.** 17 C.F.R. §240.10b5-1(c)(1)(i)(B)(2) provides that a pre-adopted plan may have "included a written formula or **algorithm, or computer program**, for determining the amount of securities to be purchased or sold and the price at which and the date on which" — and the rule calls what results **the adopter's own purchase or sale** throughout. Rel. 33-7881: such a person may "plan securities transactions in advance … and then **carry out those pre-planned transactions at a later time**." It is an analogy — 10b5-1 presupposes the attribution rather than deciding it — and it carries a defined term the configuration does not cleanly meet: "date" means "the specific day of the year."
- **The built-in delay has no support.** No authority was located, anywhere searched, stating that an interval between signal and submission bears on **who decided**. The only mandated delay in federal securities law — 10b5-1's cooling-off period — exists to sever an *informational* link. Read strictly, that is mildly adverse. **A longer interval weakens one evidentiary route to a *GEL*-style inference; it does not relocate the decision.**

**9 · Three timing variables, three bodies of law, one shared pressure point.**
The SLOA letter's fn.1 turns on discretion as to "the **amount, payee, and timing**." Rule 10b5-1(c)(1)(i)(B)(2) requires the formula to fix amount, price **and the date**. Regulation M's attribution test turns on control over "prices or amounts, the **timing** of, or the manner in which" purchases are made.

In the configuration every other parameter — sizing, order type, price band, instrument, side, account, broker — traces to an explicit member setting. **Timing does not: it is determined by when a member-authored rule fires against live market data.** Three instruments, three different bodies of law, one variable exposed in all three.

---

## Currency corrections carried by P8

These would be missed by any stale source and each was verified in the primary text.

1. **Washington repealed** WAC 460-21B-060 and 460-22B-090 (broker-dealer and salesperson unethical practices) effective **13 October 2024**. The replacement, **WAC 460-20C-210(6)**, omits **both** FINRA's "definite amount of a specified security" requirement **and** its business-day limit — materially broader on three axes.
2. The SEC's 2023 *Safeguarding Advisory Client Assets* proposal was **formally withdrawn 17 June 2025** (90 FR 25531). Rule 206(4)-2 is unchanged, and the 2017 SLOA letter interprets a rule still in force.
3. The **Predictive Data Analytics** proposal (88 FR 53960) was withdrawn by the same document. Its own text nevertheless contains the Commission articulations at 53975, 53972, 53977-78, 53984, 53997 and 54007, and 53975 is the strongest supporting passage in the whole of P8 on Q1.
4. The Massachusetts fiduciary rule litigation: the SJC decided **25 August 2023**, 492 Mass. 696, and **upheld** the rule. *(Corrects the Track 5 brief's premise.)*
5. **NASD NTM 96-60 is still live**, and says a security is recommended when a member "brings a specific security to the attention of the customer **through any means**", irrespective of a "solicited"/"unsolicited" label. **Irreconcilable with 01-23's permitted examples if read literally, and no authority reconciles them.**
6. **E*TRADE's developer programme is live, open and self-service** — not closed, not retired, and **not** folded into Morgan Stanley. The 403 is an Akamai bot block. *(Corrects the Track 1a brief's premise.)*
7. **P7's Schwab client-side gap rests on a URL that never existed.** `schwab.com/legal/terms-of-use` returns an empty Wayback snapshot set. Schwab publishes no general site terms of use; the live instruments are the Account Agreements (July 2026) and the Electronic Services Agreement (rev. 07/26). **The gap is closed.**
8. **IBKR publishes no numeric threshold for software vendors.** The "15 or fewer clients" figure governs eligibility for the Non-Professional Advisor *account type*, not software distribution, and must not be reported as a vendor threshold.
---

# 1 · BROKER TABLE (Track 1)

Six brokers, eleven-plus instruments, all retrieved 7 September 2026. Full pin-cites in S1a, S1b and S1c.

| Broker | Instruments read | Attribution clause (short) | **Q3 — is it the member's own instruction?** | Permission gate on third-party software | Developer registration |
|---|---|---|---|---|---|
| **Interactive Brokers** | Client Agreement (form 3203, 10 Jan 2025); TWS/Web API terms; third-party OAuth Registration Process; Auto Trading disclosure (form 4403, 1 Apr 2021) | Client Agmt ¶4 — credential use is "**conclusive evidence** that IBKR may treat such action as authorized" | **YES** | **Registration expected**, or a legal opinion explaining why not | Bilateral WebAPI agreement drafted by IBKR Legal — not public |
| **E*TRADE (Morgan Stanley)** | API Developer License Agreement, live portal copy (contains §§1.19, 4.8, 4.9, 7.5) and Agreement Library copy `0923-APIDEVLA-E68693` (does not); Client Agreement §9.D(c) | §4.9 by negative implication — an order resting on "a discrete, contemporaneous, and specific instruction … for that particular order" is authorized; violation is "**deemed unauthorized**" | **YES for per-order. NO for standing.** | Vendor key tier; User Intent Survey; "Vendor demo with Product and Legal"; **criteria unpublished** | **None** — no BD or IA requirement |
| **Charles Schwab** | Account Agreement (Jul 2026); Schwab One® (Jul 2026); Electronic Services Agreement rev. 07/26; Developer Program Agreement May 2023 (P7) | ESA §12 — "**deemed to have been received from you**"; Acct Agmt §26 — "considered to have been sent and authorized by you" | **YES** | ESA §14 — only browsers or software "**formally approved by Schwab in writing**" | Yes, via Developer Program registration + review; §3 disclaims any view on legal registration |
| **tastytrade** | Customer Agreement 20250811; API Terms of Service, 17 May 2023 | Cust. Agmt §4 — "**considered to have been sent and authorized by you**" | **YES on attribution** | API TOS §2(3)(f) — prior written approval for software not "**developed and owned by you**"; §2(3)(g) API Hub providers must contract | No registration; approval instead |
| **Alpaca** | Customer Agreement V26.2026.07; Terms & Conditions; Risks of Automated Trading v1.2020.02; developer docs | Cust. Agmt §16(e)(7) — "**solely responsible for and have authorized** any orders … originating from … My PINs" | **YES** — the strongest and most express | **None located** on the own-key Trading API path | None on that path. Connect/OAuth: Compliance approval; expressly open to "**non-registered firms**" |
| **Fidelity** | Terms of Use, 1 Jul 2026; FIDELITY ACCOUNT® Customer Agreement FA-CUSTOM-0626; Fidelity Access; Account Authority form 576564.19.0 | ToU — no duty to inquire as to instructions given "by a person who has logged on using Your access credentials" | **YES on attribution, NO on permission, and largely moot** | Third-Party Access Tools prohibited absent express written approval, "**even if instructed to do so by an authorized user**" | **N/A — no retail trading API and no developer programme exist** |

**The honest gap that survives all six.** Every instrument read addresses either the *account holder* (what he may do, what he is responsible for) or a *delegated human agent* (POA, trading authorization, advisor authority). **Not one has a category for the third party who writes and distributes software that the account holder installs and runs himself under his own key.** That is the broker-side mirror of P7's finding that no SEC source addresses whose credentials a vendor uses — the same hole, seen from the other side.

**And broker approval is worth nothing on Q1 or Q2, because two brokers say so.** Schwab Developer Program Agreement §3: "**Schwab has no obligation to verify whether the activities undertaken by you and/or your Applications require registration under Applicable Law.**" Fidelity's Account Authority form makes the agent "responsible for determining whether and what type of registration is required." Nothing in Track 1 should be read as a broker blessing the configuration's regulatory status.

---

# 2 · SURVIVOR TABLE (Track 2)

Sixteen names carried through the full documented protocol. Ordered by closeness to the configuration. Full search documentation in S2 §N1–§N8.

| Product | Since | Local / hosted | **Who holds the key** | Per-order act? | Status statement | Registered? | Enforcement — documented |
|---|---|---|---|---|---|---|---|
| **TradingView** broker panel | 2003 ◇ | Hosted UI; order goes client → broker's server, "The TradingView server is not involved in this data exchange" | **User ↔ broker** | Manual ticket | None located | No | **None found**, across SEC AP/LR, WA DFI 2002–2026, CFTC 61 pages, EDGAR |
| **QuantConnect** (Lean live) | 2012 | Hosted; QC's servers call the broker API | User's own credentials; "**we don't save your credentials**" | **No** — unattended | §3.6 "not an investment advisory service, nor … a registered investment advisor or broker-dealer" | No | **None found** |
| **NinjaTrader** (software era) | 2003 | **Local**, third-party broker platforms | **User** | Configurable | **None — zero status terms across the whole ToS**, byte-identical 2017→2025 | No (group now runs its own FCM) | CFTC 24-27 (2024) — **Reg 166.3 supervision, not status** |
| **MultiCharts** | 1999/2002 | **Local** | **User** | Configurable | **None** | No | **None found** |
| **Trade Ideas** | 2003 | Hybrid; user's own broker | **User** | Auto-execute available | EULA §III — trades "through a registered securities broker or dealer of the User's choosing" | No | **None found** |
| **TradeStation** (EasyLanguage) | — | Local platform, **affiliated** broker | **User** | **Yes by default**; opt-out per individual strategy, each behind "I Agree" | "TradeStation Technologies, Inc. is a software development company … **not a financial services company**" | Affiliate BD 8-48711 | 3 found — crypto interest product ×2, Reg S-ID — **none about status** |
| **Composer** | 2021 | Hosted; own BD + clearing | **Vendor-side** | **No** — "Watch your trades execute automatically" | 2021–24: "a registered investment adviser with the SEC"; **removed by 2026** | **IA 801-119952 (terminated 6 Dec 2024); BD 8-71057 active** | **None found** |
| **Alpaca** third-party apps | — | Broker API | **User grants access to app** | App-dependent | Third party places transactions "**at your direction**" | BD 8-69928 | 1 found — off-channel comms — **not status** |
| **Freqtrade** | 2021 | **Local**, open source | **User** | Configurable | "for educational purposes only … USE THE SOFTWARE AT YOUR OWN RISK" | None | **None found** — but crypto-only |
| **Hummingbot** | 2019 | **Local**, open source | **User** | Configurable | Cayman not-for-profit foundation | None | CoinAlpha Advisors — **§5 fund offering, pre-dates release** |
| **Sierra Chart** | — | Local | User | Configurable | Not retrieved (404) | No | **None found** |
| **Tickeron** | — | Hosted AI signals | Vendor | — | — | IA 801-79039, **inactive** | **None found** |
| **MetaTrader / MetaQuotes** | — | **Local**, user's own broker terminal | **User** | Configurable; EAs unattended | UNVERIFIED | No | **None found** — but predominantly forex/CFD and non-US |
| *Collective2 (AutoTrade)* — **contrast** | 2001 | Hosted; C2's servers adjust the account | Vendor-side | **No** | Terms unreachable (403) | No | **None found** |
| *eToro* — **contrast** | — | Hosted; custody + omnibus + netting | **eToro held the private keys** | No | — | BD 8-70212; IA 801-134641 | **FOUND — Rel. 34-101001, §15(a) + §17A. The one status holding in this track.** |
| *ZuluTrade* — **contrast** | — | Copy-trading | Vendor-side | No | — | No | **None found** |

**What the table shows, stated at its true weight.** Eight orders across five names; **exactly one about status**, and it involved a party that held the keys, held customer funds, netted and routed — none of which the configuration does. The silence is documented for SEC, Washington DFI, CFTC, BrokerCheck, IAPD and EDGAR; it is **not** documented for FINRA disciplinary actions or NFA, and no silence is claimed there. **Absence of enforcement is evidentiary, not authority.** It shows what regulators have not done across a large, visible, decades-old market. It shows nothing about what they may do.

**The two results that cut the other way.** Composer — the nearest analogue on economics and on user-authored rules — **registered**, and reported $0 non-discretionary. And **no located product pairs a per-order approval surface with an unaffiliated vendor and the user's own key.** The configuration is more conservative than every unaffiliated survivor found, and correspondingly it is novel rather than proven.

---

# 3 · THE THREE ANSWERS

### Q1 · Adviser characterization — **unchanged on the question P7 identified; the argument that should be made has moved.**

P8 did not find an authority distinguishing a rule the member wrote from one he adopted. That gap is exactly where P7 left it, and Track 3 now confirms it from the adverse side: across every forum searched, **no tribunal has ever accepted a user-configuration defence to adviser, broker or trading-advisor status.** It has been raised expressly and rejected at least three times (*Pinchas*, *Hall*, *Donelson*), and passed over in silence where it was structurally present.

Two findings move things, and they point in opposite directions.

**Against:** ***Rome v. Mandel*** (Colo. App. 2016) is the sharpest located rejection — a follower who could exclude named securities and cap position size, and the tailoring question held "immaterial". ***Donelson*** (7th Cir. 2024) shows **the customer confirming every single trade and it counting for nothing**. And **Composer** demonstrates that flat-fee, user-authored-rules economics did not, in practice, keep the nearest commercial analogue out of adviser registration.

**A correction that runs the other way, and it is substantial.** ***Commodity Trend Service***, 233 F.3d at 988, holds that the CEA is *broader* than the Advisers Act on precisely this point: "bona fide publishers are not IAs even if their entire business concerns giving impersonal securities trading advice", whereas "impersonal publishers … are included within the definition of CTA." **P7's and P8's five most-cited adverse authorities on this axis — *Donelson*, *Hall*, *R&W*, *Taucher*, *Vartuli* — are all CEA cases.** Their factual demonstrations transplant; the inference from CTA status to adviser status does not. Every document that cites them against Q1 should say so.

**For, and this is the more useful of the two:** Track 5 establishes that the operative axis in the recommendation line is **personalization × specificity**, not prominence, not automation, not who set the criteria. The configuration has **zero personalization** — it holds nothing about the member and uses nothing about him. That is the axis with Commission-level support behind it (Reg BI adopting release fn.182; *David Lerner*, May 2026; 88 FR 53975's treatment of a customer-configured watch-list alert as outside "recommendations"; and the withdrawal of the rulemaking that would have reached it).

**Where P8 leaves Q1: unchanged in risk, materially clearer in argument.** The position should not be carried by authorship, by the member's request or by the per-order tap — *Donelson* discarded the tap, and authorship has no authority behind it in either direction. It should be carried by **content**: no personalization, no tailoring, neutral labels, no highlight, nothing that identifies which security to the exclusion of others on any basis the Company chose. Card 03 stays at 3. What changes is the reasoning under it.

**The one live variable is the `side` field.** Every favourable text in the line concerns an alert about a condition or about news; none concerns an alert that names a direction. NTM 01-23's holding is "without more", and **no authority says whether a side is "more."**

### Q2 · Broker characterization — **unchanged on authority; better supported on evidence, and the evidence has a hole in it.**

P8 located no new authority on whether composing an order is "more than routing a message" — P7's open question B is untouched, and it remains the question that determines whether the strongest supporting letters reach the configuration at all.

What P8 adds is evidentiary. **Sixteen products in the configuration's rough shape, some operating for over two decades, produced exactly one status action — against a party that held the keys, the funds, and did the netting and routing.** That is a documented silence across a large market, and it is real. It is also, on its own terms, worth less than it looks: **no located product pairs the configuration's three defining facts** — unaffiliated vendor, user's own credentials, per-order approval. The survivors that share the credential fact run unattended; the one that shares the per-order fact is affiliated with its broker.

**And the silence is now documented on the private side too.** Five private suits naming survivor vendors as parties were traced to their dockets, and not one puts adviser status, broker-dealer status, registration or a vendor's status statement in issue. *Cantero v. TradeStation Technologies* — the only suit located against the **software entity** that declares itself "not a financial services company" — is an **unpaid-overtime wage case**. That sentence has never been tested by anyone, in any forum.

The brokers add two things, both new. **Six brokers make credential custody dispositive of attribution** — which supports the Q2 position indirectly, since the party whose credentials carry the order is the party the broker treats as its customer. And **not one of them has a category for a third party who writes software the account holder runs himself.** That absence is the same hole P7 found on the regulator's side, and P8 confirms it exists on the industry's side too.

**Where P8 leaves Q2: unchanged.** Card 04 stays at 3. The survivor evidence should be stated in the Legal Position as what it is — documented absence of enforcement across a visible market, with the FINRA and NFA gaps named — and never as authority.

### Q3 · Customer instruction — **closer to yes, and this is P8's largest movement. But the question the design was answering turns out to be the smaller half of the problem.**

The express Open in R2.4 and guardrail 15 is answered. **Six brokers, six separately drafted contracts, one test: whose credentials carried the order.** Track 6 confirms it from the law's side — attribution runs on actual authority and credentials, and **the rendering surface carries nothing at all.** The configuration's facts sit on the top two rungs of that ranking: an explicit per-order act by the member, and credentials that exist only in his own vault.

Three qualifications, each of which changes something in the documents.

**First, permission is a separate question from attribution and the design does not reach it.** Three of six brokers gate which software may connect, on grounds that have nothing to do with who decided: who wrote the software, whether the broker approved it, whether the entity is commercial. Fidelity's clause is drafted to make consent irrelevant in terms.

**Second, the per-order act is now contractually load-bearing at the first supported broker, and the price-and-time envelope is not.** E*TRADE §4.9 makes the tap the whole of the defence, and its "modifies, cancels, or manages" verbs catch automated re-pegging and the end-of-day sweep — the two places the design relies on FINRA 3260(d)(1), a rule the contract does not know about.

**Third, the trusted surface is evidence, not status.** No authority makes the renderer's identity operative. Worse, in the attribution case law, **controlling the system that produced the artefact is a liability the asserting party must neutralise** — *Banister*'s losing posture. The design's own ingredients answer it, but the reason must be restated: the value is in the operator's provable **lock-out** from the surface and the journal, not in owning them.

**Where P8 leaves Q3: closer to yes on attribution, with a new and separate exposure named on permission.** Guardrail 15's Open can be closed and cited. Guardrail 08's rationale needs rewriting. And a permission question that did not exist in the documents before now needs a home.

---

# 4 · DELTA LIST

Every place P8 changes something, cited by requirement, card or guardrail number. **Nothing else in either document is to be rewritten on the strength of P8.** This list is the handoff.

## Target Architecture

| # | Anchor | What P8 found | Citation that moves it | Direction | What the document would have to say instead |
|---|---|---|---|---|---|
| D1 | **R2.4** — the express **Open** ("the member's broker's account and API terms must confirm…") | Answered by six brokers, unanimously, in deeming language; the test is credential custody | Schwab ESA §12; IBKR Client Agmt ¶4; tastytrade Cust. Agmt §4; Alpaca Cust. Agmt §16(e)(7); Fidelity ToU; E*TRADE §4.9 | **CLOSE THE OPEN** | Replace the Open with the finding and the six citations. Add: the brokers' test is *whose credentials carried the order*, which the configuration satisfies structurally. |
| D2 | **R2.4, R3.8** — broker access | A **second, independent** condition exists that no requirement currently states: whether the broker permits *this software* to connect at all | Schwab ESA §14; tastytrade API TOS §2(3)(f), §2(3)(g); Fidelity ToU "Third-Party Access Tools"; IBKR OAuth Registration Process; E*TRADE Vendor key path | **ADD A REQUIREMENT** | New requirement: before a broker adapter ships, the broker's own permission regime for third-party software must be read, satisfied and recorded — separately from the attribution question. Name it as a distinct gate. |
| D3 | **R3.2** (end-of-day sweep) and the **price-and-time envelope** in W4, Layer 2 contract and Layer 3 contract | At E*TRADE, an automated re-peg is a **new order** (no in-place amend; `change/place` returns "the order ID of the order that is **replacing** a prior order"), and §1.19's "modifies, cancels, or manages" reaches both re-pegging and the scheduled sweep | E*TRADE API Developer License Agreement §§1.19, 4.9; E*TRADE API order-change reference | **TIGHTEN — and this is a design decision, not a wording change** | Either the envelope and the sweep become per-broker capabilities gated on that broker's terms, or they are not exercised at E*TRADE. The architecture cannot state the envelope as a uniform property of the runtime. |
| D4 | **R2.5** and the "Trusted authorization surface" paragraph | The surface's legal value is **evidentiary**, and in the attribution case law controlling the rendering system is a liability to be neutralised rather than a credential earned | *Banister v. Marinidence Opco*, 64 Cal. App. 5th 541; *Garcia v. Stoneledge Furniture*, 102 Cal. App. 5th 41; *Aerotek v. Boyd*, 624 S.W.3d 199; NASD NTM 98-66; 66 FR 55818 | **CORRECT THE RATIONALE — keep every requirement** | R2.5's seven minima all survive and are worth building. The stated *reason* changes: they exist so the operator can prove it is **locked out** of the surface and the journal, not so the runtime owns them. Add an eighth minimum: the operator's inability to mint or alter an instruction record must be demonstrable, not asserted. |
| D5 | **R1.5** ("Decision provenance") | Confirmed and strengthened from an unexpected direction: a Commission release names **parameter-setting itself** as discretion, so any Company-side preset would be the Company exercising it | Rel. 34-84528 at 70; Rule 606 FAQ (16 Aug 2019) | **STRENGTHEN** | Note that the no-presets rule is load-bearing on a Commission text, not only on IA-5653. |
| D6 | **Layer 2, "Release shape" / the standing track** | Standing execution is **contractually prohibited** at E*TRADE (§4.9, with §4.8's POA as the only alternative) and gated at IBKR; a regulator was asked to permit exactly this kind of standing instruction and **declined**; and the track's central legal intuition was separately rejected in *Pino* and by the SLOA letter's "We disagree" | **Rel. 34-49883 at 7**; E*TRADE §§4.8, 4.9; IBKR third-party OAuth Registration Process; *Michael Pino*, Rel. 34-74903; *DiPaola*, Rel. 34-105568 (28 May 2026); IAA SLOA letter (21 Feb 2017); FINRA Rule 3260(d)(1) day limit; FINRA RN 16-21 | **TIGHTEN** | State that standing mode is unavailable at the first supported broker as its terms now stand; that Rule 3260(d)(1) cannot carry it, because a regulator refused a standing form of the very writing the exception requires; and that on four independent authorities the two modes separate on one feature only — **the presence of a per-order human act**. That is the sentence the release-shape paragraph should end on. |
| D7 | **Layer 2, the built-in delay** ("a court has read a six-second response as the software deciding") | No authority anywhere says a delay bears on **who decided**. The only mandated delay in federal securities law exists to sever an *informational* link | Rel. 33-11138; documented null search at S4 NF-3 | **CORRECT** | Keep the delay; change the claim. It weakens one evidentiary route to a *GEL*-style inference. It does not relocate the decision, and nothing says it does. |
| D8 | **R3.6** (fields start empty, no presets) | Unchanged and confirmed — but the supporting reasoning should now cite the recommendation line rather than the adoption line | 88 FR 53975; Reg BI 84 FR 33318 at 33337-38 & n.182; *David Lerner*, Rel. 34-105556 | **RE-CITE** | No change to the requirement. |
| D9 | **W1** ("The access doesn't exist. Structurally.") | Materially strengthened, and by a new kind of source: six brokers make credential custody the operative test for attribution | The six attribution clauses | **STRENGTHEN** | The claim currently concedes that key custody "is not the statutory test." That concession stands for status. Add that it **is** the test the member's own broker applies to whose order it is. |
| D10 | **W2** ("the member wrote the trigger criteria himself, and the member asked to be told") | Both facts remain true and neither has gained support. The distinguishing work is now better done by **absence of personalization** | *CFTC v. Donelson*, No. 23-1809 (7th Cir. 2024); 88 FR 53975; NASD NTM 01-23 n.14 | **REBALANCE** | Keep authorship and request as facts. Stop leaning the argument on them. Lead with: nothing about the member is held or used, and nothing the Company chose determines which instrument, side, timing or rank. |
| D11 | **Layer 1 contract / R1.2** — the signal payload | The `side` field is the one unresolved variable in the entire recommendation line: every favourable text concerns a condition or news alert, none a direction | NASD NTM 01-23 n.18 ("without more"); 88 FR 53975 | **FLAG** | Record `side` as a named open question rather than a settled property of the contract. |

## Legal Position

| # | Anchor | What P8 found | Direction | What the card or guardrail would have to say |
|---|---|---|---|---|
| D12 | **Guardrail 15** — carries the same express **Open** as R2.4 | Closed. Six brokers, credential test | **CLOSE THE OPEN** | Replace the Open sentence with the finding and the citations. This is the single most satisfying change P8 produces. |
| D13 | **Guardrail 08** — "the architecture requires a surface the engine cannot fake" | The requirement survives; the rationale is wrong. The surface is evidence, and owning it is a liability unless lock-out is provable | **REWRITE THE RATIONALE** | "One explicit act per order, on a surface the engine cannot fake — and the operator must be able to prove it is locked out of that surface and of the journal. The lock-out is what the case law credits; ownership is not." |
| D14 | **Guardrail 05** — "The member's own broker executes and controls risk" | Add the permission dimension. Three of six brokers gate which software may connect, on grounds unrelated to who decided | **ADD** | Add a sentence: the broker also decides whether this software may connect at all, and that question is not answered by anything about the member's control. |
| D15 | **Guardrail 10** — carries "Still to do: read the brokers' terms on third-party display" | Partly done. The brokers' *order* terms are now read in full; the *market-data* display terms remain the open half | **NARROW THE OPEN** | Say which half is closed. |
| D16 | **Card 03** (adviser status, 3) | Score unchanged. The reasoning under it should move from authorship to content and absence of personalization | **RE-REASON, SCORE UNCHANGED** | "Why this score" should lead with personalization × specificity and cite 88 FR 53975 and *David Lerner*; and it must record *Donelson*, in which the customer confirmed every trade and it counted for nothing. |
| D17 | **Card 04** (unregistered broker-dealer, 3) | Score unchanged. Add the survivor evidence, stated as documented absence and not as authority; add that no located product pairs all three defining facts | **ADD EVIDENCE, SCORE UNCHANGED** | Name the FINRA and NFA gaps in the same breath. |
| D18 | **Card 06** (Washington, 3) | **Washington repealed** WAC 460-21B-060 and 460-22B-090 effective 13 Oct 2024. The replacement, WAC 460-20C-210(6), omits both the "definite amount of a specified security" requirement and the business-day limit | **CORRECT — and this widens the margin the card already calls thin** | Cite the current rule, and record that Washington's version of the time-and-price concept is broader than FINRA's on three axes. |
| D19 | **Card 01** (solicitation, 4) | Unchanged by P8. No new authority located. The 1996 Schwab condition-1 disclosure remains the only located cure and still does not appear in the documents | **UNCHANGED — carry P7's recommendation forward** | — |
| D19b | **Card 03's "Legal reference" line**, which lists *R&W Technical Services*, *Weiss*, *Terry's Tips* and *Park* as adverse without qualification | *R&W* is a **CEA** case, and the CEA's publisher exclusion is narrower than the Advisers Act's; *Terry's Tips* is read by the Fourth Circuit as an **auto-trading** case | *Commodity Trend Service v. CFTC*, 233 F.3d 981, 988 (7th Cir. 2000); *SEC v. Pirate Investor LLC*, 580 F.3d 233 (4th Cir. 2009) | **QUALIFY — this is a markdown of the card's own adverse list** | Mark *R&W* as CEA and note the asymmetry; mark *Terry's Tips* as auto-trading, which the configuration is not. Neither is removed; both are weighted correctly for the first time. |
| D20 | **Guardrail 09** ("We speak one language") | Confirmed and extended. Five disclaimers, including a rewrite from "suggested investments" to "examples of potential investments", failed together in *David Lerner*; and NASD NTM 96-60 is still live and irreconcilable with 01-23 if read literally | **STRENGTHEN + FLAG** | Add that a disclaimer cannot cure, on four independent sources; and record 96-60 as an unreconciled adverse text. |
| D21 | **New guardrail, or an addition to 14** | Nothing in the documents currently records that the Company must satisfy each broker's third-party-software permission regime, or that broker approval says nothing about legal status | **ADD** | Schwab §3 and Fidelity's Account Authority form both disclaim any view on registration. That disclaimer belongs in the position, so nobody later reads a broker approval as comfort. |

---

# 5 · CONSOLIDATED ADVERSE REGISTER

Ranked by threat across all seven sub-registers. Per-track adverse registers with full quotation are in Part A.

| # | Authority | Track | Threat | Distinguishes — or fails to |
|---|---|---|---|---|
| 1 | ***Rome v. Mandel***, 405 P.3d 387 (Colo. App. 2016) ¶40 — the follower could **exclude named securities** and **cap position size**, and the court held the tailoring question "**immaterial**" | 3 | **5** | **Only on execution, not on configuration.** Ditto Trade executed "without need for further instruction or approval" and followers were "often not aware of the trades until after they have occurred"; the configuration inverts both. **It takes no comfort from the member's own exclusions and caps — that follower had both.** The sharpest located rejection of a user-configuration defence on adviser status. |
| 1b | ***CFTC v. Donelson (Long Leaf)***, No. 23-1809 (7th Cir. 5 Sept. 2024) — **the customer confirmed every trade and it counted for nothing**; and "[e]ven if *Taucher* or *AVCO* drew a line between personal and impersonal advice, **the text of the statute does not**" | 3 | **4** *(marked down from 5 — see below)* | **Only on content and compensation.** Not on user control, not on the per-order act; any Q1 argument leaning on the tap leans on the fact this court discarded. **But it is a CEA case**, and ***Commodity Trend Service***, 233 F.3d at 988 holds that "bona fide publishers are not IAs even if their entire business concerns giving impersonal securities trading advice… [whereas] impersonal publishers… are included within the definition of CTA." What transplants into Q1 is the factual demonstration; **the inference from CTA status to adviser status does not.** The same markdown applies to *Hall*, *R&W*, *Taucher* and *Vartuli*. |
| 2 | **Fidelity Terms of Use, "Prohibited Uses"** — third-party access tools to trade prohibited absent express written approval, "**even if instructed to do so by an authorized user**" | 1b | **5** | **No.** Drafted to make consent irrelevant. Every distinguishing feature of the configuration is an argument about consent and attribution. Limited in practice only because Fidelity has no retail API. |
| 2b | **Rel. 34-49883 at 7 (17 Jun 2004)** — commenters asked that the writing lifting the day limit be allowed as "**general 'standing' instructions, rather than issuing written instructions on an order-by-order basis. NASD declined to adopt this position.**" Standard is **trade-specific** | 4 | **5** | **No.** A regulator was asked for exactly what the standing track proposes and refused. There is no distinguishing fact available. |
| 3 | ***Michael Pino***, Rel. 34-74903 (2015) — "**a customer's approval of a general strategy does not meet the requirements of the 'time and price discretion' exception**"; definiteness attaches to the customer's grant | 4 | **5** | **Per-order: yes, cleanly. Standing: no, not at all.** The losing formulation in *Pino* is the standing-mode argument. |
| 4 | **IAA SLOA letter (21 Feb 2017)** — the requester argued a *bounded* standing authorization differs in kind from an open one; the staff answered "**We disagree.**" | 4 | **5** | **No, not on the reasoning.** Writing, bounds, revocability and agency framing were all present and all insufficient. Distinguished on subject matter (custody) only. |
| 5 | ***In re eToro USA LLC***, Rel. 34-101001 (12 Sep 2024) — the one status holding among sixteen survivors | 2 | **5** | **Yes, on several facts at once** — eToro held the keys and the funds, netted and routed. But it is the datapoint on the other side of the documented silence, and it is recent. |
| 6 | **17 C.F.R. §275.203A-2(e)(2)** — software output "based on personal information each client supplies" **is** investment advice, re-adopted 2024 | 3 | **5** | **No.** The configuration can say the member supplies a decision *rule* rather than facts about himself. **No authority draws that distinction**, and the rule's structure treats client-supplied inputs as constitutive of advice, not exculpatory. |
| 7 | **Fiduciary Interpretation, 84 FR 33669** — "the relationship in all cases remains that of a fiduciary to the client"; client-set parameters narrow scope of duties, not status | 3 | **5** | **No.** The cleanest statement of the pattern, and it forecloses the intermediate move. |
| 8 | **E*TRADE API Developer License Agreement §§1.19 + 4.9** — automated generation, modification, cancellation or management of an order without a discrete, contemporaneous, specific instruction for that order; violation "deemed unauthorized" | 1a, 1c | **5** | **Per-order: yes, on the grammar of the qualifier — and only on that.** Standing: no, prohibited outright. Re-peg and end-of-day sweep: **not distinguished**; "contemporaneous" is undefined. |
| 9 | **Composer Technologies, Form ADV** — user-authored rules, flat subscription, user's own broker account; **registered as an investment adviser from day one**, portfolio management not publication, $0 non-discretionary | 2 | **4** | **On discretion and the per-order act only** — not on the fee, and not on the member having written the rule. |
| 10 | ***Banister***, 64 Cal. App. 5th 541 and ***Garcia***, 102 Cal. App. 5th 41 — attribution fails where the party asserting the act could have produced it itself | 6 | **5** | **Only by proving lock-out.** A runtime that renders the surface, holds the credentials and mints the record is in the losing posture until it can show the operator *could not* reach in. |
| 11 | **Reg E Official Interpretation, comment 10(b)-2** — where the authorization is defectively obtained, "it is the **third-party payee** that is in violation of the regulation" | 6 | **4** | **No, on structure.** The renderer of a consent surface acquires duties in every regime examined. Distinguished on regime and on local installation; neither distinction tested. |
| 12 | **17 C.F.R. §240.17a-3(a)(17)(ii)** + Rel. 34-44992 **n.21** — "the dated signature of **each natural person** to whom discretionary authority was granted", wording inherited from NASD 2510(b) / NYSE 408 | 4 | **4** | **Per-order: not triggered. Standing: unavoidable.** A grant to a program produces an instrument for which the federal record has no field. |
| 13 | **FINRA Rule 3260(b)** — "prior written authorization to **a stated individual or individuals**", plus written acceptance of the account by the member | 4 | **4** | **No.** The only vocabulary the rulebook supplies for a grantee is "individual" — and the second element requires the member's own broker, with whom the Company has no agreement. |
| 14 | **FINRA Rule 3260(d)(1)** — day-limited, "absent a specific, written contrary indication signed and dated by the customer"; lifted only for **institutional** accounts under Rule 4512(c) | 4 | **4** | **No — the direct hit on standing mode.** The configuration cannot have both a standing authority and the unmodified benefit of (d)(1). Second authority in the register gated on institutional status. |
| 15 | **FINRA RN 16-21** — an idea generator escapes only if "not equipped to automatically generate orders … (whether independently or **via a linked router**)" | 4 | **4** | **Per-order: yes, the tap breaks the coupling. Standing: no**, and whether a member-controlled local runtime is "a linked router" is addressed by nothing. |
| 16 | **SEC, *All About Auto-Trading*** (2009) — "Generally, the SEC considers firms that publish investment newsletters and that also engage in 'auto-trading' to be investment advisers" | 4 | **4** | **Per-order: yes, on the alert's own defining feature (no trade without the member's permission). Standing: no.** Aggravated because the engine layer is signal publication. |
| 17 | **tastytrade API TOS §2(3)(f)** — software used with the API must be "**developed and owned by you**" unless approved | 1b | **4** | **No — squarely caught.** A free open-source runtime the member did not write is, on the plain words, software needing prior written approval. Unavoidable by design. |
| 18 | **Schwab ESA §14** — only browsers or software "formally approved by Schwab in writing" | 1b | **3** | **Only by going through the gate.** The Developer Program is that written approval, and §3 disclaims any view on legal registration. |
| 19 | **IBKR third-party OAuth Registration Process** — third parties offering automated trading solutions "would hold applicable registration … unless you are able to provide support (i.e. a legal opinion)" | 1a | **4** | **No.** The configuration meets the definitional sentence. The only alternative offered is a legal opinion, and no counsel is engaged. |
| 20 | **NASD NTM 96-60** — a security is recommended when a member brings it to the customer's attention "**through any means**", irrespective of the solicited/unsolicited label | 5 | **4** | **No — and nothing reconciles it with 01-23.** Live, unreconciled, and irreconcilable with 01-23's permitted examples if read literally. |
| 21 | ***In re David Lerner Associates***, Rel. 34-105556 (27 May 2026) — a template of three to five named securities was a recommendation; five disclaimers failed | 5 | **4** | **Yes, on personalization** — the finding is "individually tailored … to a specific customer", which the configuration is not. Adverse on the disclaimer point without qualification. |
| 22 | **Solely Incidental Interpretation, 84 FR 33681** — items (i) and (vii) describe the configuration's envelope almost verbatim, **and call it investment discretion** | 3 | **4** | **Two-edged; must not be cited one-sided.** Adverse to any claim that no discretion exists at all. And the interpretation is available only to a registered broker-dealer. |
| 23 | **Rel. 34-84528 at 70 / Rule 606 FAQ** — discretion defined to include "adjusting or customizing algorithm parameters" | 4 | **3** | **Two-edged.** Supports "the member configures, therefore the member decides"; also means parameter-setting is itself named discretion, so a Company preset would be the Company exercising it. |
| 24 | **Reg BI adopting release fn.182** — "as an allocation recommendation becomes narrower or more specific, the recommendation gets closer to becoming a recommendation of particular securities" | 3, 5 | **4** | **No.** A signal naming one instrument and a side sits at the specific end. |
| 25 | **CFTC Staff Letter 03-26** — registration required "even if the CTA is not authorized to effect transactions **without the client's specific authorization**" | 3 | **3** | **Per-transaction client authorization expressly held insufficient.** Distinguishable on per-trade commission and solicitation, both absent here. |
| 26 | **FINRA Rule 2111(b) and *S3 Matching*** — where an SRO gave effect to customer independence, it confined the relief to **institutional** accounts | 3, 4 | **3** | **No — the structure is the problem.** Third instance of the institutional gate. The configuration is retail by design. |
| 27 | **IM Guidance Update 2017-02** — where a regulator addresses "the client chose it himself" in automated advice, the answer is that the adviser should *add* commentary | 3 | **3** | **No.** Obligations increase; they do not lapse. |
| 28 | **Rel. 33-7881's definition of "date"** — "the specific day of the year on which a market order is to be executed" | 4 | **3** | **No.** The track's strongest supportive text carries a defined term a condition-triggered plan does not cleanly satisfy. Unaddressed by any authority, which is the only thing holding it at 3. |
| 29 | **WAC 460-20C-210(6)** (in force 13 Oct 2024) — omits both the "definite amount of a specified security" requirement and the business-day limit | 4 | **3** | **No.** Washington's replacement rule is broader than FINRA's on three axes, in the state where the technical lead's place of business is. |
| 30 | **12 C.F.R. §1033.431(b), (c)** — the party performing the authorization procedure must be **named** to the consumer and **certify** in its own right | 6 | **4** | **No.** In the closest regulatory model of the configuration's architecture, rendering the consent surface **adds** obligations rather than subtracting them. |
| 31 | **In re Betterment LLC**, IA-6288 (2023) — a client's own switch was silently defeated by the vendor's code for three years | 3 | **3** | **Factually, not legally.** The configuration's journal and versioning are exactly the controls that would surface such a divergence — but member control **cannot be claimed as self-executing**; it is a property of Company-maintained code. |
| 32 | **Alpaca Customer Agreement §10** — "not to allow **any person** to trade for My Account unless a trading authorization … has been received and approved by Alpaca" | 1b | **3** | **Partly.** No *person* trades for the account. But nothing in Alpaca's documents resolves whether third-party-authored software is "any person". |
| 33 | **IBKR API licence §3.3** — "not … redistribute the API Code" — against GPLv3 in the same distribution | 1a | **3** | **Unresolved on IBKR's own materials.** A real conflict, not resolved in the configuration's favour. |
| 34 | **Regulation M's three-month revision limit** on a plan formula | 4 | **2** | **No.** The one federal rule that expressly tolerates a machine-executed formula conditions that tolerance on the formula-setter not touching it more than quarterly. |

---

# 6 · WHAT P8 LEAVES OPEN

**A · P7's open question B is untouched.** Whether composing an order is "more than routing a message" — the 1996 Schwab letter's carve-out and *CommandTRADE*'s "other than by providing the functionality of order transmission" — remains undecided by anything located. It still determines whether the strongest supporting letters reach the configuration at all.

**B · P7's open question A is untouched.** No new authority on the solicitation residue was located. *Neovest* ¶14 stands where P7 left it, and the 1996 letter's condition-1 disclosure remains the only located cure and still does not appear in the documents.

**C · The `side` field.** Every favourable text in the recommendation line concerns an alert about a condition or about news. None concerns an alert that names a direction. NTM 01-23's holding is expressly "without more", and nothing says whether a side is "more". **This is the sharpest new open question in P8** and it sits on the Layer 1 signal contract.

**D · The permission question has no home in either document.** Attribution is answered. Permission — may this software connect at all — is a separate condition that three of six brokers impose, that no consent architecture reaches, and that neither the Target Architecture nor the Legal Position currently records.

**E · Which E*TRADE version binds, definitively.** §11.8 answers it as a matter of drafting, and Copy A is provably a redline of Copy B, but the signature surface is MFA-walled and was not entered. The date §4.9 went live could be bracketed only to 9 May – 7 September 2026, and the reason is a documented Common Crawl coverage gap rather than an untried search.

**F · Whether a member-controlled local runtime is "a linked router"** within FINRA RN 16-21's parenthetical. Addressed by nothing located. It is the sharpest question standing mode raises in FINRA's own vocabulary.

**G · Whether a grantee of a trading authorization may be a program.** No authority either way. The drafting chain is uniform and traceable to SRO rules that simply assumed a human. An absence, not a prohibition — but there is no template to point at.

**H0 · A corpus defect that qualifies every null search in this register.** CourtListener's opinion index does **not contain** *SEC v. Coinbase* or *Risley*, and contains **no SEC or CFTC administrative decisions at all.** Every "COUNT 0" reported anywhere in P8 — and in P7, which used the same tool — is **a zero in an incomplete corpus, not a zero in US law.** This is stated once here and repeated in each sub-register's negative findings. It does not withdraw any negative finding; it fixes their weight.

**G2 · One private docket unretrieved.** *Alpha Futures v. NinjaTrader Group*, N.D. Ill. 1:26-cv-08846 — the complaint was not obtained. It costs $1.20 on PACER, or nothing under the $30 quarterly waiver. It is the only one of the five private suits whose subject matter is unknown, and it is reported as UNKNOWN rather than as a zero.

**H · The FINRA and NFA walls.** FINRA disciplinary actions sit behind a Cloudflare challenge and NFA BASIC blocks programmatic access across nine probed endpoints. Track 2's silence is documented everywhere else and **is not claimed** for those two. Anyone relying on the survivor evidence must say so. **The NFA wall has a specific consequence:** CTA registration status for every survivor is **UNVERIFIED**, and *Taucher v. Born* — the case that holds user-entered parameters did not remove a publisher from a statutory definition — is a CTA case. The one line of authority most directly on the configuration's mechanism is the one line whose real-world registration practice could not be checked.

**I2 · A better tool the register did not use.** The **FJC Integrated Database** — the Administrative Office's own docket dataset — is unwalled and answers nature-of-suit questions directly. It should be the first stop ahead of CourtListener and Justia in any future round.

**J.** ~~One unread lead: *Sherter v. Ross Fialkow* (Mass. Super. 2013).~~ **CLOSED, 7 September 2026, and it cost nothing.** The opinion was obtained free — *Sherter v. Ross Fialkow Capital Partners, LLP*, Suffolk Super. Ct. Business Litigation Session No. 10-1888-BLS1, Billings J., 4 Jan. 2013, 31 pp., reported at **31 Mass. L. Rptr. 98** — from CourtListener and from plaintiffs' counsel's own posted PDF. **It is not evidence on Q1, Q2 or Q3.** It is a private class action against a law firm and two of its partners who solicited promissory notes for a Ponzi operator, pleaded under the Massachusetts Uniform Securities Act as unregistered broker-dealer, unregistered-securities and misstatement claims; summary judgment denied. The word "software" appears **once** in the whole opinion, inside a case citation (*Greebel v. FTP Software*). **Track 3's search string was sound; its single hit is a false positive, and the null result on that search now stands clean.**

## The three questions counsel should be asked first, in order — revised by P8

**1 · Unchanged from P7: after *Neovest* ¶14, is there any marketing posture that answers the solicitation finding?** P8 found nothing that moves it, which raises rather than lowers its priority.

**2 · New, and it displaces P7's third question: does E*TRADE §4.9 reach the price-and-time envelope and the end-of-day sweep, and if it does, what is the configuration's answer?** This is answerable today, it is contractual rather than regulatory, it bears on the first supported broker, and a wrong answer is discoverable before launch. Ask counsel whether an automated re-peg within a member-set band, executed as a cancel-and-replace, is "a discrete, contemporaneous, and specific instruction … for that particular order" — and, if not, whether the envelope survives at that broker in any form.

**3 · Unchanged from P7, moved down one: is the runtime's composition-and-transmission step "more than routing messages"?** P8 located nothing new, and it remains the question that determines whether the best supporting letters reach the configuration.

*P7's former third question — whether a runtime-rendered document satisfies WAC 460-24A-220(5) — moves out of the first three. P8 establishes that the question does not arise in V1 (nobody is granted discretionary authority) and that in standing mode it is preceded by a harder one: whether a bounded standing authority remains the member's own at all, which is where *Pino* and the SLOA letter's "We disagree" now sit.*

---

# PART A — THE SUB-REGISTERS

Nine sub-registers in full. Each is self-contained: register entries with verbatim pin-cited quotes, an adverse register, direct answers, negative findings with the endpoints and counts that established them, a search log, and a ◇ list.

**Standing caveat on every null search in Part A.** CourtListener's opinion index does not contain *SEC v. Coinbase* or *Risley*, and contains no SEC or CFTC administrative decisions at all. Every COUNT 0 below is a zero in an incomplete corpus, not a zero in US law.



---

# S1a · TRACK 1a — Broker terms for third-party software: E*TRADE (Morgan Stanley) and Interactive Brokers

**Commission P8. Bears on Q3 (customer instruction) primarily, Q2 (broker characterization) secondarily.**
**All retrieval dates 7 September 2026 unless stated. All quotes verbatim.**

---

## PART A · INTERACTIVE BROKERS — register entries

### A-01 · Interactive Brokers LLC Client Agreement, form 3203, document date 10 January 2025 · https://ndcdyn.interactivebrokers.com/Universal/servlet/Registration_v2.formSampleView?formdb=3203&lang=en · retrieved 7 Sep 2026

- **Type:** published terms (customer-facing brokerage account agreement)
- **Date / status:** Document bears its own header stamp "3203 | 10 January 2025". Listed as current on IBKR's Client Agreements index, `https://www.interactivebrokers.com/en/accounts/forms-and-disclosures-client-agreements.php`, whose JSON backing store (`https://www.interactivebrokers.com/webrest/general/forms/?ids=...&langs=en`) gives `{'formNumber': 3203, 'name': 'Interactive Brokers LLC Client Agreement', 'last_updated_date': '2025-01-10'}`. Good law as contract; 30 pages.

**Verbatim quote, pin-cited — ¶4 "Responsibility for Client Orders/Trades" (complete):**

> "4. **Responsibility for Client Orders/Trades:** Client is responsible for the confidentiality and use of, and will reasonably safeguard and will not permit others to use, Client's account credentials, such as Client's username, password or security device. Client agrees to provide immediate Notice to IBKR of any theft or loss of such credentials, or any unauthorized access to Client's account. **Use of Client's credentials to effect any action will constitute conclusive evidence that IBKR may treat such action as authorized. Client is responsible for all transactions entered using Client's credentials.** IBKR is not liable for loss or damages caused by any third party using Client's credentials. **Unless IBKR agrees in a writing executed by its Chief Executive Officer or General Counsel, Client will not permit any third party to access Client's account using Client's account credentials.**"

(Bold added for locating only; the source is unemphasised.)

**Verbatim quote, pin-cited — ¶2 "No Advice Regarding Investment, Tax, Trading or Account Type" (extract):**

> "Client agrees that any order submitted to or transaction executed by IBKR is solely Client's own decision and is based on Client's own evaluation of its personal financial situation, needs, and investment objective(s). IBKR does not endorse and is not responsible for any advice, representation, content or other information provided by third parties, including but not limited to any such information or third party referenced by or accessed through any IBKR website, application or platform, including but not limited to the 'IBKR Investors Marketplace.'"

**Verbatim quote, pin-cited — ¶9.A:**

> "IBKR has no responsibility for Client's transmission of orders that are inaccurate or not received by IBKR, and may execute any order or trade on the terms actually received by IBKR. Client is bound by its trades as executed, if execution is consistent with Client's order as entered."

**Verbatim quote, pin-cited — ¶5.B "Special Risks of Algorithmic Orders" (extract):**

> "IBKR makes available various order types that use computerized algorithms. These order types allow Client to input various conditions as part of an order placed with IBKR. Client agrees that if algorithmic order types are used, it is Client's responsibility to understand how the order type works… Algorithmic trading involves special risks, including, among others, the risk of software or design flaws, technical errors, adverse market impacts from algorithmic orders and rapid losses."

**Verbatim quote, pin-cited — ¶41 "INDEMNIFICATION" (extract):**

> "Client agrees to indemnify, hold harmless and defend IBKR… from any and all liabilities, losses, costs, judgments, penalties, claims, actions, damages, or expenses… arising from or relating to: (i) any action taken in reliance on any representation, information or instruction received from Client…"

**What it establishes:** IBKR's customer contract makes credential use dispositive of authorisation and places all responsibility for transactions entered with the client's credentials on the client — without regard to what software formed the order. It contains no API clause, no automation clause and no human-review clause. In the same paragraph it prohibits the client from permitting *any third party* to access the account using the client's credentials absent a writing executed by IBKR's CEO or General Counsel.

**Q1 / Q2 / Q3:** Q3 **SUPPORT** on the first half of ¶4 and on ¶2 and ¶9.A; Q3 **ADVERSE** on the last sentence of ¶4. Q2 NEUTRAL.

**Level 3** — published contract terms of the named broker, current and directly addressed to whose instruction an order is; not law, and not a regulator's construction.

**Application note:** In the configuration, trade-capable credentials exist only in the runtime, in the member's own local keychain, per member, with no company-level or app-level trading credential. On the first half of ¶4 the composed order transmitted under the member's own key is, as between IBKR and the member, conclusively the member's own authorised action and the member's own responsibility. The last sentence of ¶4 is the pressure point and is not distinguished by anything in the configuration on the face of the text: whether a locally installed, member-controlled runtime holding the member's credentials in the member's own vault is "a third party access[ing] Client's account using Client's account credentials" is not answered by the clause. Two readings are available on the text and the agreement does not choose between them — (i) the runtime is the member's own tool and the accessing person is the member, or (ii) the runtime is a third party and the member has breached ¶4 absent a CEO/GC writing. Nothing in the Client Agreement resolves this. IBKR's technical documentation (A-05, A-06) resolves it in a different instrument and in the configuration's favour for the locally-authenticated route; that is a documentation page, not a contract term.

---

### A-02 · TWS API Non-Commercial License · https://interactivebrokers.github.io/ · undated on its face; HTTP `last-modified: Thu, 27 Aug 2026 06:47:15 GMT` · retrieved 7 Sep 2026

- **Type:** published terms (click-through software licence; "I Agree" gate in front of the API download)
- **Date / status:** No date on the instrument. Server last-modified 27 Aug 2026. **Text of §0 verified unchanged across Wayback snapshots 2 Jul 2019 (`20190702094623`), 9 Jan 2023 (`20230109231643`) and 30 Aug 2026 (`20260830233851`)** — see search log #24. Current: gates the download of TWS API Stable 10.45 (released 30 Mar 2026) and Latest 10.50 (released 26 Aug 2026).

**Verbatim quote, pin-cited — preamble and §0 (complete):**

> "This TWS API Non-Commercial License ('License') is an agreement between Interactive Brokers LLC ('IB') and You, and governs Your use of the API Code. By clicking the 'I AGREE' button below, you acknowledge that You consent to be legally bound by this Agreement.
>
> 0. **Introduction.** IB has developed application program interface ('API') code to permit its customers to use their own internal proprietary software tools in managing their accounts with IB. This License is intended only for users who wish to use the API Code by itself as is, or in connection with or for the development of their own internal proprietary tools to manage their own IB accounts. **This License is NOT for anybody who is developing software applications that they wish to: (a) sell to third party users for a fee, or (b) give to third party users to generate an indirect financial benefit (e.g., commissions).** If You wish to make a software application for the purposes described in the preceding sentence then please contact Shail Mangla at opensource@interactivebrokers.com ."

**Verbatim quote, pin-cited — §1.2:**

> "1.2. 'Non-Commercial Purposes' means using API Code by itself as is, or in connection with or for the development of applications, programs, or other works that (a) interface with IB's trading platform, and (b) allow You to access Your account information, access market data, perform analytics, enter orders, or perform any other transactions or functions all in connection with Your account at IB."

**Verbatim quote, pin-cited — §2.1, §3.1, §3.3, §3.4, §3.5:**

> "2.1. Subject to the terms of this License, IB hereby grants You… a personal, royalty-free, non-exclusive, non-sublicensable, non-transferable, restricted right and license to install, modify and use the API Code solely for Non-Commercial Purposes."
>
> "3.1. You acknowledge and agree that You shall only use the API Code for Non-Commercial Purposes. Any other uses of the API Code are expressly prohibited."
>
> "3.3. You agree not to publish, disseminate, or redistribute the API Code to any third party."
>
> "3.4. You agree that You will maintain an account at IB for the duration of this License."
>
> "3.5. You agree not to use the API for any purpose that violates any law or regulation, any right of any person… or in any manner inconsistent with IB's terms of use, privacy policy or this License."

**Verbatim quote, pin-cited — the standing note beneath the download table on the same page:**

> "Note: As a reminder, the use of the TWS API as a means of disseminating information, including market data or any other licensed or copyrighted information, to third parties or non-registered IB customers is strictly prohibited without prior written approval of Interactive Brokers."

**What it establishes:** IBKR's default API licence is expressly scoped to a customer using the code as *his own* tool to manage *his own* IB account, and is expressly *not* available to a person who develops an application to give to third-party users for a fee or for indirect financial benefit. That person is routed to a separate, negotiated licence.

**Q1 / Q2 / Q3:** Q3 **SUPPORT** as to the member (a member using the API code to enter orders in connection with his own account at IB is the paradigm case §0 and §1.2 describe). Q2 **ADVERSE** as to the company (a developer distributing the runtime to members falls in §0's excluded class and must obtain a different licence).

**Level 3** — current, stable, published contract terms of the named broker, squarely addressed to the exact distinction in issue.

**Application note:** This clause splits the configuration in two, and the split is clean. (i) **The member** accepts this licence himself, installs the code on his own machine and uses it to enter orders in connection with his own account at IB. That is §1.2's "Non-Commercial Purposes" on the face of the definition, and §0's "own internal proprietary tools to manage their own IB accounts". (ii) **The company** distributes a free, open-source runtime to members who pay a flat monthly community membership. Nothing per trade, on volume, on assets or on performance, and no payment from brokers — so §0(a) "sell to third party users for a fee" is not met by the runtime itself, which is free. But §0(b) — "give to third party users to generate an indirect financial benefit" — is not confined to commissions; "(e.g., commissions)" is illustrative, not limiting. A free runtime given to members whose membership fee is the company's revenue is within the natural reading of §0(b), and IBKR's own instruction for that case is to contact opensource@interactivebrokers.com for a different licence. **This is an adverse finding and the configuration does not distinguish it.** Separately, §3.3 forbids redistributing the API Code to any third party, which on its face bars shipping IB client code inside a distributed open-source runtime — see A-03 for the countervailing GPL grant, which is a genuine conflict on IBKR's own materials and is not resolved by either instrument.

---

### A-03 · TWS API distribution licence — GNU General Public License v3 · `IBJts/LICENSE` and source headers in `https://interactivebrokers.github.io/downloads/twsapi_macunix.1050.01.zip` (TWS API Latest 10.50, released 26 Aug 2026) · retrieved 7 Sep 2026

- **Type:** published terms (open-source licence shipped in the distribution)
- **Date / status:** In-archive file timestamps 26 Aug 2026 11:30. Downloaded 11,413,089 bytes, HTTP 200.

**Verbatim quote, pin-cited — `IBJts/LICENSE`, first two lines:**

> "                    GNU GENERAL PUBLIC LICENSE
>                        Version 3, 29 June 2007"

**Verbatim quote, pin-cited — header of `IBJts/source/pythonclient/ibapi/client.py`:**

> "Python TWS API Client
>
> Copyright (C) 2013-2026  Interactive Brokers LLC
>
> This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version."

**Verbatim quote — IBKR's own API landing page, `https://www.interactivebrokers.com/en/trading/ib-api.php`, "TWS API" panel, retrieved 7 Sep 2026:**

> "Latest API is now released as open source under the GPL license"

**What it establishes:** The TWS API client code as actually distributed carries a GPLv3 grant, in the LICENSE file and in per-file source headers, expressly permitting redistribution and modification. IBKR's own marketing page says the same.

**Q1 / Q2 / Q3:** Q2/Q3 **SUPPORT**, but qualified — it directly contradicts A-02 §3.3.

**Level 3** — primary text of the licence as shipped by the broker.

**Application note:** There is an unresolved conflict on IBKR's own primary materials: the click-through gate at A-02 §3.1/§3.3 restricts use to "Non-Commercial Purposes" and forbids redistribution to any third party; the artefact behind the gate is licensed GPLv3, which grants exactly the redistribution §3.3 forbids and imposes no non-commercial limit. A free, open-source runtime that links or ships the IB client code has a colourable GPLv3 grant on the file headers and the LICENSE file. **No IBKR instrument located states which governs.** This is flagged as a live conflict, not resolved in the configuration's favour. Note also that GPLv3 is copyleft: a runtime that links this code and is distributed engages GPLv3's own reciprocal obligations. The configuration already contemplates a free, open-source runtime, so the copyleft direction is not in tension with it.

---

### A-04 · Third Party REST WebAPI Application (developer onboarding questionnaire) · https://www.interactivebrokers.com/download/WebAPI_Onboarding_Questionnaire.pdf · PDF CreationDate 19 March 2024; HTTP `last-modified: Tue, 19 Mar 2024 15:06:27 GMT` · retrieved 7 Sep 2026

- **Type:** published terms / broker-imposed developer requirement (3-page application form)
- **Date / status:** Current — linked as "Onboarding Form / Begin Onboarding" from the "Third Party Developer" panel of IBKR's live API page, `https://www.interactivebrokers.com/en/trading/ib-api.php`.

**Verbatim quotes, pin-cited:**

Header, all three pages:
> "Third Party REST WebAPI Application
> Please provide responses to all the questions below and submit to webapionboarding@interactivebrokers.com"

Section A:
> "Section A: Provide general information requested below. **Please note that applicants must have a registered company and completed website to qualify for review.**
> Entity name and Product name (if different from entity name):
> Website URL:
> Physical location of headquarters:
> Location of technology (e.g., servers):
> Provide names and contact information of the firms:
>     a) Principal(s):
>     b) Compliance Officer (if any):
>     c) Officers or Directors:"

Section B:
> "Section B: **IBKR conducts an enhanced due diligence review of each application.** Please provide responses to the questions below with as much detail as possible. Failure to provide sufficient information may result in delays during the review.
> Please provide a detailed description of the firm's business model, services being provided and how the REST WebAPI will be used/integrated by the firm?
> If not already outlined above, please describe the client workflow within the UI.
> Please describe your firm's fee model for the services provided. (i.e., who is compensated, for what are they compensated, and how/when is that compensation paid?"

Section B, trading block:
> "If trading/order routing is offered, please answer the following:
>     a) **How are orders routed from the end-user to IBKR (i.e., who touches the orders) and Is auto-trading supported?** If so, please provide a detailed description of a scenario where this logic would be applied (origination to execution of an order and the involvement of both parties).
>     b) What products are offered for trading (e.g. STK, OPT, FUT, etc.) and in which markets…
>     c) **List all of Securities and/or Commodities Registrations the firm holds (include Country, Regulator, Name and Type of Registrations):**"

**What it establishes:** IBKR requires a third-party developer to be a registered company with a completed website, to name its principals, officers/directors and compliance officer, to disclose its fee model and who is compensated, to state **who touches the orders** and whether auto-trading is supported, and to **list all securities and/or commodities registrations the firm holds** — as a precondition of review.

**Q1 / Q2 / Q3:** Q3 **ADVERSE-LEANING** — the broker's own gate is framed around "who touches the orders", i.e. the very attribution question, and the broker reserves the answer to itself. Q2 **ADVERSE** on the entity/registration conditions.

**Level 3** — the broker's own current, published developer-admission instrument.

**Application note:** Direct hits on the configuration. "Please describe your firm's fee model… who is compensated, for what are they compensated" — the configuration's answer is a flat monthly community membership with a 20% share to a community/name owner expressly for the name and the member relationship, nothing per trade, on volume, on assets or on performance. "Who touches the orders" — the configuration's answer is that the runtime composes the order from the member's own local policy and transmits it under the member's own key after the member's own per-order tap on a runtime-owned approval surface. "Is auto-trading supported" — in V1, no; standing execution is a separate track, not shipped. "List all of Securities and/or Commodities Registrations the firm holds" — the configuration's answer is none. The form does not say that a nil answer disqualifies; it says the registrations must be listed. Compare A-06, which states IBKR's expectation directly. Note also that a Delaware LLC with two founders meets "a registered company"; "Compliance Officer (if any)" is expressly optional.

---

### A-05 · IBKR Web API — Authentication Introduction · https://www.interactivebrokers.com/docs/web-api/authentication/introduction (markdown at `…/introduction.md`) · undated page · retrieved 7 Sep 2026

- **Type:** published technical documentation (broker's own statement of which access route is open to which account type)
- **Date / status:** Live, server-rendered, HTTP 200, 3,042 bytes as markdown. No date stamp on the page.

**Verbatim quotes, pin-cited:**

> "## Client Portal Gateway
>
> The standard method of authenticating for authentication for the Web API. The Client Portal Gateway is a Java client that reverse-proxies authentication through SSO.
>
> ### Supported Account Types
>
> * Individual Accounts"

> "## OAuth 1.0a
>
> OAuth 1.0a allows users to authenticate fully programmatically using a custom build of the OAuth 1.0a authentication scheme passing a Live Session Token build by hashing a set of private keys within request headers.
> **OAuth 1.0a is the only supported authentication method for Third Party Developers.**
>
> ### Supported Account Types
>
> * Advisor Accounts
> * Broker & FCM Accounts
> * Proprietary Trading Group Accounts
> * Hedge and Mutual Fund Accounts
> * Institutional Hedge Fund Investors
> * Third Party Software Developers"

**Verbatim quote — `https://www.interactivebrokers.com/docs/web-api/authentication/cpgw/limitations-of-the-client-portal-gateway.md`, retrieved 7 Sep 2026:**

> "* **Users must log in through the browser on the same machine as Client Portal Gateway in order to authenticate.**
> * **All API Endpoint calls must be made on the same machine where the Client Portal Gateway was authenticated.**
> * None of the endpoints beginning with /gw/api, /oauth, or /oauth2 are supported for use in the Client Portal Gateway."

**Verbatim quote — `https://www.interactivebrokers.com/docs/web-api/authentication/oauth-1a/introduction.md`, retrieved 7 Sep 2026:**

> "Interactive Brokers makes a distinction between first-party use of OAuth directly by clients and third-party use of OAuth by vendors of software, described below."

**Verbatim quote — `https://www.interactivebrokers.com/docs/web-api/introduction.md`, retrieved 7 Sep 2026:**

> "Our trading API is available to all IBKR clients free of cost and can be used to manage trades, view real-time portfolio information, access market data, view contract information, and authenticate for brokerage sessions."

**What it establishes:** IBKR itself draws the line the configuration turns on, and draws it by *authentication route*, not by who wrote the software. The Client Portal Gateway route is (a) the route supported for **Individual Accounts**, (b) requires the *user* to log in through a browser **on the same machine**, and (c) requires all API calls to be made **on that same machine**. Individual Accounts are absent from the supported-account-type lists for both OAuth 1.0a and OAuth 2.0; OAuth 1.0a is "the only supported authentication method for Third Party Developers".

**Q1 / Q2 / Q3:** Q3 **SUPPORT** — strongest single support finding in this track for the configuration's local-runtime architecture.

**Level 3** — the broker's own current published documentation; technical, not contractual, and not signed by the client.

**Application note:** The configuration's architecture maps onto IBKR's Client Portal Gateway route almost exactly: a locally installed runtime on the member's own machine, trade-capable credentials only in the member's local keychain/vault, per member, no company-level or app-level trading credential. On this route the member himself authenticates, in a browser, on his own machine; the runtime then calls endpoints from that same machine. IBKR opens this route to Individual Accounts and demands no third-party registration for it, because on this route there is no third party in the credential path at all. The third-party developer route (OAuth 1.0a, registration, A-06) is the route for a vendor that authenticates on the customer's behalf from the vendor's own infrastructure — which the configuration expressly does not do. **This is the clause on which Q3 turns for IBKR.** Caveat, stated plainly: this is documentation, not a contract term, and it does not amend Client Agreement ¶4's last sentence (A-01).

---

### A-06 · IBKR Web API — Third Party OAuth "Registration Process" · https://www.interactivebrokers.com/docs/web-api/authentication/oauth-1a/third-party-oauth/registration-process (markdown at `…/registration-process.md`) · undated page · retrieved 7 Sep 2026

- **Type:** published terms / broker-imposed developer requirement
- **Date / status:** Live, HTTP 200, 3,477 bytes as markdown. No date stamp on the page.

**Verbatim quotes, pin-cited (the substantive body, near-complete):**

> "Interactive Brokers classifies third party entities as **any organization offering a platform or medium of trading to individuals outside of the organization.** Please note that interested groups that would like to register as a third party with Interactive Brokers must have an established platform with other brokerage firms, or a full proof of concept with an integration using the Web API.
>
> **Examples of this would include auto-traders or robo-advisors, public mobile applications, and groups forwarding market data.**
>
> For organizations that meet the criteria above and have an interest in integrating with Interactive Brokers, we would ask that you please email api-solutions@interactivebrokers.com .
>
> To give you a sense for the process ahead:
>
> 1. Our onboarding team conducts the initial vetting process. Once we have collected a sufficient amount of information, we will complete a preliminary review. Estimated time to complete this step is 2-3 weeks. Assuming we are able to proceed, we will send your application to our Compliance team for review.
> 2. **IBKR Compliance conducts an enhanced due diligence review on all third party applicants, followed by a three tier approval process.** Estimated time to complete Compliance related reviews and tasks is 3-6 weeks.
> 3. If Compliance approval is reached, **our Legal team will generate the WebAPI agreement** which we will send to you for review and signature. In parallel, we will ask you to provide public keys and a CallbackURL which will be required in to generate your consumer key and finalize the setup… Estimated time for our side to complete the aforementioned work and processes is 3-5 weeks.
>
> …During the enhanced due diligence reviews conducted by our Compliance teams, they will expect to see that 3rd Party Vendors looking to offer their services to our clients have a completed website with details on all of the features/services that will be provided and finalized details on their offering. This typically includes a clear user work flow for all components and details on their functionality, capability.
>
> As mentioned previously, should Compliance approval be reached we would be able to generate a live consumer key for you and **any significant changes to the offering after it has been approved (like addition of trading functionality) would require additional review and approval from our Compliance Teams before being offered to IBKR clients.**
>
> **Please be aware we expect 3rd Parties offering automated trading solutions would hold applicable registration with financial authority in all regions they plan offer the service, unless you are able to provide support (i.e. a legal opinion) as to why the business provided would not require registration that location.** Additionally, the offering will need to be reviewed and approved by Compliance teams in all regions you intend to support IBKR clients."

**What it establishes:** IBKR's definition of a "third party entity" is functional and broad — *any organization offering a platform or medium of trading to individuals outside of the organization* — and expressly names auto-traders and robo-advisors as examples. For third parties offering **automated trading solutions**, IBKR states an expectation of *applicable registration with the financial authority* in every region served, with a single stated alternative: **a legal opinion** supporting non-registration. Entry is gated by compliance due diligence, a three-tier approval, and a bilateral WebAPI agreement drafted by IBKR's Legal team. Post-approval changes — "like addition of trading functionality" — require fresh compliance approval.

**Q1 / Q2 / Q3:** Q3 **ADVERSE**; Q2 **ADVERSE**; Q1 **ADVERSE** by implication (robo-adviser named in the same breath).

**Level 3** — current published statement of the named broker's own admission requirements, directly on the registration question. Not law; a broker's contractual gate is not a legal characterization, and IBKR expressly frames it as an expectation subject to rebuttal by legal opinion.

**Application note:** This is the most adverse document located in this track, and it must not be softened. On its own definitional sentence — "any organization offering a platform or medium of trading to individuals outside of the organization" — the configuration is a third party entity: it offers a runtime and an approval surface to members, who are individuals outside the organization. The configuration does *not* meet IBKR's own "automated trading solutions" description in V1 if that phrase is read as auto-trading in the sense of A-07 (execution without the customer's per-order permission), because in V1 every order requires one explicit tap or swipe on the runtime-owned approval surface and standing execution is a separate, unshipped track. But the phrase is undefined here, and "auto-traders" appears in the *third party* definition's examples, not in a narrower automation carve-out. Two facts of the configuration bear directly and adversely: (1) **no counsel is currently engaged**, and the only alternative IBKR offers to registration is "a legal opinion" as to why registration is not required; (2) IBKR contemplates the third party authenticating via a CallbackURL and a consumer key issued to the vendor — a credential path the configuration expressly does not use. The escape from A-06 is not to argue with it but to be on the A-05 Client Portal Gateway route instead, where the vendor never authenticates and IBKR's third-party gate is not engaged. **Nothing located states that IBKR treats a locally installed runtime distributed by a vendor but authenticated solely by the member as outside the A-06 gate.** That is the single largest open gap in this track and it is a gap of silence, not of comfort.

---

### A-07 · IBKR "Disclosure Concerning Auto Trading Service Providers", form 4403, document date 1 April 2021 · https://ndcdyn.interactivebrokers.com/Universal/servlet/Registration_v2.formSampleView?formdb=4403&lang=en · retrieved 7 Sep 2026

- **Type:** published terms (broker disclosure adopting SEC investor-alert text verbatim)
- **Date / status:** Document header "4403 | 04/1/2021". Listed as current on IBKR's Disclosures index with `last_updated_date: 2021-04-01`. IBKR reproduces the SEC's text and attributes it: "The U.S. Securities & Exchange Commission (the 'SEC') has provided investors with the following information concerning Auto-Trading on the SEC's website at http://www.sec.gov/investor/pubs/autotrading.htm".

**Verbatim quote, pin-cited — IBKR's reproduction of the SEC text, ¶2:**

> "In an 'auto-trading' program, **you establish an account at a brokerage firm that has agreed to accept trading instructions from the investment newsletter.** In order to allow 'auto-trading' in your account, **you must sign an agreement with the broker authorizing it to accept trading instructions directly from the investment newsletter and to execute trades in your account without first getting your permission.** The broker will make trades in your account without consulting you about the price, the type of security, the amount and when to buy or sell."

**Verbatim quote, pin-cited — ¶3 and "Check Out the Newsletter":**

> "'Auto-trading,' like any other arrangement that **allows someone else to trade in your account without first asking your permission**, can be highly risky."
>
> "Check Out the Newsletter ? Find out whether the firm that's selling the investment newsletter is registered to do business as an investment adviser… **Generally, the SEC considers firms that publish investment newsletters and that also engage in 'auto-trading' to be investment advisers.**"

**What it establishes:** The broker publishes, and adopts, a definition of the adverse category. "Auto-trading" is constituted by two elements: (i) a signed agreement with the broker authorising the broker to accept trading instructions **directly from the third party**, and (ii) execution **without first getting the customer's permission**. The same document records the SEC's view that a newsletter publisher that *also* engages in auto-trading is generally an investment adviser.

**Q1 / Q2 / Q3:** Q3 **SUPPORT** (strong — the configuration fails both constitutive elements); Q1 **ADVERSE** as to any future standing-execution track.

**Level 3** — a broker's published disclosure reproducing an SEC investor-education page. The underlying SEC page is investor education, not a rule or a release; it carries no legal force of its own and the register should not treat it as one. Its weight here is that the named broker publishes it as its own disclosure of what auto-trading is.

**Application note:** The configuration fails element (i): there is no tripartite or bilateral agreement under which IBKR agrees to accept trading instructions from the company, and no company-level or app-level trading credential exists at IBKR at all. It fails element (ii) squarely: the member places each order by one explicit tap or swipe on a runtime-owned approval surface rendered in the signed runtime's own process, which mints an immutable instruction record bound to the exact displayed terms; the broker never trades without first getting the member's permission, because the broker receives nothing until the member has tapped. On IBKR's own published definition of the adverse category, V1 is not auto-trading. **The Q1 sentence is adverse and is not distinguished:** the SEC's stated view that a publisher that also auto-trades is generally an investment adviser would bite on the separate standing-execution track, which is not shipped in V1 and is where the written-authorization question was already reserved.

---

### A-08 · IBKR Regulation Best Interest Disclosure, form 4304, document date 5 March 2026 · https://ndcdyn.interactivebrokers.com/Universal/servlet/Registration_v2.formSampleView?formdb=4304&lang=en · retrieved 7 Sep 2026

- **Type:** published terms (regulatory disclosure)
- **Date / status:** Header "4304 | 5 March 2026"; index `last_updated_date: 2026-03-05`. Current.

**Verbatim quotes, pin-cited:**

> "Interactive Brokers LLC and Interactive Brokers Corp (collectively 'IBKR' or 'we' or 'us') do not recommend securities transactions or investment strategies involving securities (including account type recommendations) to its customers and, accordingly, Reg BI does not apply to IBKR. However, should any information or service offered by IBKR (including any customer communications or **tools or features of the IBKR trading systems**) be construed as a recommendation to a retail customer, these disclosures describe (1) the scope and terms of our relationship with retail customers and (2) conflicts of interest associated with information or services provided by the Firm."

§3 "Type and Scope of the Services to be Provided":
> "IB LLC is an online broker that provides **self-directed** trade execution and clearing services."
>
> "**We do not have discretionary trading authority over customer accounts** (although IB LLC Global Outsourced Trading Desk clients may submit unsolicited orders that are not held to time or price)."

**What it establishes:** IBKR characterises its retail relationship as self-directed execution without discretionary trading authority, and expressly contemplates that "tools or features of the IBKR trading systems" *might* be construed as a recommendation — hedging rather than asserting the negative.

**Q1 / Q2 / Q3:** Q3 SUPPORT (mild); Q1 NEUTRAL-to-ADVERSE on the hedge.

**Level 2** — a broker's self-characterisation in its own disclosure; persuasive of market practice, not of law.

**Application note:** Supports that an order arriving under a retail client's own credentials sits in a "self-directed" relationship in which no one holds discretionary trading authority — which is the configuration's own claim in V1. The hedging clause is a reminder, from the broker itself, that a *tool or feature* is capable of being construed as a recommendation; that is the same risk surface as *NASD NTM 01-23* and FINRA RN 11-02 already in the register, and the configuration does not escape it by being software.

---

### A-09 · IBKR Model Marketplace — "Important Disclosures" (form 9922) and "Supplemental License Agreement Between Model Provider and Financial Professional" (form 9941, document date 27 November 2019) and "License Agreement Between Model Provider and Financial Professional" (form 9920) · https://www.interactivebrokers.com/en/accounts/forms-and-disclosures-model-marketplace.php · retrieved 7 Sep 2026

- **Type:** published terms (broker-operated marketplace through which a third party supplies signals/models that another person implements)
- **Date / status:** 9941 header "9941 | 11/27/2019". 9920 and 9922 undated on their face. All three currently linked from the live Model Marketplace agreements page.

**Verbatim quote, pin-cited — form 9922, ¶3:**

> "The Marketplace allows **eligible financial professionals** to access investment models (each, a 'Model') created by third-party asset managers and ETF issuers (each, a 'Model Provider') and allows Model Providers to showcase their Models in the Marketplace… With respect to the Marketplace, **IB acts solely as a marketplace to bring Model Providers and financial professionals (advisors and broker-dealers) together**, and any material of any kind contained in the requested Model is solely the property of the Model Provider."

**Verbatim quote, pin-cited — form 9920, §3.b:**

> "Models… **are intended for use only by a financial professional (i.e., a financial advisor or broker-dealer) as a resource in the development of a portfolio for a financial professional's clients and that the user is a financial professional.** You are solely responsible for making investment recommendations and/or decisions with respect to your clients."

**Verbatim quote, pin-cited — form 9920, §3.c:**

> "Nothing in this Agreement shall be construed as Model Provider providing, and Model Provider shall not be responsible for providing, investment advice to you or your clients. You expressly acknowledge and affirm that by licensing the Models to you, Model Provider: (i) does not purport to attempt to meet the investment objectives of any person… and the Models were created without consideration of the investment objectives, risk tolerance or financial circumstances of any person; (ii) does not express opinions as to the investment merits of any particular securities; (iii) is not undertaking to provide and does not provide any individualized or personalized advice attuned or tailored to the concerns of any person; (iv) is not acting in any fiduciary or quasi-fiduciary capacity with respect to any person…"

**Verbatim quote, pin-cited — form 9941, §2 and §4:**

> "2. …you represent and warrant that you are making such recommendation and/or decision **with no input from Model Provider** and that the Models constitute **general investment research** which you only consider in rendering such recommendations or making such decisions. It is understood that the Models are based on parameters agreed to between Model Provider and IB, are general in nature and do not and cannot take into account the specific needs or circumstances of any particular End Client or investor."
>
> "4. …**Model Provider's services will be non-discretionary and Model Provider does not exercise 'investment discretion' with respect to the assets of each End Client account within the meaning of Section 13(f) of the Securities and Exchange Act of 1934**, as amended, and shall not be responsible for filing any required reports with the Securities and Exchange Commission ('SEC')."

**Verbatim quote, pin-cited — form 9941, §11:**

> "Model Provider agrees to provide you with a description of all Models and a copy of **Model Provider's Form ADV Part 2A ('Brochure')**."

**What it establishes:** IBKR operates a facility in which a third party supplies a securities-specific model and another person implements it — the closest structural analogue to the configuration that IBKR publishes. IBKR restricts it to **advisors and broker-dealers**; §11 presumes the Model Provider **has a Form ADV Part 2A**, i.e. is a registered investment adviser. The drafting formulae IBKR uses to keep the model provider out of adviser status are "general investment research", "with no input from Model Provider", "created without consideration of the investment objectives, risk tolerance or financial circumstances of any person", "non-discretionary", "does not exercise 'investment discretion'".

**Q1 / Q2 / Q3:** Q1 **ADVERSE** (the analogue is gated to RIAs and presumes a Form ADV); Q3 **SUPPORT** on the non-discretion formulae.

**Level 2** — private contract drafting by a broker and its counterparties. Evidence of how a sophisticated regulated intermediary structures exactly this relationship; no legal force.

**Application note:** Cuts both ways and the adverse edge is sharper. **Adverse:** IBKR's own signal-provider facility is not offered to retail at all — it is offered to "eligible financial professionals (advisors and broker-dealers)", with an RIA intermediary between the signal and the account, and §11 assumes the provider is itself an RIA with a Form ADV Part 2A. The configuration puts an engine's signals in front of a retail member with no intermediary and no ADV. Nothing in the configuration distinguishes this; the answer available is only that a marketplace IBKR curates and hosts is not the same as a signal a member's own runtime consumes, and that answer is not supplied by any IBKR text. **Support:** §3.c(iii) and 9941 §2 and §4 show a regulated broker treating a securities-specific model as non-advice precisely where it is general, is created without regard to any person's circumstances, involves no input from the provider into the implementing decision, and carries no discretion. The configuration's engine sends `{rule_id, rule_version, instrument, side, fired_at, source_id, source_signature}` and nothing else — never quantity, order type, price, price band, re-peg rule, time-in-force or account — and every decision-relevant input traces to the member's own setting. It satisfies the "no input into the decision" and "non-discretionary" limbs more completely than a model portfolio does. It does **not** satisfy "general in nature" in the same way, since the signal is instrument-specific and timed — which is the same weakness *Weiss Research* and *R&W Technical Services* already expose in the register.

---

### A-10 · IBKR advisor-registration thresholds · https://www.interactivebrokers.com/en/accounts/advisor.php and https://www.interactivebrokers.com/en/accounts/non-professional-advisor.php · undated pages; retrieved 7 Sep 2026

- **Type:** published terms / broker eligibility statement
- **Date / status:** Live, HTTP 200 (245,752 and 225,188 bytes respectively). No date stamp; the advisor page carries a datapoint "as of June 2, 2026" and the non-professional page a rate "as of August 7, 2026", so both were maintained within the last month.

**Verbatim quotes, pin-cited:**

Navigation teaser for the Non-Professional Advisor account, both pages:
> "Non-Professional Advisor — **For exempt advisors serving 15 or fewer clients**"

Non-Professional Advisor page, "Account Information":
> "Investment advisers in the US must be registered either with the SEC or with the state(s) where they operate or qualify for an exemption from registration. **Only Advisors who are exempt from registration and managing accounts on behalf of non-professional clients (such as family and/or friends) are eligible to open a Non-Professional Advisor account.**"

Non-Professional Advisor page, footnote:
> "Many states have requirements that advisors register if they have paying clients. Some allow advisors to have a de minimis number of paying clients. The rules vary from state to state. For example, Nevada has informed us that it requires that Nevada-domiciled persons be licensed as Investment Advisors to engage in this program per NRS 90.330. **You must review the rules of your state and those of your clients to determine if you need to register.**"

Registered Investment Advisor page, footnote:
> "Advisers should conduct their own research and/or seek legal advice regarding their registration requirements. **Advisor registration requirements and the number of clients an advisor can have without registering vary by jurisdiction.** For example, advisers in the US must be registered with the SEC if they have more than $100 million AUM or with the state(s) where they operate for (US securities) if they have more than $25 million AUM or a certain number of clients specified by the state (typically 1 or 6), unless you fall under an exemption from registration. Similarly, advisors who hold themselves out to the public for commodities must register with the CFTC and become an NFA member unless you fall under an exemption from registration."

**What it establishes:** The threshold at which IBKR pushes a person trading other people's accounts into an advisor structure. IBKR's *account-structure* threshold is functional, not numeric: any person trading accounts belonging to others must sit in an Advisor (or Broker) structure, and the only non-registered variant — Non-Professional Advisor — is confined to advisors exempt from registration serving non-professional clients "such as family and/or friends", teased at **15 or fewer clients**. IBKR expressly disclaims the registration judgment and pushes it back to the applicant and its counsel.

**Q1 / Q2 / Q3:** Q3 **NEUTRAL-to-SUPPORT**; Q1 ADVERSE as background.

**Level 2** — broker eligibility pages, undated, and expressly not legal advice.

**Application note:** **This threshold is not engaged by the configuration as described, and the reason matters.** IBKR's advisor/broker structures exist for a person who *trades other people's accounts* — the master-account-linked-to-client-accounts topology set out on both pages. In the configuration nobody trades anybody else's account: each member's own credentials sit in that member's own local vault, each order is composed from that member's own local policy and transmitted under that member's own key after that member's own per-order act, and there is no cross-member netting, routing, venue selection or batching. There is no master account and no linked client accounts, so there is no numeric client threshold to cross. The brief asked for "the threshold at which that happens"; the honest primary-source answer is that IBKR publishes **no numeric threshold for software vendors at all** — the 15-client figure governs a different thing (eligibility for the Non-Professional Advisor *account type*), and the gate that actually applies to a software vendor is the non-numeric one at A-06. **Do not report the 15-client figure as a software-vendor threshold; it is not one.**

---

### A-11 · IBKR third-party FAQ — credentials must be entered by the client; per-order manual transmit in one case · https://www.interactivebrokers.com/docs/third-party-integrations/general-third-party-frequently-asked-questions (markdown at `…​.md`) · undated page · retrieved 7 Sep 2026

- **Type:** published technical documentation
- **Date / status:** Live, HTTP 200, 12,952 bytes as markdown. Undated.

**Verbatim quotes, pin-cited:**

> "Is it possible to run TWS or IB Gateway on a headless server?
>
> **Both TWS and IB Gateway are designed to have a user interface for the client to enter their account credentials. For that reason, headless or GUI-less operation is not supported.**"

> "For users who uses a third party software to place orders but also receives data feed from a different vendor other than IB, TWS would also generate a default warning *'You are trying to submit an order without having market data for this instrument'* on receiving orders from third party. **The checked order will not be transmitted automatically unless user click 'Transmit' button of the order in TWS.**"

> "Some TWS precautions can be bypassed by navigating to *File/Edit → Global Configuration → API → Precautions*, and check the box *'Bypass Order Precautions for API Orders'*. Once this is done, API orders placed from a third party software will not be checked by TWS precautions."

> "It is the duty of the third party program to clearly show these TWS' messages within its own user interface."

**Verbatim quote — `https://www.interactivebrokers.com/docs/tws-api/doc/tws-settings/order-precautions.md`, retrieved 7 Sep 2026:**

> "In TWS – 'Global Configuration' – 'API' – 'Precautions', you can enable the following items to stop receiving the order submission messages.
> * Enable 'Bypass Order Precautions for API orders'. …"

**What it establishes:** (1) IBKR requires the *client* to enter their own account credentials into IBKR's own UI, and does not support headless operation — i.e. the credential act is IBKR-designed to be a human act by the accountholder on a machine with a GUI. (2) IBKR imposes a manual "Transmit" click on API orders in at least one defined case (order submitted through third-party software without IB market data for the instrument). (3) That manual step is a *default* the client may switch off, not a mandate. (4) IBKR places a duty on the third-party program to surface TWS's messages in its own interface.

**Q1 / Q2 / Q3:** Q3 **SUPPORT** on the credential-entry point; **MIXED** on manual transmit.

**Level 2** — undated FAQ documentation, not contract.

**Application note:** Answers brief item 3 directly and adversely to any strong claim: **IBKR does not require human review or manual entry before API order submission as a general rule.** It requires it in one narrow default case, and publishes the switch that turns it off. So nothing in IBKR's terms *mandates* the configuration's per-order tap — but equally nothing prohibits it, and the configuration exceeds what IBKR requires. The headless answer supports the configuration's credential architecture: IBKR's own design assumption is that the accountholder types their credentials into a GUI on their own machine, which is what the local runtime does, and which a server-side vendor cannot do. The "duty of the third party program to clearly show these TWS' messages within its own user interface" is a broker-imposed display duty that the configuration's runtime-owned approval surface is well placed to discharge but which the register should note as an obligation the configuration must actually meet.

---

### A-12 · IBKR TWS API for third-party platforms; Investors' Marketplace · https://www.interactivebrokers.com/docs/tws-api/doc/third-party-api-platforms/introduction and https://www.interactivebrokers.com/docs/third-party-integrations/prospective-third-party-integrations · retrieved 7 Sep 2026

- **Type:** published technical documentation
- **Date / status:** Live, HTTP 200 (1,673 and 1,157 bytes as markdown). Undated.

**Verbatim quotes, pin-cited:**

Prospective Integrations:
> "Interactive Brokers' Web API is the primary interface used by third-party software integrations. However, **all of our programming interfaces — Web API, TWS API, and FIX — are available to third-party developers. Each API has its own onboarding process for third-party vendors**, and we invite you to consult the respective documentation for each API for more detail"

Third Party API Platforms introduction:
> "Third party software vendors make use of the TWS' programming interface (API) to integrate their platforms with Interactive Broker's. Thanks to the TWS API, well known platforms such as Ninja Trader or Multicharts can interact with the TWS to fetch market data, place orders and/or manage account and portfolio information."
>
> "A non-exhaustive list of third party platforms implementing our interface can be found in our Investor's Marketplace. **As stated in the marketplace, the vendors' list is in no way a recommendation from Interactive Brokers.** If you are interested in a given platform that is not listed, please contact the platform's vendor directly for further information."

**What it establishes:** IBKR publicly documents and tolerates an established population of third-party software vendors whose products place orders through the TWS API into customers' own accounts, naming NinjaTrader and MultiCharts, and lists them without endorsement. It states that **each API has its own onboarding process for third-party vendors** — i.e. the A-06 gate is not unique to the Web API.

**Q1 / Q2 / Q3:** Q2/Q3 **SUPPORT** as to market practice; **ADVERSE** on the onboarding sentence.

**Level 2** — documentation; and market practice is not law. Note the register's existing negative finding: no SEC enforcement action against a vendor of retail trading software on registration grounds was located, and this population is the reason that negative finding matters.

**Application note:** IBKR names, documents and supports commercial third-party platforms that place orders into retail customers' own accounts through the TWS API — the same functional position as the configuration's runtime. That is real-world support for Q2/Q3. But the sentence "Each API has its own onboarding process for third-party vendors" removes the argument that the TWS API route escapes vendor onboarding merely because its client code is GPL-licensed and freely downloadable. **The configuration should not assume the TWS API route is ungated.**

---

## Negative findings — Interactive Brokers

Each records where I looked, the endpoint, and the result. Absence is documented, not inferred.

**N-1 · The IBKR LLC Client Agreement contains no API clause, no automation clause and no human-review clause.**
Full text extracted from form 3203 (30 pages, 1,323 lines, `pdftotext -layout`). Case-insensitive searches over the extracted text: `\bAPI\b` → **0 matches** (the 3 raw "api" hits are inside other words); `application program` → 0; `programmatic` → 0; `third party software` / `third-party software` → 0; `automated trading` → 0; `auto-trad` → 0; `screen scrap` → 0; `aggregator` → 0; `power of attorney` → 2, both in unrelated contexts (¶12 Trusted Contact Person; UGMA/UTMA). "third party"/"third-party" → 8 occurrences, none in an API or order-submission context. **The agreement the customer actually signs says nothing whatever about orders placed through an API or through third-party software.** Everything IBKR says on that subject sits in unsigned documentation pages (A-05, A-06, A-11) or in a separate click-through licence (A-02).

**N-2 · IBKR LLC (US) publishes no third-party trading-authorization or limited-power-of-attorney form for a non-advisor third party.**
Endpoint: `https://www.interactivebrokers.com/en/accounts/forms-and-disclosures-client-service.php` (HTTP 200, 177,680 bytes), full rendered list extracted. The complete Client Service Forms list is: Charitable Gift Transfer (April 5, 2018); Corporate Resolution (April 9, 2014); Customer Inquiries and Complaints (March 5, 2004); Interactive Brokers Australia Pty Ltd Certified Copy Certificate (June 1, 2017); **Interactive Brokers Canada Inc. Limited Power of Attorney – Trading Authorization (Individual Accounts) (August 11, 2021)**; **Interactive Brokers Canada Inc. Limited Power of Attorney – Trading Authorization (Organizational Accounts) (August 11, 2021)**; IRA Beneficiary Designation (September 7, 2021); IRA Qualified Charitable Distribution (January 23, 2017); IRA Transfer/Rollover Form (September 28, 2022); IRA Trustee Transfer Form (March 6, 2026); Partnership Resolution (October 20, 2008); Special Position Liquidation Agreement (February 14, 2020); Summary – IB UK Complaints Handling (October 21, 2021). The only LPOA/trading-authorization instruments are **Interactive Brokers Canada** forms, which are outside US scope. Cross-checked against the full Client Agreements index (31 forms, listed in the search log): the only US discretionary-authority instrument is **form 6112, "IBLLC Discretionary Trading Authorization for Advisor Clients", last updated 12 March 2026**, whose own text opens: *"By signing this Advisor Client Agreement ('Agreement'), you are providing the advisor designated below ('Advisor') with a limited power of attorney to manage and exercise trading discretion over your Interactive Brokers LLC ('IBKR') account"* and *"In order to use this form, your Advisor must be an approved participant in Interactive Brokers' Advisor Program."* **There is no published IBKR US instrument by which a customer grants a software vendor trading authority, because IBKR's structure does not contemplate one: the vendor either has no authority (the customer authenticates) or the vendor is in the Advisor/Broker programme.** This is a genuine structural finding and it supports the configuration's V1 position that nobody is granted discretionary authority.

**N-3 · No IBKR instrument located states that orders submitted via the API are the customer's own instructions, in those terms.**
Searched: form 3203 full text; A-02 licence full text; the Web API documentation tree via its own index at `https://www.interactivebrokers.com/docs/web-api/llms.txt` (HTTP 200, 69,254 bytes); the third-party integrations tree via `https://www.interactivebrokers.com/docs/third-party-integrations/llms.txt` (HTTP 200, 9,432 bytes). The nearest instruments are Client Agreement ¶4 (credential-based attribution, A-01) and ¶2 ("any order submitted to or transaction executed by IBKR is solely Client's own decision"). Neither mentions the API. **The attribution rests on credentials, not on the submission channel** — which is itself the finding, and it is the finding that matters, because the register already records that *no located SEC letter, release or staff guidance addresses whose credentials a software vendor uses*. IBKR's terms do, and they make credentials dispositive.

**N-4 · No IBKR requirement of insurance, bonding, or a specified entity type beyond "a registered company" was located.**
Searched A-04 (all 3 pages), A-06 (full text). A-04 requires "a registered company and completed website"; neither document mentions insurance, bonding, minimum capital, or a required form of entity. Certification: A-06 requires "an established platform with other brokerage firms, or a full proof of concept with an integration using the Web API", compliance due diligence and a three-tier approval, but no third-party certification body. Indemnity: A-02 §7.1 (developer indemnifies IB); Client Agreement ¶41 (client indemnifies IBKR). **No separate vendor insurance or bonding requirement located.**

**N-5 · No IBKR market-data clause new to Track 8 was located, with one exception, flagged.**
Endpoint `https://www.interactivebrokers.com/en/accounts/forms-and-disclosures-market-data.php` was not separately mined (Track 8 covers market data). The one item flagged as bearing on third-party *display* and possibly new: the standing note on the A-02 licence page — *"the use of the TWS API as a means of disseminating information, including market data or any other licensed or copyrighted information, to third parties or non-registered IB customers is strictly prohibited without prior written approval of Interactive Brokers."* Application note: the configuration states market data is the member's own token and the company holds no data credential, so the company disseminates nothing; but a runtime that pulled data through the member's TWS API session and displayed it on a surface the *engine* framed would need this note checked. Flagged to Track 8, not resolved here.

**N-6 · IBKR publishes no FIX/CTCI third-party terms.**
Endpoint `https://www.interactivebrokers.com/docs/fix/intro.md` (HTTP 200, 768 bytes) is the entire published FIX introduction. Its operative sentence is: *"Use of FIX requires an integration process lead by our FIX Engineering team, who can be reached at fixengineering@ibkr.com."* There is no published FIX agreement, no published FIX third-party terms, and no published CTCI terms. FIX access is bilateral and negotiated. **UNVERIFIED as to content; no document exists to read.**

**N-7 · IBKR Investors' Marketplace terms are UNVERIFIED — browser route needed.**
Endpoint `https://www.interactivebrokers.com/Universal/servlet/MarketPlace.MarketPlaceServlet` redirects (302) to `https://ndcdyn.interactivebrokers.com/aces/Marketplace/InvestorsMarketplace`, HTTP 200, 8,418 bytes, which renders **only** the string "Investors' Marketplace" — a client-rendered SPA shell with no server-side content. No vendor participation agreement or marketplace terms could be read. The marketplace's own disclaimer is quoted at A-12 **only as IBKR's documentation describes it** ("As stated in the marketplace, the vendors' list is in no way a recommendation from Interactive Brokers"), not from the marketplace page itself. **A browser route is needed to read the Investors' Marketplace vendor terms.** Do not treat any marketplace clause as verified.

**N-8 · The forms index's `last_updated_date` is not always the document's own date.**
Verified discrepancy: the JSON index gives form 3073 `last_updated_date: 2021-04-01`, but the PDF's own header reads "3073 | 10/27/2021". Where the two differ this register quotes **the document's own header date** and says so. Recorded so that a later reader does not treat the index date as the instrument's date.

**N-9 · IBKR publishes no standalone "API trading risk" disclosure.**
The brief anticipated one. All **71** IBKR LLC disclosures were enumerated from the live index's own JSON backing store (`webrest/general/forms/?ids=<71 ids>&langs=en`, HTTP 200, 9,050 B) with names and `last_updated_date`. **No disclosure in the list concerns API trading, programmatic trading, algorithmic trading risk, third-party access or trading authorization**, with the single exception of form 4403 (A-07), which is about *auto-trading service providers*, not about API risk. The nearest thing to an API-trading risk disclosure is **inside the Client Agreement**, at ¶5.B (algorithmic order types) and ¶42 (System Failure and alternative trading arrangements), not in a standalone disclosure. Negative finding; endpoints in the search log at #21.


---

---

## PART B · E*TRADE (MORGAN STANLEY) — register entries

### Status of the developer programme — the brief's first question, answered

**The E*TRADE API developer programme is LIVE, OPEN to new developers, and SELF-SERVICE as of 7 September 2026. It is not closed, not retired, and not replaced by a Morgan Stanley programme.** The architecture's naming of E*TRADE as the first supported broker is **not** undermined on the vitality question.

**An access warning that must travel with this finding, because it will otherwise produce a false negative:** `https://developer.etrade.com/` returns **HTTP 403, 374 bytes** to a plain or lightly-disguised curl. The body is an Akamai edge denial — `server: AkamaiGHost`, `<TITLE>Access Denied</TITLE>`, reference `18.5ead1302.1788775602.120faf50`, `https://errors.edgesuite.net/…`. **This is a bot block, not a dead site.** It is defeated by a full browser header set (User-Agent + `Accept` + `Accept-Language` + `Sec-Fetch-*` + `sec-ch-ua*` + `Upgrade-Insecure-Requests`), which returns HTTP 200 with server-rendered AEM content; and the site renders normally in a real browser, which is how it was first confirmed here. `HEAD` is refused even with full headers, so **no `Last-Modified` is obtainable** for any page on this host. Adding a cache-buster query string re-trips the 403.

---

### B-01 · E*TRADE "Getting Started" — programme status and the two-tier key system · https://developer.etrade.com/getting-started · **no date stamp on the page** · retrieved 7 September 2026

- **Type:** published terms / broker-imposed developer requirement
- **Date / status:** Live, HTTP 200, 8,787 B server-rendered. **The page carries no printed date**: the footer template renders the literal unpopulated token `© currentYear E*TRADE from Morgan Stanley`. Dating is therefore indirect, from CDN asset stamps embedded in the page's own HTML in `YYMMDDHHMMS` form — `cdn2.etrade.net/1/26081920310.0/…/scripts.js` = **19 Aug 2026 20:31** and `/1/26011420430.0/` = 14 Jan 2026. Actively maintained. Wayback snapshot `20250726011457` (26 Jul 2025) is byte-identical apart from a server-instance footer token, so the onboarding flow itself is not new.

**Verbatim quotes, pin-cited:**

> "The E*TRADE Developer Platform enables E*TRADE customers and developers to create their own investment applications that leverage E*TRADE's extensive market data offerings, order-routing capabilities, and other services.
>
> **The platform's API also allows E*TRADE customers who currently use a third-party trading platform to view E*TRADE account and market information and place trade orders directly to E*TRADE from that platform.**"

On authorisation:
> "The E*TRADE REST API uses the OAuth protocol to authorize every service request. In practice, this means that **your application must enable users to log in to their E*TRADE account and click a consent button to grant access for each session.**"

On the two key tiers — **the threshold**:
> "We support two levels of consumer key. **An individual key is tied to a single user ID, and allows access for only that user. This is appropriate for developing applications for personal use. A vendor key, on the other hand, permits access by multiple users and is appropriate for applications that may be widely distributed.**"
>
> "Note that if you are assigned an individual key, rather than a vendor key, it will only work with your E*TRADE account. Attempting to use an individual key with a different user account will result in an error. Your Individual Key will work with any of your E*TRADE accounts."

On admission:
> "To request a key, you must have an E*TRADE account. (You will also need the account so that you can log in and use your application.) **It can be a personal, professional, or corporate account.** If you don't have one, you can quickly set one up online at https://www.etrade.com."
>
> "To request either an Individual or Vendor LIVE API key, please navigate to the bottom of this page and complete your API Developer Agreement and User Intent Survey. **Individual Keys will be provided immediately in page upon satisfying these requirements.**
>
> **Vendor keys will be provided immediately in page, but will be Inactive. E*TRADE will reach out to you via email to schedule your short online Vendor demo with Product and Legal teams. Upon approval of your access based on your demo, your key will be made active.**"
>
> "If you already have your Live Keys, you do not need to complete any of the below processes. **These are for new customers seeking to gain keys through our self-service process.**"

On the four standing obligations:
> "**User Intent Survey** — As a developer, you must disclose to us your intentions with your API access by completing our API User Intent Survey located here."
> "**API Agreement** — As a developer, you are asked to sign an API agreement before you will be issued a consumer key for production data."
> "**Market Data Agreement** — As a user, you must sign the Market Data Agreement before you can access data with the quote API. Additionally, you must sign the Extended Hours Trading Agreement before you can perform after-hours trading (if the application supports this feature)."
> "**Market Data Attestation** — As a developer, you must return to this page Annually after completing our Developer Agreement in order to attest to your Market Data Attestation."

**What it establishes:** The programme is open and self-service. E*TRADE **expressly contemplates the exact fact pattern in issue** — a customer using a third-party trading platform to place orders directly to E*TRADE from that platform. Authorisation is per-session OAuth consent by the user personally. Developer admission is two-tier: an **Individual key** (own account only, issued immediately, "for personal use") and a **Vendor key** (multiple users, issued inactive, activated only after a demo to E*TRADE's **Product and Legal teams**). Entry requires only an E*TRADE account of any kind — no entity requirement, no securities registration requirement stated here.

**Q1 / Q2 / Q3:** Q3 **SUPPORT** (strong); Q2 SUPPORT.

**Level 3** — the broker's own current published statement, directly on the fact pattern. Undated on its face, which weakens it; corroborated by asset stamps and a 2025 Wayback snapshot.

**Application note:** The sentence *"allows E*TRADE customers who currently use a third-party trading platform to… place trade orders directly to E*TRADE from that platform"* is the closest thing found in either broker's materials to an express blessing of the configuration's shape. Per-session OAuth consent by the member matches the configuration's design (credentials only in the member's local runtime; the member authenticates himself). **The key tier is the operative fork and it is decided by facts the configuration has already fixed:** a runtime distributed to many members is a **Vendor** case ("permits access by multiple users… applications that may be widely distributed"), not an Individual one, notwithstanding that each member's key is tied to that member's own account. Vendor keys are issued **inactive** and require a live demo to Product **and Legal**. So E*TRADE's gate is materially lighter than IBKR's (no registered-company requirement, no enhanced due diligence, no registration expectation, days rather than 8-14 weeks) — **but it is a gate, and Legal sits on it.**

---

### B-02 · E*TRADE **API Developer License Agreement** — §1.19, §4.8, §4.9 · https://developer.etrade.com/support/terms-of-use · **no effective date on its face** · retrieved 7 September 2026 · **[Copy A]**

- **Type:** published terms (developer agreement), publicly readable without login
- **Date / status:** Live, HTTP 200, 19,464 B, **7,004 words**. Titled "API DEVELOPER LICENSE AGREEMENT". **No effective date**; it self-dates to "the date of your online acknowledgment". **No form number.**
- ⚠ **TWO MATERIALLY DIFFERENT VERSIONS OF THIS AGREEMENT ARE LIVE SIMULTANEOUSLY — see B-03.**
- ⚠ **THIS TEXT IS NEW. It was added between 9 May 2026 and 7 September 2026 — within the last four months.** Independently verified: Wayback CDX for this URL returns **21 snapshots**, 25 Aug 2019 to 9 May 2026. The two most recent (`20260509223240`, 9 May 2026 22:32:40 UTC, and `20260217111131`) were fetched with the `id_` raw modifier (HTTP 200, 37,715 / 37,710 B) and **both host a different, shorter document — the "E*TRADE API Non-Commercial License", 2,459 words — in which "Automated Order Generation" = 0, "No Exercise of Discretion" = 0 and "Power of Attorney" = 0.** The live page today is 7,004 words with those counts at 3 / 1 / 1. Wayback has no capture after 9 May 2026, so the change cannot be dated more precisely than **after 2026-05-09 22:32:40 UTC and on or before 2026-09-07**.

**Verbatim quote, pin-cited — §4.9 (complete). This is the single most important clause in the whole track:**

> "**4.9  Prohibition on Algorithmic or Automated Order Generation.** Developer shall not implement, use, permit the use of, or design the Application or any related functionality to engage in Algorithmic or Automated Order Generation in connection with the API. **Each order submitted through the API must be based on a discrete, contemporaneous, and specific instruction provided by the applicable End User (or, in the case of an Individual Use Developer, by the Developer with respect to the Developer's own account) for that particular order.** Any order submitted in violation of this Section shall be deemed unauthorized and may result in immediate suspension of API access and termination of this Agreement."

**Verbatim quote, pin-cited — §1.19 (complete), the definition §4.9 turns on:**

> "1.19  'Algorithmic' or 'Automated Order Generation' means any logic, code, feature, rule set, model, **signal, trigger**, process, workflow, or functionality—whether deterministic, rules‑based, or otherwise—that directly or indirectly generates, initiates, routes, submits, modifies, cancels, or manages an order through the API **without a discrete, contemporaneous, and affirmative instruction for that specific order provided by the End User** (or, in the case of an Individual Use Developer, by the Developer with respect to the Developer's own account)."

**Verbatim quote, pin-cited — §4.8 (complete):**

> "**4.8  No Exercise of Discretion.** The Developer shall not create, initiate, or route any order on behalf of a third-party through the API unless the Developer has received **explicit, contemporaneous instructions from the third-party** authorizing such action. In the absence of such instructions, the Developer must possess a valid and enforceable **Power of Attorney ('POA')** from the third-party that specifically authorizes order placement and routing. Any order submitted without such authorization shall be deemed unauthorized and may result in immediate suspension of API access, termination of this Agreement, and potential legal liability."

**Verbatim quote, pin-cited — §1.7 (complete), the developer taxonomy:**

> "1.7  'Developer' collectively means an individual or a legal entity exercising rights under this Agreement. Developer is further sub-categorized as an Individual Use Developer or a Vendor Use Developer. An **'Individual Use Developer' means a Developer exercising the rights under this Agreement for their own personal use and is tied to a single Developer ID.** A **'Vendor Use Developer' means a Developer exercising the rights under this Agreement for multiple users and for Applications that may be more widely distributed.**"

**Verbatim quote, pin-cited — §1.15 and §1.2:**

> "1.15  'End User(s)' means customers of the Company who obtain a license through a Vendor Use Developer to use the Developer Application."
> "1.2  'Application' means the proprietary software application developed by Developer for their own personal use (Individual Use Developer) or to make available to customers of the Company (Vendor Use Developer)."

**Verbatim quote, pin-cited — §2.3 (restrictions) and §3.1 (market data), extracts:**

> "2.3  Restrictions on Developer Use. Developer will not use the API Code for any purpose that violates any law or regulation, any underlying Market Data Agreement, any right of any person… Further, **Developer will not publish, disseminate, or redistribute the API Code to any Third Party.** Developer will not assign, transfer, grant access or use of, disclose or otherwise provide, in any form whatsoever, any content of the API to any third party or **display data electronically, unless agreed by the Company.**"
>
> "3.1 … DEVELOPER ALSO ACKNOWLEDGES AND AGREES THAT **USE OF API AS A MEANS OF DISSEMINATING INFORMATION INCLUDING MARKET DATA OR ANY OTHER LICENSED OR COPYRIGHTED INFORMATION TO THIRD PARTIES IS STRICTLY PROHIBITED WITHOUT PRIOR WRITTEN APPROVAL OF THE COMPANY** AND YOU SHALL NOT ENGAGE IN SUCH PRACTICES."

**Verbatim quote, pin-cited — §2.2 (licence grant) and §7.5:**

> "2.2  Grant of License: … the Company hereby grants to Developer … the nonexclusive, nontransferable, revocable, royalty free license to install, modify, and use the API Code for any allowed purpose, including for an **Individual Use Developer's personal, non-commercial use or a Vendor Use Developer's multiple End User use case.**"
>
> "7.5 Unauthorized Use; No Company Liability — Developer acknowledges and agrees that the Company does not control, and has no responsibility for, (a) the acts or omissions of any End User, (b) any Individual Use Developer's own use or misuse of the API, or (c) any unauthorized access to, or use of, the API, the E*TRADE System, or any End User Account Log-on or Developer credentials…"

**What it establishes:** E*TRADE's current developer agreement **prohibits automated order generation outright** and defines the prohibited category expressly to include a "**signal**" or "**trigger**" that generates or submits an order. The single dividing line it draws is whether **each particular order** rests on "**a discrete, contemporaneous, and affirmative instruction for that specific order**" from the End User. Anything else "shall be deemed unauthorized". §4.8 adds that a developer routing orders for a third party needs either explicit contemporaneous instructions **or** a power of attorney. **§4.9 binds an Individual Use Developer on their own account too — no volume threshold, no de-minimis carve-out.**

**Q1 / Q2 / Q3:** Q3 **SUPPORT — the strongest single authority located in this track**, and simultaneously **ADVERSE to any standing-execution design**. Q2 SUPPORT.

**Level 3** — current, published, binding contract terms of the named broker, drafted directly onto the exact question. Not law, and its recency (see below) is a real weakness: a four-month-old clause has no interpretive history.

**Application note — this clause is the configuration's design specification, written by the broker.**
The configuration's permission ladder is: every new source starts `disabled`; one explicit logged local act enables `per-order` live use; **standing execution is a separate track, not shipped in V1**. And the approval surface: the member places the order with **one explicit tap or swipe** on a runtime-owned surface rendered in the signed runtime's own process, minting an immutable instruction record bound to the exact displayed terms, member, account, source, scope, timestamp and nonce.

Map that onto §1.19's three requirements:
- **"discrete"** — one act, one order; the instruction record is bound to that order's exact displayed terms and carries a nonce.
- **"contemporaneous"** — the tap occurs on the composed order then displayed, immediately before transmission.
- **"affirmative"** — an explicit tap or swipe, and the engine "can never fabricate the yes".
- **"for that specific order"** — the record is bound to the exact terms shown.

**On the face of §1.19 and §4.9 the V1 configuration is outside the prohibition, and it is outside it because of the per-order act.** Three consequences follow and each is load-bearing:

1. **The per-order tap is not a design preference; under E*TRADE's terms it is the only thing standing between V1 and a clause that deems its orders "unauthorized".** Any dilution — batching several signals behind one confirmation, a "confirm all", a remembered consent, a timeout auto-accept — reads straight into §1.19.
2. **The V2 standing-execution track is prohibited outright by §4.9 as drafted, on E*TRADE.** Not conditioned, not subject to a threshold — prohibited, with suspension and termination as stated consequences. §4.8 offers the only alternative route and it is a **power of attorney**, which is precisely the discretionary-authority characterization the configuration exists to avoid. This is squarely adverse to the roadmap and must not be softened.
3. **§1.19's word "signal" is aimed at the engine layer.** The definition reaches "any logic, code, feature, rule set, model, signal, trigger, process, workflow, or functionality… that directly or indirectly generates, initiates, routes, submits… an order". The engine sends signals only, holds no trade credentials, and has no broker code path (provable by static check) — so it does not itself generate or submit an order through the API. But the words "**indirectly**" and "**workflow**" are broad, and the configuration's own description of the engine "**framing the workflow**" sits uncomfortably close to them. What saves it on the text is the closing qualifier — the definition only bites "**without** a discrete, contemporaneous, and affirmative instruction for that specific order" — not the separation of layers. **The separation of engine from runtime does not answer §1.19; only the per-order tap does.**

Also note **§2.3**: "Developer will not publish, disseminate, or redistribute the API Code to any Third Party" — the same redistribution problem as IBKR's A-02 §3.3, and here **without** any countervailing GPL grant. A distributed open-source runtime must not ship E*TRADE API client code. And §2.3's "**display data electronically, unless agreed by the Company**" plus §3.1's all-caps market-data dissemination bar bear on any surface that displays quotes; flagged to Track 8.

---

### B-03 · The same agreement, materially different · https://us.etrade.com/l/f/agreement-library/api-developer-licensing-agreement · form number **0923-APIDEVLA-E68693** (September 2023) · retrieved 7 September 2026 · **[Copy B]**

- **Type:** published terms (the copy in E*TRADE's customer-facing Agreement Library)
- **Date / status:** Live, HTTP 200, 19,546 B, **6,337 words**. Carries the form number **`0923-APIDEVLA-E68693`** in the raw HTML as `<div style="text-align: right;" class="disclaimer">0923-APIDEVLA-E68693</div>` — E*TRADE's form-number convention encodes **09/23 = September 2023**. No effective date otherwise.

**The finding, independently verified by section-level diff of both live documents:**

| | Copy A (`developer.etrade.com/support/terms-of-use`) | Copy B (`us.etrade.com/l/f/agreement-library/…`) |
|---|---|---|
| Word count | 7,004 | 6,337 |
| Form number | none | `0923-APIDEVLA-E68693` (Sept 2023) |
| **§1.19** Algorithmic/Automated Order Generation definition | **present** | **absent** |
| **§4.8** No Exercise of Discretion | **present** | **absent** |
| **§4.9** Prohibition on Algorithmic or Automated Order Generation | **present** | **absent** |
| **§7.5** Unauthorized Use; No Company Liability | **present** | **absent** |
| §4.5 Vendor Use Developer obligations | rewritten (hold-harmless framing) | original (End User written acknowledgment; five-year retention duty) |
| §7.2 Order Acceptance | identical | identical |

Sections present in Copy B but absent from Copy A: **none.** Occurrence counts, verified on the raw HTML as served: `"Automated Order Generation"` — Copy A **3**, Copy B **0**.

**Verbatim quote — §4.5 opening, Copy B (the text Copy A replaced):**
> "4.5  Vendor Use Developer Obligations related to End Users. For the sake of clarity this Section 4.5 applies only to Vendor Use Developers. **Prior to making the functions of an Application available to an End User, the Vendor Use Developer will obtain an acknowledgment from End User in written form containing clear language that the Company is not responsible for the functionality of an Application or for results obtained from using an Application**…"

**Verbatim quote — §4.5 opening, Copy A:**
> "4.5   Vendor Use Developer Obligations related to End Users. For the sake of clarity this Section 4.5 applies only to Vendor Use Developers.  **Developer understands and agrees that the Company is not endorsing the Developer Application and makes no representations or warranties to its performance, and agrees to hold the Company harmless from any liabilities that arise as a result of End User's use of the Developer Application** (the 'End User Ackno…"

**What it establishes:** Two materially different versions of the same-named agreement are simultaneously live on E*TRADE's own domains, and the difference is exactly the automation and discretion prohibitions. The copy reachable from the customer-facing "Account Agreements and Disclosures" footer link is the **older** one and does **not** contain §4.9.

**Q1 / Q2 / Q3:** Q3 — **INDETERMINATE, and that is the finding.**

**Level 3** for the existence of the divergence (both fetched and diffed directly); **UNVERIFIED** as to which text governs.

**Application note:** **Which version binds a developer is unresolved on the face of the documents.** Neither carries an effective date; both self-date to "the date of your online acknowledgment". Copy B's Sept-2023 form number and Copy A's Wayback-confirmed post-May-2026 appearance together *suggest* Copy A is the newer text — but that is inference from a form number and an archive gap, **not a date stamp, and it is not verified.** The agreement actually presented at signature sits behind MFA (`https://us.etrade.com/etx/ris/apisurvey/#/agreement` returns HTTP 200 but only **537 bytes**, a JS shim calling `redirectToMfaLogin()`; Wayback has **never** captured it — CDX for `us.etrade.com/etx/ris*` returns 28 rows, all 302). **Plan against Copy A (§4.9), because it is the version on the developer portal where a developer actually onboards and it is the more restrictive; do not rely on Copy B's silence.** Closing this needs either an authenticated E*TRADE session or written confirmation from E*TRADE Legal, and it is the single highest-value open item in this track.

---

### B-04 · E*TRADE Client Agreement for Self-Directed Accounts · https://us.etrade.com/l/f/agreement-library/client-agreement · **Effective May 20, 2026** · retrieved 7 September 2026

- **Type:** published terms (customer-facing brokerage account agreement)
- **Date / status:** Live, HTTP 200, 65,099 B gzip / 263,093 B decompressed. Document date stamp **"Effective May 20, 2026"**. Note: there is no longer an "E*TRADE Brokerage Customer Agreement" — `/l/f/agreement-library/customer-agreement` **302-redirects** to `/l/f/agreement-library/client-agreement`. Correction for the record: `https://us.etrade.com/l/f/legal-agreements` **does not exist** (HTTP 404, 13,632 B; Wayback CDX returns `[]`, i.e. it never existed). The correct hub is `https://us.etrade.com/l/f/agreement-library`.

**Verbatim quote, pin-cited — §9.D:**

> "You represent and warrant that (a) you will not use the Service in contravention of this Self-Directed Account Agreement, (b) **you will use the Service only for the benefit of your Self-Directed Account and not on behalf of any other person**, and (c) with the exception of a web browser and other applications specifically approved by Morgan Stanley in writing, **you will not use (or allow another person to use) any software, program, application, or other device, directly or indirectly, to access or obtain information through the Service or to automate the process of accessing or obtaining such information.**"

**Verbatim quote, pin-cited — §11.B:**

> "**If you share your Access Means or account information with anyone, we will consider their activities to have been authorized by you**, including activities by persons to whom you have intentionally or unintentionally, directly or indirectly granted authority over your Self-Directed Account(s)."
>
> "**you are responsible for all acts and omissions relating to the use of the Service, including all the orders that you or an Authorized Agent enter through the Service using the Access Means.**"

**Verbatim quote, pin-cited — §9.B and §9.A:**

> "9.B — **Any duplication by you of a pending order will be considered authorized and intended by you**, even if the execution of the order exceeds your available funds, purchasing power, or available position."
>
> "9.A — your account statements and transaction confirmations **shall conclusively be deemed accurate and that the underlying transactions are authorized by and binding on you** unless you notify Morgan Stanley otherwise…"

**What it establishes:** The customer-facing agreement attributes by **credential sharing** (§11.B) and makes the customer responsible for all orders entered using the Access Means, on the same credential-based logic as IBKR's ¶4. §9.D(c) contains a **broad anti-automation warranty with no API carve-out.** §9.D(b) restricts use of the Service to the customer's own account and "not on behalf of any other person".

**Q1 / Q2 / Q3:** Q3 **SUPPORT** on §11.B / §9.A / §9.B; Q3 **ADVERSE** on §9.D(c).

**Level 3** — current, dated, signed customer contract of the named broker.

**Application note:** §11.B is the E*TRADE analogue of IBKR ¶4 and points the same way: activity under the member's Access Means is deemed authorised by the member, and the member is responsible for all orders entered with them. That supports Q3 directly. **But §9.D(c) is a genuine and unresolved problem, and it is worse drafted than IBKR's equivalent:** it forbids using *any* software or application, directly or indirectly, to access information through the Service or to automate that access, excepting only "a web browser and other applications specifically approved by Morgan Stanley in writing". **On its face that clause forbids the very thing the API Developer License Agreement licenses.** The API agreement says only that it "supplements" the Client Agreement; **the Client Agreement never cross-references the API agreement, and grants no API carve-out.** The reconciliation available is that a developer's approved API key and countersigned API agreement constitute the "applications specifically approved by Morgan Stanley in writing" — a reading the documents permit but neither adopts. **Flag it; do not resolve it.** Note also that §9.D(c) binds the *customer*, i.e. the member, not the company — so it is the member who breaches if the reconciliation fails.

**One further point on §9.D(b) — "not on behalf of any other person":** this supports the configuration's architecture, in which each member uses the Service only for that member's own account and nobody trades anybody else's.

---

### B-05 · E*TRADE API documentation — mandatory preview→place order flow · https://apisb.etrade.com/docs/api/order/api-order-v1.html · undated · retrieved 7 September 2026

- **Type:** published technical documentation
- **Date / status:** Live, HTTP 200, 686,928 B. **Fetchable by plain curl — `apisb.etrade.com` is NOT Akamai-blocked**, unlike `developer.etrade.com`. Undated.

**Verbatim quotes, pin-cited:**

> "**Place Order** — Description: **The Place Order API is used to submit an order after it has been successfully previewed.**"
>
> "**Preview Order** — Description: The Preview Order API is used to submit an order request for preview before placing it."

`previewId` parameter of `PlaceOrderRequest`:
> "**This parameter is required and must specify the numeric preview ID from the preview and the other parameters of this request must match the parameters of the preview.**"

`Message.description`:
> "The text of the result message, indicating order status, success or failure, additional requirements that must be met before placing the order, and so on. **Applications typically display this message to the user, which may result in further user action.**"

`clientOrderId`:
> "A reference ID generated by the developer that is used to ensure that a duplicate order is not being submitted. This reference ID may be any value of 20 or less alphanumeric characters but **must be unique within the account.**"

**Verbatim quote — the standing footer disclosure on every E*TRADE API documentation page:**

> "By using E*TRADE API ('API') and accepting the terms of the **API Developer License Agreement**, you agree that API may employ security policies, procedures and systems of Third Party providers which may or may not be less stringent and secure than the policies, procedures and systems of Morgan Stanley Smith Barney LLC ('Morgan Stanley') or its affiliates… **To the extent that API or Third Party providers express opinions or make recommendations, you understand that such opinions or recommendations are expressed by the Third Party provider and are not the opinions or recommendations of Morgan Stanley or its affiliates.** Morgan Stanley is not responsible for the accuracy of market data displayed on API or made available by Third Party providers. There may be latency between the time an order (or other information) is submitted from API and the time the order is received by Morgan Stanley. The E*TRADE Customer Protection Guarantee does not apply. **Orders created and submitted through API are not vetted until they are received by Morgan Stanley.** It is possible that Morgan Stanley may reject an order placed through API."

**Verbatim quote — API Developer License Agreement §7.2 (identical in Copy A and Copy B):**

> "**7.2  E*TRADE System Order Acceptance.** There may be latency between the time an order (or other information) is submitted from API and the time the order is received by the E*TRADE System. The E*TRADE Customer Protection Guarantee does not apply. **Orders created and submitted through API are not vetted until they are received by the E*TRADE System. E*TRADE reserves the right to reject any order submitted through the API.**"

**What it establishes:** E*TRADE's order API **structurally enforces a two-step flow**: an order must be previewed, and the subsequent place call must carry the numeric `previewId` **and match the previewed parameters**. E*TRADE also contemplates that applications display result messages to the user "which may result in further user action", and provides a per-order idempotency key unique within the account. Separately, E*TRADE expressly contemplates that a **Third Party provider** may "express opinions or make recommendations" through an API application, and disclaims those as not Morgan Stanley's.

**Q1 / Q2 / Q3:** Q3 **SUPPORT** (strong, and structural rather than merely contractual); Q2 SUPPORT.

**Level 3** — the broker's own published API contract, machine-enforced.

**Application note:** This is a remarkable convergence and it should be used. The configuration's approval surface shows the **complete composed order**, the member taps once, and the transmitted instruction is **bound to the exact displayed terms**. E*TRADE's API requires precisely that shape: preview, then place with a `previewId` whose "other parameters… must match the parameters of the preview." **The broker's own protocol enforces terms-binding between what was displayed and what is transmitted** — the machine-level analogue of the configuration's immutable instruction record, and independent corroboration that a display-then-confirm architecture is the expected way to use this API. `clientOrderId` maps onto the configuration's nonce. Note the sequencing point in §7.2 / the footer: *"Orders created and submitted through API are not vetted until they are received by Morgan Stanley"* — consistent with the configuration's allocation of pre-trade risk control (Rule 15c3-5) to the broker, and confirming that nothing in the runtime performs a broker-side check.

The footer sentence about a Third Party expressing "opinions or… recommendations" is **double-edged** and must be recorded as such: it shows E*TRADE contemplating third-party recommendation content flowing through an API application (which normalises the engine layer), while using the word "recommendations" for exactly that content — which is the Q1 exposure, not a defence to it.

---

### B-06 · No successor programme; no retail Morgan Stanley developer platform · retrieved 7 September 2026

- **Type:** published pages / SEC filing
- **Date / status:** as stated below.

**Verbatim quote — `https://developer.morganstanley.com/signin`, HTTP 200, 1,660 B:**
> "**Morgan Stanley APIs are accessible to clients via invitation. Please contact your client service representative for more information about our API products and services.**"

Corroborating endpoints: `/signup` → **HTTP 403**. Public API catalogue `…/developer/apis?api-version=2022-04-01-preview` → HTTP 200, **28 bytes**, body `{"value":[],"nextLink":null}` — empty to the public. Footer date stamp "© 2022 Morgan Stanley".

**E*TRADE Advisor Services** (the RIA-custody API business) **left Morgan Stanley entirely** — sold to Axos Financial, closing **2 August 2021**, per the primary filing at `https://www.sec.gov/Archives/edgar/data/1299709/000129970921000122/pressrelease20210802closin.htm` (SEC EDGAR 8-K EX-99.1). `etradeadvisorservices.com` is now **NXDOMAIN**.

**What it establishes:** Morgan Stanley's own developer platform is institutional and **invitation-only**, not a retail successor to the E*TRADE programme, and its public catalogue is empty. The E*TRADE retail developer programme was **not** folded into it; it remains where it is, self-service, at `developer.etrade.com`. The RIA-custody arm was divested five years ago and is not part of this picture.

**Q1 / Q2 / Q3:** Q3 NEUTRAL — vitality/status finding only.

**Level 3** for the SEC filing; **Level 2** for the undated Morgan Stanley pages.

**Application note:** Corrects the premise in the brief that E*TRADE's developer programme "was folded into Morgan Stanley". The **corporate parent** changed; the **developer programme** did not migrate and is still open on its own domain. This removes what would have been a load-bearing adverse finding for the architecture.

---

## Negative findings — E*TRADE

**N-10 · The E*TRADE Client Agreement never mentions the API.**
Word-boundary grep over the full decompressed text of the Client Agreement for Self-Directed Accounts (Effective May 20, 2026; 263,093 B): `API` = **0**. Also **0** for `programmatic`, `algorithm`, `screen scraping`, `aggregator`, `trading authorization`. **There is no clause anywhere in the customer agreement deeming API-submitted orders to be the customer's own instructions.** Binding effect is only *inferable*, from §11.B (credential sharing = authorised) plus §9.A (statements conclusively deemed accurate and transactions authorised) plus §9.B (duplicated orders deemed authorised and intended). **Do not represent that an API-specific deeming clause exists — it does not.** Exactly as with IBKR (N-1, N-3), the customer-facing attribution rule is credential-based and channel-agnostic. That both brokers land in the same place, independently, is the most useful cross-broker fact in this track.

**N-11 · §14.B "Automated Systems" of the E*TRADE Client Agreement is about Morgan Stanley's own systems, not the customer's.**
It concerns Morgan Stanley's order handling, clearing and settlement. **It must not be cited as permission for customer-side automation.** Recorded because the section title invites exactly that misreading.

**N-12 · No broker-dealer or investment-adviser registration requirement in the E*TRADE API Developer License Agreement.**
Greps over the full body of both live versions: `broker-dealer` = 0, `broker dealer` = 0, `investment adviser` = 0 in the body (the single document hit is footer boilerplate describing Morgan Stanley Smith Barney itself), `registered representative` = 0, `insurance` = 0, `entity type` = 0, `screen scrap` = 0, `aggregator` = 0. **E*TRADE imposes no registration requirement on developers** — a material contrast with IBKR's A-06, which expects registration or a legal opinion. E*TRADE's control is substantive (§4.9 bans the conduct) rather than status-based (IBKR gates the person).

**N-13 · No express "human review before submission" requirement in the E*TRADE API agreement.**
Greps: `human` = 0, `review before` = 0, `manual` = 0. **§4.9 achieves a comparable effect in different words** — a "discrete, contemporaneous, and affirmative instruction for that specific order" — and the preview→place protocol enforces terms-binding mechanically (B-05). **Do not paraphrase §4.9 as "human review"; it does not say that, and the difference matters** — §4.9 is about the *provenance of the instruction*, not about a person auditing a machine's proposal.

**N-14 · The E*TRADE Copyright Policy is not a second source for the automation prohibition.**
`https://us.etrade.com/l/copyright-policy`, HTTP 200, 7,619 B, retrieved 7 Sep 2026. Verbatim: *"Unless otherwise specified, this website is for your personal and non-commercial use only and you may print, copy and download any information or portion of this website for your personal use only. You may not modify, copy, distribute, transmit, display, perform, reproduce, publish, license, frame, create derivative works from, transfer, or otherwise use in any other way for commercial or public purposes in whole or in part any information, software, products or services obtained from this website, except for the purposes expressly provided herein, without Morgan Stanley's prior written approval."* Zero hits for `robot`, `spider`, `crawler`, `scrape`, `extract`, `data mining`. **The automation prohibition therefore rests entirely on Client Agreement §9.D(c) and API agreement §4.9 — the Copyright Policy adds nothing and must not be cited as independent support.**

**N-15 · Account aggregation is absent from the E*TRADE Client Agreement.**
It lives in two separate opt-in contracts: **Total Wealth View** terms ("Effective October 2025", Yodlee) and the **Instant Verification User Agreement** ("Effective September 2023", form `0923-INSTVRF-E68685`), the latter granting Yodlee a limited power of attorney. Neither bears on a developer using the published API under the customer's own OAuth token; recorded so the aggregator question is not left open.

**N-16 · One live but orphaned stale document — flagged, legal status UNVERIFIED.**
`https://content.etrade.com/etrade/estation/pdf/customeragreement.pdf` returns HTTP 200, 425,289 B, and is the **2017** Customer Agreement. It is **unlinked from the current Agreement Library**, and it contains a trading-authorization regime and an irrevocable power of attorney **both deleted from the current agreement**. Do not cite it as current. Recorded because it is live and reachable and will otherwise be found and mistaken for governing text.
## ADVERSE REGISTER (both brokers)

| # | Authority | Threat 1-5 | Does the configuration distinguish it? |
|---|---|---|---|
| A-06 | IBKR Web API Third Party OAuth "Registration Process" — *"any organization offering a platform or medium of trading to individuals outside of the organization"*; *"we expect 3rd Parties offering automated trading solutions would hold applicable registration with financial authority… unless you are able to provide support (i.e. a legal opinion) as to why the business provided would not require registration"* | **5** | **No — not on the definitional sentence.** The configuration is an organization offering a platform to individuals outside it, so it is a "third party entity" by IBKR's own definition. The only distinctions available are (i) it is not an "automated trading solution" as A-07 defines auto-trading, since every V1 order needs the member's per-order tap, and (ii) the vendor never authenticates, so the A-05 Client Portal Gateway route may not engage this gate at all. **Neither distinction is confirmed by any IBKR text.** Aggravating fact: the sole alternative IBKR offers to registration is a legal opinion, and no counsel is currently engaged. |
| A-01 ¶4 last sentence | IBKR Client Agreement: *"Unless IBKR agrees in a writing executed by its Chief Executive Officer or General Counsel, Client will not permit any third party to access Client's account using Client's account credentials."* | **4** | **No, not on the text.** The clause does not define "third party" and does not distinguish a locally installed, member-controlled tool from a remote vendor. The configuration's answer — that the accessing person is the member, using his own tool, on his own machine, with his own keys in his own vault — is a reading the clause permits but does not adopt. A-05 and A-11 support that reading in *documentation*; documentation does not amend the signed agreement. |
| A-02 §0(b) | TWS API Non-Commercial License: *"This License is NOT for anybody who is developing software applications that they wish to: (a) sell to third party users for a fee, or (b) give to third party users to generate an indirect financial benefit (e.g., commissions)."* | **4** | **No.** The runtime is free, so §0(a) is not met. But §0(b) is not limited to commissions — "(e.g., commissions)" is illustrative. A free runtime given to members whose flat monthly membership is the company's revenue reads as an indirect financial benefit. IBKR's own instruction for that case is to seek a different licence. The member's own acceptance of the licence for his own account is fine; **the company's distribution of the runtime is the exposure.** |
| A-02 §3.3 vs A-03 | *"You agree not to publish, disseminate, or redistribute the API Code to any third party"* vs GPLv3 in the shipped distribution | **3** | **Partly, and by conflict rather than by argument.** A free, open-source runtime that ships IB client code has a colourable GPLv3 grant on the file headers and LICENSE. No IBKR instrument states which governs. Unresolved on IBKR's own materials; not resolved in the configuration's favour. |
| A-09 (9922 ¶3; 9920 §3.b; 9941 §11) | IBKR's own signal-provider facility is restricted to *"eligible financial professionals (advisors and broker-dealers)"* and §11 presumes the provider has a **Form ADV Part 2A** | **4** | **No.** IBKR's structural analogue to the configuration puts a registered adviser between the signal and the retail account and assumes the signal provider is itself registered. The configuration puts the signal in front of a retail member with no intermediary and no ADV. The only available distinction — that a broker-curated marketplace differs from a signal a member's own runtime consumes — is not supplied by any IBKR text. |
| A-04 | Third Party REST WebAPI Application: *"applicants must have a registered company and completed website"*; *"IBKR conducts an enhanced due diligence review of each application"*; *"who touches the orders"*; *"List all of Securities and/or Commodities Registrations the firm holds"* | **3** | **Partly.** A Delaware LLC satisfies "registered company"; "Compliance Officer (if any)" is optional; the fee model (flat membership, nothing per trade/volume/assets/performance) and the order path (member's own per-order tap, member's own key) are answerable on the configuration's own facts. **But the registrations line is answered "none",** and the form frames the gate around exactly the attribution question the commission exists to settle, with the broker reserving the answer. |
| A-07 Q1 sentence | *"Generally, the SEC considers firms that publish investment newsletters and that also engage in 'auto-trading' to be investment advisers."* | **3** | **Yes for V1, no for the roadmap.** V1 is not auto-trading on IBKR's own two-element definition. The sentence bites on the separate standing-execution track, which is not shipped and where the register already reserves the written-authorization question. |
| A-08 hedge | *"should any information or service offered by IBKR (including any customer communications or tools or features of the IBKR trading systems) be construed as a recommendation to a retail customer…"* | **2** | **No, and nobody escapes it.** A regulated broker with no advice business still hedges that its own *tools and features* may be construed as recommendations. Same risk surface as NASD NTM 01-23 and FINRA RN 11-02 already in the register. |
| A-12 | *"Each API has its own onboarding process for third-party vendors."* | **3** | **No.** Removes the argument that the TWS API route escapes vendor onboarding because its client code is GPL-licensed and freely downloadable. |
| **B-02 §4.9** | E*TRADE API Developer License Agreement, **Prohibition on Algorithmic or Automated Order Generation** — *"Developer shall not implement, use, permit the use of, or design the Application or any related functionality to engage in Algorithmic or Automated Order Generation in connection with the API."* Read with §1.19, which reaches any *"logic, code, feature, rule set, model, **signal**, trigger, process, workflow, or functionality"* acting *"without a discrete, contemporaneous, and affirmative instruction for that specific order"* | **5 for the roadmap · 1 for V1** | **V1: YES, distinguished — squarely, and by the per-order tap alone.** The prohibition bites only where there is no discrete, contemporaneous, affirmative per-order instruction; the configuration supplies exactly that. **V2 standing execution: NO — flatly prohibited as drafted**, with suspension and termination stated, and §4.8's only alternative is a **power of attorney**, i.e. the very discretionary characterization the design exists to avoid. Note §4.9 binds even an Individual Use Developer on their own account: **no volume threshold, no de-minimis carve-out.** Aggravating: any dilution of the per-order act — batching, "confirm all", remembered consent, timeout auto-accept — reads straight back into §1.19. |
| **B-03** | **Two materially different versions of the E*TRADE API Developer License Agreement are live simultaneously**; the customer-library copy (form `0923-APIDEVLA-E68693`, Sept 2023) **lacks** §1.19, §4.8, §4.9 and §7.5 | **3** | **No — and it cannot be, on the documents.** Neither copy carries an effective date; both self-date to "the date of your online acknowledgment". Which governs is **UNVERIFIED** and is answerable only behind MFA or from E\*TRADE Legal. Plan against the more restrictive Copy A. |
| **B-04 §9.D(c)** | E*TRADE Client Agreement (Effective 20 May 2026): *"with the exception of a web browser and other applications specifically approved by Morgan Stanley in writing, you will not use (or allow another person to use) any software, program, application, or other device, directly or indirectly, to access or obtain information through the Service or to automate the process of accessing or obtaining such information."* | **4** | **No.** Drafted with **no API carve-out**. The API agreement says only that it "supplements" the Client Agreement; the Client Agreement never cross-references it. The available reconciliation — that an approved key plus a countersigned API agreement is the "applications specifically approved… in writing" — is permitted by the texts but **adopted by neither**. Note it binds the **member**, not the company, so the member carries the breach risk. |
| **B-02 §2.3** | *"Developer will not publish, disseminate, or redistribute the API Code to any Third Party"*; and no electronic display of data *"unless agreed by the Company"* | **3** | **No.** Same redistribution problem as IBKR A-02 §3.3 but **without** any countervailing GPL grant. A distributed open-source runtime must not ship E\*TRADE API client code. |
| **B-05 footer** | E*TRADE contemplates that *"API or Third Party providers express opinions or make **recommendations**"* | **2** | **No, and it is double-edged.** It normalises third-party content flowing through an API application, while using the word "recommendations" for exactly that content — the Q1 exposure, not a defence to it. |
| **B-01** | Vendor keys are issued **inactive** and activated only after a *"short online Vendor demo with Product and Legal teams"* | **2** | **Partly.** Far lighter than IBKR's gate — no entity requirement, no due diligence, no registration expectation. **But it is a gate, and Legal sits on it**, and the criteria are unpublished (◇4). The configuration is a **Vendor** case from its second member. |

## DIRECT ANSWERS — Interactive Brokers

Answered in the terms of the sources found. No legal conclusions.

**1 · Are orders placed via the API the customer's own instructions? Is the customer responsible for orders submitted through third-party software?**
Yes as to responsibility, and the attribution runs through **credentials, not through the channel**. Client Agreement ¶4: *"Use of Client's credentials to effect any action will constitute conclusive evidence that IBKR may treat such action as authorized. Client is responsible for all transactions entered using Client's credentials."* ¶2: *"any order submitted to or transaction executed by IBKR is solely Client's own decision."* ¶9.A: *"Client is bound by its trades as executed, if execution is consistent with Client's order as entered."* **The agreement never mentions the API** (N-1); the rule is credential-based and channel-agnostic, which is why it reaches API orders at all.

**2 · Is automated or programmatic order submission permitted, restricted or prohibited?**
**Permitted, and marketed.** IBKR's API page invites users to *"Automate algorithmic trading strategies, advanced programmatic investing or trading systems"* and to *"Programmatically place orders including advanced order types and algos"*; the Web API introduction says *"Our trading API is available to all IBKR clients free of cost."* The Client Agreement contemplates client-side algorithmic order types and allocates their risk to the client (¶5.B). The restriction is not on automation as such but on **who may offer automated trading to other people**: A-06 expects a third party offering *"automated trading solutions"* to hold applicable registration or produce a legal opinion.

**3 · Is human review or "manual entry" required before submission?**
**No, not as a general rule** — and this must not be overstated. IBKR imposes a manual "Transmit" click in one narrow default case (an order arriving from third-party software for an instrument for which the user has no IB market data): *"The checked order will not be transmitted automatically unless user click 'Transmit' button of the order in TWS."* IBKR then publishes the switch that removes it: *"Bypass Order Precautions for API Orders… API orders placed from a third party software will not be checked by TWS precautions."* So the configuration's per-order tap **exceeds** what IBKR requires; it is not compelled by IBKR's terms, and no IBKR term prohibits it. The one place IBKR does insist on a human act is the credential act: *"Both TWS and IB Gateway are designed to have a user interface for the client to enter their account credentials. For that reason, headless or GUI-less operation is not supported."*

**4 · Is the third party treated as an agent of the customer?**
**No IBKR instrument says either way.** The word "agent" in the Client Agreement is used only of IBKR's own execution capacity (¶8.A: *"IBKR is authorized to execute Client orders as agent or principal"*). IBKR does not characterise a third-party application as the customer's agent, nor deny it. What IBKR does instead is **structural**: it sorts access by authentication route (A-05). A vendor that authenticates on the customer's behalf is a "third party" requiring registration and a bilateral agreement; software running on the customer's own machine after the customer's own browser login is not separately characterised at all, because on that route IBKR sees only the customer's authenticated session. **The agency question is answered by architecture in IBKR's materials, not by characterisation.**

**5 · What does IBKR require of the third-party developer?**
- **Entity:** *"applicants must have a registered company and completed website to qualify for review"* (A-04). No entity type specified; a Delaware LLC qualifies. Names of principals, officers/directors, and *"Compliance Officer (if any)"* — expressly optional.
- **Prior track record:** *"must have an established platform with other brokerage firms, or a full proof of concept with an integration using the Web API"* (A-06).
- **Review:** *"IBKR conducts an enhanced due diligence review of each application"* (A-04); *"IBKR Compliance conducts an enhanced due diligence review on all third party applicants, followed by a three tier approval process"* (A-06). Roughly 8-14 weeks on IBKR's own estimates.
- **Agreement:** *"our Legal team will generate the WebAPI agreement which we will send to you for review and signature"* (A-06) — bilateral, non-public, and therefore **UNVERIFIED in content**; see gaps.
- **Disclosure of the order path and the money:** *"How are orders routed from the end-user to IBKR (i.e., who touches the orders) and Is auto-trading supported?"*; *"who is compensated, for what are they compensated, and how/when is that compensation paid?"* (A-04).
- **Registrations:** *"List all of Securities and/or Commodities Registrations the firm holds"* (A-04).
- **Ongoing:** *"any significant changes to the offering after it has been approved (like addition of trading functionality) would require additional review and approval from our Compliance Teams"* (A-06).
- **Indemnity:** A-02 §7.1 (developer indemnifies IB, including for IP infringement in any application developed with the API Code). **No insurance or bonding requirement located** (N-4). **No certification body.**
- **Not required to be a broker-dealer** by any located text — see 7.

**6 · Trading authorization / discretion / power of attorney / third-party access / credential sharing / screen scraping / aggregators.**
- **Credential sharing:** the only express prohibition located, and it is squarely on point. Client Agreement ¶4: *"Unless IBKR agrees in a writing executed by its Chief Executive Officer or General Counsel, Client will not permit any third party to access Client's account using Client's account credentials."* IBKR's own third-party route avoids it by using OAuth tokens rather than shared credentials.
- **Trading authorization / power of attorney:** the only US instrument is **form 6112**, restricted to the Advisor Program (*"your Advisor must be an approved participant in Interactive Brokers' Advisor Program"*), granting *"a limited power of attorney to manage and exercise trading discretion over your Interactive Brokers LLC ('IBKR') account."* **IBKR publishes no US instrument by which a customer grants a software vendor trading authority** (N-2).
- **Discretion:** IBKR states *"We do not have discretionary trading authority over customer accounts"* (A-08); form 9941 §4 states a model provider *"does not exercise 'investment discretion' … within the meaning of Section 13(f)."*
- **Auto-trading:** defined by IBKR (adopting SEC text) as requiring a signed broker authorisation to accept instructions **directly from the third party** and execution **without first getting the customer's permission** (A-07).
- **Screen scraping / aggregators:** **no IBKR clause located on either term** in any document read. Searched form 3203, A-02, and both documentation trees. Negative finding, endpoints in the search log.

**7 · Must the developer be a registered broker-dealer or investment adviser? Any partner/vendor programme with such a requirement?**
**Not a broker-dealer — no located IBKR text requires it.** But A-06 states an expectation short of that and it is the governing sentence: *"we expect 3rd Parties offering automated trading solutions would hold applicable registration with financial authority in all regions they plan offer the service, unless you are able to provide support (i.e. a legal opinion) as to why the business provided would not require registration that location."* IBKR names *"auto-traders or robo-advisors"* among its third-party examples. Separately, IBKR's **Model Marketplace** — its own facility for third-party securities-specific signals — is restricted to *"eligible financial professionals (advisors and broker-dealers)"* and presumes the provider furnishes *"Model Provider's Form ADV Part 2A"* (A-09). And the account structures for trading others' accounts (Advisor, Non-Professional Advisor, Introducing Broker) all presuppose an advisor or broker status, with the only unregistered variant confined to *"exempt advisors serving 15 or fewer clients"* managing for *"non-professional clients (such as family and/or friends)"* (A-10).

**8 · Brief's specific question — the threshold at which a third-party developer is pushed into an "Investment Advisor" or "Introducing Broker" structure.**
**IBKR publishes no numeric threshold for software vendors.** The 15-client figure is real but governs a different thing: eligibility for the **Non-Professional Advisor account type**, i.e. for a *person managing other people's accounts*. IBKR's account structures turn on a topology — a master account linked to client accounts — that the configuration does not create, since each member's credentials, policy, orders and account are that member's own and there is no master account, no linked client accounts, no cross-member netting, routing, venue selection or batching. The gate that actually applies to a software vendor is the **non-numeric** one at A-06, triggered by *"offering a platform or medium of trading to individuals outside of the organization"*, with the registration expectation attaching to *"automated trading solutions."* Reporting "15 clients" as the software-vendor threshold would be wrong.

**9 · One line — does a per-order act by the member on a third-party surface, followed by transmission under the member's own key, fall inside IBKR's own terms as the member's instruction?**

> **YES — on Client Agreement ¶4: *"Use of Client's credentials to effect any action will constitute conclusive evidence that IBKR may treat such action as authorized. Client is responsible for all transactions entered using Client's credentials."*** IBKR attributes by credential, not by channel or by who wrote the software, and IBKR's own definition of the adverse category (A-07 auto-trading) requires a broker-level authorisation to take instructions from the third party and execution without the customer's prior permission — neither of which the configuration has. **Two qualifications that do not change the answer but must travel with it:** (i) the same ¶4 forbids permitting "any third party to access Client's account using Client's account credentials" absent a CEO/GC writing, and no IBKR instrument says whether a member's locally installed runtime is that third party; (ii) whether IBKR would nonetheless require the *vendor* to pass its A-06 third-party gate is a separate question from whose instruction the order is, and A-06's answer to it is adverse.

---

## BROKER TABLE

| Broker | Instrument(s) read, with dates | Clauses quoted (short form) | **Q3** | Developer-registration requirement |
|---|---|---|---|---|
| **Interactive Brokers LLC** | IBKR LLC **Client Agreement**, form 3203, **10 Jan 2025** · **TWS API Non-Commercial License**, undated, server-modified **27 Aug 2026**, §0 text unchanged since at least **2 Jul 2019** · **GPLv3** in TWS API 10.50 distribution, **26 Aug 2026** · **Third Party REST WebAPI Application**, **19 Mar 2024** · Web API **auth introduction** + **CPGW limitations** + **third-party OAuth registration**, undated, retrieved 7 Sep 2026 · **Auto Trading Service Providers disclosure**, form 4403, **1 Apr 2021** · **Reg BI disclosure**, form 4304, **5 Mar 2026** · **Model Marketplace** forms 9920/9922/9941, 9941 dated **27 Nov 2019** · advisor + non-professional-advisor pages, undated · third-party FAQ + order precautions, undated · FIX intro, undated | ¶4 credentials = conclusive evidence of authorisation, client responsible for all transactions entered with them — **but** no third-party access with client credentials absent CEO/GC writing · ¶2 order is "solely Client's own decision" · ¶9.A bound by trades as entered · ¶5.B algorithmic-order risk on client · ¶41 indemnity · Licence §0 not for software given to third parties for indirect financial benefit; §1.2 "Non-Commercial Purposes"; §3.3 no redistribution; §3.4 must keep an IB account · CPGW: **Individual Accounts**, user must log in **on the same machine**, all calls **from that machine** · OAuth 1.0a **"the only supported authentication method for Third Party Developers"**; OAuth 2.0 **not available to Individual account structures** · third party = **"any organization offering a platform or medium of trading to individuals outside of the organization"**; **"we expect 3rd Parties offering automated trading solutions would hold applicable registration… unless… a legal opinion"** · auto-trading = signed broker authorisation **+** execution "without first getting your permission" · "self-directed"; "We do not have discretionary trading authority" · Model Marketplace limited to **"advisors and broker-dealers"**, provider furnishes **Form ADV Part 2A** · headless operation unsupported; client enters own credentials | **YES** — decided by **Client Agreement ¶4**: *"Use of Client's credentials to effect any action will constitute conclusive evidence that IBKR may treat such action as authorized. Client is responsible for all transactions entered using Client's credentials."* Reinforced by form 4403, whose definition of the adverse category (auto-trading) requires a broker-level authorisation to take instructions from the third party **and** execution without the customer's prior permission — the configuration has neither. **Carries two qualifications:** ¶4's last sentence (no third-party access with client credentials absent a CEO/GC writing) is undistinguished on the text; and whether the *vendor* must pass the A-06 third-party gate is a separate and adverse question. | **YES, for a third-party vendor — heavy.** Registered company + completed website; principals, officers/directors, compliance officer (optional); fee model and who is compensated; **"who touches the orders"**; **all securities/commodities registrations held**; established platform elsewhere or full proof of concept; **enhanced due diligence + three-tier compliance approval**; bilateral WebAPI agreement drafted by IBKR Legal; re-approval for added trading functionality; **~8-14 weeks** on IBKR's own estimate. **Expectation of financial-authority registration in every region served, or a legal opinion.** **No** broker-dealer requirement located. **NO registration requirement at all** on the Client Portal Gateway route, where the member authenticates himself on his own machine (**Individual Accounts**). |
| **E*TRADE (Morgan Stanley)** | **API Developer License Agreement — TWO LIVE VERSIONS**: Copy A `developer.etrade.com/support/terms-of-use`, 7,004 words, **no date**, §§1.19/4.8/4.9/7.5 **added between 9 May 2026 and 7 Sep 2026** (Wayback-verified); Copy B `us.etrade.com/l/f/agreement-library/…`, 6,337 words, form **0923-APIDEVLA-E68693 (Sept 2023)**, those sections **absent** · **Client Agreement for Self-Directed Accounts, Effective 20 May 2026** · **Getting Started** page, no date (CDN asset stamp 19 Aug 2026) · **Order API documentation**, undated · Copyright Policy · Morgan Stanley developer sign-in; SEC 8-K EX-99.1 **2 Aug 2021** | **§4.9 Prohibition on Algorithmic or Automated Order Generation** — *"Each order submitted through the API must be based on a discrete, contemporaneous, and specific instruction provided by the applicable End User… for that particular order"*; violation "deemed unauthorized" · **§1.19** defines the prohibited category to include a **"signal, trigger"** acting **"without a discrete, contemporaneous, and affirmative instruction for that specific order"** · **§4.8 No Exercise of Discretion** — explicit contemporaneous instructions, else a **Power of Attorney** · §1.7 Individual vs **Vendor Use Developer** · §2.3 no redistribution of API Code; no electronic data display without agreement · §3.1 market-data dissemination barred · §7.2 orders "not vetted until… received" · **Client Agreement §11.B** sharing Access Means = activities "authorized by you"; responsible for **all orders** entered with the Access Means · §9.A statements conclusively deemed authorised · §9.B duplicated orders deemed authorised · **§9.D(c)** no software to automate access, **no API carve-out** · Getting Started: API **"allows E*TRADE customers who currently use a third-party trading platform to… place trade orders directly to E*TRADE from that platform"**; per-session OAuth consent; Individual vs Vendor key · Order API: **place requires `previewId`; "other parameters… must match the parameters of the preview"** | **YES — and more squarely than any other source in this track.** Decided by **API Developer License Agreement §4.9 read with §1.19**: the prohibition bites only on an order placed *without* "a discrete, contemporaneous, and affirmative instruction for that specific order provided by the End User". The configuration's one explicit per-order tap on a runtime-owned surface, minting a record bound to the exact displayed terms, **is** that instruction, and E*TRADE's own preview→place protocol mechanically enforces the same display-then-transmit binding. **Two qualifications, both material:** (i) §4.9's presence depends on which of the two live versions governs — **UNVERIFIED**; (ii) Client Agreement §9.D(c) forbids automation software with no API carve-out, an unresolved conflict with the API agreement that E*TRADE's own drafting does not settle. | **YES, but light — and status-blind.** Any E*TRADE account (personal, professional or corporate); signed **API Developer Agreement** + **API User Intent Survey**; Market Data Agreement; **annual** Market Data Attestation. **Individual key** (own account only) issued **immediately**. **Vendor key** (multiple users, wide distribution) issued **inactive**, activated only after a short online **demo to E*TRADE's Product and Legal teams**. **No entity requirement, no due-diligence review, no registration requirement, and no broker-dealer or RIA requirement** — verified by grep over both versions (N-12). E*TRADE controls the **conduct** (§4.9); IBKR controls the **person** (A-06). |

---

## CROSS-BROKER DIRECT ANSWERS

**The one-line answers the brief asked for:**

> **Interactive Brokers — YES.** Client Agreement ¶4: *"Use of Client's credentials to effect any action will constitute conclusive evidence that IBKR may treat such action as authorized. Client is responsible for all transactions entered using Client's credentials."*
>
> **E*TRADE (Morgan Stanley) — YES.** API Developer License Agreement §4.9: *"Each order submitted through the API must be based on a discrete, contemporaneous, and specific instruction provided by the applicable End User… for that particular order."* — the per-order act is the express dividing line, and the configuration is on the permitted side of it.

**What the two brokers agree on, independently — the most useful finding in this track.**
Neither customer agreement mentions the API at all (IBKR N-1: `API` = 0 in form 3203; E*TRADE N-10: `API` = 0 in the Client Agreement). **Both attribute an order by credentials rather than by channel**, and both do it in near-identical terms — IBKR ¶4 ("conclusive evidence that IBKR may treat such action as authorized… responsible for all transactions entered using Client's credentials") and E*TRADE §11.B ("we will consider their activities to have been authorized by you… responsible for all acts and omissions… including all the orders that you or an Authorized Agent enter through the Service using the Access Means"). Two unaffiliated brokers, drafting separately, landed on the same rule. **The register already records that no located SEC letter, release or staff guidance addresses whose credentials a software vendor uses. Both brokers' terms do, and they make credentials dispositive.** That is a genuine addition to the register on Q3, and it is the strongest thing this track produces.

**Where they diverge, and why it matters.**
E*TRADE regulates the **conduct** — §4.9 prohibits automated order generation by anyone, including an Individual Use Developer on their own account, with no threshold, and permits everything resting on a per-order instruction. IBKR regulates the **person** — A-06 gates who may be a third party at all, expects registration or a legal opinion, and says comparatively little about the order act itself. **A configuration built to satisfy E*TRADE's §4.9 (per-order act, terms-bound) satisfies IBKR's published concerns about the order; it does not by itself satisfy IBKR's concerns about the vendor.** Conversely IBKR's Client Portal Gateway route (Individual Accounts, member logs in on his own machine, all calls from that machine) is the one architecture in either broker's materials that avoids the vendor gate entirely, because on it no third party ever authenticates.

**On human review (brief item 3), both brokers, plainly:** **neither requires it.** IBKR requires a manual "Transmit" click in one narrow default case and publishes the switch that disables it (A-11); E*TRADE's agreement contains no `human`, `manual` or `review before` at all (N-13). What E*TRADE requires instead is that the *instruction* be discrete, contemporaneous and specific — a requirement about **provenance**, not about a person auditing a machine's proposal. The configuration's per-order tap satisfies the stricter of the two by a margin, and **on E*TRADE it is load-bearing rather than optional.**

**On agency (brief item 4):** **no instrument from either broker characterises the third-party application as the customer's agent, or denies it.** IBKR uses "agent" only of its own execution capacity (¶8.A). E*TRADE's §4.8 comes closest by implication — a developer routing orders for a third party needs either explicit contemporaneous instructions **or a power of attorney** — which frames the alternatives as *messenger* or *attorney-in-fact*, without naming the first. Both brokers answer the question **structurally**, by authentication route and by per-order provenance, rather than by characterisation. **The agency question is not answered by either broker's terms and remains open for Q3.**

**On the threshold the brief asked IBKR about:** **IBKR publishes no numeric threshold for software vendors.** The "15 or fewer clients" figure governs eligibility for the Non-Professional Advisor **account type** — a person managing others' accounts — not software distribution. **E*TRADE, by contrast, does publish a threshold, and it is binary and clean:** an **Individual key** is "tied to a single user ID, and allows access for only that user… appropriate for developing applications for personal use"; a **Vendor key** "permits access by multiple users and is appropriate for applications that may be widely distributed." **The configuration crosses into Vendor at the second member.** That is the only crisp, published, per-broker threshold located in this track, and it is E*TRADE's, not IBKR's.

---

## ◇ LIST — resting on secondary confirmation only, or unverified; flagged for primary verification

| ◇ | Item | Status and what would close it |
|---|---|---|
| ◇1 | **Which of the two live E*TRADE API Developer License Agreement versions governs.** | **UNVERIFIED — highest-value open item in this track.** Both fetched and diffed directly, so the *divergence* is Level 3 fact; which one *binds* is inference. Neither carries an effective date. The agreement presented at signature is behind MFA: `https://us.etrade.com/etx/ris/apisurvey/#/agreement` → HTTP 200 but **537 bytes**, a JS shim calling `redirectToMfaLogin()`; Wayback has never captured it (CDX for `us.etrade.com/etx/ris*` = 28 rows, **all 302**). **Closed only by an authenticated E*TRADE session or written confirmation from E*TRADE Legal.** Plan against Copy A (§4.9). |
| ◇2 | **Exact date §§4.8/4.9 went live on E*TRADE.** | Bounded to **after 2026-05-09 22:32:40 UTC and on or before 2026-09-07**, verified from Wayback `id_` snapshots. Cannot narrow: no Wayback capture after 9 May 2026 (confirmed via `archive.org/wayback/available`); `archive.today` returns 404 (never captured); `timetravel.mementoweb.org` fails DNS (curl exit 6, service defunct). |
| ◇3 | **Contents of the E*TRADE API User Intent Survey and Market Data Attestation.** | **Login-walled. A genuine blind spot.** A broker-dealer / RIA / automation-disclosure question could be asked inside the survey and would not appear in any public text. Needs an authenticated session. |
| ◇4 | **Criteria applied in E*TRADE's "Vendor demo with Product and Legal teams".** | **Unpublished.** No document exists to read. Closed only by going through it, or by asking E*TRADE. |
| ◇5 | **Content of IBKR's bilateral "WebAPI agreement" generated by IBKR Legal (A-06 step 3).** | **UNVERIFIED — not public.** This is IBKR's operative third-party contract and nothing in it can be quoted. Closed only by entering the onboarding process. |
| ◇6 | **IBKR Investors' Marketplace vendor terms.** | **UNVERIFIED — browser route needed.** `ndcdyn.interactivebrokers.com/aces/Marketplace/InvestorsMarketplace` → HTTP 200, **8,418 B**, renders only the string "Investors' Marketplace" (client-rendered SPA). The marketplace disclaimer at A-12 is quoted **as IBKR's documentation describes it**, not from the marketplace itself. |
| ◇7 | **Which licence governs the TWS API client code — the click-through Non-Commercial License §3.1/§3.3, or the GPLv3 shipped in the distribution.** | Both texts verified primary (A-02, A-03). **The conflict is real and unresolved on IBKR's own materials.** Not resolved in the configuration's favour. Closed only by IBKR confirming, or by counsel. |
| ◇8 | **IBKR contributor licence for the TWS API beta repository.** | **UNVERIFIED — no public document.** The repo is private; the licence is emailed on request (`api_software_contribute.html`, HTTP 200, 7,179 B). |
| ◇9 | **IBKR FIX / CTCI third-party terms.** | **No document exists to read.** `docs/fix/intro.md` is **768 bytes** entire; access is bilateral via `fixengineering@ibkr.com`. |
| ◇10 | **Legal status of the orphaned 2017 E*TRADE Customer Agreement PDF** at `content.etrade.com/etrade/estation/pdf/customeragreement.pdf` (HTTP 200, 425,289 B). | Live but unlinked from the current Agreement Library; contains a trading-authorization regime and irrevocable POA both deleted from the current agreement. **Do not cite as current.** |
| ◇11 | **Dates of most IBKR and E*TRADE documentation pages.** | A-05, A-06, A-11, A-12, B-01 and B-05 carry **no date stamp**. E*TRADE's footer renders the literal unpopulated token `© currentYear`. `HEAD` is refused on `developer.etrade.com` even with full browser headers, so no `Last-Modified`. Dating rests on CDN asset stamps and Wayback comparison, both recorded inline. |

---

---

## SEARCH LOG

Every query run, including the ones that failed.

### Search log — Interactive Brokers

All 7 September 2026. `UA` = browser User-Agent (`Mozilla/5.0 (Macintosh…) Chrome/128.0 Safari/537.36`); a plain curl UA was not used on IBKR because the site fingerprints it.

| # | Source / query | Endpoint | Result / access note |
|---|---|---|---|
| 1 | IBKR customer agreement, guessed legacy path | `interactivebrokers.com/download/customeragreement.pdf` | **HTTP 404**, 14,356 B error page. Dead path. |
| 2 | IBKR agreements index, guessed legacy path | `interactivebrokers.com/en/general/agreements.php` | **HTTP 404**, 14,356 B. Dead. |
| 3 | IBKR disclosures, guessed legacy path | `interactivebrokers.com/en/trading/disclosures.php` | **HTTP 404**, 14,356 B. Dead. |
| 4 | Legacy forms servlet | `interactivebrokers.com/Universal/Servlet/FormsAndAgreements` | **HTTP 404** after redirect to `ndcdyn.interactivebrokers.com`. Dead. |
| 5 | `ibkr.com` mirror of customer agreement | `ibkr.com/download/customeragreement.pdf` | **HTTP 404** (redirects to interactivebrokers.com). Dead. |
| 6 | WebSearch: `Interactive Brokers "Customer Agreement" pdf ibkr.com forms and agreements 2026` | — | Surfaced the live index path. Used only to locate the endpoint; **nothing quoted from search output.** |
| 7 | Client Agreements index | `interactivebrokers.com/en/accounts/forms-and-disclosures-client-agreements.php` | HTTP 200, 178,658 B. List is client-rendered; form ids found in a JS constant `LLC_DISCLOSURES` at line 2171. |
| 8 | Forms metadata JSON (client agreements) | `interactivebrokers.com/webrest/general/forms/?ids=<31 ids>&langs=en` | HTTP 200, 4,119 B. 31 forms with `last_updated_date`. Identified form **3203** = "Interactive Brokers LLC Client Agreement", 2025-01-10; **6112** = "IBLLC Discretionary Trading Authorization for Advisor Clients", 2026-03-12. |
| 9 | Client Agreement PDF | `ndcdyn.interactivebrokers.com/Universal/servlet/Registration_v2.formSampleView?formdb=3203&lang=en` | HTTP 200, 365,909 B, PDF 30 pp. Extracted 1,323 lines with `pdftotext -layout`. → **A-01** |
| 10 | Advisor LPOA PDF | same servlet, `formdb=6112` | HTTP 200, 368,803 B. Extracted 320 lines. → **N-2** |
| 11 | Keyword sweep over form 3203 text | local `grep -i` | `\bAPI\b` 0 · `application program` 0 · `programmatic` 0 · `third party software` 0 · `automated trading` 0 · `auto-trad` 0 · `screen scrap` 0 · `aggregator` 0 · `power of attorney` 2 (unrelated) · `third party`/`third-party` 8 (none in an order/API context). → **N-1** |
| 12 | IBKR API solutions page | `interactivebrokers.com/en/trading/ib-api.php` | HTTP 200, 203,294 B. Yielded the **"Third Party Developer"** persona panel and the "Begin Onboarding" link; and the TWS API "open source under the GPL license" line. → **A-03, A-12** |
| 13 | Third-party developer onboarding form | `interactivebrokers.com/download/WebAPI_Onboarding_Questionnaire.pdf` | HTTP 200, 134,828 B, PDF 3 pp. `pdfinfo` CreationDate **19 Mar 2024**; HTTP `last-modified: Tue, 19 Mar 2024 15:06:27 GMT`. → **A-04** |
| 14 | Third Party Integration page | `interactivebrokers.com/en/trading/third-party-integration.php` | HTTP 200, 249,539 B. Portfolio/OMS/post-trade vendor lists; surfaced the "15 or fewer clients" nav teaser. |
| 15 | Non-Professional Advisor account page | `interactivebrokers.com/en/accounts/non-professional-advisor.php` | HTTP 200, 225,188 B. → **A-10** |
| 16 | RIA account page | `interactivebrokers.com/en/accounts/advisor.php` | HTTP 200, 245,752 B. → **A-10** (registration-threshold footnote) |
| 17 | Introducing Broker account page | `interactivebrokers.com/en/accounts/broker.php` | HTTP 200, 253,429 B. Master/linked-account topology; no software-vendor threshold. |
| 18 | TWS API licence gate | `interactivebrokers.github.io/` | HTTP 200, 18,199 B, fully server-rendered. Complete licence text recovered. HTTP `last-modified: Thu, 27 Aug 2026 06:47:15 GMT`. → **A-02** |
| 19 | API contribute page | `interactivebrokers.github.io/api_software_contribute.html` | HTTP 200, 7,179 B. Beta repo is **private**; contributor licence is emailed, **not published**. Contributor agreement text UNVERIFIED (no public document). |
| 20 | TWS API distribution | `interactivebrokers.github.io/downloads/twsapi_macunix.1050.01.zip` | HTTP 200, 11,413,089 B. `IBJts/LICENSE` = **GPLv3** (35,149 B); `IBJts/NOTICE`; source headers confirm GPLv3. → **A-03** |
| 21 | Disclosures index + JSON | `…forms-and-disclosures-disclosures.php` then `webrest/general/forms/?ids=<71 ids>` | HTTP 200 (177,753 B; 9,050 B). 71 disclosures enumerated with dates. Identified **4403** "Disclosure Concerning Auto Trading Service Providers" and **4304** Reg BI. |
| 22 | Auto-trading disclosure PDF | servlet `formdb=4403` | HTTP 200, 59,424 B. Header "4403 \| 04/1/2021". → **A-07** |
| 23 | Reg BI disclosure PDF | servlet `formdb=4304` | HTTP 200, 418,882 B. Header "4304 \| 5 March 2026". → **A-08** |
| 24 | Wayback CDX, licence page | `web.archive.org/cdx/search/cdx?url=interactivebrokers.github.io&output=json&collapse=timestamp:6&limit=200&filter=statuscode:200` | HTTP 200. **127 snapshots**, earliest `20130414144710`, latest `20260830233851`. Fetched `20190702094623`, `20230109231643`, `20260830233851` (HTTP 200; 20,910 / 20,902 / 20,871 B). **§0 text byte-identical across all three.** → dates **A-02** |
| 25 | Client Service Forms index | `…forms-and-disclosures-client-service.php` | HTTP 200, 177,680 B. Full 13-item list extracted. **No US third-party trading-authorization form.** → **N-2** |
| 26 | Model Marketplace index | `…forms-and-disclosures-model-marketplace.php` | HTTP 200, 176,014 B. Form ids 9920, 9922, 9941. |
| 27 | Model marketplace agreements | servlet `formdb=9920 / 9922 / 9941` | HTTP 200 (44,058 / 31,878 / 37,974 B). 9941 header "9941 \| 11/27/2019". → **A-09** |
| 28 | Web API introduction | `interactivebrokers.com/docs/web-api/introduction` | HTTP 200, 444,885 B HTML. Docs expose a machine index — `.md` suffix returns clean markdown, `/llms.txt` returns a page index. |
| 29 | Web API docs index | `interactivebrokers.com/docs/web-api/llms.txt` | HTTP 200, 69,254 B. Enumerated the auth tree, incl. separate **first-party** and **third-party** OAuth registration pages. |
| 30 | Auth introduction | `…/docs/web-api/authentication/introduction.md` | HTTP 200, 3,042 B. Account-type matrix per auth method. → **A-05** |
| 31 | CPGW limitations | `…/authentication/cpgw/limitations-of-the-client-portal-gateway.md` | HTTP 200, 778 B. Same-machine login and same-machine call requirements. → **A-05** |
| 32 | Third-party OAuth registration | `…/authentication/oauth-1a/third-party-oauth/registration-process.md` | HTTP 200, 3,477 B. → **A-06** (most adverse document in the track) |
| 33 | First-party OAuth registration | `…/authentication/oauth-1a/first-party-oauth/registration-process.md` | HTTP 200, 1,565 B. First party = "institutions that will be trading on behalf of themselves or their institution". |
| 34 | OAuth 2.0 registration | `…/authentication/oauth-2/register.md` | HTTP 200, 1,065 B. **"OAuth 2.0 is not available to Individual account structures".** |
| 35 | OAuth 1.0a / 2.0 introductions | `…/oauth-1a/introduction.md`, `…/oauth-2/introduction.md` | HTTP 200 (926 / 910 B). "IBKR makes a distinction between first-party use of OAuth directly by clients and third-party use of OAuth by vendors of software". → **A-05** |
| 36 | Prospective third-party integrations | `…/docs/third-party-integrations/prospective-third-party-integrations.md` | HTTP 200, 1,157 B. "Each API has its own onboarding process for third-party vendors." → **A-12** |
| 37 | Third-party integrations index | `…/docs/third-party-integrations/llms.txt` | HTTP 200, 9,432 B. Enumerated named vendor integrations incl. Collective2, NinjaTrader, MultiCharts, QuantConnect, MetaTrader 5, Sierra Chart, DAS Trader, TradeStation, Bookmap, MotiveWave, Bloomberg EMSX. |
| 38 | TWS API third-party platforms | `…/docs/tws-api/doc/third-party-api-platforms/introduction.md` | HTTP 200, 1,673 B. → **A-12** |
| 39 | General third-party FAQ | `…/docs/third-party-integrations/general-third-party-frequently-asked-questions.md` | HTTP 200, 12,952 B. Headless unsupported; manual "Transmit" default; bypass switch. → **A-11** |
| 40 | Order precautions | `…/docs/tws-api/doc/tws-settings/order-precautions.md` | HTTP 200, 1,532 B. "Bypass Order Precautions for API orders". → **A-11** |
| 41 | Collective2 integration | `…/specific-third-party-connection-details/collective-2/introduction.md` | HTTP 200, 1,000 B. IBKR documents a **signal/auto-trading service** integration but publishes no terms of its own for it; links out to Collective2's "IB-Agreement" article on collective2.com. **Third-party site — not fetched, not quoted** (secondary source, outside primary-source rule). |
| 42 | FIX introduction | `interactivebrokers.com/docs/fix/intro.md` | HTTP 200, **768 B** — the entire published FIX documentation. No FIX/CTCI agreement published. → **N-6** |
| 43 | Investors' Marketplace | `interactivebrokers.com/Universal/servlet/MarketPlace.MarketPlaceServlet` → `ndcdyn.interactivebrokers.com/aces/Marketplace/InvestorsMarketplace` | HTTP 200, **8,418 B**; renders only the string "Investors' Marketplace". **Client-rendered SPA; no readable terms. Browser route needed.** → **N-7** |
| 44 | WebSearch: `"Interactive Brokers" "API Non-Commercial License" agreement text "TWS API"` | — | Used only to confirm the licence's canonical location. **Nothing quoted from search output**; full text taken from the live page at #18. |

### Search log — E*TRADE (Morgan Stanley)

All 7 September 2026. **"full headers"** = User-Agent + `Accept` + `Accept-Language` + `Sec-Fetch-Dest/Mode/Site/User` + `Upgrade-Insecure-Requests` + `sec-ch-ua`/`-mobile`/`-platform`. Endpoints on `developer.etrade.com` and `us.etrade.com` require it; `apisb.etrade.com` does not.

| # | Source / query | Endpoint | Result / access note |
|---|---|---|---|
| 45 | E*TRADE developer portal, plain curl + browser UA only | `developer.etrade.com/` | **HTTP 403, 374 B.** `server: AkamaiGHost`; body `<TITLE>Access Denied</TITLE>`, ref `18.5ead1302.1788775602.120faf50`, `errors.edgesuite.net`. **Bot block, NOT a dead site.** |
| 46 | Same, `HEAD` with full headers | `developer.etrade.com/` | **403 — HEAD is refused even with full headers.** No `Last-Modified` obtainable for this host. |
| 47 | Same, `GET` with full headers | `developer.etrade.com/` | **HTTP 200, 7,329 B**, server-rendered AEM. Title "E*TRADE \| Welcome Developers". |
| 48 | Same, **via real browser** (independent confirmation of #47) | `developer.etrade.com/home` | **HTTP 200**, rendered. Text recovered: "Welcome Developers — Build your own trading app…". Confirms the programme is live. |
| 49 | Getting Started | `developer.etrade.com/getting-started` | **HTTP 200, 8,787 B.** → **B-01**. No printed date; footer token renders literally as `© currentYear`. |
| 50 | Date corroboration from page source | CDN asset paths in #49's HTML | `cdn2.etrade.net/1/26081920310.0/…` = **19 Aug 2026 20:31**; `/1/26011420430.0/` = 14 Jan 2026. |
| 51 | Wayback, Getting Started | `web.archive.org/web/20250726011457/…/getting-started` | Byte-identical to live apart from a server-instance footer token. Onboarding flow **not** new. |
| 52 | Production API liveness | `api.etrade.com/v1/accounts/list` | **HTTP 401, 102 B**, body `<Error><message>Unauthorized request - invalid Consumer key and/or session token</message></Error>`. **Live OAuth rejection, not 404/410 — the API is operational.** Sandbox identical. |
| 53 | Release notes (adverse vitality signal) | `developer.etrade.com/support/release-notes` | HTTP 200, 6,802 B. **ONE entry, date-stamped "9/14/2018".** Recorded as the only adverse vitality signal. |
| 54 | **API Developer License Agreement, Copy A** | `developer.etrade.com/support/terms-of-use` | **HTTP 200, 19,464 B, 7,004 words.** No form number, no effective date. → **B-02** |
| 55 | **API Developer License Agreement, Copy B** | `us.etrade.com/l/f/agreement-library/api-developer-licensing-agreement` | **HTTP 200, 19,546 B, 6,337 words.** Form number `0923-APIDEVLA-E68693` present in raw HTML. → **B-03** |
| 56 | Section-level diff of #54 vs #55 | local | **In A not B: §1.19, §4.8, §4.9, §7.5. In B not A: none.** `"Automated Order Generation"`: A = **3**, B = **0**. §4.5 differs in wording. §7.2 identical. |
| 57 | Wayback CDX, Copy A URL | `web.archive.org/cdx/search/cdx?url=developer.etrade.com/support/terms-of-use&output=json&filter=statuscode:200` | **21 snapshots**, `20190825085540` → `20260509223240`. |
| 58 | Wayback raw snapshots, Copy A URL | `web.archive.org/web/20260509223240id_/…` and `…20260217111131id_/…` | HTTP 200, 37,715 / 37,710 B. **Both are a different, 2,459-word document — "E*TRADE API Non-Commercial License".** `"Automated Order Generation"` = 0, `"No Exercise of Discretion"` = 0, `"Power of Attorney"` = 0. **Dates the change to after 9 May 2026.** |
| 59 | Newest-capture check | `archive.org/wayback/available?url=developer.etrade.com/support/terms-of-use` | Confirms `20260509223240` is the newest capture. No later snapshot exists. |
| 60 | Alternative archives | `archive.today`; `timetravel.mementoweb.org` | archive.today **404** (never captured). timetravel **DNS failure, curl exit 6** — service defunct. Change cannot be dated more precisely. |
| 61 | Agreement signature flow | `us.etrade.com/etx/ris/apisurvey/` and `…/#/agreement` | **Login-gated.** Browser: 302 to `us.etrade.com/etx/pxy/login?TARGET=…`, "Log on to E*TRADE". The `#/agreement` route returns 200 but **537 B**, a JS shim calling `redirectToMfaLogin()`. **Not authenticated — entering credentials is out of bounds.** → **◇1, ◇3** |
| 62 | Wayback, signature flow | CDX `us.etrade.com/etx/ris*` | **28 rows, all 302.** Never captured. → ◇1 |
| 63 | Legal agreements hub — **corrected** | `us.etrade.com/l/f/legal-agreements` | **HTTP 404, 13,632 B.** Wayback CDX returns `[]` — **it never existed.** Correct hub is `us.etrade.com/l/f/agreement-library` (HTTP 200, 9,500 B); its `#tab_0` fragment is dead, content is one flat server-rendered list. |
| 64 | Customer agreement redirect | `us.etrade.com/l/f/agreement-library/customer-agreement` | **302** → `/l/f/agreement-library/client-agreement`. There is no longer an "E*TRADE Brokerage Customer Agreement". |
| 65 | **Client Agreement** | `us.etrade.com/l/f/agreement-library/client-agreement` | HTTP 200, 65,099 B gzip / **263,093 B** decompressed. **"Effective May 20, 2026".** → **B-04** |
| 66 | Keyword sweep over #65 | local grep | `API` (word-boundary) = **0** · `programmatic` = 0 · `algorithm` = 0 · `screen scraping` = 0 · `aggregator` = 0 · `trading authorization` = 0. → **N-10** |
| 67 | Keyword sweep over both agreement versions | local grep | `broker-dealer` 0 · `broker dealer` 0 · `investment adviser` 0 in body · `registered representative` 0 · `insurance` 0 · `entity type` 0 · `screen scrap` 0 · `aggregator` 0 · `human` 0 · `review before` 0 · `manual` 0. → **N-12, N-13** |
| 68 | Order API documentation | `apisb.etrade.com/docs/api/order/api-order-v1.html` | **HTTP 200, 686,928 B — plain curl works, this host is not Akamai-blocked.** Preview→place flow, `previewId` matching requirement. → **B-05** |
| 69 | Account API documentation (footer disclosure) | `apisb.etrade.com/docs/api/account/api-account-v1.html` | HTTP 200, 29,547 B. Standing footer disclosure naming the "API Developer License Agreement". → **B-05** |
| 70 | Authorization documentation | `apisb.etrade.com/docs/api/authorization/request_token.html` | HTTP 200, 22,539 B. OAuth request-token flow. |
| 71 | Login-gated API page (independent probe) | `us.etrade.com/etx/hw/v2/api` | HTTP 200, 15,958 B, 302 → `/etx/pxy/login?TARGET=…`. **Genuinely login-gated; not where public material lives.** |
| 72 | Copyright Policy | `us.etrade.com/l/copyright-policy` | HTTP 200, 7,619 B. Zero hits for `robot`, `spider`, `crawler`, `scrape`, `extract`, `data mining`. → **N-14** |
| 73 | Aggregation contracts | Total Wealth View terms; Instant Verification User Agreement | "Effective October 2025" (Yodlee); "Effective September 2023", form `0923-INSTVRF-E68685`, grants Yodlee a limited POA. → **N-15** |
| 74 | Morgan Stanley developer platform | `developer.morganstanley.com/signin` · `/signup` · `/developer/apis?api-version=2022-04-01-preview` | 200, 1,660 B ("accessible to clients via invitation") · **403** · 200, **28 B**, `{"value":[],"nextLink":null}`. Footer "© 2022 Morgan Stanley". → **B-06** |
| 75 | E*TRADE Advisor Services divestiture | `sec.gov/Archives/edgar/data/1299709/000129970921000122/pressrelease20210802closin.htm` | SEC EDGAR 8-K EX-99.1, closing **2 Aug 2021**, sold to Axos. `etradeadvisorservices.com` now **NXDOMAIN**. → **B-06** |
| 76 | Orphaned stale agreement | `content.etrade.com/etrade/estation/pdf/customeragreement.pdf` | HTTP 200, **425,289 B** — the **2017** Customer Agreement, unlinked from the current library. → **N-16, ◇10** |

**Method note on the browser.** Endpoints #48 and #61 were confirmed in a real browser because `developer.etrade.com` 403s naive curl. **No credentials were entered anywhere**; at the login wall the page was read and abandoned. The browser was shared with another agent working concurrently in this session, which repeatedly reclaimed the tab — a dedicated tab was created and calls were batched to work around it. This is recorded because it affected method, not results: every browser finding above was independently re-confirmed by curl with full headers (#47, #54, #55).


---

# S1b · TRACK 1b — Broker terms for third-party software: Charles Schwab (client-side gap), Fidelity, tastytrade, Alpaca

**Commission:** P8 · **Analyst track:** 1b · **Retrieval dates:** all 7 September 2026 unless stated.
**Primary questions:** Q3 (customer instruction) primarily; Q2 (broker characterization) secondarily.

**Scope note.** Schwab is narrow scope only (client-facing terms gap + Developer Program Agreement version status + the Q3 line). The Schwab Trader API Developer Program Agreement (May 2023) and the April 2026 Pricing Guide were already quoted in P7 and are **not** re-fetched or re-quoted here. E*TRADE and Interactive Brokers are out of this track.

---

## Broker table (summary — detail and pin-cites below)

| Broker | Instrument(s) read · date | Clauses quoted (short form) | **Q3 — orders via third-party software = customer's own instruction?** | Developer-registration requirement |
|---|---|---|---|---|
| **Alpaca** | Customer Agreement **V26.2026.07**; Terms & Conditions (undated, current); Risks of Automated Trading **v1.2020.02**; Conditional Orders v1.2020.02; docs.alpaca.markets Broker/Trading API + OAuth + Connect pages | Cust. Agmt §4 (self-directed; agent for *My* directions; third-party access "solely at My risk"); §5(a) (all orders unsolicited, "My own investment decisions"); §10 (no person may trade without approved trading authorization); §16(a)–(e) (PINs; POA; **§16(e)(7): "solely responsible for and have authorized any orders … originating from … My PINs"**); §33 (Automated Systems; customer-authorized third-party access indemnity); T&C "Personal and Non-Commercial Usage" (30-day notice for a User Application) | **YES** — expressly, §16(e)(7) + §5(a) | **Two-track.** Own-key Trading API use: none. OAuth / Alpaca Connect (other users' accounts): app submission + **Alpaca Compliance approval**; written approval for commercial apps. |
| **tastytrade** | Customer Agreement **20250811** (11 Aug 2025); API Terms of Service **last updated 17 May 2023** | Cust. Agmt §3 (all decisions by Customer); **§4 ("Any orders communicated to tastytrade's platform with your user login information will be considered to have been sent and authorized by you")**; §5 (solely responsible for all orders associated with your credentials); §7 (1-Click Trading — one click, no confirmation prompt); third-party Open API/PII clause (credential sharing with third-party service providers expressly contemplated); API TOS §2(2), **§2(3)(b)** (own behalf only), **§2(3)(f)** (third-party software needs prior written approval), **§2(3)(g)** + "API Hub" definition, §2(8), §2(13)(b), §3(1), §13 "Permitted Purpose" | **YES on attribution** (Cust. Agmt §4, §5) — **but** the API TOS independently restricts *which* software may be used (§2(3)(f)/(g)) | **YES — prior written approval** for any application/software not "developed and owned by you"; API Hub providers must enter a tastytrade agreement |
| **Charles Schwab** | Schwab Account Agreement **July 2026** `(0726-3HXA)`; Schwab One® Account Agreement **July 2026**; Electronic Services Agreement (standalone) **rev. 07/26**; Amendment notice **1 Jul 2026**; Developer Program Agreement **May 2023** (version status only) | **ESA §12** ("responsible for all orders entered through and under your Access Information … **deemed to have been received from you**"; aggregators and "agent, proxy or investment manager" named); **Acct Agmt §26** ("considered to have been sent and authorized by you"); **ESA §11** ("Orders May Not Be Manually Reviewed"); **ESA §14** (no software but a web browser or one "formally approved by Schwab in writing"); Acct Agmt §58 (advisor trading authority), §6 (POA) | **YES on attribution** (§12 + §26, deeming language) — **but §14 separately gates *which* software may connect** | **YES** — ESA §14's "formally approved by Schwab in writing" carve-out is satisfied through the Developer Program Agreement's registration + review (P7 §2). Client-side and developer-side terms are mutually consistent. |
| **Fidelity** | Terms of Use **Last Updated 1 Jul 2026**; FIDELITY ACCOUNT® Customer Agreement **FA-CUSTOM-0626** (Jun 2026); Fidelity Access pages; "Authorize Others to Access Your Accounts"; Account Authority form **`576564.19.0 (09/25)`** | ToU "Password Security and Notification" (customer responsible for all instructions under his credentials; Fidelity has no duty to inquire) — **but** ToU "Prohibited Uses and Termination of Access" (**"Third-Party Access Tools" prohibited absent express written approval, expressly including tools "used … to facilitate trading in a Fidelity account"**; **"…is in violation of these Terms, even if instructed to do so by an authorized user"**); Cust. Agmt "Modification and Enforcement" (password sharing = **de facto transfer of the account**, void without prior written approval); "Prohibited Uses and Actions" | **YES on attribution — but NO on permission, and largely MOOT: Fidelity has no retail trading API at all** | **N/A — no developer programme exists.** The only sanctioned third-party trading route is a **human** authorized agent (Limited/Full Authority or POA), who must be an individual, **unpaid**, and self-determines registration. |

---

# Register entries

## ALPACA

### S1b-01 · Alpaca Customer Agreement, version V26.2026.07 (July 2026) · https://s3.amazonaws.com/files.alpaca.markets/disclosures/library/AcctAppMarginAndCustAgmt.pdf · retrieved 7 Sep 2026

- **Type:** published terms (brokerage customer agreement)
- **Date / status:** version stamp `V26.2026.07` printed in the footer of every page — operative as of retrieval. Linked as the live Customer Agreement from `alpaca.markets/disclosures` and `alpaca.markets/legal`. Direct `files.alpaca.markets` host returned HTTP 403 to curl; the `s3.amazonaws.com/files.alpaca.markets/...` origin returned HTTP 200, 478,094 bytes.
- **Counterparty:** Alpaca Securities LLC, a registered broker-dealer, FINRA/SIPC member.

**Verbatim quotes, pin-cited:**

§4 (Authorization), first paragraph:

> "I understand that My Account is self-directed. Accordingly, I appoint You as My agent for the purpose of carrying out My directions to You in accordance with the terms and conditions of this Agreement and any attendant risks with respect to the purchase or sale of securities. You are authorized to open or close My Accounts, place and withdraw orders and take such other steps as are reasonable to carry out My directions. All transactions will be effected only on My order or the order of My authorized delegate, except as described in Section 10. I understand Alpaca provides trading and brokerage services through the Website, the App. and the Application Programming Interface (the "API"). I agree to receive and transmit financial information through such electronic means. My use or My grant of access to My Account to any third party to access information or place transactions in My Account is solely at My risk."

§5(a) (Customer Representations and Responsibilities — Self-directed Account):

> "I understand that My Account is self-directed, I am solely responsible for any and all orders placed in My Account and all orders entered by me or on My behalf are unsolicited and based on My own investment decisions or the investment decision of My duly authorized representative or agent. Accordingly, I agree that neither You nor any of Your employees, agents, principals or representatives:
> 1. provide investment advice in connection with this Account;
> 2. recommend any security, transaction or order;
> 3. solicit orders;
> 4. act as a market maker in any security;
> 5. make discretionary trades; and
> 6. produce or provide research"

§10 (Purchases):

> "All orders for the purchase of securities given for My Account will be authorized by Me and executed in reliance on My promise that an actual purchase is intended. It is My obligation to pay for purchases immediately or on Alpaca's demand. I understand Alpaca may, at any time, in its sole discretion and without prior notice to Me, prohibit or restrict My ability to trade securities. **I further agree not to allow any person to trade for My Account unless a trading authorization for that person has been received and approved by Alpaca.**" *(emphasis added; the emphasised sentence is verbatim)*

§13 (Assistance by Alpaca):

> "I understand that when I request assistance from Your employees in using the investment tools available on the Website, the App, or API, it will be limited to an explanation of the tool's functionality and, if requested by Me, to the entry by Your employees of variables provided by Me, and that such assistance does not constitute investment advice, an opinion with respect to the suitability of any transaction, or solicitation of any orders."

§16 (Electronic Access), (a)–(e):

> "a) I am solely responsible for keeping My Account numbers and PINs confidential. "PINs" shall mean My username and password.
> b) I agree and accept full responsibility for monitoring and safeguarding My Accounts and access to My Accounts.
> c) In the event that I wish to grant a third-party power and authority over My Account, I will complete a Limited Power of Attorney and Hold Harmless Agreement ("POA") and submit the executed POA to You. I understand and acknowledge that by executing and submitting a POA to You that I will be subject to the terms and conditions of such POA, and that the POA shall supplement the terms of this Agreement.
> d) Granting a third-party access to My Accounts does not in any way mitigate my responsibility for monitoring for loss, theft, or unauthorized access to My Accounts."

§16(e)(7), continuation paragraph — **the Q3 clause**:

> "The use and storage of any information including, without limitation, My Account numbers, PINs, portfolio information, transaction activity, account balances and any other information or orders available on My wireless, web-enabled cellular telephone or similar wireless communications device (collectively, "Mobile Device") or My personal computer is at My own risk and is My sole responsibility. **I represent that I am solely responsible for and have authorized any orders or instructions appearing in, originating from, or associated with My Account, My Account number, and PINs.**" *(emphasis added; sentence verbatim)*

§17 (Clearance of Trades):

> "Until receipt from Me of written notice to the contrary, Alpaca may accept without inquiry or investigation, (i) orders for the purchase or sale of securities and other property on margin, if I have elected to have a margin account, or otherwise, and (ii) any other instructions concerning said accounts."

§22 (Oral Authorization):

> "I agree that You shall be entitled to act upon any oral instructions given by Me so long as You reasonably believe such instruction was actually given by Me or my authorized agent."

Automated Systems paragraph (within the indemnity/limitation-of-liability section, unnumbered, immediately preceding §34):

> "I consent to the use of automated systems or service bureaus by You and Your affiliates in conjunction with My Account, including, but not limited to, automated order entry and execution, record keeping, reporting and account reconciliation and risk management systems (collectively "Automated Systems")."

Same section, customer-authorized third-party access:

> "Further, if I authorize or allow third parties to gain access to Your services, including My Accounts, I will defend and indemnify You against any Losses arising out of claims or suits by such third parties based upon or relating to such access and use. Alpaca does not warrant against loss of use or any direct, indirect or consequential damages or losses to Me caused by My assent, expressed or implied, to a third party accessing My Account or information, including access provided through any other third party systems or sites."

- **What it establishes:** Alpaca's operative retail customer agreement (i) deems every order originating from or associated with the customer's credentials to be an order the customer *authorized* and is *solely responsible* for; (ii) characterises every order in a self-directed account as *unsolicited* and based on the customer's own investment decisions; (iii) expressly contemplates the customer granting third parties access to place transactions, allocating that risk to the customer rather than prohibiting it; and (iv) in §10 separately requires an Alpaca-approved trading authorization before "any person" may trade for the account, and in §16(c) requires a Limited POA where the customer grants a third party "power and authority over" the account.
- **Q3:** **SUPPORT (strong).** §16(e)(7) is close to a deeming provision: orders originating from the member's own credentials are, as between broker and customer, the member's own authorized orders. §5(a) adds that they are *unsolicited*.
- **Q2:** **SUPPORT (moderate).** §5(a)'s "no recommendation / no solicitation / no discretionary trades" framing and §4's "self-directed" characterisation align with the configuration; but a broker's contractual allocation between itself and its customer does not determine §15(a) status of a third party, and Alpaca does not purport to.
- **Level 3.** Published operative contract of a registered broker-dealer, retrieved in full and version-stamped; it is a private contract, not law, so it evidences market practice and broker characterization rather than legal status.
- **Application note:** The configuration's runtime holds the member's own trade credentials in a local vault and transmits under them. §16(e)(7) maps onto that directly: orders "originating from … My PINs" are represented by the member to be orders the member authorized. §5(a)'s "unsolicited" characterisation matches the configuration's claim that no company-controlled input determines instrument, side or timing. **Two counter-pressures inside the same document:** §10 forbids allowing "any person to trade for My Account" absent an Alpaca-approved trading authorization, and §16(c) requires a Limited POA where a third party is given "power and authority over" the account. Whether a locally installed runtime executing the member's own per-order tap is "any person" trading for the account, or is instead the member's own instrumentality, is not addressed anywhere in the document. §4's "My grant of access to My Account to any third party to access information or **place transactions** in My Account is solely at My risk" cuts the other way — it contemplates third-party transaction placement as a risk allocation, not a prohibition, and imposes no POA condition in that sentence. The document does not reconcile these.

---

### S1b-02 · Alpaca Terms and Conditions (undated; linked as current from alpaca.markets/legal) · https://s3.amazonaws.com/files.alpaca.markets/disclosures/library/TermsAndConditions.pdf · retrieved 7 Sep 2026

- **Type:** published terms
- **Date / status:** **undated** — no version stamp or effective date anywhere in the document. Linked as the live "Alpaca Terms and Conditions" from `alpaca.markets/legal`. HTTP 200, 27,092 bytes. ◇ as to date only; text is primary and complete.

**Verbatim quotes:**

Opening paragraph — Alpaca's own status statement (**Q2**):

> "Alpaca Securities, LLC ("Alpaca Securities") and Alpaca Crypto, LLC ("Alpaca Crypto"), wholly-owned subsidiaries of AlpacaDB, Inc. (collectively "ALPACA"; "the Firm"). Alpaca Securities is a registered broker-dealer and member of FINRA and SIPC that provides online and mobile application-based discount stock brokerage services to self-directed investors."

"General" — the API is part of the defined Service:

> "The Alpaca website, Application Programming Interface ("API"), and mobile application for Android and iOS (collectively, the "Service") may include or make available certain content (the "Content")."

**"Personal and Non-Commercial Usage"** — in full:

> "Other than as set forth herein, you agree to use the Services and Content solely for your own personal and non-commercial purposes. Should you wish to use the Services and Content for any other purposes, including without limitation commercial usage, or making the Services and Content available to others through your own application (a "User Application"), you shall provide Alpaca with 30 days advance written notice prior to making such User Application available to others. Alpaca reserves the right to restrict your User Application's connectivity to the Service and Content, and may disallow any connectivity entirely, if Alpaca determines the User Application may interfere with Alpaca's Services or otherwise be detrimental to Alpaca, as may be determined in Alpaca's sole discretion."

"No Recommendations":

> "Alpaca Securities provides self-directed investors with discount brokerage services, and does not make recommendations of any kind. You are solely responsible for evaluating the merits and risks associated with the use of any Content provided through the Service before making any decisions based on such Content."

- **What it establishes:** Alpaca's default customer licence is personal and non-commercial; a customer who makes the Service available to others "through your own application" owes 30 days' advance written notice and is subject to Alpaca's discretionary disconnection. This is a **notice** obligation, not an approval gate — contrast Alpaca Connect (S1b-04) and tastytrade API TOS §2(3)(f) (S1b-06), both of which are approval gates.
- **Q3:** NEUTRAL. **Q2:** SUPPORT (weak) — Alpaca's self-description as serving "self-directed investors" and making no recommendations.
- **Level 3.**
- **Application note:** A free, open-source runtime installed locally by each member, each using their **own** credentials, does not on its face make "the Services and Content available to others" — each member's own connection is their own personal use. The clause would bite if the distributor operated a shared connection or re-served Alpaca Content. The configuration expressly holds no company-level or app-level trading credential and never mirrors or re-serves data, which is the fact that keeps it on the "personal use" side of this clause. Not free of doubt: "making the Services and Content available to others through your own application" is undefined, and distributing software that connects others to Alpaca could be read either way. The 30-day notice is cheap and unconditional; nothing in the clause requires Alpaca's consent.

---

### S1b-03 · Alpaca, "Risks of Automated Trading", v1.2020.02 · https://s3.amazonaws.com/files.alpaca.markets/disclosures/library/RisksAutoTrading.pdf · retrieved 7 Sep 2026

- **Type:** published terms (risk disclosure incorporated into the Customer Agreement by its opening paragraph — "I also agree to the terms of the Alpaca Terms and Conditions, Alpaca Use and Risk Disclosures…")
- **Date / status:** version stamp `v1.2020.02` (February 2020). Still the live document linked from `alpaca.markets/disclosures` at retrieval. HTTP 200, 27,984 bytes.

**Verbatim quotes:**

Opening:

> "There are risks unique to automated trading algorithms that you should know about. A system of continuous monitoring or alerting should be setup to let you know if there is a mechanical failure, such as connectivity issues, power loss, a computer crash, or system quirk. You should also monitor for instances where your automated trading system experiences anomalies that could result in errant, missing, or duplicated orders."

"Mechanical failures" — **the locally-installed-runtime sentence**:

> "The theory behind automated trading makes it seem simple: Set up the software, program the rules and watch it trade. In reality, however, automated trading is a sophisticated method of trading, yet not infallible. **Alpaca initially will only support algorithms that run on your own computer, thus your trading system will reside on your computer – and not a server.** What that means is that if an internet connection is lost, an order might not be sent to the market. There is also the potential for a power loss, computer crash, or some other system quirk that could stop your algorithm from running or cause an anomaly." *(emphasis added; sentence verbatim)*

"Monitoring":

> "Although it would be great to turn on the computer and leave for the day / week, automated trading systems do require monitoring or an alerting system."

"Reliance on Risk-Reducing Orders or Strategies":

> "With automated trading, substituting manual market monitoring with the placing of certain orders (e.g. 'stop-loss' orders or 'stop-limit' orders) which are intended to limit losses to certain amounts may not be effective because market conditions may make it impossible to execute such orders. At times, it is also difficult or impossible to liquidate a position without incurring substantial losses and **Alpaca's platform does not provide a readily available manual intervention process.**" *(emphasis added)*

- **What it establishes:** Alpaca's operative risk disclosure treats automated, unattended, rule-driven order generation from software **running on the customer's own computer** as an ordinary, disclosed and permitted mode of using a retail brokerage account. It nowhere requires human review or manual entry of each order; the closing sentence assumes the opposite ("does not provide a readily available manual intervention process").
- **Q3:** **SUPPORT (strong).** A retail broker's own disclosure regime that contemplates locally-resident algorithms transmitting orders with no per-order human act is the closest broker-side analogue to *CommandTRADE*'s "automatic mode" facts, and it is treated as the customer's own trading.
- **Q2:** SUPPORT (moderate) — evidences that a locally installed automated trading system operating on the customer's own account is ordinary retail conduct, not something the broker treats as intermediation.
- **Level 3.**
- **Application note:** The configuration is *more* restrictive than what this disclosure permits: it requires an explicit per-order tap on a runtime-owned approval surface, whereas Alpaca's disclosure contemplates fully unattended operation ("Set up the software, program the rules and watch it trade"). If the *un*attended case is ordinary customer trading in Alpaca's own documents, the per-order-consent case is a fortiori on the customer's side of the line — but note this is a **risk disclosure**, not a legal characterization, and Alpaca is describing the customer's own algorithm, not a third-party vendor's runtime. The document is silent on who wrote the software. **Note also the date:** v1.2020.02 says "Alpaca *initially* will only support algorithms that run on your own computer" — "initially" signals this was a launch-era statement; whether it still describes Alpaca's supported topology in 2026 is not established by the document itself, though it remains the live linked disclosure.

---

### S1b-04 · Alpaca developer documentation — Broker API / Trading API boundary, OAuth scopes, and Alpaca Connect approval · docs.alpaca.markets · retrieved 7 Sep 2026

- **Type:** published terms / published developer documentation (not a signed instrument; the "Terms of Access and Use" bullets are Alpaca's own published conditions of API access)
- **Date / status:** undated pages, live at retrieval. HTTP 200 (462–500 KB SPA documents; body extracted from the embedded page JSON, which matches the rendered `<p>` text and the `<meta name="description">` verbatim).

**Verbatim quotes:**

**"About Broker API"** (`https://docs.alpaca.markets/docs/about-broker-api`), page excerpt — **the boundary statement**:

> "This is the documentation about Broker API that helps you build trading apps and brokerage services for your end users. If you are looking to build your own trading bots and algos, read the Trading API documentation.  With Alpaca Broker API, you can build the full brokerage experiences for your end users around account opening, funding and trading. This document describes all you need to know to build your trading app."

Same page, body — Broker API use cases:

> "There are several different use cases for Broker API integration. Below are some common ones, but please do not hesitate to reach out to our sales team if you have a different case in mind. We want our platform to encourage a broad range of use cases.
>
> * Broker dealer (fully-disclosed, omnibus)
> * Registered Investment Advisor (RIA)
>
> *We support most use cases internationally.*
>
> Depending on the case, the API methods you want to use could vary. For example, the omnibus broker-dealer case never uses API to open a customer account since the trading accounts are created upfront and you will submit orders to them, and manage your end customer accounting on your end."

Docs home cards (same source HTML), the two products side by side:

> "Trading API — Stock trading for individuals and business accounts. Built for retail, algorithmic and proprietary traders."

> "Broker API — Build trading apps and brokerage services for your end users. Tailored for businesses such as trading apps, challenger banks, etc.."

**"Using OAuth2 and Trading API"** (`https://docs.alpaca.markets/docs/using-oauth2-and-trading-api`), opening:

> "By default once you have a valid client_id and client_secret, any paper account and the live account associated with the OAuth Client will be available to connect to your app. We welcome developers to build applications and products that are powered by Alpaca while also protecting the privacy and security of our users. To build using Alpaca's APIs, please follow the guide below."

Same page, "Allowed Scopes" table, verbatim:

> | Scope | Description |
> | `account:write` | Write access for account configurations and watchlists. |
> | `trading` | Place, cancel or modify orders. |
> | `data` | Access to the Data API. |

**"About Connect API"** (`https://docs.alpaca.markets/us/docs/about-connect-api`) — **Q2-relevant status statement**:

> "# Non-Registered and Fintech Partners
>
> Alpaca Connect allows non-registered firms, developers and fintech companies to build trading apps on Alpaca's platform. Using OAuth, your application can connect to Alpaca brokerage accounts . Apps ranging from algorithmic trading and charting to crypto and more are  published on the Alpaca Connect Marketplace once they are approved by Alpaca Compliance."

Same page, **"Terms of Access and Use"** in full:

> "* You must read the terms and register in order to connect and use Alpaca's APIs
> * All API clients must authenticate with OAuth 2.0
> * You may not imply that the app was developed by Alpaca.
> * If you are building a commercial application that makes money (including ads, in-app purchases, etc), you must disclose it in the registration form and receive written approval.
> * To allow live trading for other users, the app needs to be approved by Alpaca. Please create your application via the Alpaca Dashboard under the [Alpaca Connect](https://app.alpaca.markets/connect) tab. For further details, please review [Registering Your App](https://docs.alpaca.markets/update/docs/registering-your-app)
> * For any additional questions, please reach out to [Support@alpaca.markets](mailto:Support@alpaca.markets)"

Same page, FAQ — **the boundary restated by Alpaca itself**:

> "### Q: What can an OAuth app do?
>
> A: OAuth allows you to manage your end-user's Alpaca brokerage account on their behalf. This means you can create many types of financial services including automated investing, portfolio analytics and much more."

> "### Q: Should I use OAuth or Broker API?
>
> A: OAuth allows you to expand your audience to users with Alpaca brokerage accounts. On the other hand, Broker API allows you to build an application fully within your environment. Users sign up for a brokerage account under your application. If you want to create your own brokerage, automated investment app, or any app where you want to own your users, use the Broker API. If you want to build your trading service on Alpaca's platform, use OAuth."

**"Registering Your App"** (`https://docs.alpaca.markets/us/docs/registering-your-app`):

> "Before integrating with Alpaca, you'll need to create a new OAuth application from your Alpaca Connect Apps page."
> …
> "### 3. Click on Submit Your App and Fill in the Details
>
> Please complete the Alpaca Connect Application for our team to review."
> …
> "### 4. Application Review
>
> Once your application has been submitted, our team will follow up with you shortly via email to complete the remaining process."

- **What it establishes:** Alpaca publishes a **three-way**, not two-way, split, and the dividing line in its own words is *whose accounts* and *whose users*:
  1. **Trading API with the account holder's own API key** — "Stock trading for individuals and business accounts. Built for retail, algorithmic and proprietary traders"; "if you are looking to build your own trading bots and algos, read the Trading API documentation". **No registration, no review, no approval requirement is stated anywhere for this path.**
  2. **OAuth / Alpaca Connect** — a developer-held `client_id`/`client_secret` under which *other people's* Alpaca accounts are connected to the developer's app; the `trading` scope permits the app to "Place, cancel or modify orders"; Alpaca describes this as "manage your end-user's Alpaca brokerage account on their behalf". **Requires app submission and Alpaca Compliance approval to allow live trading for other users, and written approval for commercial apps.**
  3. **Broker API** — "brokerage services for your end users", account opening and funding, "any app where you want to own your users"; use cases enumerated as "Broker dealer (fully-disclosed, omnibus)" and "Registered Investment Advisor (RIA)".
- **Q2:** **SUPPORT (notable).** "Alpaca Connect allows **non-registered firms**, developers and fintech companies to build trading apps on Alpaca's platform" is a registered broker-dealer stating in its own published terms that a non-registered firm may build a trading app that places orders in customers' accounts. That is a market-practice datapoint on §15(a), and an adverse-to-the-SEC-position datapoint only in the weak sense that a broker's commercial policy is not a legal conclusion and Alpaca does not purport to opine on the developer's registration status.
- **Q3:** SUPPORT (moderate) — the OAuth consent flow is a per-user authorization the account holder grants, and the scope that permits order placement is granted by the user, not assumed by the developer.
- **Level 3** for the boundary statements (Alpaca's own published product definitions and access conditions); **Level 2** for the marketplace/approval mechanics, which are operational descriptions that could change without notice and are not a signed instrument.
- **Application note — which side does the configuration fall on, *as the terms are written*:**

  **As written, a locally installed runtime that authenticates with the member's own Alpaca API key falls on the Trading API side, not the Broker API side, and not the OAuth/Connect side.** Three features of Alpaca's own text drive that:
  - The Broker API is defined by **carrying or serving "your end users"** — account opening, funding, "own your users", omnibus/fully-disclosed broker-dealer or RIA. The configuration opens no accounts, holds no customer funds or securities, carries nobody, and each member's broker relationship is the member's own direct relationship with Alpaca. None of the Broker API's defining facts are present.
  - The OAuth/Connect path is defined by a **developer-held client credential** under which the developer's app reaches other people's accounts — "manage your end-user's Alpaca brokerage account on their behalf". The configuration expressly holds **no company-level or app-level trading credential**; credentials exist only in each member's local vault, per member. The approval gate — "To allow live trading **for other users**, the app needs to be approved by Alpaca" — is triggered by trading *for other users* under the app's own OAuth client. On the configuration's facts there is no such client and no "other users" relative to any credential the company holds.
  - The Trading API is described as "Built for retail, **algorithmic** and proprietary traders" and is the path Alpaca points to for "your own trading bots and algos" — which is what the member is running, on the member's own machine (cf. S1b-03: "algorithms that run on your own computer").

  **Two honest qualifications.** (i) Alpaca's Trading API text addresses the *account holder* building *his own* bot; it does not address a third party **distributing** the bot the account holder runs. Alpaca's documents nowhere say whether the author of locally installed software that a customer runs against the customer's own key is subject to any Alpaca requirement — that question is simply not asked or answered anywhere in the material located. The nearest thing is the Terms and Conditions "Personal and Non-Commercial Usage" clause (S1b-02), which imposes a 30-day notice on the *customer* who makes the Service available to others through "your own application", not on a vendor. (ii) If the configuration ever moved to a company-held OAuth client — e.g. to spare members from handling raw API keys — it would cross onto the Connect path and the Compliance-approval gate and the commercial-application written-approval requirement would both attach. Nothing in the configuration as held constant does that, but the boundary is one design decision away.

---

## TASTYTRADE

### S1b-05 · tastytrade Customer Agreement and Acknowledgments, document 20250811 (11 August 2025) · https://assets.tastyworks.com/production/documents/broker_customer_agreement.pdf · retrieved 7 Sep 2026

- **Type:** published terms (brokerage customer agreement)
- **Date / status:** footer of every page reads "20250811 - tastytrade Customer Agreement"; operative at retrieval. This is the URL that the API Terms of Service itself names in its definition of "Customer Agreement" (see S1b-06, §13). HTTP 200, 228,158 bytes. Introducing broker: tastytrade, Inc.; clearing firm: Apex Clearing Corporation.

**Verbatim quotes, pin-cited:**

§3 (Customer Relationship With tastytrade And The Clearing Firm), opening:

> "Customer acknowledges that all decisions relating to its investment or trading activity shall be made by Customer or its duly authorized representative. tastytrade does not provide investment advice or offer recommendations for the purchase or sale of securities, futures, options or other financial instruments."

§4 (Electronic Order Execution Requests And Communication), opening paragraph — **the Q3 clause**:

> "You agree to the following terms and conditions with respect to all electronic communications in which you communicate a request to an agent of tastytrade and any related information pertaining to such request. Requests may include instructions to execute an unsolicited order in your Account via phone or through the Firm's live support chat feature. The Firm will only accept orders via email under certain circumstances. You acknowledge that electronic or phone requests communicated to the Firm will be handled on a best efforts basis. Additionally, these terms and conditions require you to acknowledge your responsibility to protect your sensitive account information as well as your responsibility to routinely monitor your account information and activity. **Any orders communicated to tastytrade's platform with your user login information will be considered to have been sent and authorized by you.**" *(emphasis added; sentence verbatim)*

§4(a), (d), (h), (i):

> "(a)   You agree you will not transmit securities trade orders to tastytrade using electronic communications other than those designated by tastytrade for the express purpose of placing securities orders."

> "(d)   You agree that you are responsible for the monitoring of all your orders entered into tastytrade's platform or via tastytrade's electronic communication system until such order is accompanied by an official confirmation or cancellation given by tastytrade."

> "(h)   You agree to protect your sensitive account information, including, but not limited to, your password, username, other login credentials.
> (i)   You agree to not give your account login credentials or make them easily accessible to a minor."

§5 (Electronic Trading), opening:

> "You acknowledge that you bear all risk associated with your orders, regardless if they are placed through tastytrade's platform, through a tastytrade's representative or otherwise. You acknowledge that you are solely responsible for all orders (whether successfully entered or attempted to be entered) that are associated with your unique customer identifiers, including, but not limited to, your Account number, customer identification number, or your unique user login credentials."

§7 (1-Click Trading) — **the one-tap clause**:

> "You understand and acknowledge that "1-click trading" is an optional feature available to you on the tastytrade platform that, should you choose to use it at your sole discretion, allows you to submit an order after one (1), single mouse click and without the use or display of an in-platform order confirmation. All orders submitted using the 1-click trading feature will automatically be routed for execution without any platform prompts or messaging to review or confirm the order before it is sent to the market for execution. You further understand and acknowledge that any order entered by accident or in error as a result of your use of 1-click trading may be executed before you are able to cancel the order. Under the terms of this Agreement, you are responsible for, and bear all the risks of, any order entered in your Account."

Unnumbered clause in the disclaimer section (immediately following the market-data disclaimer, p.9) — **credential sharing with third-party API providers, expressly contemplated**:

> "You acknowledge that tastytrade allows third party service providers to connect to the Firm's Open API. You are advised that if you give your tastytrade username and password to a third party service provider that connects to the Firm's Open API, it is possible that the third party service provider will be able to access your personal information ("PII") that was given to tastytrade. If you are concerned about the access of your PII, you acknowledge and agree that it is your responsibility to contact the third party service provider in question to ask them what information they are accessing and review such third party service provider's privacy policy as tastytrade is not responsible for the privacy policies and practices of any third party who provides services to you directly."

- **What it establishes:** (i) tastytrade's customer agreement contains an express attribution rule — any order carrying the customer's login information "will be considered to have been sent and authorized by you"; (ii) the customer bears sole responsibility for all orders associated with his credentials "regardless" of the channel; (iii) tastytrade **expressly acknowledges that it allows third-party service providers to connect to its Open API and expressly contemplates the customer giving that third party his username and password**, warning only about PII exposure — it does not prohibit the practice; (iv) tastytrade offers a native one-click order-submission feature with **no** confirmation prompt, so nothing in the customer agreement requires human review of a composed order beyond the single click.
- **Q3:** **SUPPORT (strong).** §4's attribution sentence is the most explicit "credential = customer's own instruction" language located in this track. The third-party Open API/PII clause is the only located instance of a broker affirmatively acknowledging customer credential sharing with third-party software.
- **Q2:** SUPPORT (weak-moderate) — §3 places all trading decisions with the customer; the Open API clause treats the third-party service provider as someone "who provides services to you directly", i.e. the customer's own counterparty, not tastytrade's.
- **Level 3.**
- **Application note:** §4's attribution sentence maps onto the configuration exactly: the runtime transmits under the member's own credentials, so the order is "considered to have been sent and authorized by" the member as against tastytrade. §7 is a useful calibration point for the approval surface — tastytrade itself treats **one click with no confirmation screen** as a sufficient customer act to own the order, whereas the configuration displays the complete composed order and takes an explicit tap on it, which is strictly more than tastytrade's own minimum. The Open API/PII clause is directly on the credential question that P7 recorded as unaddressed by any SEC source: tastytrade's answer, as a matter of its own contract, is that the customer may hand credentials to a third-party service provider and bears the consequences. **Counter-pressure:** this clause is a *privacy* warning, and it does not license the third party — the licence question is governed by the API Terms of Service, which imposes an approval gate (S1b-06). The customer agreement and the API TOS point in different directions and the API TOS expressly prevails over the Customer Agreement in a conflict (S1b-06 §1).

---

### S1b-06 · tastytrade API Terms of Service, last updated 17 May 2023 · https://assets.tastyworks.com/production/documents/USA/open_api_terms_and_conditions.pdf · retrieved 7 Sep 2026

- **Type:** published terms (developer/API agreement between tastytrade and its own customer)
- **Date / status:** first page: "API TERMS OF SERVICE / Last updated: May 17, 2023". Linked from the footer of `developer.tastytrade.com` as "API Terms of Service" ("By using tastytrade's API, you agree to our API Terms of Service"). HTTP 200, 209,039 bytes.

**Verbatim quotes, pin-cited:**

Preamble:

> "This Agreement is between you, the client, and us, tastytrade, Inc., with offices at 1330 W Fulton Market, Suite 600, Chicago, IL, 60607. … By accessing or using our APIs and other developer services (collectively, "APIs"), you are agreeing to these terms of service."

§1 (Introduction) — **the API TOS prevails over the Customer Agreement**:

> "You have an account with us that allows you to enter into Transactions which are subject to the Customer Agreement. The Customer Agreement sets out (a) the basis upon which we will enter into Transactions with you and the terms attached to each Transaction that we enter into with you, including any Transactions concluded via the API Connection; and (b) the basis upon which we will provide you with Data. You agree and acknowledge that the Customer Agreement will apply to the arrangements set out in this Agreement to the extent that they are relevant. **In the event of any conflict between the terms of this Agreement and the terms of the Customer Agreement, the terms of this Agreement will prevail.**" *(emphasis added)*

§2 (Licence), grant:

> "Where we grant you the ability and right to enter into Transactions, to deal with us or to receive Data through the API Connection, we hereby grant you, for the term of this Agreement, a personal, limited, non-exclusive, revocable (upon notice), non-transferable and non-sublicensable license to use the API Connection solely for the Permitted Purpose pursuant to and in strict accordance with this Agreement (the "License")."

§2(1)–(2):

> "(1)    Any permission to use the API Connection will be at our sole discretion, which may be granted, suspended and/or revoked at any time, with or without notice, and may be subject to any conditions that we may communicate to you from time to time.
>
> (2)    You are only permitted to use the API connection and Data on the basis you are a Client and have a valid customer agreement and brokerage account with relevant certifications with TASTYTRADE, INC. and to the extent you are no longer a Client of TASTYTRADE, INC. or no longer, in our reasonable opinion, hold relevant certifications, your access to the API Connection and Data shall cease immediately or when we determine in our sole and absolute discretion."

§2(3)(b) — **own behalf only**:

> "(b) you have entered into this Agreement on your own behalf and not on behalf of any other person;"

§2(3)(e)–(g) — **the third-party-software approval gate and the API Hub rule**:

> "(e) you will use the API Connection solely for the Permitted Purpose pursuant to this Agreement and not for any other purpose;
>
> **(f) any application or software that you use in conjunction with the API Connection will be a software or application that is developed and owned by you unless you have notified us of the nature of the software or application and received our prior written approval for its use; and**
>
> **(g) you will not use an API Hub to communicate with us via the API Connection, unless you first ask our permission and unless the API Hub provider enters into a form of agreement with us as is required by us.**" *(emphasis added; text verbatim)*

§2(7) — third-party integrators:

> "You agree to monitor the use of your applications and software, including as a third party integrator, for any activity that violates Applicable Regulations or any terms and conditions of this Agreement or your Customer Agreement, including any fraudulent, inappropriate, or potentially harmful behavior, and promptly restrict any offending users of your applications or software. As between you and us, you are responsible for all acts and omissions of your end users in connection with your applications and software, and their use of the API Connection, if any."

§2(8) — **customer owns the instructions**:

> "You will be responsible for the accuracy and completeness of all information, data, instructions, orders, trades, or communications that you make via the API Connection. You acknowledge that you will be both responsible and liable for any errors in your communications to us via the API Connection or failure to communicate with us via the API Connection. We shall have no liability with respect to the above."

§2(12):

> "You agree that you will not hold yourself out as being part of, or representing, TASTYTRADE, INC. or any Associated Company of TASTYTRADE, INC., including when contracting with your clients. You acknowledge and agree that TASTYTRADE, INC. takes no liability or responsibility for your contractual or tortious relationship with your clients."

§2(13)(b) — **redistribution of the API**:

> "(b) rent, lease, lend, sell, license, sublicense, assign, distribute, publish, transfer, or otherwise make available the API Connection or any rights to the API Connection;"

§2(13)(f):

> "(f) design or permit your applications or software to disable, override, or otherwise interfere with the API Connection or any TASTYTRADE, INC.-implemented communications to end users, consent screens, user settings, alerts, warning, or the like."

§3 (Dealing Via The API Connection)(1):

> "Each time you place an order using the API Connection, you expressly acknowledge and agree that:
>
> (a) It is your responsibility to understand how an order operates before you place any such order with us and that you will not place an order unless you fully understand the terms and conditions attached to such order;
>
> (b) Whether or not we accept an order is at our absolute discretion
>
> (c)   We may restrict the availability of certain orders, or manage the execution of certain orders, increase margin requirements, or suspend the API Connection at our discretion and in particular during volatile market conditions, such as over economic announcements."

§8(4) — data redistribution:

> "Other than as expressly provided for under this Agreement, you represent and warrant that you will not copy, distribute, show, make available or publish any Data made available to you via the API Connection to any third party for whatever reason."

§13 (Definitions) — **"API Hub"**:

> ""API Hub" means a third party supplier's platform, technology or any other system that, directly or indirectly, enables you to communicate with us via, or otherwise access, the API Connection;"

§13 — **"Permitted Purpose"**:

> ""Permitted Purpose" means your use of the API Connection to receive Data provided to you under the terms of this Agreement, to facilitate your entry into Transactions with us in your personal or other account and such use so you can build out your own value-add front end platform or algorithmic trading systems."

§13 — "Client(s)" and "Customer Agreement":

> ""Client(s)" means any person who has entered into the Customer Agreement with us;"

> ""Customer Agreement" means the then current Customer Agreement set out on TASTYTRADE, INC.'s website at https://assets.tastyworks.com/production/documents/broker_customer_agreement.pdf as entered into between you and us;"

- **What it establishes:** tastytrade's API licence runs **to its own customer**, not to a software vendor. Within it: (i) the customer contracts "on your own behalf and not on behalf of any other person" (§2(3)(b)); (ii) the Permitted Purpose expressly includes building "your own value-add front end platform **or algorithmic trading systems**" — automated programmatic order submission on one's own account is affirmatively permitted; (iii) **but** §2(3)(f) requires that any application or software used with the API be "developed and owned by you" *unless* the customer has notified tastytrade of its nature and obtained **prior written approval**; and (iv) §2(3)(g) plus the "API Hub" definition require, for any "third party supplier's platform, technology or any other system that, directly or indirectly, enables you to communicate with us via … the API Connection", both the customer's request for permission **and** that the API Hub provider itself enter into a form of agreement with tastytrade.
- **Q3:** **SUPPORT on attribution** (§2(8): the customer is responsible and liable for all instructions and orders he makes via the API Connection; §3(1): "each time **you** place an order using the API Connection"). **ADVERSE on permission**: the same document conditions *which* software may make those orders.
- **Q2:** **ADVERSE (moderate).** §2(3)(g) is the clearest broker-side statement located in this track that a third party whose technology sits between the customer and the broker's API is a distinct regulated-by-contract category ("API Hub") that must itself contract with the broker. That is a private-contract analogue of interpositioning, and it is exactly the structural position the configuration's runtime occupies.
- **Level 3** (published operative contract; §2(3)(f)/(g) are the operative words, quoted in full).
- **Application note:** The configuration's runtime is a **free, open-source, locally installed** program that the member did not develop and does not own. On the plain words of §2(3)(f), it is therefore "software … used in conjunction with the API Connection" that is **not** "developed and owned by you", and its use requires the member to notify tastytrade of its nature and obtain **prior written approval**. That is a per-customer obligation running to the member, not to the distributor, but it is a real gate: absent approval, each member using the runtime against tastytrade is in breach of §2(3)(f). Separately, §2(3)(g)'s "API Hub" definition — "a third party supplier's platform, **technology or any other system** that, **directly or indirectly**, enables you to communicate with us via … the API Connection" — is drafted broadly enough on its face to reach a locally installed third-party runtime that composes and transmits orders to the tastytrade API, in which case tastytrade requires **the provider itself** to enter into a form of agreement with tastytrade. Whether "platform, technology or any other system" was intended to capture locally installed software the customer runs himself, as opposed to a hosted intermediating service, is **not resolved anywhere in the document**: "API Hub" is defined once and used twice (§2(3)(g), and in the liability carve-outs at §§5–6), with no example and no carve-out for locally installed clients. The tension with the Customer Agreement's own clause acknowledging that "tastytrade allows third party service providers to connect to the Firm's Open API" and contemplating the customer handing over username and password (S1b-05) is unresolved on the face of the two documents — and §1 of the API TOS says the API TOS prevails. **This is the sharpest adverse finding in the track**, and it is adverse to the configuration on Q2 in a way none of the other three brokers' terms are. Note finally that §2(3)(b) ("on your own behalf and not on behalf of any other person") confirms the API licence is not a vehicle for trading others' accounts — the tastytrade Open API has **no** Broker-API-style path at all, so unlike Alpaca there is no "other side" of the boundary to fall on.

---

### S1b-07 · tastytrade developer documentation (developer.tastytrade.com) — OAuth registration, agent trading, dry-run gate · retrieved 7 Sep 2026

- **Type:** published developer documentation (**not** contractual terms — see status note)
- **Date / status:** live at retrieval; pages undated. Site footer: "© 2017–2026 tastytrade, Inc. · tastytrade, Inc., member FINRA | SIPC | NFA". Retrieved as Markdown by appending `.md` (the site's documented agent-first convention). HTTP 200.
- **Status caution:** these pages are **engineering guidance, not terms**. The site's own footer routes the contractual question elsewhere: "By using tastytrade's API, you agree to our API Terms of Service." Nothing quoted below creates or evidences a contractual requirement of human review. It is recorded because a brief asked whether human review or manual entry is *required*, and the answer from tastytrade's own material is that it is a documented **product convention**, not an obligation.

**Verbatim quotes:**

`developer.tastytrade.com` home page:

> "tastytrade Open API — Trade programmatically — built for developers and AI agents. A REST/JSON API for equities, options, futures, futures options, and cryptocurrency. Place orders, stream market data, and manage accounts — with a safety-first MCP server for autonomous agents."

> "AI agents — Drive trading from an LLM via the self-hosted, open-source MCP server — order submission gated by dry-run-first confirmation."

`/docs/sdks-and-tools/mcp-server.md`:

> "The tastytrade **MCP server** gives AI agents structured access to the tastytrade API through the [Model Context Protocol](https://modelcontextprotocol.io/). It exposes the API as MCP **Tools**, **Resources**, and **Prompts**, and gates order submission behind a dry-run-first confirmation flow."

> "> **Self-hosted and open source.** You run it yourself. The source is at [github.com/tastytrade/tastytrade-mcp](https://github.com/tastytrade/tastytrade-mcp). There is no tastytrade-hosted endpoint to connect to."

> "Trading APIs are unforgiving — wrong quantity, wrong account, or wrong symbol costs real money. The MCP server adds guardrails enforced server-side, so an agent cannot skip them"

`/docs/concepts/accounts-and-customers.md`:

> "Once you have an `account-number`, you can read balances and positions and place orders against it. Because orders move money, follow the standard discipline: **dry-run first**, then submit the live order with a unique client-supplied `external-identifier`."

`/docs/authentication/oauth2.md` — **self-service registration by the account holder**:

> "Every request to the tastytrade API is authenticated with an OAuth2 access token in the `Authorization` header. All API users must use OAuth2 — the legacy `POST /sessions` flow was [decommissioned in 20260211](/docs/release-notes)."

> "## Step 1 — Create an OAuth application
>
> On [my.tastytrade.com](https://my.tastytrade.com), go to **Manage → My Profile → API → OAuth Applications** and click **+ New OAuth client**.
>
> - **Client Name** is prefilled with your tastytrade username.
> - **Redirect URI**, one per environment requested. …
> - **Scopes**: `read`, `trade`, `openid`."

> "## Step 2 — Generate a personal grant
>
> For your own application you do not need the full authorization flow. Go to **Manage → My Profile → API → OAuth Applications**, click **Manage** next to your application, then **Create Grant**. This shows your grant's **refresh token**."

- **What it establishes:** (i) tastytrade publicly markets its API as "built for developers and AI agents" and ships its own open-source, **self-hosted** MCP server for autonomous agent trading — i.e. programmatic order submission by non-human agents on a customer's own account is not merely tolerated but productised by the broker; (ii) the "dry-run-first confirmation" is a **product guardrail in tastytrade's own optional software**, not a contractual requirement — the Customer Agreement's 1-Click Trading clause (S1b-05 §7) proves the opposite is contractually fine; (iii) OAuth client registration is **self-service by the account holder**, with a "personal grant" path expressly for "your own application", carrying scopes `read`, `trade`, `openid`. There is **no** Alpaca-Connect-style compliance review of the app in the documented flow; the gate on third-party software sits instead in API TOS §2(3)(f)/(g).
- **Q3:** SUPPORT (moderate) — the credential is the account holder's own, created by the account holder, and the "personal grant" path is designed for the account holder running his own client.
- **Q2:** NEUTRAL to SUPPORT (weak).
- **Level 2** — undated vendor documentation, expressly non-contractual, subject to change.
- **Application note:** The "personal grant" flow is a close structural match to the configuration: the member registers his own OAuth client under his own tastytrade login, creates his own refresh token, and the locally installed runtime holds it in the member's local vault. Nothing in the documented flow involves a company-held client credential. But note the mismatch with API TOS §2(3)(f): the OAuth docs say the personal-grant path is "**for your own application**", and the runtime is not the member's own application. The documentation does not address software the member did not write; the API TOS does, and it requires prior written approval. On tastytrade specifically, **the documentation is more permissive than the contract, and the contract governs.**

---

## CHARLES SCHWAB — client-side gap (narrow scope)

> **Gap status: CLOSED.** P7 recorded `schwab.com/legal/terms-of-use` as HTTP 404 and the client-facing instrument as unlocated. It is now located and quoted. **Correction to P7's premise:** that URL is not a broken link to a moved document — `archive.org/wayback/available?url=schwab.com/legal/terms-of-use` returns `{"archived_snapshots": {}}`, i.e. **it has never been archived and appears never to have existed.** Schwab publishes no general website "terms of use" instrument. The operative client-side terms are the **Account Agreements** and the **Electronic Services Agreement** embedded in and published alongside them.

### S1b-08 · Schwab Electronic Services Agreement (standalone), rev. `(0123-22KE) REG131111-01 (07/26)` · https://www.schwab.com/legal/electronic-services-agreement · retrieved 7 Sep 2026 (HTTP 200, 392,300 bytes)

Also read and cross-checked, same date:
- **Schwab Account Agreement**, July 2026, doc code `(0726-3HXA)` — `https://www.schwab.com/legal/schwab-brokerage-account-agreement` (HTTP 200, 734,641 bytes)
- **Schwab One® Account Agreement**, July 2026, doc code `(0726-3HXA)` — `https://www.schwab.com/legal/schwab-one-account-agreement` (HTTP 200, 830,812 bytes)
- **Amendments to the Following Account Agreements**, effective 1 July 2026, `E-0726-03990 REG91216-19 (07/26)` — `https://www.schwab.com/legal/account-agreement-amendment` (HTTP 200, 345,538 bytes)

- **Type:** published terms (retail brokerage client agreement)
- **Date / status:** operative at retrieval. **Structural note:** the Account Agreements each embed a complete Electronic Services Agreement as a sub-agreement numbered §§1–23; the standalone ESA at the URL above is the same agreement in a **modernized redraft**. Both are live simultaneously and **§12 differs materially between them** (see below). The standalone ESA states: "This Electronic Services Agreement amends your brokerage account agreement(s) and replaces any prior agreement between you and Schwab regarding your use of the Electronic Services."
- **Amendment check:** the 1 July 2026 amendment notice amends only "Security for Indebtedness and Right of Setoff" and adds "Intraday Margin Buying Power". **Nothing in it touches ESA §§11, 12 or 14, or Order Entry Services.** The clauses below stand as quoted.
- **Verification:** independently re-fetched and confirmed by this analyst, not only by the delegated search — all four probe strings located in the live HTML at the byte offsets recorded, and the zero-counts below re-run directly.

**Verbatim quotes, pin-cited:**

**ESA §11, sub-heading "Orders May Not Be Manually Reviewed"** (identical in the standalone ESA and in both Account Agreements) — **directly on the human-review question**:

> "Orders May Not Be Manually Reviewed. You understand and acknowledge that when you place orders using Schwab's Electronic Services, those orders may be sent directly to an exchange without being viewed by an individual Schwab representative. You acknowledge that you bear the entire risk and agree to accept full responsibility for the orders you place. You further agree to release Schwab from any liability for executing the orders you place using Schwab's Electronic Services."

**ESA §12 (Access, Passwords and Security) — standalone ESA, rev. 07/26 — THE Q3 CLAUSE:**

> "12. Access, Passwords and Security
>
> You will be responsible for the confidentiality and use of your access number(s), password(s), account number(s), and other information used to facilitate access to your account (collectively, "Access Information"). You agree that Schwab is not liable for any damages of any kind resulting from your decision to disclose any of your Access Information to any third party, including, but not limited to, entities that aggregate account information or website content, or persons who are or claim to be acting as your agent, proxy or investment manager. If you inform Schwab or Schwab has reason to believe that the security of your account, or the security of any of your Access Information, may be or has been compromised, we have the right to terminate your use of Electronic Services. **You will be responsible for all orders entered through and under your Access Information, and any orders so received by Schwab will be deemed to have been received from you.** All orders shall be deemed to be made at the time received by Schwab and in the form received."

*(emphasis added. Transcription note: Schwab's own HTML renders "confidentiality", "confirmation", "five" and "conflicting" with the U+FB01 "fi" ligature — a PDF-to-HTML extraction artifact in Schwab's source. Normalised to "fi" above; the ligature is in the original bytes.)*

**ESA §12 — the older draft as embedded in the July 2026 Account Agreements** (both documents), materially narrower:

> "You will be responsible for the confidentiality and use of your access number(s), password(s) and account number(s). You agree not to hold Schwab liable for any damages of any kind resulting from your decision to disclose your access number(s), password(s) or account number(s) to any third party, including, but not limited to, entities that aggregate account information or website content, or persons who are or claim to be acting as your agent, proxy or Investment Advisor. … **You will be responsible for all orders entered through and under your access number(s), password(s) and account number(s), and any orders so received by Schwab will be deemed to have been received from you.** All orders shall be deemed to be made at the time received by Schwab and in the form received."

**ESA §14 — the adverse clause:**

> "14. Use of Software, Programs, Applications or Other Devices to Access Electronic Services
>
> With the exception of applications commonly known as web-browser software, or other applications formally approved by Schwab in writing, you agree not to use any software, program, application or any other device to access or log on to Schwab's computer systems, website or proprietary software or to automate the process of obtaining, downloading, transferring or transmitting any content, information or quotes to or from Schwab's computer systems, website or proprietary software."

**Schwab Account Agreement §26 (Order Entry Services), July 2026** — a second, independent attribution clause:

> "The services may require you to use a number or password to access your Schwab Account. You are responsible for the confidentiality and use of your access number, password, and account number, and for all securities and other transactions initiated through these means. **Any orders communicated to us through these means will be considered to have been sent and authorized by you.**"

*(The Schwab One® Account Agreement carries the same text with "Schwab One® Account" / "Securities" substituted.)*

**Schwab Account Agreement §58 (Authorizations Granted to Advisors)** — the trading-authorization surface:

> "For accounts managed by an advisor, any and all authorizations you grant to your advisor or other third parties with respect to your Account will apply to the successors and assigns of such advisor or other third party, subject to limitations of applicable law.
>
> This provision applies if your Account is managed by an advisor and you have granted your advisor 'trading and disbursement' authority and instructed Schwab (either on a form or otherwise) to accept that authority."

**Schwab Account Agreement §6 (Payment of Indebtedness)** — POA language:

> "You agree to make payment of any indebtedness related to your Schwab Account, including, but not limited to, any such indebtedness that results from instructions provided to Schwab by you, your agent, or any attorney-in-fact under a power of attorney or advisor authorized to make transactions in your Schwab Account."

**ESA §1 (Scope of the Agreement)** — defines the surface §14 governs:

> "Scope of the Agreement —This Electronic Services Agreement (the 'Agreement') between you and Schwab states the terms and conditions that govern your use of Schwab's Electronic Services. It is part of your brokerage account agreement. The term 'we,' when used below, means Schwab. The term 'Electronic Services' includes all of Schwab's computer, telephonic, facsimile, email, or wireless services or systems."

- **What it establishes:** (i) Schwab's retail client agreement contains an express **deeming** provision — orders entered under the client's Access Information "will be deemed to have been received from you", reinforced by Account Agreement §26 ("considered to have been sent and authorized by you"); (ii) Schwab expressly contemplates the client disclosing Access Information to third parties — naming **aggregators** and "persons who are or claim to be acting as your **agent, proxy or investment manager**" — and responds by disclaiming liability, **not** by prohibiting it; (iii) Schwab's retail terms contain **no** requirement of human review and affirmatively disclaim it (§11); and (iv) §14 prohibits using any software other than a web browser or an application "formally approved by Schwab in writing" to access Schwab's systems or to automate transmission of content to or from them.
- **Q3:** **SUPPORT (strong) on attribution** — §12 and §26 are deeming provisions keyed to credentials. **ADVERSE on permission** — §14 conditions *which* software may reach Schwab's systems.
- **Q2:** NEUTRAL to weak SUPPORT — §12's naming of "agent, proxy or investment manager" as a category of third party the client may hand credentials to shows Schwab treats such arrangements as client-side matters it declines to police, without characterizing them.
- **Level 3** (published operative retail contract, retrieved in full and independently verified).
- **Application note:** §12/§26 map onto the configuration as squarely as Alpaca's §16(e)(7) and tastytrade's §4: the runtime transmits under the member's own Access Information, so the resulting order is **deemed** by contract to have been received from, sent by and authorized by the member. Schwab goes further than the other two by naming the very categories of third party at issue — aggregators and persons "acting as your agent, proxy or investment manager" — and treating disclosure to them as the client's own risk allocation rather than a breach.

  **§14 is the real adverse finding, and it needs care.** Two readings are available on the words, and the documents do not choose between them:
  - **Narrow reading:** §14's object is "**Schwab's computer systems, website or proprietary software**", and the verbs are "access or log on to" and "automate the process of obtaining, downloading, transferring or transmitting … content, information or quotes". That is the vocabulary of scraping and automating the *retail web channel*. The **Trader API is a different, separately licensed channel** with its own instrument (the Developer Program Agreement) and its own fee treatment — P7 already has the April 2026 Pricing Guide expressly pricing "Trades placed through Schwab.com … **or Schwab APIs**" at $0, which is Schwab acknowledging the API as a first-class order channel for retail clients. On this reading a registered Trader API application is not what §14 is aimed at.
  - **Broad reading:** "Schwab's computer systems" is broader than the website, and a locally installed runtime is plainly "software, program, application" that "transmit[s] … content [and] information … to … Schwab's computer systems".

  **The two readings converge on the same practical answer**, which is the useful point: §14 carves out "**other applications formally approved by Schwab in writing**", and the Schwab Trader API Developer Program Agreement's registration-and-review regime (P7, §2 — any Application distributed to third parties, free or for a fee, is a Commercial Application requiring "Company" registration and review) **is** the written-approval mechanism. So on either reading, the client-side terms and the developer-side terms point to the same gate: **a third-party application reaching Schwab under a client's credentials needs Schwab's written approval, obtained through the Developer Program.** Schwab is therefore the broker in this track whose client-side and developer-side instruments are most consistent with each other — and the gate is real, not avoidable by the configuration's design choices. Note that P7 also already records Developer Program Agreement §3: "Schwab has no obligation to verify whether the activities undertaken by you and/or your Applications require registration under Applicable Law" — approval under the programme is expressly **not** a view on securities-law status.

**Documented zero-counts (re-run directly by this analyst on the live HTML, 7 Sep 2026):** across the standalone ESA (38,506 chars of extracted text) and the Schwab Brokerage Account Agreement (227,204 chars), case-insensitive occurrences of `robot` = **0**, `spider` = **0**, `crawl` = **0**, `scrap` = **0**, `application programming interface` = **0**. Schwab covers this ground functionally through §14 and through §12's "entities that aggregate account information or website content", not through the robots/spiders vocabulary. **There is no API clause in Schwab's retail client agreements at all** — the API is governed entirely on the developer side.

---

### S1b-09 · Schwab Trader API Developer Program Agreement — version status check (task 2 only; body NOT re-quoted, per brief)

- **Finding: "May 2023" remains the operative version as of 7 September 2026. Not amended, not superseded.**
- **How established (primary, not secondary):** `developer.schwab.com` is an Angular SPA — every legal path (`/legal-notices`, `/terms-of-use`, `/terms`, `/legal`, `/developer-program-agreement`, `/products/trader-api--individual`) returns HTTP 200 with an identical 55,033-byte shell and no server-rendered content. The document itself was reached through the portal's own content API:
  - anonymous bearer token from `https://devportal-token.schwab.com/api/v1/Token` (HTTP 400 without a `Schwab-Resource-Version` header; **HTTP 200**, 515 bytes with it);
  - `…/AnonymousUser/api/v1/Product/product-access-management/trader-api--individual` → HTTP 200, 248 bytes → `"termsAndConditionsCmsAssetIds":["trader-api-terms-and-conditions"]` (identical for `trader-api--commercial`; the five other lines of business return an empty array — this is the only such asset portal-wide);
  - **`https://contentdelivery.schwab.com/api/content/rtcontent/asset/trader-api-terms-and-conditions`** → **HTTP 200, 23,226 bytes**, fetched 7 Sep 2026 09:54:56Z.
- **Evidence of version:** the document's own opening line reads `SCHWAB TRADER API DEVELOPER PROGRAM AGREEMENT May 2023`. Schwab's CMS metadata returns `published_date: "2023-05-24T16:39:41+00:00"`, `moderation_state: "published"`, and **no** `changed` value. The only year token in the 56,005-character body is 2023; there is no effective date, revision number, or any occurrence of `revis*`. Sibling assets in the same API carry 2026 dates (2026-09-03, 2026-08-20, 2026-07-21), which demonstrates the field **does** track republication — so its absence here is meaningful rather than an artefact.
- **Two caveats, recorded rather than smoothed over:** (i) there are **zero** Wayback captures of the asset endpoint itself, so a silent body edit under an unchanged header would be invisible to this method; (ii) this was established **anonymously** — `Product/find-products` returned HTTP 401, so an authenticated or commercial-applicant surface remains unexamined. Confidence high but not absolute; **not** marked ◇ because the primary document text and its CMS publication metadata were both retrieved directly.
- **Do not confuse with:** the adjacent **Developer Program Website Terms and Conditions** (`dev-portal-user-registration-terms-and-conditions`, HTTP 200, 16,840 bytes), which is dated "Last Updated February 14, 2023" and is a distinct site-usage instrument.

### Schwab — the Q3 line, answered

**YES — and Schwab states it twice, in deeming language, in two separate operative instruments.**

The clause that decides it is **ESA §12**:

> "**You will be responsible for all orders entered through and under your Access Information, and any orders so received by Schwab will be deemed to have been received from you.** All orders shall be deemed to be made at the time received by Schwab and in the form received."

with **Account Agreement §26** to the same effect ("Any orders communicated to us through these means will be considered to have been sent and authorized by you"), and **ESA §11** removing any implication that a human must see the order first ("those orders may be sent directly to an exchange without being viewed by an individual Schwab representative … you bear the entire risk and agree to accept full responsibility for the orders you place").

**The qualification that must travel with that answer:** Schwab's YES is an answer about **attribution**, not about **permission**. The same agreement, at §14, forbids using any application other than a web browser or one "formally approved by Schwab in writing" to reach Schwab's systems. So under Schwab's own terms an order sent by third-party software under the member's credentials is **the member's own order** — and may simultaneously be an order sent by software that needed Schwab's written approval and, absent Developer Program registration, did not have it. **Attribution and authorization are answered separately, and the answers do not depend on each other.** That separation is the single most important structural finding in this track and it recurs at every broker in it.

---

## FIDELITY

> **Headline: Fidelity is the adverse outlier of this track.** It is the only broker of the four whose terms expressly provide that **the customer's own consent does not cure** third-party access — and the only one with **no retail trading API at all**.

### S1b-10 · Fidelity Investments Terms of Use, Last Updated **1 July 2026** · https://www.fidelity.com/terms-of-use · retrieved 7 Sep 2026 (HTTP 200, 47,039 bytes gzip / 261,069 bytes raw)

- **Type:** published terms (website terms of use, incorporated into the brokerage relationship — see S1b-11, "Terms Concerning This Agreement / Applicability")
- **Date / status:** "Last Updated: July 1, 2026", stated at the head of the document. Operative at retrieval.
- **Citation caution — recorded because it nearly caused an error:** the sections of this document are **unnumbered `<h2>` headings**, not numbered clauses. An automated summarising fetch asserted twice, independently, that "Prohibited Uses and Termination of Access" is "Section 14". **It is not numbered at all in the source.** Cite by heading, never by number.
- **Verification status:** the verbatim text below was extracted from raw HTML by the delegated researcher. This analyst's own re-fetch was **blocked by Akamai (HTTP 403, 390 bytes, on both the target and a previously-good control page)** after the earlier crawl — Akamai's gating is rate- and header-sensitive, so this is a block, not evidence of non-existence. Every decisive quotation below was therefore **independently re-confirmed through a second, different retrieval channel**, which returned the same sentences verbatim and the same "Last Updated: July 1, 2026". **Two independent retrievals agree on every quoted sentence.** Not marked ◇: the text is primary and doubly sourced.

**Verbatim quotes, cited by heading:**

Heading **"Prohibited Uses and Termination of Access"** — **the decisive passage**:

> "You may use the Fidelity Websites only as permitted by law.
> You may use the Fidelity Websites only for personal, non-commercial purposes.
> You may not do any of the following: (a) use the Fidelity Websites in any manner that could damage or overburden any Fidelity server, or any network connected to any Fidelity server; (b) use the Fidelity Websites in any manner that would interfere with any other party's use of the Fidelity Websites; or (c) introduce or permit any person to introduce into the Fidelity Websites any code or malicious or hidden mechanisms that would impair the operation of the Fidelity Websites, or of Fidelity's computers, networks, or other devices or software.
>
> **You may not access the Fidelity Websites using devices, services, platforms, or software ("Third-Party Access Tools") designed to provide high-speed, automated, or repeated access to Fidelity Websites. This prohibition extends to Third-Party Access Tools used or intended to be used to facilitate trading in a Fidelity account or to automate or otherwise assist the process of obtaining, downloading, transferring, or transmitting any information to or from any Fidelity account, unless such Third-Party Access Tools are expressly approved in writing, authorized, or made available by Fidelity for Your use.**
>
> You may not use any feature or services made available by the Fidelity Websites to interact with any Fidelity computer, network or service other than for the purposes and in the manner for which the feature or service is made available to, and is intended to be used by, users of the Fidelity Websites.
>
> **Certain parts of the Fidelity Websites require credentials, such as a username and password, to access them ("Restricted Content"). You may not obtain or attempt to obtain access to Restricted Content, including but not limited to Fidelity customer accounts, through any means not intentionally made available by Fidelity for Your specific use.**
>
> **Any commercial entity that accesses Restricted Content without express consent from Fidelity for any purpose, including to view, transact in or manage Fidelity customer accounts, is in violation of these Terms, even if instructed to do so by an authorized user or another party acting with authority on the authorized user's behalf.** No content made available on the Fidelity Websites may be reproduced, duplicated, copied, sold, resold, or otherwise exploited for any commercial purpose without express written consent of Fidelity."

*(emphasis added; text verbatim)*

Immediately following, the remedy:

> "Accessing, using, or disclosing any data, content, or materials (including Third Party Content and Restricted Content) from the Fidelity Websites in any manner inconsistent with these Terms or any other obligations that are made to Fidelity by You will constitute immediate and irreparable harm to Fidelity and/or the Third Party Content Providers and, in such an event, remedies at law will not be adequate. Accordingly, in addition to all other remedies available at law or in equity, and regardless of any arbitration clause or alternative dispute resolution clause that might otherwise be applicable to certain disputes between You and Fidelity, Fidelity and its Third Party Content Providers shall have the right to seek equitable and injunctive relief…"

Heading **"Password Security and Notification"** — **the Q3 attribution clause, and the credential-sharing prohibition**:

> "If You have a password for access to non-public areas of the Fidelity Websites, You are solely responsible for maintaining the confidentiality of any username, password, and other security data, methods, and devices. **Further, You are responsible for all activities that occur in connection with Your access credentials or password, including all instructions electronically transmitted to Fidelity via the Fidelity Websites and all use of any data, information or services obtained using Your access credentials or password and other security data. Fidelity shall not be under any duty to inquire as to the authority or propriety of any instructions given to Fidelity by You or by a person who has logged on using Your access credentials or password, shall be entitled to act upon any such instructions, and will not be liable for any loss, cost, expense, or other liability arising out of any such instructions.** Accordingly, You should take steps to protect the confidentiality of Your access credentials or password. Nothing in these Terms alters or supersedes any rights or protections that might be provided to You under Regulation E."

Same heading — the flat prohibition:

> "**Do not share Your access credentials or passwords for the Fidelity Websites, or any accounts held outside of Fidelity aggregated through the Fidelity Websites, with any other persons. Doing so voids Fidelity's Customer Protection Guarantee (available here and here) and may also void account protections at any other firm where the accounts reside.**"

Heading **"Modification of These Terms"**:

> "Fidelity Investments may modify these Terms at any time without notice to You, except where required by law. When we make changes to these Terms, we will change the 'Last Updated' date specified at the beginning of these Terms. … Use of the Fidelity Websites shall constitute acceptance by You of the Terms in effect as of such time."

- **What it establishes:** Fidelity prohibits, without its own express written approval, the use of any "devices, services, platforms, or software" designed for "automated … access", **expressly extending that prohibition to tools "used or intended to be used to facilitate trading in a Fidelity account"**; treats credentialed areas as "Restricted Content" reachable only "through … means … intentionally made available by Fidelity"; and provides that a **commercial entity** accessing Restricted Content to "view, transact in or manage" customer accounts violates the Terms **"even if instructed to do so by an authorized user"**. Simultaneously, and without contradiction, it makes the customer "responsible for all activities that occur in connection with Your access credentials", including "all instructions electronically transmitted to Fidelity", and relieves Fidelity of any duty to inquire into the authority or propriety of instructions given by "a person who has logged on using Your access credentials".
- **Q3:** **SUPPORT on attribution, ADVERSE on permission — and here the two are expressly severed by the document itself.** The customer owns the instruction (Password Security heading); the third party is nonetheless in violation (Prohibited Uses heading). Fidelity is the only broker in this track that states the severance in terms.
- **Q2:** **ADVERSE (strong).** "Any commercial entity that accesses Restricted Content … including to view, transact in or manage Fidelity customer accounts, is in violation of these Terms, even if instructed to do so by an authorized user" is a direct, current, operative statement by a major retail broker that customer authorization is **not** a sufficient basis for third-party commercial software to reach a customer's account. It is not a securities-law holding and creates no §15(a) liability — but it is the single strongest broker-side statement located in this track against the proposition that "the member authorized it" settles the matter.
- **Level 3** (published operative terms of a major retail broker; doubly retrieved).
- **Application note:** The configuration's runtime is software that facilitates trading in the member's account and automates transmission of information to and from it. On the plain words it is a "Third-Party Access Tool", and its use requires Fidelity's express written approval, which Fidelity provides no published route to obtain (see S1b-12). The configuration's central design feature — that **every** decision-relevant input is the member's and the member performs an explicit per-order act — **does not engage this clause at all**, because the clause is not about who decides or who consents. It bites on the *nature of the access mechanism* and on the *commercial character of the entity*. The "even if instructed to do so by an authorized user" sentence is drafted precisely to foreclose the consent argument. Two features of the configuration are nevertheless worth putting beside it, without drawing a conclusion: (i) the prohibition's object is "the **Fidelity Websites**" — a term Fidelity defines by reference to its own web properties, and the configuration contemplates connecting to a broker's **published retail API**, which for Fidelity does not exist (S1b-12), so the clause and the configuration may simply never meet on Fidelity; and (ii) the clause targets a "**commercial entity**" accessing Restricted Content — the configuration's runtime is free and open-source and the entity accessing the account is the member himself using software he installed, though the distributor charges a monthly membership, which is a commercial fact a reader could press either way.

---

### S1b-11 · FIDELITY ACCOUNT® Customer Agreement, `FA-CUSTOM-0626` (June 2026) · https://www.fidelity.com/bin-public/060_www_fidelity_com/documents/customer-service/updated-agreements/Updated-Fidelity-Account-Customer-Agreement.pdf · retrieved 7 Sep 2026 (HTTP 200, 160,370 bytes)

- **Type:** published terms (brokerage customer agreement)
- **Date / status:** doc code `FA-CUSTOM-0626`; © 2026 FMR LLC; version `459480.52.0` / `1.828130.154`; PDF ModDate 17 June 2026. Uses **named headings, not numbered sections** — cited accordingly.

**Verbatim quotes:**

Heading "Things to Know Before Using Your Account" / "Your Commitments to Fidelity":

> "• to accept full responsibility for the content and accuracy of all authorized instructions placed on your account, and for all results and consequences of these instructions, including all investment decisions, trading orders, tax consequences, and instructions placed by you or any other person you authorize"

> "As the account owner, you are fully responsible for monitoring your account and for all investment decisions and instructions concerning your account. Unless we have contractually agreed otherwise, we have no responsibility for monitoring your account or your investment decisions, even if your decisions were based on our recommendations."

Heading "Limits to Our Responsibility":

> "You therefore agree that we are not responsible for any losses you incur … as a result of any of the following:
> • the acceptance and processing of any order placed on your account, whether received electronically or through other means, **as long as the order reasonably appears to be authentic**; or the refusal to accept or execute any order, instruction, or transfer as Fidelity may elect to do at any time
> …
> • investment decisions or instructions placed on your account, or other such actions attributable to you or **any authorized person**"

> "Note that beyond taking reasonable steps to verify the authenticity of instructions, we have no obligation to inquire into the purpose, wisdom, or propriety of any instruction we receive."

Heading "Indemnification":

> "You agree to indemnify us from, and hold us harmless for, any losses (as defined in 'Limits to our Responsibility') resulting from your actions or failures to act, whether intentional or not, **including losses resulting from actions taken by third parties.**"

Heading "Modification and Enforcement" — **credential sharing recharacterised as an assignment of the account**:

> "Fidelity may transfer its interests in this account or agreement to any of its successors and assigns, whether by merger, consolidation, or otherwise. **You may not transfer your interests in your account or agreement (including de facto transferal by giving a nonowner access to the account using a password) except with the prior written approval of Fidelity**, or through inheritance, corporate dissolution, or similar circumstance, as allowed by law…"

Heading "Prohibited Uses and Actions" — **the account-holder's own bar**:

> "**You are strictly prohibited from using your account in conjunction with any business as a broker-dealer, trader, agent, or advisor in any type of security, commodity, future, or contract, or in any business or organization connected with individuals performing these functions.** You are also prohibited from publicizing or sharing with anyone any information you obtain through your account (such as securities quotes). In addition, be aware that we may freeze your account or suspend certain privileges, features, or services at any time without notice."

Heading "Accessing Your Account" — **the exhaustive channel list**:

> "There are a variety of ways you can place orders, access your account, get market and investment information, or contact Fidelity. Online choices include Fidelity.com, Fidelity Active Trader Pro®, alerts and wireless trading services, the Fidelity Investments mobile app, and other interactive services for computers or handheld devices. Some of these services are offered by Fidelity directly; others are offered by outside providers.
> Telephone choices include Fidelity Automated Service Telephone (FAST®) as well as Fidelity's telephone representatives. Both services are generally available 24 hours a day, 7 days a week…"

- **What it establishes:** Fidelity's customer agreement attributes authorized instructions to the customer, declines any duty to inquire beyond authenticity, and indemnifies itself against "losses resulting from actions taken by third parties" — but separately characterises giving a non-owner password access as a **de facto transfer of the account**, void absent Fidelity's prior written approval, and separately again bars the customer from using the account "in conjunction with any business as a broker-dealer, trader, agent, or advisor". Its enumeration of access channels is entirely human-facing UIs plus telephone; **no programmatic channel appears**.
- **Q3:** SUPPORT on attribution ("all authorized instructions placed on your account … including … instructions placed by you or any other person you authorize"); **ADVERSE on permission** (the "de facto transferal" clause).
- **Q2:** ADVERSE (moderate).
- **Level 3.**
- **Application note:** The "de facto transferal by giving a nonowner access to the account using a password" clause is the second broker-side prohibition on the exact credential mechanism the configuration uses, and it is drafted to catch it regardless of consent — the customer's consent is the very act it voids. Note that the configuration would not "give" credentials to anyone: they never leave the member's own machine and no company system holds them. Whether software installed on the member's own machine, holding the member's key in the member's own keychain, gives "a nonowner access to the account" is unaddressed. That is a genuinely open reading, but Fidelity's Terms of Use "Third-Party Access Tools" clause (S1b-10) does not depend on it and would still apply.

---

### S1b-12 · Fidelity — NEGATIVE FINDING: no open retail trading API, no developer portal · established 7 Sep 2026

**Finding: as of 7 September 2026, Fidelity publishes no open retail trading API and no developer portal for individual customers.** The brief anticipated this; it is confirmed, and documented from Fidelity's own infrastructure rather than asserted. Six independent lines, each reproducible:

**(i) DNS — every candidate developer hostname does not resolve:**

| Hostname | Result |
|---|---|
| `developer.fidelity.com` | **NXDOMAIN** |
| `developers.fidelity.com` | **NXDOMAIN** |
| `api.fidelity.com` | **NXDOMAIN** |
| `apis.fidelity.com` | **NXDOMAIN** |
| `devportal.fidelity.com` | **NXDOMAIN** |

**(ii) Path probing against a validated control.** Because Akamai returns 403 for both blocked and non-existent paths, a control signature was established first: a known-nonexistent path (`/zzz-this-page-does-not-exist-12345`) returns **403 with body size exactly 243 bytes**, while a known-good path (`/security/overview`) returns **200, 39,126 bytes**. Against that discriminator:

| Path | Result | Reading |
|---|---|---|
| `/zzz-this-page-does-not-exist-12345` (control) | 403, **243 B** | not-found signature |
| `/security/overview` (control) | 200, 39,126 B | exists |
| `/developer` | 403, **243 B** | does not exist |
| `/developers` | 403, **243 B** | does not exist |
| `/api` | 404, 85 B | does not exist |

**(iii) Fidelity's own sitemap.** `sitemap1.xml` + `sitemap2.xml` enumerate **3,208 URLs**. Filtering for `develop|/api|partner|integrat` returns exactly **one** hit — `/learning-center/women-talk-money/planning-with-your-partner`, an unrelated article. No developer, API, partner or integration page exists anywhere in Fidelity's published site index.

**(iv) Fidelity's own robots.txt** (2,478 bytes, read in full) lists ~200 disallowed paths and contains no `/developer`, `/api` or partner path.

**(v) The word "API" appears zero times** in either the Terms of Use or the Fidelity Account Customer Agreement (`grep -own "API"` across both: **0 matches**).

**(vi) The Customer Agreement's own enumeration of access channels** (S1b-11, "Accessing Your Account") lists only human-facing UIs and telephone. No programmatic channel.

- **Q3 / Q2:** **NEUTRAL as to the configuration, but dispositive as to Fidelity.** The configuration requires the member's broker to have an "own published retail API". Fidelity has none. **Fidelity is therefore not an available broker for this configuration at all** — which makes its adverse Terms-of-Use language a warning about industry drafting practice rather than an operative obstacle on the configuration's own facts.
- **Level 4** as a negative finding — documented at the DNS, HTTP, sitemap, robots.txt and document-text layers against a validated control, not inferred from silence.
- **Explicitly UNVERIFIED and excluded:** Fidelity's **institutional/Wealthscape** API offering. Two candidate endpoints (`institutional.fidelity.com/app/item/RD_13569_46171/wealthscape-integration-xchange.html` and `/advisors/services/technology/apis`) each returned HTTP 200 with **identical 9,358-byte "Page Unavailable / Akamai Reference Number" error bodies**. Nothing in this register entry is a claim about Fidelity's institutional APIs, which are in any event not a retail channel and not available to a member trading his own account.

---

### S1b-13 · Fidelity Access — data-sharing programme (not a trading channel) · retrieved 7 Sep 2026

Sources: **"Fidelity Access And Data Security: Protecting Your Online Finances"**, `https://www.fidelity.com/security/fidelity-access-data-security` (HTTP 200, 39,423 bytes; the redirect target of `/security/fidelity-access`), and **"Data security when connecting with third-party websites and apps"**, `https://www.fidelity.com/security/third-party-app-protection` (HTTP 200, 40,158 bytes).

**Verbatim quotes:**

> "**Fidelity Access℠ — Sharing your Fidelity account data with confidence**
> To enhance the protection of your Fidelity account data, Fidelity has established a secure connection that better controls how third-party websites and applications that you've authorized, and the data aggregators they use, connect to your Fidelity accounts. We call this connection Fidelity Access.
> When you choose to access your Fidelity account information through a website or application that has an integrated connection to Fidelity via Fidelity Access, you'll be automatically linked to Fidelity. You complete the process by authorizing Fidelity to allow the website or application to access **the account information** for the Fidelity accounts you identified. With Fidelity Access, you never have to provide your Fidelity username and password to a third party. In addition, you can use your data sharing dashboard to remove a third party's authorization to access your Fidelity account information."

FAQ, "What is Fidelity Access?":

> "Fidelity Access provides a convenient and more secure way to share your Fidelity account data with third-party websites and applications using our integrated connection. This means you do not provide your Fidelity username and password to these third parties to access your Fidelity account data."

FAQ, "How do third-party financial websites and applications obtain Fidelity account data without Fidelity Access?" — **Fidelity's own definition of screen scraping**:

> "Third-party websites, apps and data aggregators that don't use Fidelity Access to obtain your Fidelity account information likely obtain that information through a practice called 'screen scraping'. To accomplish this, the third-party website, app, or aggregator requires you to provide them with your username and password for your Fidelity accounts. They then use your Fidelity username and password to log into your Fidelity accounts and to extract your Fidelity account information for their use or for use by the third-party financial site or application they serve. Since these third parties access your Fidelity accounts using your username and password, they have the same access to much of the same information that you do when you log in to your Fidelity accounts."

From "Data security when connecting with third-party websites and apps":

> "**How Fidelity is helping protect your data** — To enhance the protection of your account data, Fidelity has established a secure connection that better controls how third-party websites and apps that you've authorized, and the data aggregators they use, connect to your accounts. **Fidelity is requiring these data aggregators to transition to this secure connection.** Fidelity users of some third-party websites and apps may experience a disruption in the link between those websites and apps and their Fidelity accounts."

> "**What is a data aggregator?** Data aggregators are used to collect and exchange data between your accounts and third-party websites and apps. When you provide your login credentials to a third-party website or app, your data may be retrieved by an aggregator. Once you share your login credentials, they have the same access to your data that you do."

> "**What if I still want an impacted third-party provider to have my data?** Typically, you can manually enter data on the third-party provider's website."

- **What it establishes:** Fidelity Access is a **tokenized, revocable, read-only account-data** channel in which the customer authorizes **Fidelity** (not the third party) and no credentials pass to the third party. Fidelity is actively **compelling** aggregators off credential-based screen scraping. **In the entire Fidelity Access corpus there is no statement that a third party may place trades through it**; the only transactional extension mentioned anywhere is money movement for peer-to-peer payment apps, which is cash transfer, not securities orders.
- **Q3:** NEUTRAL. **Q2:** NEUTRAL.
- **Level 3** for the quoted programme description; the read-only characterisation rests on the **absence** of any trading reference across the whole corpus — strong, but an inference, and flagged as such.
- **Application note:** Fidelity Access is the sanctioned third-party channel and it is a **data** channel. It confirms the industry direction P7 did not have: brokers are replacing credential sharing with tokenized, scoped, revocable delegation — but at Fidelity that delegation carries **read** scope only, in contrast to Alpaca's OAuth `trading` scope ("Place, cancel or modify orders") and tastytrade's `trade` scope. **The scoped-token trend is not uniformly a trading-enabled trend**, and that distinction is the most useful thing this entry contributes.
- **NEGATIVE FINDING — no published participation terms:** no Fidelity-published developer or partner terms for joining Fidelity Access were located. `/security/how-fidelity-access-works` (403, 420 B), `/security/data-sharing-third-parties` (403, 417 B) and `/security/third-party-access` (403, 405 B) all returned the not-found signature, and a scan of all 3,208 sitemap URLs found nothing. **What a third party must do to participate in Fidelity Access is UNVERIFIED from primary sources.** (A particular network is commonly named for this in secondary sources; no Fidelity page states it and it is therefore **not** asserted here.)

---

### S1b-14 · Fidelity — the sanctioned third-party trading route: human authorized agent · retrieved 7 Sep 2026

Sources: **"Authorize Others to Access Your Accounts"**, `https://www.fidelity.com/customer-service/account-access-rights-overview` (HTTP 200, 38,728 bytes, ver. `341132.14.0`); **Account Authority** form, `576564.19.0 (09/25)`, `https://www.fidelity.com/bin-public/060_www_fidelity_com/documents/customer-service/ACCOUNT_AUTHORITY.pdf` (HTTP 200, 2,273,348 bytes).

**Verbatim quotes:**

The four authorization levels:

> "**Inquiry Access** — Learn how to grant inquiry access, which gives someone access to your account information and the right to make account inquiries.
> **Limited Authority** — Learn how to grant limited authority, which includes everything permitted with inquiry access, plus the ability to buy and sell securities, trade options, and incur margin debt.
> **Full Authority** — Learn how to grant full authority, which includes everything permitted with limited authority, plus the ability to make tax elections, withdraw and transfer funds, and initiate IRA rollovers, recharacterizations, and Roth IRA conversions for your account.
> **Power of Attorney (POA)** — Learn how to set up a POA. By naming a POA, you give another person full control over your account."

Account Authority form, purpose and limits:

> "Use this form to grant a third party some or all of the powers over your account(s) as described below, or to provide updated information about a third party who already holds authority over your account(s). Do NOT use this form for fiduciary accounts, workplace retirement plans, such as a 401(k), **or to add an individual who will be paid for the investment management of the account(s).**"

> "• Fill out a separate form for each authorized agent.
> • **This form cannot be used to add an individual who will be paid for the investment management of the account(s). To establish a Registered Investment Advisor relationship, please contact Fidelity Institutional Wealth Services at 800-735-3756.**"

> "• A Medallion signature guarantee is required to add Full Authority. If the Medallion signature guarantee is not provided, Limited Authority will be added to the account."

Authorized agent's own certifications — **Fidelity pushes the registration question onto the agent**:

> "• **Acknowledge that entities and individuals who provide investment advice to others may be subject to regulation by federal and state regulators and agree to be responsible for determining whether and what type of registration is required.**
> • **Certify that you will not be paid for the investment management related to the account(s). If you are looking to establish a Registered Investment Advisor relationship, please contact Fidelity Institutional Wealth Services.**"

- **What it establishes:** the only sanctioned route by which a third party may place trades in a Fidelity retail account is as a **human authorized agent** under a per-agent paper form (Full Authority requiring a Medallion signature guarantee), who must be an **individual**, must be **unpaid** for investment management, and must **determine its own registration status**. Any paid investment-management relationship is routed off the retail form entirely into an RIA relationship with Fidelity Institutional Wealth Services.
- **Q3:** **ADVERSE (moderate).** Fidelity's model of third-party involvement in trading is **delegated authority granted to a person**, evidenced on a form Fidelity holds — the opposite pole from "the member's own instruction transmitted by his own software". Fidelity offers no category for the latter.
- **Q2:** ADVERSE (weak-moderate) — note that Fidelity's form makes the *agent* responsible for determining its own registration, echoing Schwab Developer Program Agreement §3 ("Schwab has no obligation to verify whether the activities undertaken by you and/or your Applications require registration under Applicable Law"). **Two of the four brokers expressly disclaim any view on the third party's registration status.** Neither broker's approval is evidence of anything on Q1 or Q2.
- **Level 3.**
- **Application note:** The configuration grants nobody discretionary authority and would not use this route. Its relevance is as the *only* trading-capable third-party channel Fidelity recognises, and it is built entirely around a natural person holding delegated authority — the very framing the configuration's permission ladder is designed to avoid, and the framing that the shared context notes would arise only on the unshipped standing-execution track.

### Fidelity — the Q3 line, answered

**YES on attribution — but the question is largely moot at Fidelity, and the permission answer is NO.**

Attribution: Terms of Use, "Password Security and Notification" — "You are responsible for all activities that occur in connection with Your access credentials or password, including all instructions electronically transmitted to Fidelity … Fidelity shall not be under any duty to inquire as to the authority or propriety of any instructions given to Fidelity by You or by a person who has logged on using Your access credentials or password".

Permission: the same document, "Prohibited Uses and Termination of Access" — third-party software that facilitates trading is prohibited absent Fidelity's express written approval, and **"Any commercial entity that accesses Restricted Content … including to view, transact in or manage Fidelity customer accounts, is in violation of these Terms, even if instructed to do so by an authorized user."**

Moot: Fidelity has **no retail trading API** (S1b-12), so the configuration cannot use Fidelity as a broker in any event.

---

## Adverse register

| Authority | Threat 1–5 | Does the configuration distinguish it? |
|---|---|---|
| **tastytrade API TOS §2(3)(f)** — software used with the API must be "developed and owned by you" unless notified and given prior written approval | **4** | **No — it does not distinguish it; it is squarely caught.** A free, open-source runtime the member did not write and does not own is, on the plain words, software requiring prior written approval before the member may use it with the tastytrade API. The configuration's design (local install, member's own key, member's own tap) is irrelevant to this clause, which turns solely on *who developed and owns the software*. This is a per-member contractual breach exposure, not a securities-law exposure, but it is real and it is unavoidable by design changes short of tastytrade approval. |
| **tastytrade API TOS §2(3)(g) + "API Hub" definition** — third-party technology enabling the customer to communicate with the API, directly or indirectly, requires the provider to contract with tastytrade | **4** | **Only partly, and the distinction is untested.** The configuration can argue an API Hub is a *supplier's platform* — a hosted service the customer routes through — whereas the runtime is software the customer installs and runs on his own machine under his own key, with no supplier-operated system in the path. That reading is available on the words "platform" and "supplier's". But the definition's own breadth — "technology or any other system that, **directly or indirectly**, enables you to communicate with us" — is drafted to catch exactly the enabling function the runtime performs, and there is no carve-out for locally installed software. The document supplies no example either way. **Blunt:** this is the single clause in the track most likely to be read against the configuration, and it would put the obligation on the *distributor*, not the member. |
| **Alpaca Customer Agreement §10** — "I further agree not to allow any person to trade for My Account unless a trading authorization for that person has been received and approved by Alpaca" | **3** | **Partly.** The configuration's answer is that no *person* trades for the account: the member composes policy, the member taps, and the runtime is the member's own instrumentality transmitting the member's own order under the member's own key — the same posture as the member's own script, which §10 plainly does not reach. Alpaca's own Risks of Automated Trading disclosure (S1b-03) supports that reading by treating locally resident algorithms as the customer's own trading. **But** the configuration cannot point to any Alpaca text resolving whether third-party-authored software is "any person", and §16(c)'s POA requirement for granting "power and authority over My Account" sits alongside it. The Alpaca documents do not answer the question. |
| **Alpaca Connect "Terms of Access and Use"** — "To allow live trading for other users, the app needs to be approved by Alpaca"; commercial applications need written approval | **2** | **Yes, on the configuration as held constant.** The gate is triggered by an app trading **for other users** under a developer-held OAuth client. The configuration holds no company-level or app-level trading credential at all; every credential is the member's own, in the member's own vault. It therefore sits on the Trading API path, for which Alpaca states no registration, review or approval requirement. **The distinction is one design decision deep:** adopting a company-held OAuth client for convenience would trigger both the Compliance approval and, given the flat monthly membership fee, the commercial-application written approval. |
| **Alpaca Terms and Conditions, "Personal and Non-Commercial Usage"** — 30 days' advance written notice before making the Services available to others through "your own application" | **2** | **Probably, but the clause is ambiguous.** Each member connects personally with his own credentials, so no one is being given access through anyone else's application, and the company never mirrors or re-serves Alpaca Content. But "making the Services and Content available to others through your own application" is undefined and could be argued to reach distributing software that connects others to Alpaca. The obligation is only **notice**, not consent, so the cost of compliance is near zero — this is a housekeeping item, not a barrier. |
| **tastytrade API TOS §2(13)(b)** — no "distribute … or otherwise make available the API Connection or any rights to the API Connection" | **2** | **Yes.** The configuration distributes a client that speaks to the API under each member's own licence; it does not sublicense, resell or make available tastytrade's API Connection or any rights in it. Each member's right to the API Connection comes from that member's own API TOS with tastytrade, not from the distributor. |
| **Fidelity Terms of Use, "Prohibited Uses and Termination of Access"** — "Third-Party Access Tools" prohibited absent Fidelity's express written approval, expressly reaching tools "used or intended to be used to facilitate trading in a Fidelity account"; and a commercial entity accessing Restricted Content to "view, transact in or manage" accounts violates the Terms "**even if instructed to do so by an authorized user**" | **5** | **No — and this is the one clause in the track that the configuration's core design cannot reach.** Every distinguishing feature of the configuration — member-owned inputs, member-owned credentials, an explicit per-order act, no discretion granted — is an argument about *consent and attribution*. This clause is drafted to make consent irrelevant: it bites on the nature of the access mechanism and the commercial character of the entity, and forecloses the authorized-user argument in terms. **Two genuine limits on its reach, neither a distinction the configuration earns by design:** (i) its object is "the **Fidelity Websites**", and the configuration contemplates a broker's *published retail API* — which at Fidelity does not exist, so the clause and the configuration may never meet; and (ii) Fidelity is therefore **not an available broker for this configuration at all**, which makes this a warning about where industry drafting is heading rather than an operative obstacle. Its real weight is as evidence that a major broker has already written the "customer consent does not cure" position into live retail terms. |
| **Fidelity Customer Agreement, "Modification and Enforcement"** — giving a nonowner password access is a "de facto transferal" of the account, void without Fidelity's prior written approval | **3** | **Partly, and untested.** The configuration gives credentials to nobody: they are generated by the member, held in the member's own local keychain, and never leave his machine or reach any company system. Whether software the member installs and runs himself "gives a nonowner access" is unaddressed. But the argument is unnecessary at Fidelity (no retail API) and does not help against the Terms-of-Use clause above, which does not depend on this one. |
| **Fidelity Account Authority form** — the only sanctioned third-party trading route is a **human** agent, individual, unpaid, self-determining registration | **3** | **The configuration does not fit the category and does not need to.** It grants nobody discretionary authority, so it neither uses nor breaches this route. Adverse in a structural sense only: Fidelity's entire model of third-party trading involvement is *delegated authority granted to a natural person and evidenced on a form the broker holds*, with **no category at all** for "the customer's own instruction transmitted by the customer's own software". The absence of a category is itself the finding. |
| **Schwab ESA §14** — no software other than web-browser applications or those "formally approved by Schwab in writing" may access Schwab's systems or automate transmission of information to or from them | **3** | **Yes, but only by going through the gate, not around it.** Two readings are available (narrow: aimed at scraping the retail web channel, with the Trader API a separately licensed channel that P7's April 2026 Pricing Guide prices as a first-class retail order route; broad: "Schwab's computer systems" reaches any connection). **Both converge:** §14 carves out applications "formally approved by Schwab in writing", and the Developer Program Agreement's registration-and-review regime is that written approval. So the configuration distinguishes §14 only by *obtaining* Developer Program approval — which P7 §2 already establishes is required for any Application distributed to third parties, free or for a fee. The gate is real and is not avoidable by design. Note P7's Developer Program Agreement §3: approval is expressly **not** a view on whether registration under Applicable Law is required. |
| **tastytrade Customer Agreement §7 (1-Click Trading)** and Alpaca Risks of Automated Trading | — | **Not adverse — recorded for calibration.** Both show brokers treating *less* customer involvement than the configuration requires (one click with no confirmation screen; fully unattended local algorithms) as ordinary self-directed trading. Adverse only in the indirect sense that they undercut any argument that the configuration's per-order tap is *distinctive*: brokers do not appear to regard the presence or absence of a per-order human act as changing whose order it is. Whose order it is turns, in every instrument located, on **whose credentials carried it**. |

---

## Direct answers

Answered against the seven clause-categories in the brief. Alpaca and tastytrade are answered in full here; **Schwab's and Fidelity's dedicated Q3 answers appear at the end of their register sections above** ("Schwab — the Q3 line, answered"; "Fidelity — the Q3 line, answered"), and both are folded into the cross-broker synthesis that follows.

### 1. Are orders placed via the API the customer's own instructions?

**Alpaca — YES, expressly.** Customer Agreement §16(e)(7): "I represent that I am solely responsible for and have authorized any orders or instructions appearing in, originating from, or associated with My Account, My Account number, and PINs." Reinforced by §5(a) ("I am solely responsible for any and all orders placed in My Account and all orders entered by me or on My behalf are unsolicited and based on My own investment decisions") and §4 ("All transactions will be effected only on My order or the order of My authorized delegate").

**tastytrade — YES, expressly.** Customer Agreement §4: "Any orders communicated to tastytrade's platform with your user login information will be considered to have been sent and authorized by you." Reinforced by §5 ("solely responsible for all orders … associated with your unique customer identifiers, including … your unique user login credentials") and API TOS §2(8) ("You will be responsible for the accuracy and completeness of all information, data, instructions, orders, trades, or communications that you make via the API Connection").

**The common structure across both:** the attribution test in these contracts is **whose credentials carried the order**, not who or what composed it, and not whether a human reviewed it. Neither agreement anywhere conditions attribution on human authorship, human review, or the absence of automation.

### 2. Is automated or programmatic order submission permitted, restricted or prohibited?

**Alpaca — PERMITTED and expressly disclosed.** Risks of Automated Trading (v1.2020.02) is an operative risk disclosure incorporated into the Customer Agreement, describing "automated trading algorithms", "Set up the software, program the rules and watch it trade", and stating that "Alpaca initially will only support algorithms that run on your own computer, thus your trading system will reside on your computer – and not a server." Customer Agreement §33 records the customer's consent to "automated order entry and execution". No human-review requirement anywhere; the disclosure states "Alpaca's platform does not provide a readily available manual intervention process."

**tastytrade — PERMITTED, and within the Permitted Purpose by definition.** API TOS §13: "Permitted Purpose" means use "to facilitate your entry into Transactions with us in your personal or other account and such use so you can build out your own value-add front end platform **or algorithmic trading systems**." tastytrade additionally publishes and open-sources an MCP server for autonomous LLM agent trading. **Restricted only as to *which software*** — API TOS §2(3)(f)/(g).

### 3. Is human review or "manual entry" required before submission?

**No — in neither Alpaca's nor tastytrade's terms, and both affirmatively contemplate the opposite.** Nothing located in either broker's instruments requires a human to review or manually enter an order before submission. Positively to the contrary: Alpaca's Risks of Automated Trading contemplates unattended operation and warns that manual intervention is *not* readily available; tastytrade's Customer Agreement §7 offers a native 1-click feature that submits "without the use or display of an in-platform order confirmation" and "without any platform prompts or messaging to review or confirm the order before it is sent to the market". tastytrade's "dry-run-first" convention is documentation and optional-tool behaviour, **not** a term.

### 4. Is the third party treated as an agent of the customer?

**Neither agreement says so, and both avoid the characterization.** The closest either comes:
- Alpaca §5(a) refers to orders entered "on My behalf … based on … the investment decision of My duly authorized representative or agent", and §22 to "my authorized agent" — but these describe a *human* delegate, and §16(c) channels the grant of "power and authority over My Account" into a Limited POA. Alpaca does not say whether software is such an agent. Notably, §4 makes **Alpaca** the customer's agent ("I appoint You as My agent for the purpose of carrying out My directions") — the only express agency in the document runs to the broker, not to any third-party software.
- tastytrade's Customer Agreement describes the third-party API connector as "any third party who provides services **to you directly**", i.e. the customer's own counterparty rather than tastytrade's — which points toward, without stating, an agent-of-the-customer characterization. API TOS §2(12) expressly negates any agency toward *tastytrade* ("you will not hold yourself out as being part of, or representing, TASTYTRADE, INC.").

**This is a genuine gap, not a finding either way.** No located clause in this track answers whether locally installed software transmitting under the customer's own credentials is an agent of the customer. It is consistent with P7's already-documented negative finding that no located SEC source addresses whose credentials a vendor uses.

### 5. What does the broker require of the third-party developer?

| Broker | Registration | Review / approval | Indemnity | Insurance | Entity type |
|---|---|---|---|---|---|
| **Alpaca — Trading API, member's own key** | **None located** | **None located** | Customer indemnifies Alpaca for third-party access he authorises (Cust. Agmt §33) — runs to the *customer*, not the developer | None located | None |
| **Alpaca — OAuth / Connect** | Yes — submit app via Alpaca Connect | **Yes — Alpaca Compliance approval** to allow live trading for other users; **written approval** for commercial apps | Not located in public terms | Not located | Expressly open to "non-registered firms, developers and fintech companies" |
| **Alpaca — Broker API** | Yes | Yes (sales/onboarding) | Not located | Not located | Use cases stated as "Broker dealer (fully-disclosed, omnibus)" and "Registered Investment Advisor (RIA)" |
| **tastytrade** | No developer registration programme located; the API licence runs to the **customer** | **Yes, indirectly and materially** — API TOS §2(3)(f) prior written approval for software not developed and owned by the customer; §2(3)(g) API Hub provider must enter a tastytrade agreement | Customer responsible for "all acts and omissions of your end users" (§2(7)) | Not located | Not specified — but §2(3)(b) requires the API client to contract "on your own behalf and not on behalf of any other person" |

### 6. Trading authorization / discretion / POA / third-party access / credential sharing / screen scraping / aggregators

- **Trading authorization:** Alpaca Cust. Agmt §10 — no person may trade for the account without an Alpaca-approved trading authorization. tastytrade — no equivalent located in the Customer Agreement.
- **Discretion:** Alpaca §5(a)(5) — Alpaca does not "make discretionary trades". Neither broker's terms characterise third-party software as exercising discretion; neither addresses it.
- **Power of attorney:** Alpaca §16(c) — a Limited Power of Attorney and Hold Harmless Agreement is required "In the event that I wish to grant a third-party power and authority over My Account". **No POA requirement is attached to §4's separate sentence about a third party placing transactions**, and the agreement does not reconcile the two. tastytrade — no POA requirement located for API/third-party software.
- **Third-party access:** expressly contemplated by both. Alpaca §4 ("My grant of access to My Account to any third party to access information or place transactions in My Account is solely at My risk") and §33 (indemnity for authorised third-party access). tastytrade — "tastytrade allows third party service providers to connect to the Firm's Open API".
- **Credential sharing:** **tastytrade expressly contemplates it** — "if you give your tastytrade username and password to a third party service provider that connects to the Firm's Open API…", with a PII warning and no prohibition; the only credential-sharing prohibition located is §4(i), giving credentials to **a minor**. Alpaca requires the customer to keep PINs confidential (§16(a)) and makes him responsible for all orders originating from them (§16(e)(7)), but does not in terms prohibit sharing with a third party — instead it allocates the risk to him (§4, §33).
- **Screen scraping / aggregators / robots / spiders:** **no clause located in any Alpaca or tastytrade instrument read.** Alpaca's Terms and Conditions restrict copying and redistribution of Content and prohibit interference with the Service, but contain no anti-scraping, anti-robot or aggregator clause. This is a documented negative finding, not an inference — see Negative findings.

### 7. Registered broker-dealer or investment adviser requirement

**No such requirement in either Alpaca's or tastytrade's terms for the paths at issue**, and Alpaca states the opposite for its third-party app programme: "Alpaca Connect allows **non-registered firms**, developers and fintech companies to build trading apps on Alpaca's platform." The only place registration status appears is Alpaca's **Broker API** use-case list ("Broker dealer (fully-disclosed, omnibus)", "Registered Investment Advisor (RIA)"), which is a description of who typically uses that product, not a stated eligibility condition. tastytrade's API TOS conditions access on being a **Client** with a brokerage account (§2(2)), not on any registration status.

### Alpaca Broker API vs Trading API — which side does the configuration fall on, as the terms are written?

**The Trading API side.** See S1b-04 Application note for the full reasoning and the two qualifications. In one line: Alpaca's own boundary is drawn by **whose accounts and whose users** — Broker API is for "brokerage services for your end users" and "any app where you want to own your users"; OAuth/Connect is for apps that "manage your end-user's Alpaca brokerage account on their behalf" under a developer-held client credential; the Trading API is "Built for retail, algorithmic and proprietary traders" and is where Alpaca sends anyone building "your own trading bots and algos". A runtime installed on the member's own machine, authenticating with the member's own key, opening no accounts, holding no funds or securities and carrying nobody, has none of the Broker API's defining facts and none of the OAuth path's defining fact (a company-held client credential reaching other people's accounts). **The unresolved point is not which API path it uses — it is that Alpaca's documents address the account holder who writes his own bot and are silent on the third party who distributes the bot the account holder runs.**

---

# Cross-broker synthesis — the structural finding

The four brokers differ sharply on policy and not at all on structure. **Every one of them answers two separate questions separately, and the answers do not depend on each other:**

**Question A — attribution: whose order is it?** All four answer the same way, in deeming language, and the test is uniformly **whose credentials carried the order** — never who or what composed it, never whether a human reviewed it, never whether the software was automated.

- Schwab ESA §12: "any orders so received by Schwab will be **deemed to have been received from you**"; Account Agreement §26: "will be **considered to have been sent and authorized by you**".
- tastytrade Customer Agreement §4: "Any orders communicated to tastytrade's platform with your user login information will be **considered to have been sent and authorized by you**."
- Alpaca Customer Agreement §16(e)(7): "I represent that I am **solely responsible for and have authorized** any orders or instructions … originating from … My PINs."
- Fidelity Terms of Use: "You are responsible for **all instructions electronically transmitted to Fidelity** … Fidelity shall not be under any duty to inquire as to the authority or propriety of any instructions given to Fidelity by You **or by a person who has logged on using Your access credentials**."

**This is a strong and genuinely new result for Q3.** P7 recorded that no located SEC letter, release or staff guidance addresses **whose credentials** a software vendor uses. The brokers' own terms do address it, unanimously, and they resolve it by credential. On the configuration's facts — trade-capable credentials existing only in the member's local vault, per member, with no company-level or app-level credential anywhere — all four brokers would treat the resulting order as the member's own instruction. Four independent major-broker instruments, drafted separately, converging on one test is worth more than any one of them.

**Question B — permission: may that software connect at all?** Here they diverge completely, and three of the four impose a gate:

| Broker | Gate on third-party software |
|---|---|
| **Alpaca** (own-key Trading API) | **None located.** Locally-run algorithms are an expressly disclosed, ordinary mode of use. |
| **Alpaca** (OAuth/Connect, other users' accounts) | Alpaca Compliance approval; written approval for commercial apps. Open to "non-registered firms". |
| **tastytrade** | Prior written approval for software not "developed and owned by you" (§2(3)(f)); API Hub providers must contract with tastytrade (§2(3)(g)). |
| **Schwab** | Only web browsers or applications "formally approved by Schwab in writing" (ESA §14) — satisfied via Developer Program registration and review. |
| **Fidelity** | Prohibited absent express written approval, **"even if instructed to do so by an authorized user"** — and no retail API exists in any case. |

**Three consequences worth carrying forward:**

1. **The configuration's design work all lands on Question A, and Question A was never seriously in doubt at any of these brokers.** Member-owned inputs, the per-order approval surface, the permission ladder, the journal — these make the order unmistakably the member's own. But no broker's terms condition attribution on any of it. The one design feature that actually does the work under every instrument read is the narrowest and least celebrated one: **credentials live only with the member**. That single fact, not the approval surface, is what makes all four attribution clauses bite in the configuration's favour.

2. **Question B is where the exposure sits, and no amount of member-side consent architecture reaches it.** Fidelity says so explicitly; tastytrade's §2(3)(f) turns purely on who *developed and owns* the software; Schwab's §14 turns purely on whether Schwab *approved* it. None of these clauses can be satisfied by making the member more clearly in control. They are satisfied only by the broker's own approval, or by choosing a broker that does not require it. **On the four brokers in this track, that means Alpaca's own-key Trading API path is the only one with no located gate** — and even there, the terms address the account holder writing his own bot and are silent on a third party distributing the bot he runs.

3. **Broker approval is worthless on Q1 and Q2, and two brokers say so.** Schwab Developer Program Agreement §3 (P7): "Schwab has no obligation to verify whether the activities undertaken by you and/or your Applications require registration under Applicable Law." Fidelity's Account Authority form makes the agent "responsible for determining whether and what type of registration is required". Nothing in this track should be read as a broker blessing the configuration's regulatory status; the brokers have expressly declined to give one. Conversely, **Alpaca's "Alpaca Connect allows non-registered firms, developers and fintech companies to build trading apps on Alpaca's platform" is a market-practice datapoint on Q2, not a legal conclusion**, and Alpaca does not purport to make it one.

**The honest gap that survives all four.** Every instrument read addresses either the *account holder* (what he may do, what he is responsible for) or a *delegated human agent* (POA, trading authorization, advisor authority). **Not one of the eleven instruments read has a category for the third party who writes and distributes software that the account holder installs and runs himself under his own key.** tastytrade's "API Hub" comes closest and is ambiguous on its face (◇4). This is the broker-side counterpart to P7's already-documented finding that no SEC authority addresses whose credentials a vendor uses — and it is the same hole, seen from the other side.

---

# Negative findings

Each documents where it looked, with endpoints and counts. No absence below is inferred from silence.

**N1 · No anti-scraping / robots / spiders / aggregator vocabulary in Alpaca's or tastytrade's instruments.** Case-insensitive counts run directly by this analyst over the extracted text of the Alpaca Customer Agreement (`alp_cust.txt`), Alpaca Terms and Conditions (`alp_tc.txt`), tastytrade Customer Agreement (`tt_cust.txt`) and tastytrade API TOS (`tt_api.txt`): `scrap` = 0/0/0/0; `spider` = 0/0/0/0; `robot` = 0/0/0/0; `crawl` = 0/0/0/0; `screen scrap` = 0/0/0/0; `automated tool` = 0/0/0/0. `aggregat` returned 1 hit in the Alpaca Customer Agreement ("AGGREGATE BALANCE MAINTAINED IN THE PROGRAM", an FDIC-sweep term) and 2 in the tastytrade Customer Agreement (one referring to "any Exchange, aggregator, the Clearing Firm, or clearing corporation" in a force-majeure list; one "non-aggregated basis" in margin interest). **No data-aggregator or anti-scraping clause exists in any Alpaca or tastytrade instrument read.** By contrast Schwab and Fidelity both address the ground — Schwab through ESA §12's "entities that aggregate account information or website content" and §14, Fidelity through "Third-Party Access Tools".

**N2 · No robots/spiders/crawler/scraping vocabulary, and no API clause, in Schwab's retail client agreements.** Counts re-run directly by this analyst on the live HTML: standalone Electronic Services Agreement (38,506 chars extracted) and Schwab Brokerage Account Agreement (227,204 chars extracted) — `robot` = 0, `spider` = 0, `crawl` = 0, `scrap` = 0, `application programming interface` = 0 in each. **Schwab's retail agreements contain no API clause whatsoever**; the API is governed entirely on the developer side.

**N3 · Same for Fidelity's Terms of Use.** `grep -oiE "spider|robot|crawler|scrap[a-z]*|data mining|harvest"` over the extracted Terms of Use text: **no matches**; independently re-confirmed through a second retrieval channel (spider: no; robot: no; crawler: no; scrape/screen scraping: no). Fidelity has **replaced** the traditional vocabulary with the functionally broader "Third-Party Access Tools". "Screen scraping" appears only on customer-education pages describing conduct Fidelity is phasing out.

**N4 · No human-review or manual-entry requirement at any of the four brokers.** Searched: Alpaca Customer Agreement + T&C + Risks of Automated Trading; tastytrade Customer Agreement + API TOS; Schwab ESA + both Account Agreements; Fidelity Terms of Use + Fidelity Account Customer Agreement (`grep -in "manual"` over the Customer Agreement → **no matches**; `grep -in "manual\|human\|keystroke\|by hand"` over the Terms of Use → **no matches**). **Not one of the eleven instruments read requires a human to review or manually enter an order before submission.** Three affirmatively contemplate the opposite: Schwab ESA §11 ("Orders May Not Be Manually Reviewed"), tastytrade Customer Agreement §7 (1-click, no confirmation screen), Alpaca Risks of Automated Trading ("does not provide a readily available manual intervention process"). tastytrade's "dry-run-first" is documentation and optional-tool behaviour, not a term.

**N5 · No broker of the four requires a third-party developer to be a registered broker-dealer or investment adviser.** Alpaca states the opposite for its third-party app programme ("Alpaca Connect allows **non-registered firms**, developers and fintech companies to build trading apps on Alpaca's platform"). tastytrade conditions API access on being a **Client** (§2(2)), not on registration. Schwab's Developer Program Agreement §3 expressly disclaims any obligation to verify whether registration is required (P7). Fidelity's Account Authority form makes the **agent** "responsible for determining whether and what type of registration is required". **No broker approval located in this track is evidence of registration status, and two brokers say so in terms.**

**N6 · No Fidelity developer portal or open retail trading API.** Full documentation at S1b-12: five NXDOMAIN hostnames; `/developer` and `/developers` returning the validated 243-byte not-found signature and `/api` a 404; one irrelevant hit across 3,208 sitemap URLs; no such path in robots.txt; zero occurrences of "API" in either governing document.

**N7 · No published Fidelity Access third-party participation terms.** `/security/how-fidelity-access-works` (403, 420 B), `/security/data-sharing-third-parties` (403, 417 B), `/security/third-party-access` (403, 405 B) — all the not-found signature; 3,208-URL sitemap scan returned nothing. Marked UNVERIFIED.

**N8 · No standalone Alpaca Connect developer agreement located.** The Connect "Terms of Access and Use" bullets say "You must read the terms and register in order to connect and use Alpaca's APIs" but do not link a distinct instrument; `app.alpaca.markets/connect` returned HTTP 200 with a 15,237-byte SPA shell requiring login. **The "terms" a Connect developer accepts were not located as a standalone document** and may be presented only inside the authenticated submission flow. Marked UNVERIFIED; a browser route with an authenticated Alpaca account would be needed.

**N9 · Not attempted / out of scope.** E*TRADE and Interactive Brokers (assigned to another agent). Fidelity's institutional/Wealthscape APIs (both endpoints returned identical 9,358-byte Akamai "Page Unavailable" bodies — UNVERIFIED, and not a retail channel). Fidelity `/cash-management/full-view/terms-of-use` was retrieved (HTTP 200, 45,028 bytes) but **not analysed**; Full View is Fidelity's own inbound aggregation service and may contain further relevant terms — flagged as an open thread. Login-gated Fidelity surfaces (`digital.fidelity.com/ftgw/digital/dae/fidelityAccess`, `.../security/dashboard/view`) not fetched.

---

# Search log

| # | Source / query | Endpoint | Date | Result / access note |
|---|---|---|---|---|
| 1 | Alpaca disclosures index | `alpaca.markets/disclosures` | 7 Sep 26 | 200, 112,839 B — full document library enumerated |
| 2 | Alpaca legal index | `alpaca.markets/legal` | 7 Sep 26 | 200, 81,041 B |
| 3 | Alpaca Customer Agreement (direct host) | `files.alpaca.markets/disclosures/library/AlpacaCustomerAgreement.pdf` | 7 Sep 26 | **403**, 263 B — direct host rejects curl |
| 4 | Alpaca Customer Agreement (S3 origin) | `s3.amazonaws.com/files.alpaca.markets/disclosures/library/AcctAppMarginAndCustAgmt.pdf` | 7 Sep 26 | **200**, 478,094 B ✅ — the working route; version V26.2026.07 |
| 5 | Alpaca Terms and Conditions | `…/library/TermsAndConditions.pdf` | 7 Sep 26 | 200, 27,092 B ✅ (undated) |
| 6 | Alpaca Risks of Automated Trading | `…/library/RisksAutoTrading.pdf` | 7 Sep 26 | 200, 27,984 B ✅ (v1.2020.02) |
| 7 | Alpaca Conditional Orders | `…/library/CondOrders.pdf` | 7 Sep 26 | 200, 24,382 B ✅ |
| 8 | Alpaca Broker API Exhibit B | `…/library/BrokerAPIExhibitB.pdf` | 7 Sep 26 | 200, 122,724 B — fee schedule only, not the boundary |
| 9 | Alpaca docs (wrong slug) | `docs.alpaca.markets/docs/about-trading-api` | 7 Sep 26 | 404, 360,190 B (SPA shell) |
| 10 | Alpaca About Broker API | `docs.alpaca.markets/docs/about-broker-api` | 7 Sep 26 | 200, 462,106 B ✅ — body extracted from embedded page JSON |
| 11 | Alpaca Trading API | `docs.alpaca.markets/docs/trading-api` | 7 Sep 26 | 200, 466,260 B ✅ |
| 12 | Alpaca OAuth2 + Trading API | `docs.alpaca.markets/docs/using-oauth2-and-trading-api` | 7 Sep 26 | 200, 500,684 B ✅ — scopes table verbatim |
| 13 | Alpaca Registering Your App | `docs.alpaca.markets/us/docs/registering-your-app` | 7 Sep 26 | 200, 466,876 B ✅ |
| 14 | Alpaca About Connect API | `docs.alpaca.markets/us/docs/about-connect-api` | 7 Sep 26 | 200, 476,184 B ✅ — "non-registered firms"; Terms of Access and Use |
| 15 | Alpaca Connect dashboard | `app.alpaca.markets/connect` | 7 Sep 26 | 200, 15,237 B — SPA shell, login required; **N8 UNVERIFIED** |
| 16 | tastytrade developer home | `developer.tastytrade.com` | 7 Sep 26 | 200, 29,681 B ✅ — surfaced the API TOS link |
| 17 | tastytrade legal (guess) | `tastytrade.com/legal` | 7 Sep 26 | 404, 326,956 B |
| 18 | tastytrade disclosures | `tastytrade.com/disclosures/` | 7 Sep 26 | 200, 348,827 B |
| 19 | **tastytrade API Terms of Service** | `assets.tastyworks.com/production/documents/USA/open_api_terms_and_conditions.pdf` | 7 Sep 26 | **200**, 209,039 B ✅ — 17 May 2023 |
| 20 | **tastytrade Customer Agreement** | `assets.tastyworks.com/production/documents/broker_customer_agreement.pdf` | 7 Sep 26 | **200**, 228,158 B ✅ — doc 20250811 |
| 21 | tastytrade MCP docs (bad path) | `developer.tastytrade.com/docs/sdks-and-tools/mcp-server/index.md` | 7 Sep 26 | 404, 587 B (S3 NoSuchKey) |
| 22 | tastytrade MCP docs | `developer.tastytrade.com/docs/sdks-and-tools/mcp-server.md` | 7 Sep 26 | 200 ✅ — dry-run gate |
| 23 | tastytrade llms.txt | `developer.tastytrade.com/llms.txt` | 7 Sep 26 | 200 ✅ (note: internal links emit `localhost:3000` — a build defect; real paths resolve on the public host) |
| 24 | tastytrade OAuth2 doc | `developer.tastytrade.com/docs/authentication/oauth2.md` | 7 Sep 26 | 200 ✅ — self-service registration, scopes `read`/`trade`/`openid` |
| 25 | tastytrade accounts concept | `developer.tastytrade.com/docs/concepts/accounts-and-customers.md` | 7 Sep 26 | 200 ✅ |
| 26 | Alpaca OAuth approval (URL discovery only) | WebSearch, domains restricted to alpaca.markets | 7 Sep 26 | Used **only** to locate URLs; all propositions then verified against Alpaca's own pages (rows 13–14) |
| 27 | Schwab legal index | `schwab.com/legal` | 7 Sep 26 | **404**, 359,783 B |
| 28 | Schwab terms-of-use (P7's gap) | `schwab.com/legal/terms-of-use` | 7 Sep 26 | **404**, 359,809 B |
| 29 | Schwab terms-of-use (alt) | `schwab.com/terms-of-use` | 7 Sep 26 | **404**, 359,797 B |
| 30 | Schwab account-agreements (guess) | `schwab.com/legal/account-agreements` | 7 Sep 26 | 404, 359,821 B |
| 31 | Schwab ESA (guessed slug) | `schwab.com/legal/schwab-electronic-services-agreement` | 7 Sep 26 | 404, 359,857 B |
| 32 | Schwab public/file paths | `schwab.com/public/file/P-642150/`, `/P-5539932/` | 7 Sep 26 | 404 both — **the `public/file` scheme appears retired** |
| 33 | **Wayback availability, P7's 404 URL** | `archive.org/wayback/available?url=schwab.com/legal/terms-of-use` | 7 Sep 26 | **`{"archived_snapshots": {}}`** — never archived; **the URL appears never to have existed** |
| 34 | Wayback CDX | `schwab.com/legal*` | 7 Sep 26 | Only `alexa-terms-of-use` (2020) matched "terms" — no general site terms-of-use |
| 35 | **Schwab Brokerage Account Agreement** | `schwab.com/legal/schwab-brokerage-account-agreement` | 7 Sep 26 | **200**, 734,641 B ✅ — July 2026 `(0726-3HXA)`; **independently re-fetched and verified by this analyst** |
| 36 | **Schwab One® Account Agreement** | `schwab.com/legal/schwab-one-account-agreement` | 7 Sep 26 | **200**, 830,812 B ✅ — July 2026 |
| 37 | **Schwab Electronic Services Agreement (standalone)** | `schwab.com/legal/electronic-services-agreement` | 7 Sep 26 | **200**, 392,300 B ✅ — rev. 07/26; **independently re-fetched and verified** |
| 38 | Schwab amendment notice | `schwab.com/legal/account-agreement-amendment` | 7 Sep 26 | 200, 345,538 B ✅ — 1 Jul 2026; does not touch §§11/12/14 |
| 39 | Schwab account agreements index | `schwab.com/accountagreements` | 7 Sep 26 | 200, 337,608 B ✅ |
| 40 | Schwab developer portal (all legal paths) | `developer.schwab.com/{legal-notices,terms-of-use,terms,legal,developer-program-agreement,products/trader-api--individual}` | 7 Sep 26 | 200 each, **identical 55,033-byte SPA shell**, no server-rendered content — Angular router-guarded |
| 41 | Schwab dev portal token | `devportal-token.schwab.com/api/v1/Token` | 7 Sep 26 | 400 without `Schwab-Resource-Version`; **200**, 515 B with it |
| 42 | Schwab product access mgmt | `…/AnonymousUser/api/v1/Product/product-access-management/trader-api--individual` | 7 Sep 26 | 200, 248 B → `"termsAndConditionsCmsAssetIds":["trader-api-terms-and-conditions"]` |
| 43 | **Schwab Developer Program Agreement asset** | `contentdelivery.schwab.com/api/content/rtcontent/asset/trader-api-terms-and-conditions` | 7 Sep 26 09:54:56Z | **200**, 23,226 B ✅ — header "May 2023"; CMS `published_date 2023-05-24`, no `changed` value. **Version status established; body not re-quoted per brief.** |
| 44 | Schwab dev portal site terms | `…/asset/dev-portal-user-registration-terms-and-conditions` | 7 Sep 26 | 200, 16,840 B — distinct instrument, "Last Updated February 14, 2023"; **not** the Developer Program Agreement |
| 45 | Schwab find-products | `…/api/v1/Product/find-products` | 7 Sep 26 | **401** — authenticated surface unexamined; recorded as a limit on row 43 |
| 46 | Fidelity, minimal headers | `/security/fidelity-access`, `/terms-of-use`, `/customer-service/customer-agreement`, `/security/overview`, `/developer` | 7 Sep 26 | **403** on all (390–420 B) — Akamai gates HTML against a plain UA |
| 47 | Fidelity DNS probes | `developer.` / `developers.` / `api.` / `apis.` / `devportal.fidelity.com` | 7 Sep 26 | **NXDOMAIN ×5** |
| 48 | Fidelity, full Chrome header set | `/terms-of-use` | 7 Sep 26 | **200**, 47,039 B ✅ — Last Updated 1 Jul 2026 |
| 49 | **Fidelity Account Customer Agreement** | `/bin-public/…/Updated-Fidelity-Account-Customer-Agreement.pdf` | 7 Sep 26 | **200**, 160,370 B ✅ — `FA-CUSTOM-0626`. **Technique: Akamai gates HTML but serves `/bin-public/` PDFs to a plain browser UA** |
| 50 | Fidelity Access data security | `/security/fidelity-access-data-security` (redirect target) | 7 Sep 26 | 200, 39,423 B ✅ |
| 51 | Fidelity third-party app protection | `/security/third-party-app-protection` | 7 Sep 26 | 200, 40,158 B ✅ |
| 52 | Fidelity account access rights | `/customer-service/account-access-rights-overview` | 7 Sep 26 | 200, 38,728 B ✅ |
| 53 | Fidelity Account Authority form | `/bin-public/…/ACCOUNT_AUTHORITY.pdf` | 7 Sep 26 | 200, 2,273,348 B ✅ — `576564.19.0 (09/25)` |
| 54 | Fidelity control probes | `/zzz-this-page-does-not-exist-12345`; `/security/overview` | 7 Sep 26 | 403/**243 B** (not-found signature); 200/39,126 B — **discriminator established before any absence conclusion** |
| 55 | Fidelity developer paths | `/developer`, `/developers`, `/api` | 7 Sep 26 | 403/243 B, 403/243 B, 404/85 B — **do not exist** |
| 56 | Fidelity Access partner-terms probes | `/security/how-fidelity-access-works`, `/security/data-sharing-third-parties`, `/security/third-party-access` | 7 Sep 26 | 403 / 420 B, 417 B, 405 B — do not exist → **N7 UNVERIFIED** |
| 57 | Fidelity sitemap | `/sitemap.xml` → `/sitemap1.xml`, `/sitemap2.xml` | 7 Sep 26 | 200 — **3,208 URLs**; `develop\|/api\|partner\|integrat` → 1 irrelevant hit |
| 58 | Fidelity robots.txt | `/robots.txt` | 7 Sep 26 | 200, 2,478 B — ~200 disallowed paths, no developer/API path. *(First attempt 403/380 B with reduced headers, then 200 on retry — Akamai gating is rate- and header-sensitive; a single 403 is never sufficient evidence of non-existence.)* |
| 59 | Fidelity institutional | `institutional.fidelity.com/app/item/RD_13569_46171/…`, `/advisors/services/technology/apis` | 7 Sep 26 | 200 but **identical 9,358 B "Page Unavailable"** error bodies → **UNVERIFIED**, excluded |
| 60 | **This analyst's own Fidelity re-verification** | `fidelity.com/terms-of-use` (+ cookie-jar and warm-up retry) | 7 Sep 26 | **403**, 390 B on both target and previously-good control — **rate-limited after the earlier crawl**; resolved by cross-checking through a second retrieval channel (row 61) |
| 61 | **Independent cross-check of Fidelity ToU** | second retrieval channel, same URL | 7 Sep 26 | ✅ Confirmed verbatim: "Last Updated: July 1, 2026"; "Third-Party Access Tools"; "Restricted Content"; the "even if instructed to do so by an authorized user" sentence; "Do not share Your access credentials…"; and spider/robot/crawler/scrape all absent. **Also re-asserted the fabricated "Section 14" — see ◇/method note.** |
| 62 | Alpaca/tastytrade zero-count verification | local `grep -ic` over all four extracted texts | 7 Sep 26 | Counts reported at N1 — run directly by this analyst |
| 63 | Schwab zero-count verification | local `grep` over live ESA + Brokerage Account Agreement HTML | 7 Sep 26 | Counts reported at N2 — run directly by this analyst |

---

# ◇ list — resting on secondary or single-channel confirmation, flagged for primary verification

| # | Item | Status | What would close it |
|---|---|---|---|
| ◇1 | **Alpaca Terms and Conditions has no date or version stamp anywhere.** | Text is primary and complete; **the date is unknown**. | Alpaca confirmation of effective date, or a Wayback diff series to bound when it last changed. |
| ◇2 | **Alpaca Risks of Automated Trading is stamped v1.2020.02** and says Alpaca "**initially** will only support algorithms that run on your own computer". | Primary and current-linked, but the word "initially" makes it a launch-era statement now six years old. | Whether Alpaca still restricts to locally-run algorithms, or whether the disclosure is simply stale. Material, because this is one of the strongest support items in the track. |
| ◇3 | **No standalone Alpaca Connect developer agreement located** (N8). | UNVERIFIED — `app.alpaca.markets/connect` is a login-walled SPA (200, 15,237 B). | A browser route with an authenticated Alpaca account. **Requested of the coordinator.** |
| ◇4 | **Whether tastytrade's "API Hub" definition reaches locally installed third-party software.** | The definition is quoted verbatim and is primary; its *application* is genuinely ambiguous and unresolved on the face of the document. | Nothing in the public record resolves it. Would require tastytrade's own position. **This is the sharpest open question in the track.** |
| ◇5 | **Schwab Developer Program Agreement version status.** | Established from the CMS asset and its `published_date` metadata — primary, but with two recorded caveats: zero Wayback captures of the asset endpoint (a silent body edit would be invisible), and `find-products` returned 401 so the authenticated surface is unexamined. | A Wayback capture series of the asset endpoint, or an authenticated developer-portal view. |
| ◇6 | **Fidelity Terms of Use — retrieval channel.** | Text is primary and **doubly retrieved** (raw-HTML extraction plus an independent second channel agreeing verbatim on every quoted sentence). This analyst's own third re-fetch was Akamai-403'd. | Not a substantive doubt; recorded for provenance honesty. A clean direct re-fetch from an unthrottled IP would fully close it. |
| ◇7 | **Fidelity Access is read-only as to trading.** | Rests on the **absence** of any trading reference across the whole Fidelity Access corpus — strong, but an inference, not a quoted denial. | A Fidelity statement of Fidelity Access scopes, or the (unpublished, N7) third-party participation terms. |
| ◇8 | **Fidelity Access third-party participation terms** (N7) and **Fidelity institutional/Wealthscape APIs** (N9). | UNVERIFIED — not published / Akamai error pages. | A browser route, or Fidelity partner documentation. Institutional APIs are out of scope for a retail configuration in any event. |
| ◇9 | **Fidelity `/cash-management/full-view/terms-of-use`** retrieved (200, 45,028 B) but **not analysed**. | Open thread. | Read it — Full View is Fidelity's own inbound aggregation service and may carry further third-party-access terms. |

**Method note carried into the ◇ list, because it nearly produced a fabricated pin-cite.** An automated summarising fetch asserted — twice, in two separate sessions, unprompted — that Fidelity's "Prohibited Uses and Termination of Access" is "**Section 14**". The Terms of Use headings are **unnumbered**; verification against the raw HTML in the first instance, and this analyst's deliberate re-probe in the second, both refute it. Every quotation in this register was taken from raw HTML or PDF, extracted locally. **Where a numbered pin-cite appears in this document it came from the document's own numbering; Fidelity's is cited by heading only, and Alpaca's and Fidelity's agreements both use named headings rather than numbered sections in places, which is noted at each entry.**


---

# S1c · TRACK 1c — E*TRADE API Developer License Agreement: which version governs, when §4.9 went live, what §1.19 reaches, and whether a Vendor path exists

**Commission P8. Narrow follow-up to S1a Part B. Bears on Q3 (customer instruction) primarily, Q2 (broker characterization) secondarily.**
**All retrieval dates 7 September 2026. All quotes verbatim from documents fetched on that date.**
**No E*TRADE account was used. Nothing was logged into, applied for or submitted. Every endpoint below was fetched unauthenticated.**

---

## Naming convention carried from S1a

- **Copy A** = `https://developer.etrade.com/support/terms-of-use` — the developer-portal page. Live, HTTP 200, 19,464 B, **6,897 words of agreement text**. Titled "API DEVELOPER LICENSE AGREEMENT". No form number, no printed effective date. Contains §1.19, §4.8, §4.9, §7.5.
- **Copy B** = `https://us.etrade.com/l/f/agreement-library/api-developer-licensing-agreement` — the copy in E*TRADE's customer-facing Agreement Library. Live, HTTP 200, **6,274 words of agreement text**, form number `0923-APIDEVLA-E68693`. Lacks §1.19, §4.8, §4.9, §7.5.
- **The 2019–2026 portal document** = the "E*TRADE API Non-Commercial License", ~2,459 words, which occupied Copy A's URL for its **entire archived history** until at least 9 May 2026. This is a *third* document and S1a's framing understated its significance — see C-04.

Word counts differ from S1a's (7,004 / 6,337) because S1a counted page chrome as well as agreement text. The section-level findings are identical and were independently re-verified here.

**Two conventions, stated so no quote is mistaken for an alteration.**
1. **Quotation marks.** E*TRADE serves curly double quotation marks throughout (e.g. `Power of Attorney (“POA”)`, `the Morgan Stanley Smith Barney LLC (“Company”)`). Inside the block quotes below these are rendered as **single** quotation marks, so that they nest legibly within the quoted passage. **No other character is altered.** Every quote in this file was mechanically verified against the fetched source text after drafting; the sole systematic difference is this quotation-mark rendering. Em-dashes, the non-breaking hyphen in "rules‑based", and E*TRADE's own typographical errors ("Vender Use Developer", "the the Company's websites") are reproduced as served.
2. **Bold.** Where bold appears inside a block quote it was added for locating only; **every source passage is unemphasised**.

**One numbering trap, recorded to prevent a misreading.** Both copies contain a **§6.3 headed "Unauthorized Use"**. That is *not* the section at issue. The section absent from Copy B is **§7.5, "Unauthorized Use; No Company Liability"**. Verified by distinctive-string count: `No Company Liability` — Copy A **1**, Copy B **0**; `social engineering` — Copy A **1**, Copy B **0**; and §7 runs 7.1, 7.2, 7.3, 7.4 in Copy B and 7.1 → 7.5 in Copy A.

---

# Register entries

### C-01 · E*TRADE API Developer License Agreement §11.8 "Amendment; Waiver" — **the clause that answers the version question, and it is identical in both copies** · Copy A `https://developer.etrade.com/support/terms-of-use`; Copy B `https://us.etrade.com/l/f/agreement-library/api-developer-licensing-agreement` · retrieved 7 September 2026

- **Type:** published terms (developer agreement), publicly readable without login
- **Date / status:** Live in both locations. Neither copy bears an effective date; both self-date to "the date of your online acknowledgment". §11.8 is **byte-identical in Copy A and Copy B** — verified by normalised sentence-level diff, which returned no difference at this section.

**Verbatim quote, pin-cited — §11.8, complete, and identical in both copies:**

> "**11.8 Amendment; Waiver.** This Agreement contains the entire understanding and agreement between the parties hereto as to the subject matter of this Agreement. This Agreement may not be amended or modified by Developer. **The Company may modify this Agreement from time to time without notice. The most current version of the Agreement will supersede all previous versions. By using the Company's live API environment subsequent to publication of modifications to the Agreement, you agree to be bound to the full language of the most current Agreement, as revised and published.** Your only recourse if you disagree with the terms and conditions, or changes to the Agreement, is to discontinue your use of the Company's live API environment. Any provision of this Agreement may be waived if, and only if, such waiver is in writing and signed by the party against whom the waiver is to be effective. No failure or delay by the Company in exercising any right, power or privilege hereunder shall operate as a waiver thereof nor shall any single or partial exercise thereof preclude any other or further exercise thereof or the exercise of any other right, power or privilege."

(Bold added for locating only; the source is unemphasised.)

**Verbatim quote, pin-cited — the preamble, Copy A (Copy B's is materially the same; the immaterial wording difference is set out in C-03):**

> "By accessing the Morgan Stanley Smith Barney LLC ('Company') live Application Program Interface ('API') environment and its contents, you and, if applicable, the company you represent (collectively, 'Developer') accept and agree to be bound by the following terms and conditions of the API Developer License Agreement (the 'Agreement') **as of the date of your online acknowledgment ('Effective Date')**. This Agreement supplements the E*TRADE from Morgan Stanley Client Agreement for Self-Directed Accounts and any other agreements entered into by Developer and the Company."

**What it establishes:** The agreement contains **four distinct versioning mechanisms, all in the developer's disfavour and all resolving the same way**:

1. **An integration clause** — "This Agreement contains the entire understanding and agreement between the parties hereto as to the subject matter of this Agreement." There is therefore no room to argue that an older published copy survives alongside a newer one as a separate collateral understanding.
2. **A unilateral amendment right with no notice obligation** — "The Company may modify this Agreement from time to time **without notice**." The notice mechanism the brief asked me to find **does not exist**; the clause expressly disclaims one. §11.3 ("Notices") governs notices *under* the Agreement (by post or by Secure Message) but §11.8 removes amendments from any notice requirement altogether.
3. **A self-executing supersession rule** — "**The most current version of the Agreement will supersede all previous versions.**" This is the operative sentence. It decides the conflict by its own terms, without needing an effective date on either instrument.
4. **Acceptance by conduct** — "By using the Company's live API environment subsequent to **publication** of modifications to the Agreement, you agree to be bound to the full language of the most current Agreement, as revised and published." The triggering event is **publication**, not signature, not notice, and not the developer's awareness. The stated sole remedy is to stop using the live API.

**Q1 / Q2 / Q3:** Q3 **ADVERSE in operation** — not because the clause says anything about instructions, but because it forecloses the argument that the developer is bound by the older, silent Copy B. Q2 NEUTRAL.

**Level 3** — current, published, binding contract terms of the named broker, drafted squarely onto the question asked. Not law. Its force here is contractual and its self-referential character is a genuine limit: a clause in a document cannot by itself prove that *that* document is the most current one.

**Application note:** The brief asked for an integration clause and an amendment clause and posited that they might differ between the copies. **They do not differ — they are identical — and that is what makes them decisive.** Copy B contains, verbatim, the clause that subordinates Copy B to any later-published version. A developer cannot rely on the Agreement Library copy's silence about automated order generation, because the Agreement Library copy itself says that the most current version supersedes it and that continued use of the live API after publication binds the developer to the current text. The remaining question is purely factual — **which copy is the most current** — and that is answered on the documents themselves at C-03, not by inference from the form number alone.

Two limits on this entry must be stated. First, §11.8 identifies the governing text as "the most current version" but **nowhere states where the most current version is published**; neither copy carries a version number, a revision line or a "last updated" stamp, so the developer is given no locus to check. Second, the clause is self-referential: it appears in both copies and so cannot, standing alone, rank them.

---

### C-02 · The recital conflict clause — present in **both** copies, and it does not resolve the conflict · retrieved 7 September 2026

- **Type:** published terms (recital / order-of-precedence provision)
- **Date / status:** Live in both copies; verified present in each by direct grep (one occurrence of the word "conflict" in each document, being this sentence).

**Verbatim quote, pin-cited — third recital, final sentence, identical in both copies:**

> "WHEREAS, the Company is willing to grant such license in accordance with the terms and conditions of this Agreement. **If there is a conflict between this Agreement and any previous agreement that contained terms of use related to the Company's API, including but not limited to, an API License Agreement, User Agreement, or Developer Agreement entered into between the Parties, this Agreement shall be controlling.**"

**What it establishes:** Each copy claims priority over "any **previous** agreement that contained terms of use related to the Company's API", and the enumeration — "an API License Agreement, User Agreement, or Developer Agreement" — is expressly non-exhaustive.

**Q1 / Q2 / Q3:** Q3 NEUTRAL — an ordering rule, not a substantive term.

**Level 3** — primary contract text.

**Application note:** This clause is **circular between the two copies and cannot break the tie by itself**: each says it beats any *previous* agreement, so it operates only once you already know which is previous. Its real work is different and worth recording: the enumerated list "an API License Agreement, User Agreement, or Developer Agreement" is a good fit for the **"E*TRADE API Non-Commercial License"** that occupied the developer-portal URL until at least 9 May 2026 (C-04). Read against that document, the recital tells a developer who accepted the old Non-Commercial License that the current API Developer License Agreement controls over it. That is the one conflict this clause plainly does resolve. It is silent as between two simultaneously-published copies of the *same-named* agreement.

---

### C-03 · Directional evidence that Copy A is the later revision of Copy B — full section-level diff of the two live documents · retrieved 7 September 2026

- **Type:** published terms (documentary comparison of two primary texts)
- **Date / status:** Both fetched live on 7 September 2026, normalised (smart quotes, em-dashes and whitespace folded) and diffed sentence-by-sentence. Copy B additionally verified against four Wayback `id_` captures (see C-05).

**The diff, complete. Every difference between the two documents is listed; there are no others.**

**Present in Copy A, absent from Copy B — four whole sections:**

| Section | Heading |
|---|---|
| §1.19 | "Algorithmic" or "Automated Order Generation" (definition) |
| §4.8 | No Exercise of Discretion |
| §4.9 | Prohibition on Algorithmic or Automated Order Generation |
| §7.5 | Unauthorized Use; No Company Liability |

**Present in Copy A, absent from Copy B — two added sentences inside existing sections:**

§5.2 (Application Branding), added final sentence:
> "Developer agrees not to use or publish any of Company's registered marks without the express written consent of the Company and subject to the Company's branding guidelines."

§11.2 (Independent Contractor), added final sentence:
> "**Developer agrees not to represent having any relationship with the Company beyond that of an independent contractor, such as, but not limited to, holding themselves out to be an employee, partner, agent or fiduciary of the Company.**"

**Present in Copy B, absent from Copy A — one substantive deletion.** Copy B's §4.5 imposed a written End User acknowledgment and a five-year retention duty; Copy A replaces both with a bare hold-harmless.

Copy B §4.5, verbatim:
> "4.5 Vendor Use Developer Obligations related to End Users. For the sake of clarity this Section 4.5 applies only to Vendor Use Developers. **Prior to making the functions of an Application available to an End User, the Vendor Use Developer will obtain an acknowledgment from End User in written form containing clear language that the Company is not responsible for the functionality of an Application or for results obtained from using an Application, that the Company is not endorsing the Developer Application and makes no representations or warranties to its performance, and that the Company is indemnified and held harmless from any liabilities that arise as a result of End User's use of the Developer Application (the 'End User Acknowledgment'). Developer will retain records evidencing End Users' Acknowledgment during the term of this Agreement and for a period of not less than five years from the date of termination of this Agreement and will make such records available to the Company upon the Company's request.**"

Copy A §4.5, verbatim and complete:
> "4.5 Vendor Use Developer Obligations related to End Users. For the sake of clarity this Section 4.5 applies only to Vendor Use Developers. Developer understands and agrees that the Company is not endorsing the Developer Application and makes no representations or warranties to its performance, and agrees to hold the Company harmless from any liabilities that arise as a result of End User's use of the Developer Application (the 'End User Acknowledgement')."

**Non-substantive differences — copy-editing only, and they run in one direction:**

- §1.4: Copy B separates the (a)–(d) list with commas; Copy A with semicolons. §9.1: the reverse. Punctuation is therefore **mixed and gives no direction**; it is recorded so that it is not later mistaken for evidence.
- §1.10: Copy B "shall mean"; Copy A "means" — a modernisation consistent with, but not proof of, Copy A being later.
- §1.7: Copy B "A 'Developer' is further sub-categorized as an 'Individual Use Developer' or a 'Vendor Use Developer'."; Copy A drops the quotation marks, the terms having been defined in the immediately preceding sentence.
- §5.1(a): **Copy B reads "in and to the the Company's websites"; Copy A reads "in and to the Company's websites".** Verified by direct count: the string "the the Company" occurs **once in Copy B and zero times in Copy A**.
- Preamble: Copy B "the following terms and conditions (the 'Agreement')"; Copy A "the following terms and conditions **of the API Developer License Agreement** (the 'Agreement')" — Copy A names the instrument in its own operative sentence; Copy B does not.
- Recitals: Copy B's second recital ends "(collectively 'Developer(s)'," — an unclosed parenthesis and a dangling clause; Copy A removes it and adds "as defined below" cross-references.

**What it establishes:** Copy A is a **revision of Copy B**, not an independent document. The two share the same skeleton, the same eleven top-level sections, the same numbering, the same §11.8 and the same recital conflict clause. Copy A adds four sections and two sentences, deletes one obligation, and applies copy-editing that includes **fixing a doubled article and closing a dangling parenthesis that exist in Copy B**.

**Q1 / Q2 / Q3:** Q3 **ADVERSE** — it is the more restrictive text that is the current one.

**Level 3** for the diff itself (both texts fetched directly and compared mechanically). **Level 2** for the chronological inference drawn from it, which is documentary inference rather than a date stamp.

**Application note — how strong is the chronology, stated honestly.** Three independent lines converge and none of them is a date on the face of the instrument:

1. **Form number.** Copy B carries `0923-APIDEVLA-E68693`; E*TRADE's form-number convention encodes 09/23 = September 2023. Copy A carries no form number at all. Corroborated at C-05: the Agreement Library copy has been served with that form number, unchanged, in every archived capture from at least 27 December 2025 to 16 May 2026, and the same 6,274-word text without the form number was already being served on 1 April 2023.
2. **Error correction.** Copy A fixes a doubled article and a dangling parenthesis present in Copy B. Error *removal* is overwhelmingly more likely than error *introduction*. This is directional but not conclusive, and I record it as such: a drafter working from a clean master could in principle have introduced the errors into Copy B. Nothing observed excludes that.
3. **Archive.** Copy A's text did not exist at its own URL on 9 May 2026 (C-04). Copy B's text has been stable at its URL across the same period (C-05).

Taken together these establish, to a documentary standard and not to a date-stamp standard, that **Copy A is the most current version and therefore the version §11.8 makes governing.** S1a's instruction to "plan against Copy A" is confirmed, and the basis for it is now stronger than S1a's — it no longer rests only on the form number and an archive gap, but on the internal evidence that Copy A is a redline of Copy B.

**The countervailing point must be stated and is not disposed of.** Copy B is the copy a *customer* reaches from the "Account Agreements and Disclosures" footer link that appears on every E*TRADE page, including on Copy A's own page. Copy B is also on the same host (`us.etrade.com`) as the signature flow (C-08). If E*TRADE's own signature surface serves Copy B's text, then the text a developer actually acknowledges lacks §4.9, and §11.8's supersession rule would then operate the other way if Copy B were in fact the later publication. **That possibility is not excluded by anything I could read, because the signature surface is behind MFA.** It is, however, made unlikely by the diff: Copy B is the text Copy A was drafted *from*.

---

### C-04 · The developer-portal URL served a **different document entirely** for its whole archived history — the change is larger than S1a recorded · `https://web.archive.org/web/<ts>id_/https://developer.etrade.com/support/terms-of-use` · retrieved 7 September 2026

- **Type:** archived published terms
- **Date / status:** Wayback CDX for this URL, `collapse=digest`, returns **21 distinct-digest captures**, `20190825085540` (25 Aug 2019) through `20260509223240` (9 May 2026 22:32:40 UTC). Six were retrieved with the `id_` raw modifier and parsed.

**The measurement, on every snapshot retrieved:**

| Snapshot (UTC) | Words | "Automated Order Generation" | "Power of Attorney" | "1.19" |
|---|---|---|---|---|
| 20190825085540 (25 Aug 2019) | 2,473 | 0 | 0 | 0 |
| 20230129083026 (29 Jan 2023) | 2,505 | 0 | 0 | 0 |
| 20250718065430 (18 Jul 2025) | 2,459 | 0 | 0 | 0 |
| 20251115083358 (15 Nov 2025) | 2,459 | 0 | 0 | 0 |
| 20260217111131 (17 Feb 2026) | 2,459 | 0 | 0 | 0 |
| 20260509223240 (9 May 2026) | 2,459 | 0 | 0 | 0 |
| **live, 7 Sep 2026** | **6,897** | **3** | **1** | **1** |

Every archived capture is the **"E*TRADE API Non-Commercial License"**, a ~2,459-word document. Not one is the API Developer License Agreement.

**What it establishes:** S1a recorded that "this text is new". The stronger and more precise finding is that **the developer-portal terms URL never hosted the API Developer License Agreement at all** before the change. For at least six years and eight months it hosted a short non-commercial software licence. The change after 9 May 2026 therefore did two things at once: it **replaced one instrument with a different instrument** on the page where developers onboard, and the replacement instrument carried four sections that neither the outgoing portal document nor the Agreement Library copy contains.

**Q1 / Q2 / Q3:** Q3 **ADVERSE** — the restrictive text is both new and newly placed where a developer will meet it.

**Level 3** — raw archived captures of the named broker's own page, retrieved directly.

**Application note:** This matters for §11.8. The supersession rule speaks of "the most current version of **the Agreement**" — that is, of the API Developer License Agreement. Before the change, the developer portal was not publishing that agreement at all; the only published copy was Copy B in the Agreement Library. After the change there are two published copies and they differ. So the divergence S1a found is not a stale-page artefact of long standing: **it was created by the same edit that introduced §4.9**, at some point in the last four months. That is consistent with the Agreement Library copy simply not having been refreshed yet, which is the reading the C-03 diff supports.

---

### C-05 · The Agreement Library copy has been static since 2023 and still lacks §4.9 today · `https://us.etrade.com/l/f/agreement-library/api-developer-licensing-agreement` and its Wayback `id_` captures · retrieved 7 September 2026

- **Type:** published terms + archived published terms
- **Date / status:** Wayback CDX, `collapse=digest`, returns **15 distinct-digest captures**, `20230401064137` (1 Apr 2023) through `20260516073024` (**16 May 2026**). The 16 May 2026 capture is the newest in the archive. The page is live today.

**The measurement:**

| Snapshot | Words | "Automated Order Generation" | "No Exercise of Discretion" | "Power of Attorney" | Form number |
|---|---|---|---|---|---|
| 20230401064137 (1 Apr 2023) | 6,286 | 0 | 0 | 0 | *(none present)* |
| 20251227072552 (27 Dec 2025) | 6,274 | 0 | 0 | 0 | `0923-APIDEVLA-E68693` |
| 20260208095838 (8 Feb 2026) | 6,274 | 0 | 0 | 0 | `0923-APIDEVLA-E68693` |
| **20260516073024 (16 May 2026)** | **6,274** | **0** | **0** | **0** | `0923-APIDEVLA-E68693` |
| **live, 7 Sep 2026** | **6,274** | **0** | **0** | **0** | `0923-APIDEVLA-E68693` |

**What it establishes:** Copy B is unchanged in substance from at least December 2025 to today, and its 6,274-word body was already in place on 1 April 2023 — before the `0923` form number was stamped on it, which is itself consistent with a September 2023 stamping of an existing text. **Critically, Copy B still lacked §4.9 on 16 May 2026, one week after Copy A's URL last showed the old Non-Commercial License, and still lacks it on 7 September 2026.**

**Q1 / Q2 / Q3:** Q3 — this is the entry that makes the divergence *live rather than historical*. NEUTRAL as to substance; it establishes a fact about currency.

**Level 3** — raw archived and live captures.

**Application note:** The Agreement Library has not been updated to match the developer portal at any point in the four months since the portal changed. On §11.8's own logic the Agreement Library copy is superseded; on any reader's logic it is a trap, because it is the copy reachable from the "Account Agreements and Disclosures" link in the footer of every E*TRADE page including the developer portal's own. **A developer who reads the agreement via the route E*TRADE's own footer offers will not see §4.9.** Whether that has any legal consequence — notice, reasonable expectations, contra proferentem against the drafter under New York law, which §11.4 selects — is a question of law this register does not answer and no located E*TRADE document addresses.

---

### C-06 · §1.19 and §4.9 — the definitional sentence, its qualifier, and its verb list · Copy A · retrieved 7 September 2026

- **Type:** published terms
- **Date / status:** Live. No effective date. See C-03/C-04 for currency.

**Verbatim quote, pin-cited — §1.19, complete, unaltered, including the em-dashes and the non-breaking hyphen in "rules‑based" as served:**

> "1.19 'Algorithmic' or 'Automated Order Generation' means any logic, code, feature, rule set, model, signal, trigger, process, workflow, or functionality—whether deterministic, rules‑based, or otherwise—that directly or indirectly generates, initiates, routes, submits, modifies, cancels, or manages an order through the API without a discrete, contemporaneous, and affirmative instruction for that specific order provided by the End User (or, in the case of an Individual Use Developer, by the Developer with respect to the Developer's own account)."

**Verbatim quote, pin-cited — §4.9, complete:**

> "4.9 Prohibition on Algorithmic or Automated Order Generation. Developer shall not implement, use, permit the use of, or design the Application or any related functionality to engage in Algorithmic or Automated Order Generation in connection with the API. Each order submitted through the API must be based on a discrete, contemporaneous, and specific instruction provided by the applicable End User (or, in the case of an Individual Use Developer, by the Developer with respect to the Developer's own account) for that particular order. Any order submitted in violation of this Section shall be deemed unauthorized and may result in immediate suspension of API access and termination of this Agreement."

**What it establishes:** E*TRADE prohibits automated order generation outright and defines the prohibited category by reference to an eleven-item list of mechanisms — which expressly includes a "**signal**" and a "**trigger**" — and a seven-verb list of effects on an order, which expressly includes "**modifies, cancels, or manages**" as well as "generates" and "submits". The single dividing line the definition draws is whether the thing acts on that order **without** "a discrete, contemporaneous, and affirmative instruction for that specific order" from the End User. §4.9 turns that definition into a prohibition, requires that **each** order rest on such an instruction "for that particular order", and provides that any order submitted in violation "shall be deemed unauthorized". **§4.9 binds an Individual Use Developer operating on his own account as well: there is no volume threshold and no de-minimis carve-out.** The agreement nowhere defines "contemporaneous" and contains no time limit of any kind.

**Structural analysis of §1.19 — the sentence taken apart.** This is set out as syntax, not as a conclusion.

The sentence has four parts:

1. **The genus list (eleven disjunctive nouns):** "any logic, code, feature, rule set, model, **signal**, trigger, process, workflow, or functionality". This list identifies *what kind of thing* may be caught. It does not, on its own, catch anything.
2. **A concessive parenthetical:** "—whether deterministic, rules‑based, or otherwise—". This forecloses any argument built on the *mechanism* being simple, transparent, deterministic or member-authored. A plain if-then rule is expressly not excluded by being a plain if-then rule.
3. **A restrictive relative clause governing the whole list:** "**that** directly or indirectly generates, initiates, routes, submits, **modifies, cancels, or manages** an order through the API". Because the relative pronoun is restrictive and takes the whole preceding list as its antecedent, **each of the eleven nouns is caught only if it does one of these seven things to an order through the API.**
4. **An adverbial qualifier attaching to the verb phrase in (3):** "**without** a discrete, contemporaneous, and affirmative instruction for that specific order provided by the End User (or, in the case of an Individual Use Developer, by the Developer with respect to the Developer's own account)."

**The consequence of that structure, which is the answer to the brief's central question.** A thing falls inside "Automated Order Generation" only if **both** (3) and (4) are satisfied: it must act on an order through the API, **and** it must do so *without* the qualifying instruction. The qualifier in (4) is **the only limiting element in the entire definition** — (1) is drafted to be exhaustive by enumeration and (2) removes an exclusion rather than creating one.

Therefore: **the appearance of the word "signal" in the genus list does not, by itself, place a signal inside the prohibition.** "Signal" is one of eleven names for a mechanism; the definition bites on what the mechanism *does* and on *whether a qualifying instruction accompanied it*. Where an engine emits a signal and the End User then gives a discrete, contemporaneous, affirmative instruction for that specific order, limb (4) is not satisfied on the face of the sentence, and the definition is not met — **however completely limb (3) may be satisfied via "indirectly".**

**This cuts both ways and the adverse edge must be recorded with equal force.** Because the qualifier is the *only* limit, the separation of the engine layer from the runtime layer does **no work at all** under §1.19. The words "directly or **indirectly**" and the nouns "process" and "workflow" are wide enough to reach a signal that is the but-for cause of a composed order, and the concessive parenthetical pre-empts the answer that the rule is deterministic and member-written. **Nothing in §1.19 turns on who wrote the rule, on where the code runs, on whose credentials are used, or on how many layers separate the signal from the order.** The single question §1.19 asks is whether that particular order carried a discrete, contemporaneous, affirmative instruction from the End User. Everything the configuration relies on for §1.19 purposes rests on the per-order act and on nothing else.

**A drafting discrepancy between the definition and the prohibition, recorded because it is not reconciled anywhere in the document.** §1.19 requires the instruction be "discrete, contemporaneous, and **affirmative**"; §4.9's second sentence requires it be "discrete, contemporaneous, and **specific**". Four adjectives across two clauses, with only two in common. §1.19 further requires the instruction be "for that **specific** order"; §4.9 requires it be "for that **particular** order". The agreement does not say whether these are meant to be the same test. Read cumulatively — which is the safer reading and the one this register adopts for mapping purposes — an instruction must be **discrete, contemporaneous, affirmative and specific, and be given for that particular order**.

**"Contemporaneous" is used three times and is never defined.** Verified: the word occurs at §1.19, §4.8 and §4.9, and nowhere else. §1.0 provides that "Capitalized terms used herein shall have the meanings set forth below or as otherwise defined in this Agreement"; "contemporaneous" is not capitalised and is not defined. **The agreement contains no time limit of any kind** — a keyword sweep of the definitions section for "within [n]", "no more than", "time limit", "elapse", "seconds", "minutes" and "hours" returns nothing, and the words "seconds", "minutes" and "real-time" do not appear anywhere in the document. **How much time may elapse between the display of a composed order and the End User's tap is therefore not answered by this instrument, and no located E*TRADE document answers it.** That is a gap, not a permission.

**Q1 / Q2 / Q3:** Q3 **SUPPORT** on the qualifier as it applies to the per-order tap; Q3 **ADVERSE** on the "modifies, cancels, or manages" verbs as they apply to re-pegging and the end-of-day sweep (C-07); Q3 **ADVERSE** as to any standing-execution track. Q2 SUPPORT.

**Level 3** — current, published, binding contract terms of the named broker, drafted directly onto the exact question.

**Application note — mapping the configuration's facts onto each element, one at a time. No conclusion is offered.**

- **"discrete" — one act, one order.** The configuration's approval surface takes one explicit tap or swipe per composed order and mints one immutable instruction record per tap. On the ordinary meaning of "discrete" that is satisfied. The agreement does not define the word. Nothing in the configuration batches, aggregates or carries a single act across multiple orders; if it ever did, §1.19 would engage directly.
- **"contemporaneous" — the tap follows the composed order's display.** The configuration displays the complete composed order and the member taps on that display, immediately before transmission. **The document sets no interval and defines no outer bound.** The configuration's own sequencing — display, then tap, then transmit, with the instruction record bound to the exact terms displayed — is on any reading closer to the centre of "contemporaneous" than to its edge. But the edge is undrawn, and a design that permitted a long-lived displayed order to be tapped much later would be testing an undefined term.
- **"affirmative" (§1.19) and "specific" (§4.9).** The act is an explicit tap or swipe on a surface rendered in the signed runtime's own process, never an iframe or an engine-owned DOM, and the engine "can never fabricate the yes". A tap is affirmative on the ordinary meaning. Specificity is supplied by the binding of the instruction record to the exact displayed terms.
- **"for that specific order" / "for that particular order".** The instruction record is bound to the exact displayed terms, member, account, source, scope, timestamp and nonce. This is the element the configuration satisfies most completely, and it is corroborated mechanically by E*TRADE's own `previewId` requirement (C-07).
- **The §1.19 genus list, and the "signal" question specifically.** Set out in the structural analysis above. The qualifier takes a human-tapped signal back out of the definition **on the sentence's own grammar**, and it is the qualifier — not the layering, not the member's authorship of the rule, not the locality of the runtime — that does it.

---

### C-07 · The price-and-time envelope: E*TRADE's API models a change as a **replacement order with a new order ID**, and §1.19 expressly reaches "modifies, cancels, or manages" · `https://apisb.etrade.com/docs/api/order/api-order-v1.html` · undated · retrieved 7 September 2026

- **Type:** published technical documentation (the broker's own API reference)
- **Date / status:** Live, HTTP 200, 56,924 B gzip, 27,052 words as text. Plain `curl` succeeds — this host is not behind the Akamai block that guards `developer.etrade.com`. Undated.

**Verbatim quotes, pin-cited — the five order endpoints as documented:**

> "**Preview Order** — Description: The Preview Order API is used to submit an order request for preview before placing it. HTTP Method: POST · Live URL `https://api.etrade.com/v1/accounts/{accountIdKey}/orders/preview`"
>
> "**Place Order** — Description: The Place Order API is used to submit an order after it has been successfully previewed. HTTP Method: POST · Live URL `https://api.etrade.com/v1/accounts/{accountIdKey}/orders/place`"
>
> "**Cancel Order** — Description: The cancel order API is used to cancel an existing order. HTTP Method: PUT · Live URL `https://api.etrade.com/v1/accounts/{accountIdKey}/orders/cancel`"
>
> "**Change Previewed Order** — Description: The Preview Changed order API is used to preview a modified order. HTTP Method: PUT · Live URL `https://api.etrade.com/v1/accounts/{accountIdKey}/orders/{orderId}/change/preview` … Request body: **PreviewOrderRequest**"
>
> "**Place Changed Order** — Description: The Place Changed Order API is used to place a modified order. HTTP Method: PUT · Live URL `https://api.etrade.com/v1/accounts/{accountIdKey}/orders/{orderId}/change/place` … Request body: **PlaceOrderRequest**"

**Verbatim quote, pin-cited — the two fields that state E*TRADE's own model of what a change *is*:**

> "**replacedByOrderId** · integer · In the event of a change order request, **the order ID of the order that is replacing a prior order.**"
>
> "**replacesOrderId** · integer · In the event of a change order request, **the order ID of the order that the new order is replacing.**"

**Verbatim quote, pin-cited — the `previewId` field of `PlaceOrderRequest`, which is also the body of Place Changed Order:**

> "**previewId** · integer (int64) · **This parameter is required and must specify the numeric preview ID from the preview and the other parameters of this request must match the parameters of the preview.**"

**Verbatim quote, pin-cited — `clientOrderId`:**

> "A reference ID generated by the developer that is used to ensure that a duplicate order is not being submitted. This reference ID may be any value of 20 or less alphanumeric characters but must be unique within the account. This field does not appear in any API responses."

**Verbatim quote, pin-cited — E*TRADE's own message text returned to applications, error code 20109:**

> "Important: The order you are entering has an estimated total ${0}. **If you would like to modify your order, please click the Change Order link. Otherwise, please click the Place Order button to continue.**"

Error codes 9050 and 9051, verbatim:
> "IMPORTANT: You are about to place a marketable limit order that is significantly greater than the current ask price for the security and could be executed if placed. **To proceed as planned, please click Place Order. Otherwise, you may change or cancel your order.**"

**Verbatim quote — E*TRADE's own description of the platform's capabilities, `https://developer.etrade.com/getting-started`, retrieved 7 September 2026:**

> "Using the E*TRADE Developer Platform, a client application can: … **Directly manage trading: place orders, modify or cancel orders, and check order status**"

**What it establishes, on three points the brief asked about:**

1. **Is re-pegging within a member-set band a new "order submitted through the API"?** On E*TRADE's own documentation, **yes**. There is no in-place amend primitive. A change requires two calls — `change/preview` then `change/place` — and E*TRADE's own field descriptions characterise the result as a **new order, with a new order ID, that "replaces" the prior order**. The `previewId` matching requirement applies to `PlaceOrderRequest`, which is the body of `change/place`, so **each re-peg must carry its own fresh preview whose parameters the place call must match**.
2. **Does E*TRADE require a cancel/replace?** Not a literal `cancel` then `place`; it provides a dedicated change pair. But the semantics E*TRADE documents are replacement semantics, and it is a distinct order that results.
3. **§1.19's verb list reaches this conduct expressly.** The definition catches functionality that "generates, initiates, routes, submits, **modifies, cancels, or manages** an order through the API". Modification and cancellation are named in terms.

**Q1 / Q2 / Q3:** Q3 **SUPPORT** as to the initial order (the preview→place protocol enforces exactly the display-then-confirm, terms-bound shape the configuration implements); Q3 **ADVERSE** as to re-pegging, the end-of-day sweep and V2. Q2 SUPPORT.

**Level 3** — the broker's own published API contract, machine-enforced.

**Application note — this is the sharpest new finding of this follow-up and it is adverse. It must not be softened.**

S1a mapped the configuration onto §1.19 and §4.9 using only the verbs "generates" and "submits", and concluded on the face of those that V1 sits outside the prohibition because of the per-order tap. That mapping is incomplete. **§1.19 also names "modifies", "cancels" and "manages", and the configuration performs all three without a fresh per-order act:**

- **Re-pegging.** The configuration provides that "once a definite order exists (definite security, definite quantity, day-limited), the runtime may exercise only the narrow price-and-time latitude the member's own policy granted (price band, re-peg rule)." Executing that latitude against E*TRADE requires `change/preview` + `change/place`, producing a **new order with a new order ID**. §4.9's second sentence provides that "**Each** order submitted through the API must be based on a discrete, contemporaneous, and specific instruction provided by the applicable End User … **for that particular order**." The replacement order is a particular order. The member's tap was given for the *original* order, before the replacement existed.
  - **The reading that defeats the configuration:** "contemporaneous" and "for that particular order" are conjunctive requirements alongside "specific". An instruction given at 10:00 for order #825 is not contemporaneous with, and is not "for", replacement order #826 submitted at 11:20. On this reading every automated re-peg is an order "deemed unauthorized" under §4.9's third sentence.
  - **The reading that saves it:** the member's policy fixed the price band and the re-peg rule in advance and by his own hand, so the replacement's terms are wholly determined by the member's own prior specific instruction; the runtime exercises no latitude the member did not define. On this reading the instruction is "specific" as to the replacement.
  - **The agreement does not choose between these readings, and nothing located in E*TRADE's published materials chooses between them.** The word "contemporaneous" — which is the adjective on which the first reading turns — is undefined (C-06). This is the single largest unresolved exposure this follow-up identifies, and it is an exposure S1a did not surface.
- **The end-of-day sweep.** The configuration provides that "end-of-day sweep cancels the runtime's own resting orders." §1.19 expressly reaches functionality that "cancels … an order through the API without a discrete, contemporaneous, and affirmative instruction for that specific order". An automated EOD cancel has no contemporaneous per-cancellation instruction. **Note the precise mechanics of how §4.9 catches it:** §4.9's *second* sentence speaks only of "each order **submitted**", which arguably does not reach a cancellation; but §4.9's *first* sentence is broader — "Developer shall not implement, use, permit the use of, or design the Application or any related functionality to engage in **Algorithmic or Automated Order Generation** in connection with the API" — and that defined term includes cancelling. **The first sentence catches the sweep even though the second does not.** Recorded because the distinction determines which sentence the exposure sits under and hence which remedy clause applies.
- **What supports the configuration here, stated with equal care.** E*TRADE's own `previewId` rule — "the other parameters of this request must match the parameters of the preview" — is the machine-level analogue of the configuration's immutable instruction record bound to the exact displayed terms, and it applies to the change pair as well as the initial pair. A design in which every re-peg is itself previewed, displayed and tapped would satisfy §4.9 on either reading. A design in which re-pegs are automatic would not satisfy the first reading. **The distinction is a design choice, and E*TRADE's protocol makes the compliant version mechanically available.** That is a factual observation about the API, not a recommendation.
- Note finally the tension inside E*TRADE's own materials: the Getting Started page advertises that a client application can "**modify or cancel orders**", while §1.19 defines automated modification and cancellation into the prohibited category. Neither document acknowledges the other. This is not resolved by anything located.

---

### C-08 · §4.8 "No Exercise of Discretion" in full, and the power-of-attorney alternative · Copy A · retrieved 7 September 2026

- **Type:** published terms
- **Date / status:** Live in Copy A; **absent from Copy B**.

**Verbatim quote, pin-cited — §4.8, complete:**

> "**4.8 No Exercise of Discretion.** The Developer shall not create, initiate, or route any order on behalf of a third-party through the API unless the Developer has received explicit, contemporaneous instructions from the third-party authorizing such action. In the absence of such instructions, the Developer must possess a valid and enforceable **Power of Attorney ('POA')** from the third-party that specifically authorizes order placement and routing. Any order submitted without such authorization shall be deemed unauthorized and may result in immediate suspension of API access, termination of this Agreement, and potential legal liability."

**Verbatim quote, pin-cited — §7.1(c), the developer's warranty, which bears on the Vendor case:**

> "(c) An Individual Use Developer warrants they are the sole owner of the Developer Account for personal, non-commercial use. **A Vender Use Developer warrants that they are the sole owner of the Developer Account and that any multiple use access that they allow will adhere to all terms and conditions of this Agreement and that any access is only allowed to End Users or Users with their own E*TRADE account.**"

("Vender" is E*TRADE's typographical error, reproduced as served.)

**Verbatim quote, pin-cited — §4.7, which bears on the transaction-based-compensation question:**

> "4.7 Cost and Expenses. … **Neither party is obligated under this Agreement to share any revenues, pay any royalties, or otherwise pay commissions to the other party.**"

**Verbatim quote, pin-cited — §9.1, automatic termination (identical in substance in both copies):**

> "9.1 Suspension or Termination by the Company. The Company may change, suspend or discontinue the API and suspend or immediately terminate the use of this Agreement and the API at any time, with or without notice, for any reason or no reason. In addition, this Agreement and the rights granted hereunder will terminate automatically: (a) if Developer fails to complete required annual attestation confirming API Use, (b) **if Developer is no longer a customer of the Company**, or (c) the Developer Key is not actively utilized."

**What it establishes:** §4.8 offers a developer routing orders for a third party exactly two routes: **explicit contemporaneous instructions from that third party**, or **a valid and enforceable power of attorney specifically authorising order placement and routing**. There is no third route. §7.1(c) requires a Vendor Use Developer to warrant that access is granted only to End Users who have their own E*TRADE accounts. §9.1(b) makes the developer's own continuing status as an E*TRADE customer a condition of the agreement's survival.

**Q1 / Q2 / Q3:** Q3 **SUPPORT** as to V1 (the per-order tap is "explicit, contemporaneous instructions from the third-party"); Q3 **ADVERSE and unmitigated** as to V2. Q2 ADVERSE-LEANING on §4.8's premise that it is "the Developer" who creates, initiates or routes.

**Level 3** — current published contract terms of the named broker.

**Application note.**

**On V2 standing execution — confirmed from the text, as the brief required.** The configuration's V2 track is standing execution: the runtime transmits without a per-order act. Under §4.9's first sentence that is Automated Order Generation and is prohibited outright — not conditioned, not thresholded. §4.8 supplies the **only** alternative the agreement offers, and it is a **power of attorney "that specifically authorizes order placement and routing"**. A POA is the paradigm instrument of discretionary authority. Taking it engages, on their own terms, FINRA Rule 3260(b) and (d)(1), FINRA Rule 4512(a)(3) (time-and-price *is* investment discretion), and the Exchange Act §3(a)(35) analysis already in the register — the precise characterization V1 is designed to avoid. **On E*TRADE, the V2 track and the avoidance of discretionary-authority characterization cannot both be had.** This is squarely adverse to the roadmap and is not distinguished by anything in the configuration.

**On §4.8's application to V1, an unresolved point.** §4.8 forbids "**the Developer**" from creating, initiating or routing an order on behalf of a third party. In the configuration the software that composes the order runs on the member's own machine, under the member's own credentials, and transmits only after the member's own act. Whether the Developer thereby "creates, initiates, or routes" the order — or whether the member does, using the Developer's tool — **is not answered by the clause**. Both readings are available on the text. On either reading V1 survives §4.8, because the first limb is satisfied: the per-order tap is "explicit, contemporaneous instructions from the third-party authorizing such action". But the ambiguity is real and would matter to any design that weakened the tap.

**On §4.7.** "Neither party is obligated … to share any revenues, pay any royalties, or otherwise pay commissions to the other party" records that E*TRADE's developer relationship carries no transaction-based compensation in either direction. That is a point of contrast with *Neovest* (Rel. 34-92285), where transaction-based compensation was one of two limbs of the finding. It is a fact about the broker's contract, not about the configuration's own economics, and it does not touch the *Neovest* solicitation limb.

**On §9.1(b) and §7.1(c) together.** Every participant must hold their own E*TRADE account, and the developer must remain an E*TRADE customer or the agreement terminates automatically. Both align with the configuration (each member uses his own broker account under his own credentials; no company-level or app-level trading credential exists), and both are conditions rather than concessions.

---

### C-09 · The Vendor path — everything E*TRADE publishes about it, and what it does not publish · `https://developer.etrade.com/getting-started`, Copy A §§1.2, 1.7, 1.15, 2.2, 4.1, 4.5, 7.1(c) · retrieved 7 September 2026

- **Type:** published terms / broker-imposed developer requirement
- **Date / status:** The Getting Started page is live, HTTP 200, 8,787 B, and carries **no printed date** — its footer template renders the unpopulated token "© currentYear E*TRADE from Morgan Stanley". Dating is indirect, from CDN asset stamps in its own HTML in `YYMMDDHHMMS` form; the newest is `cdn2.etrade.net/1/26081920310.0/` = **19 Aug 2026 20:31**. The same stamp appears on Copy A, so the stamps are site-wide build tokens and **do not date any individual page's content** — recorded so they are not mistaken for a content date.

**Verbatim quotes, pin-cited — Getting Started, the complete published account of the two key tiers and the Vendor process:**

> "**Consumer keys** — We support two levels of consumer key. **An individual key is tied to a single user ID, and allows access for only that user. This is appropriate for developing applications for personal use. A vendor key, on the other hand, permits access by multiple users and is appropriate for applications that may be widely distributed.**"
>
> "Note that separate keys are required for accessing 'sandbox' data (used for development and testing purposes) versus actual production data. For this reason, a typical developer has at least two consumer keys."
>
> "**Requesting keys** — To request a key, you must have an E*TRADE account. (You will also need the account so that you can log in and use your application.) **It can be a personal, professional, or corporate account.** If you don't have one, you can quickly set one up online at https://www.etrade.com. For development purposes, it is not necessary to fund the account, but to do any actual trading will require funds."
>
> "Note that if you are assigned an individual key, rather than a vendor key, **it will only work with your E*TRADE account. Attempting to use an individual key with a different user account will result in an error.** Your Individual Key will work with any of your E*TRADE accounts."
>
> "To request either an Individual or Vendor LIVE API key, please navigate to the bottom of this page and complete your API Developer Agreement and User Intent Survey. **Individual Keys will be provided immediately in page upon satisfying these requirements.**"
>
> "**Vendor keys will be provided immediately in page, but will be Inactive. E*TRADE will reach out to you via email to schedule your short online Vendor demo with Product and Legal teams. Upon approval of your access based on your demo, your key will be made active.**"

**Verbatim quotes, pin-cited — the four standing obligations, Getting Started:**

> "**User Intent Survey** — As a developer, you must disclose to us your intentions with your API access by completing our API User Intent Survey located here."
> "**API Agreement** — As a developer, you are asked to sign an API agreement before you will be issued a consumer key for production data."
> "**Market Data Agreement** — As a user, you must sign the Market Data Agreement before you can access data with the quote API. Additionally, you must sign the Extended Hours Trading Agreement before you can perform after-hours trading (if the application supports this feature)."
> "**Market Data Attestation** — As a developer, you must return to this page Annually after completing our Developer Agreement in order to attest to your Market Data Attestation."

**Verbatim quote, pin-cited — Copy A §4.1, the contractual counterpart of the User Intent Survey:**

> "4.1 Delivery of Access to API/ Developer Key: **Upon request of the Company, Developer will complete an API questionnaire which will assist in identifying Developer as either an Individual User Developer or a Vendor Use Developer.** Upon completion of the API questionnaire, Developer will be provided a consumer key ('Consumer Key'), which is unique to the Application, by the Company as follows: (1) **Developer must specify (via the API questionnaire process) whether an Individual Use Key or a Vendor Use Key is appropriate based upon their intended usage**, (2) the Company shall deliver the Consumer Key to Developer by providing such Consumer Key to Developer in a message sent electronically through Developer's account with the Company (the 'Developer Account'), following Developer's request (made electronically through the Developer Account) for the Consumer Key from the Company. Developer agrees to keep the Consumer Key confidential, and not to disclose it to, or share it with any Third-Party."

**Verbatim quotes, pin-cited — the Vendor definitions, Copy A:**

> "1.7 … A '**Vendor Use Developer**' means a Developer exercising the rights under this Agreement **for multiple users and for Applications that may be more widely distributed.**"
> "1.15 '**End User(s)**' means customers of the Company who obtain a license through a Vendor Use Developer to use the Developer Application."
> "1.2 '**Application**' means the proprietary software application developed by Developer for their own personal use (Individual Use Developer) or **to make available to customers of the Company (Vendor Use Developer)**."
> "2.2 Grant of License: … the nonexclusive, nontransferable, revocable, royalty free license to install, modify, and use the API Code for any allowed purpose, including for an Individual Use Developer's personal, non-commercial use or a **Vendor Use Developer's multiple End User use case**."

**What it establishes — and what it does not.**

**A Vendor path exists, is published, and is self-service up to a gate.** Its published elements are exactly six: (i) a two-tier key system with a stated functional threshold — multiple users / wide distribution; (ii) an eligibility floor of holding an E*TRADE account of any kind, "personal, professional, or corporate"; (iii) a self-declaration of tier via the API questionnaire / User Intent Survey; (iv) issuance of the Vendor key **immediately but Inactive**; (v) a **"short online Vendor demo with Product and Legal teams"** scheduled by E*TRADE by email; (vi) activation "upon approval of your access based on your demo".

**What E*TRADE does not publish — this is a documented negative and it is the finding.**
- **No review criteria.** Nothing states what Product and Legal assess, what standard they apply, what would cause rejection, or how long it takes.
- **No separate Vendor agreement.** The Agreement Library index lists exactly one API instrument, "Application Program Interface (API) Developer License Agreement", under "Global Agreements"; it links to Copy B. No second, Vendor-specific agreement is published anywhere located. **The same API Developer License Agreement governs both tiers**, differentiated internally by the §1.7 sub-categories — which is why §4.9 binds an Individual Use Developer on his own account as well.
- **No vendor registration requirement of any kind.** Confirmed by keyword sweep over both copies: `broker-dealer` = 0, `broker dealer` = 0, `investment adviser` = 0 in the body, `registered representative` = 0. E*TRADE imposes **no securities-registration expectation on developers** — a material contrast with Interactive Brokers, whose published third-party registration process states it "expect[s] 3rd Parties offering automated trading solutions would hold applicable registration with financial authority in all regions they plan offer the service, unless you are able to provide support (i.e. a legal opinion)" (S1a, A-06).
- **No entity requirement.** "personal, professional, or corporate" account — a natural person qualifies. Contrast IBKR's "applicants must have a registered company and completed website to qualify for review" (S1a, A-04).
- **No published fee, no revenue share, no volume condition.** §4.7 confirms neither party owes the other revenues, royalties or commissions.

**Q1 / Q2 / Q3:** Q3 NEUTRAL; Q2 **ADVERSE-LEANING** — the Vendor gate exists and Legal sits on it, and the criteria applied at that gate are unpublished and therefore unknowable in advance from public materials.

**Level 3** for the published elements (the broker's own current statements, fetched directly); the absence of criteria is a **documented negative finding**, recorded under Negative findings with its endpoints.

**Application note.** S1a established that the configuration crosses into the Vendor tier at its second member; that is confirmed by §1.7 ("for multiple users and for Applications that may be more widely distributed") and by the Getting Started sentence that an Individual key "will only work with your E*TRADE account" and will "result in an error" on any other. Nothing in the configuration avoids that. Compared with IBKR's gate (S1a, A-04/A-06 — registered company, completed website, named principals and compliance officer, enhanced due diligence, three-tier compliance approval, a bilateral agreement drafted by IBKR Legal, an expectation of registration or a legal opinion, 8–14 weeks), **E*TRADE's published gate is materially lighter: no entity requirement, no registration expectation, no due-diligence questionnaire published, no bilateral agreement, and a stated timeline of one short demo.** But three cautions are on the face of the published text and must travel with that comparison:
1. **Legal is in the room.** "your short online Vendor demo with **Product and Legal teams**". The demo is the only published gate and it is not a formality on its face.
2. **The criteria are unpublished, so the gate cannot be modelled in advance.** A configuration cannot be pre-qualified against a standard that is not stated anywhere.
3. **What the demo will be shown is the workflow, and §4.9 is now the applicable standard.** The Vendor demo is scheduled after the developer has completed the API Developer Agreement and User Intent Survey — that is, after accepting the text that contains §4.9. The four exposures identified at C-06 and C-07 (re-pegging, the EOD sweep, the undefined "contemporaneous", and V2) are exactly what a demo would surface.

---

# Adverse register

| Authority | Threat 1–5 | Does the configuration distinguish it, or not — bluntly |
| --- | --- | --- |
| **§11.8 (both copies)** — "The most current version of the Agreement will supersede all previous versions"; "The Company may modify this Agreement from time to time **without notice**"; binding by continued use after **publication** | **4** | **No.** It forecloses reliance on Copy B's silence. It also means the governing text can change at any time with no notice and no version marker to check, and the sole stated remedy is to stop using the live API. Any design built on §4.9's current wording is built on a term the broker may rewrite unilaterally and silently. |
| **§1.19 verb list — "modifies, cancels, or manages"** applied to **automated re-pegging** within the member's own price band | **5** | **Not distinguished.** E*TRADE's own API makes a re-peg a **new order with a new order ID** that "replaces" the prior one (C-07). §4.9 requires **each** order to rest on a discrete, contemporaneous, specific instruction **for that particular order**. The member's tap was for the original order. Two readings exist; the agreement chooses neither, and "contemporaneous" is undefined. **S1a did not identify this. It is the largest new exposure in this follow-up.** |
| **§1.19 "cancels"** applied to the **end-of-day sweep** of the runtime's own resting orders | **4** | **Not distinguished.** Caught by §4.9's *first* sentence (which incorporates the defined term, including "cancels") though not by its second (which speaks only of orders "submitted"). No contemporaneous per-cancellation instruction exists in the design as described. |
| **§4.9 + §4.8 applied to V2 standing execution** | **5** | **Not distinguished, and cannot be.** Prohibited outright by §4.9; the only alternative §4.8 offers is a **power of attorney "that specifically authorizes order placement and routing"** — the discretionary-authority characterization V1 exists to avoid. On E*TRADE the two cannot both be had. |
| **"Contemporaneous" undefined; no time limit anywhere in the agreement** | **3** | **Not distinguished — it is a gap, not a permission.** The configuration's display→tap→transmit sequence sits near the centre of any ordinary meaning, but the outer bound is undrawn and the register must not infer one. |
| **§1.19's "directly or indirectly", "process", "workflow", and the concessive "whether deterministic, rules-based, or otherwise"** | **3** | **Partly.** The qualifier takes a human-tapped signal back out (C-06). But the layering of engine from runtime, the member's authorship of the rule, the locality of the code and the ownership of the credentials **do no work whatever** under §1.19. Everything rests on the per-order act. |
| **§1.19 / §4.9 adjective mismatch** — "affirmative" v. "specific"; "that specific order" v. "that particular order" | **2** | **Not distinguished.** Unreconciled in the document. Adopted cumulatively here, which is the stricter reading. |
| **Copy A §11.2 new sentence** — Developer must not hold out "any relationship with the Company beyond that of an independent contractor … employee, partner, agent or fiduciary" | **3** | **Partly.** The configuration's marketing rule (software tools, never a trading, execution or signal service) points the same way. But the clause is new in Copy A and reaches all marketing, and it sits alongside §5.2's new bar on using E*TRADE's registered marks without express written consent — which constrains naming a supported broker in marketing at all. Flagged to the marketing track. |
| **§2.3** — "Developer will not publish, disseminate, or redistribute the API Code to any Third Party" | **4** | **Not distinguished, and here there is no GPL counterweight** (contrast IBKR, S1a A-03). A distributed open-source runtime must not ship E*TRADE API client code. |
| **Vendor gate criteria unpublished**; activation requires a demo to **Product and Legal** | **3** | **Not distinguished.** The gate is light on its published face but unmodellable in advance. The demo occurs after acceptance of the §4.9 text. |
| **Copy B is the copy E*TRADE's own site footer routes a reader to, and it lacks §4.9** | **2** | **Cuts the other way, and is recorded as such.** It is a fact about E*TRADE's publication practice, not a defence available to the configuration on §11.8's terms. Any argument built on it is an argument about notice under New York law (§11.4), which this register does not reach. |

---

# Direct answers

## 1 · Which version governs?

**On the documents' own terms, the version published as the most current governs — and both copies say so in identical words.** The dispositive text is §11.8, present verbatim in Copy A and Copy B alike:

> "This Agreement contains the entire understanding and agreement between the parties hereto as to the subject matter of this Agreement. This Agreement may not be amended or modified by Developer. The Company may modify this Agreement from time to time without notice. **The most current version of the Agreement will supersede all previous versions.** By using the Company's live API environment subsequent to publication of modifications to the Agreement, you agree to be bound to the full language of the most current Agreement, as revised and published."

Answering the brief's sub-questions one by one:

- **Integration or entire-agreement clause in each version, quoted and compared:** present in both, **identical**, at §11.8 first sentence — "This Agreement contains the entire understanding and agreement between the parties hereto as to the subject matter of this Agreement." There is no difference to compare. A separate order-of-precedence clause appears in the third recital of **both** copies — "If there is a conflict between this Agreement and any previous agreement that contained terms of use related to the Company's API … this Agreement shall be controlling" — which is circular between two copies of the same agreement and resolves only the conflict with the superseded **API Non-Commercial License** (C-02, C-04).
- **Effective-date or version line:** **neither copy has one.** Both self-date to "the date of your online acknowledgment ('Effective Date')" — i.e., to an event, not a date. Copy B carries the form number `0923-APIDEVLA-E68693`; Copy A carries no form number at all. Neither carries a revision line, a version number or a "last updated" stamp.
- **"We may amend" clause and its notice mechanism:** the amendment right is §11.8 and **it expressly disclaims notice** — "The Company may modify this Agreement from time to time **without notice**." The binding event is **publication**, not notice and not awareness. §11.3 governs notices *under* the agreement (registered mail, or Secure Message through the developer's etrade.com account) but does not apply to amendments. **The notice mechanism the brief hypothesised does not exist.**
- **Incorporation by reference from the Client Agreement or the application flow:** the incorporation runs **one way only**. The API agreement's preamble states, in both copies: "This Agreement **supplements** the E*TRADE from Morgan Stanley Client Agreement for Self-Directed Accounts and any other agreements entered into by Developer and the Company." The Client Agreement does **not** reciprocate — S1a's N-10 recorded a word-boundary count of `API` = **0** across its full 263,093-byte text, and that stands. From the application flow, the Getting Started page's "STEP 2: API AGREEMENT" button links to `https://us.etrade.com/etx/ris/apisurvey/#/agreement`, which is MFA-gated (see below).
- **The Agreement Library's own index page:** fetched at `https://us.etrade.com/l/f/agreement-library`, HTTP 200, 41,269 B. It lists "Application Program Interface (API) Developer License Agreement" under the heading **"Global Agreements"** and links it to Copy B. **It carries no revision date, no effective date, no version column and no statement that the listed forms are current** — verified by keyword sweep: `effective` = 0, `revised` = 0, `updated` = 0, `current as of` = 0, `last modified` = 0 occurrences on the page, and no form number appears on the index itself. Its only self-description is: *"We like when our customers want to learn more. **Here are some of the key Agreements and Disclosures** to help you do just that."* The brief's hypothesis that the index might carry a currency statement or a newer revision date is **negatived**.

**Which copy is the most current, as a matter of fact.** Copy A, on three converging documentary lines and no date stamp: (i) Copy B's `0923` form number, corroborated by archived captures showing that text stable and unchanged from 1 April 2023 to 16 May 2026 and today; (ii) Copy A is demonstrably a **redline of Copy B** — same skeleton, same numbering, same §11.8, adding four sections and two sentences, deleting one obligation, and **fixing a doubled article ("the the Company's websites") and a dangling parenthesis that remain in Copy B**; (iii) Copy A's text did not exist at its own URL as recently as 9 May 2026, while Copy B's has been static across that period. **This is documentary inference, not a date on the instrument, and it is labelled Level 2 as such.**

**What a developer is therefore bound by:** the API Developer License Agreement **as most recently published**, which on the evidence is Copy A, including §1.19, §4.8, §4.9 and §7.5. **S1a's instruction to plan against Copy A is confirmed and the basis for it is now stronger.**

**The one thing that could displace this, and it is UNVERIFIED.** The agreement actually presented at signature sits at `https://us.etrade.com/etx/ris/apisurvey/#/agreement`. Unauthenticated, that URL returns HTTP 200 and **537 bytes** — a JavaScript shim whose sole function is `redirectToMfaLogin()`; following redirects lands on `https://us.etrade.com/e/t/user/login;jsessionid=…?TARGET=https%3A%2F%2Fus.etrade.com%2Fetx%2Fris%2Fapisurvey%2F`. The sibling routes `#/questionnaire` and `/etx/ris/apikey` behave identically. Wayback has never captured any of them. **I did not authenticate and did not create an account.** If that surface serves Copy B's text, the instrument actually acknowledged lacks §4.9. **UNVERIFIED. Closing it requires an authenticated E*TRADE session or written confirmation from E*TRADE Legal, and it remains the single highest-value open item.**

## 2 · When did §4.9 go live?

**I cannot narrow S1a's bracket. The tightest bracket I can evidence is unchanged: after 2026-05-09 22:32:40 UTC and on or before 2026-09-07.** Saying so plainly, as the brief directed.

What was tried and what it returned:

- **Wayback CDX with `collapse=digest` on Copy A's URL, all statuses:** **21 distinct-digest captures**, 25 Aug 2019 → 9 May 2026. **Every one was retrieved by digest sampling and every one is the ~2,459-word "E*TRADE API Non-Commercial License", with zero occurrences of "Automated Order Generation".** There is no capture after `20260509223240`. `archive.org/wayback/available` confirms that is the newest.
- **Why the gap exists — documented rather than assumed.** The only crawler reaching this host is Common Crawl, whose captures the Internet Archive ingests; the timestamps match exactly (e.g. `20260509223240` appears identically in both). Its 2026 crawls of `developer.etrade.com` are **shallow, 5–6 URLs each**, and after May they never included the terms page: **June 2026 (CC-MAIN-2026-25, crawled 7 Jun)** — `/home`, `/pagenotfound`, `/support`, `/robots.txt`, one `/ctnt` redirect, **5 rows**; **July 2026 (CC-MAIN-2026-30, crawled 14 Jul)** — 6 rows, same shape; **August 2026 (CC-MAIN-2026-34, crawled 7 Aug)** — `/home`, `/robots.txt`, `/support/downloads`. The terms page appears in **CC-MAIN-2026-21 only**, at `20260509223240`. **This is a crawl-coverage gap, not a block**, and I record it that way because the distinction matters to anyone re-running this.
- **Sibling-page route, tried and negative.** `developer.etrade.com/support` — the hub that links the terms page — was captured on both **9 May 2026** (`20260509233933`) and **7 June 2026** (`20260607083934`). Both were retrieved raw and diffed. They are **identical at 874 words apart from a single server-instance token** (`121w201m1-168w201m1` → `121w201m1-170w201m1`). The link label was "View our terms of use" on both dates and the hub never names the document, so it carries no signal. Negative.
- **Common Crawl index API**, all 2026 collections queried individually (2026-04, -08, -12, -17, -21, -25, -30, -34; 2026-12, -17, -25 and -34 returned nginx 502/504 on first attempt and were retried until they answered). No capture of the terms page after 9 May 2026. Also queried for Copy B's URL in CC-MAIN-2026-34: `{"message": "No Captures found"}`.
- **Alternative archives.** `archive.ph/newest/…` → **HTTP 404**, never captured. `timetravel.mementoweb.org` → DNS failure, service defunct (carried from S1a, re-confirmed as unavailable).
- **Wayback Save Page Now**, to create a citable snapshot of the live text: `https://web.archive.org/save/…` → **HTTP 520**, failed. Newest capture remains `20260509223240`. No snapshot was created.
- **Page-embedded date metadata, tried and negative.** Copy A's HTML carries **no** `lastmod`, `dc:modified`, `dc:date` or `datemodified`; its meta tags are `title`, `keywords` (empty), `description` (empty) and empty Open Graph/Twitter tags. Its CDN asset stamps in `YYMMDDHHMMS` form (`cdn2.etrade.net/1/26081920310.0/` = 19 Aug 2026 20:31, plus older bundles back to 2021) are **site-wide build tokens** — the identical newest stamp appears on the Getting Started page — and **do not date the page's content**. `HEAD` is refused by Akamai even with full browser headers, so no `Last-Modified` is obtainable for any page on this host.
- **AEM content-API route, tried and negative.** `terms-of-use.model.json`, `.infinity.json` and `.1.json`, and `/ctnt/dev-portal/getArticleByCategory?category=Support` and `…=Documentation`, **all return HTTP 302 (225 B) to `/pagenotfound`**. No `jcr:lastModified` obtainable.
- **Developer-portal release notes, negative.** `developer.etrade.com/support/release-notes`, HTTP 200, 6,799 B: **exactly one entry, dated 9/14/2018**, about the V1 API and the Swagger docs. A date sweep of the whole page returns that single date. E*TRADE does not publish agreement changes there.

- **Open-web and code-forge sweep, twelve queries, entirely negative (N-C9, C37–C55).** Exact-phrase searches for both clause titles return nothing anywhere outside E*TRADE's own site; GitHub code and issue search return `total_count: 0`; the actively-maintained `pyetrade` client has no mention of a terms change across 30 issues and 11 commits through mid-2026. **reddit.com and stackoverflow.com were unreachable and are UNCHECKED, not cleared.** One secondary article dated 26 June 2026 covering E*TRADE API automation limits does not mention the clause — **that is recorded as a lead that was pursued and did not pay, not as evidence that the clause post-dates it. No date is inferred from silence.**

**Corroborating boundary, which is the one thing this track adds to the date question:** Copy B was captured on **16 May 2026** (`20260516073024`) and **still lacked §4.9** — as it does live today. That does not narrow when Copy A gained the clause, but it fixes that **as of 16 May 2026 the Agreement Library copy had not been updated**, and it has not been updated since.

**Statement for the register: the appearance of §1.19, §4.8, §4.9 and §7.5 on `developer.etrade.com/support/terms-of-use` can be placed only within a four-month window, after 9 May 2026 22:32:40 UTC and on or before 7 September 2026. No public archive, index or page metadata narrows it further. The clause is at most four months old and has no interpretive history.**

## 3 · Does the prohibition reach the configuration as described?

A mapping, element by element. No conclusion is offered.

**The single most important question — does §1.19's qualifier take a human-tapped signal back out?**

The full definitional sentence, with its qualifier:

> "1.19 'Algorithmic' or 'Automated Order Generation' means any logic, code, feature, rule set, model, **signal**, trigger, process, workflow, or functionality—whether deterministic, rules‑based, or otherwise—that directly or indirectly generates, initiates, routes, submits, modifies, cancels, or manages an order through the API **without a discrete, contemporaneous, and affirmative instruction for that specific order provided by the End User** (or, in the case of an Individual Use Developer, by the Developer with respect to the Developer's own account)."

**On the syntax: yes, the qualifier takes it back out.** The eleven-noun list is a genus list; it is governed by a **restrictive** relative clause ("that … generates, initiates, routes, submits, modifies, cancels, or manages an order through the API"), which is in turn governed by an adverbial qualifier ("**without** a discrete, contemporaneous, and affirmative instruction for that specific order"). Both must be satisfied for the definition to bite. The presence of "signal" among the nouns settles only that a signal *can* be an instance; it does not settle that any given signal *is* one. Where the End User supplies a discrete, contemporaneous, affirmative instruction for that specific order, the "without" limb fails and the definition is not met — **however completely the "indirectly" limb may be satisfied.**

**And the corollary, which is adverse and must be stated with the same force.** Because the qualifier is the **only** limiting element in the definition, **nothing else in the configuration's architecture does any work under §1.19**: not the separation of engine from runtime, not the member's authorship of every threshold and weight, not the locality of the runtime on the member's own machine, not the member-only credentials, not the absence of a broker code path in the engine. The concessive parenthetical "—whether deterministic, rules‑based, or otherwise—" pre-empts the answer that the rule is simple and member-written; the adverb "indirectly" and the nouns "process" and "workflow" are wide enough to reach a signal that is the but-for cause of the composed order. **The per-order act is the whole of the defence under §1.19.** S1a said this; this analysis confirms it from the grammar and makes the reason explicit.

**Element by element:**

- **"discrete" — one act, one order.** Satisfied on ordinary meaning: one explicit tap or swipe per composed order, one immutable instruction record per tap. Undefined in the agreement. Any batching, "confirm all", remembered consent or timeout auto-accept would read straight into §1.19.
- **"contemporaneous" — how much time may elapse?** **The document does not define it and sets no limit.** The word occurs three times (§1.19, §4.8, §4.9) and is never defined; §1.0's definitional rule reaches only capitalised terms; the agreement contains no interval anywhere — "seconds", "minutes" and "real-time" do not appear in it at all. The configuration displays the complete composed order and the member taps on that display immediately before transmission, which sits near the centre of any ordinary meaning. **But the outer bound is undrawn, and this register does not infer one.**
- **"specific instruction … for that particular order" — the tap is bound to the exact displayed terms.** This is the element the configuration satisfies most completely: the instruction record is bound to the exact displayed terms, member, account, source, scope, timestamp and nonce. It is corroborated mechanically by E*TRADE's own protocol — `previewId` "must specify the numeric preview ID from the preview and **the other parameters of this request must match the parameters of the preview**". The broker's own API enforces terms-binding between what was previewed and what is placed.
- **The price-and-time envelope — is re-pegging a new "order submitted through the API"?** **On E*TRADE's own documentation, yes.** There is no in-place amend. A change requires `PUT /orders/{orderId}/change/preview` followed by `PUT /orders/{orderId}/change/place`, the latter carrying a `PlaceOrderRequest` with its own `previewId`. E*TRADE's own field descriptions state the semantics: `replacedByOrderId` = "the order ID of the order that is **replacing** a prior order"; `replacesOrderId` = "the order ID of the order that **the new order** is replacing". **A re-peg produces a new order with a new order ID.** §4.9 requires that "**Each** order submitted through the API … be based on a discrete, contemporaneous, and specific instruction … **for that particular order**", and §1.19's verb list expressly includes "**modifies**". Two readings are available and **the agreement chooses neither**: (i) the member's tap was for the original order and is not contemporaneous with the replacement, so each automated re-peg is an order "deemed unauthorized"; (ii) the member's price band and re-peg rule, fixed in advance by his own hand, make the instruction "specific" as to the replacement. The adjective on which reading (i) turns — "contemporaneous" — is undefined. **This is a live exposure that S1a did not identify.** Note also that E*TRADE's protocol makes the compliant alternative mechanically available: a design that previews, displays and takes a tap for each re-peg satisfies §4.9 on either reading.
- **The end-of-day sweep.** §1.19 expressly reaches functionality that "**cancels** … an order through the API without a discrete, contemporaneous, and affirmative instruction for that specific order". An automated EOD cancel of the runtime's own resting orders has no contemporaneous per-cancellation instruction. It is caught by **§4.9's first sentence** (which prohibits engaging in the defined term, and the defined term includes cancelling) though **not by its second** (which speaks only of orders "submitted"). Recorded precisely because the distinction determines which sentence applies.
- **Standing execution — confirmed from the text that V2 is caught.** §4.9 first sentence: "Developer shall not implement, use, permit the use of, or design the Application or any related functionality to engage in Algorithmic or Automated Order Generation in connection with the API." A design that transmits without a per-order act is Automated Order Generation by definition. Prohibited outright — not conditioned, not thresholded, with "immediate suspension of API access and termination of this Agreement" stated. **§4.9 binds an Individual Use Developer on his own account too: no volume threshold, no de-minimis carve-out.**

**§4.8's power-of-attorney alternative, quoted in full as the brief required:**

> "**4.8 No Exercise of Discretion.** The Developer shall not create, initiate, or route any order on behalf of a third-party through the API unless the Developer has received explicit, contemporaneous instructions from the third-party authorizing such action. In the absence of such instructions, the Developer must possess a valid and enforceable **Power of Attorney ('POA')** from the third-party that specifically authorizes order placement and routing. Any order submitted without such authorization shall be deemed unauthorized and may result in immediate suspension of API access, termination of this Agreement, and potential legal liability."

The clause offers exactly two routes and no third. For V1 the first route is satisfied — the per-order tap is "explicit, contemporaneous instructions from the third-party". For V2 only the second remains, and it is a power of attorney specifically authorising order placement and routing — the paradigm instrument of discretionary authority, engaging FINRA Rules 3260(b) and (d)(1) and 4512(a)(3) and the §3(a)(35) analysis already in the register. **On E*TRADE, V2 and the avoidance of discretionary-authority characterization are mutually exclusive on the face of the text.**

## 4 · Is there a route through — does E*TRADE operate a Vendor path?

**Yes, a Vendor path exists and is published; its criteria are not.**

**What is published**, in full at C-09: a two-tier consumer-key system in which "a **vendor key** … permits access by multiple users and is appropriate for applications that may be widely distributed"; an eligibility floor of holding an E*TRADE account which "can be a personal, professional, or corporate account"; self-declaration of tier through the API questionnaire / User Intent Survey (§4.1: "Developer must specify (via the API questionnaire process) whether an Individual Use Key or a Vendor Use Key is appropriate based upon their intended usage"); and this, which is the entire published account of the approval process:

> "**Vendor keys will be provided immediately in page, but will be Inactive. E*TRADE will reach out to you via email to schedule your short online Vendor demo with Product and Legal teams. Upon approval of your access based on your demo, your key will be made active.**"

**Is a separate agreement signed? No — and this is a finding, not an absence of searching.** The Agreement Library index lists exactly one API instrument, "Application Program Interface (API) Developer License Agreement", under "Global Agreements". No Vendor-specific agreement is published anywhere located. **The same API Developer License Agreement governs both tiers**, sub-categorised internally by §1.7 — which is precisely why §4.9 binds an Individual Use Developer operating on his own account.

**Is any registration required of the vendor? No.** Keyword sweeps over both live copies return `broker-dealer` = 0, `broker dealer` = 0, `investment adviser` = 0 in the body, `registered representative` = 0. E*TRADE imposes **no securities-registration requirement or expectation on developers of either tier**, and no entity requirement — a natural person with a personal account qualifies. This is a material contrast with Interactive Brokers (S1a, A-04/A-06), which requires a registered company and a completed website to qualify for review, conducts enhanced due diligence with a three-tier compliance approval, generates a bilateral agreement through its Legal team, and states an expectation that third parties offering automated trading solutions hold applicable registration or furnish a legal opinion. **E*TRADE's control is substantive — §4.9 bans the conduct — where IBKR's is status-based: IBKR gates the person, E*TRADE gates the behaviour.**

**Are the criteria unpublished? Yes — and that is the finding.** Nothing published states what Product and Legal assess at the Vendor demo, what standard is applied, what causes rejection, or how long approval takes. Documented at Negative findings N-C4 with its endpoints. Three cautions follow from the published text itself: **Legal sits on the gate**; the criteria cannot be modelled in advance from public materials; and the demo is scheduled **after** the developer has completed the API Developer Agreement — that is, after accepting the text containing §4.9 — so the exposures at C-06 and C-07 are exactly what a demo would surface.

**On whether the configuration is in the Vendor tier at all:** it is, and nothing avoids it. §1.7 defines a Vendor Use Developer as one "exercising the rights under this Agreement **for multiple users and for Applications that may be more widely distributed**", and the Getting Started page states that an Individual key "will only work with your E*TRADE account. Attempting to use an individual key with a different user account **will result in an error**."

---

# Negative findings

Each with the endpoints, the exact queries and the counts. Absence documented, never inferred.

**N-C1 · The Agreement Library index carries no currency statement, no revision date and no version information.**
`https://us.etrade.com/l/f/agreement-library`, HTTP 200, 41,269 B, retrieved 7 Sep 2026. Case-insensitive counts over the rendered text and raw HTML: `effective` = **0**, `revised` = **0**, `updated` = **0**, `current as of` = **0**, `last modified` = **0**. No form number appears on the index itself (regex `[0-9]{4}-[A-Z]+-[A-Z0-9]+` → **0 matches**). The page lists "Application Program Interface (API) Developer License Agreement" under "Global Agreements" with `href="/l/f/agreement-library/api-developer-licensing-agreement"`. Its only self-description is *"Here are some of the key Agreements and Disclosures to help you do just that."* **The brief's hypothesis that the index might state which forms are current, or carry a newer revision date, is negatived on the primary source.**

**N-C2 · Neither copy of the agreement carries an effective date, a version number or a revision line.**
Both fetched live 7 Sep 2026. Both self-date only to "the date of your online acknowledgment ('Effective Date')". Copy A has **no form number**; Copy B has `0923-APIDEVLA-E68693`. **§11.8 makes "the most current version" governing but nowhere states where the most current version is published or how a developer is to identify it.**

**N-C3 · No page-level modification metadata is obtainable for `developer.etrade.com`, by any route tried.**
(a) `HEAD` with full browser headers → **403** (Akamai); no `Last-Modified` obtainable for any page on the host. (b) Copy A's HTML contains no `lastmod`, `dc:modified`, `dc:date` or `datemodified`; its meta tags are `title` ("Terms of Use"), empty `keywords`/`description`, and empty OG/Twitter tags. (c) AEM selector routes `terms-of-use.model.json`, `terms-of-use.infinity.json`, `terms-of-use.1.json` → all **HTTP 302, 225 B → `/pagenotfound`**. (d) AEM content API `/ctnt/dev-portal/getArticleByCategory?category=Support` and `…=Documentation` → **HTTP 302 → `/pagenotfound`**. (e) CDN asset stamps in the page HTML (`cdn2.etrade.net/1/26081920310.0/` = 19 Aug 2026 20:31, and six older bundles back to 2021) are **site-wide build tokens** — the identical newest stamp appears on `getting-started` — and do not date page content.

**N-C4 · E*TRADE publishes no Vendor-key review criteria, no separate Vendor agreement, and no vendor registration requirement.**
Endpoints swept 7 Sep 2026: `developer.etrade.com/getting-started` (HTTP 200, 8,787 B; 5 occurrences of "vendor", all quoted at C-09); `developer.etrade.com/support/frequently-asked-questions` (HTTP 200, 8,096 B; **"vendor" = 0 occurrences**); `developer.etrade.com/home` (HTTP 200, 7,329 B; **"vendor" = 0**); `us.etrade.com/l/f/agreement-library` (one API instrument listed, no Vendor-specific agreement). Keyword sweeps over both live copies of the agreement: `broker-dealer` = 0, `broker dealer` = 0, `investment adviser` = 0 in the body, `registered representative` = 0. **The published Vendor process consists of: complete the agreement and survey → receive an Inactive key immediately → E*TRADE emails to schedule "your short online Vendor demo with Product and Legal teams" → "Upon approval of your access based on your demo, your key will be made active." Nothing states the criteria applied at that demo.**

**N-C5 · The developer-portal release notes are not a change log for the agreement.**
`developer.etrade.com/support/release-notes`, HTTP 200, 6,799 B, retrieved 7 Sep 2026. **Exactly one entry**, date-stamped **9/14/2018**, describing the V1 API, the Swagger documentation and a Python sample app. A date-regex sweep (`[0-9]{1,2}/[0-9]{1,2}/[0-9]{4}`) over the whole page returns **that single date**. E*TRADE does not publish agreement changes here, and this route cannot date §4.9.

**N-C6 · No archive narrows the §4.9 window, and the reason is a crawl-coverage gap, not a block.**
Wayback CDX on Copy A's URL (`collapse=digest`, all statuses): **21 rows**, newest `20260509223240`. `archive.org/wayback/available` confirms it is the newest. Common Crawl 2026 collections queried individually: **2026-21** contains the terms page at `20260509223240` and nothing later; **2026-25 (7 Jun)** = 5 rows, **2026-30 (14 Jul)** = 6 rows, **2026-34 (7 Aug)** = 3 rows, **none including `/support/terms-of-use`**. `archive.ph/newest/…` → **404**, never captured. `timetravel.mementoweb.org` → DNS failure, defunct. Wayback Save Page Now → **HTTP 520**, no snapshot created. Sibling-page route: `developer.etrade.com/support` captured 9 May and 7 Jun 2026, **identical at 874 words apart from one server-instance token**, no signal.

**N-C7 · The agreement contains no time limit, and "contemporaneous" is nowhere defined.**
Counts over Copy A: `contemporaneous` = **3** (§1.19, §4.8, §4.9 — all three quoted above), `discrete` = 2, `affirmative` = 2, `specific instruction` = 1. `seconds` = **0**, `minutes` = **0**, `real-time` = **0**. A sweep of the definitions section (§§1.0–1.19) for `within [0-9]+`, `no more than`, `time limit`, `elapse`, `seconds`, `minutes`, `hours` returns **nothing**. §1.0 confines the definitional rule to capitalised terms; "contemporaneous" is lowercase throughout.

**N-C8 · The signature surface could not be read and was not attempted beyond an unauthenticated fetch. UNVERIFIED.**
`https://us.etrade.com/etx/ris/apisurvey/` and `…/#/agreement` → HTTP 200, **537 bytes**, a JavaScript shim whose only executable statement is `redirectToMfaLogin()`; following redirects lands on `https://us.etrade.com/e/t/user/login;jsessionid=…?TARGET=https%3A%2F%2Fus.etrade.com%2Fetx%2Fris%2Fapisurvey%2F`. `…/#/questionnaire` → identical, 537 B. `https://us.etrade.com/etx/ris/apikey` → same login redirect. Wayback CDX for `us.etrade.com/etx/ris*` → **28 rows, all 302**; never captured. **No credentials were entered; no account was created; no survey or application was submitted.** Which text is served at signature is **UNVERIFIED**.

**N-C9 · No public trace of the change exists anywhere reachable — and this does NOT narrow the date.**
A twelve-query open-web and code-forge sweep (C37–C55) located **zero** discussion of §1.19, §4.8, §4.9 or §7.5 anywhere outside E*TRADE's own site. Exact-phrase WebSearch on `"Prohibition on Algorithmic or Automated Order Generation"` → 10 hits, 0 relevant; on `"discrete, contemporaneous, and affirmative instruction"` → 9 hits, 0 relevant. GitHub code search for both phrases → `total_count: 0`. GitHub issue search across four query variants → `total_count: 0`. `jessecooper/pyetrade`, an actively-maintained E*TRADE API client (issues through 31 Jul 2026, commits through 15 May 2026), has **no mention of a terms change across 30 issues/PRs and 11 commits**. `nathanramoscfa/etradebot` — 21 issues, newest June 2024, nothing relevant.

**Two limits on this finding, both of which must travel with it.**
1. **reddit.com and stackoverflow.com are unreachable from this environment** (HTTP 400 / blocked user agent). Those two channels — the two most likely places for a retail-API developer to complain about a terms change — are **UNCHECKED, not cleared.**
2. **Absence of discussion is not evidence of a date.** A trading-focused article at `horizon.trade`, dated 26 June 2026, covering E*TRADE API automation limitations specifically, does not mention the clause (C53). It is tempting to read that as evidence the clause post-dates 26 June 2026. **That inference is not available and is not drawn here.** The article attributes E*TRADE bot limitations to authentication friction and a 2024 tool deprecation; it shows no sign of having consulted the developer-portal terms page at all, and a secondary writer's silence is not a survey. Per the commission's standing rule, safety and dates are not inferred from silence. **The bracket at Direct answer 2 stands unchanged.**

---

# Search log

All 7 September 2026. **"full headers"** = User-Agent (Chrome 139/macOS) + `Accept` + `Accept-Language` + `Cache-Control` + `Sec-Fetch-Dest/Mode/Site/User` + `Upgrade-Insecure-Requests` + `Referer` + `sec-ch-ua`/`-mobile`/`-platform`. `developer.etrade.com` and `us.etrade.com` require it; `apisb.etrade.com`, `web.archive.org` and `index.commoncrawl.org` do not.

| # | Source / query | Endpoint | Result / access note |
|---|---|---|---|
| C1 | Copy A, browser-UA headers only (no Referer/Cache-Control) | `developer.etrade.com/support/terms-of-use` | **HTTP 403, 406 B** — Akamai. Confirms S1a's access note and that the header set must be complete, not merely UA-spoofed. |
| C2 | Copy A, **full headers incl. `Referer: /home` + `Cache-Control` + `Sec-Fetch-Site: same-origin`**, three consecutive attempts | same | **HTTP 200, 19,467 / 19,464 / 19,464 B.** Stable. → C-01, C-03, C-06, C-08 |
| C3 | Copy B | `us.etrade.com/l/f/agreement-library/api-developer-licensing-agreement` | **HTTP 200, 68,055 B uncompressed** (19,546 B gzip, matching S1a). → C-01, C-03, C-05 |
| C4 | Agreement Library index | `us.etrade.com/l/f/agreement-library` | **HTTP 200, 41,269 B.** → C-01, N-C1 |
| C5 | Section-heading extraction, Copy A | local | 50 numbered headings, §1.0 → §11.10. §11.8 "Amendment; Waiver" identified as the amendment/integration clause. |
| C6 | §11 dump, both copies | local | **§11.8 byte-identical in both.** §11.1–11.7, 11.9, 11.10 identical except §11.2 (Copy A adds one sentence). → C-01 |
| C7 | Grep both copies: `supplement`, `client agreement`, `incorporat`, `entire under`, `effective date` | local | Preamble "supplements the … Client Agreement" in both; §11.8 integration clause in both. No reciprocal incorporation. → Direct answer 1 |
| C8 | **Normalised sentence-level diff, recitals → §11.10** | local (`difflib`, smart quotes/dashes/whitespace folded) | Complete diff at C-03. In A not B: §1.19, §4.8, §4.9, §7.5, §5.2 final sentence, §11.2 final sentence. In B not A: §4.5 End User written acknowledgment + 5-year retention. |
| C9 | Direction check: `"conflict"` | local | **1 occurrence in each copy** — the recital clause is in **both**. Not a Copy A addition. → C-02 |
| C10 | Direction check: `"the the Company"` | local | **Copy B = 1, Copy A = 0.** Copy A fixes a doubled article present in Copy B. → C-03 |
| C11 | §9.1 automatic-termination text, both copies | local | Substantively identical; punctuation differs in the opposite direction to §1.4, so punctuation gives no direction. → C-03, C-08 |
| C12 | **Wayback CDX, Copy A URL, `collapse=digest`, all statuses** | `web.archive.org/cdx/search/cdx?url=developer.etrade.com/support/terms-of-use&output=json&collapse=digest&fl=timestamp,statuscode,digest,length,mimetype` | **21 distinct-digest rows**, `20190825085540` → `20260509223240`. All ~10–11 kB WARC length. |
| C13 | **Raw `id_` retrieval of 6 sampled digests** spanning 2019–2026 | `web.archive.org/web/<ts>id_/…` | **All six are the ~2,459-word "E*TRADE API Non-Commercial License"**; `Automated Order Generation` = 0, `Power of Attorney` = 0, `1.19` = 0 in every one. → **C-04** |
| C14 | **Wayback CDX, Copy B URL, `collapse=digest`** | `…url=us.etrade.com/l/f/agreement-library/api-developer-licensing-agreement…` | **15 rows**, `20230401064137` → **`20260516073024` (16 May 2026, newest)**. |
| C15 | **Raw `id_` retrieval of 4 Copy B captures** (2023-04-01, 2025-12-27, 2026-02-08, **2026-05-16**) | `web.archive.org/web/<ts>id_/…` | 6,286 / 6,274 / 6,274 / **6,274** words; `Automated Order Generation` = **0** in all; form number `0923-APIDEVLA-E68693` present from Dec 2025 onward, absent Apr 2023. → **C-05** |
| C16 | Wayback CDX, whole host, 2026 | `…url=developer.etrade.com&matchType=domain&from=2026&limit=200` | 36 rows. Only `/support/terms-of-use` captures are `20260217111131` and `20260509223240`. Sibling captures exist at 7 Jun 2026. |
| C17 | **Sibling-page narrowing attempt** — `/support` hub, 9 May v. 7 Jun 2026, raw `id_`, text-diffed | `web.archive.org/web/20260509233933id_/…` and `…20260607083934id_/…` | **Identical, 874 words each, one server-instance token differs** (`168w201m1` → `170w201m1`). Link label "View our terms of use" on both. **No signal.** → N-C6 |
| C18 | Common Crawl collection list | `index.commoncrawl.org/collinfo.json` | 127 crawls; monthly indexes through **CC-MAIN-2026-34 (August 2026)**. |
| C19 | **Common Crawl, all 2026 collections + 2025-51**, prefix query | `index.commoncrawl.org/<coll>-index?url=developer.etrade.com%2F*&output=json` | 2026-12/-17/-25/-34 returned nginx **502/504** on first attempt; retried until answered. **2026-25 (7 Jun) = 5 rows; 2026-30 (14 Jul) = 6 rows; 2026-34 (7 Aug) = 3 rows — none include `/support/terms-of-use`.** CC timestamps match Wayback exactly, so CC is the crawler feeding these captures. → N-C6 |
| C20 | Common Crawl, exact terms URL, May 2026 | `…CC-MAIN-2026-21-index?url=developer.etrade.com%2Fsupport%2Fterms-of-use` | **1 row, `20260509223240`**, digest `3V4ZKT…` — matches Wayback. Confirms the coverage gap. |
| C21 | Common Crawl, Copy B URL, Aug 2026 | `…CC-MAIN-2026-34-index?url=us.etrade.com%2Fl%2Ff%2Fagreement-library%2Fapi-developer-licensing-agreement` | `{"message": "No Captures found"}` |
| C22 | archive.today | `archive.ph/newest/https://developer.etrade.com/support/terms-of-use` | **HTTP 404** — never captured. |
| C23 | **Wayback Save Page Now** (to create a citable snapshot of Copy A) | `web.archive.org/save/https://developer.etrade.com/support/terms-of-use` | **HTTP 520, failed.** Newest capture remains `20260509223240`. No snapshot created. |
| C24 | Page-embedded date metadata, Copy A | local grep of raw HTML | No `lastmod`/`dc:modified`/`dc:date`/`datemodified`. Meta tags: `title`="Terms of Use", empty `keywords`/`description`/OG/Twitter. CDN stamps 2021→`26081920310.0` (19 Aug 2026), **site-wide, not page-specific**. → N-C3 |
| C25 | AEM selector + content-API probes | `…/terms-of-use.model.json`, `.infinity.json`, `.1.json`; `/ctnt/dev-portal/getArticleByCategory?category=Support` and `=Documentation` | **All HTTP 302, 225 B → `/pagenotfound`.** No `jcr:lastModified` obtainable. → N-C3 |
| C26 | Developer-portal release notes | `developer.etrade.com/support/release-notes` | **HTTP 200, 6,799 B. One entry, 9/14/2018.** Date regex over whole page → that single date. → N-C5 |
| C27 | **Order API reference** | `apisb.etrade.com/docs/api/order/api-order-v1.html` | **HTTP 200, 56,924 B gzip / 27,052 words.** Plain curl works. Five endpoints: Preview, Place, Cancel, **Change Previewed Order**, **Place Changed Order**. → **C-07** |
| C28 | Change-order semantics | local grep of #C27 | `replacedByOrderId` / `replacesOrderId` field descriptions recovered verbatim; `previewId` "must match the parameters of the preview" — **3 occurrences**. → **C-07** |
| C29 | E*TRADE's own preview→confirm message text | local grep of #C27 | Error codes 20109, 9050, 9051 recovered verbatim ("please click the Change Order link… Otherwise, please click the Place Order button"). → C-07 |
| C30 | Getting Started | `developer.etrade.com/getting-started` | **HTTP 200, 8,787 B**, 5 occurrences of "vendor". Vendor-key process recovered verbatim. → **C-09** |
| C31 | Link extraction, Getting Started + Copy A | local | "STEP 2: API AGREEMENT" → `https://us.etrade.com/etx/ris/apisurvey/#/agreement`; "STEP 1" → `…/#/questionnaire`; sandbox key → `us.etrade.com/etx/ris/apikey`. Both pages' footers link "Account Agreements and Disclosures" → `us.etrade.com/l/f/agreement-library#tab_0` (**i.e. to Copy B**). → C-05, N-C8 |
| C32 | Developer FAQ | `developer.etrade.com/support/frequently-asked-questions` | **HTTP 200, 8,096 B. "vendor" = 0.** Content is stale relative to Getting Started (says keys take "a few business days"; Getting Started says "immediately in page"). No approval criteria. → N-C4 |
| C33 | Developer home | `developer.etrade.com/home` | HTTP 200, 7,329 B. **"vendor" = 0.** → N-C4 |
| C34 | Signature surface, unauthenticated, follow redirects | `us.etrade.com/etx/ris/apisurvey/` and `…/#/questionnaire` | **HTTP 200, 537 B**, JS shim, sole statement `redirectToMfaLogin()`; final URL `us.etrade.com/e/t/user/login;jsessionid=…?TARGET=…`. **Not authenticated.** → N-C8, ◇C1 |
| C35 | Sandbox key request endpoint, unauthenticated | `us.etrade.com/etx/ris/apikey` | Same login redirect. **Not authenticated; no key requested.** → N-C8 |
| C36 | Keyword sweeps over both copies | local | `contemporaneous` = 3 (never defined), `seconds`/`minutes`/`real-time` = 0, no interval in §§1.0–1.19; `broker-dealer` = 0, `investment adviser` = 0 in body, `registered representative` = 0. → N-C4, N-C7 |
| C37 | WebSearch, exact phrase | `"Prohibition on Algorithmic or Automated Order Generation"` | **10 hits, 0 relevant** (US patents; algorithmic-*pricing* legislation). |
| C38 | WebSearch, exact phrase | `"discrete, contemporaneous, and affirmative instruction"` | **9 hits, 0 relevant** (autism therapy; jury instructions). |
| C39 | WebSearch | `etrade api "Automated Order Generation" developer license agreement` | 7 hits, **0 containing the phrase**. |
| C40 | WebSearch | `etrade api no longer allowed automated trading 2026 terms change` | 7 hits, 0 relevant. |
| C41 | WebSearch | `etrade api terms of use updated 2026 "No Exercise of Discretion" OR "power of attorney" developer` | 7 hits, **0 containing either phrase**. |
| C42 | WebSearch | `"E*TRADE" API developer license agreement 2026 revised new sections algorithmic` | 7 hits, 0 relevant. |
| C43 | WebSearch | `etrade api "vendor key" approval process demo application` | 8 hits, 1 useful (the Getting Started page already at C-09). |
| C44 | WebSearch, site-restricted | reddit.com — etrade api terms of use change 2026 algotrading | **BLOCKED — HTTP 400; reddit.com not reachable from this environment. This channel is UNCHECKED, not cleared.** |
| C45 | WebSearch, site-restricted | stackoverflow.com / HN / github.com — etrade api automated trading prohibited terms 2026 | **BLOCKED — stackoverflow.com not reachable from this environment. UNCHECKED, not cleared.** |
| C46 | GitHub code search | `"Prohibition on Algorithmic or Automated Order Generation"` | **total_count: 0** |
| C47 | GitHub code search | `"Automated Order Generation" etrade` | **total_count: 0** |
| C48 | GitHub issue search | E*TRADE API terms change / automated order generation / consumer key revoked (4 query variants) | **total_count: 0** on every variant. |
| C49 | GitHub REST | `jessecooper/pyetrade` — 30 newest issues/PRs (state=all), through 2026-07-31 | **0 mention terms, agreement or automation prohibition.** Repo is actively maintained. |
| C50 | GitHub REST | `jessecooper/pyetrade` — commits since 2026-03-01 | 11 commits through 2026-05-15, **0 relevant**. |
| C51 | GitHub REST | `nathanramoscfa/etradebot` — issues, state=all | 21 issues, newest **2024-06-16**, 0 relevant. |
| C52 | GitHub REST | `etrade-python-client/etrade-python-client` | **HTTP 404 — repo does not exist at that path.** |
| C53 | WebFetch, secondary | `horizon.trade/blog/e-trade-algorithmic-trading-navigating-automated-portfolios-and-api-bot-limitations`, publication date shown **26 June 2026** | HTTP 200. **LEAD ONLY, secondary — not citable as authority.** Discusses E*TRADE API bot limitations but attributes them to manual-authentication friction and a Feb 2024 tool deprecation; **does not mention §4.9, §1.19 or any 2026 terms change.** See N-C9 for why this does **not** narrow the bracket. |
| C54 | Independent re-fetch of Copy B (corroboration of C3/C15) | `us.etrade.com/l/f/agreement-library/api-developer-licensing-agreement`, live, separate client | HTTP 200, 68,055 B. **Definitions run 1.1→1.18; §4 runs 4.1→4.7; §7 runs 7.1→7.4.** `Algorithmic`, `Automated Order`, `contemporaneous`, `power of attorney`, `No Exercise of Discretion`, `Unauthorized Use; No Company Liability` — **all 0 occurrences.** Confirms C-05 by an independent route. |
| C55 | Wayback CDX, Getting Started page | `…url=developer.etrade.com/getting-started` | 15 captures, **latest 2025-07-26**. No 2026 capture — the Vendor-key text cannot be archive-dated within 2026. |

---

# ◇ list — resting on secondary confirmation only, or unverified; flagged for primary verification

**◇C1 · Which text is served at the signature surface. UNVERIFIED — and it is the single highest-value open item in this track.**
`https://us.etrade.com/etx/ris/apisurvey/#/agreement` returns HTTP 200 / 537 B unauthenticated, a JS shim calling `redirectToMfaLogin()`, redirecting to `us.etrade.com/e/t/user/login…`. Wayback has never captured it (CDX `us.etrade.com/etx/ris*` → 28 rows, all 302). If that surface serves Copy B's text, the instrument a developer actually acknowledges lacks §1.19, §4.8, §4.9 and §7.5, and the analysis at C-06 to C-08 would need revisiting. **Closing it requires an authenticated E*TRADE session or written confirmation from E*TRADE Legal.** Neither was attempted; authentication was out of bounds for this commission.

**◇C2 · The chronological ordering of Copy A and Copy B. Level 2 — documentary inference, not a date stamp.**
Copy A being the later revision rests on the form number, the redline relationship (including the doubled-article fix), and the archive gap. It does **not** rest on any effective date, because neither instrument bears one. The inference is strong and three-stranded but it is an inference, and it is labelled as one throughout. Primary verification would be an E*TRADE statement of the revision date.

**◇C3 · The precise date §4.9 went live. Cannot be narrowed below a four-month window on any public source.**
After 2026-05-09 22:32:40 UTC, on or before 2026-09-07. Nine independent routes were tried and are logged at C12–C26 and N-C6. Primary verification would be an E*TRADE change log or a statement from E*TRADE Legal; the developer portal's release-notes page has one entry from 2018 and is not a change log.

**◇C3a · Two search channels were unreachable and remain UNCHECKED.**
`reddit.com` (HTTP 400) and `stackoverflow.com` (blocked user agent) could not be searched from this environment. They are the two channels where a retail-API developer would most plausibly have recorded a dated reaction to the change. N-C9's negative result therefore covers the open web, GitHub code and GitHub issues, but **not** those two. Anyone re-running this should try them from an environment that can reach them; a dated developer complaint would narrow ◇C3 directly.

**◇C4 · The Vendor-demo review criteria. Unpublished; documented as a negative at N-C4.**
That Product and Legal review, and that approval gates key activation, is published. **What they assess is not.** Primary verification is only obtainable from E*TRADE.

**◇C5 · Whether "the Developer" or the member "creates, initiates, or routes" the order under §4.8 when the composing software runs on the member's own machine under the member's own credentials.**
Both readings are available on the text; neither is adopted by any located E*TRADE document. Does not affect V1's outcome under §4.8 (the first limb is satisfied by the per-order tap) but would matter to any design that weakened the tap.

**◇C6 · Whether an automated re-peg within a member-set band satisfies §4.9's "discrete, contemporaneous, and specific instruction … for that particular order".**
Two readings set out at C-07 and Direct answer 3. **The agreement chooses neither and "contemporaneous" is undefined.** No located E*TRADE document, and no authority in the P1–P7 register, addresses whether a prior member-set price band constitutes a contemporaneous specific instruction for a replacement order generated under it.


---

# S2 · TRACK 2 — Survivors: products operating for years in a shape close to this configuration, and their regulatory history

**Researcher note on scope and honesty.** This track was commissioned on the premise that survivors are evidence *if the absence of enforcement is documented rather than assumed*. Two things must be said at the top, because they govern how everything below should be read.

**First — the headline is not what the premise expected.** The hosted survivor closest in shape to the configuration (Composer) did **not** survive unregistered. It registered as an SEC investment adviser *before* it took its first live order, on flat-subscription-fee economics, with user-authored rules, and told the Commission its accounts were **100% discretionary**. That is an adverse finding and it is reported first, not buried.

**Second — the strongest support is architectural, not enforcement-based.** TradingView publishes an order-flow architecture (`client → broker, TradingView's server not involved`) that is a close published analogue of the configuration's credential and transmission design, at ~100M users and 100+ integrated brokers, with no registration anywhere and no located enforcement.

**Access walls that limit this track** (stated up front so nothing below is over-read):
- **FINRA disciplinary actions online is behind a Cloudflare JS challenge.** I could not obtain a single valid result, positive or negative. **No FINRA disciplinary silence is claimed anywhere in this document.** See Negative Findings §N7 and Search Log #48–#50.
- **NFA BASIC blocks programmatic access** (its JSON-RPC endpoint returns `success:false` for every parameter signature probed). NFA registration status for these vendors is **UNVERIFIED**. See §N8.
- **CourtListener rate-limits anonymous callers at 50 requests/hour.** Paced quoted runs closed **48 of 56** queries; the 8 that failed are recorded as **THROTTLED**, never as zero (§N6). That sweep also surfaced **five private suits naming survivor vendors as parties** — including one against TradeStation's *software* entity. **I retrieved only case names, courts and dates, and I do not assert what any of them was about.** They are the track's highest-value open item.

---

## Register entries

### S2-01 · Composer Technologies Inc., Form ADV Part 1A, Annual Amendment filed 3/14/2024 (CRD 311289; SEC File No. 801-119952) · `https://reports.adviserinfo.sec.gov/reports/ADV/311289/PDF/311289.pdf` · retrieved 7 Sep 2026
- **Type:** Registration filing (Form ADV Part 1A), sworn
- **Date / status:** Filed 3/14/2024. Registration **TERMINATED effective 12/6/2024** (IAPD `registrationStatus`: `{"secJurisdiction":"SEC","status":"Terminated","effectiveDate":"12/6/2024"}`; `orgScopeStatusFlags`: `isSECRegistered":"N","isStateRegistered":"N","isERARegistered":"N"`).
- **Verbatim, pin-cited** (Item 5.E, Compensation Arrangements — the **only** box checked):
  > "(7) Other (specify): SUBSCRIPTION FEES"

  Boxes **not** checked: "(1) A percentage of assets under your management"; "(5) Commissions"; "(6) Performance-based fees".

  (Item 5.F.(1)): > "Do you provide continuous and regular supervisory or management services to securities portfolios?" — answered **Yes**.

  (Item 5.F.(2)):
  > "Discretionary: (a) $ 46,700,000 … (d) 2,948
  > Non-Discretionary: (b) $ 0 … (e) 0
  > Total: (c) $ 46,700,000 … (f) 2,948"

  (Item 5.G, Advisory Activities — the **only** box checked):
  > "(2) Portfolio management for individuals and/or small businesses"

  Boxes **not** checked include "(8) Publication of periodicals or newsletters" and "(10) Market timing services".

  (Item 8.C, Investment or Brokerage Discretion): > "Do you or any related person have discretionary authority to determine the: (1) securities to be bought or sold for a client's account?" — **Yes**. "(2) amount of securities to be bought or sold for a client's account?" — **Yes**.

  *(Item 5.E, 5.F, 5.G checkbox states read from a 150-dpi render of p.8 of the PDF; Item 8.C from p.15. The checkbox glyphs do not survive text extraction — they were read visually, per shared-context §4.)*
- **What it establishes:** A platform whose users author their own rules, compensated by a **flat subscription fee and nothing else**, registered with the SEC as an investment adviser, characterised its service as **portfolio management** rather than publication, and reported **every dollar and every one of 2,948 accounts as discretionary**, answering "Yes" to discretionary authority over both the security and the amount.
- **Q1 / Q2 / Q3:** **Q1 ADVERSE (strong). Q3 ADVERSE.** Q2 NEUTRAL.
- **Level 1** — a sworn federal registration filing by the closest commercial analogue; not an authority interpreting law, but the highest-grade evidence of how a market participant in this shape characterised itself to the Commission.
- **Application note:** The configuration's economics are the same in kind as Composer's — a flat monthly membership, nothing per trade, on volume, on assets or on performance. Composer's Item 5.E shows that *flat-subscription compensation did not keep a user-authored-rules platform out of adviser registration*; it checked "SUBSCRIPTION FEES" and registered anyway. This connects directly to *Weiss Research* (IA-2525), already in the register, where a flat annual fee did not prevent §202(a)(11) being met. The configuration distinguishes itself on **discretion**, not on fee: Composer answered "Yes" to Item 8.C(1) and (2) and reported non-discretionary AUM of exactly $0, whereas the configuration grants discretionary authority to nobody in V1 and every order is minted by an explicit member act on a runtime-owned surface. That is the whole of the distance, and it is a factual distinction about discretion, not about compensation or about who wrote the rule. Note also what Composer did **not** claim: it did not check Item 5.G(8) "Publication of periodicals or newsletters", i.e. it did not position itself under the *Lowe* publisher's exclusion.

### S2-02 · Composer, homepage as archived 9 Sep 2021 · `https://web.archive.org/web/20210909065710/https://www.composer.trade/` · retrieved 7 Sep 2026
- **Type:** Published vendor description (archived)
- **Date / status:** Snapshot 9 Sep 2021 — the earliest Wayback capture of the domain (CDX first snapshot `20210909065710`).
- **Verbatim:**
  > "Composer acts as a layer on top of brokerages."

  > "Live trading available with our brokerage partner, Alpaca."

  > "Composer is a registered investment advisor with the US Securities and Exchange Commission (SEC). While such registration does not imply a certain level of skill, it does require us to follow federal regulations that protect you, the investor. By law, we must provide investment advice that is in the best interest of our client."

  And from the snapshot of 2 Mar 2022 (`https://web.archive.org/web/20220302061408/https://www.composer.trade/`):
  > "Composer is an automated trading platform."

  > "No more spreadsheets, no more manual trades. Create dynamic strategies with a no-code visual editor. Watch your trades execute automatically."

  > "To invest, connect Composer to an account with our brokerage partner, Alpaca."
- **What it establishes:** At the point Composer was a "layer on top of brokerages" connecting to the user's **own** account at a third-party broker — architecturally the nearest thing located to the configuration — it was **already** asserting SEC investment-adviser registration. It did not operate in that shape unregistered and later register; the registration was there from the first archived day.
- **Q1 ADVERSE.** Q2 NEUTRAL. Q3 ADVERSE.
- **Level 2** — vendor's own contemporaneous published statement, date-stamped by archive, corroborated by the Form ADV at S2-01.
- **Application note:** This is the single most directly comparable commercial precedent located, and it runs against the configuration on Q1. The distinguishing facts available are: (i) Composer executed **without a per-order human act** ("Watch your trades execute automatically"), whereas the configuration mints each order by one explicit tap on a runtime-owned surface; (ii) Composer's rebalancing was continuous and unattended, which is what Item 5.F.(1) "continuous and regular supervisory or management services" records. Nothing located shows Composer ever offered a per-order-approval mode, so the comparison cannot be pushed further than that.

### S2-03 · Composer, status sentence removed between Sep 2024 and the live page · `https://www.composer.trade/disclosures` (live) vs. `https://web.archive.org/web/20240914154603id_/https://www.composer.trade/_next/data/5SDj8zr4Gq6dfxf0MJL9K/legal/advisory-agreement.json` · retrieved 7 Sep 2026
- **Type:** Published terms, change over time (the Wayback diff the brief asked for)
- **Date / status:** Adviser sentence present 14 Sep 2024; absent on the live page 7 Sep 2026.
- **Verbatim — present 14 Sep 2024, on a page titled "Advisory Agreement":**
  > "Composer is a registered investment adviser with the US Securities and Exchange Commission (SEC). While such registration does not imply a certain level of skill, it does require us to follow federal regulations that protect you, the investor. By law, we must provide investment advice that is in the best interest of our client. Please refer to Composer's ADV Part 2A Brochure for important additional information."
- **Verbatim — live page, 7 Sep 2026, with the adviser sentence gone and replaced by a broker-dealer sentence:**
  > "Securities products and brokerage services are offered by Composer Securities LLC, a broker-dealer registered with the SEC and member of FINRA / SIPC. Composer Securities LLC and Composer Technologies Inc. are separate but affiliated companies. Accounts are carried and securities execution, clearance and settlement services are provided by Alpaca Securities LLC, and Apex Clearing Corporation, SEC-registered broker-dealers and members of FINRA / SIPC."

  The live page also states: > "Big news: Composer has joined SoFi!"

  The live site's primary navigation label is now > "Trade with AI" — where the 2021 site's proposition was > "Composer allows you to create custom automated investing strategies." That shift, from *the user composes the rule* toward *the product generates it*, moves Composer further from the configuration on the one axis the configuration most depends on, and should be kept in mind before treating present-day Composer as the comparator. The Form ADV evidence at S2-01 is from **March 2024**, i.e. from the user-authored era, which is why it is the version relied on.
- **Corroborating archive structure:** a `/legal/advisory-agreement` route is present in the Wayback URL index for the 14 Sep 2024 build (`_next/data/5SDj8zr4Gq6dfxf0MJL9K/legal/advisory-agreement.json`) and **absent** from the 4 Dec 2025 build (`9AhvAFSRk0dgtogjvfSEh`) and the 4 Apr 2026 build (`3M4z4mc9Vwq_sItdhocXQ`), whose legal routes are only `disclosures`, `payment-agreement`, `privacy-policy`, `terms-of-service`.
- **What it establishes:** The disappearance of the advisory agreement and of the adviser status sentence tracks the Form ADV termination date of **12/6/2024** exactly. Composer moved from *registered adviser + user's own outside brokerage account* to *its own registered broker-dealer with Apex/Alpaca clearing*.
- **Q1 NEUTRAL / context. Q2 ADVERSE (weak).**
- **Level 2** — archived primary text plus the IAPD registration record.
- **Application note:** The brief asked whether anything suggests a status statement was ever tested. Here the wording did not merely change — the *entity structure* changed underneath it. The direction of travel is the point: Composer did not shed regulated status, it swapped adviser registration for **broker-dealer** registration. A vendor in this shape that grows toward carrying the customer relationship ended up registered as a BD, not deregulated. That bears on Q2 as a commercial-practice data point only; it is not an SEC statement about what §3(a)(4) requires.

### S2-04 · Composer Securities LLC · FINRA BrokerCheck / IAPD firm record, CRD 325118, SEC File No. 8-71057 · `https://api.adviserinfo.sec.gov/search/firm?query=Composer` · retrieved 7 Sep 2026
- **Type:** Registration record
- **Verbatim (record fields):**
  > `"firm_name": "COMPOSER SECURITIES LLC"`, `"firm_bd_full_sec_number": "8-71057"`, `"firm_scope": "ACTIVE"`, `"firm_disclosure_fl": "N"`, `"firm_approved_finra_registration_count": 1`, `"finraLastApprovalDate": "2023-09-12T00:00:00"`, address `"2750 EAST COTTONWOOD PARKWAY #300, COTTONWOOD HEIGHTS, UT"`.
- **What it establishes:** Composer's broker-dealer arm was FINRA-approved **12 Sep 2023** and carries **no disclosure events** (`firm_disclosure_fl: "N"`). EDGAR full-text confirms it files annual audited BD reports: form **X-17A-5**, filed 2026-03-31, file number 008-71057, CIK 0001965825.
- **Q2 ADVERSE (weak, as commercial practice).**
- **Level 1** for the fact of registration; **not** an authority on what registration requires.
- **Application note:** `firm_disclosure_fl: "N"` is the one clean, FINRA-sourced negative available in this track: Composer Securities has no disclosure events. This is *not* a substitute for a FINRA disciplinary-database search, which I could not run (§N7).

### S2-05 · QuantConnect Terms of Use §3.6, "No Investment Advice; Not an Investment Advisory Service" · `https://www.quantconnect.com/terms` · retrieved 7 Sep 2026
- **Type:** Published terms (vendor status statement)
- **Date / status:** Live page, undated on its face.
- **Verbatim, §3.6:**
  > "The Company is not an investment advisory service, nor is it a registered investment advisor or broker-dealer and does not purport to tell or suggest the value of any securities or which securities customers should buy or sell for themselves."

  and, in the same section:
  > "In addition, the indicators, strategies, columns, articles and all other features of the Site are provided for informational and educational purposes only and should not be construed as investment advice. Examples presented on the site are for educational purposes only. Such set-ups are not solicitations of any order to buy or sell."
- **What it establishes:** An explicit, sectioned, dual-status disclaimer — neither adviser nor broker-dealer — by a platform that runs users' own algorithms live against the users' own brokerage accounts.
- **Q1 SUPPORT. Q2 SUPPORT.** (Both weak: a self-description binds nobody. NASD NTM 01-23 and *Ranieri/Phillips*, both already in the register, hold that a disclaimer does not discharge the obligation and that counsel-drafted role limits are disregarded where conduct does not match.)
- **Level 3** — published terms of a long-operating participant; probative of market practice, not of law.
- **Application note:** The wording tracks the configuration's own marketing rule (software tools, never a trading, execution or signal service). Its evidential value is that it has stood, in this form, on a platform doing live automated order transmission, without a located challenge — see §N1 and §N3 for exactly how far that silence is documented and how far it is not.

### S2-06 · QuantConnect, Interactive Brokers live-trading documentation — the credential question · `https://www.quantconnect.com/docs/v2/cloud-platform/live-trading/brokerages/interactive-brokers` · retrieved 7 Sep 2026
- **Type:** Published vendor operating documentation
- **Verbatim:**
  Under heading **"Account Credentials"** (within "Security and Stability"):
  > "When you deploy live algorithms with IB, we don't save your credentials."

  Under heading **"API Outages"**:
  > "We call the IB API to place live trades."

  From the deployment instructions:
  > "Enter your IB user name, ID, and password. Your account details are not saved on QuantConnect."

  Also: > "By default, IB only supports one connection at a time to your account. If you interfere with your brokerage account while an algorithm is connected to it, the algorithm may stop executing."
- **What it establishes:** A hosted vendor that (i) takes the **user's own broker credentials**, (ii) states it does **not persist** them, and (iii) states that **its own servers call the broker's API to place the trades**, operating unattended with no per-order human act.
- **Q2 SUPPORT (moderate). Q3 NEUTRAL.**
- **Level 2** — vendor's own operating documentation, unambiguous on the mechanics.
- **Application note:** This is the **closest located analogue on the credential axis** and it is more aggressive than the configuration in every direction that matters: QuantConnect is **hosted** (the configuration's runtime is local, on the member's own machine); the credential passes **through the vendor's servers** (the configuration's trade-capable credential exists only in the member's local keychain and never leaves it); and there is **no per-order human act** (the configuration mints each order by an explicit tap). QuantConnect has no SEC or FINRA registration of any kind (§N4) and no located enforcement (§N1–§N3). The configuration is strictly more conservative than this survivor on every one of those three axes. That is the strongest survivor-based support in this track — and it is support by *comparison to unchallenged practice*, not by any authority.

### S2-07 · TradingView, Broker Integration Manual, "Integration overview" — order-flow architecture · `https://www.tradingview.com/broker-api-docs/integration-overview/` · retrieved 7 Sep 2026
- **Type:** Published vendor technical documentation
- **Verbatim**, under heading "Trading integration issues → How trading integration works":
  > "The trading integration uses a client-server architecture: requests from the user's browser are sent directly to the broker's server. **The TradingView server is not involved in this data exchange.** An exception is a request to /permissions. It is sent from the TradingView server to give the user access to the data."

  And under "Integration architecture → What are the parts of the integration":
  > "The broker's integration consists of two independent parts: data integration based on a server-to-server architecture and trading integration based on a client-server architecture."

  On credentials, the only credentials the document assigns to TradingView are **data-feed** credentials, not trading credentials:
  > "The data is requested only by our API client applications running on the servers. The end-user browser never makes requests to these endpoints. TradingView client applications use a separate set of credentials per environment by default (if authorized)."

  And on the homepage of the same manual (`https://www.tradingview.com/broker-api-docs/overview/`):
  > "The Broker Integration API lets brokers connect their backend systems to the TradingView interface, so that the broker partners can be supported on the TradingView Web Platform."
- **What it establishes:** In the largest deployed instance of this pattern, the **broker** implements the trading endpoints, the user authenticates to the **broker** (PasswordBearer or OAuth2Bearer with the broker as authorization server), and the order request goes **from the user's client straight to the broker's server without transiting the software vendor's infrastructure**. The vendor renders the ticket; the vendor holds no trading credential.
- **Q2 SUPPORT (strong as market practice). Q3 SUPPORT.**
- **Level 2** — the vendor's own published technical specification, unambiguous and current.
- **Application note:** This is the closest published architecture to the configuration's core design claims — "orders go through the member's broker's own published retail API under the member's own credentials", "no company-level or app-level trading credential", "no routing decisions". TradingView goes further than the configuration in one respect that cuts *against* it (see S2-08: it openly sells customer acquisition to brokers, which is the *Neovest* ¶3 conduct) and less far in another (TradingView renders a manual ticket; it does not compose an order from a stored policy and does not fire on a rule). It has **no SEC or FINRA registration of any kind** (§N4) and no located enforcement (§N1–§N3).

### S2-08 · TradingView, "Brokerage Integration to TradingView: Grow Your Business" · `https://www.tradingview.com/brokerage-integration/` · retrieved 7 Sep 2026
- **Type:** Published vendor marketing to brokers
- **Verbatim:**
  > "Top gear for your brokerage. Integrate with the world's largest trading ecosystem to drive business growth."

  > "20K+ Leads distributed monthly"; "100+ Integrated brokers partners"; "100M+ Users from 200+ countries"

  > "Let traders come to you. Reach out to our vibrant community of diverse market enthusiasts, expand your audience, and nurture new customers."

  > "Generate high-quality leads. Acquire new customers from our 100 million-strong audience with the Open account button that allows you to transfer leads directly to your sign-up page."
- **What it establishes:** A software vendor in this shape openly and continuously markets **customer acquisition for brokers** as its commercial proposition to those brokers, at scale, with a metered lead count.
- **Q2 ADVERSE.**
- **Level 2** — the vendor's own current marketing page.
- **Application note:** This is squarely the conduct *In re Neovest* ¶3 and ¶14 identified — "solicitation of customers for those services" — and the shared context records that no authority defines that phrase. TradingView performs it at scale and no enforcement against it was located (§N1–§N3). **This does not make the conduct lawful and must not be read as if it did**; it is documented unchallenged practice, and P7 already records that inferring safety from silence is forbidden. Its actual use is narrower and real: it shows that the *Neovest* solicitation limb has not, on the located record, been applied to a software vendor that takes **no transaction-based compensation**. *Neovest* found transaction-based compensation **and** solicitation together. The configuration has neither — no payment from brokers or issuers at all, and a marketing rule against selling itself as a trading or execution service. Against TradingView, the configuration is the more conservative case on this axis by a wide margin.

### S2-09 · NinjaTrader Terms of Service Agreement §1(a) · `https://ninjatrader.com/downloads/TermsOfServiceAgreement.pdf` · retrieved 7 Sep 2026
- **Type:** Published terms (EULA)
- **Date / status:** Live document. Wayback digest `GRTCXG2YXRZSGN2FBZXZUFGN4HNWR3GU` is **byte-identical from 13 Jul 2017 through 27 Mar 2025** across 6 captures. A materially different version is captured 21 Apr 2016 (digest `C5YRF5LEO2BUWCYLN23SZUOBUMSDZ4MO`).
- **Verbatim, §1(a) "Description":**
  > "Software/Service is an order entry and trading application for transactions involving, but not limited to, stocks, futures, exchange traded funds, mutual funds, single stock futures, options, and currency orders (collectively "Orders") that interfaces through an Application Protocol Interface ("API") or Software Development Kit ("SDK"). These systems may be based on software platforms developed by various other third party brokers and/or software developers (collectively "Broker Platforms"). Orders may be executed by brokers via Broker Platforms."
- **THE STATUS STATEMENT THAT IS NOT THERE.** Across the whole 11-section, 3,415-word agreement, machine-counted:
  | term | occurrences |
  |---|---|
  | "broker-dealer" / "broker dealer" | **0** |
  | "investment advice" | **0** |
  | "investment adviser" / "advisor" | **0** |
  | "not a broker" | **0** |
  | "recommend" | **0** |
  | "registered" | **0** |
  | "solicit" | 1 — and it is in §5, prohibiting users from sending "unsolicited commercial e-mail" |

  The same counts are **0** in the materially different 21 Apr 2016 version (3,427 words).
- **What it establishes:** A platform that has shipped since at least May 2003 (earliest Wayback capture of `ninjatrader.com`: `20030529100106`), which describes its own product to its users as "**an order entry and trading application**", has **never**, in the decade of terms text recoverable, asserted that it is not a broker-dealer, not an adviser, or that it does not give advice.
- **Q1 SUPPORT (weak). Q2 SUPPORT (weak).**
- **Level 3** — published terms; the absence is documented across archived versions, which is what makes it usable.
- **Application note:** The brief asked whether a status sentence was ever added or removed over time. For NinjaTrader the answer is that **there was never one to add or remove**, and the document sat frozen for eight years. This is the opposite of the configuration's posture, which leans on an express marketing rule and a status position. It is evidence that a locally-installed order-entry application has operated for ~23 years at scale without ever feeling the need to disclaim broker or adviser status — and, equally, evidence that no such disclaimer is what protected it.

### S2-10 · NinjaTrader — what the group actually became · `https://ninjatrader.com/terms-of-service/` (live homepage served at that path) and `https://ninjatrader.com/disclosures/` · retrieved 7 Sep 2026
- **Type:** Published vendor description
- **Date / status:** Live. Note: `ninjatrader.com` soft-404s unknown paths to a marketing homepage; `/terms-of-service/` and `/disclaimer/` returned byte-identical marketing pages (79,043 bytes each), **not** legal text. The operative terms document is the PDF at S2-09.
- **Verbatim, live marketing page:**
  > "Trade on the #1 Rated Futures Platform… **Regulated. Transparent. More Control.**"

  > "Open a Live Account"; "Over 2.5MM accounts"; "Commissions from $0.09–$1.29 per trade."
- **What it establishes:** NinjaTrader is no longer usefully describable as a third-party software vendor sitting beside somebody else's broker. The group now runs its own regulated futures brokerage and prices per-trade commissions.
- **Q2 — distinguishing fact, not evidence.**
- **Level 3.**
- **Application note:** NinjaTrader's survival therefore cannot be offered as evidence that an *unaffiliated* software vendor survives, because the modern NinjaTrader is the broker. Its value to this track is confined to the historical terms record at S2-09 and to the CFTC action at S2-11, which is against the FCM entity.

### S2-11 · *In re NinjaTrader Clearing, LLC*, CFTC Docket No. 24-27 (23 Sep 2024) · `https://www.cftc.gov/media/11316/enfninjatraderclearingorder092324/download` · retrieved 7 Sep 2026
- **Type:** Enforcement order (CFTC, settled, admissions)
- **Verbatim:**
  > "the Commission has reason to believe that beginning no later than December 31, 2020 to the present ("Relevant Period"), NinjaTrader Clearing, LLC dba NinjaTrader, Tradovate and TransAct Futures ("NTC" or "Respondent") violated Regulation 166.3, 17 C.F.R. §166.3 (2023)"

  > "Respondent, a registered futures commission merchant ("FCM"), violated Regulation 166.3, 17 C.F.R. § 166.3 (2023), by failing to diligently supervise its employees' handling of accounts that needed to be frozen, disabled, or otherwise restricted on an emergency basis."

  > "As a result of these deficiencies, NTC failed to take diligent steps to understand and implement the SRO. These failures resulted in positions in the Patel accounts remaining open for several days after the SRO was served, during which time they lost $233,425.70 in value."
- **What it was actually about:** **Supervision (Reg 166.3)** — the FCM's employees failed to implement a court-ordered account freeze arising from a third party's fraud. **It is about neither broker status nor adviser status, and it is NOT evidence on Q1 or Q2.** It is recorded here because the brief requires every located action to be reported and characterised, and because a name-match on "NinjaTrader" would otherwise look like an unexplained hit.
- **Q1 / Q2 / Q3: NOT EVIDENCE.** Recorded for completeness.
- **Level 1** as an order; irrelevant to the questions.

### S2-12 · MultiCharts, LLC, "Legal Statement" · `https://web.archive.org/web/20160621143257/http://www.multicharts.com/company/legal/` · retrieved 7 Sep 2026
- **Type:** Published terms
- **Date / status:** Archived 21 Jun 2016 (live site returns HTTP 403 to non-browser clients — Search Log #27). Footer reads "© 1999-2016 MultiCharts, LLC". Home offices stated as Columbus, Ohio.
- **Verbatim — the only advice-adjacent sentence in the document:**
  > "You should be aware of all the risks associated with trading and seek advice from an independent financial advisor if you have any doubts."
- **Machine counts across the document:** "not a broker" **0**; "investment adviser/advisor" **0** (the only "advis-" hits are "HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES" and the risk sentence above); "recommend" **0**; "broker-dealer" **0**. The only "registered" is a trademark notice: "TradeStation and EasyLanguage are a registered trademarks of TradeStation Securities."
- **What it establishes:** The same pattern as NinjaTrader — a long-running, locally-installed, user-programmable order-entry platform with **no status statement of any kind** in its terms.
- **Q1 SUPPORT (weak). Q2 SUPPORT (weak).**
- **Level 3.**
- **Application note:** Two independent desktop survivors (S2-09, S2-12) with a decade-plus of archived terms and no status sentence between them establishes that the *absence* of a disclaimer is the norm in this product category, not an anomaly. It does not establish that the absence is safe.

### S2-13 · Trade Ideas, LLC, End User License Agreement §III ("Security Disclaimers") and §XII · `https://www.trade-ideas.com/eula/` · retrieved 7 Sep 2026
- **Type:** Published terms
- **Verbatim, §III "Security Disclaimers":**
  > "Nothing herein constitutes an offer or a solicitation for the purchase or sale of any security to any person in any jurisdiction in which such an offer or solicitation is not authorized. All purchases and sales of securities must and are made through a registered securities broker or dealer of the User's choosing with whom the User has a contractual relationship and have agreed to and accepted such broker's or dealer's terms and conditions."
- **Verbatim, §XII "Simulated Performance Disclaimer for OddsMaker & A.I. System, ("HOLLY")":**
  > "All the information included herein should not be considered as a recommendation to buy, sell or hold any security or use any trading system."

  > "The OddsMaker & HOLLY software may highlight different types of systems or algorithms from which User may choose to execute trades."
- **Founding, from the vendor's own About page** (`https://www.trade-ideas.com/about/`, retrieved 7 Sep 2026): > "Founded in 2003 by financial technology pioneers, Trade Ideas emerged from a vision to empower self-directed investors in an evolving market landscape."
- **Machine counts:** "not a broker" **0**; "investment advice/adviser" **0**.
- **What it establishes:** Trade Ideas disclaims *recommendation* and asserts **broker-neutrality in the user's own hands** — the broker is "of the User's choosing" and the contractual relationship is between the user and that broker — but never states it is not a broker-dealer or not an adviser.
- **Q1 SUPPORT (weak, and see the caveat). Q2 SUPPORT (weak). Q3 SUPPORT.**
- **Level 3.**
- **Application note:** The §III sentence is the closest located commercial echo of the *Charles Schwab* (1996) Condition 1 posture and of *CommandTRADE*'s broker-neutrality ground — the user is the broker's customer under the broker's own terms. But Trade Ideas is a **poor** survivor analogue on Q1 and the difference must not be blurred: HOLLY is a **company-controlled** selection engine that "may highlight different types of systems or algorithms", and §XII's own language concedes highlighting. The configuration expressly forbids exactly that — "Nothing highlighted, no picks", and no company-controlled choice may determine which instrument qualifies. Trade Ideas therefore sits *further from* the configuration on Q1 than the configuration sits from the adverse line, and its unchallenged survival is correspondingly weaker evidence than it first appears.

### S2-14 · TradeStation, "Enabling Automated Execution for a Strategy" and "Disabling Order Confirmations for Automated Execution of Strategy-Generated Orders" · `https://help.tradestation.com/10_00/eng/tradestationhelp/automated_execution/enable_auto_execution_strategy.htm` and `.../disable_order_confirm_strategy_gen_orders.htm` · retrieved 7 Sep 2026
- **Type:** Published vendor operating documentation
- **Verbatim:**
  > "Strategy automation provides you with the ability to automatically trade your strategies through your TradeStation account(s)."

  > "Select the Automate execution using [account number] account with confirmation check box. The Enable Order Generation dialog is displayed. Click I Agree to proceed in automatically place and generate strategy orders and continue, or click I Do Not Agree if you do not wish to continue using the automate execution feature."

  > "Select On to receive an order confirmation, or Off to not receive an order confirmation prior to orders generated are placed for the selected strategy… If Off is selected, the Disable Confirmation dialog is displayed. Read the statement concerning fully automated trading with TradeStation. Click I Agree to continue…"

  > "You can take advantage of fully-automated strategy execution by disabling the order confirmations for strategy-generated orders. **Since there is no global setting, you must do this for each individual strategy that you have enabled to generate orders.**"

  And from the 9.1 help (`.../about_auto_execution_strategies.htm`): > "You will receive an order confirmation before any strategy-generated orders are placed, unless you choose not to."
- **What it establishes:** A twenty-year-deployed product in which the default is **per-order human confirmation**, unattended execution is an **opt-out that must be taken separately for each individual strategy**, and each escalation is gated behind an explicit "I Agree".
- **Q3 SUPPORT (moderate).** Q2 NEUTRAL — see the application note.
- **Level 2** — vendor operating documentation.
- **Application note:** This is the closest published commercial analogue to the configuration's **permission ladder** — every new source starts `disabled`; one explicit logged local act enables `per-order` live use; no global switch. TradeStation's "no global setting… you must do this for each individual strategy" is the same design instinct, per-strategy rather than per-source. **Its Q2 value is close to nil and must not be overstated:** TradeStation Technologies (the software) and TradeStation Securities, Inc. (BD, CRD 39473, SEC File No. 8-48711) are affiliates within one group, so the software runs on the broker's own platform. This is *not* an unaffiliated-vendor precedent. It is useful on Q3 only, as evidence that a per-order confirmation surface preceding automated strategy orders is long-established, unremarkable retail practice.

### S2-14A · TradeStation Group, Inc. Companies — the software entity's own status statement · `https://www.tradestation.com/DisclosureTSCompanies` → `https://cdn.tradestation.com/uploads/TradeStation-Group-Inc-Companies.pdf` · retrieved 7 Sep 2026
- **Type:** Published terms (corporate status disclosure)
- **Date / status:** Live version date-stamped **05-13-2026**. Archived version date-stamped **04-17-2024** (`https://web.archive.org/web/20240517045427id_/…`). **The operative sentence is identical in both** — no wording change across the two years of archived versions.
- **Verbatim — the two entities, side by side:**
  > "TradeStation Securities, Inc. is an SEC-licensed broker dealer and a CFTC-licensed futures commission merchant (FCM), and a member of FINRA, SIPC, CME, NFA and several equities and futures exchanges, which offers to self-directed investors and traders Equities accounts for stocks, exchange-traded products (such as ETFs) and equity and index options, and Futures accounts for commodity and financial futures and futures options."

  > "TradeStation Technologies, Inc. is a software development company which offers analytics subscriptions that self-directed investors and traders can use to chart, analyze and design back-tested strategies for Equities, Options, Futures, Forex and Crypto markets **(TradeStation Technologies is not a financial services company)**."
- **Verbatim — group-wide non-advice / non-solicitation clause:**
  > "No offer or solicitation to buy or sell securities, securities derivative or futures products of any kind, or any type of trading or investment advice, recommendation or strategy, is made, given or in any manner endorsed by any TradeStation Group company, and the information made available on or in any TradeStation Group company website or other publication or communication is not an offer or solicitation of any kind in any jurisdiction where such TradeStation Group company or affiliate is not authorized to do business."
- **What it establishes:** The group draws an express line **at execution**. The software entity is characterised as selling "analytics subscriptions" to "**self-directed**" investors for charting, analysis and back-tested strategy **design**, and is expressly declared "**not a financial services company**"; the licensed broker-dealer/FCM entity is the one that offers accounts. The non-advice clause is drafted to cover *every* group company, software entity included.
- **Q1 SUPPORT (moderate). Q2 SUPPORT (weak).**
- **Level 2** — published corporate disclosure, stable across archived versions, and the most explicit software-entity status statement located anywhere in this track.
- **Application note:** This is the clearest commercial articulation found of the exact boundary the configuration draws — **design and analytics on one side of the line, execution on the other** — and it is the only located instance of a vendor expressly declaring its software entity "not a financial services company". Three limits must be stated. (i) TradeStation Technologies and TradeStation Securities are **affiliates in one group**, so the line is drawn inside a corporate family that already holds BD and FCM licences; it is not evidence that an *unaffiliated* vendor may draw the same line. (ii) The description covers "chart, analyze and design back-tested strategies" — it does **not** claim that the software entity transmits live orders, and the automated execution documented at S2-14 runs through the licensed broker's own platform and account. The configuration's runtime *does* compose and transmit, so this sentence does not reach the configuration's hardest fact. (iii) A self-description binds nobody — *Ranieri Partners / Phillips*, already in the register, disregards counsel-drafted role limits where conduct does not match. Its real evidential value is as **market practice**: the industry's own line falls where the configuration puts it, and the group that draws it has never been challenged on that line.

### S2-15 · Alpaca — the broker's own characterisation of third-party access · `https://alpaca.markets/disclosures` · retrieved 7 Sep 2026
- **Type:** Published broker terms
- **Verbatim:**
  > "You should know that the use or granting of any third party access to your account information or **place transactions in your account at your direction** is solely at your risk. Alpaca does not warrant against loss of use or any direct, indirect or consequential damages or losses to you caused by your assent, expressed or implied, to a third party accessing your account or information, including access provided through any other third party apps, systems, or sites."

  And separately: > "Providing use of the Paper Trading API is not an offer or solicitation to buy or sell securities… or any type of trading or investment advice, recommendation or strategy, given or in any manner endorsed by AlpacaDB, Inc. or any AlpacaDB, Inc. affiliate."
- **What it establishes:** A registered broker-dealer's own published terms characterise a third-party application that places transactions in the customer's account as doing so **"at your direction"** — the customer's direction — and locate the authorising act in the customer's **"assent, expressed or implied, to a third party accessing your account"**.
- **Q3 SUPPORT (moderate).** Q2 NEUTRAL.
- **Level 2** — a broker's published terms, which Q3 expressly says can answer the question.
- **Application note:** Q3 asks whether the member's per-order act followed by transmission under his own credentials is treated as **the member's own instruction** rather than discretionary authority exercised by another person, and notes this "can be answered by a broker's own terms, not only by a regulator". This is the answer located, and it is favourable: Alpaca frames third-party-placed transactions as being at the customer's direction, and frames the enabling act as the customer's grant of access. It is the **closest thing found in this track to a credential-custody-dependent statement in any broker's or regulator's document** — the operative trigger is the customer *granting access*. But note precisely what it is not: it is a **risk-allocation and warranty-disclaimer** clause, not a characterisation of the third party's regulatory status, and Alpaca says nothing about whether that third party must register. See §N9.

### S2-16 · *In re eToro USA LLC*, Exchange Act Rel. No. 34-101001, AP File No. 3-22106 (12 Sep 2024) · `https://www.sec.gov/files/litigation/admin/2024/34-101001.pdf` · retrieved 7 Sep 2026
- **Type:** Enforcement order (SEC, settled, no admissions) — **the adverse contrast case**
- **Verbatim, ¶4:**
  > "Throughout the Relevant Period, eToro effected transactions in crypto assets, including crypto asset securities, for customers, as their agent, and held U.S. dollars and crypto assets on its customers' behalf… eToro—through an eToro affiliate acting as a sub-custodian—held crypto assets, including crypto asset securities, that had been purchased by customers in omnibus wallets maintained for the benefit of its customers **of which eToro or its sub-custodian affiliate held the private keys**."
- **Verbatim, ¶5:**
  > "These prices consisted of bids and offers provided to the Trading Platform by the eToro affiliate, **plus or minus a fixed fee charged by eToro**. When a customer chose to buy or sell a crypto asset on the platform, eToro routed the order to this affiliate… Each day, eToro netted these U.S. dollar debits and credits…"
- **Verbatim, ¶7 — the operative broker finding:**
  > "Section 3(a)(4) of the Exchange Act defines a 'broker' generally as 'any person engaged in the business of effecting transactions in securities for the account of others.' **By arranging customers' purchase and sale of crypto asset securities, as their agent, in the manner described above, eToro acted as a broker.** eToro was not, however, registered as such and no exemption or exception applied. Accordingly, eToro violated Section 15(a) of the Exchange Act."
- **What it was actually about:** Unregistered **broker** (§15(a)) and unregistered **clearing agency** (§17A) for crypto asset securities. This one **IS** on Q2 — it is a §3(a)(4) holding — and it is the adverse contrast the brief asked for.
- **Q2 ADVERSE in form; SUPPORT in substance on the facts.**
- **Level 1** — Commission order applying §3(a)(4) directly.
- **Application note:** Every factor the Commission actually relied on is **absent** from the configuration, and the list is worth stating flatly because it is the clearest available map of what an affirmative §3(a)(4) finding was built from: (i) eToro **held customer funds** in an omnibus account — the configuration touches no funds or securities; (ii) eToro or its affiliate **held the private keys** — the configuration's trade-capable credentials exist only in the member's own local keychain and there is no company-level trading credential; (iii) eToro charged **a fixed fee on every transaction** — the configuration takes nothing per trade, on volume, on assets or on performance; (iv) eToro **routed** orders to an affiliate and **netted** across customers — the configuration performs no routing, no venue selection, no batching and no cross-member netting; (v) eToro acted **"as their agent"** — the configuration's order is minted by the member's own act on a runtime-owned surface, and the broker's own terms (S2-15) call such transactions the customer's direction. Note the credential/key-custody sentence in ¶4: it is the second regulator document located in which key custody appears in the operative facts, alongside *In re Coburn* (already in the register, control found in exclusive private-key custody). **Neither is a broker-credential holding**, and neither supplies a test — see §N9.

### S2-17 · *In re CoinAlpha Advisors LLC*, Securities Act Rel. No. 33-10582, AP File No. 3-18913 (7 Dec 2018) · `https://www.sec.gov/files/litigation/admin/2018/33-10582.pdf` · retrieved 7 Sep 2026
- **Type:** Enforcement order (SEC, settled, no admissions)
- **Verbatim:**
  > "CoinAlpha Advisors LLC ("CoinAlpha") is a Delaware limited liability company with its principal place of business in Sunnyvale, California. CoinAlpha was formed in July 2017 to act as the managing member of and manager to CoinAlpha Falcon LP. CoinAlpha has never been registered with the Commission in any capacity."

  > "Respondent formed the Fund in October 2017 for the purpose of investing in digital assets. From October 2017 through May 2018 (the "Relevant Period"), Respondent raised approximately $600,000 from 22 investors, residing in at least five U.S. states."
- **What it was actually about:** An **unregistered offering of fund limited-partnership interests** under Securities Act §5. **It is NOT about broker status, adviser status, or software, and is NOT evidence on Q1 or Q2.**
- **Entity and timing, stated carefully:** Hummingbot's own Foundation page states > "Hummingbot was originally built and open sourced by CoinAlpha in April 2019" and > "In December 2021, CoinAlpha spun off the Hummingbot Fou[ndation]" (`https://hummingbot.org/about/`, retrieved 7 Sep 2026). The order therefore **predates the Hummingbot software's release by roughly four months**. The respondent is "CoinAlpha **Advisors** LLC"; EDGAR shows a separate filer "CoinAlpha, Inc." (CIK 0001722645) alongside "CoinAlpha Falcon LP" (CIK 0001721669). Whether the respondent entity is the same as the entity that built Hummingbot is **not established on the record I retrieved** and I do not assert it.
- **Q1 / Q2 / Q3: NOT EVIDENCE.** Recorded because a name-sweep hit on the vendor's corporate family and the brief requires characterisation of every hit.
- **Level 1** as an order; irrelevant to the questions.

### S2-18 · The other four name-sweep hits, characterised — none is evidence on Q1/Q2/Q3
All retrieved 7 Sep 2026 from `sec.gov`. Each is recorded so that no name-match in the sweep is left looking like an unexplained regulatory event.

| Order | Respondent | What it was actually about | Evidence on Q1/Q2/Q3? |
|---|---|---|---|
| Rel. 33-11269, AP 3-21845 (7 Feb 2024) · `/files/litigation/admin/2024/33-11269.pdf` | TradeStation Crypto, Inc. | Securities Act §5 — an unregistered **crypto interest-earning product**. Verbatim: "TradeStation's crypto asset accounts with the Interest Feature were offered and sold as securities in the form of investment contracts, and TradeStation offered and sold them without registering such offers and sales." | **No.** Product-registration case. |
| Rel. 34-95369, AP 3-20938 (27 Jul 2022) · `/files/litigation/admin/2022/34-95369.pdf` | TradeStation Securities, Inc. | Regulation S-ID Rule 201 — inadequate written **Identity Theft Prevention Program**. Verbatim: "These proceedings arise out of TradeStation's failure to adequately develop and implement a written Identity Theft Prevention Program as required by Rule 201 of Regulation S-ID." | **No.** Compliance-program case against an already-registered BD. |
| Rel. 34-101137, AP 3-22159 (24 Sep 2024) · `/files/litigation/admin/2024/34-101137.pdf` | Alpaca Securities LLC | Recordkeeping — **off-channel communications**. Verbatim: "Alpaca personnel sent and received off-channel communications that related to its broker-dealer business." | **No.** Recordkeeping case against an already-registered BD. |
| Rel. 34-92486, AP 3-20433 (26 Jul 2021) · `/files/litigation/admin/2021/34-92486.pdf` | Tradier Brokerage, Inc. | **Form CRS** filing and delivery failure. Verbatim: "The firm failed to file and deliver Form CRS by these deadlines, not becoming compliant until May 5, 2021." | **No.** Filing case against an already-registered BD. |

Also located and characterised: **WA DFI, *In re TradeStation Crypto, Inc.*, No. S-21-3172-23-CO01, Consent Order (21 Dec 2023)** (`https://dfi.wa.gov/securities-enforcement-actions/securities2023`, retrieved 7 Sep 2026). Verbatim: > "On December 21, 2023, the Securities Division entered into a consent order with Respondent TradeStation Crypto, Inc. … as part of a multistate settlement to resolve the Securities Division's investigation into TradeStation's crypto interest-earning program." **Not evidence on Q1/Q2/Q3** — the same crypto interest product as Rel. 33-11269, at state level.

### S2-19 · Collective2 "AutoTrade" — recorded as an ADVERSE CONTRAST, not a survivor · `https://web.archive.org/web/20110703062502/http://www.collective2.com/about-autotrade` and `https://web.archive.org/web/20210410143744/https://collective2.com/about-trades-own-strategy` · retrieved 7 Sep 2026
- **Type:** Published vendor description (archived)
- **Date / status:** Snapshots 3 Jul 2011 and 10 Apr 2021. Live `collective2.com/legal` returns HTTP 403 to non-browser clients (Search Log #24); no terms page appears anywhere in the Wayback URL index for the domain (§N6).
- **Verbatim (2011):**
  > "AutoTrading lets you choose any system on this Web site and have its trades placed automatically in your real-life brokerage account."

  > "Our advanced AutoSync technology is constantly monitoring your real-life brokerage account, and comparing it to what you should have in the account, based on your instructions and the trading system's trade record. **We will adjust your account automatically to make sure you stay in sync with your chosen systems.**"

  > "If you choose to use the optional feature, **our servers will automatically place a stop loss order** for each position opened by your trading system, at whatever dollar amount you specify."
- **Verbatim (2021), on the revenue model:**
  > "TOS Strategies keep 60% of subscription revenue, as opposed to 50%."
- **What it establishes:** Collective2 distributes **third-party-authored** strategies to subscribers, its own servers adjust the subscriber's account and place orders, and it splits subscription revenue with the strategy author.
- **Q1 ADVERSE as a contrast. Q2 ADVERSE as a contrast.**
- **Level 3.**
- **Application note:** **Collective2 is not a survivor in this configuration's shape and must not be counted as one.** The decisive difference is authorship: the subscriber **adopts somebody else's rules**, which is the *Weiss Research* and copy-trading fact pattern, and the configuration's central claim is the opposite — every decision-relevant input is the member's own. Collective2 also fails the configuration's other tests: its servers place orders and adjust the account, and it shares revenue with the person whose selections drive the trades. Its correct classification is alongside eToro/ZuluTrade as a contrast. Registration checks returned **nothing** for it (§N4) and no enforcement was located (§N1–§N3) — which, given how much further it goes than the configuration, is a documented silence worth recording but not one to lean on.

### S2-20 · Freqtrade and Hummingbot — recorded with a scope limitation that removes most of their value
- **Freqtrade**, `https://www.freqtrade.io/en/stable/`, retrieved 7 Sep 2026. Verbatim, under "DISCLAIMER":
  > "This software is for educational purposes only. Do not risk money which you are afraid to lose. USE THE SOFTWARE AT YOUR OWN RISK. THE AUTHORS AND ALL AFFILIATES ASSUME NO RESPONSIBILITY FOR YOUR TRADING RESULTS."

  Self-description: > "Freqtrade is a free and open source crypto trading bot written in Python. It is designed to support all major exchanges and be controlled via Telegram or webUI."
- **Hummingbot**, `https://hummingbot.org/about/`, retrieved 7 Sep 2026. Verbatim:
  > "Hummingbot Foundation is a not-for-profit organization established in the Cayman Islands. The Foundation's mission is to democratize high-frequency trading by maintaining the open-source Hummingbot code repository and the HBOT governance system."
- **What it establishes:** Both are free, open-source, self-hosted, user-configured bots in which the user holds their own exchange API keys and no vendor takes custody — architecturally the purest examples of the configuration's credential design.
- **Q1 / Q2: NEUTRAL — and here is why they cannot carry weight.** Both trade **crypto assets on crypto exchanges**, not securities through US registered broker-dealers. Neither is inside the Exchange Act §3(a)(4) / Advisers Act §202(a)(11) fact pattern the commission is examining. Hummingbot's steward is a **Cayman Islands** entity, outside the US-federal-plus-Washington scope the shared context sets. **Their absence from every enforcement database is therefore close to meaningless for Q1 and Q2**, because the relevant regulator would in most instances not be the SEC at all. I record them because the brief named them, and I record the limitation because the alternative would be to pad the survivor count with products that do not answer the question.
- **Level 3**, and discounted further for scope.

**Same scope limitation, recorded for MetaTrader / MetaQuotes (survivor table row 13).** MetaTrader "Expert Advisors" are the largest deployed instance anywhere of the exact mechanical shape under examination — locally installed, user-authored code, the user's own broker login held in the user's own terminal, unattended order generation. Its enforcement record was swept on the same footing as everything else and returned **0 in SEC AP and LR (both "MetaQuotes" and "MetaTrader"), 0 across 61 CFTC enforcement pages, 0 across WA DFI 2002–2026, and 0 in BrokerCheck and IAPD**. **That silence carries little weight for Q1 and Q2** for two reasons that must be stated rather than glossed: the platform is overwhelmingly used for **forex and CFDs**, not US securities through US registered broker-dealers, so the SEC would rarely be the relevant regulator; and MetaQuotes is a **non-US** vendor, outside the US-federal-plus-Washington scope the shared context sets. Its status statement was not retrieved and is **UNVERIFIED**.

### S2-21 · Trality — a survivor that did not survive, for non-regulatory reasons ◇
- **Status:** `trality.com` returned **no Wayback CDX record** on the query run (Search Log #45), and the product is not reachable. Secondary sources state Trality was an Austrian company founded 2019 by Christopher Helf and Moritz Putzhammer, discontinued 31 Jul 2023, with an insolvency filing in Aug 2023.
- **◇ SECONDARY CONFIRMATION ONLY — UNVERIFIED.** I did not reach any primary Austrian insolvency record, any regulator document, or any vendor statement. Per shared-context §0 this is a **negative finding**, not a citable proposition.
- **What can properly be said:** No US regulatory action against Trality was located in any database searched (§N1–§N4). No evidence was found that its wind-down was regulator-driven; equally, no evidence was found that it was not. Austrian insolvency is in any event outside the US-federal-plus-Washington scope.
- **Q1 / Q2 / Q3: NOT EVIDENCE.**

---

## Survivor table

Ordered by closeness to the configuration. "Key" = who holds the trade-capable credential. Every enforcement cell is the *documented* result of the searches in §N1–§N4 and the Search Log, subject to the FINRA and NFA walls at §N7–§N8.

| # | Product | Operating at least since (source) | Local or hosted; whose connection | **Who holds the key** | Per-order approval? | Status statement (short, verbatim) | Registration check | Enforcement — documented |
|---|---|---|---|---|---|---|---|---|
| 1 | **TradingView** broker panel | domain 2003 ◇; broker manual live 2026 | Hosted UI, but **order goes client → broker's server**; "The TradingView server is not involved in this data exchange" | **User ↔ broker.** TV holds only *data-feed* credentials | Manual ticket (no rule-fired orders) | **None located** in Terms of Use | BrokerCheck **0**, IAPD **0** | SEC AP/LR populate **0/0**; CL quoted o=**2** — **not a party in either** (*Hyde Park v. FairXchange*; *Coinbase v. SEC*), r THROTTLED; WA DFI **0** (2002-2026); CFTC 61 pages **0**; EDGAR FTS 113 (no enforcement forms) |
| 2 | **QuantConnect** (Lean live) | Wayback 5 May 2012 | **Hosted**; QC's servers call the broker API — "We call the IB API to place live trades" | **User's own credentials, entered by user; "we don't save your credentials"** | **No** — unattended | "The Company is not an investment advisory service, nor is it a registered investment advisor or broker-dealer" (§3.6) | BrokerCheck **0**, IAPD **0** | SEC AP/LR **0/0**; **CL quoted o=0 r=0 — no litigation of any kind**; WA DFI **0**; CFTC **0**; EDGAR FTS 8 (Form C/D only) |
| 3 | **NinjaTrader** (software era) | Wayback 29 May 2003 | **Local**, connects to third-party Broker Platforms via API/SDK | **User** (local platform login to own broker) | Configurable; ATM/automated modes | **NONE — 0 occurrences** of "broker-dealer", "investment advice", "adviser", "not a broker", "registered" across the whole ToS, 2016 and 2017-2025 versions | BrokerCheck **0**, IAPD **0**; group now runs its own FCM | **CFTC 24-27 (2024) — FOUND**, Reg 166.3 supervision, **not status**; SEC AP/LR **0/0**; CL quoted r=**39** (o THROTTLED) — incl. **private suits *Suresh v. NinjaTrader* (2022) and *Alpha Futures v. NinjaTrader Group* (2026), subject matter ◇UNVERIFIED**; WA DFI **0** |
| 4 | **MultiCharts** | Wayback 6 Feb 2002; footer "© 1999-2016" | **Local**, third-party broker connections | **User** | Configurable | **NONE** — 0 occurrences of any status term | BrokerCheck **0**, IAPD **0** | SEC AP/LR **0/0**; CL quoted o=**0**, r=2 — **not a party in either**; WA DFI **0**; CFTC **0**; EDGAR FTS **0** |
| 5 | **Trade Ideas** (Holly, Brokerage Plus) | **"Founded in 2003"** (own About page) | Local/hosted hybrid; user's own broker | **User** ("broker or dealer of the User's choosing") | Auto-execute available | "All purchases and sales of securities must and are made through a registered securities broker or dealer of the User's choosing…" (EULA §III); no "not a broker" | BrokerCheck **0**, IAPD **0** | SEC AP/LR **0/0**; WA DFI **0**; CFTC **0**; CL quoted o=**0**, r=**1** (*Monegro*, private suit, nature ◇UNVERIFIED) |
| 6 | **TradeStation** (EasyLanguage automation) | BD CRD 39473; EDGAR 10-K405 filings | Local platform, **affiliated** broker | **User** (own TradeStation account) | **Yes by default**; opt-out **per individual strategy**, each behind "I Agree" | **"TradeStation Technologies, Inc. is a software development company… (TradeStation Technologies is not a financial services company)"** — stable Apr 2024 → May 2026 | **TradeStation Securities IS a registered BD**, 8-48711, disclosure_fl **Y** | **4 FOUND** (SEC 33-11269, 34-95369; WA DFI S-21-3172-23-CO01; see S2-18) — **none about status**; CL quoted o=19 r=469 incl. ***Cantero v. Tradestation Technologies*** (2010) — **suit against the SOFTWARE entity, subject matter ◇UNVERIFIED** |
| 7 | **Composer** | Wayback 9 Sep 2021 | Hosted; began as "a layer on top of brokerages" (Alpaca), now own BD + Apex/Alpaca clearing | **Vendor-side** (token/managed account) | **No** — "Watch your trades execute automatically" | 2021-2024: "Composer is a registered investment adviser with the … SEC"; **removed** by 2026 | **BOTH**: Composer Securities LLC BD **8-71057** (active, disclosure_fl **N**); Composer Technologies IA **801-119952**, **TERMINATED 12/6/2024** | SEC AP/LR **0/0**; EDGAR FTS 18 (X-17A-5, D, 8-K); **CL quoted o=0 r=0 for BOTH entities** |
| 8 | **Alpaca** third-party app ecosystem | BD CRD 288202 | Broker API; third-party apps | **User grants access to app** | App-dependent | Broker's terms: third party places transactions "**at your direction**" | Alpaca Securities LLC BD **8-69928**, disclosure_fl **Y** | **1 FOUND** (34-101137, off-channel comms) — **not about status**; CL quoted o=**0**, r=77 (incl. *In re Jan. 2021 Short Squeeze* MDL) |
| 9 | **Freqtrade** | Wayback 9 Jan 2021 | **Local**, open source | **User** (own exchange API keys) | Configurable | "This software is for educational purposes only… USE THE SOFTWARE AT YOUR OWN RISK." | None (no legal entity) | SEC **0**; CL quoted r=**0** (o THROTTLED); CFTC **0**; EDGAR **0** — **but crypto-only; see S2-20** |
| 10 | **Hummingbot** | open-sourced Apr 2019 (own page) | **Local**, open source | **User** (own exchange API keys) | Configurable | Foundation = Cayman not-for-profit | None | SEC **0**; CFTC **0**; CL quoted o=**0**, r=10 — **not a party in any**; **CoinAlpha Advisors** action FOUND but §5 fund offering, pre-dates release — **crypto-only; see S2-20** |
| 11 | **Sierra Chart** | — | Local | User | Configurable | Not retrieved (404) — **UNVERIFIED** | BrokerCheck **0**, IAPD **0** | SEC **0**; CFTC **0**; EDGAR FTS **0**; CL quoted o=1 r=2 — **not a party in any** |
| 12 | **Tickeron** | — | Hosted AI signals | Vendor | — | — | **IA 801-79039, INACTIVE** | SEC AP/LR **0/0**; EDGAR FTS 2 (Form D); CL quoted r=**0**, o=THROTTLED |
| 13 | **MetaTrader / MetaQuotes** (Expert Advisors) | — | **Local**, user's own broker terminal | **User** (broker login in terminal) | Configurable; EAs run unattended | Not retrieved — **UNVERIFIED** | BrokerCheck **0**, IAPD **0** | SEC AP/LR **0/0** (both "MetaQuotes" and "MetaTrader"); CFTC 61 pages **0**; WA DFI **0** (2002-2026); CL quoted o=1 r=42 — mostly MetaQuotes as *plaintiff*; incl. *Gurung v. MetaQuotes* ◇ — **but predominantly forex/CFD and non-US; see note** |
| — | **Collective2 (AutoTrade)** — **CONTRAST** | Wayback 20 Feb 2001 | Hosted; **C2's servers** adjust the account | Vendor-side | **No** — AutoSync adjusts automatically | No terms page reachable (403; none in CDX) — **UNVERIFIED** | BrokerCheck **0**, IAPD **0** | SEC AP/LR **0/0**; CL quoted o=**0**, r=13 — **not a party in any**; WA DFI **0** |
| — | **eToro** — **CONTRAST** | BD CRD 298361 | Hosted; custody + omnibus + netting | **eToro held the private keys** | No | — | BD **8-70212** (disclosure_fl **Y**); IA **801-134641** | **FOUND — 34-101001, §15(a) + §17A. The one §3(a)(4) holding in this track.** CL quoted r=199 (private consumer/IP suits, not status) |
| — | **ZuluTrade** — **CONTRAST** | — | Copy-trading | Vendor-side | No | — | BrokerCheck **0**, IAPD **0** | SEC AP/LR **0/0**; EDGAR FTS 8 (S-1 only); CL quoted r=3 — **two CFTC fraud dockets in which ZuluTrade is the tool used, NOT the defendant** |

---

## Direct answers

**Q. How many products, and how many have any action found?**
**Sixteen** products/entities carried through the full search protocol — thirteen offered as survivors and three (Collective2, eToro, ZuluTrade) carried expressly as adverse contrasts. **Five** produced an action bearing their name: TradeStation (three — SEC ×2 + WA DFI), NinjaTrader Clearing (CFTC ×1), Alpaca Securities (SEC ×1), eToro USA (SEC ×1), CoinAlpha Advisors (SEC ×1) — **eight orders in total**. A ninth, *Tradier Brokerage* (Rel. 34-92486), surfaced in the same sweep; Tradier is a broker in this ecosystem rather than one of the sixteen products, and it is characterised at S2-18 for completeness. Of the eight, **exactly one — *eToro*, Rel. 34-101001 — is about broker or adviser status.** The other seven are: two on the same unregistered **crypto interest product** (SEC 33-11269 and the parallel WA DFI consent order), one **identity-theft-program** case (Reg S-ID), one **off-channel-communications recordkeeping** case, one **Form CRS** filing case, one **Reg 166.3 supervision** case, and one **§5 fund-offering** case. **None of the seven is evidence on Q1, Q2 or Q3, and each is labelled as not being so at S2-11, S2-17 and S2-18.**

**Q. Is the absence of enforcement documented rather than assumed?**
Partly, and the parts must be kept separate. **Documented:** SEC Administrative Proceedings and Litigation Releases (48 respondent names × 2 listings, with a verified empty-vs-populated discriminator and a demonstrated substring match — §N1); Washington DFI (every year page 2002-2024 fetched and grepped, plus the 2025-26 filtered index, with a working control — §N2); CFTC enforcement (61 distinct listing pages fetched, with a working control — §N3); FINRA BrokerCheck and SEC IAPD (§N4); EDGAR full-text (§N5). **NOT documented, and no silence is claimed:** FINRA disciplinary actions (Cloudflare wall — §N7) and NFA registration/disciplinary status (BASIC wall — §N8). CourtListener is now **substantially documented** — paced quoted runs closed **48 of 56** queries, including **COUNT=0 on both opinions and dockets for QuantConnect, Composer Technologies, Composer Securities and Tickeron**; eight queries remain throttled and are recorded as such (§N6). But that sweep also **opened** something: **five private suits naming survivor vendors as parties**, including ***Cantero v. Tradestation Technologies, Inc.*** (S.D. Fla. 2010) against a vendor's *software* entity. **I have their case names, courts and filing dates only, and I do not assert what any of them was about.** Whether a survivor's status statement has ever been tested in private litigation is therefore now an **open** question, not a closed one — and that is a change from where this track stood before the sweep.

**Q. Which vendor's status statement is strongest, and was any ever tested?**
Two are strongest, for different reasons. **QuantConnect §3.6** is the only located statement disclaiming *both* adviser and broker-dealer status in one sentence, and it sits on a platform doing live unattended order transmission. **TradeStation Group's Companies disclosure (S2-14A)** is the only located instance of a vendor expressly declaring its software entity "**not a financial services company**" while naming its sibling as the licensed broker-dealer/FCM — i.e. the only located vendor that draws the design/execution line explicitly in writing, and it draws it where the configuration draws it. **Nothing located suggests any of these statements was ever tested by a regulator**, and the TradeStation sentence is word-for-word identical across its archived versions from 17 Apr 2024 to 13 May 2026. What the Wayback work did establish is the opposite of a testing signal in two directions: NinjaTrader's terms sat **byte-identical for eight years** (Jul 2017 → Mar 2025) and never contained a status sentence to begin with; MultiCharts likewise has none. The one status sentence that demonstrably **changed** is Composer's, and it changed because the **registration behind it was terminated (12/6/2024)** and the business moved to a broker-dealer — a corporate restructuring, not a regulator's challenge.

**Q. The credential question — does anything turn on credential custody?**
**No regulator document was located that turns on whose credentials a software vendor uses.** P7's negative finding stands and this track did not overturn it. Three things were found that sit adjacent to it, and their limits matter more than their existence:
1. **A broker's own terms come closest.** Alpaca frames a third party that places transactions in the customer's account as acting **"at your direction"**, with the enabling act being the customer's **"assent, expressed or implied, to a third party accessing your account"** (S2-15). The trigger is the customer *granting access* — which is credential-custody-shaped. But it is a **risk-allocation clause**, not a status test, and Alpaca says nothing about whether the third party must register.
2. **A regulator document in which key custody appears in the operative facts** — *eToro* ¶4: "of which eToro or its sub-custodian affiliate held the private keys" (S2-16). This joins *In re Coburn*, already in the register. **Neither is a holding about credentials**, both concern crypto private keys rather than broker login credentials, and in *eToro* key custody sat alongside customer funds, agency, a per-transaction fee, routing and netting — so nothing isolates it as the operative fact.
3. **The clearest industry articulation is a vendor's, not a regulator's** — QuantConnect's "we don't save your credentials" (S2-06) and TradingView's "The TradingView server is not involved in this data exchange" (S2-07). These show the industry treats credential custody as the material line. **They are not authority and cannot be cited as any.**

**Q. Does any survivor share the configuration's per-order approval design?**
**TradeStation, and only TradeStation** (S2-14): per-order confirmation is the default, unattended execution is an opt-out that "you must do… for each individual strategy", and each step is gated by an explicit "I Agree". This is the configuration's permission ladder in commercial form. Its Q2 value is near zero because TradeStation's software and broker are affiliates. **Every other survivor located runs unattended**: QuantConnect, Composer, Collective2, Freqtrade and Hummingbot all execute without a per-order human act. That is the striking structural result of this track — **the configuration's per-order approval surface is more conservative than every unaffiliated survivor found**, and I located no product that pairs a per-order approval surface with an unaffiliated vendor and the user's own credentials.

**Q. What is the single most load-bearing thing found?**
**Composer's Form ADV (S2-01/S2-02).** The nearest commercial analogue — user-authored rules, a flat subscription fee and nothing else, connecting to the user's own account at a third-party broker — was **already a registered investment adviser** on the first archived day it existed, told the SEC its service was **portfolio management** and not publication, and reported **$46,700,000 discretionary across 2,948 accounts and $0 non-discretionary**, answering "Yes" to discretionary authority over both the security and the amount. This is adverse to Q1 and it removes one argument entirely: **flat-fee, subscription economics did not keep a user-authored-rules platform out of adviser registration.** The distinction available to the configuration is discretion and the per-order act — not the fee, and not the fact that the member wrote the rule. That matters because, as the shared context records, *no authority located anywhere in P1–P7 distinguishes a rule the member wrote from one he adopted* — and Composer is a real-world instance of a firm that did not try to rely on that distinction.

---

## Negative findings

Each states the endpoint, the exact query, and the count. Absence documented, never inferred.

**§N1 · SEC Administrative Proceedings and Litigation Releases — respondent-name sweep.**
Endpoints: `https://www.sec.gov/enforcement-litigation/administrative-proceedings?populate=<name>` and `https://www.sec.gov/enforcement-litigation/litigation-releases?populate=<name>`. UA declared with contact address.
**Discriminator established before trusting any zero:** an empty result renders `<span class="no-results-text">No Results match the chosen filters.</span>`; a populated result renders `<tr class="pr-list-page-row">` rows and a footer "1 to N of N items". Verified by contrast: `populate=ZZQQXNONSENSE` → 76,418 bytes, `no-results-text` present; `populate=TradeStation` → 79,003 bytes, 2 rows, footer "1 to 2 of 2 items".
**Filter behaviour established:** the filter is a **substring** match on the Respondents field, not a token match — `populate=Trality` returned "American Ce**ntrality** Group, Inc.". This makes its zeros *stronger*, not weaker, since any respondent containing the string would surface.
**48 names swept × 2 listings = 96 queries.** Names: TradeStation, NinjaTrader, MultiCharts, TradingView, Composer, QuantConnect, Alpaca, Freqtrade, Hummingbot, Trade Ideas, Trality, Collective2, eToro, ZuluTrade, Interactive Brokers, Tradier, Tradeworks, MetaQuotes, MetaTrader, Wealthfront, Betterment, Kavout, Tickeron, Trade-Ideas, Hummingbot Foundation, CoinAlpha, Composer Technologies, QuantConnect Corporation, NinjaTrader Group, Modulus, Sierra Chart, Quantopian, Numerai, Darwinex, Tradetron, 3Commas, Cryptohopper, Pionex, Shrimpy, Coinrule, StreetSmart, Wealth-Lab, AmiBroker, Motif, M1 Finance, SigFig, Tastytrade, Trade Ideas LLC.
**Result — COUNT = 0 in BOTH listings** for, among others: **NinjaTrader, MultiCharts, TradingView, Composer, Composer Technologies, QuantConnect, Collective2, Trade Ideas, Trade Ideas LLC, Freqtrade, Hummingbot, Hummingbot Foundation, Sierra Chart, ZuluTrade, MetaQuotes, MetaTrader, Quantopian, Tradetron, AmiBroker, Wealth-Lab, Kavout, Modulus, Numerai, Darwinex, 3Commas, Cryptohopper.**
Non-zero returns were the seven orders characterised at S2-11, S2-16, S2-17 and S2-18, plus Interactive Brokers (4), Wealthfront (1), Betterment (1+1) — none of which is a software-vendor status case.

**§N2 · Washington State DFI — full-archive sweep.**
2025–2026: `https://dfi.wa.gov/securities-enforcement-actions?title=<name>`. **Filter behaviour established:** `title=` is the working respondent filter (baseline page = 20 rows; `title=Johnson` = 2 rows; `?search=`, `?respondent=`, `?combine=` are silently ignored and return the unfiltered 20). It matches loosely — `title=Collective` returned "The Franchise **Collective**, LLC" and `title=Trade+Ideas` returned "TD Ameri**trade**" and "1ero**trade**r 2.0 LLC" — which strengthens its zeros.
2002–2024: no filter exists, so **all 23 year pages** at `https://dfi.wa.gov/securities-enforcement-actions/securities<YYYY>` were fetched (3,328,054 bytes total) and grepped. **Control:** `grep -il "Solium"` → `wa/2020.html`, correctly locating *In re Solium Financial Services LLC* (23 Jan 2020), the case already in the P7 register — the sweep demonstrably works.
**Result — 0 hits across 2002–2026** for: NinjaTrader, MultiCharts, TradingView, QuantConnect, Collective2, Trade Ideas, Trality, Freqtrade, Hummingbot, Alpaca, Tickeron, eToro, ZuluTrade, Sierra Chart, AmiBroker, MetaTrader, Composer. **1 hit:** TradeStation Crypto (2023), characterised at S2-18.

**§N3 · CFTC enforcement — 61-page listing sweep.**
Endpoint: `https://www.cftc.gov/LawRegulation/EnforcementActions/index.htm?page=0…60`. **Search behaviour established first:** the CFTC listing **ignores** `?search_api_fulltext=`, `?keys=` and `?search=` (all three returned 65,182 bytes, identical, 0 rows), and `https://www.cftc.gov/search?keys=` returns HTTP 403 — so no filtered query is possible and the listing had to be paged exhaustively. 61 pages fetched, **all 61 digests distinct** (3,165,069 bytes). **Control:** `grep -il Ellison` → 2 pages, correctly locating the Ellison order visible on the index.
**Result — 0 hits:** TradeStation, MultiCharts, Sierra Chart, Trade Ideas, Freqtrade, Hummingbot, CoinAlpha, MetaQuotes, ZuluTrade, Collective2, QuantConnect. **1 hit:** NinjaTrader Clearing (S2-11).

**§N4 · FINRA BrokerCheck and SEC IAPD.**
Endpoints: `https://api.brokercheck.finra.org/search/firm?query=<name>&hl=true&nrows=12&start=0&r=25&wt=json` and `https://api.adviserinfo.sec.gov/search/firm?query=<name>&…`. 21 names × 2 = 42 queries, all returning HTTP 200 with a parsed `hits.total`.
**`total=0` in BOTH** for: **NinjaTrader, MultiCharts, TradingView, QuantConnect, Collective2, Trade Ideas, Trality, Freqtrade, Hummingbot, CoinAlpha, Sierra Chart, ZuluTrade, AmiBroker, Capitalise, Tradetron.**
Non-zero: TradeStation (BD 8-48711), Composer (BD 8-71057 + IA 801-119952 terminated), Alpaca (BD 8-69928 + an unrelated "Alpaca VC Investment Management" IA 801-127816), eToro (BD 8-70212 + IA 801-134641), Tickeron (IA 801-79039, inactive), Wealth-Lab (15 unrelated name-collisions).
*Caveat recorded:* the firm-detail endpoints `api.brokercheck.finra.org/firm/<crd>` and `/firm/summary/<crd>` return `{"message":"Forbidden"}`, and `reports.adviserinfo.sec.gov` returns S3 `AccessDenied` for the Part 2A brochure. Firm-level data was therefore taken from the search API and from the IAPD detail endpoint `https://api.adviserinfo.sec.gov/search/firm/<crd>`, which does work and supplied Composer's `registrationStatus` and `orgScopeStatusFlags`.

**§N5 · EDGAR full-text search.**
Endpoint: `https://efts.sec.gov/LATEST/search-index?q=%22<name>%22`. 18 names. Coverage caveat: EDGAR FTS indexes filings from 2001 onward only.
**total=0:** MultiCharts, Freqtrade, Sierra Chart, AmiBroker. Low, non-enforcement counts: QuantConnect 8 (Form C/C-AR/C-TR/D), Collective2 5 (D/D-A/C), Trality 1 (a 6-K name-collision), Hummingbot 2, Tickeron 2 (D), CoinAlpha 16 (D/D-A), ZuluTrade 8 (S-1/S-1A), Composer Securities 3 (X-17A-5 ×2, 10-Q), Composer Technologies 18. **No enforcement-type filing surfaced for any vendor.** "Trade Ideas" (10,000) and "TradingView"/"NinjaTrader" (113/165) are dominated by generic-phrase and third-party-mention noise and carry no weight.

**§N6 · CourtListener v4 — partially documented, and honestly flagged.**
Endpoint: `https://www.courtlistener.com/api/rest/v4/search/?q=<name>&type=o|r`. **A first, unquoted sweep of 24 queries completed** and its COUNTs are reported in the survivor table: MultiCharts o=0 r=3; Freqtrade o=0 r=0; Hummingbot o=0; QuantConnect o=0; Collective2 o=0 r=13; NinjaTrader o=2 r=39; TradeStation o=19 r=475; TradingView r=83; Alpaca o=234. Counts for "Trade Ideas" (o=43,549) and "Composer" (o=158,636) are **meaningless** — the unquoted terms match ordinary English and were re-run quoted for that reason.
**A paced quoted-phrase re-run was then completed across 20 names + a follow-up run of 8.** CourtListener enforces **50 requests/hour** for anonymous callers (`{"detail":"Request was throttled. Rate limit exceeded: 50/hour."}`). Runs at 1.2 s and 85 s spacing were partly throttled; run at 80-90 s with retries, **48 of 56 quoted queries returned a COUNT. The 8 that did not are recorded as THROTTLED and are NOT reported as zeros.**

**Quoted counts (`q="<name>"`), retrieved 7 Sep 2026:**

| Quoted query | type=o | type=r | Is the vendor a party? |
|---|---|---|---|
| `"QuantConnect"` | **0** | **0** | — **clean zero on both** |
| `"Composer Technologies"` | **0** | **0** | — **clean zero on both** |
| `"Composer Securities"` | **0** | **0** (2nd run) | — **clean zero on both** |
| `"Freqtrade"` | THROTTLED | **0** | — |
| `"Tickeron"` | **0** | **0** | — **clean zero on both** |
| `"MultiCharts"` | **0** | 2 | **No** — *Topsteptrader v. OneUp Trader*; *Scanz Techs. v. Jewmon* |
| `"Hummingbot"` | **0** | 10 | **No** — mentions in *SEC v. Terraform*, *US v. Guo*, *Ho Wan Kwok*, *Snyder v. Jump Trading* |
| `"CoinAlpha"` | **0** | 6 | **No** — mentions in *Terraform*, *SEC v. Ripple*, *SEC v. Binance*, *Prime Core* |
| `"Sierra Chart"` | 1 | 2 | **No** — *Hyde Park v. FairXchange*; *Topsteptrader v. OneUp*; *Sierra v. Guevara* (surname collision) |
| `"Collective2"` | **0** | 13 | **No** — *Topsteptrader v. OneUp*, *Goodly v. Check-6*, and employment cases; "collective" noise |
| `"TradingView"` | 2 | THROTTLED | **No** — *Hyde Park v. FairXchange*; *Coinbase v. SEC* |
| `"AmiBroker"` | THROTTLED | 1 | **No** — *Market Studies LLC v. Technical Analysis Inc.* |
| `"Alpaca Securities"` | **0** | 77 | **Yes, in part** — *In re January 2021 Short Squeeze Trading Litigation* and the *Ally Financial* cases |
| `"NinjaTrader"` | THROTTLED | 39 | **Yes, in part** — see below |
| `"TradeStation"` | 19 | 469 | **Yes, in part** — see below |
| `"MetaQuotes"` | 1 | 42 | **Yes, in part** — mostly MetaQuotes as *plaintiff* in trademark enforcement |
| `"eToro"` | 4 | 199 | **Yes, in part** — private consumer/IP suits |
| `"Trade Ideas"` / `"Trade Ideas LLC"` | 4 / **0** | 288 / **1** | Quoted `"Trade Ideas LLC"` is the reliable form: **o=0, r=1** |
| `"ZuluTrade"` | THROTTLED | 3 | **No** — *CFTC v. Scharf*, *CFTC v. Traders Domain FX*, *Champion-Cain v. MacDonald* |
| `"Trality"` | 74 | 106 | **UNUSABLE — pure substring noise** (matches "neu*trality*" etc.); the returns are FCC, FOIA and prison-litigation cases with no connection to the vendor |

**What the non-zero returns actually are — and the important distinction.** In the large majority the vendor is **not a party**: CourtListener's `q=` searches docket and opinion **full text**, so a hit usually means the product was *named inside* somebody else's filing. That is true of every hit for MultiCharts, Hummingbot, CoinAlpha, Sierra Chart, Collective2, TradingView, AmiBroker and ZuluTrade. The ZuluTrade returns are worth one line for the contrast case: a copy-trading platform appears in two **CFTC fraud dockets** (*Scharf*, *Traders Domain FX*) as the *tool the fraudster used*, never as the respondent.

**PRIVATE SUITS NAMING A SURVIVOR VENDOR AS A PARTY — located, but subject matter NOT verified.** The brief asked whether anything suggests a vendor's status statement was ever tested, expressly including "a private suit". These are the candidates found. **I retrieved case names, courts and filing dates only. I did not retrieve any complaint, docket entry or nature-of-suit code, and I therefore do NOT assert what any of them was about.** Each is ◇ **UNVERIFIED**:
- ***Cantero v. Tradestation Technologies, Inc.*** (S.D. Fla., 2010-02-24) — **the only located suit naming a vendor's SOFTWARE entity rather than its broker-dealer.** Potentially the most valuable item in this list, since TradeStation Technologies is the entity declared "not a financial services company" at S2-14A.
- ***Suresh v. NinjaTrader, LLC*** (D. Colo., 2022-11-07).
- ***Alpha Futures, Limited v. NinjaTrader Group, LLC*** (N.D. Ill., 2026-07-24).
- ***Monegro v. Trade Ideas LLC*** (S.D.N.Y., 2021-02-19).
- ***Gurung v. MetaQuotes Ltd.*** (E.D.N.Y., 2023-08-24).
- ***Wanderer v. TradeStation Securities, Inc.*** (N.D. Ill., 2009-07-01) and ***Sanchez v. TradeStation Group, Inc.*** (S.D.N.Y., 2021-05-26) — against the broker/group rather than the software entity.
- ***In re January 2021 Short Squeeze Trading Litigation*** (S.D. Fla., MDL) — names **Alpaca Securities** among many brokers; this is the meme-stock trading-restriction litigation, not a software-status case.

**Net effect on the track.** The three survivors whose silence carries the most weight — **QuantConnect (o=0, r=0), Composer Technologies (o=0, r=0) and Composer Securities (o=0, r=0)** — have **no litigation of any kind** behind them, which is a genuine documented silence rather than an assumed one. Against that, **the possibility that a survivor's status was tested in a private suit is now an open question rather than a closed one**, and it was not open before this sweep.

**§N7 · FINRA disciplinary actions online — NOT SEARCHED. No silence claimed.**
Endpoint: `https://www.finra.org/rules-guidance/oversight-enforcement/finra-disciplinary-actions-online`. Per the brief I established how the search behaves before trusting any result, and the answer is that **it cannot be used programmatically**. `?search=` is silently ignored (`search=NinjaTrader`, `search=Merrill` and `search=ZZQNONSENSE` all returned ~94,990 bytes, indistinguishable) — confirming the P7 note. The real form fields are `firms`, `individuals`, `fda_search`, `case_id`, `from_date`, `to_date`, `op`, `terms_of_service`. Submitting `?firms=NinjaTrader&fda_search=&op=Search` returned **5,905 bytes reading "Just a moment… Enable JavaScript and cookies to continue"** — a Cloudflare interstitial, i.e. a **block, not a zero**. `firms=Merrill` returned a full page, so the parameter is right and the block is intermittent/bot-triggered.
**Consequence, stated plainly: this track makes NO claim that FINRA has taken no action against any of these vendors.** Two mitigations are recorded, neither a substitute: (i) BrokerCheck shows that of the products studied, only Composer Securities, Alpaca Securities, TradeStation Securities and eToro USA Securities are FINRA members at all, so FINRA's disciplinary jurisdiction would not reach the others; (ii) Composer Securities' BrokerCheck record carries `firm_disclosure_fl: "N"`. **Flagged to the coordinator as needing a browser route.**

**§N8 · NFA BASIC — NOT SEARCHED. Registration status UNVERIFIED.**
`https://www.nfa.futures.org/BasicNet/` is a client-rendered SPA. I located its JSON-RPC transport (`basic-api/DataHandlerSearch.ashx` and `DataHandler.ashx`, envelope `{"id":n,"method":m,"params":[…]}`) and its method allow-list (`getFirmSearchResults`, `getRegActionsIndex`, `getRegCasesDetails`, `getVitals`, …) by reading `basic-js/basic-rpc-client.js`. **Nine parameter signatures were probed for `getFirmSearchResults` and all returned `{"success": false, "message": "GetFirmSearchResults execution failed."}`; all five `DataHandler.ashx` methods failed against a known NFA ID.** Guessed REST paths returned HTTP 403.
A second route was then attempted against NFA's **enforcement** index rather than its registration database. `https://www.nfa.futures.org/news/EnforceRegActionsSimple.aspx` ("Enforcement and Registration Actions") does render server-side (133,848 b) but contains **no action data** — the rows are loaded client-side; a direct grep of the delivered HTML for NinjaTrader, MultiCharts, Sierra Chart, Trade Ideas and TradeStation returned **0 for each, which is meaningless because no rows are present**. Its `<meta name="api-endpoint" content="api/DataHandlerEnforcementReg.ashx"/>` and its script `cms/includes/js/enforcementRegSimple.js` (retrieved, 21,693 b) disclose the call as `getEnforcementRegs(yearFrom, yearTo)`. **Four candidate endpoint paths were POSTed with `{"id":1,"method":"getEnforcementRegs","params":[1998,2026]}` and every one returned NFA's "Page Not Found" HTML rather than JSON.** Three further index paths (`/news/PressReleases.aspx`, `/news/newsRegActions.asp`, `/about/regulatory-actions.html`) all returned the identical 128,061-byte soft-404.
**The conclusion is unchanged and is a wall, not a zero.**
**Consequence: NFA registration status (CTA / IB / FCM) for NinjaTrader, MultiCharts, Sierra Chart and Trade Ideas is UNVERIFIED.** This matters more than it looks: *Taucher v. Born* — already in the register at the holding "Each of the plaintiffs in this case falls squarely within the definition of a CTA" — is a **CTA** case, so CTA registration status is the directly comparable datum for the desktop futures platforms and it is exactly the datum I could not obtain. **Flagged to the coordinator as needing a browser route.**

**§N9 · The credential question — P7's negative finding is NOT overturned.**
Searched: all vendor terms retrieved in this track; all seven enforcement orders retrieved; the Alpaca broker disclosures; the TradingView broker integration manual; the QuantConnect brokerage documentation. **No SEC letter, release, staff guidance, court opinion or state order was located that turns on whose credentials a software vendor uses.** The three adjacent items are set out in Direct Answers above with their limits. The closest is a **broker's** contractual language ("at your direction"), not a regulator's.

**§N10 · Vendor terms that could not be read.**
`https://collective2.com/legal` → HTTP 403, and **no terms/legal/disclaimer URL appears anywhere in the Wayback CDX index for `collective2.com*`** across 3,000 captured URLs (only `.well-known/dnt-policy.txt`). `https://www.multicharts.com/terms-of-use/` → HTTP 403 live (read via Wayback instead, S2-12). `https://www.trade-ideas.com/terms-of-service/` and `/disclaimer/` → HTTP 404 (the operative document is the EULA, found and read, S2-13). `https://www.sierrachart.com/index.php?page=doc/DisclaimerAndTerms.php` → HTTP 404; **Sierra Chart's status statement is UNVERIFIED**. `https://ninjatrader.com/terms-of-service/` and `/disclaimer/` serve a marketing homepage, not legal text (both exactly 79,043 bytes) — the operative terms are the PDF at S2-09. TradingView's `/broker-api-docs/authentication/` and `/trading-integration/` returned the manual's index shell rather than section content; the architecture was obtained from `/integration-overview/` instead. **No clause anywhere in this document has been reconstructed from memory or inference; where I could not read it, it is marked UNVERIFIED.**

---

## Search log

Every query, including the ones that failed. Date: all 7 September 2026.

| # | Source / query | Endpoint | Result / access note |
|---|---|---|---|
| 1 | SEC AP discriminator test, `populate=ZZQQXNONSENSE` | sec.gov/enforcement-litigation/administrative-proceedings | 76,418 b, `no-results-text` — empty baseline established |
| 2 | SEC AP `populate=TradeStation` | ibid. | 79,003 b, 2 rows, "1 to 2 of 2 items" — populated baseline |
| 3 | SEC AP substring test `populate=Trality` | ibid. | 2 rows, both "American Ce**ntrality** Group" — **filter is substring** |
| 4 | SEC AP + LR sweep, 48 names × 2 | AP + LR listings | 96 queries; zeros per §N1; 7 orders located |
| 5–10 | 6 SEC order PDFs downloaded and text-extracted | sec.gov/files/litigation/admin/… | 33-11269, 34-95369, 34-101137, 34-101001, 34-92486, 33-10582 — all read |
| 11 | CourtListener first sweep, 24 unquoted queries | courtlistener.com/api/rest/v4/search/ | Completed; counts in survivor table |
| 12 | CourtListener quoted re-run, 46 queries @1.2 s | ibid. | **HTTP 429 on 44 of 46 — THROTTLED, not zero** |
| 13 | CourtListener quoted re-run @85 s spacing | ibid. | Still 429; "Rate limit exceeded: 50/hour" |
| 13a | CourtListener quoted sweep, 8 names × 2, paced 80-90 s | ibid. | **Completed: 13 of 16 returned COUNT; 3 THROTTLED.** Table in §N6 |
| 13b | CourtListener docket detail, `"Monegro v. Trade Ideas"` | ibid. | **`count: None` — rate-limited; nature of suit NOT verified** |
| 13c | CourtListener quoted sweep, 20 names × 2, paced 80-90 s w/ retries | ibid. | **Completed; 48 of 56 quoted queries returned COUNT. Full table in §N6** |
| 14 | CourtListener single probe | `?q=%22QuantConnect%22&type=o` | `{"detail":"Request was throttled…50/hour…1478 seconds"}` |
| 15 | BrokerCheck firm search, 21 names | api.brokercheck.finra.org/search/firm | 200; totals per §N4 |
| 16 | IAPD firm search, 21 names | api.adviserinfo.sec.gov/search/firm | 200; totals per §N4 |
| 17 | IAPD firm detail, Composer | api.adviserinfo.sec.gov/search/firm/311289 | 200 — `registrationStatus` Terminated 12/6/2024 |
| 18 | Composer Form ADV Part 1A | reports.adviserinfo.sec.gov/reports/ADV/311289/PDF/311289.pdf | 200, 1,020,767 b, 22 pp — read |
| 19 | Composer ADV pp. 8 & 15 rendered at 150 dpi | pdftoppm | Checkbox states read visually (Items 5.E/5.F/5.G, 8.C) |
| 20 | Composer ADV Part 2A brochure | reports.adviserinfo.sec.gov/…/311289-Brochure-887920.pdf | **HTTP 403 / S3 AccessDenied** — not read |
| 21 | BrokerCheck firm detail, CRD 325118 | api.brokercheck.finra.org/firm/325118 | **`{"message":"Forbidden"}`** |
| 22 | Composer disclosures (live) | composer.trade/disclosures | 200 — adviser sentence **absent** |
| 23 | Composer terms | composer.trade/terms | HTTP 404 |
| 24 | Collective2 legal | collective2.com/legal, /legal-terms | **HTTP 403** both |
| 25 | Collective2 CDX, 3,000 URLs | web.archive.org/cdx | **No terms/legal/disclaimer URL exists in the index** |
| 26 | Collective2 AutoTrade + TOS pages | Wayback 2011, 2021 | 200 — read, S2-19 |
| 27 | MultiCharts terms (live) | multicharts.com/trading-software/…/Terms_of_Use | **HTTP 403** |
| 28 | MultiCharts legal, CDX + 2016 snapshot | Wayback | 200 — read, S2-12; 0 status terms |
| 29 | NinjaTrader ToS PDF (live) | ninjatrader.com/downloads/TermsOfServiceAgreement.pdf | 200, 6 pp, 3,415 words — read |
| 30 | NinjaTrader ToS CDX, both paths | Wayback | Digest identical 2017-07-13 → 2025-03-27 |
| 31 | NinjaTrader ToS 2016 snapshot | Wayback 20160421061819 | 200, 3,427 words — 0 status terms |
| 32 | NinjaTrader ToS 2011 snapshot attempt | Wayback 20110929040528 | Returned live-file bytes (173,901 = current) — **discarded as unreliable** |
| 33 | NinjaTrader /terms-of-service/, /disclaimer/ | ninjatrader.com | 200 but both 79,043 b marketing homepage — soft-404 |
| 34 | QuantConnect terms | quantconnect.com/terms | 200 — §3.6 verified verbatim, heading confirmed |
| 35 | QuantConnect IB live-trading docs | quantconnect.com/docs/v2/…/interactive-brokers | 200 — credential + "We call the IB API" verbatim |
| 36 | TradingView Terms of Use | tradingview.com/policies/ | 200 — **no status statement located** |
| 37 | TradingView broker manual, overview + trading | tradingview.com/broker-api-docs/{overview,trading}/ | 200 — index shell only |
| 38 | TradingView integration overview | /broker-api-docs/integration-overview/ | 200 — **client-server architecture verbatim** |
| 39 | TradingView auth + trading-integration subpages | /broker-api-docs/{authentication,trading-integration}/ | 200 but index shell — section content not served |
| 40 | TradingView brokerage marketing | tradingview.com/brokerage-integration/ | 200 — lead-generation language verbatim |
| 41 | Trade Ideas terms / disclaimer | trade-ideas.com/terms/, /disclaimer/ | HTTP 404 both |
| 42 | Trade Ideas EULA | trade-ideas.com/eula/ | 200 — §III and §XII verbatim |
| 43 | Trade Ideas About | trade-ideas.com/about/ | 200 — "Founded in 2003" |
| 44 | Alpaca disclosures | alpaca.markets/disclosures | 200 — "at your direction" verbatim |
| 45 | Trality CDX | web.archive.org/cdx?url=trality.com | **Empty — no snapshot returned** |
| 46 | Freqtrade docs | freqtrade.io/en/stable/ | 200 — DISCLAIMER verbatim |
| 47 | Hummingbot Foundation | hummingbot.org/about/ | 200 — CoinAlpha origin + Cayman status verbatim |
| 48 | FINRA disciplinary `?search=` behaviour test ×3 | finra.org/rules-guidance/…/disciplinary-actions-online | All ~94,990 b, indistinguishable — **param silently ignored** |
| 49 | FINRA form field discovery | ibid. | Real fields: `firms`, `individuals`, `fda_search`, `case_id`, `op` |
| 50 | FINRA `?firms=NinjaTrader&op=Search` | ibid. | **5,905 b Cloudflare "Just a moment…" — BLOCK, not zero** |
| 51 | NFA BASIC case page (NinjaTrader Clearing 24BCC00012) | nfa.futures.org/BasicNet/basic-reg-actions-details.aspx | SPA shell — no data |
| 52 | NFA RPC transport + method list discovery | /BasicNet/basic-js/basic-rpc-client.js | 200 — envelope and allow-list recovered |
| 53 | NFA `getFirmSearchResults`, 9 signatures | /BasicNet/basic-api/DataHandlerSearch.ashx | **All `success:false`** |
| 54 | NFA `DataHandler.ashx`, 5 methods × 4 signatures | ibid. | **All failed** |
| 55 | NFA guessed REST paths ×2 | /basicnet/api/… | HTTP 403 |
| 55a | NFA enforcement index | /news/EnforceRegActionsSimple.aspx | 200, 133,848 b — **renders, but rows are client-loaded; contains no action data** |
| 55b | NFA enforcement JS | /cms/includes/js/enforcementRegSimple.js | 200, 21,693 b — call disclosed as `getEnforcementRegs(yearFrom, yearTo)` |
| 55c | NFA `getEnforcementRegs` POST, 4 candidate paths | /api/ and /news/api/DataHandlerEnforcementReg.ashx (±`?proxy`) | **All returned "Page Not Found" HTML, not JSON** |
| 55d | NFA alternate index paths ×3 | /news/PressReleases.aspx, /news/newsRegActions.asp, /about/regulatory-actions.html | All identical 128,061-b soft-404 |
| 56 | CFTC listing filter behaviour ×3 | cftc.gov/PressRoom/PressReleases?… | All 65,182 b — **params ignored** |
| 57 | CFTC site search | cftc.gov/search?keys= | **HTTP 403** |
| 58 | CFTC enforcement pages 0–60 | /LawRegulation/EnforcementActions/index.htm?page=N | 61 distinct pages, 3,165,069 b; control `Ellison` = 2 |
| 59 | CFTC NinjaTrader Clearing order | cftc.gov/media/11316/…/download | 200 — Docket 24-27 read |
| 60 | WA DFI index + filter-param discovery | dfi.wa.gov/securities-enforcement-actions | `title=` works; `search`/`respondent`/`combine` ignored |
| 61 | WA DFI `title=` sweep, 17 names | ibid. | 0 except 2 false positives, both verified non-vendor |
| 62 | WA DFI year pages 2002–2024 | /securities-enforcement-actions/securities<YYYY> | 23 pages, 3,328,054 b; control `Solium` → 2020 ✓ |
| 63 | WA DFI initial URL guesses ×3 | /securities/administrative-orders etc. | HTTP 404 / 403 — corrected via link discovery |
| 64 | EDGAR full-text, 18 names | efts.sec.gov/LATEST/search-index?q= | Counts per §N5 |
| 65 | Wayback first-snapshot, 14 domains | web.archive.org/cdx | Dates in survivor table |
| 66 | Composer homepage 2021 + 2022 | Wayback 20210909065710, 20220302061408 | 200 — verbatim, S2-02 |
| 67 | Composer advisory agreement 2024 | Wayback `_next/data/…/legal/advisory-agreement.json` | 200 (gzip) — adviser sentence verbatim, S2-03 |
| 68 | Composer legal-route diff 2024 / 2025 / 2026 | Wayback CDX | `advisory-agreement` present 2024, **absent** 2025-12 and 2026-04 |
| 69 | TradeStation automated execution docs ×3 | help.tradestation.com/…/automated_execution/ | 200 — verbatim, S2-14 |
| 70 | TradeStation Important Information | tradestation.com/important-information/ | 200 — 0 hits for "not a broker", "investment advice", "recommend"; **but links onward to DisclosureTSCompanies** |
| 70a | TradeStation Group Companies disclosure | tradestation.com/DisclosureTSCompanies → cdn.tradestation.com/uploads/TradeStation-Group-Inc-Companies.pdf | 308 redirect then 200 — **"not a financial services company" verbatim**, S2-14A |
| 70b | Same PDF, Wayback CDX + Apr 2024 version | web.archive.org | 16 captures; operative sentence **identical** 04-17-2024 vs 05-13-2026 |
| 71 | Sierra Chart disclaimer | sierrachart.com/…DisclaimerAndTerms.php | HTTP 404 — **UNVERIFIED** |
| 72 | Hummingbot terms | hummingbot.org/legal/terms-of-use/ | HTTP 404 |

---

## ◇ list — resting on secondary confirmation only, flagged for primary verification

| Item | What is unverified | What is needed |
|---|---|---|
| **Trality wind-down** (S2-21) | Founded 2019 Vienna; discontinued 31 Jul 2023; Aug 2023 insolvency. **No primary source reached; `trality.com` has no Wayback CDX record.** | Austrian insolvency register; any vendor statement. Out of US scope regardless. |
| **NFA registration status** (§N8) | Whether NinjaTrader, MultiCharts, Sierra Chart or Trade Ideas is or ever was NFA-registered as a **CTA** — the datum directly comparable to *Taucher v. Born* | Browser route to NFA BASIC |
| **NFA case 24BCC00012** | A second NinjaTrader-family NFA registration action surfaced in search-result metadata; **primary document not retrieved** (the CFTC order at S2-11 is a *different* matter, Docket 24-27) | Browser route to NFA BASIC |
| **FINRA disciplinary history** (§N7) | All vendors — **no search performed at all** | Browser route past Cloudflare |
| **CourtListener quoted counts** (§N6) | **48 of 56 quoted queries closed.** Still THROTTLED: `"NinjaTrader"`/o, `"TradingView"`/r, `"Freqtrade"`/o, `"CoinAlpha"`/o, `"ZuluTrade"`/o+r, `"AmiBroker"`/o, `"Composer Securities"`/r (closed on 2nd run) | Re-run from another IP or with an API token |
| **`"Trality"` CourtListener counts** (§N6) | o=74, r=106 are **pure substring noise** ("neu*trality*") and carry no information | Requires an exact-entity search, not a string search |
| **PRIVATE SUITS NAMING SURVIVOR VENDORS** (§N6) — ***Cantero v. Tradestation Technologies, Inc.*** (S.D. Fla. 2010); ***Suresh v. NinjaTrader, LLC*** (D. Colo. 2022); ***Alpha Futures Ltd v. NinjaTrader Group, LLC*** (N.D. Ill. 2026); ***Monegro v. Trade Ideas LLC*** (S.D.N.Y. 2021); ***Gurung v. MetaQuotes Ltd.*** (E.D.N.Y. 2023) | **Case names, courts and filing dates only. No complaint, docket entry or nature-of-suit code retrieved. I do NOT assert what any was about.** | Retrieve the complaints. ***Cantero v. Tradestation Technologies*** is the priority: it is the only located suit naming a vendor's **software entity** rather than its broker-dealer, and that entity is the one declared "not a financial services company" (S2-14A). If any of these tested a vendor's status or its disclaimer, it is the only located instance of that happening and would be the most valuable single document in the track. **HIGHEST-VALUE OPEN ITEM.** |
| **Sierra Chart status statement** (§N10) | Never retrieved (404) | Locate current legal page |
| **TradingView founding date** | Domain first captured 2003, but the company is generally dated to 2011 — the early snapshot may be a prior registrant | Primary corporate record |
| **Composer ADV Part 2A** (§N4) | Narrative description of the service in the brochure — would be the best single quote on how Composer described user-authored strategies to the SEC | Browser route past S3 AccessDenied |
| **TradeStation "statement concerning fully automated trading"** | The help page refers to a dialog the user must read and accept; **its text was not retrieved** — it is in-product, not on the web | In-product capture |

---

## Adverse register

| Authority / source | Threat 1–5 | Does the configuration distinguish it? — blunt |
|---|---|---|
| **Composer Form ADV Part 1A, Items 5.E, 5.F, 5.G, 8.C (S2-01)** — flat **subscription fee only**, user-authored rules, yet SEC-registered as an adviser, "portfolio management", **$46.7M discretionary / $0 non-discretionary**, "Yes" to discretion over security and amount | **5** | **Partly, and only on discretion.** It kills the fee argument outright: the configuration's flat monthly membership is the same kind of compensation Composer checked at Item 5.E, and Composer registered anyway. It also kills any reliance on user-authorship alone: Composer's users write their own symphonies and it still reported 100% discretionary. What survives is real but narrow — Composer answered "Yes" to Item 8.C(1) and (2) and reported non-discretionary AUM of **$0**; the configuration grants discretionary authority to nobody in V1, every order is minted by an explicit member act on a runtime-owned surface, and standing execution is expressly not shipped. Note Composer also declined Item 5.G(8) "Publication of periodicals or newsletters" — it did not attempt the *Lowe* route. |
| **Composer homepage, Sep 2021 (S2-02)** — asserted SEC adviser registration while it was still "a layer on top of brokerages" using the user's own Alpaca account | **5** | **Weakly.** This is the configuration's own architecture, registered from day one. The only distinctions are the per-order act and the absence of unattended rebalancing ("Watch your trades execute automatically"). Nothing located shows Composer ever offered a per-order mode, so the comparison cannot be pushed past that single fact. |
| **TradingView brokerage-integration marketing (S2-08)** — "20K+ Leads distributed monthly", "Acquire new customers", "Let traders come to you" | **4** | **Yes, decisively — but the survival proves nothing.** This is *Neovest* ¶3 "solicitation of customers for those services" performed openly at scale with no located enforcement, which is exactly the silence P7 forbids treating as safety. The configuration's distinction is real and independent: no payment from brokers or issuers at all, no transaction-based compensation, and a marketing rule against presenting itself as a trading, execution or signal service. *Neovest* required transaction-based compensation **and** solicitation together; the configuration has neither limb. |
| ***In re eToro USA LLC*, Rel. 34-101001 ¶¶4, 5, 7 (S2-16)** — the only §3(a)(4) holding located in this track | **3** | **Yes, on every operative fact.** The Commission built "acted as a broker" from: customer funds in an omnibus account; **private keys held by eToro or its affiliate**; a **fixed fee on every transaction**; routing to an affiliate; daily netting; and acting "as their agent". The configuration has none of the six — no funds or securities, credentials only in the member's local keychain, nothing per trade, no routing or venue selection, no cross-member netting, and an order minted by the member's own act that the broker's own terms call the customer's direction. The gap is wide and it is factual, not characterisational. |
| **Collective2 AutoTrade (S2-19)** — C2's servers adjust the account; third-party-authored strategies; 50/60% revenue split | **3** | **Yes, and it is not a survivor at all.** Authorship is the dividing line: the subscriber adopts somebody else's rules, which is the *Weiss Research* fact pattern. It belongs with eToro/ZuluTrade as a contrast and is classified that way in the survivor table, not counted as a survivor. |
| **Trade Ideas HOLLY, EULA §XII (S2-13)** — "may highlight different types of systems or algorithms" | **2** | **Yes.** HOLLY is company-controlled selection and the EULA concedes highlighting. The configuration expressly forbids exactly this — "Nothing highlighted, no picks"; no company-controlled choice may determine which instrument qualifies. Trade Ideas is *further* from the configuration than the configuration is from the adverse line, so its unchallenged survival is weaker evidence than it looks. |
| **The FINRA and NFA walls (§N7, §N8)** | **3** | **No — this is an evidentiary gap in this track, not a distinguishable authority.** No FINRA disciplinary search was performed at all, and CTA registration status — the datum directly comparable to *Taucher v. Born*'s holding that the plaintiffs "fall squarely within the definition of a CTA" — is unverified for every desktop futures platform studied. Any reader relying on this track must treat the survivor picture as **incomplete on precisely the futures-side question *Taucher* makes live.** |


---

# S2b · TRACK 2 (supplement) — The five private suits naming survivor vendors: what they were actually about

**Commission:** close Track 2's highest-value open item. Track 2's CourtListener sweep surfaced five private suits naming survivor vendors as parties, with case names, courts and filing dates only, and asserted nothing about any of them. This document establishes what they were.

---

## Headline, stated first

**Four of the five are closed, and none of the four put a vendor's status, its registration, or its status statement in issue. The fifth could not be closed and is reported as UNKNOWN, not as a zero.**

- **Closed, with certainty, from the courts' own records:** *Cantero* — unpaid overtime (NOS 710). *Suresh* — copyright (NOS 820). *Monegro* — ADA website accessibility (NOS 446). *Gurung* — civil RICO (NOS 470). Not one pleads, argues or decides investment-adviser status, broker-dealer status, SEC/CFTC/NFA registration, or a vendor disclaimer. Where full text was machine-scanned, the counts for "broker-dealer", "investment adviser", "registered", "registration", "Exchange Act", "Advisers Act", "CFTC" and "FINRA" are **zero**.
- **NOT closed:** ***Alpha Futures, Limited v. NinjaTrader Group, LLC*** (N.D. Ill. 1:26-cv-08846, filed 24 Jul 2026, **still open**). Its 12-page Verified Complaint could not be retrieved by any free route. The clerk coded it **NOS 890 / 28 U.S.C. §1332 diversity tort**, not federal question and not NOS 850 (Securities/Commodities/Exchange) — **an observation about coding, not a conclusion about what was pleaded.** It costs about **$1.20** to settle, or nothing under PACER's quarterly waiver. **I do not assert what it was about, and it must not be counted as a negative.**

So the Track 2 open item closes **four-fifths**, on retrieved docket text rather than inference, with one priced, named residual.

***Cantero v. Tradestation Technologies, Inc.*** — the priority document, the only suit Track 2 located against a vendor's **software entity**, the entity that declares itself "not a financial services company" (S2-14A) — **is an unpaid-overtime wage case.** Nature of suit **710 Labor: Fair Labor Standards Act**; cause **29:0201 Fair Labor Standards Act**. Alejandro Cantero sued his employer for overtime, together with three TradeStation Group officers named individually in the ordinary FLSA employer-liability pattern. It settled and was dismissed with prejudice five months after filing. **The "not a financial services company" sentence was never in issue in it, and could not have been:** the case is about hours and wages, and the corporate defendant appears as an *employer*, not as a software vendor.

**The one thing this document does establish about the status statement is a pure negative, and it should be read as exactly that and no more:** across everything retrieved here, no private litigant has been located who put a retail trading-software vendor's status statement in issue. That is now a documented absence with endpoints and counts attached, where before it was an open question. It remains an absence in an incomplete corpus — see the standing caveat below, which governs every count in this file.

---

## Standing caveats governing this entire document

**1 · A private suit is not a regulator's view.** Even a case squarely about a vendor's status would be evidence about what a private litigant argued and what one court said — not about what the Commission would do. Every entry below is marked **NOT EVIDENCE on Q1/Q2/Q3** unless it says otherwise, and none says otherwise. Nothing in this file may be read as authority on Q1 or Q2.

**2 · Every zero here is a zero in an incomplete corpus.** Carried forward from Track 3 and now applying to my own null results: **CourtListener's opinion index does not contain *SEC v. Coinbase* or *Risley*, and contains no SEC or CFTC administrative decisions at all.** The RECAP archive is likewise a quarterly, donation-driven mirror of PACER, not a complete one. A case absent from RECAP is **not located**, which is not the same as **not existing**. Where I report COUNT 0 I have, wherever possible, run a **control query on the same endpoint that returns a non-zero**, so the zero is distinguishable from an access failure; where I could not, I say so.

**3 · Party status was verified, not assumed.** The brief warned that CourtListener searches full text, so a vendor can appear inside another party's filing without being a party. Every case below was checked against a **parties array from the docket itself**, not against a search hit. Where a case turned out not to be a suit against the vendor, that is recorded as a finding.

**4 · No purchase was made.** No PACER account was created, no payment details were entered, nothing was bought. Where a document is paywalled I record the docket number and the exact document number, and the published fee, so it can be bought deliberately later.

---

## Summary table

| # | Case | Court | Docket | Filed | Defendant entity — software or broker | Nature of suit | **Status or status statement in issue?** | Disposition | What could not be retrieved |
|---|---|---|---|---|---|---|---|---|---|
| 1 | *Cantero v. Tradestation Technologies, Inc.* | S.D. Fla. (Miami) | **0:10-cv-60271**, PACER case id 352447, Judge Marcia G. Cooke | 2010-02-24 | **SOFTWARE** — *Tradestation Technologies, Inc., a Florida Corporation*, plus Salomon Sredni, David H. Fleischman and Marc J. Stone, each "Individually" | **710 Labor: Fair Standards**; cause *29:0201 Fair Labor Standards Act*; federal question; jury demanded by plaintiff | **NO.** An unpaid-overtime wage claim. No adviser, broker, registration or disclaimer issue appears anywhere on the 30-entry docket | **Settled.** Stipulation of dismissal with prejudice (DE 23, 1 Jul 2010); case administratively closed pending FLSA settlement review (DE 24); **ORDER DISMISSING CASE (DE 26, 29 Jul 2010)**. Terminated 2010-07-29 | **No document text.** All 30 entries show `is_available: false` — no PDF was ever purchased into RECAP. The complaint (DE 1) and answer (DE 12) are PACER-only |
| 2 | *Suresh v. Ninjatrader, LLC* | D. Colo. (Denver) | **1:22-cv-02903**, Judge Nina Y. Wang / Mag. S. Kato Crews | 2022-11-07 | **SOFTWARE** — *Ninjatrader, LLC*, sole defendant. **Not** NinjaTrader Clearing, LLC (the FCM) | **820 Copyright**; cause *17:501 Copyright Infringement*; federal question; jury demanded by plaintiff | **NO.** A copyright infringement claim by an individual photographer-plaintiff. No securities, adviser, broker, registration or disclaimer element in the coded docket | **Voluntarily dismissed with prejudice** by plaintiff under Rule 41(a)(1)(A)(i); terminated 2023-01-17. Defendant had served an Offer of Judgment 2022-12-20 | No document text. All RECAP docs `is_available: false`. Complaint (DE 1) is PACER-only |
| 3 | *Alpha Futures, Limited v. NinjaTrader Group, LLC et al* | N.D. Ill. (Chicago) | **1:26-cv-08846**, PACER case id 504834, Judge John Robert Blakey / Mag. Heather K. McShain (settlement) | 2026-07-24 | **SOFTWARE / PLATFORM, not the FCM** — *NinjaTrader Group, LLC* and *Tradovate, LLC* (both **terminated as parties** 2026-08-06); *NinjaTrader, LLC* and *Tradovate Technologies, LLC* remain. **No entity with "Clearing" in its name is a defendant** | **890 Other Statutes – Other Statutory Actions**; cause **28:1332 Diversity–Tort/Non-Motor Vehicle**; demand **$9,999,000**; **no jury demand** | **UNKNOWN — the only genuine unknown of the five.** The complaint could not be retrieved. The clerk coded it as a **diversity** tort, not federal question, and not NOS 850 (Securities/Commodities/Exchange). That is an observation about coding, **not** a conclusion about what was pleaded | **STILL OPEN** (`date_terminated: null`; PacerMonitor status "Active"). A TRO/preliminary-injunction motion was filed at DE 5 on 2026-07-25; **no ruling on it was located** | **The 12-page Verified Complaint (DE 1) and the Civil Cover Sheet (DE 2).** No RECAP item, no free PDF, no published opinion. See "What remains unretrieved" |
| 4 | *Monegro v. Trade Ideas LLC* | S.D.N.Y. | **1:21-cv-01518-AT**, Judge Analisa Torres / Mag. Stewart D. Aaron | 2021-02-19 | **SOFTWARE** — *Trade Ideas LLC* | **446 Americans with Disabilities Act – Other** (FJC IDB, the AO's own coding); statute 42 U.S.C. §12101; **class action**; plus NYCHRL | **NO.** A templated website-accessibility complaint about image `alt` text. Its only description of the defendant's business is the phrase "Defendant is a stock trading company." Full-text scan of the complaint for `broker\|dealer\|regist\|SEC\|CFTC\|NFA\|FINRA\|disclaim` → **0 hits** | **Settled** (IDB `DISP 13 – settled`), **59 days** after filing; terminated 2021-04-19. `JUDGMENT 0` — **no judgment, no merits ruling** | Settlement agreement **not obtainable at any price** — the court declined to retain jurisdiction and it was never made public record. ECF 12 (settlement notice) unread |
| 5 | *Gurung v. MetaQuotes Ltd. et al* | E.D.N.Y. | **1:23-cv-06362-OEM-PK**, Judge Orelia E. Merchant | 2023-08-24 | **SOFTWARE** — *MetaQuotes Ltd.* (Cyprus), *MetaQuotes Software Corp.* (Bahamas), *MetaQuotes Software Corp.* (Delaware), *Forexware LLC*. **No MetaQuotes broker or FCM affiliate exists or is named** | **470 Civil RICO** (FJC IDB); statute 18 U.S.C. §1962; plus fraud, conspiracy, breach of contract | **NO.** RICO and fraud arising from a "pig-butchering" scam run through the MT5 platform. Machine count across the full 22-page opinion: "broker-dealer" 0, "investment adviser" 0, "registered" 0, "registration" 0, "Exchange Act" 0, "Advisers Act" 0, "CFTC" 0, "FINRA" 0. Same zero across complaint and opposition brief | **Dismissed as to the MetaQuotes entities on *forum non conveniens*, WITHOUT PREJUDICE**, enforcing the **MT5 EULA's Cyprus forum-selection clause** (ECF 60, 16 Aug 2024); Forexware dismissed on RICO pleading grounds. Terminated 2025-02-18 | 2d Cir. appeal No. 25-328 **UNVERIFIED** — no CA2 RECAP item, no published opinion |
| — | *(bonus, same sweep)* *Sanchez v. TradeStation Group, Inc.* | S.D.N.Y. | 1:21-cv-04723-RA | 2021-05-26 | Holding company — *TradeStation Group, Inc.* | ADA Title III, 42 U.S.C. §12181 (class action) | **NO.** Website accessibility for blind users | Not retrieved | Docket sheet absent from the RECAP item; only DE 1, 5, 10 PDFs present |
| — | *(bonus)* *Chart Trading Development, LLC v. TradeStation Group, Inc. et al* | E.D. Tex. (Tyler) | 6:15-cv-1136-JDL (lead case) | 2015 | Group + affiliates | Patent | **NO.** Covered Business Method patent review stay | Memorandum Opinion and Order, 29 Mar 2016 | — |
| — | *(bonus)* *Trading Technologies Int'l v. TradeStation Technologies Inc.* | Fed. Cir. | 18-1443 | 2018-01-22 | **SOFTWARE** — TradeStation Technologies Inc. as appellee | Patent (CBM appeal; AIA constitutional challenge certified to the Attorney General) | **NO.** Patent | Not retrieved | — |

---

## Register entries

### S2b-01 · *Cantero v. Tradestation Technologies, Inc.*, No. 0:10-cv-60271 (S.D. Fla.), docket sheet as mirrored in the RECAP archive · `https://archive.org/download/gov.uscourts.flsd.352447/gov.uscourts.flsd.352447.docket.json` (canonical: `https://www.courtlistener.com/docket/8247431/cantero-v-tradestation-technologies-inc/`) · retrieved 7 Sep 2026

- **Type:** Federal district court docket sheet (PACER, mirrored by the Free Law Project onto the Internet Archive as item `gov.uscourts.flsd.352447`)
- **Date / status:** Filed **24 Feb 2010**; terminated **29 Jul 2010**. Closed. Not appealed.
- **Court / judge:** United States District Court for the Southern District of Florida, Miami Division. Assigned to **Judge Marcia G. Cooke**; referred to **Magistrate Judge Ted E. Bandstra** for non-dispositive pretrial proceedings.

**Verbatim — the docket's own classification fields:**

> `"docket_number": "0:10-cv-60271"`
> `"pacer_case_id": "352447"`
> `"cause": "29:0201 Fair Labor Standards Act"`
> `"nature_of_suit": "710 Labor: Fair Standards"`
> `"jurisdiction_type": "Federal Question"`
> `"jury_demand": "Plaintiff"`
> `"date_filed": "2010-02-24"`
> `"date_terminated": "2010-07-29"`
> `"assigned_to_str": "Marcia G. Cooke"`
> `"referred_to_str": "Ted E. Bandstra"`

**Verbatim — the parties, with the docket's own `extra_info` annotations:**

> Plaintiff: **"Alejandro Cantero"** — *"and other similarly-situated individuals"* — counsel Anthony Maximillien Georges-Pierre
> Defendant: **"Tradestation Technologies, Inc."** — *"a Florida Corporation"* — counsel Andrew Lawrence Rodman
> Defendant: **"Salomon Sredni"** — *"Individually"*
> Defendant: **"David Fleischman"** — *"Individually"*
> Defendant: **"Marc J. Stone"** — *"Individually"*

**Verbatim — the docket entries that establish subject matter and disposition** (all quoted from the docket text as filed):

> **DE 1** (2010-02-24): "COMPLAINT for Damages against David Fleischman, Salomon Sredni, Marc J. Stone, Tradestation Technologies, Inc. Filing fee $ 350.00, filed by Alejandro Cantero. (Attachments: # 1 Civil Cover Sheet)"

> **DE 6** (2010-03-05): "**Order of Court-Mandated Requirements in FLSA case** Statement of Claim due by 3/26/2010.. Signed by Judge Marcia G. Cooke on 3/5/10."

> **DE 11** (2010-03-29): "Statement of: STATMENT OF CLAIMS by Alejandro Cantero" *(sic — "STATMENT" is the docket's own typographical error)*

> **DE 12** (2010-04-07): "Defendants' ANSWER and Affirmative Defenses to Complaint by David Fleischman, Salomon Sredni, Marc J. Stone, Tradestation Technologies, Inc."

> **DE 16** (2010-05-07): "SCHEDULING ORDER: Jury Trial set for 9/27/2010 09:30 AM in Miami Division before Judge Marcia G. Cooke…"

> **DE 17** (2010-05-07): "ORDER REFERRING CASE to Mediation. Mediation Deadline 7/30/2010."

> **DE 23** (2010-07-01): "**STIPULATION of Dismissal with Prejudice** by David Fleischman, Salomon Sredni, Marc J. Stone, Tradestation Technologies, Inc. (Attachments: # 1 Exhibit A - Proposed Order)"

> **DE 24** (2010-07-09): "**Order Administratively Closing Case. Settlement Agreement due by 7/22/10.**. Signed by Judge Marcia G. Cooke on 7/8/10."

> **DE 25** (2010-07-15): "RESPONSE/REPLY to 24 **Administrative Order Requiring Parties to Submit FLSA Settlement Agreement for Review** by David Fleischman, Salomon Sredni, Marc J. Stone, Tradestation Technologies, Inc."

> **DE 26** (2010-07-29): "**ORDER DISMISSING CASE.** Signed by Judge Marcia G. Cooke on 7/29/2010."

**Verbatim — the FJC Integrated Database record for the case** (`idb_data`), which independently classifies it:

> `"nature_of_suit": 710`, `"section": "0201"`, `"jurisdiction": 3`, `"plaintiff": "CANTERO"`, `"defendant": "TRADESTATION TECHNOLOGI, ET AL"`, `"date_filed": "2010-07-29"`, `"date_terminated": "2010-07-29"`, `"monetary_demand": 0`, `"amount_received": 0`, `"county_of_residence": 12011`, `"district": "flsd"`, `"circuit": "ca11"`, `"pro_se": 0`

**Decoding those IDB codes — the codebook was subsequently retrieved.** The FJC's *Civil Codebook 1988 Forward* (`https://www.fjc.gov/sites/default/files/idb/codebooks/Civil%20Codebook%201988%20Forward%2010252023.pdf`, retrieved 7 Sep 2026) defines:
> **DISP 13** = "13 – settled" (listed under the heading "Dismissals:")

So the Administrative Office's own coding of *Cantero* is **settled** — which matches, independently, what the docket text says in words at DE 23–26 (stipulation of dismissal with prejudice → administrative closure pending FLSA settlement review → order dismissing case). **Two independent sources, the docket narrative and the AO's statistical record, agree.** `monetary_demand: 0` and `amount_received: 0` are the IDB's standard entries where no sum is stated on the civil cover sheet; they do **not** indicate the settlement was for nothing, and I draw no inference from them. I do not translate `procedural_progress: 10`, which the codebook's progress table does not resolve unambiguously for this record.

**Who the three individual defendants were — verified independently.** TradeStation Group, Inc.'s own proxy statement (Form DEF 14A) filed **27 April 2010**, two months after this complaint, at `https://www.sec.gov/Archives/edgar/data/1111559/000119312510094305/ddef14a.htm` (retrieved 7 Sep 2026), lists under "NAME / AGE / POSITION WITH THE COMPANY":

> "Salomon Sredni 42 **Chief Executive Officer and President and Director** · David H. Fleischman 64 **Chief Financial Officer, Vice President of Finance and Treasurer** · Marc J. Stone 49 **General Counsel, Vice President of Corporate Development and Secretary**"

- **What it establishes:** *Cantero* is an **unpaid-overtime wage suit** under the Fair Labor Standards Act, brought by one employee "and other similarly-situated individuals" against his corporate employer and three of the parent group's senior officers sued in their individual capacities. That is the standard FLSA pleading pattern, which reaches individuals who qualify as an "employer" under 29 U.S.C. §203(d). The case was mediated, settled, stipulated to dismissal with prejudice, and dismissed by court order after the FLSA settlement review that DE 24 and DE 25 record. **No merits opinion exists**; every order on the docket is scheduling, referral, extension or administrative.

  **Adviser status, broker-dealer status, registration, and the vendor's own status statement appear nowhere on this docket.** The corporate defendant is named as an **employer**, not as a software vendor, and nothing about what its software does was at issue.

- **Q1 / Q2 / Q3: NOT EVIDENCE.** Recorded because Track 2 flagged it as the single highest-value open item and it must be characterised so that a name-match is not left looking like an unexplained event.
- **Level 1** as a court record of what the case was; **irrelevant to all three questions.**
- **Application note:** The value of this entry is entirely negative and entirely real. Track 2 identified *Cantero* as potentially "the most valuable single document in the track" because TradeStation Technologies, Inc. is the only located vendor entity that expressly declares itself "**not a financial services company**" (S2-14A), and a suit naming that entity raised the possibility that a private litigant had put that sentence in issue. **It did not.** The sentence has still never been tested by anyone, on the located record. The configuration therefore gains nothing and loses nothing from *Cantero*; what changes is that Track 2's open question is now closed, and the S2-14A status statement stands exactly where it stood — as unchallenged market practice, never as adjudicated ground.

### S2b-02 · Corroborating sweep — every RECAP-mirrored suit naming a TradeStation **software-side** entity · `https://archive.org/advancedsearch.php` · retrieved 7 Sep 2026

Because *Cantero* mattered only as "the only located suit against a vendor's software entity", I tested that characterisation directly rather than accepting it.

**Query:** `q=title:("Tradestation Technologies")`, `rows=100`, `output=json` → **numFound = 2**
> `gov.uscourts.flsd.352447` — *Cantero v. Tradestation Technologies, Inc.*
> `gov.uscourts.cafc.18-1443` — *Trading Technologies Intl. v. TradeStation Technologies Inc.*

**Query:** `q=title:(Tradestation)`, `rows=100` → **numFound = 19**, of which 8 are `gov.uscourts.*` court items and 11 are unrelated non-court uploads (EasyLanguage manuals, indicator packs, software torrents). The 8 court items:
> `gov.uscourts.flsd.352447` *Cantero v. Tradestation Technologies, Inc.*
> `gov.uscourts.cafc.18-1443` *Trading Technologies Intl. v. TradeStation Technologies Inc.*
> `gov.uscourts.nysd.560974` *Sanchez v. Tradestation Group, Inc.*
> `gov.uscourts.ncwd.74438` *TradeStation Securities, Inc. v. Barclay* — TradeStation as **plaintiff**
> `gov.uscourts.flsd.721416` and `gov.uscourts.flsd.721455` *Cedar Lane Technologies Inc. v. Tradestation Securities, Inc.*
> `gov.uscourts.flsd.668249` and `gov.uscourts.ca11.89442` *Inter-Coastal Waterways LLC v. Tradestation Securities, Inc.*
> `gov.uscourts.wiwd.42135`, `.42136` *United States v. $8,190,248 in Funds Deposited in Account Number 21044740 Labeled "MFS1 Futures" at TradeStation Securities, Inc.* — a civil forfeiture in which TradeStation is the **custodian of the res**, not a defendant

**Corrective finding.** Track 2's statement that *Cantero* is "the only located suit naming a vendor's SOFTWARE entity" is **slightly overstated**. There is a second: ***Trading Technologies Int'l v. TradeStation Technologies Inc.***, Fed. Cir. No. **18-1443**, docketed 22 Jan 2018 — a patent appeal arising from Covered Business Method review, in which the appellant filed a "Notice … of Constitutional Challenge to Federal Statute" (DE 25, 7 Jun 2018) that the court certified to the Attorney General (DE 26, 8 Jun 2018, staying briefing). It is a **patent** case and touches no status question. Track 2's substantive point survives intact — *Cantero* remains the only located suit against the software entity **in a district court**, and neither suit tests status — but the count is two, not one.

*(Note on that item: the RECAP `docket.json` for `gov.uscourts.cafc.18-1443` carries `case_name: "Trading Technologies Int'l v. United States"` while the Internet Archive item title and the CourtListener slug both read "Trading Technologies Intl. v. TradeStation Technologies Inc." The discrepancy appears to follow the United States' intervention on the constitutional challenge. I report both strings rather than choosing between them. Federal Circuit dockets carry no nature-of-suit code; the fields are empty.)*

### S2b-03 · *Sanchez v. TradeStation Group, Inc.*, No. 1:21-cv-04723-RA (S.D.N.Y.), Complaint (DE 1) · `https://archive.org/download/gov.uscourts.nysd.560974/gov.uscourts.nysd.560974.1.0.pdf` · retrieved 7 Sep 2026

Not one of the five, but surfaced by the same sweep and retrieved because it is one of only three TradeStation-related documents whose **full text** is free.

- **Type:** Class action complaint (federal district court), 26 pages
- **Verbatim, caption and ¶¶2, 4–5:**
  > "CRISTIAN SANCHEZ, on behalf of himself and all others similarly situated, Plaintiffs, v. TRADESTATION GROUP, INC., Defendant. **CLASS ACTION COMPLAINT AND DEMAND FOR JURY TRIAL**" (p.1)

  > "2. Plaintiff is a visually-impaired and legally blind person who requires screen-reading software to read website content using his computer." (p.1)

  > "4. Plaintiff brings this civil rights action against Defendant for its failure to design, construct, maintain, and operate its website to be fully accessible to and independently usable by Plaintiff and other blind or visually-impaired people. Defendant's denial of full and equal access to its website, and therefore denial of its goods and services offered thereby, is a violation of Plaintiff's rights under the **Americans with Disabilities Act ("ADA")**." (p.2)

  > "6. This Court has subject-matter jurisdiction over this action under 28 U.S.C. § 1331 and 42 U.S.C. § 12181, as Plaintiff's claims arise under **Title III of the ADA**, 42 U.S.C. § 12181, et seq., and 28 U.S.C. § 1332." (p.2)
- **What it establishes:** The private litigation these vendors actually attract is **website-accessibility, employment, patent and consumer** litigation. Not status litigation. This is the second independent instance in this document of a suit naming a TradeStation entity that has nothing to do with what the software does.
- **Q1 / Q2 / Q3: NOT EVIDENCE.**
- **Level 1** as a court record; irrelevant to the questions.

### S2b-04 · *Suresh v. Ninjatrader, LLC*, No. 1:22-cv-02903 (D. Colo.) · CourtListener v4 search API structured docket fields; PacerMonitor free docket `https://www.pacermonitor.com/public/case/46743300/Suresh_v_Ninjatrader,_LLC`; Docket Alarm free preview `https://www.docketalarm.com/cases/Colorado_District_Court/1--22-cv-02903/Suresh_v._Ninjatrader_LLC/` · retrieved 7 Sep 2026

- **Type:** Federal district court docket sheet (three independent sources agreeing on every coded field)
- **Date / status:** Filed **7 Nov 2022**; terminated **17 Jan 2023**. Closed.
- **Verbatim — coded docket fields** (CourtListener structured fields, corroborated by PacerMonitor and Docket Alarm):
  > `suitNature: "820 Copyright"` · `cause: "17:501 Copyright Infringement"` · `jurisdictionType: "Federal Question"` · `juryDemand: "Plaintiff"` · `dateFiled: "2022-11-07"` · `dateTerminated: "2023-01-17"` · `assignedTo: "Nina Y. Wang"` · `party: ['Ninjatrader, LLC', 'Ajay Suresh']`

  PacerMonitor renders the same code as "820 Property Rights - Copyrights". Division: Denver. Magistrate: S. Kato Crews. Plaintiff's counsel: William Serge Wenzel (Red Road Legal, PC) and Jonah A. Grossbardt (SRIPLAW, P.A.).
- **Party status — VERIFIED, not assumed.** NinjaTrader appears in CourtListener's **structured `party` array**, not merely in document full text. It is a true named defendant. **The sole defendant is `Ninjatrader, LLC`** — the software entity — not `NinjaTrader Clearing, LLC` (the registered FCM that was the respondent in CFTC Docket No. 24-27 at S2-11), and not `NinjaTrader Group, LLC`.
- **Docket entries visible free** (PacerMonitor, retrieved 7 Sep 2026): Complaint for Copyright Infringement (11/07/2022) · Notice of Entry of Appearance · Corporate Disclosure Statement · Case assignment (11/08) · **Report re: Copyright sent to Copyright Office** (11/08) · Summons issued · Order referring to magistrate (11/10) · Waiver of service executed (12/01) · **Notice of Service of Offer of Judgment by defendant (12/20/2022)** · **Notice of Voluntary Dismissal With Prejudice (01/16/2023)** · Minute order; case terminated (01/17/2023).
- **What it establishes:** *Suresh* is a **copyright infringement** action under 17 U.S.C. §501 against the NinjaTrader software entity, resolved by the plaintiff's own voluntary dismissal with prejudice roughly a month after the defendant served an Offer of Judgment. The clerk's AO-121 "Report re: Copyright sent to Copyright Office" entry is filed in every copyright case and independently corroborates the coding.

  **Adviser status, broker-dealer status, registration and the vendor's own status statement are not in it.** A case pleading those would ordinarily carry NOS **850 (Securities/Commodities/Exchange)**; this one carries 820.
- **Merits opinion: NONE EXISTS.** The case ended on a Rule 41(a)(1)(A)(i) notice, which takes effect without judicial action, so no merits ruling was reached. Independently confirmed against govinfo: no `USCOURTS-cod-1_22-cv-02903` package exists (the PDF path returns a 44,165-byte `text/html` error page rather than `application/pdf`; a control package returns `application/pdf`).
- **Q1 / Q2 / Q3: NOT EVIDENCE.**
- **Level 1** as a court record of what the case was; irrelevant to the questions.

### S2b-05 · *Alpha Futures, Limited v. NinjaTrader Group, LLC et al*, No. 1:26-cv-08846 (N.D. Ill.) · PacerMonitor free docket `https://www.pacermonitor.com/public/case/65889160/...`; Docket Alarm free preview `https://www.docketalarm.com/cases/Illinois_Northern_District_Court/1--26-cv-08846/...`; CourtListener docket id 73669812 · retrieved 7 Sep 2026

**This is the one case of the five whose subject matter I could NOT establish, and I do not assert it.**

- **Type:** Federal district court docket sheet only. **No substantive document was retrievable. I state that exactly.**
- **Date / status:** Filed **24 Jul 2026**. **STILL OPEN** — `date_terminated: null`; PacerMonitor status "Active".
- **Verbatim — coded docket fields:**
  > Nature of suit: **"890 Other Statutes – Other Statutory Actions"** (Docket Alarm renders it "890 Statutory Actions - Other")
  > Cause: **"28:1332 Diversity-Tort/Non-Motor Vehicle"**
  > Demand: **$9,999,000** · Jury demand: **None** · Filing fee $405, receipt AILNDC-25433028
  > Judge John Robert Blakey; Magistrate Heather K. McShain (Settlement); Chicago Division
- **Party status — VERIFIED, and the entity mix matters.** PacerMonitor's party list (retrieved 7 Sep 2026):
  > `NinjaTrader Group, LLC` — **terminated as a party 08/06/2026**
  > `Tradovate, LLC` — **terminated as a party 08/06/2026**
  > `NinjaTrader, LLC` — remains
  > `Tradovate Technologies, LLC` — remains

  **Read those dates carefully:** 8/6/2026 are *party* terminations — two defendants dropped out — **not** a termination of the case, which remains open. PacerMonitor's summary field labels them ambiguously and it would be easy to misread the case as closed.

  **No entity with "Clearing" in its name is a defendant.** The registered FCM affiliate is not in this case; the defendants are the platform/software and Tradovate entities.
- **Docket entries visible free** (all 07/24/2026 unless noted): case assignment to Judge Blakey · Local Rule 73.1(b) clerk's notice · **Verified Complaint, DE 1, 12 pages** · Civil Cover Sheet, DE 2 · appearances for plaintiff by Sandy L. Morris (DE 3) and Jennifer E. Novoselsky (DE 4) · **DE 5, Motion for Preliminary Injunction AND Temporary Restraining Order, filed 07/25/2026** · DE 12, Order on Motion to Appear Pro Hac Vice (07/30). CourtListener reports `document_count: 9`; entries beyond these are not free-visible. **Every RECAP document shows `is_available: false`.** No ruling on the TRO/PI motion was located.
- **What can and cannot be said.** What is established is only how the clerk **coded** the case: NOS 890, jurisdiction invoked under **28 U.S.C. §1332 (diversity)**, tort/non-motor-vehicle, damages demand $9,999,000, no jury. A claim resting on the Exchange Act, the Advisers Act or the Commodity Exchange Act would ordinarily be coded **federal question** and typically NOS **850**. **That is an observation about coding, not a legal conclusion about what was pleaded**, and only the 12-page Verified Complaint can settle it. It is behind PACER.
- **Q1 / Q2 / Q3: UNKNOWN — insufficient retrieval.** Not recorded as evidence in either direction.
- **Level — not assigned;** the underlying document was not read.
- **Secondary context, marked ◇ UNVERIFIED and non-probative:** trade press (Finance Magnates, republished at `tradingview.com/news/financemagnates:dd75106fd094b:0-...`, retrieved 7 Sep 2026) reports that NinjaTrader ended its relationship with Alpha Futures around 12 July 2026 after negotiations failed over Alpha's competing "AlphaTrader" platform. **That article does not mention the lawsuit at all** — it was fetched and checked. It is recorded only because it is chronologically adjacent to the 24 July filing. **It is not evidence of what was pleaded**, and per shared-context §0 it could not be cited for any proposition even if it were.

### S2b-06 · *Monegro v. Trade Ideas LLC*, No. 1:21-cv-01518-AT (S.D.N.Y.) · FJC Integrated Database civil record; complaint ECF 1 via `https://archive.org/download/gov.uscourts.nysd.554645/…` · retrieved 7 Sep 2026

- **Type:** Federal district court record — the Administrative Office's own docket coding, plus the complaint
- **Date / status:** Filed **19 Feb 2021**; terminated **19 Apr 2021**. **59 days.** Closed.
- **Verbatim — the FJC Integrated Database record** (`https://www.fjc.gov/sites/default/files/idb/textfiles/cv88on.zip`, the AO's own civil docket dataset, downloaded and queried directly — 329,665,474-byte archive expanding to a 2,009,227,701-byte tab-delimited file):
  > `CIRCUIT 2 | DISTRICT 08 | OFFICE 1 | DOCKET 2101518 | ORIGIN 1`
  > `FILEDATE 02/19/2021 | TERMDATE 04/19/2021 | **NOS 446** | JURIS 3`
  > `TITL 42 | SECTION 1210 | **CLASSACT 1** | **DISP 13** | PROCPROG 2`
  > `PLT MONEGRO | DEF TRADE IDEAS LLC | **JUDGMENT 0**`
- **Verbatim — the codebook definitions** (`https://www.fjc.gov/sites/default/files/idb/codebooks/Civil%20Codebook%201988%20Forward%2010252023.pdf`, retrieved 7 Sep 2026):
  > **NOS 446** = "446   Americans with Disabilities Act - Other"
  > **DISP 13** = "13 – settled" (listed under the heading "Dismissals:")
  > **DISTRICT 08** = "08 - New York - Southern"
  > **CLASSACT 1** = "1 – indicates the case filed is a class action suit"

  Statutory cause coded TITL 42 / SECTION 1210 / SUBSECT 1 → **42 U.S.C. §12101** (ADA). **JUDGMENT 0** — no judgment entered. **PROCPROG 2** — terminated at "order entered", before issue joined. FILEDATE and TERMDATE match the ECF stamps on the retrieved documents exactly.
- **What it establishes:** *Monegro* is a **website-accessibility class action under Title III of the ADA and the NYCHRL**, coded as such by the court itself, settled in 59 days with **no judgment and no merits ruling**. A full-text scan of the complaint for `broker | dealer | regist | SEC | CFTC | NFA | FINRA | disclaim` returned **zero hits**. **Its only description of the defendant's business is the sentence "Defendant is a stock trading company."** Magistrate Judge Stewart D. Aaron; plaintiff's counsel Mark Rozenberg, Stein Saks PLLC.
- **The serial-filing context, on authoritative AO data rather than assertion.** Querying the same IDB dataset for first-listed plaintiff surname MONEGRO returns **160 S.D.N.Y. cases at NOS 446**, every one coded 42 U.S.C. §12101 and every one `CLASSACT = 1`, filed between **4 Aug 2020 and 15 Jul 2021** — 160 federal suits in about eleven months. All 160 terminated; **median 102 days**. Dispositions: settled 76 · voluntarily dismissed 65 · other dismissal 9 · consent judgment 5 · other judgment 4 · want of prosecution 1. **141 of 160 (88%) ended in settlement or withdrawal; not one ended in a merits ruling.** *Trade Ideas* sits in the modal bucket. This was independently corroborated by a separate RECAP-title method returning ~163.

  *(Rigour note: the IDB stores only the first-listed party's **surname**, never a first name. The defensible statement is "160 S.D.N.Y. ADA class complaints filed by a plaintiff surnamed Monegro in eleven months." The *Trade Ideas* complaint and two others were read directly and all three name **Frankie Monegro** on identical boilerplate.)*

  The same campaign's targets include a mix of finance and non-finance website operators — **Stock Rover LLC, Stash Financial Inc., Poloniex LLC, PayPal Inc., Street Insider Dot Com Inc.**, alongside a caviar seller, a popcorn company and a toy maker. *(Source: RECAP item titles, `collection:(usfederalcourts) AND title:("Monegro v.")` — docket-sourced, but titles only.)*
- **Q1 / Q2 / Q3: NOT EVIDENCE.**
- **Level 1** as a court record; irrelevant to the questions.
- **Application note:** This is the cleanest "generic-name-match" outcome of the five, and exactly the caution the brief flagged. Trade Ideas was not selected because of anything it does with securities; it was one of 160 websites swept indiscriminately in an eleven-month `alt`-text campaign. **Citing *Monegro* on regulatory status would be citing a case about image alt text.** The vendor's EULA §III and §XII status language quoted at S2-13 was never mentioned, let alone tested.

### S2b-07 · *Gurung v. MetaQuotes Ltd. et al*, No. 1:23-cv-06362-OEM-PK (E.D.N.Y.), **Memorandum and Order, ECF 60 (16 Aug 2024)** · `https://www.govinfo.gov/content/pkg/USCOURTS-nyed-1_23-cv-06362/pdf/USCOURTS-nyed-1_23-cv-06362-0.pdf` · retrieved 7 Sep 2026

**This is the only one of the five with a published merits opinion, and it is the closest any private litigant has come to attacking a trading-software vendor for what happens on its platform. It still does not touch status.**

- **Type:** Court opinion (Memorandum and Order on motions to dismiss), 22 pages, Hon. **Orelia E. Merchant**, U.S. District Judge, E.D.N.Y.
- **Date / status:** Filed **16 Aug 2024**. Complaint filed 24 Aug 2023.
- **Verbatim — caption and the defendants, p.1:**
  > "ANJITA GURUNG, Plaintiff, -against- **METAQUOTES LTD., a Cyprus corporation; METAQUOTES SOFTWARE CORP., a Bahamas corporation; METAQUOTES SOFTWARE CORP., a Delaware corporation; FOREXWARE LLC, a Delaware Limited Liability Company;** SICH CAPITAL LTD, a United Kingdom corporation; OPSON INTERNATIONAL TECHNICAL SERVICE CO., LTD., a Hong Kong corporation; VOREX TRADING LLC, a Georgia corporation; SOPHIE CAPITAL FINANCIAL TRADING LTD, a Canadian corporation; and JOHN DOE, Defendants."
- **Verbatim — the claims, p.1:**
  > "bringing claims arising under (1) the **Racketeer Influenced and Corrupt Organizations ("RICO") Act, 18 U.S.C. §§ 1962(c) and (d)**, (2) fraud, (3) conspiracy to commit fraud, (4) breach of contract and breach of implied covenant of good faith and fair dealing…"
- **Verbatim — what the case was about, pp.3–4:**
  > "Through a series of transactions spanning several months, Plaintiff transferred hundreds of thousands of dollars to the digital wallet that she believed was linked to her MT5 trading account… The MT5 interface allegedly showed each of Plaintiff's transactions and purported profit and loss values of the transactions."

  > "However, Plaintiff alleges that the Defendant Brokers were in fact '**illegitimate entities**' which had **disguised themselves as brokerages** and used the MT5 platform to manipulate Plaintiff's user account balance and display '**false profit and funds information**' to Plaintiff… By that point, Plaintiff had transferred **$596,708** to what she believed was her MT5 trading account, approximately $576,708 of which was borrowed from friends, family, and creditors. Plaintiff's funds were never returned."

  > "Plaintiff alleges that **MT5, through Forexware's software, allows illegitimate entities to manipulate user account balances, displaying false profit and funds information to victims like Plaintiff.** Plaintiff alleges that the MSC Defendants and Forexware are **aware of the criminal activity on MT5.**"
- **Verbatim — the operative holding, p.13:**
  > "The MSC Defendants contend that Plaintiff's claims are subject to a **forum selection clause in the MT5 EULA** that requires Plaintiff's claims to be litigated in the **Republic of Cyprus**." (p.4)

  > "**Because the Court finds that the forum selection clause is valid, covers all of Plaintiff's claims against the MSC Defendants, and is enforceable, Plaintiff's claims against the MSC Defendants are dismissed without prejudice for forum non conveniens.**" (p.13)
- **Verbatim — conclusion, p.22:**
  > "For the foregoing reasons, the MSC Defendants' motion to dismiss is granted and Forexware's motion to dismiss is granted. **The MSC Defendants and Forexware are hereby dismissed as parties to this action.**"

  (Forexware was dismissed separately, on RICO pleading sufficiency: "the Court finds that Plaintiff fails to plead sufficient facts to support the…", pp.16, 18.)
- **Party status — VERIFIED, and in the ordinary direction.** Anjita Gurung is **plaintiff**; the MetaQuotes entities are **defendants**. This matters because my own sweep found MetaQuotes appearing as **plaintiff** in two other federal matters (§N6), so a name-match could easily have misled. Verified from the ECF 1 complaint caption, the ECF 60 opinion caption, the ECF 71 clerk's judgment, govinfo's "Party Names" metadata and PacerMonitor's party block. **The defendants are the SOFTWARE entities — MetaQuotes Ltd. (Cyprus), MetaQuotes Software Corp. (Bahamas), MetaQuotes Software Corp. (Delaware) and Forexware LLC. No MetaQuotes broker or FCM affiliate appears in the caption**, and none exists. The four "Broker Defendants" are alleged **by the plaintiff herself** to be sham entities that were never real brokerages; none appeared, and all were voluntarily dismissed 13 Feb 2025.
- **THE STATUS QUESTION IS ABSENT — machine-counted across the full 22-page opinion text:**

  | term | occurrences |
  |---|---|
  | "broker-dealer" / "broker dealer" | **0** |
  | "investment adviser" / "advisor" | **0** |
  | "registered" | **0** |
  | "registration" | **0** |
  | "Exchange Act" | **0** |
  | "Advisers Act" | **0** |
  | "Securities and Exchange" | **0** |
  | "CFTC" | **0** |
  | "FINRA" | **0** |
  | "commodity trading advisor" | **0** |
  | "NFA" | 1 — and it is a substring artifact: *"association-in-fact"* in a RICO citation (D'Addario, 901 F.3d) |

  The same scan across the complaint and the opposition brief returned zero (parallel researcher).
- **What it establishes:** A retail user who lost $596,708 to a "pig-butchering" scam sued the **software vendor** on the theory that its platform enabled fraudsters to display false balances and that the vendor knew. **She pleaded RICO and fraud — not that MetaQuotes was an unregistered broker or adviser.** The court never reached the merits as to MetaQuotes: it enforced the **MT5 EULA's Cyprus forum-selection clause** and dismissed **without prejudice** on forum non conveniens.
- **Q1 / Q2 / Q3: NOT EVIDENCE.** No status question was pleaded, argued or decided.
- **Level 1** as a court opinion; **irrelevant to all three questions**, and in any event a private suit is not a regulator's view.
- **Application note — read narrowly, and note what it is *not*.** This is the located case whose fact pattern comes closest to the *Vartuli* / *R&W Technical Services* anxiety: harm to a retail user flowing through a trading-software vendor's product. Two observations, both narrow. **First**, the theory a real plaintiff with real losses actually chose was **RICO and fraud**, not registration — which is a data point about what private litigants plead, and nothing more. **Second**, what did the work for the vendor was **its own EULA's forum clause**, not any status statement; the vendor's terms were dispositive on *where* the case would be heard and said nothing about *what the vendor is*. Neither observation supports or undercuts the configuration on Q1 or Q2, and neither should be carried into the register as if it did. The dismissal was **without prejudice** and resolves nothing on the merits.

### S2b-08 · *Sheaf v. Ninja Trader Group, LLC*, No. 3:24-cv-01754-DMS-DDL (S.D. Cal.), Doc. 4 (27 Feb 2025) · `https://www.govinfo.gov/content/pkg/USCOURTS-casd-3_24-cv-01754/pdf/USCOURTS-casd-3_24-cv-01754-0.pdf` · retrieved 7 Sep 2026

Not one of the five. Surfaced by a govinfo sweep and included because it is **the only free, published merits opinion in existence against any NinjaTrader entity** — and therefore the best single test of whether a court has ever reached a status question about this vendor.

- **Type:** Court opinion / order (screening order under 28 U.S.C. §1915(e)(2)(B)(ii)), pro se plaintiff, 3 pages
- **Verbatim, caption and p.2:**
  > "ORDER (1) GRANTING PROCEED IN FORMA PAUPERIS AND (2) DISMISSING COMPLAINT WITHOUT PREJUDICE FOR FAILING TO STATE A CLAIM UPON WHICH RELIEF CAN BE GRANTED PURSUANT TO 28 U.S.C. § 1915(e)(2)(B)(ii)" (caption)

  > "Here, Plaintiff fails … to allege Defendant owed him any duty whatsoever, much less a duty to close his accounts upon request. Absent that allegation and any facts or law to support the existence of a duty …" (p.2 of 3)

  *(Text extracted from the PDF; the extractor dropped short spans, marked with ellipses, and introduced ligature artifacts. Quoted as extracted.)*
- **What it establishes:** A retail customer sued over a **failure to close his accounts on request**. The court dismissed on ordinary **duty-of-care** grounds and never reached any regulatory question. A keyword scan of the full extracted opinion text for `broker | dealer | adviser | advisor | registrat* | SEC | CFTC | NFA | fiduciar* | commodit*` returned **zero hits**.
- **Q1 / Q2 / Q3: NOT EVIDENCE.**
- **Application note:** This matters as a negative. The single published merits opinion involving a NinjaTrader entity — a customer-facing complaint about account handling, which is the fact pattern most likely of all to raise a status question — **is silent on status.** Add it to *Cantero*, *Suresh*, *Sanchez* and the patent line and the pattern is consistent: the private litigation these vendors attract is employment, copyright, patent, accessibility and ordinary consumer litigation.

---

## Adverse register

**Nothing in this document is adverse to the configuration, and nothing in it is supportive either.** That is the correct result, not an evasion: a private suit about overtime, copyright, alt text or a wire-fraud scam is not evidence about Q1, Q2 or Q3 in either direction. The table is filled in as the format requires, so the absence is on the record rather than left implicit.

| Authority | Threat 1–5 | Does the configuration distinguish it? |
|---|---|---|
| *Cantero v. Tradestation Technologies* (S.D. Fla. 2010) | **0 — not a threat** | Nothing to distinguish. An FLSA overtime claim against an employer. The software's regulatory character was never in issue |
| *Suresh v. Ninjatrader* (D. Colo. 2022) | **0 — not a threat** | Nothing to distinguish. Copyright infringement, 17 U.S.C. §501 |
| *Monegro v. Trade Ideas* (S.D.N.Y. 2021) | **0 — not a threat** | Nothing to distinguish. One of 160 templated ADA `alt`-text complaints; the vendor was selected for having a website |
| *Gurung v. MetaQuotes* (E.D.N.Y. 2023) | **0 — not a threat**, but the one to watch | RICO/fraud by a scam victim, dismissed on a EULA forum clause without prejudice. The *fact pattern* — retail loss flowing through a vendor's platform — is the closest located analogue to the *Vartuli* / *R&W* anxiety, but the *theory pleaded* was fraud, not registration, and nothing was decided on the merits |
| *Alpha Futures v. NinjaTrader Group* (N.D. Ill. 2026) | **UNKNOWN — cannot be scored** | **Not assessable.** The complaint was not retrieved. It is neither counted as a threat nor cleared as one |
| *Sheaf v. Ninja Trader Group* (S.D. Cal. 2025) | **0 — not a threat** | The only published merits opinion involving a NinjaTrader entity, on the fact pattern most likely to raise a status question (customer complains about account handling), and it is silent on status: 0 hits for broker/dealer/adviser/registration/SEC/CFTC/NFA |

**One correction to Track 2, recorded here because the format requires bluntness.** Track 2's statement that *Cantero* is "the only located suit naming a vendor's SOFTWARE entity" is **overstated**. There is a second — *Trading Technologies Int'l v. TradeStation Technologies Inc.*, Fed. Cir. 18-1443 — a patent appeal. Track 2's substantive point survives (*Cantero* is the only district-court suit against the software entity, and neither tests status), but the count is two, not one. Details at S2b-02.

---

## Direct answers

**Q. Did any of the five test a vendor's status or its status statement?**
**No, for the four that could be closed; the fifth is UNKNOWN and is not counted either way.** *Cantero* is unpaid overtime (NOS 710). *Suresh* is copyright (NOS 820). *Monegro* is ADA website accessibility (NOS 446). *Gurung* is civil RICO (NOS 470). *Alpha Futures* is coded NOS 890 / 28 U.S.C. §1332 diversity tort, and its complaint could not be retrieved — it is the single residual unknown. **Not one of the four closed cases pleads, argues or decides adviser status, broker-dealer status, registration, or a vendor's status statement.** Where the full text was machine-scanned — *Gurung*'s 22-page opinion, *Monegro*'s complaint, *Sheaf*'s opinion, *Crumwell*'s complaint — the counts for "broker-dealer", "investment adviser", "registered", "registration", "Exchange Act", "Advisers Act", "CFTC" and "FINRA" are **zero**.

**Q. What was *Cantero* actually?**
**An unpaid-overtime wage case.** Alejandro Cantero, "and other similarly-situated individuals", sued his employer under the Fair Labor Standards Act — nature of suit **710 Labor: Fair Standards**, cause **29:0201**. Named alongside the corporation were three TradeStation Group officers **"Individually"** — CEO Salomon Sredni, CFO David H. Fleischman and General Counsel Marc J. Stone — which is the ordinary FLSA pleading pattern reaching individuals who qualify as an "employer" under 29 U.S.C. §203(d), verified against the company's own DEF 14A of 27 Apr 2010. The case was referred to mediation, **settled**, stipulated to dismissal with prejudice on 1 Jul 2010, and dismissed by court order on 29 Jul 2010 after the court's FLSA settlement review. **There is no merits opinion, and none of the 30 docket entries has a purchasable-free document behind it.**

The corporate defendant appears as an **employer**, not as a software vendor. Nothing about what its software does was in issue. **The "not a financial services company" sentence at S2-14A was never put in issue by anyone, and remains untested.**

**Q. Which of the five turned out not to be suits against the vendor at all?**
**None — and that itself is a finding.** The brief warned that generic-name matches were likely, since CourtListener searches full text. Party status was verified from the docket in every case, and **all five are genuine suits naming the vendor as a defendant.** Track 2's identifications were sound.

But the related caution *did* bite, in a different form: ***Monegro* is a genuine suit against Trade Ideas that carries no view whatsoever about Trade Ideas.** It is one of **160** near-identical S.D.N.Y. ADA `alt`-text class complaints filed by one plaintiff in eleven months, sweeping website operators indiscriminately — a caviar seller, a popcorn company and a toy maker sit alongside Stock Rover, Stash Financial, Poloniex, PayPal and Street Insider. The vendor was selected for having a website, not for what it does.

And **two near-misses were caught**: MetaQuotes is an active **plaintiff**-side litigant in two other federal matters (both NOS 840 trademark), so a name-sweep could easily have inverted the party direction in *Gurung* — it did not, verified five ways. Likewise the RECAP sweep surfaced TradeStation entities as **plaintiff** (*TradeStation Securities v. Barclay*) and as mere **custodian of the res** in a civil forfeiture; neither is a suit against the vendor.

**Q. Whether the defendant is the software entity or a broker-dealer/FCM affiliate.**
**Strikingly, four of the five name the SOFTWARE entity, and none names the regulated affiliate.**
- *Cantero* → **Tradestation Technologies, Inc.** (the entity declared "not a financial services company"), **not** TradeStation Securities, Inc. (BD/FCM, CRD 39473).
- *Suresh* → **Ninjatrader, LLC**, sole defendant — **not** NinjaTrader Clearing, LLC, the registered FCM that was respondent in CFTC Docket No. 24-27 (S2-11).
- *Alpha Futures* → **NinjaTrader Group, LLC** and **Tradovate, LLC** (both dropped as parties 6 Aug 2026), **NinjaTrader, LLC** and **Tradovate Technologies, LLC** remaining. **No entity with "Clearing" in its name is a defendant.**
- *Monegro* → **Trade Ideas LLC** (no regulated affiliate exists).
- *Gurung* → **MetaQuotes Ltd.** (Cyprus), **MetaQuotes Software Corp.** (Bahamas and Delaware) and **Forexware LLC**. **No MetaQuotes broker or FCM affiliate exists or is named.**

**Q. Any opinion, order or memorandum reaching the merits?**
**One, and only one: *Gurung*.** ECF 60 (16 Aug 2024, Merchant J.) is a 22-page Memorandum and Order — quoted verbatim at S2b-07 — and it does **not** reach the merits as to MetaQuotes either: it enforces the **MT5 EULA's Cyprus forum-selection clause** and dismisses **without prejudice** on *forum non conveniens*. Forexware was dismissed on RICO pleading sufficiency.
- *Cantero*: no merits opinion; govinfo COUNT 0 with a working control.
- *Suresh*: none possible — a self-effectuating Rule 41(a)(1)(A)(i) notice; govinfo package does not exist.
- *Monegro*: **`JUDGMENT 0`** in the AO's own data — no judgment, no merits ruling, settled in 59 days.
- *Alpha Futures*: a TRO/preliminary-injunction motion at DE 5 with **no located ruling**; case still open.

**Q. Where only a docket sheet was available with no substantive document.**
**Stated exactly, as required: *Alpha Futures, Limited v. NinjaTrader Group, LLC et al*, N.D. Ill. 1:26-cv-08846, is a case for which the only thing available to me was a docket sheet with no substantive document.** Every RECAP entry shows `is_available: false`; the Internet Archive has no item; `storage.courtlistener.com` returns HTTP 404 for DE 1, 2, 5 and 12; and govinfo has no opinion package. The same is true of *Cantero* and *Suresh*, though in those two the docket's own coding and entry text answer the question completely, so nothing turns on it.

**Q. Any state-court matter among the five?**
**No. All five are federal**, in five different district courts (S.D. Fla., D. Colo., N.D. Ill., S.D.N.Y., E.D.N.Y.), confirmed by docket number format, PACER case id and — for four of the five — the Administrative Office's own federal civil database. The question of free versus paid state-court routes therefore does not arise. *(Had it arisen: free routes are the court's own public portal and Trellis/UniCourt free previews; paid routes are the state e-filing vendor's per-document fee, which varies by state and is not governed by the PACER schedule.)*

---

## Negative findings

Each with the endpoint, the exact query and the count. Absence documented, never inferred. **Every count below is a count in an incomplete corpus** — see Standing Caveat 2.

**§N1 · No free federal opinion exists in *Cantero*.**
Endpoint: `https://www.govinfo.gov/wssearch/search` (POST, JSON), the govinfo site's own search API, collection `USCOURTS` (United States Courts Opinions).
- Query `collection:USCOURTS AND "Cantero" AND "TradeStation"` → **iTotalCount = 0**
- Query `packageid:USCOURTS-flsd-0_10-cv-60271` → **iTotalCount = 0**
- Direct package probes `USCOURTS-flsd-0_10-cv-60271` and `USCOURTS-flsd-1_10-cv-60271`: `/app/details/` returns HTTP 200 but is a client-rendered SPA shell carrying no package data; `/content/pkg/<id>/mods.xml` 302-redirects and resolves to a 44,165-byte **HTML error page**, not MODS XML — i.e. **no such package exists**.
- **Control, same endpoint, same session:** `collection:USCOURTS AND "Trading Technologies"` → **iTotalCount = 375**, returning real packages (`USCOURTS-ilnd-1_04-cv-05312`, `USCOURTS-ilnd-1_10-cv-00715`, `USCOURTS-ilnd-1_05-cv-04811`, …). **The endpoint works; the zero is a real zero, not an access failure.**
- This is consistent with the docket itself, which contains no merits opinion.

**§N2 · The free federal-opinions corpus contains no opinion about TradeStation's software entity on any status question.**
Endpoint as §N1. Query `collection:USCOURTS AND "TradeStation Technologies"` → **iTotalCount = 8**. All 8 are patent:
- Seven are the *Trading Technologies* / *IBG* Federal Circuit line: `USCOURTS-ca13-18-01443` (×2), `USCOURTS-ca13-17-02323`, `USCOURTS-ca13-17-02054`, `USCOURTS-ca13-17-02053`, `USCOURTS-ca13-17-02257`, `USCOURTS-ca13-17-02052`.
- The eighth is `USCOURTS-txed-6_15-cv-01136`, *Chart Trading Development, LLC v. TradeStation Group, Inc. et al*, opinion issued **29 Mar 2016**. I retrieved and read it rather than inferring from the caption. Its first page reads:
  > "IN THE UNITED STATES DISTRICT COURT FOR THE EASTERN DISTRICT OF TEXAS TYLER DIVISION · CHART TRADING DEVELOPMENT, LLC. v. TRADESTATION GROUP, INC., et al · CASE NO. 6:15-cv-1136-JDL (lead case) · **MEMORANDUM OPINION AND ORDER** · Before the Court is Defendants' Motion to Stay or Alternatively Dismiss Proceedings **Pending Covered Business Method Patent Review**." (Doc. No. 109, filed 03/29/16, p.1)
  Retrieved from `https://www.govinfo.gov/content/pkg/USCOURTS-txed-6_15-cv-01136/pdf/USCOURTS-txed-6_15-cv-01136-0.pdf`, 7 Sep 2026.
- **Finding:** across the whole free federal-opinions collection, **no opinion mentioning "TradeStation Technologies" concerns adviser status, broker status, registration or a status statement.** All 8 concern patents.

**§N3 · CourtListener's API and web frontend were both unavailable to me for this task; nothing in this document rests on them.**
- API, first call of this task: `https://www.courtlistener.com/api/rest/v4/search/?q="Cantero" "Tradestation"&type=r` → **HTTP 429**, body verbatim: `{"detail":"Request was throttled. Rate limit exceeded: 125/day. Expected available in 70699 seconds."}` — a **daily** cap of 125, resetting in ~19.6 hours. This is a *second, harder* wall than the 50/hour limit Track 2 documented at its §N6, and Track 2's own 56-query paced sweep had already consumed much of the day's quota.
- **Important qualification, and it changes how the wall should be understood.** A parallel researcher on this same commission found the API **responding normally** on its first calls — returning 39 dockets and 183 documents for `q=NinjaTrader&type=r`, and full structured docket fields for both NinjaTrader cases — before hitting the identical `125/day` message partway through. **The quota is shared across everything running from this IP and is consumed in-session.** So the wall is not "CourtListener is down"; it is "the day's budget is finite and was spent". The structured docket fields underlying S2b-04 and S2b-05 came from that pre-exhaustion window and are CourtListener-sourced.
- The authenticated endpoints are separately gated regardless of quota: `/api/rest/v4/dockets/?court=cod&docket_number=1:22-cv-02903` → `{"detail":"Authentication credentials were not provided."}`. A free API token would unlock them; **no account was created**, per the brief.
- Web frontend, browser User-Agent: `https://www.courtlistener.com/?q=Cantero%20Tradestation&type=r` → **HTTP 202 with a zero-byte body** (bot challenge).
- Web frontend via the fetch tool → **HTTP 403**.
- **Consequence, and it is a favourable one:** I did not need CourtListener. The Free Law Project mirrors RECAP dockets onto the Internet Archive, which is **not walled** and **not rate-limited**, and serves the identical `docket.json` payload. That route is documented at §N5 and is the reason this document exists. **The CourtListener COUNT-0 caveat that Track 3 established still governs**: its opinion index does not contain *SEC v. Coinbase* or *Risley* and contains no SEC or CFTC administrative decisions at all.

**§N4 · Justia dockets were unreachable.**
- `https://dockets.justia.com/search?query=TradeStation+Technologies&cases=mostrecent` → **HTTP 403**, 5,902-byte Cloudflare interstitial containing `__cf_chl_tk` / `__cf_chl_f_tk` challenge tokens.
- `https://dockets.justia.com/search?query=Cantero+TradeStation` → **HTTP 403**, same challenge.
- Same URLs via the fetch tool → **HTTP 403**.
- Nothing in this document rests on Justia. Recorded so the wall is on record for the next researcher.

**§N5 · The route that worked, documented so it can be reused.**
The Free Law Project uploads RECAP dockets to the Internet Archive as items named `gov.uscourts.<court>.<pacer_case_id>`. archive.org is open, unauthenticated and not rate-limited. Three steps:
1. `https://archive.org/advancedsearch.php?q=<query>&fl[]=identifier&fl[]=title&rows=100&output=json` — full-text and title search across all mirrored dockets.
2. `https://archive.org/metadata/<identifier>` — file list; `metadata.source_url` gives the canonical CourtListener docket URL and id.
3. `https://archive.org/download/<identifier>/<identifier>.docket.json` — **note it 302-redirects; `curl -L` is required.** Yields parties (with `party_types[].extra_info` and counsel), every docket entry's full text, `cause`, `nature_of_suit`, `jurisdiction_type`, `jury_demand`, `date_filed`, `date_terminated`, assigned judge, and the FJC `idb_data` record.
Each item's `recap_documents[].is_available` says whether a PDF was ever purchased into the archive. **Where a PDF is present it is genuinely free** — that is how the *Sanchez* complaint at S2b-03 was read.
**Limits, stated plainly:** the mirror is refreshed quarterly and covers only what someone has fetched into RECAP. A case absent from it is **not located**, not **non-existent**.

**§N6 · A vendor-wide RECAP party-name sweep, closing gaps Track 2 had to leave THROTTLED.**
Because the Internet Archive mirror is unwalled and unmetered where CourtListener is not, I ran the party-name sweep Track 2 could not finish. Endpoint `https://archive.org/advancedsearch.php`, query form `q=identifier:gov.uscourts.* AND title:(<name>)`, `rows=60`, retrieved 7 Sep 2026. Restricting to `identifier:gov.uscourts.*` excludes the many unrelated user uploads (EasyLanguage manuals, indicator packs) that made Track 2's raw counts noisy.

| Vendor name queried | numFound | Items |
|---|---|---|
| `NinjaTrader` | **0** | — (both NinjaTrader cases are real; see §N7 on why this zero is a mirror gap, not a case gap) |
| `"Trade Ideas"` | **1** | `gov.uscourts.nysd.554645` *Monegro v. Trade Ideas LLC* |
| `MetaQuotes` | **3** | `gov.uscourts.nyed.502112` *Gurung v. MetaQuotes Ltd.*; `gov.uscourts.cacd.847721` *MetaQuotes Ltd. v. MetaQuotes Software Corp.*; `gov.uscourts.vaed.569952` *MetaQuotes Ltd. v. BESTAMBERMT5.COM* — **in the latter two MetaQuotes is the PLAINTIFF** (name/domain disputes), not a defendant |
| `MetaTrader` | **0** | — |
| `QuantConnect` | **0** | — corroborates Track 2's CourtListener o=0, r=0 on a second, independent index |
| `"Composer Technologies"` | **0** | — corroborates Track 2's o=0, r=0 |
| `TradingView` | **3** | `gov.uscourts.azd.1322547` *DeMark Analytics LLC v. TradingView Incorporated*; `gov.uscourts.nysd.601893` *Crumwell v. Tradingview, Inc.*; `gov.uscourts.ohsd.292799` *Trading Central Canada Inc. v. TradingView, Inc.* — **this closes Track 2's THROTTLED `"TradingView"`/r query** |
| `MultiCharts` | **0** | — |
| `Hummingbot` | **0** | — |
| `Collective2` | **0** | — |
| `AmiBroker` | **0** | — |
| `Tickeron` | **0** | — |

**What the sweep adds.** No previously unknown suit against any of these vendors on a status question was found.

**The three TradingView matters, characterised from primary documents rather than left as name-matches.** Track 2's `"TradingView"`/r query was THROTTLED, so these had never been characterised. All three carry free PDFs in the archive, which I retrieved and read:

- ***Crumwell v. TradingView, Inc.***, No. **1:23-cv-05918-KPF** (S.D.N.Y., filed 10 Jul 2023), Complaint DE 1, 27 pp. Caption: > "DENISE CRUMWELL, ON BEHALF OF HERSELF AND ALL OTHER PERSONS SIMILARLY SITUATED, Plaintiffs, v. TRADINGVIEW, INC., Defendant. … **CLASS ACTION COMPLAINT** · JURY TRIAL DEMANDED" (p.1). ¶5: > "is a violation of Plaintiff's rights under the **Americans with Disabilities Act ("ADA")**." A full-text scan of the complaint returns: "Americans with Disabilities" ×5, "42 U.S.C" ×18, "NYCHRL" ×8, "blind" ×48 — and **"broker" 0, "dealer" 0, "adviser" 0, "advisor" 0, "FINRA" 0.** (The 4 apparent "SEC" hits are substring artifacts of "Sect." and "Section 302(b)"; there is no securities content.) **A website-accessibility class action — the same pattern as *Sanchez* at S2b-03.**
- ***DeMark Analytics, LLC v. TradingView, Inc.***, No. **2:23-cv-00132-DJH** (D. Ariz., filed 30 Jan 2023), DE 14 = **Form AO 120**, "REPORT ON THE FILING OR DETERMINATION OF AN ACTION REGARDING A PATENT OR TRADEMARK", filed under 35 U.S.C. §290 and/or 15 U.S.C. §1116. **An intellectual-property action.** *(Which of the two boxes — patent or trademark — is checked does not survive text extraction from the scanned form, so I do not state which; the AO 120 is filed only for patent or trademark actions, and that much is on the face of the document.)*
- ***Trading Central Canada, Inc. v. TradingView, Inc.***, No. **2:24-cv-02535-ALM-CMV** (S.D. Ohio, Eastern Div., Judge Algenon L. Marbley), DE 33, Order of 26 Feb 2025: > "This matter comes before this Court on Defendant TradingView, Inc.'s **motion to dismiss for failure to state a claim** (ECF No. 17). On January 15, 2025, the parties notified this Court that they have reached a **settlement in principle**. (ECF No. 29). In light of the settlement notice … this Court **denies the pending motion to dismiss (ECF No. 17) as moot**, without prejudice to renewal…" (p.1 of 1). **A commercial dispute between two firms, settled; the motion to dismiss was never decided on the merits.**

**None of the three touches adviser status, broker-dealer status, registration or a status statement.** TradingView is the vendor Track 2 identified as performing *Neovest*-style broker customer-acquisition at scale (S2-08); the litigation it has actually attracted is accessibility, IP and commercial.

**§N7 · The RECAP mirror's coverage gap, measured rather than assumed.**
Both NinjaTrader cases are independently confirmed to exist (PacerMonitor, Docket Alarm and CourtListener's structured fields all return them), yet:
- `q=identifier:gov.uscourts.* AND NinjaTrader` → **0**
- `q=title:(Suresh AND Ninjatrader)` → **0**
- `q=title:(Alpha Futures AND NinjaTrader)` → **0**
- `https://archive.org/metadata/gov.uscourts.ilnd.504834` → **`{}`** (no item)
- `https://archive.org/metadata/gov.uscourts.cod.213906` → **`{}`** (no item)

**This is a demonstrated false negative in the Internet Archive RECAP mirror**, and it is the reason Standing Caveat 2 is written as it is. The mirror is quarterly and covers only dockets someone has already pulled into RECAP. **An absence there is "not located", never "does not exist"** — and I now have a measured instance proving it, not merely a theoretical caution. Every zero in §N6 must be read through this.

**§N8 · No free copy of the *Alpha Futures* complaint exists anywhere.**
Direct probes of the CourtListener RECAP document store, `https://storage.courtlistener.com/recap/gov.uscourts.ilnd.504834/gov.uscourts.ilnd.504834.<n>.pdf` for n = 1.0, 2.0, 5.0, 12.0 → **HTTP 404** on all four (`content_type: application/xml`, 334–354 bytes). Combined with `is_available: false` on every RECAP entry, the absent Internet Archive item, and the absent govinfo package, this is a closed question: **DE 1 is obtainable only from PACER.**

**§N9 · The authoritative free route, found late and worth carrying forward: the FJC Integrated Database.**
The Administrative Office of the U.S. Courts publishes its **complete civil docket dataset** free and unwalled. It is the source from which nature-of-suit codes, disposition codes and termination dates ultimately derive, and it is not a mirror, an aggregator or a scrape.
- Data: `https://www.fjc.gov/sites/default/files/idb/textfiles/cv88on.zip` — **329,665,474 bytes**, HTTP 200, expanding to `cv88on.txt`, **2,009,227,701 bytes**, tab-delimited, 46 columns with a header row, covering 1988 to date.
- Codebook: `https://www.fjc.gov/sites/default/files/idb/codebooks/Civil%20Codebook%201988%20Forward%2010252023.pdf`

**Why it matters here.** It closed the last open coding question (*Monegro*'s NOS) with the court's own data rather than an aggregator's rendering, and it independently confirmed *Gurung* a third time (`NOS 470`, `TITL 18 / SECTION 1962`, `FILEDATE 08/24/2023`, `TERMDATE 02/18/2025`, `DISP 6` = "6 – motion before trial", matching the granted motions to dismiss). It also supplied the codebook that let me decode *Cantero*'s `DISP 13` at S2b-01.

**It also settled the party-direction risk on MetaQuotes definitively.** Scanning the entire IDB, 1988–2026, for METAQUOTES returns exactly **three** cases:

| District | Docket | NOS | Plaintiff | Defendant |
|---|---|---|---|---|
| 73 | 2200462 | **840 Trademark** | METAQUOTES LTD., ET AL | METAQUOTES SOFTWARE COR, ET AL |
| **07 (E.D.N.Y.)** | **2306362** | **470 Civil RICO** | **GURUNG** | **METAQUOTES LTD., ET AL** |
| 22 | 2500426 | **840 Trademark** | METAQUOTES LTD. | BESTAMBERMT5.COM, ET AL |

The two non-*Gurung* matters are **trademark enforcement suits MetaQuotes brought as plaintiff** — not confusable with *Gurung*, in which it is squarely the defendant.

**Limitation, stated plainly:** the IDB stores only the **first-listed party's surname**, never a first name, and no case caption. It answers *how the court coded the case*; it does not tell you what was pleaded. It is a complement to the docket text, not a substitute.

**Recommendation for the register:** this endpoint should be the first stop for any future nature-of-suit or disposition question, ahead of CourtListener, Justia, PacerMonitor and Docket Alarm — all four of which are either walled, metered or second-hand.

---

## Search log

| # | Source / query | Endpoint | Date | Result / access note |
|---|---|---|---|---|
| 1 | CourtListener v4 search, `q="Cantero" "Tradestation"&type=r` | `courtlistener.com/api/rest/v4/search/` | 7 Sep 2026 | **HTTP 429** — `{"detail":"Request was throttled. Rate limit exceeded: 125/day. Expected available in 70699 seconds."}`. Daily cap, ~19.6 h to reset |
| 2 | CourtListener HTML frontend, browser UA, `?q=Cantero Tradestation&type=r` | `courtlistener.com/` | 7 Sep 2026 | **HTTP 202, 0 bytes** — bot challenge |
| 3 | CourtListener HTML frontend via fetch tool | ibid. | 7 Sep 2026 | **HTTP 403** |
| 4 | Justia dockets search, `query=TradeStation+Technologies` | `dockets.justia.com/search` | 7 Sep 2026 | **HTTP 403**, 5,902-byte Cloudflare `__cf_chl_tk` interstitial |
| 5 | Justia dockets search, `query=Cantero+TradeStation` | ibid. | 7 Sep 2026 | **HTTP 403**, same |
| 6 | Justia dockets via fetch tool, `court=flsdce` | ibid. | 7 Sep 2026 | **HTTP 403** |
| 7 | Web search, `"Cantero" "TradeStation Technologies" lawsuit Southern District Florida 2010` | web search | 7 Sep 2026 | No direct hit on the case; surfaced only unrelated TradeStation litigation |
| 8 | **Internet Archive advanced search**, `q=identifier:gov.uscourts.flsd.* AND Cantero` | `archive.org/advancedsearch.php` | 7 Sep 2026 | **HTTP 200, numFound=10** — located `gov.uscourts.flsd.352447` "Cantero v. Tradestation Technologies, Inc." |
| 9 | Internet Archive advanced search, `q=title:(Cantero AND Tradestation)` | ibid. | 7 Sep 2026 | **HTTP 200, numFound=1** — same item; confirms uniqueness |
| 10 | IA item metadata, `gov.uscourts.flsd.352447` | `archive.org/metadata/…` | 7 Sep 2026 | HTTP 200, 2,698 bytes. `source_url` = CourtListener docket 8247431; file `…docket.json` 57,707 bytes present; **no PDFs in item** |
| 11 | RECAP docket JSON, no `-L` | `archive.org/download/…/….docket.json` | 7 Sep 2026 | **HTTP 302** — redirect not followed; must use `curl -L` |
| 12 | RECAP docket JSON, `-L` | ibid. | 7 Sep 2026 | **HTTP 200, 57,707 bytes.** Parsed: 30 docket entries, 5 parties, full `idb_data`. **This is the source for S2b-01** |
| 13 | Parse: all 30 entries' `recap_documents[].is_available` | ibid. | 7 Sep 2026 | **All `false`** — no PDF ever purchased into RECAP for this case |
| 14 | govinfo browse probe, flsd | `govinfo.gov/wssearch/rb/uscourts/flsd/` | 7 Sep 2026 | HTTP 200, 2,863 bytes (navigation payload only) |
| 15 | govinfo package probe ×2, `USCOURTS-flsd-0_10-cv-60271`, `USCOURTS-flsd-1_10-cv-60271` | `govinfo.gov/app/details/…` and `/content/pkg/…/mods.xml` | 7 Sep 2026 | `/app/details` HTTP 200 = SPA shell, no data. `mods.xml` 302 → **44,165-byte HTML error page**. **No such package** |
| 16 | govinfo search API, `collection:USCOURTS AND "Cantero" AND "TradeStation"` | `govinfo.gov/wssearch/search` (POST) | 7 Sep 2026 | **iTotalCount = 0** |
| 17 | govinfo search API, `packageid:USCOURTS-flsd-0_10-cv-60271` | ibid. | 7 Sep 2026 | **iTotalCount = 0** |
| 18 | govinfo search API, `collection:USCOURTS AND "TradeStation Technologies"` | ibid. | 7 Sep 2026 | **iTotalCount = 8** — all patent; enumerated at §N2 |
| 19 | **govinfo CONTROL**, `collection:USCOURTS AND "Trading Technologies"` | ibid. | 7 Sep 2026 | **iTotalCount = 375** with real packages — **proves the endpoint works and #16/#17 are true zeros** |
| 20 | govinfo opinion PDF, *Chart Trading Development v. TradeStation Group* | `govinfo.gov/content/pkg/USCOURTS-txed-6_15-cv-01136/pdf/…-0.pdf` | 7 Sep 2026 | HTTP 200, 286,928 bytes. Read: CBM patent-review stay motion. **Not status** |
| 21 | IA advanced search, `q=title:("Tradestation Technologies")` | `archive.org/advancedsearch.php` | 7 Sep 2026 | **numFound = 2** — *Cantero* and Fed. Cir. 18-1443 |
| 22 | IA advanced search, `q=title:(Tradestation)` | ibid. | 7 Sep 2026 | **numFound = 19** — 8 court items, 11 unrelated uploads; enumerated at S2b-02 |
| 23 | RECAP docket JSON, `gov.uscourts.cafc.18-1443` | `archive.org/download/…` | 7 Sep 2026 | HTTP 200, 39,358 bytes. Fed. Cir. patent appeal; `nature_of_suit` empty (appellate dockets carry none) |
| 24 | IA item metadata, `gov.uscourts.nysd.560974` (*Sanchez*) | `archive.org/metadata/…` | 7 Sep 2026 | HTTP 200. **No `docket.json`**; three free PDFs present (DE 1, 5, 10) |
| 25 | *Sanchez* complaint DE 1 | `archive.org/download/gov.uscourts.nysd.560974/gov.uscourts.nysd.560974.1.0.pdf` | 7 Sep 2026 | HTTP 200, 167,601 bytes. Read: **ADA Title III website-accessibility class action** |
| 26 | EDGAR full-text search, `"Salomon Sredni"` | `efts.sec.gov/LATEST/search-index` | 7 Sep 2026 | 992 hits, top hit TRADESTATION GROUP INC (CIK 0001111559) |
| 27 | EDGAR full-text search, `"Marc J. Stone" "TradeStation"` | ibid. | 7 Sep 2026 | 147 hits, same CIK |
| 28 | EDGAR full-text search, `"David H. Fleischman"` | ibid. | 7 Sep 2026 | 265 hits, same CIK |
| 29 | EDGAR FTS, `"Salomon Sredni" "Marc J. Stone"`, forms `DEF 14A`, 2010 | ibid. | 7 Sep 2026 | 1 hit: `0001193125-10-094305:ddef14a.htm`, filed 2010-04-27 |
| 30 | TradeStation Group DEF 14A, officer table | `sec.gov/Archives/edgar/data/1111559/000119312510094305/ddef14a.htm` | 7 Sep 2026 | HTTP 200, 500,784 bytes. Confirms all three individual *Cantero* defendants were TradeStation Group officers |
| 31 | PACER published fee schedule | `pacer.uscourts.gov/pacer-pricing-how-fees-work` | 7 Sep 2026 | "$0.10 per page"; "You won't be charged more than $3 per document"; no cap on transcripts or non-case-specific reports; "Spend $30 or less on court records in a quarter and fees are WAIVED" |
| 32 | **Vendor-wide RECAP party sweep, 12 names**, `q=identifier:gov.uscourts.* AND title:(<name>)` | `archive.org/advancedsearch.php` | 7 Sep 2026 | Full counts at §N6. NinjaTrader 0 · "Trade Ideas" 1 · MetaQuotes 3 · MetaTrader 0 · QuantConnect 0 · "Composer Technologies" 0 · TradingView 3 · MultiCharts 0 · Hummingbot 0 · Collective2 0 · AmiBroker 0 · Tickeron 0 |
| 33 | RECAP document store probe, *Alpha Futures* DE 1, 2, 5, 12 | `storage.courtlistener.com/recap/gov.uscourts.ilnd.504834/…` | 7 Sep 2026 | **HTTP 404 on all four** (`application/xml`, 334–354 B). No free PDF exists |
| 34 | IA item probe, `gov.uscourts.ilnd.504834` and `gov.uscourts.cod.213906` | `archive.org/metadata/…` | 7 Sep 2026 | **`{}` both** — no items. Demonstrated mirror false negative; see §N7 |

### Search log — parallel researcher, NinjaTrader cases (S2b-04, S2b-05, S2b-06)

Run concurrently and merged here. Endpoints and results as reported.

| # | Query / source | Endpoint or URL | Result / access note |
|---|---|---|---|
| N1 | PacerMonitor free docket, *Suresh* | `pacermonitor.com/public/case/46743300/Suresh_v_Ninjatrader,_LLC` | **SUCCESS.** NOS 820, cause 17:501, filed 11/07/22, terminated 01/17/23, Judge Wang, full free docket listing |
| N2 | PacerMonitor free docket, *Alpha Futures* | `pacermonitor.com/public/case/65889160/Alpha_Futures,_Limited_v_NinjaTrader_Group,_LLC_et_al` | **SUCCESS.** 1:26-cv-08846, NOS 890, cause 28:1332, 4 defendants (2 terminated 8/6/26), first 6 entries |
| N3 | Docket Alarm free preview, *Suresh* | `docketalarm.com/cases/Colorado_District_Court/1--22-cv-02903/…` | **SUCCESS.** NOS 820, cause 17:501, Denver Div., jury demand Plaintiff, terminated 01/17/2023. Entry text behind login |
| N4 | Docket Alarm free preview, *Alpha Futures* | `docketalarm.com/cases/Illinois_Northern_District_Court/1--26-cv-08846/…` | **SUCCESS.** NOS 890, cause 28:1332, demand **$9,999,000**, jury demand **None**, Mag. McShain (Settlement). Entry text behind login |
| N5 | CourtListener v4 search, `q=NinjaTrader&type=r` | `courtlistener.com/api/rest/v4/search/` | **WORKING on first attempt** — 39 dockets, 183 documents. Quota not yet exhausted at that moment |
| N6 | CourtListener v4 search, `q=docketNumber:"1:26-cv-08846"&type=r&court=ilnd` | ibid. | **SUCCESS.** docket_id 73669812, pacer_case_id 504834, DE 1/5/12, all `is_available:false` |
| N7 | CourtListener v4 search, `q=NinjaTrader&type=r&court=cod` | ibid. | **SUCCESS.** *Suresh*: NOS `820 Copyright`, cause `17:501`, Federal Question, jury Plaintiff, structured `party` array |
| N8 | CourtListener v4 `type=rd` entry enumeration | ibid. | **THROTTLED.** `Rate limit exceeded: 125/day. Expected available in 70553 seconds` |
| N9 | CourtListener `/api/rest/v4/dockets/?court=cod&docket_number=1:22-cv-02903` | ibid. | `{"detail":"Authentication credentials were not provided."}` — token required |
| N10 | CourtListener docket HTML ×2 | `/docket/65745439/…`, `/docket/73669812/…` | **HTTP 403** both |
| N11 | Justia docket search ×2 (fetch tool and curl + browser UA) | `dockets.justia.com/search?query=NinjaTrader` | **HTTP 403** both — Cloudflare |
| N12 | **govinfo search API**, `NinjaTrader AND collection:USCOURTS` | `govinfo.gov/wssearch/search` (POST) | **SUCCESS, no key needed. 14 USCOURTS opinions mention NinjaTrader**; only *Sheaf* is a merits ruling against a NinjaTrader entity |
| N13 | govinfo, `"Alpha Futures" AND collection:USCOURTS` | ibid. | 2 hits, both *Loginovskaya v. Batratchenko* (unrelated). **No opinion in this case** |
| N14 | govinfo, `"Suresh" AND "Ninjatrader"` | ibid. | **0 hits** |
| N15 | govinfo, `packageid:USCOURTS-ilnd-1_26-cv-08846` and `…cod-1_22-cv-02903` | ibid. | **0 hits each** |
| N16 | govinfo PDF existence probe, both cases, suffixes -0/-1/-2 | `/content/pkg/<pkg>/pdf/<pkg>-N.pdf` | HTTP 200 but `content_type=text/html`, 44,165 B error page → **no package exists**. **Control** `casd-3_24-cv-01754-0` returned `application/pdf`, 239,287 B |
| N17 | *Sheaf* opinion download + full-text keyword scan | `govinfo.gov/content/pkg/USCOURTS-casd-3_24-cv-01754/pdf/…-0.pdf` | **SUCCESS.** Scan for `broker\|dealer\|adviser\|advisor\|registrat*\|SEC\|CFTC\|NFA\|fiduciar*\|commodit*` → **0 hits** |
| N18 | IA RECAP probes ×4 + 1 metadata | `archive.org/advancedsearch.php`, `archive.org/metadata/gov.uscourts.ilnd.504834` | **0 hits / empty `{}`.** Mirror false negative; see §N7 |
| N19 | Finance Magnates article via TradingView | `tradingview.com/news/financemagnates:dd75106fd094b:0-…` | Fetched; **confirms the article does not mention the lawsuit**. Secondary, non-probative |
| N20 | PlainSite · UniCourt · Docketbird · Law360 | respective search URLs | CAPTCHA wall · HTTP 405 · HTTP 403 · HTTP 404 |
| N21 | DuckDuckGo HTML, DuckDuckGo Lite, Mojeek, search.marcia.cc | respective endpoints | HTTP 202 bot wall ×2 · CAPTCHA · connection failed |

### Search log — parallel researcher, *Monegro* and *Gurung* (S2b-06, S2b-07)

| # | Query / source | Endpoint or URL | Result / access note |
|---|---|---|---|
| M1 | IA RECAP item, *Monegro v. Trade Ideas LLC* | `archive.org/metadata/gov.uscourts.nysd.554645` and `/download/…` | **SUCCESS.** Complaint ECF 1 and ECF 7 retrieved as free PDFs |
| M2 | IA RECAP item, *Gurung v. MetaQuotes Ltd.* | `archive.org/metadata/gov.uscourts.nyed.502112` and `/download/…` | **SUCCESS.** Complaint ECF 1 retrieved; caption verified verbatim |
| M3 | Full-text scan of *Monegro* complaint for `broker\|dealer\|regist\|SEC\|CFTC\|NFA\|FINRA\|disclaim` | local | **0 hits.** Only business description: "Defendant is a stock trading company" |
| M4 | Full-text scan of *Gurung* complaint and 4,195-line opposition filing, same terms | local | **0 hits** |
| M5 | **govinfo opinion**, *Gurung* Memorandum & Order ECF 60 | `govinfo.gov/content/pkg/USCOURTS-nyed-1_23-cv-06362/pdf/…-0.pdf` | **SUCCESS**, `application/pdf`, 383,912 B, 22 pp. Independently retrieved and quoted at S2b-07 |
| M6 | govinfo, *Monegro* / Trade Ideas opinions | `govinfo.gov/wssearch/search` (POST) | **iTotalCount = 0** — no opinion; consistent with `JUDGMENT 0` in the AO data |
| M7 | govinfo `getContentDetail`, Party Names field, *Gurung* | `govinfo.gov/wssearch/getContentDetail?packageId=USCOURTS-nyed-1_23-cv-06362` | Lists "Anjita Gurung, Plaintiff" and each MetaQuotes entity as "Defendant" |
| M8 | *Gurung* clerk's judgment ECF 71 | RECAP | Caption confirms party direction a third time |
| M9 | **FJC Integrated Database — full civil dataset download** | `fjc.gov/sites/default/files/idb/textfiles/cv88on.zip` | **SUCCESS**, HTTP 200, **329,665,474 B** → `cv88on.txt` **2,009,227,701 B**, 46 tab-delimited columns |
| M10 | FJC IDB codebook | `fjc.gov/sites/default/files/idb/codebooks/Civil%20Codebook%201988%20Forward%2010252023.pdf` | **SUCCESS.** NOS 446, NOS 840, DISP 13, DISP 6, CLASSACT 1, DISTRICT 08 definitions quoted verbatim |
| M11 | IDB query — *Monegro v. Trade Ideas* record | local | **NOS 446, DISP 13 (settled), CLASSACT 1, JUDGMENT 0**, TITL 42 / SECTION 1210; dates match ECF stamps exactly |
| M12 | IDB query — plaintiff surname MONEGRO, S.D.N.Y. | local | **160 cases at NOS 446**, 4 Aug 2020 – 15 Jul 2021, all CLASSACT 1, median 102 days, 141/160 settled or withdrawn, **0 merits rulings** |
| M13 | IDB query — METAQUOTES, all districts, 1988–2026 | local | **Exactly 3 cases.** *Gurung* = NOS 470, MetaQuotes as **defendant**; the other two = NOS 840 Trademark, MetaQuotes as **plaintiff** |
| M14 | IDB query — *Gurung* record | local | `NOS 470`, `TITL 18 / SECTION 1962`, `FILEDATE 08/24/2023`, `TERMDATE 02/18/2025`, `DISP 6` = "motion before trial" |
| M15 | RECAP title sweep, `collection:(usfederalcourts) AND title:("Monegro v.")` | `archive.org/advancedsearch.php` | numFound 198; 163 matching `^Monegro v.`, 160 in nysd — independently corroborates M12 by a different method |
| M16 | 2d Cir. appeal No. 25-328 in *Gurung* | CA2 RECAP; govinfo | **No CA2 item; govinfo `iTotalCount: 1` (district only). UNVERIFIED** — ◇2 |

---

## ◇ list — resting on secondary confirmation only

Everything load-bearing in this document rests on a primary source: a docket sheet, a filed pleading, a court opinion, an SEC filing, or the Administrative Office's own dataset. The items below are the exceptions, and **none of them is relied on for any finding.**

| ◇ | Item | What it rests on | Why it does not matter |
|---|---|---|---|
| ◇1 | **The commercial backdrop to *Alpha Futures*** — that NinjaTrader ended its relationship with Alpha Futures around 12 Jul 2026 over Alpha's competing "AlphaTrader" platform | A single Finance Magnates trade-press article, republished at `tradingview.com/news/financemagnates:dd75106fd094b:0-…`. **The article does not mention the lawsuit at all** — this was checked, not assumed | Recorded only as chronology adjacent to the 24 Jul filing. Per shared-context §0 it could not be cited for any proposition. **It is not evidence of what was pleaded**, and the *Alpha Futures* entry is marked UNKNOWN regardless |
| ◇2 | **The 2d Cir. appeal in *Gurung*, No. 25-328** | Referenced but not verified: no CA2 RECAP item, and govinfo returns `iTotalCount: 1` (the district opinion only) | The district disposition (S2b-07) is fully sourced from the opinion PDF. Whether an appeal is pending does not change what was pleaded or decided below, and a dismissal without prejudice on forum grounds would not become a status ruling on appeal |
| ◇3 | **"Frankie" as the first name across all 160 Monegro suits** | The IDB stores surnames only. Three complaints were read directly and all three name Frankie Monegro on identical boilerplate; the remaining 157 are inferred from the pattern | The rigorous claim — "160 S.D.N.Y. ADA class complaints filed by a plaintiff surnamed Monegro in eleven months" — is fully AO-sourced and is the one used. Whether every one is the same individual does not affect the *Trade Ideas* finding, which rests on that case's own complaint and IDB record |
| ◇4 | **Which box is checked on the *DeMark Analytics v. TradingView* Form AO 120** — patent or trademark | The checkbox glyph does not survive text extraction from the scanned form (the same limitation Track 2 hit with Form ADV checkboxes) | The AO 120 is filed **only** for patent or trademark actions, which is on the face of the document and is all that is claimed. Either way it is IP, not status |
| ◇5 | **The exact wording of the *Suresh* minute order** describing the dismissal as self-effectuating under Rule 41(a)(1)(A)(i) | Reached the researcher through a summarising layer, **not as a verbatim retrieval of the order** | Flagged expressly so it is **not** quoted as a pin-cited passage. The shape of the disposition is independently solid: NOS 820, the Notice of Voluntary Dismissal With Prejudice at DE dated 01/16/2023, and termination 01/17/2023 |
| ◇6 | **The three TradingView docket sheets** (§N6) | The three cases were characterised from their **free filed PDFs** — a complaint, an AO 120 and a court order, all primary — but the docket sheets themselves were not pulled, so no NOS code is reported for them | They are context, not findings. None of the three is one of the five, and none bears on Q1/Q2/Q3 |

**Not on this list, and deliberately so:** the *Alpha Futures* subject matter. That is not a ◇ — it is a straightforward **UNKNOWN**, marked as such in the summary table and at S2b-05, with the exact document needed and its price stated.

---

## What remains unretrieved, and what it would cost

**The published PACER fee schedule**, quoted verbatim from `https://pacer.uscourts.gov/pacer-pricing-how-fees-work`, retrieved 7 Sep 2026:

> "**$0.10 per page**"
> "**You won't be charged more than $3 per document.**"
> "**Spend $30 or less on court records in a quarter and fees are WAIVED**"

The $3 cap corresponds to 30 pages and applies to documents and case-specific docket reports; the page notes there is **no** maximum fee for transcripts or for non-case-specific reports. **Everything listed below therefore costs well under the $30 quarterly waiver threshold, and would in practice very likely cost nothing** — provided the account's total usage in the quarter stays under $30. **Nothing was purchased; no account was created.**

### Priority 1 — the only item that could still change the answer

***Alpha Futures, Limited v. NinjaTrader Group, LLC et al***, N.D. Ill. **1:26-cv-08846**. This is the sole case of the five whose subject matter is unestablished.

| Order | Document | Why it is wanted | Pages | Cost |
|---|---|---|---|---|
| **1** | **DE 2 — Civil Cover Sheet (Form JS-44)** | Cheapest possible answer. Box VI states the "brief description of cause" in the filer's own words and Box III the basis of jurisdiction. Settles the question for pennies | 1–2 | **$0.10–$0.20** |
| **2** | **DE 1 — Verified Complaint** | Definitive. The only document that can show whether registration, adviser or broker-dealer status, or NinjaTrader's own status statement was pleaded | **12** | **$1.20** |
| 3 | DE 5 — Motion for TRO and Preliminary Injunction, with supporting memorandum | Would show the legal theories actually argued, and any status-based argument | — | ≤ $3.00 each |
| 4 | Full docket sheet | DE 6–11 and everything after DE 12 are invisible free. Would reveal any ruling on the TRO/PI and why two defendants were dropped on 6 Aug 2026 | — | ≤ $3.00 |

**Total to settle the open question: about $1.40, and $0 under the quarterly waiver.**

**A free route exists and should be tried first.** CourtListener's 125/day quota resets roughly 19.6 hours after it was exhausted on 7 Sep 2026. A single call — `GET /api/rest/v4/search/?q=docket_id:73669812&type=rd` — returns **every docket entry's full description text** at no cost, which may itself reveal the claims and any TRO ruling without touching PACER. A free CourtListener API token would additionally unlock `/api/rest/v4/dockets/` and `/docket-entries/`; **no account was created, per the brief**, but registering one is free and would remove this wall permanently for the register's future work.

### Priority 2 — completeness only; these cannot change any answer

| Case | Document | Why it cannot change the answer | Cost |
|---|---|---|---|
| *Cantero* (S.D. Fla. 0:10-cv-60271) | **DE 1 Complaint; DE 12 Answer and Affirmative Defenses** | Nature of suit 710 and cause 29:0201 are on the docket, and DE 6, 11, 24 and 25 are FLSA-specific court orders. The case is an overtime claim on the face of the record | ≤ $3.00 each |
| *Suresh* (D. Colo. 1:22-cv-02903) | DE 1 Complaint for Copyright Infringement | NOS 820, cause 17:501 and the clerk's AO-121 copyright report already fix it. Would only identify the specific work | ≤ $3.00 |
| *Monegro* (S.D.N.Y. 1:21-cv-01518-AT) | **ECF 12**, the filing advising the court of the settlement in principle — the only unread substantive item on that docket; and the literal docket-sheet header (the NOS is known from AO data but was not read off the sheet itself) | NOS 446, DISP 13, JUDGMENT 0 and the complaint's own text already fix it | ≤ $3.00 + ~$0.20 |
| *Monegro* | **The settlement agreement** | **Not obtainable at any price.** The court expressly declined to retain jurisdiction and the agreement was never made public record | — |
| *Gurung* (E.D.N.Y. 1:23-cv-06362) | 2d Cir. appeal No. 25-328 docket sheet (◇2) | The district opinion is fully retrieved and quoted; an appeal on a forum-clause dismissal would not create a status ruling | ≤ $3.00 |
| Monegro campaign | Confirmation of "Frankie" across all 160 suits (◇3) | Free via RECAP for the ~164 mirrored items; 15–30 min of fetching. Does not affect any finding | $0 |

### Walls that remain open, recorded for the next researcher

| Wall | Exact symptom | What would clear it |
|---|---|---|
| **CourtListener API** | `{"detail":"Request was throttled. Rate limit exceeded: 125/day."}` | Free API token, or a different IP, or waiting out the day |
| **CourtListener web frontend** | HTTP 202 zero-byte body (curl, browser UA); HTTP 403 (fetch tool) | Browser route |
| **Justia dockets** | HTTP 403 with Cloudflare `__cf_chl_tk` interstitial | Browser route |
| **PlainSite · Docketbird · UniCourt · Mojeek · DuckDuckGo** | CAPTCHA · 403 · 405 · CAPTCHA · 202 | Browser route |
| **Internet Archive RECAP mirror** | Silent false negatives — two confirmed-real cases return no item (§N7) | Nothing; it is a coverage gap, not an access gap. Always corroborate a zero against a second index |
| **Three TradingView dockets** (§N6) | Characterised from their free PDFs, but the docket sheets themselves were not pulled | Low priority; all three are already established as accessibility, IP and commercial |


---

# S3 · TRACK 3 — Cases where the customer wrote the rule and lost

**Commission P8. Bears on Q1 (adviser characterization) principally; Q2 and Q3 where noted.**
All retrieval dates are 7 September 2026 unless otherwise stated.

> **Scope note.** This track was commissioned to find the other side of the configuration's strongest fact — that every decision-relevant input is the member's own. The brief predicted the robo-adviser line would be "the richest vein." **It is not, and the reason matters more than the prediction did.** The robo line contains no user-configuration *status* defence because every robo respondent was already a registered adviser; the status question was never contested. What the robo line yields instead is worse for the configuration than a lost defence would have been: a **codified Commission rule** that makes client-supplied inputs a *constitutive element* of software-generated investment advice rather than a defence to it. That is entry S3-01, and it is the most adverse single item in this track.

---

## Register entries

### S3-01 · 17 C.F.R. § 275.203A-2(e)(2) (Internet investment advisers), as amended at 89 FR 24712 (9 Apr. 2024) · https://www.ecfr.gov/api/versioner/v1/full/2026-09-01/title-17.xml?section=275.203A-2 · retrieved 7 Sep 2026

- **Type:** rule (codified, current)
- **Date / status:** Good law. Current eCFR text as of 1 Sep 2026. Source note line reads: "[62 FR 28133, May 22, 1997, as amended at 63 FR 39715, 39716, July 24, 1998; 65 FR 57450, Sept. 22, 2000; 67 FR 77625, Dec. 18, 2003; 76 FR 43012, July 19, 2011; **89 FR 24712, Apr. 9, 2024**]"
- **Verbatim quote, pin-cited:**

> "(2) For purposes of this paragraph (e), 'operational interactive website' means a website, mobile application, or similar digital platform through which the investment adviser provides digital investment advisory services on an ongoing basis to more than one client (except during temporary technological outages of a de minimis duration). For purposes of this rule, **'digital investment advisory service' is investment advice to clients that is generated by the operational interactive website's software-based models, algorithms, or applications based on personal information each client supplies through the operational interactive website.**"
> — 17 C.F.R. § 275.203A-2(e)(2) (emphasis added)

- **What it establishes:** The Commission's own codified rule text defines a category of **investment advice** by three elements: (i) it is *generated by* software-based models, algorithms or applications; (ii) it is *based on personal information the client supplies*; (iii) it is provided on an ongoing basis to more than one client. The fact that the client supplies the inputs is written into the definition of the advice, not offered as a limit on it.
- **Q1:** **ADVERSE** — and this is the sharpest adverse item located in this track. The configuration's central submission is that because every decision-relevant input traces to a member setting, the output is not the company's advice. § 275.203A-2(e)(2) is a rule of the Commission that describes exactly that architecture — client supplies the personal information, software generates the output — and calls the output *investment advice*.
- **Level 5** — codified Commission rule, currently in force, addressing software-generated output from client-supplied inputs in terms.
- **Application note:** The configuration differs from the rule's subject in three respects that must be stated without softening in either direction. (1) **What the client supplies.** The rule's client supplies "personal information" — the adopting release's footnote 32 glosses this as "information relevant to the client's financial situation, level of financial sophistication, investment experience, and financial goals and objectives," i.e. *facts about himself*, from which the vendor's model derives a conclusion. The configuration's member supplies *the decision rule itself* — thresholds, weights, inclusion rules, universe, side mapping, sort key. That is a different kind of input, and no located authority draws the distinction (see Q1's premise in the shared context). (2) **Whose model.** The rule's advice is "generated by the operational interactive website's software-based models" — the vendor's model. In the configuration the engine is independently built and the member's settings determine the output, but the engine's *code* is still the company's. (3) **Direction of the rule.** § 203A-2(e) is a *registration-forum* rule — it determines whether an adviser registers with the Commission rather than the states. It presupposes the entity is an investment adviser and does not itself decide status. That is a real limit on its weight and it is recorded here rather than argued away. What it cannot be read to support is the proposition that client-supplied inputs negate advice; the rule text runs the other way.

---

### S3-02 · Exemption for Certain Investment Advisers Operating Through the Internet, Advisers Act Rel. No. IA-6578, 89 FR 24693 (9 Apr. 2024), eff. 8 July 2024 · https://www.federalregister.gov/documents/full_text/text/2024/04/09/2024-06865.txt · retrieved 7 Sep 2026

- **Type:** release (final rule adopting release)
- **Date / status:** Adopted, effective 8 July 2024. Good law.
- **Verbatim quotes, pin-cited:**

> "The current rule defines 'interactive website' to mean **a website in which computer software-based models or applications provide investment advice to clients based on personal information each client supplies through the website.**"
> — 89 FR 24693, § II.A (describing the pre-2024 rule text), text at n.32

> "We are adopting the definition of 'digital investment advisory service,' as proposed. The amendments will define 'digital investment advisory service' to mean investment advice to clients that is generated by the operational interactive website's software-based models, algorithms, or applications based on personal information each client supplies through the operational interactive website."
> — 89 FR 24693, § II.B

> "**Advisers are increasingly using algorithms to generate investment advice** in order to provide clients with cost-effective and tailored advice and the definition encompasses this use. The amendments will specify that, to qualify for the exemption, the investment advice to clients must be 'generated by' the website's software-based models, algorithms, or applications. Like the current rule, this definition is designed so that an adviser's personnel do not generate, modify, or otherwise provide client-specific investment advice through the operational interactive website or otherwise. **Human-directed client-specific investment advice, even if delivered through electronic means, would not be eligible activity under the Internet Adviser Exemption.**"
> — 89 FR 24693, § II.B (emphasis added)

- **What it establishes:** Two things. First, the *pre-2024* rule used the identical formulation — software-based models providing advice "based on personal information each client supplies" — so this construction has been the Commission's since 1997 and survived a 2024 re-adoption unchanged in substance. Second, the release's operative distinction is **software-generated versus human-directed**, not vendor-configured versus user-configured. The Commission drew a line in 2024 through this exact territory and the line it drew is orthogonal to the user-configuration argument.
- **Q1:** **ADVERSE.** The Commission had the occasion in 2024 to say something about who supplies the inputs to an algorithm and what follows from it. It said the client supplies personal information and the algorithm generates advice. It did not carve out, qualify, or reserve the case where the user supplies the decision rule.
- **Level 5** — Commission adopting release, current, addressing algorithmic advice in terms.
- **Application note:** Directly relevant to the configuration's engine layer. Note in fairness the release also records a commenter's request "that the Commission provide clarity, within the rule text itself, that personnel of the adviser cannot expand upon technologically generated advice but can answer other questions and help clients navigate the website or application" (§ II.B, text at n.56) — the Commission did not adopt that clarification in rule text. Note also the release's footnote 25 collects the enforcement history under this exemption: *In re Boveda Asset Management, Inc.*, IA-6016 (6 May 2022); *Ajenifuja Investments, LLC*, IA-5110 (12 Feb. 2019); *Strategic Options, LLC*, IA-5689 (24 Feb. 2021); *In re RetireHub, Inc.*, IA-3337 (15 Dec. 2011). **Every one of those is a case of an adviser claiming the exemption and being found ineligible because it did NOT have a qualifying interactive website** — i.e. the enforcement runs in the direction of "you were not automated enough," never "your users configured it, so you are not an adviser." That is a negative finding of some force and it is recorded at NF-3 below.

---

### S3-03 · IM Guidance Update No. 2017-02, "Robo-Advisers" (Div. of Investment Management, Feb. 2017) · https://www.sec.gov/investment/im-guidance-2017-02.pdf · retrieved 7 Sep 2026

- **Type:** staff guidance (Division of Investment Management; not Commission action, no legal force)
- **Date / status:** Issued Feb. 2017; not withdrawn as of retrieval. **Staff-level only** — weight discounted accordingly.
- **Verbatim quotes, pin-cited:**

> "Robo-advisers, which are typically registered investment advisers, use innovative technologies to provide **discretionary** asset management services to their clients through online algorithmic-based programs. **A client that wishes to utilize a robo-adviser enters personal information and other data into an interactive, digital platform (e.g., a website and/or mobile application). Based on such information, the robo-adviser generates a portfolio for the client** and subsequently manages the client's account."
> — IM Guidance Update 2017-02, p. 1 (emphasis added)

> "We have observed that robo-advisers may provide investment advice based primarily, if not solely, on client responses to online questionnaires."
> — *id.*, p. 6, under "Reliance on Questionnaires to Gather Client Information"

> **"Client-Directed Changes in Investment Strategy.** Many robo-advisers give clients the opportunity to select portfolios other than those that they have recommended. Some robo-advisers do not, however, give a client the opportunity to consult with investment advisory personnel about how the client-selected portfolio relates to the client's stated investment objective and risk profile, and its suitability for that client. **This may result in a client selecting a portfolio that the robo-adviser believes is not suitable for the investment objective and risk profile the robo-adviser has generated for the client based on his or her questionnaire responses. Thus, consistent with its obligation to act in its client's best interests, a robo-adviser should consider providing commentary as to why it believes particular portfolios may be more appropriate** for a given investment objective and risk profile."
> — *id.*, p. 7 (emphasis added)

- **What it establishes:** The staff's anatomy of the robo relationship is: **client supplies the inputs, adviser supplies the model, adviser's output is advice.** And on the precise point of this track — where the *client* overrides the model and selects for himself — the staff's response is not that the adviser's duty falls away but that the adviser should *add* commentary. Client selection increases what the adviser must do; it does not subtract from what the adviser is.
- **Q1:** **ADVERSE**, at staff level. This is the closest thing located anywhere to a regulator addressing "the client chose it himself" in an automated-advice setting, and the answer given is that the adviser's obligation persists through the client's own choice.
- **Level 3** — squarely on point and unambiguous, but staff guidance with no legal force, and directed to firms that are *already* registered advisers rather than to the status question.
- **Application note:** The passage does not decide status; it allocates duties within a conceded advisory relationship. The configuration's member is not choosing among the company's recommended portfolios — nothing is recommended and nothing is highlighted. But the structural move the staff makes is the one that hurts: the client's act of selecting for himself was treated as a fact about *how the advice is delivered*, not as a fact that removes the vendor from the advisory role. No located authority runs the other way. See also the "questionnaire" discussion at pp. 6-7, which asks whether the questionnaire "elicit[s] sufficient information to allow the robo-adviser to conclude that its initial recommendations and ongoing investment advice are suitable" — the client's own answers are treated as the *raw material* of the adviser's conclusion, which is the same structure as S3-01.

---

### S3-04 · In re Wealthfront Advisers, LLC, Advisers Act Rel. No. IA-5086, AP File No. 3-18949 (21 Dec. 2018) · https://www.sec.gov/litigation/admin/2018/ia-5086.pdf · retrieved 7 Sep 2026

- **Type:** enforcement order (settled administrative proceeding, §§ 203(e), 203(k))
- **Date / status:** Final. Settled without admitting or denying, except as to jurisdiction (¶ II).
- **Verbatim quotes, pin-cited:**

> "Wealthfront is an online 'robo adviser' that provides **automated, software-based portfolio management on a discretionary basis.** Wealthfront has been registered with the Commission as an investment adviser since 2008."
> — IA-5086, ¶ 1 (Respondent) (emphasis added)

> "In Wealthfront's TLH program, wash sales could occur, or were permitted, in certain circumstances relating to the management of a client account such as rebalancing a client portfolio or **client directed transactions**."
> — IA-5086, Summary (§ III); same at ¶ 3

- **What the client controlled:** Enrolment in the tax-loss-harvesting program; "client directed transactions" (¶ 3). Nothing else appears on the face of the order.
- **What the vendor controlled:** The whole of it — the TLH algorithm and how it was "programmed" (¶ 3), portfolio construction, rebalancing, and discretionary management of the account (¶ 1).
- **Which fact the finding turned on:** Not configuration at all. The violations rest on a **false statement in a whitepaper** — "Wealthfront's TLH whitepaper stated that 'Wealthfront monitors all the accounts it manages for each client to avoid any transactions that might trigger a wash sale.' **This statement was false.**" (¶ 3) — plus retweeted testimonials, unregistered-solicitor payments under Rule 206(4)-3, Form ADV misstatements, and books-and-records failures (¶¶ 6-17).
- **Was the "user configured it" argument made?** **No.** It appears nowhere in the order, in any form.
- **Disposition:** Willful violations of Advisers Act §§ 206(2), 206(4) (Rules 206(4)-1, 206(4)-3, 206(4)-7), 207 and 204(a) (Rules 204-2(a)(7), 204-2(a)(11)); censure, cease-and-desist, civil penalty, undertakings.
- **Q1:** **NEUTRAL** as to the user-configuration question — it is not addressed. Mildly **ADVERSE** only in that the Commission's baseline description of the product category is "discretionary."
- **Level 2** — a settled order, findings not binding on any other person (n.1), and it decides nothing this track asks.
- **Application note:** Recorded to close the line, not to carry weight. The brief asked what the client controlled and what the vendor controlled on the face of the order and which fact the finding turned on; the honest answer is that the client controlled almost nothing, the vendor controlled everything, and the finding turned on a false advertising statement. **Wealthfront is not authority against the configuration and it is not authority for it.** Anyone citing it either way is citing an advertising case.

---

### S3-05 · In re Hedgeable Inc., Advisers Act Rel. No. IA-5087 (21 Dec. 2018) · https://www.sec.gov/litigation/admin/2018/ia-5087.pdf · retrieved 7 Sep 2026

- **Type:** enforcement order (settled administrative proceeding)
- **Date / status:** Final. Settled (Offer of Settlement; findings "not binding on any other person or entity," n.1).
- **Verbatim quotes, pin-cited:**

> "Hedgeable operates a 'robo-adviser': an automated digital investment advisory program that is marketed to individuals, small business owners, trusts, corporations and partnerships through the fund's website, Hedgeable.com, as well as through social media platforms."
> — IA-5087, ¶ 1

> "Hedgeable has been registered with the Commission as an **internet investment adviser** since 2009."
> — IA-5087, ¶ 4

- **What the client controlled:** Nothing identified on the face of the order.
- **What the vendor controlled:** The models, the composite methodology, the published performance figures.
- **Which fact the finding turned on:** Misleading performance advertising — a "Robo-Index" built from Hedgeable's own estimate of two competitors' models, compared against a "Hedgeable Composite" that included "only 22 client accounts in 2014 and 38 client accounts in 2015, excluding 1,104 client accounts" (¶ 6), with cumulative returns presented as annualized (¶ 8); plus recordkeeping and compliance failures.
- **Was the "user configured it" argument made?** **No.**
- **Disposition:** Advisers Act §§ 206(2), 206(4)/Rules 206(4)-1(a)(5), 206(4)-7, 204(a)/Rule 204-2; censure, cease-and-desist, penalty.
- **Q1:** **NEUTRAL** on the track's question.
- **Level 2** — settled performance-advertising order.
- **Application note:** Its one contribution is ¶ 4's registration basis — Hedgeable was registered under the **internet adviser exemption**, which is the rule quoted at S3-01. That is the connective tissue: the Commission's automated-advice enforcement population is drawn from firms registered *under a rule whose definition of advice presupposes client-supplied inputs.*

---

### S3-06 · Commission Interpretation Regarding the Solely Incidental Prong of the Broker-Dealer Exclusion from the Definition of Investment Adviser, Advisers Act Rel. No. IA-5249, 84 FR 33681 (12 July 2019) · https://www.federalregister.gov/documents/full_text/text/2019/07/12/2019-12209.txt · retrieved 7 Sep 2026

- **Type:** release (Commission interpretation — Commission-level, not staff)
- **Date / status:** Final interpretation, in force.
- **Verbatim quotes, pin-cited:**

> "[The exercise of investment discretion is not] in connection with and reasonably related to effecting securities transactions; rather, the broker-dealer is making investment decisions relating to the purchase or sale of securities on behalf of customers on an ongoing basis. At the same time, the Commission has taken the position that some limited exercise of discretionary authority by broker-dealers could be considered solely incidental to their business."
> — 84 FR 33681, § II.B (text at nn.51-53)

> "We recognize, however, that there are situations where a broker-dealer may exercise **temporary or limited discretion** in a way that is not indicative of a relationship that is primarily advisory in nature. Generally, these are situations where the discretion is limited in time, scope, or other manner and lacks the comprehensive and continuous character of investment discretion that would suggest that the relationship is primarily advisory. … instances of temporary or limited investment discretion that, standing alone, would not support the conclusion that a relationship is primarily advisory … include discretion: **(i) As to the price at which or the time to execute an order given by a customer for the purchase or sale of a definite amount or quantity of a specified security;** … and **(vii) to purchase or sell a security or type of security limited by specific parameters established by the customer.** We view these examples of temporary or limited discretion as typically consistent with the broker-dealer exclusion because they are in connection with and reasonably related to a broker-dealer's business of effecting securities transactions and do not suggest that the broker-dealer's primary business is providing investment advice."
> — 84 FR 33681, § II.B (emphasis added), at 33685-86

> Footnote 61: "The Commission has in the past stated that the **quintessentially supervisory or managerial character of investment discretion** warrants the protection of the Advisers Act."
> — 84 FR 33681 n.61

- **What it establishes:** This is the **only Commission-level text located in this track that treats customer-established parameters as a fact with favourable legal consequence.** Item (vii) — "to purchase or sell a security or type of security limited by specific parameters established by the customer" — is the user-configuration fact, and the Commission lists it among the instances that do *not* make a relationship primarily advisory. Item (i) — price and time on an order for "a definite amount or quantity of a specified security" — is verbatim the configuration's envelope.
- **Q1 / Q2 / Q3:** **SUPPORT on outcome, ADVERSE on characterization** — and both halves must be carried together.
  - **SUPPORT:** the Commission has said, at Commission level, that acting within "specific parameters established by the customer," and exercising price-and-time latitude on an already-definite order, do not by themselves make a relationship primarily advisory.
  - **ADVERSE:** every item on that list is expressly an instance of **investment discretion**. The Commission's framing is that this conduct *is* discretion, merely "temporary or limited" discretion. That squarely reinforces FINRA Rule 4512(a)(3) (already in the register: time-and-price *is* investment discretion) and bears directly on Q3, where the configuration's position is that nobody is granted discretionary authority at all. On this release's framing, the runtime's price-band and re-peg latitude is not the absence of discretion; it is a small amount of it.
- **Level 4** — Commission-level interpretation, current, addressing customer-set parameters in terms; discounted from 5 only because it answers a different statutory question.
- **Application note:** The limit on this entry is structural and decisive, and must not be blurred. § 202(a)(11)(C) is an **exclusion available only to a broker or dealer.** The entire interpretation presupposes that the actor *is* a registered broker-dealer receiving no special compensation, and asks only whether its advice is solely incidental to *that* business. It therefore cannot be transplanted to an actor who is not a registered broker-dealer: it does not say the conduct is not advice, it says the conduct does not cost a broker-dealer its exclusion. For the configuration — where the runtime is not a broker-dealer and the relief sought is that no registration is required at all — item (vii) is an articulation of Commission thinking about customer-set parameters, not a safe harbour the configuration can occupy. Stated at its highest for the configuration: the Commission does not regard customer-established parameters as inherently advisory. Stated at its lowest against it: the Commission regards acting on them as the exercise of discretion.

---

### S3-07 · Regulation Best Interest: The Broker-Dealer Standard of Conduct, Exchange Act Rel. No. 34-86031, 84 FR 33318 (12 July 2019) · https://www.federalregister.gov/documents/full_text/text/2019/07/12/2019-12164.txt · retrieved 7 Sep 2026

- **Type:** release (final rule adopting release)
- **Date / status:** In force.
- **Verbatim quotes, pin-cited:**

> "We confirm that, consistent with the Proposing Release and as discussed further below, Regulation Best Interest would not: (1) Extend beyond a particular recommendation or generally require a broker-dealer to have a continuous duty to a retail customer or impose a duty to monitor; (2) require the broker-dealer to refuse to accept a customer's order that is contrary to the broker-dealer's recommendation; or **(3) apply to self-directed or otherwise unsolicited transactions by a retail customer, whether or not she also receives separate recommendations from the broker-dealer.**"
> — 84 FR 33318, at 33334-35 (emphasis added)

> "As we indicated in the Proposing Release, **the fact that a customer may have some knowledge of financial markets or some 'control' should not absolve the broker-dealer of the ultimate responsibility to have a reasonable basis to believe that any recommendations it makes are in the best interest of the retail customer.** … We further note that Regulation Best Interest does not require a broker-dealer to refuse to accept a customer's order that is contrary to the broker-dealer's recommendation. Nor does Regulation Best Interest apply to self-directed or otherwise unsolicited transactions by a retail customer, whether or not he or she also receives separate recommendations from the broker-dealer."
> — 84 FR 33318, § on excessive trading / Care Obligation (text at nn.662-64) (emphasis added)

> "Factors considered in determining whether a recommendation has taken place include whether the communication 'reasonably could be viewed as a "call to action"' and 'reasonably would influence an investor to trade a particular security or group of securities.' **The more individually tailored the communication to a specific customer or a targeted group of customers about a security or group of securities, the greater the likelihood that the communication may be viewed as a 'recommendation.'**"
> — 84 FR 33318, at 33335, text at n.161 (n.161 citing NASD Notice to Members 01-23)

> On the excluded categories (general financial and investment information; asset allocation models; interactive investment materials): these are excluded "**as long as they do not include (standing alone or in combination with other communications) a recommendation of a particular security or securities**."
> — 84 FR 33318, at 33337-38, quoting FINRA Rule 2111.03 framework

> Footnote 182: "In this regard, **as an allocation recommendation becomes narrower or more specific, the recommendation gets closer to becoming a recommendation of particular securities** and, thus, subject to the suitability rule. See FINRA Regulatory Notice 12-25 at FAQ 8."
> — 84 FR 33318 n.182

- **What it establishes:** The Commission's dividing line is **whether a recommendation was made**, not who held control. Customer control does not absolve where a recommendation exists; and where no recommendation exists, self-directed and unsolicited transactions fall outside the rule entirely, *even for a customer who receives recommendations elsewhere from the same firm*. The exclusions for tools and models are conditioned throughout on the communication not being about **a particular security**, and footnote 182 records that narrowing toward particular securities moves the communication toward recommendation.
- **Q1 / Q2:** **Mixed, and the mixture is the point.**
  - **SUPPORT:** "(3) apply to self-directed or otherwise unsolicited transactions by a retail customer, **whether or not she also receives separate recommendations from the broker-dealer**" is the cleanest statement located that a self-directed transaction is assessed on its own footing, and that contamination from a surrounding advisory relationship is not automatic. That bears on the configuration's approval surface sitting beside the engine's UI.
  - **ADVERSE:** the excluded categories are all *general* — asset classes, concepts, allocation models. The configuration's signal is `{instrument, side, fired_at}` — a **particular security, with a side, at a moment**. On the release's own axis ("the more individually tailored … about a security or group of securities") and footnote 182's ("as … narrower or more specific … closer to becoming a recommendation of particular securities"), a per-instrument timed signal sits at the far end from the excluded categories. The "some 'control' should not absolve" sentence is the Commission's own formulation of the answer to a user-configuration defence, and it is a rejection.
- **Level 4** — Commission adopting release, in force, but addressed to a broker-dealer's conduct standard rather than to status.
- **Application note:** Reg BI is a *conduct* rule that presupposes a registered broker-dealer, so it does not decide Q1 or Q2 status. Its value here is that it contains, in the Commission's own words, both the strongest general statement that a self-directed transaction is outside the recommendation framework and the strongest general statement that customer control does not absolve. They are reconciled by the recommendation inquiry, which turns on the **content and specificity of the communication**, not on who configured it. That reconciliation is the pattern this track was sent to find; see Direct Answer B.

---

### S3-08 · FINRA Rule 2214 (Requirements for the Use of Investment Analysis Tools) · read from Wayback snapshot **15 Feb. 2026** at http://web.archive.org/web/20260215151413/https://www.finra.org/rules-guidance/rulebooks/finra-rules/2214 · retrieved 7 Sep 2026

- **Type:** rule (SRO)
- **Date / status:** In force as at the 15 Feb. 2026 snapshot. **Access note:** finra.org itself returned HTTP 403 behind a Cloudflare JavaScript challenge on 7 Sep 2026 to curl with both a contact User-Agent and a browser User-Agent; the rule text here is from a dated Wayback snapshot, and the *live* text has not been confirmed as at the retrieval date. Flagged in the ◇ list.
- **Verbatim quotes, pin-cited:**

> "(a) General Considerations — This Rule provides a limited exception to Rule 2210(d)(1)(F). No member may imply that FINRA endorses or approves the use of any investment analysis tool or any recommendation based on such a tool. A member that offers or intends to offer an investment analysis tool under this Rule (**whether customers use the member's tool independently or with assistance from the member**) must provide FINRA's Advertising Regulation Department ('Department') access to the investment analysis tool upon request."
> — FINRA Rule 2214(a) (emphasis added)

> "(b) Definition — For purposes of this Rule and any interpretation thereof, an 'investment analysis tool' is an interactive technological tool that produces simulations and statistical analyses that present the likelihood of various investment outcomes if certain investments are made or certain investment strategies or styles are undertaken, thereby serving as an additional resource to investors in the evaluation of the potential risks and returns of investment choices."
> — FINRA Rule 2214(b)

> "(c) … A member may provide an investment analysis tool (**whether customers use the member's tool independently or with assistance from the member**), written reports indicating the results generated by such tool and related retail communications only if the tool, written report or related retail communication: (1) describes the criteria and methodology used, including the investment analysis tool's limitations and key assumptions; (2) explains that results may vary with each use and over time; (3) if applicable, **describes the universe of investments considered in the analysis, explains how the tool determines which securities to select, discloses if the tool favors certain securities and, if so, explains the reason for the selectivity**, and states that other investments not considered may have characteristics similar or superior to those being analyzed; and (4) displays the following additional disclosure: 'IMPORTANT: The projections or other information generated by [name of investment analysis tool] regarding the likelihood of various investment outcomes are hypothetical in nature, do not reflect actual investment results and are not guarantees of future results.'"
> — FINRA Rule 2214(c) (emphasis added)

- **What it establishes:** FINRA's rule for investor-facing analytical tools applies **"whether customers use the member's tool independently or with assistance from the member"** — the phrase appears three times, in (a), in (c), and in Supplementary Material .01. Independent, unassisted customer use of the tool does not take the tool outside the rule. And (c)(3)'s vocabulary attributes the selection to the tool: "**explains how the tool determines which securities to select**," "discloses if **the tool favors** certain securities."
- **Q1:** **ADVERSE**, with an important limit. The repeated parenthetical is the closest thing in the SRO rulebook to an express answer to "but the customer ran it himself," and the answer is that it makes no difference to the rule's application. The rule's own language also treats the tool, not the user, as the entity that "determines which securities to select" and that may "favor" securities.
- **Level 3** — SRO rule, directly on tools and expressly addressing independent customer use; discounted because it is a **communications and disclosure** rule that presupposes a FINRA member and imposes no status consequence on a non-member.
- **Application note:** Rule 2214 cannot make a non-member a member and does not speak to registration status; it is a limited exception to the advertising rule in Rule 2210(d)(1)(F). Its relevance is as a data point on the recurring question this track asks: does a regulator anywhere treat independent user operation of a tool as changing the analysis? Here, expressly, it does not. Two further asymmetries: (i) Rule 2214's subject is a tool "that produces simulations and statistical analyses that present the *likelihood of various investment outcomes*" — a forward-looking probabilistic tool, which the configuration's rule-firing signal is not; (ii) the disclosure duties in (c)(3) presuppose that the *member* knows and can explain "how the tool determines which securities to select," which in the configuration is determined by member settings. Note that this cuts both ways and is recorded as such: NASD NTM 01-23 (already in the register) is the source of the proposition that a search tool may rank securities by criteria the customer selected, and 2214 does not contradict it.

---

### S3-09 · 17 C.F.R. § 270.3a-4 (Status of investment advisory programs) · https://www.ecfr.gov/api/versioner/v1/full/2026-09-01/title-17.xml?section=270.3a-4 · retrieved 7 Sep 2026

- **Type:** rule (codified, current) — nonexclusive safe harbor
- **Date / status:** In force.
- **Verbatim quotes, pin-cited:**

> "**Note:** This section is a nonexclusive safe harbor from the definition of investment company for programs that provide **discretionary** investment advisory services to clients. … The section is not intended, however, to create any presumption about a program that is not organized and operated in the manner contemplated by the section."
> — 17 C.F.R. § 270.3a-4, Note

> "(3) **Each client has the ability to impose reasonable restrictions on the management of the client's account, including the designation of particular securities or types of securities that should not be purchased for the account, or that should be sold if held in the account; Provided, however, that nothing in this section requires that a client have the ability to require that particular securities or types of securities be purchased for the account.**"
> — 17 C.F.R. § 270.3a-4(a)(3) (emphasis added)

> "(1) Each client's account in the program is managed on the basis of the client's financial situation and investment objectives and in accordance with any reasonable restrictions imposed by the client on the management of the account."
> — 17 C.F.R. § 270.3a-4(a)(1)

- **What it establishes:** In the Commission's principal rule on model-portfolio and managed-account programs, **client control is a condition of the safe harbor, not a consequence of the program being non-advisory.** The programs in scope are expressly ones "that provide discretionary investment advisory services to clients." Client-imposed restrictions and client designation of particular securities coexist with, and are required by, an admittedly advisory and discretionary program.
- **Q1:** **ADVERSE**, structurally. The configuration's argument is that member control over the inputs is a reason the output is not the company's advice. Rule 3a-4 is the Commission's own instrument for the model-portfolio setting, and there client control is what makes an advisory program *acceptable*, never what makes it *not advisory*.
- **Level 3** — codified rule, current, directly about programs in which the client selects and restricts; discounted because it answers an Investment Company Act question (is the program an investment company?), not an Advisers Act status question.
- **Application note:** The proviso in (a)(3) is worth isolating: the Commission expressly did *not* require that a client be able "to require that particular securities or types of securities be purchased." Client control in the Commission's model of these programs is **negative** (exclusion, restriction) and the affirmative selection stays with the manager. The configuration inverts this — the member's settings determine affirmatively which instrument qualifies and on which side — and no located authority addresses that inversion. That gap is real and is recorded at NF-4.

---

### S3-10 · Rafael Pinchas, Exchange Act Rel. No. 34-41816, 54 S.E.C. 331 (1999) (Commission opinion on appeal from NASD) · https://www.sec.gov/litigation/opinions/34-41816.htm · retrieved 7 Sep 2026

- **Type:** Commission opinion (adjudicatory, on review of an SRO disciplinary action)
- **Date / status:** Final Commission opinion.
- **Verbatim quotes, pin-cited:**

> "Excessive trading occurs when a securities professional has control over trading in an account and the level of activity in that account is inconsistent with the customer's objectives and financial situation. **Pinchas asserts that Wang and Schimel either ordered him, or gave him permission, to execute the trades in their accounts and that they had full knowledge and understanding of the trading activity in those accounts. However, the record establishes that Pinchas had formal discretionary authority over the accounts at Lieberbaum and exercised de facto control over Wang's and Schimel's accounts at Prudential. De facto control can be established if a customer relies on a broker's advice because the customer is unable to evaluate the broker's recommendations and exercise independent judgment.**"
> — 34-41816, § III.A (emphasis added)

> Footnote 8: "See *Follansbee v. Davis, Skaggs & Co., Inc.*, 681 F.2d 673, 676-77 (9th Cir. 1982) (**even if a broker does not have formal discretionary authority, the account may be under the broker's control if his customer is unable to evaluate his recommendations and to exercise an independent judgment**)."
> — 34-41816 n.8 (emphasis added)

> "Pinchas asserts that he did not have control over Wang's and Schimel's accounts because the supervisors at Prudential and Lieberbaum approved the trading ticket orders for the accounts. However, a registered representative is responsible for his actions and cannot shift that responsibility to the firm or his supervisors."
> — 34-41816, § III.A

- **What the customer controlled:** On the respondent's account of it, everything that mattered — the customers "either ordered him, or gave him permission, to execute the trades" and "had full knowledge and understanding of the trading activity."
- **What the vendor/broker controlled:** The recommendations, and in the Commission's finding, de facto control of the accounts.
- **Which fact the decision turned on:** **Customer incapacity to evaluate.** "Schimel's and Wang's lack of sophistication gave Pinchas virtually complete control over their accounts." Wang "was unable to read and write English … and had practically no experience with investments"; Schimel "had only elementary-school-level skills in reading and arithmetic."
- **Was the "the customer decided it" argument made expressly, and in whose words?** **Yes — expressly, in the respondent's own words, as recited by the Commission:** "Pinchas asserts that Wang and Schimel either ordered him, or gave him permission, to execute the trades in their accounts."
- **How it was disposed of:** Rejected on the facts. Formal customer authorization of each trade did not defeat control, because control was found *de facto* from the customers' inability to exercise independent judgment.
- **Q1 / Q3:** **ADVERSE**, but narrowly and honestly so.
- **Level 3** — a Commission adjudicatory opinion in which the defence was expressly raised and expressly rejected; discounted because the ground of rejection is customer incapacity, which is a fact the configuration does not share and which is not present in a self-configuring member.
- **Application note:** This is the clearest instance located of a "the customer told me to do it" defence being made and rejected by the Commission, and it must be reported at full strength. But its ratio is **reliance and capacity**, not configuration: the Commission did not say that customer authorization is irrelevant; it said these particular customers could not evaluate what they were authorizing. That is a real and stated distinction from a member who writes his own thresholds. *Follansbee* (9th Cir. — the circuit containing Washington State) supplies the same rule: formal authority is not required where the customer "is unable to evaluate his recommendations and to exercise an independent judgment." The operative variable in this line is the **customer's capacity to evaluate**, which is a fact-specific inquiry the configuration would have to win on the facts rather than on its architecture.

---

### S3-11 · Request for Information and Comments on Broker-Dealer and Investment Adviser Digital Engagement Practices, Related Tools and Methods, and Regulatory Considerations and Potential Approaches, Exchange Act Rel. No. 34-92766 / Advisers Act Rel. No. IA-5833, 86 FR 49067 (1 Sept. 2021) · https://www.federalregister.gov/documents/full_text/text/2021/09/01/2021-18901.txt · retrieved 7 Sep 2026

- **Type:** release (Request for Information / request for comment only — **not a proposed rule**)
- **Date / status:** **Comment request only. It proposed nothing and adopted nothing.** Status-check result at NF-1 below.
- **Verbatim quotes, pin-cited:**

> "3.6 Do broker-dealers consider the observable impacts of DEPs when determining if they are making 'recommendations' for purposes of Reg BI? How does the fact that a DEP might impact the behavior of a statistically significant number of retail investors affect this determination? …
> 3.7 **Are there particular types of DEPs that broker-dealers avoid using because they would be recommendations?** If so, which DEPs and why? …
> 3.8 Do investment advisers consider the observable impacts of DEPs when determining if they are providing investment advice? …
> 3.9 **Are there particular types of DEPs that investment advisers avoid using because they would constitute providing investment advice?** If so, which DEPs and why?"
> — 86 FR 49067, questions 3.6-3.9 (emphasis added)

> "1.19 Do retail investors believe they are receiving investment advice or recommendations from DEPs or certain types of DEPs? If so, please explain."
> — 86 FR 49067, question 1.19

> "To the extent that a broker-dealer makes a recommendation, as that term is interpreted by the Commission … in connection with a DEP, Reg BI would apply to the recommendation."
> — 86 FR 49067, § II (footnote text accompanying the Reg BI discussion)

- **What it establishes:** The Commission **asked** whether digital engagement practices constitute recommendations or advice. It did not answer. The only operative statement is the tautology that if a recommendation is made, Reg BI applies to it.
- **Q1 / Q2:** **NEUTRAL.** A request for comment states no position and creates no authority.
- **Level 1** — request for information; no legal effect; question form throughout.
- **Application note:** The brief asked specifically for passages in which the Commission discusses tools where the user sets the parameters, or "selects" criteria, or screeners/watchlists/alerts. **A full-text term sweep of the release found: "parameters" — 0 occurrences; "self-directed" — 0; "watchlist" — 0; "watch list" — 0; "investor-directed" — 0; "screen" — 1 occurrence (unrelated); "alert" — 4 occurrences, all of which are citations to staff "Risk Alert" publications, none referring to a price or condition alert.** The DEP release therefore does **not** address user-configured tools at all, in either direction. That is a documented negative finding, not an inference from silence — see NF-2.

---

### S3-12 · Commission Interpretation Regarding Standard of Conduct for Investment Advisers, Advisers Act Rel. No. IA-5248, 84 FR 33669 (12 July 2019) · https://www.federalregister.gov/documents/full_text/text/2019/07/12/2019-12208.txt · retrieved 7 Sep 2026

- **Type:** release (Commission interpretation — Commission-level, final)
- **Date / status:** Final interpretation, in force.
- **Verbatim quotes, pin-cited:**

> "Although all investment advisers owe each of their clients a fiduciary duty under the Advisers Act, **that fiduciary duty must be viewed in the context of the agreed-upon scope of the relationship between the adviser and the client.** In particular, the specific obligations that flow from the adviser's fiduciary duty depend upon what functions the adviser, as agent, has agreed to assume for the client, its principal. For example, the obligations of an adviser providing comprehensive, discretionary advice in an ongoing relationship with a retail client … will be significantly different from the obligations of an adviser to a registered investment company or private fund where the contract defines the scope of the adviser's services and limitations on its authority with substantial specificity (e.g., **a mandate to manage a fixed income portfolio subject to specified parameters, including concentration limits and credit quality and maturity ranges**)."
> — 84 FR 33669, at 33671-72 (emphasis added)

> "**While the application of the investment adviser's fiduciary duty will vary with the scope of the relationship, the relationship in all cases remains that of a fiduciary to the client.** In other words, an adviser's federal fiduciary duty may not be waived, though it will apply in a manner that reflects the agreed-upon scope of the relationship."
> — 84 FR 33669, at 33672 (emphasis added)

> Footnote 26: "Several commenters asked that we clarify that **an adviser and its client can tailor the scope of the relationship to which the fiduciary duty applies through contract.** See, e.g., MMI Letter; Financial Engines Letter; ABA Letter."
> — 84 FR 33669 n.26

> Footnote 27: "**This Final Interpretation also applies to automated advisers, which are often colloquially referred to as 'robo-advisers.' Automated advisers, like all SEC-registered investment advisers, are subject to all of the requirements of the Advisers Act**, including the requirement that they provide advice consistent with the fiduciary duty they owe to their clients. See Division of Investment Management, Robo Advisers, IM Guidance Update No. 2017-02 (Feb. 2017) …"
> — 84 FR 33669 n.27 (emphasis added)

- **What it establishes:** This is the cleanest articulation located anywhere of the pattern this track was sent to find. **Client-specified parameters change the content of what the adviser owes; they do not change whether the adviser is an adviser.** The Commission expressly contemplates a mandate "subject to specified parameters" set by contract, expressly accepts that the parties may "tailor the scope of the relationship," and then expressly holds that "the relationship in all cases remains that of a fiduciary."
- **Q1:** **ADVERSE on the status question, SUPPORT on the duties question.** The configuration's argument that member-set inputs bear on *what the company is* runs into the second quoted sentence. Its argument that member-set inputs narrow *what the company would owe* is directly supported by the first.
- **Level 5** — Commission-level final interpretation, current, addressing client-specified parameters in terms.
- **Application note:** Two further consequences. (1) Footnote 27 is the Commission itself adopting IM Guidance Update 2017-02 by citation in a final interpretation — that raises the weight of S3-03 above ordinary staff guidance, in the same way NASD NTM 01-23 gains weight from being cited in the Reg BI adopting release at n.161 (already in the register). (2) The whole interpretation presupposes a *registered* adviser and an *agreed-upon relationship*; it does not address whether a person is an adviser in the first place, so it is not direct authority on Q1's threshold. What it forecloses is the intermediate move — the argument that because the member's own settings drive the output, the relationship is something other than advisory *in kind*. On this text, scope varies; kind does not.

---

### S3-13 · Withdrawal of Proposed Regulatory Actions, 90 FR 25531 (17 June 2025) — withdrawing the Predictive Data Analytics proposal, 88 FR 53960 (9 Aug. 2023) · https://www.federalregister.gov/documents/full_text/text/2025/06/17/2025-11110.txt · retrieved 7 Sep 2026

- **Type:** release (notice of withdrawal of proposed rules)
- **Date / status:** **Effective 17 June 2025. Confirms P7's record that the PDA proposal is WITHDRAWN, and supplies the exact instrument and date.**
- **Verbatim quotes, pin-cited:**

> "**ACTION: Notice of withdrawal of proposed rules.** SUMMARY: The Securities and Exchange Commission ('Commission') is formally withdrawing certain notices of proposed rulemaking issued between March 2022 and November 2023. **The Commission does not intend to issue final rules with respect to these proposals. If the Commission decides to pursue future regulatory action in any of these areas, it will issue a new proposed rule.**"
> — 90 FR 25531, Action and Summary (emphasis added)

> "**DATES:** The Commission is withdrawing the proposed rules published at 87 FR 45052 (July 27, 2022), **88 FR 53960 (August 9, 2023)**, 88 FR 14672 (March 9, 2023), 87 FR 13524 (March 9, 2022), 87 FR 36654 (June 17, 2022), 87 FR 68816 (November 16, 2022), 88 FR 41338 (June 26, 2023), 88 FR 76282 (November 6, 2023), 88 FR 5440 (January 27, 2023), 88 FR 128 (January 3, 2023), 88 FR 23146 (April 14, 2023), 88 FR 20212 (April 5, 2023), 87 FR 15496 (Mar. 18, 2022), and 85 FR 65990 (Oct. 16, 2020) **as of June 17, 2025.**"
> — 90 FR 25531, Dates (emphasis added)

> "On August 9, 2023, the Commission published proposed new rules under the Securities Exchange Act of 1934 ('Exchange Act') and the Investment Advisers Act of 1940 ('Advisers Act') to, among other things, address certain interactions between broker-dealers or investment advisers and investors through these firms' use of predictive data analytics."
> — 90 FR 25531, § "… Predictive Data Analytics by Broker-Dealers and Investment Advisers"

> Footnote 2: "88 FR 53960 (Aug. 9, 2023). When issued, this rule proposal was associated with RINs 3235-AN00 and 3235-AN14; RIN 3235-AN00 has subsequently been merged with RIN 3235-AN14. In addition, the Commission published a release making a correction to this rule proposal on Mar. 18, 2024. *Conflicts of Interest Associated With the Use of Predictive Data Analytics by Broker-Dealers and Investment Advisers; Correction*, 89 FR 19292 (Mar. 18, 2024)."
> — 90 FR 25531 n.2

- **What it establishes:** P7's record is confirmed and now precisely dated. The PDA proposal was withdrawn on **17 June 2025** by **90 FR 25531**, with the Commission stating it "does not intend to issue final rules" and that any future action would require a **new proposed rule**. Note also that the same instrument withdrew the SEC's Cybersecurity Risk Management proposal for advisers, 87 FR 13524.
> **Independent corroboration, and a date discrepancy that must be recorded.** The SEC's **Regulatory Flexibility Agenda, 90 FR 45652 (22 Sept. 2025)**, item 328, RIN 3235-AN14, states: "The Division of Trading and Markets and the Division of Investment Management were considering recommending that the Commission re-propose rules related to broker-dealer and investment adviser conflicts in the use of predictive data analytics, artificial intelligence, machine learning, and similar technologies in connection with certain investor interactions. **This item is being withdrawn from the Agenda.**" Its timetable reads: "NPRM … 08/09/23 … 88 FR 53960 / NPRM Comment Period End … 10/10/23 / **Withdrawn … 04/21/25**."
> — 90 FR 45652, at 45656-57, item 328 · https://www.federalregister.gov/documents/full_text/text/2025/09/22/2025-18321.txt · retrieved 7 Sep 2026
>
> **The agenda gives the withdrawal date as 21 April 2025; the Federal Register withdrawal notice states withdrawal "as of June 17, 2025."** Both are recorded; the operative public instrument is 90 FR 25531 and its stated date is **17 June 2025**. The April date appears to be the internal decision date carried on the agenda. **Do not cite 21 April 2025 as the effective withdrawal date without noting the discrepancy.**
>
> **And it has not returned.** The most recent Regulatory Flexibility Agenda, **91 FR 53164 (14 Aug. 2026)**, contains **0** occurrences of "predictive data analytics," **0** of "digital engagement," and **0** of "artificial intelligence." As at 7 Sep 2026 there is no agenda item signalling a re-proposal.

- **Q1 / Q2:** **NEUTRAL.** A withdrawn proposal is not authority. It is recorded so that no one in the register cites it as live.
- **Level 1** — as authority for any proposition about user configuration, nil. Level 5 only as to the fact and date of withdrawal.
- **Application note:** The brief asked whether anything in the PDA *proposing* release about a user "choosing" an output survives the withdrawal as an articulation of staff thinking. **A full-text term sweep of 88 FR 53960 returned: "parameters" — 0 occurrences; "investor chooses" — 0; "investor's choice" — 0; "investor selects" — 0; "user-defined" — 0; "investor input" — 0; "self-directed" — 2, both of which are recitations of comment-letter positions rather than Commission statements** (one is the Commission's summary of commenters noting "that Reg BI does not apply to firms with a self-directed brokerage business model," at 88 FR 53970; the other is footnote 101, quoting the Robinhood comment letter: "The SEC acknowledged the benefits of a self-directed model such as Robinhood's in adopting Reg BI, explicitly stating that Reg BI does not apply to this model."). **The PDA release therefore contains no Commission articulation of the user-choice point.** The Commission's own statement on self-directed transactions is in the Reg BI adopting release at S3-07, which is live law and which the Robinhood letter was characterising. Documented at NF-2.

---

### S3-24 · In re Betterment LLC, Advisers Act Rel. No. IA-6288, AP File No. 3-21373 (18 Apr. 2023) · https://www.sec.gov/files/litigation/admin/2023/ia-6288.pdf · **independently retrieved and verified by this track's author, 7 Sep 2026** (HTTP 200, 283,384 B, 12 pp.)

- **Type:** enforcement order (settled administrative proceeding, §§ 203(e), 203(k))
- **Date / status:** Final. Settled.
- **Verbatim quotes, pin-cited:**

> "**Coding Errors.** 18. Beginning in April 2016, **a coding error caused two Betterment client databases to not interface properly for certain accounts. The result was that for at least 150 accounts, TLH was disabled although clients had enabled it.** Consequently, Betterment did not scan these accounts or harvest any tax losses until the coding error was fixed."
> — IA-6288, ¶ 18, at 5 (emphasis added)

> "19. In January 2019, Betterment learned about and fixed the coding error after an inquiry from the third-party investment adviser referenced in paragraph 16. Betterment attempted to notify impacted clients and remediate the issue, but these efforts were incomplete. In particular, **Betterment determined that the error had persisted for nearly three years**, but in emails notifying clients, it stated that the error 'may have caused your account to miss some efficient harvesting opportunities in 2018.'"
> — IA-6288, ¶ 19, at 5-6 (emphasis added)

- **What the client controlled:** The **election itself** — clients "had enabled" tax-loss harvesting. That is the purest instance in the whole register of a client-set switch.
- **What the vendor controlled:** The code that read the switch. And the code silently did not.
- **Which fact the finding turned on:** That the service delivered did not match what was represented and what the client had elected — and, at ¶ 19, that the remediation notice understated a three-year defect as a 2018 problem.
- **Was the "user configured it" argument made?** No. It could not be: the user *had* configured it, and the configuration was defeated by the vendor's own software.
- **Q1:** **ADVERSE — and adverse in a way nothing else in this track is.**
- **Level 3** — settled order, findings not binding on others; but its facts go to a proposition no other located source addresses.
- **Application note — this is the most uncomfortable single fact for the configuration in the securities line, and it is not a legal holding.** Every other adverse entry attacks the *legal significance* of member control. *Betterment* attacks its *factual reality*. The configuration's central submission is that "every decision-relevant input is the member's" and that "no company-controlled choice may determine which instrument qualifies, its side, when it fires, or where it ranks." **But the member's settings are only ever as good as the company's code that reads them.** In *Betterment*, 150 clients had switched a feature on, the company's code did not honour it, and for nearly three years the outcome in those accounts was determined by company code rather than by client election. Stated as a comparison and not a conclusion: the configuration's architecture contains several mitigations that *Betterment* did not have — an append-only, provenance-linked, replay-safe journal (source → policy version → composed order → exact terms shown → instruction → adapter → broker response); policy versions journaled; a runtime-owned approval surface rendered in the signed runtime's own process that displays the complete composed order before the member acts; and the broker's statement as final truth. Those are precisely the controls by which a *Betterment*-type divergence would surface rather than persist. **What the configuration cannot claim is that member control is self-executing.** It is a property of the code, maintained by the company, and *Betterment* is the Commission's demonstration of what happens when that property silently fails. Note also that Betterment was charged under §§ 206(2) and 206(4)/Rule 206(4)-7 — i.e. this was actionable as a *disclosure and compliance-program* failure, not as a status question.

---

### S3-25 · In re Fair Invest, LLC and Khalid Parekh, Securities Act Rel. No. 33-11329 / Advisers Act Rel. No. IA-6776, AP File No. 3-22331 (25 Nov. 2024) · https://www.sec.gov/files/litigation/admin/2024/33-11329.pdf · **independently retrieved and verified by this track's author, 7 Sep 2026** (HTTP 200, 193,332 B, 9 pp.)

- **Type:** enforcement order (settled administrative proceeding)
- **Date / status:** Final. Settled.
- **Verbatim quotes, pin-cited:**

> "[Fair Invest's Form ADV stated that] Fair Invest '**provides "robo-advisory" portfolio management services via an online interface.**' '**These automated investment solutions are customized to each client and based on individual characteristics, such as the client's age, risk tolerance, income, and current assets, among others.**'"
> — 33-11329, ¶ 16.b, at 4 (emphasis added)

> "18. The above statements in Paragraphs 16 and 17 were untrue or misleading. … **Second, Fair Invest never created software to provide 'robo' advisory services and never engaged a third party to provide such services. Third, Fair Invest never sought or obtained information to determine each client's specific risk tolerance, investment strategy, or investment objectives.** Fourth, Fair Invest never made long-term investments in equities, ETFs, mutual funds, or commodities, as represented in the Form ADV. Instead, it limited investments to short-term crypto-asset lending."
> — 33-11329, ¶ 18, at 5 (emphasis added)

> "20. Parekh's original plan was for Fair Invest to provide investment advice to WBA accountholders using a robo-adviser model. **He used an automated on-line compliance service to prepare the initial Form ADV, which reflected Parekh's original plan.** Before accepting any WBA clients, however, he abandoned the original plan … But he did not disclose to clients the switch to a crypto-asset lending strategy and did not revise the firm's Form ADV or other documents to disclose the new strategy."
> — 33-11329, ¶ 20, at 6 (emphasis added)

- **What the client controlled:** Nothing. **What the vendor controlled:** Everything, including a robo-adviser that did not exist.
- **Which fact the finding turned on:** The falsity of the Form ADV representations, including the representation that the service was "**customized to each client**."
- **Q1:** **NEUTRAL as authority; instructive as to what the Commission polices.**
- **Level 2** — settled order; a misrepresentation case, not a status case.
- **Application note:** Recorded for one reason that bears on this track's question from an unexpected direction. The representation whose falsity the Commission charged is the **personalization claim** — "customized to each client and based on individual characteristics." In the robo line the Commission's enforcement interest attaches to **claims of tailoring**, and it attaches whether the claim is inflated (*Fair Invest*, where no software existed) or the tailoring silently fails (*Betterment*, S3-24). Neither direction assists a vendor arguing that user configuration removes it from adviser status; both show the Commission treating the personalization/customization representation as the material one. Note ¶ 20's incidental detail — the false Form ADV was generated by "an automated on-line compliance service" — which is not a holding about anything, but is worth a line in any register that touches automated compliance tooling.

---

### S3-26 · Conflicts of Interest Associated With the Use of Predictive Data Analytics by Broker-Dealers and Investment Advisers, Exchange Act Rel. No. 34-97990 / Advisers Act Rel. No. IA-6353, File No. S7-12-23, 88 FR 53960 (9 Aug. 2023) — **the proposing release's own articulations** · https://www.federalregister.gov/documents/full_text/text/2023/08/09/2023-16377.txt · **all passages independently verified verbatim and page-located by this track's author, 7 Sep 2026**

- **Type:** release (proposed rule — **WITHDRAWN**, see S3-13)
- **Date / status:** **Withdrawn 17 June 2025 by 90 FR 25531.** Not authority. Recorded because the brief asked specifically what in it survives the withdrawal as an articulation of Commission thinking — and because one passage is the most on-point text located anywhere in this track for the alert line.

**(i) THE HEADLINE PASSAGE — 88 FR 53975. Verbatim:**

> "**The proposed definition of investor interaction would include interactions that have generally been viewed as outside the scope of 'recommendations' for broker-dealers.**\135\ For example, under the proposed definition, an investor interaction could include: **firms' use of research pages or 'electronic libraries'** to provide investors with the ability to obtain or request research reports, news, quotes, and charts from a firm-created website; or **firm's use of technologies to generate emails to investors as part of a firm-run email communication subscription that investors can sign up for and customize, and which alerts investors to items such as news affecting the securities in the investor's portfolio or on the investor's 'watch list.'**\136\ **Accordingly, the proposed definition would capture firm communications that may not rise to the level of a recommendation**, yet are nonetheless designed to, or have the effect of, guiding or directing investors to take an investment-related action."
> — 88 FR 53960, at **53975** (emphasis added). Footnote 135 cites **NASD Notice to Members 01-23** (Online Suitability) and the Reg BI Adopting Release § II.B.2; **footnote 136 cites NASD NTM 01-23 alone.**

- **Q1 / Q2:** **SUPPORT — and on existing law, this is the strongest securities-side passage in the track.**
- **Level 3** — the *proposal* is withdrawn and carries no force; but the quoted sentence is not a proposal, it is **the Commission's characterization of the pre-existing baseline** ("have generally been viewed as outside the scope of 'recommendations'"), and that characterization is unaffected by the withdrawal of the rule that would have changed it.
- **Application note — what it gives and what it does not.**
  **What it gives.** In 2023 the Commission described an **investor-signed-up-for, investor-customizable alert keyed to the securities on the investor's own watch list** as something that "may not rise to the level of a recommendation" and that has "generally been viewed as outside the scope of 'recommendations'." It cited NASD NTM 01-23 for that proposition — the same notice whose fn.18 (already in the register) says a customer-requested price-point alert is, "without more," not a recommendation. **The Commission then proposed a new rule to capture such communications, and that rule was withdrawn on 17 June 2025.** The consequence, stated as a comparison and not a conclusion: the Commission thought it needed **new rulemaking** to reach investor-customized watch-list alerts, and it does not have it. That is the cleanest available evidence of where the Commission itself located the existing-law boundary, and the boundary sits on the far side of a customer-configured alert.
  **What it does not give, and this is the material limit.** The example is an alert about **news affecting** securities — *information*, not a side. The configuration's signal is `{rule_id, rule_version, instrument, side, fired_at, …}`: it carries a **side**, a buy or a sell, on a **particular instrument**, at a **particular moment**. Nothing in this passage addresses a communication carrying a side. Read against the Reg BI axis at S3-07 ("the more individually tailored … about a security or group of securities") and NTM 01-23's "without more," **the side field is exactly the "more,"** and no located authority says what it does. The passage narrows the gap in Q1; it does not close it.
  Note also that this concerns a **broker-dealer's** communications to its own customers within an existing brokerage relationship, which is not the configuration's posture.

**(ii) The adverse counterweights in the same release, verified verbatim:**

> "Similarly, **using algorithmic-based tools, such as investment analysis tools, to provide tailored investment recommendations to investors would fall under the proposed definition of covered technology** because the use of such tools is directly intended to guide investment-related behavior. … Similarly, if a firm utilizes a spreadsheet that implements financial modeling tools or calculations, such as correlation matrices, algorithms, or other computational functions, to [guide investment-related behavior, the model in that spreadsheet would be a covered technology]."
> — 88 FR 53960, at **53972**. **ADVERSE, but note the qualifier is "tailored investment recommendations"** — the same tailoring axis as Rule 4.14(a)(9) at S3-20, not a who-configured-it axis.

> "**To the extent a technology is customizable, we anticipate a firm will be able to evaluate the technology and identify the conflicts associated with its use through the choices it makes when customizing the technology.** For technologies that are not customizable, we anticipate a firm will be able to evaluate the technology and identify conflicts via other means. For example, a firm that licenses a covered technology from a third party may have no access, or limited access, to the underlying source code of the technology. … **Firms without access to the underlying source code could review**, for example, documentation about how the technology can be tailored to its investors' requirements …"
> — 88 FR 53960, at **53977-78**. **ADVERSE in structure:** customizability is treated as generating a **firm-side** diligence obligation, never as an investor-side answer. Note also that the Commission contemplated a firm deploying **third-party technology whose source code it cannot see** and still bearing the evaluation duty — relevant to the configuration's three-layer, independently-built-engine architecture.

> "This requirement would include **making and maintaining records of all instances where an investor requested that a covered technology be altered or restricted in any manner.** We believe these records will assist in identifying which technologies may present higher risks, for example if they require constant alterations or **if certain investors request that such technologies not be used on their accounts.**"
> — 88 FR 53960, at **53997**. **ADVERSE in structure:** an investor's own act of restricting the technology is treated as a **recordkeeping artefact and a risk signal**, not as a fact bearing on status.

> "For example, **complex algorithms used in discretionary or non-discretionary robo-advising platforms could make it difficult for an investor to understand material facts or conflicts of interest and make an informed decision whether to consent** or to allocate assets into or out of the platform."
> — 88 FR 53960, at **54007**. Note the express bracketing of "**discretionary or non-discretionary**" — consistent with CFTC Letter 09-27 at S3-17 and with Rel. IC-22579 n.18 already in the register.

**(iii) A genuinely supportive design passage — 88 FR 53984. Verbatim:**

> "Similarly, a broker-dealer may bring general investment ideas to the attention of retail investors, using an algorithm for selection, where some of the investments that may be selected provide revenue to the firm if the investor places an order to purchase. If the firm determines that in selecting the investment ideas, the algorithm used for selecting the investment ideas does not place the firm's interests ahead of investors' interests—**because, for example, it does not give more prominence to the investments that provide revenue to the firm than those that do not and no one investment is being recommended**—it could reasonably determine that the conflict of interest created by the algorithm considering the revenue does not require elimination or neutralization under the proposed conflicts rules."
> — 88 FR 53960, at **53984** (emphasis added)

- **Application note on (iii):** even under the *proposed* (and now withdrawn) conflicts rules, the Commission's stated safe outcome for an algorithm that selects and presents investments rested on two facts the configuration is built to have: **no differential prominence**, and **"no one investment is being recommended."** The configuration's "Sort labels are neutral ('Yield: high to low', never 'best'); nothing highlighted, no picks" maps onto the first, and its absence of any pick maps onto the second. It also had a third fact the configuration lacks entirely — a revenue interest in the selected investments — which is what created the conflict needing to be reasoned away in the first place.

---

## Register entries — the CEA / CFTC line (what came after *R&W* and *Taucher*)

> The brief directed this track to the CFTC/NFA parallel because *R&W Technical Services* and *Taucher v. Born* live there, and to find what came after them. **What came after them is worse for the configuration than either of them, and it is recent.**

### S3-14 · CFTC v. Donelson (Long Leaf Trading Group), No. 23-1809 (7th Cir. 5 Sept. 2024) · slip op. · https://www.govinfo.gov/content/pkg/USCOURTS-ca7-23-01809/pdf/USCOURTS-ca7-23-01809-0.pdf · retrieved and read in full 7 Sep 2026

- **Type:** court opinion (US Court of Appeals, Seventh Circuit)
- **Date / status:** Decided 5 Sept. 2024. **The newest appellate decision in the *Taucher*/*R&W* line, and it post-dates everything in P7's frozen set.** Good law.
- **Verbatim quotes, pin-cited:**

> "The district court correctly found that Long Leaf is a CTA and was acting as one throughout Donelson's tenure as CEO. Donelson's own words confirm this. As he explains, Long Leaf 'recommended transactions to consumers' as part of its brokerage activities. **Once customers confirmed the recommended trade, Long Leaf forwarded it to a futures commission merchant and earned a commission.** In other words, Long Leaf advised clients for profit as to the advisability of trading in commodity options, which fits it within the Act's definition. See 7 U.S.C. § 1a(12)(A)(i)."
> — slip op. at 15 (emphasis added)

> "Donelson objects to that finding and cites two out-of-circuit, district court cases as support for reversing. Per Donelson, the first case, *Taucher v. Born*, 53 F. Supp. 2d 464 (D.D.C. 1999), found that the plaintiffs were not CTAs. Quoting *Taucher*, Donelson says they did not 'engage in individual consultations with their customers regarding their standard advice and recommendations and **under no circumstances do they make trades for their customers**,' having instead to go through 'some other licensed broker.'"
> — slip op. at 15-16 (emphasis added)

> "**But *Taucher* holds the opposite:** 'Each of the plaintiffs in this case falls squarely within the definition of a CTA. They engage in the business of advising others, through publications, writings and electronic media, as to the value of or the advisability of trading in the futures market, and they do so for compensation or profit.' *Id.* at 475."
> — slip op. at 16 (emphasis added)

> "**Even if *Taucher* or *AVCO* drew a line between personal and impersonal advice, the text of the statute does not. The CTA definition is 'broad'—'broad' enough to include both types of advice.** *Commodity Trend Serv.*, 149 F.3d at 687. Thus, we agree with the district court that there is no genuine dispute of material fact that Long Leaf was acting as a CTA."
> — slip op. at 16 (emphasis added)

- **What the customer controlled:** **The decision on every single trade.** Nothing happened until "customers confirmed the recommended trade."
- **What the vendor controlled:** The recommendation, and the onward transmission to the FCM; it earned a per-trade commission.
- **Which fact the decision turned on:** That Long Leaf "advised clients for profit as to the advisability of trading" — i.e. **the content of the communication plus compensation.** The customer's confirmation of each trade is recited as part of the *operative* description and is given **no exculpatory weight whatsoever**.
- **Was the "the customer decided it" argument made expressly, and in whose words?** **Yes — expressly, by the appellant, relying on *Taucher* itself**, and quoted by the court: Long Leaf "under no circumstances … make[s] trades for their customers," going instead through "some other licensed broker."
- **How it was disposed of:** Rejected. The Seventh Circuit held Donelson had misread *Taucher*, and delivered the sentence that matters most for P8: **"Even if *Taucher* or *AVCO* drew a line between personal and impersonal advice, the text of the statute does not."**
- **Q1 / Q3:** **ADVERSE — the single most adverse new authority located in this track.**
- **Level 5** — federal appellate decision, 2024, in the exact doctrinal line, expressly rejecting a *Taucher*-based user-autonomy argument.
- **Application note, stated bluntly.** This is the closest structural analogue located anywhere to the configuration's per-order approval act: **a customer who confirms every single trade before anything is transmitted.** In *Donelson* that fact did no work at all. The two facts that *did* do the work are facts the configuration does not share: (i) Long Leaf **recommended** the transactions (the configuration highlights nothing, ranks by neutral labels, and picks nothing); and (ii) Long Leaf **earned a commission per trade** (the configuration takes a flat monthly membership and nothing per trade, on volume, on assets or on performance). So the configuration distinguishes *Donelson* — **but it distinguishes it on content and compensation, not on user control.** Anyone relying on the member's per-order tap as the distinguishing fact is relying on precisely the fact the Seventh Circuit passed over in silence. Note also the sting for the register's existing reliance on *Taucher*: the Seventh Circuit reads *Taucher* as P7 already recorded it — the holding at *475 that the plaintiffs "fall squarely within the definition of a CTA" — and treats the contrary reading as a misreading. **And note the statutory limit on transplanting any of this to Q1, added after the court sweep:** *Donelson* is a **CEA** case. *Commodity Trend Service* (S3-28) holds that "the CEA has a broader scope than the IAA" on exactly this axis, because the Advisers Act's publisher exclusion is not qualified by "solely incidental" while the CEA's is — so that impersonal publishers "are included within the definition of CTA, **even though an analogous publisher would be excluded from the definition of IA**." What survives transplantation from *Donelson* to Q1 is its **factual** demonstration that per-trade customer confirmation did no work in the tribunal's reasoning. What does **not** survive is any inference that CTA status implies adviser status. **Note finally the one thing that ran Donelson's way:** the §6m(1) registration count and the disclosure count were **vacated and remanded**, on the Reg. 4.14(a)(6) introducing-broker exemption, with the court rejecting the CFTC's "guided accounts" comment letter (CFTC Staff Letter 95-82) as "neither attempt[ing] nor achiev[ing] a close reading of the text" (slip op. at 18). That partial win rests on statutory text about introducing-broker business; **it has nothing to do with user configuration.**

---

### S3-15 · CFTC v. Hall, 49 F. Supp. 3d 444 (M.D.N.C. 30 Sept. 2014) · read in official reporter text at https://static.case.law/f-supp-3d/49/html/0444-01.html · retrieved 7 Sep 2026

- **Type:** court opinion (federal district court)
- **Date / status:** Final; summary judgment for the CFTC.
- **Verbatim quotes, pin-cited:**

> "It is undisputed that, during the relevant period, 'in exchange for payment of a monthly fee, [Defendant] advised [his] subscribers, via e-mail as to when they should open and close positions in E-mini S & P's 500 Futures Contracts' … and that Defendant's Website 'advertise[d] [Defendant's] trading system for E-mini S & P's 500 Futures contracts.' **Accordingly, regardless of whether or not Plaintiff considered himself a CTA, he met the definition for purposes of the Act.**"
> — 49 F. Supp. 3d at 449-50 (emphasis added)

> "Thus, Defendant concludes that, because '**at no time did [he] give advice that was tailored to even one individual**,' he was not a CTA and was not required to register as a CTA. (Docket Entry 39 at 7.) **Defendant's position does not comport with a proper reading of the Regulation.** Rather, by conducting any of the activities listed in Section 4.14(9), Defendant failed to meet the registration exemption of Regulation 4.14."
> — 49 F. Supp. 3d at 452 (emphasis added)

- **What the customer controlled:** Received e-mails telling them when to open and close positions and acted on them or not.
- **What the vendor controlled:** The trading system and the signals; and — decisively — he also **directed some accounts**, which he admitted.
- **Which fact the decision turned on:** The subscription service advising "when they should open and close positions … in exchange for payment of a monthly fee" met the CTA definition; and the Rule 4.14(a)(9) exemption failed because he *directed accounts*.
- **Was the argument made expressly?** **Yes, in the defendant's own words:** "at no time did [he] give advice that was tailored to even one individual"; "[Defendant] was not and never has been required to register as and should not be considered a CTA according to specific rule and law."
- **How it was disposed of:** Rejected. Summary judgment; §6m(1) violation; lifetime registration ban.
- **Q1:** **ADVERSE**, with a real distinguishing fact.
- **Level 3** — district court; on point as to a signal-subscription service on a flat monthly fee, but the exemption analysis turned on account-direction, which the configuration does not have.
- **Application note:** The compensation structure is the notable overlap — **a flat monthly subscription fee, not per-trade** — and it did not save him, because the CTA definition asks about advising for "compensation or profit" without regard to its form. The distinguishing fact is that Hall admitted directing accounts ("Yes[,] [Defendant] traded accounts for individuals who ask him to, and this could be referred to as 'directing' an account"), which independently defeated Rule 4.14(a)(9). The configuration has no account-direction. But the first quoted holding — that he met the CTA definition by e-mailing subscribers when to open and close positions for a monthly fee — did not depend on account-direction at all.

---

### S3-16 · CFTC Staff Letter 03-26 (Div. of Clearing & Intermediary Oversight, 30 May 2003) · https://www.cftc.gov/sites/default/files/idc/groups/public/@lrlettergeneral/documents/letter/03-26.pdf · retrieved 7 Sep 2026

- **Type:** no-action / interpretive letter (staff — no legal force; binds only the Division)
- **Date / status:** Issued 30 May 2003. **Request REFUSED.**
- **Verbatim quotes, pin-cited:**

> "In adopting Rule 4.14(a)(9), the Commission noted it intended '**that a CTA who manages a client's trading under some type of informal arrangement be required to register even if the CTA is not authorized to effect transactions without the client's specific authorization.**'"
> — CFTC Letter 03-26, at 1-2 (quoting the Rule 4.14(a)(9) adopting release) (emphasis added)

> "[T]he facts as represented by you, and confirmed by .A., would indicate the presence of the type of 'informal arrangement' for which the exemption provided under Rule 4.14(a)(9) was not intended. Moreover, the fact that the whole of your activities as an AP of .X. consists of the solicitation of clients for the trading program would urge registration as a CTA. **Accordingly, registration as a CTA is required of either .X. or yourself.**"
> — CFTC Letter 03-26, at 2-3 (emphasis added)

> "Rule 4.14(a)(9) exempts from registration CTAs who do not provide trading advice based on, or tailored to, the commodity interest or cash market positions or other circumstances or characteristics of particular clients. … Additionally, Rule 4.14(a)(9) exempts from registration CTAs who do not **direct** client accounts, meaning that it may not be authorized to cause transactions to be effected for any client's commodity interest account."
> — CFTC Letter 03-26, at 1

- **What it establishes:** The most directly on-point sentence located in the entire CEA line for **Q3**. The Commission's stated intention in adopting the standardized-advice exemption was that an informal arrangement requires registration **"even if the CTA is not authorized to effect transactions without the client's specific authorization."** Per-transaction client authorization is expressly contemplated and expressly held insufficient.
- **Q1 / Q3:** **ADVERSE.** The configuration's Q3 position is that the member's per-order act makes the transaction the member's own instruction. This letter says, in the CEA context, that the requirement of the client's specific authorization for each transaction does not remove the registration obligation.
- **Level 2** — staff letter, no legal force, and it construes a CEA exemption rather than the Advisers Act or the Exchange Act. But it is quoting the *Commission's* adopting-release intent, which raises it.
- **Application note:** The letter's own facts include a per-trade commission ("you will instead receive per-trade commissions as an AP of .X.") and solicitation, both absent from the configuration. The quoted sentence about specific authorization, however, is a general statement of the Commission's intent in the adopting release, not a fact-bound conclusion. It is the CEA analogue of the point *Donelson* later made without argument.

---

### S3-17 · CFTC Staff Letter 09-27 (Div. of Clearing & Intermediary Oversight, 25 June 2009) · https://www.cftc.gov/csl/09-27/download · retrieved 7 Sep 2026

- **Type:** interpretive letter (staff — no legal force)
- **Date / status:** Issued 25 June 2009.
- **Verbatim quote, pin-cited:**

> "In analyzing this definition as it applies to your request, we note that **the CTA definition is not dependent on whether a person provides advice on a discretionary basis** (e.g., pursuant to a power of attorney or other similar means). **Nor is it dependent on compensation being received from trading recommendations made on a discretionary basis or the results of the performance of a TPCTA, or as commissions from the account as traded by a TPCTA. What is required, however, is that a person advise others about 'the value of or the advisability of' trading** the financial instruments referred to in Section 1a(6)(A)(i) of the Act."
> — CFTC Letter 09-27, at 3 (emphasis added)

- **What it establishes:** In the CEA line, **who pulls the trigger is not the test, and the form of compensation is not the test.** The single required element is that the person advise others as to the value or advisability of trading.
- **Q1 / Q3:** **ADVERSE.** This is the clearest staff articulation located that discretion — the presence or absence of it — is not what makes a person a trading advisor.
- **Level 2** — staff letter, no legal force, CEA rather than Advisers Act.
- **Application note:** Read together with S3-06 (the Commission's Solely Incidental interpretation, which treats acting on customer parameters as *a form of* discretion) and S3-16, the CEA line's structure is: discretion is neither necessary nor sufficient; the content of the communication is what counts. That is the same axis the securities-law materials converge on. See Direct Answer B.

---

### S3-18 · Nadex Advisory Notice 2015_01, "Advisory Notice Regarding Third Party Technology and Signal Providers," deemed certified effective 15 Dec. 2015 (CEA §5c(c)(1); CFTC Rule 40.6(a)) · rule certification submission no. 20151130(1) · https://www.cftc.gov/filings/orgrules/rule120115nadexdcm001.pdf · retrieved 7 Sep 2026 — **read together with** Dissenting Statement of Commissioner Caroline D. Pham (29 Aug. 2023) · https://www.cftc.gov/PressRoom/SpeechesTestimony/phamstatement082923 · retrieved 7 Sep 2026 — **and** CFTC v. BareIt Media LLC d/b/a SignalPush & Masten, Consent Order, No. 1:20-cv-00908-RP (W.D. Tex. 29 Aug. 2023), CFTC Rel. 8770-23

- **Type:** exchange (DCM) advisory notice, self-certified · plus a Commissioner's dissenting statement · plus a consent order
- **Date / status:** **Contested. The advisory notice was deemed certified in 2015 and not stayed; a sitting Commissioner stated in August 2023 that the Commission had just departed from it. The dissent did not carry.**
- **Verbatim quotes, pin-cited:**

> "To illustrate the registration requirement, according to the CEA definition of a CTA, a signal provider who provides advice (i.e. the trade signal) either directly to the trader or through a publication, and is compensated for such advice is acting as a CTA. This provider may need to register with the CFTC as a CTA unless it qualifies for an exemption from registration pursuant to CFTC Rule 4.14(a)(9). **On the other hand, a technology provider that sells software capable of receiving and aggregating trade signals, and submitting orders to the Exchange based upon those signals and parameters customized by the trader is not likely required to register with the CFTC as the trade advice does not originate from the technology provider. In such instances, the technology merely facilitates the flow of information between the signal provider, the trader, and the Exchange.**"
> — Nadex Advisory Notice 2015_01, at 4 (emphasis added); quoted verbatim in the Pham dissent

> "For the past nearly 10 years, the Commission has distinguished that a signal provider that provides trade signals or advice for compensation must register as a CTA, but that a technology provider that aggregates (but does not originate) trade signals and submits orders to an exchange is not likely required to register as a CTA."
> — Pham, Dissenting Statement (29 Aug. 2023)

> "**But now, for the first time since the Nadex Advisory Notice, the Commission is changing this interpretation because the Masten Consent Order may be construed to require technology providers that do not originate trade signals to nonetheless register as CTAs.** … This is not merely regulation by enforcement—this is regulation by fiat. Such a broad proclamation is the act of kings, not of a free democracy."
> — Pham, Dissenting Statement (29 Aug. 2023) (emphasis added)

> The consent order's own operative finding: "**In exchange for compensation, SignalPush offered customers and potential customers the ability to obtain trade signals and to automate trading on binary options platforms using those trade signals.** … By the conduct described in paragraphs 20 through 22 above, Defendant BareIt Media acted as a commodity trading advisor by, for compensation or profit, engaging in the business of advising others … and failed to register as such, in violation of Section 4m(1) of the Act."
> — SignalPush Consent Order ¶¶ 20, 25 (Case 1:20-cv-00908-RP, Doc. 111, filed 29 Aug. 2023, at 5-6) · https://www.cftc.gov/media/9186/enfryanmastenconsentorder082923/download · **independently retrieved and verified in the primary PDF by this track's author, 7 Sep 2026**

> **Negative finding within the consent order.** A full-text term sweep of the 12-page consent order returned: **"select" — 0 occurrences; "choose" — 0; "parameters" — 0; "customiz" — 0; "originate" — 0.** The order therefore makes no finding whatever about what the customer configured, what the customer selected, or whether the advice originated with SignalPush. It recites only that "SignalPush offered customers and potential customers the ability to obtain trade signals and to automate trading … using those trade signals" (¶ 20) and concludes that BareIt "acted as a commodity trading advisor" (¶ 25). **This silence is the whole of the disagreement between the majority and Commissioner Pham**: the order neither applied nor distinguished the Nadex origin/configuration line, and it is a consent order with agreed findings, so nothing was litigated.

- **What it establishes:** **This is the answer to Framing Question A, and it is a qualified "almost."** The Nadex Advisory Notice is the only text located in this entire track in which a user-configuration fact — "parameters customized by the trader" — appears in a sentence concluding that registration is "not likely required."
- **Q1 / Q2:** **SUPPORT, heavily qualified — and see the reading caveat below, which materially reduces it.**
- **Level 2** — and only 2, for four reasons stated without softening: (i) it is a **derivatives exchange's own advisory**, self-certified under Rule 40.6(a), not a Commission interpretation, not a staff letter, and not an adjudication; (ii) "deemed certified" means the Commission did not stay it, which is not approval of its reasoning; (iii) it is a **CEA** document, not securities law; (iv) a sitting Commissioner stated in 2023 that the Commission had **departed from it**, and her statement was a **dissent that did not carry**, which means the majority neither adopted nor repudiated the notice in a reasoned document.
- **Application note — the reading caveat, which matters more than the quote.** The Nadex sentence gives its own reason, and the reason is **not** customization. It is origin: "**as the trade advice does not originate from the technology provider.**" The customization clause describes *how the technology behaves*; the operative because-clause is that **the advice came from somewhere else** — a separate signal provider, with the technology merely "facilitat[ing] the flow of information between the signal provider, the trader, and the Exchange." In the configuration the engine **originates the signal**. That the signal is computed from member-set thresholds is precisely the point in issue, and the Nadex notice does not address it: its favourable outcome is reserved for a provider that is a *conduit for someone else's advice*, which is the position of the configuration's **runtime**, not its **engine**. Read at its highest, S3-18 supports the runtime layer and the third-party-list mechanism. It does not, on its own words, support the engine layer. **Framing Question A is therefore answered "no" as to any adjudicated authority, and "almost, in a non-binding exchange notice that a Commissioner says has since been departed from, and on a rationale of origin rather than configuration."**

---

### S3-19 · NFA Interpretive Notice 9055, "NFA Bylaw 1101, Compliance Rules 2-9 and 2-29: Guidelines Relating to the Registration of Third-Party Trading System Developers" (Board 19 Aug. 2004; eff. 10 Jan. 2005; amended 19 Sept. 2016 and 1 Jan. 2020) · https://www.nfa.futures.org/rulebooksql/rules.aspx?RuleID=9055&Section=9 · **independently retrieved and verified by this track's author, 7 Sep 2026** (HTTP 200, 158,160 B)

- **Type:** SRO interpretive notice
- **Date / status:** In force as amended 1 Jan. 2020.
- **Verbatim quotes, pin-cited:**

> "[NFA Members increasingly do business with] third-party trading system developers ('third-party system developers'), who are neither NFA members nor registered with the CFTC. Typically, in these situations, the customer will execute a Letter of Direction that directs the Member to place trades for the customer in strict accordance with the signals generated by the trading system. **In some cases, the Letter of Direction is more limited and includes instructions to follow only certain signals (e.g., signals in given contracts or signals that meet particular parameters).** In almost all cases in which a Letter of Direction is used, the Member is not permitted to use any judgment when placing orders for the customer."
> — NFA Interpretive Notice 9055 (emphasis added)

> "[If] the advice is provided to a particular client in a face-to-face communication or over the telephone, that factor may weigh in favor of a finding that the CTA's advice is 'based on or tailored to' that particular customer's characteristics, since such a context suggests that the CTA is being responsive to the client's individual needs."
> — NFA Interpretive Notice 9055 (on the Rule 4.14(a)(9) tailoring axis)

> "**Whether a third-party system developer is required to be registered as a CTA still depends on the particular facts of each case.**"
> — *id.*

> "This is clearly the case where **a customer independently selects a trading system** and the IB does not solicit discretionary trading authority. However, if any of these factors change (e.g., the IB has authority to deviate from the trading system by selecting only some of the trades generated by the system), **the IB may be required to register as a CTA** …"
> — *id.*

> "Member firms should not seek to circumvent NFA's promotional material requirements by relying upon the unregistered status of the third-party trading system developer."
> — *id.*

- **What it establishes:** NFA expressly contemplates customers who select the system independently and who restrict it to "signals that meet particular parameters." **The relief that customer selection generates is directed at the *broker*, not at the *system developer*.** For the developer, the notice says only that registration "still depends on the particular facts of each case" — no safe harbour.
- **Q1:** **ADVERSE**, mildly, by omission: the one place an SRO squarely addresses customer-selected parameters in a signal-system context, the customer's selection relieves the intermediary and leaves the developer's status open.
- **Level 2** — SRO interpretive notice, CEA context, and it declines to state a rule for developers.
- **Application note:** The final quoted sentence is the closest analogue located to *Ranieri Partners* (already in the register): a member firm cannot lean on the vendor's unregistered status to escape its own obligations. Note also the enforcement teeth the notice supplies — if a developer will not produce a counsel letter or register, "the Member should terminate its relationship with the third-party system developer to avoid liability under NFA Bylaw 1101." That is a **commercial** risk channel to the vendor that operates without any regulator ever charging the vendor, and it has no securities-law analogue located in P1–P8.

---

### S3-20 · Rule 4.14(a)(9) adopting release, "Exemption From Registration for Certain Commodity Trading Advisors," 65 FR 12938 (10 Mar. 2000) · https://www.cftc.gov/files/foia/fedreg00/foi000310a.pdf · **independently retrieved and verified by this track's author, 7 Sep 2026** (HTTP 200, 143,046 B)

- **Type:** release (final rule adopting release, CFTC)
- **Date / status:** Adopted 10 Mar. 2000 — **the CFTC's own response to *Taucher* (1999) and *R&W* (2000)**. Rule 4.14(a)(9) remains in force.
- **Verbatim quotes, pin-cited:**

> "**C.** A CTA provides commodity trading advice through an Internet web site. **The web site requires the user to indicate whether he or she has a preference for trading agricultural futures contracts or financial futures contracts. Users who indicate that their preference is agricultural futures contracts receive different advice from those who indicate that financial futures contracts are their preference.** The CTA's advice is not 'based on, or tailored to, the commodity interest or cash market positions or other circumstances or characteristics of particular clients,' within the meaning of Rule 4.14(a)(9)(ii). **Rather, the CTA is merely allowing its clients to select which advisory services they wish to purchase. Therefore, this CTA is exempt from the Section 4m registration requirement under Rule 4.14(a)(9).**"
> — 65 FR 12938, at 12941-42, Example C (emphasis added)

> "**E.** A CTA conducts seminars at which it teaches attendees how to trade commodity futures contracts aided by a software program that the CTA sells. **Before each seminar commences, the CTA polls the attendees to discover their level of ability and knowledge. The CTA presents a more advanced seminar for classes that have a higher degree of experience.** Because such advice is not 'based on, or tailored to, the commodity interest or cash market positions or other circumstances or characteristics of particular clients,' within the meaning of Rule 4.14(a)(9)(ii), **this CTA is exempt from the Section 4m registration requirement.**"
> — 65 FR 12938, at 12942, Example E (emphasis added)

> Footnote 14: "The following examples of the application of Rule 4.14(a)(9) supercede the examples provided in the Notice of Proposed Rulemaking. **Examples are illustrative and not intended to be statements of law.** As noted above, persons are free to seek advice regarding their specific activities."
> — 65 FR 12938 n.14 (emphasis added)

> Footnote 15: "In each of the following examples, **the CTA does not have powers of attorney from any of its clients to trade accounts.** In addition, **the CTA in each example remains subject to requirements of the Act and the Commission's regulations that apply to all CTAs without regard to registration**, such as Section 4o of the Act and Commission Rules 4.30, 4.41(a) and 4.41(b), as well as to provisions that apply to any person, such as Section 4b of the Act."
> — 65 FR 12938 n.15 (emphasis added)

- **What it establishes:** **This is the strongest supporting text located in the entire track, and it is the only official agency document found in which a user's own selection is expressly held not to make the resulting advice tailored.** Example C is a website on which *the user's own indicated preference determines which advice he receives*, and the agency's answer is that the vendor "is merely allowing its clients to select which advisory services they wish to purchase." Example E goes further in one respect: the vendor *collects information from the users* and *adapts its output to them*, and the advice is still not "tailored," because tailoring is measured against **the client's own positions and circumstances**, not against whether the output varies by user input.
- **Q1:** **SUPPORT — the best located.**
- **Level 3** — an agency adopting release with worked examples, currently in force; but held down from 4 by four limits, each of which must be stated.
- **Application note — the four limits, none of which can be softened.**
  **(1) It is an exemption from registration, not an exclusion from status.** Rule 4.14(a)(9) exempts "certain **commodity trading advisors**." Every person in Examples C, D, E and F **is a CTA**; the rule merely relieves them of registering. Footnote 15 makes this explicit: each "remains subject to requirements of the Act and the Commission's regulations that apply to all CTAs **without regard to registration**," including the antifraud provision, §4o. So even the best supporting text in this track does **not** say that user selection means the vendor is not an advisor. It says a person who *is* an advisor need not register. That is precisely the distinction Pattern B describes at Direct Answer B, and it holds even here.
  **(2) There is no Advisers Act counterpart.** The CEA has a standardized-advice exemption with a tailoring test; the Advisers Act does not. **The configuration cannot import Rule 4.14(a)(9)**, and this track located no analogous instrument on the securities side. This is the structural reason *R&W* and *Taucher* read as P7 recorded them.
  **(3) Footnote 14 disclaims legal effect** — "Examples are illustrative and not intended to be statements of law."
  **(4) The selection in Example C is between two broad asset classes** (agricultural vs financial futures), not a per-instrument decision rule with thresholds, weights and a firing time. Whether the reasoning extends from "which advisory service do you wish to purchase" to "which instrument qualifies, on which side, and when" is **not addressed**, and the reasoning's own words ("merely allowing its clients to select which advisory services they wish to **purchase**") are about product selection, not signal generation.
  **What it is genuinely worth.** As evidence of *how a regulator draws the line when it wants to protect impersonal tools*, this is the most useful document in the track: the axis it chose is **tailoring to the client's own positions and circumstances**, and it expressly held that output varying with user-supplied input does **not** cross that line. That is a direct answer, from an agency, to one half of the user-configuration question — and it went the vendor's way, on registration.

---

### S3-21 · CFTC v. Wall Street Underground, Inc., 281 F. Supp. 2d 1260 (D. Kan. 2003) · official reporter text at https://static.case.law/f-supp-2d/281/html/1260-01.html · **independently retrieved and verified by this track's author, 7 Sep 2026**

- **Type:** court opinion (federal district court)
- **Date / status:** Final as to the rulings described (findings of fact and conclusions of law on injunctive relief).
- **Verbatim quotes, pin-cited:**

> "Defendants Web and Asaro argue that they are incapable of violating the Act because they do not meet the definition of commodity trading advisors ('CTA'), as set forth above. **The court agrees. There is no evidence in the record to support a finding that defendants Web and Asaro acted as CTAs.** However, as set forth in detail below, the court concludes that defendants Guarino and WSU, while acting as CTAs, violated Section 4o(1)(A) and 4o(1)(B) of the Act …"
> — 281 F. Supp. 2d at 1268, § III.A "Violation of Act" (emphasis added)

> "During the relevant time period, **defendant Web accepted client orders, collected payments, and recommended futures commission merchants at which clients could open accounts and trade utilizing the trading systems' recommendations.** Defendant Web shipped computers, facsimile machines, pagers, beepers, and welcome packages to existing clients. Defendant Web's customer service representatives gave clients instructions on how to use the computers and how to navigate through the defendant WSU's website … **Neither defendant Web nor its employees made specific buy and sell recommendations to clients.**"
> — 281 F. Supp. 2d, Findings of Fact § II.A (emphasis added)

- **What it establishes:** **A defence to CTA status that SUCCEEDED** — recorded because Framing Question A requires every success to be reported. But the ground was that the defendant **made no specific buy and sell recommendations** — not that customers configured anything.
- **Q1 / Q2:** **SUPPORT**, and materially stronger than it first appears — see the application note.
- **Level 3** — district court, CEA; raised from 2 because the findings of fact isolate the operative variable unusually cleanly.
- **Application note.** The findings of fact make this the most instructive *favourable* case located in the track, for a reason that has nothing to do with user configuration. **Web did a great deal that looks like intermediation and was still not a CTA:** it "accepted client orders," "collected payments," "recommended futures commission merchants," shipped the hardware, ran the customer-service channel, and was for part of the period the *only* way clients could contact WSU. None of that made it a trading advisor. **The single fact that saved it is the one in the last sentence of the findings: it "made [no] specific buy and sell recommendations to clients."** The contrast inside one case is exact: the system's authors (Guarino and WSU), whose "Letter and trading systems make specific buy and sell recommendations on commodity futures and commodity options," **were** CTAs; the party that handled everything else was not. Two consequences for the register: (i) this is direct support for the proposition that **order handling and payment collection do not, without recommendation content, create advisor status** in the CEA line — compare the *CommandTRADE* carve-out for "order transmission" already in the register on the securities side; (ii) it confirms Pattern 1 at Direct Answer B — **content about a particular security is the operative variable** — and confirms that user configuration is not. Note the limits: it is a district court, it is the CEA, and Web was found liable on other theories (common enterprise / controlling person) notwithstanding that it was not a CTA.

---

### S3-22 · In re Charles Schwab & Co., Inc., Charles Schwab Investment Advisory, Inc., and Schwab Wealth Investment Advisory, Inc., Exchange Act Rel. No. 34-95087 / Securities Act Rel. No. 33-11069 / Advisers Act Rel. No. IA-6058 (13 June 2022) · https://www.sec.gov/litigation/admin/2022/34-95087.pdf · retrieved 7 Sep 2026

- **Type:** enforcement order (settled administrative proceeding)
- **Date / status:** Final. Settled on Offers of Settlement; findings "not binding on any other person or entity" (n.1). $187 million to harmed clients.
- **Verbatim quotes, pin-cited:**

> "Each of SIP's model portfolios held between 6% and 29.4% of clients' assets in cash. **The amount of cash that each SIP model portfolio contained was pre-set so that Respondents' affiliate bank would earn at least a minimum amount of revenue from the spread on the cash by loaning out the money.** In significant part because of the revenue received from the spread on the SIP cash allocations, Respondents did not charge investors an advisory fee for the SIP service."
> — 34-95087, ¶ 1 (emphasis added)

> "Respondents made false and misleading statements in their Form ADV filings regarding both their conflict of interest in setting the cash allocations at a level that would earn a minimum amount of revenue, as well as the effect of the cash allocations. … Also, they **falsely claimed that the cash allocations in the SIP portfolios were determined through a 'disciplined portfolio construction methodology' when in fact they were pre-set for business reasons, and to compensate Respondents for not charging an advisory fee.**"
> — 34-95087, ¶ 2 (emphasis added)

- **What the client controlled:** Nothing identified in the order as bearing on the violation.
- **What the vendor controlled:** **The parameter itself.** The cash allocation was "pre-set" by the respondents, at a level chosen to guarantee affiliate revenue.
- **Which fact the finding turned on:** An undisclosed **conflict of interest** in a **vendor-set parameter**, plus the false characterization of that parameter as the output of a "disciplined portfolio construction methodology."
- **Was the "user configured it" argument made?** **No.** It could not have been: the client configured nothing, and the parameter at issue was set by the respondents for their own revenue.
- **Disposition:** Willful violations of Securities Act §17(a)(2) and (3) and Advisers Act §§ 206(2), 206(4)/Rule 206(4)-7 and 207; censure, cease-and-desist, $187m disgorgement/distribution and penalty.
- **Q1:** **NEUTRAL as authority; SUPPORT by negative implication.**
- **Level 2** — settled disclosure order; decides nothing about status or configuration.
- **Application note:** This is the one robo matter whose *operative fact* is a parameter, and the parameter runs the opposite way from the configuration. What made Schwab's conduct unlawful was that **a company-controlled setting determined a client outcome and was set to serve company revenue, undisclosed.** The configuration's architecture is the negation of each limb: no company-controlled choice may determine which instrument qualifies, its side, when it fires or where it ranks; the economics are a flat monthly membership with nothing per trade, on volume, on assets or on performance, and no payment from brokers or issuers. Stated as a comparison and not a conclusion: *Schwab* is evidence of what the Commission polices in automated advice — **hidden vendor-set parameters with a revenue interest attached** — and the configuration is built to have none. That is a genuine point in the configuration's favour, and it is the only one this track found in the robo line. It says nothing about whether the configuration is an adviser.

---

### S3-23 · FINRA Rule 2111 (Suitability), incl. paragraph (b) and Supplementary Material .02 and .03 · read from Wayback snapshot **18 Feb. 2025** at http://web.archive.org/web/20250218115433/https://www.finra.org/rules-guidance/rulebooks/finra-rules/2111 · retrieved 7 Sep 2026

- **Type:** rule (SRO)
- **Date / status:** In force as at the 18 Feb. 2025 snapshot. **Access note:** finra.org returned HTTP 403 behind a Cloudflare JavaScript challenge on 7 Sep 2026; live text not confirmed as at the retrieval date. Flagged in the ◇ list.
- **Verbatim quotes, pin-cited:**

> "(b) A member or associated person **fulfills the customer-specific suitability obligation for an institutional account, as defined in Rule 4512(c), if (1) the member or associated person has a reasonable basis to believe that the institutional customer is capable of evaluating investment risks independently, both in general and with regard to particular transactions and investment strategies involving a security or securities and (2) the institutional customer affirmatively indicates that it is exercising independent judgment** in evaluating the member's or associated person's recommendations. Where an institutional customer has delegated decisionmaking authority to an agent, such as an investment adviser or a bank trust department, these factors shall be applied to the agent."
> — FINRA Rule 2111(b) (emphasis added)

> ".02 **Disclaimers.** A member or associated person **cannot disclaim any responsibilities under the suitability rule.**"
> — FINRA Rule 2111, Supp. Mat. .02 (emphasis added)

> ".03 **Recommended Strategies.** The phrase 'investment strategy involving a security or securities' used in this Rule is to be interpreted broadly and would include, among other things, an explicit recommendation to hold a security or securities. However, the following communications are excluded from the coverage of Rule 2111 **as long as they do not include (standing alone or in combination with other communications) a recommendation of a particular security or securities** …"
> — FINRA Rule 2111, Supp. Mat. .03 (emphasis added)

- **What it establishes:** This is the **most structurally important SRO text located in this track**, and it has not previously been read this way in the register. FINRA *does* recognise a rule under which the customer's own independent judgment discharges the firm's customer-specific obligation. **It is available only for an institutional account**, it requires *two* findings — the customer is "capable of evaluating investment risks independently" **and** "affirmatively indicates that it is exercising independent judgment" — and it is expressly followed through to any agent to whom decision-making has been delegated.
- **Q1 / Q3:** **ADVERSE by structure**, and the structure is the finding. Where a self-regulatory rule wanted to give effect to customer independence, it did so **expressly, in a codified paragraph, and confined it to institutional customers.** There is no retail counterpart. The configuration serves retail members.
- **Level 3** — SRO rule directly codifying a customer-independence relief; discounted because it presupposes a FINRA member and governs suitability rather than status.
- **Application note:** Three consequences, stated as comparison only. (1) This is the **same axis** on which *S3 Matching Technologies* (already in the register) was conditioned — institutional accounts under FINRA Rule 4512(c). Two independent instruments, one a staff letter and one a codified rule, both give relief for sophisticated customer independence and both restrict it to institutional accounts. That is now a **pattern of two**, and it runs against a retail-facing configuration. (2) The two-part test in 2111(b) is instructive on what regulators require before customer independence counts: not merely that the customer *had* control, but that the customer was **capable of evaluating the risk** and **affirmatively said** he was exercising independent judgment. That is the same variable *Pinchas* and *Follansbee* turn on (S3-10) — capacity, not formal control. (3) Supp. Mat. .02 forecloses the disclaimer route in one sentence, consistent with NASD NTM 01-23 and the Web Sites Guidance already in the register.

---

## Register entries — the court-decision sweep (added last; all verified in primary text)

### S3-27 · Rome v. Mandel, 2016 COA 192M, 405 P.3d 387 (Colo. App. 29 Dec. 2016) · official reporter text at https://static.case.law/p3d/405/html/0387-01.html · **independently retrieved and verified by this track's author, 7 Sep 2026**

- **Type:** court opinion (state intermediate appellate — Colorado Securities Act)
- **Date / status:** Final; summary judgment for the Securities Commissioner affirmed.
- **Verbatim quotes, pin-cited:**

> "Under the Ditto Trade model, **a follower may choose certain controls limiting the extent to which the follower's account mimics the lead trader's transactions (e.g., the follower can exclude identified securities from being traded or limit the investment amount that will follow the lead trader's transactions).** Alternatively, the follower can select the 'ditto all' or 'full throttle' option …"
> — ¶ 7, 405 P.3d at 390-91 (emphasis added)

> "[W]hen the lead trader initiates a transaction for his or her account, the broker-dealer automatically executes the same transaction in the followers' accounts, **without need for further instruction or approval. Followers are often not aware of the trades until after they have occurred.**"
> — ¶ 6, 405 P.3d at 390 (emphasis added), citing *Terry's Tips*, 409 F. Supp. 2d at 530

> "¶ 32 Defendants disseminated investment advice under their lead trader service by **effectively exercising discretion** over part or all of their subscribers' accounts with Ditto Trade. … **The advice, therefore, was sufficiently personalized to require a license under the CSA, regardless of whether defendants based the advice on the subscribers' individual portfolios or financial goals.**"
> — ¶ 32, 405 P.3d at 395 (emphasis added)

> "¶ 40 … Under the circumstances of this case, **the question whether defendants rooted their advice in a client's particular portfolio or specific investment needs is immaterial because that disputed fact does not affect the outcome.**"
> — ¶ 40, 405 P.3d at 396 (emphasis added)

> "**Merely publishing a newsletter allegedly compliant with the exclusion does not give the publisher carte blanche to offer other services that do not satisfy the exclusion and would require an investment adviser license.**"
> — ¶ 33, 405 P.3d at 395, quoting *Terry's Tips*, 409 F. Supp. 2d at 532

- **What the user controlled:** **Real configuration** — the follower could *exclude identified securities from being traded* and *cap the investment amount* that would follow. That is a member-set universe restriction and a member-set sizing limit, two of the configuration's own categories.
- **What the vendor controlled:** Which security, which side, when, and how much — by trading his own account, which the platform then replicated.
- **Which fact the decision turned on:** That the defendants were "**effectively exercising discretion**" and that execution occurred "**without need for further instruction or approval**," with followers "often not aware of the trades until after they have occurred."
- **Was the argument made expressly, and in whose words?** **Yes — the court records that "[d]efendants identify only one disputed fact: whether they based their services on their subscribers' individual portfolios or specific investment needs" (¶ 20, at 392).** That is the tailoring/user-configuration defence in the defendants' own framing.
- **How it was disposed of:** Held **immaterial**. Licence required; First Amendment defence rejected; $80,000 restitution affirmed.
- **Q1:** **ADVERSE — the most on-point *securities-law* rejection of the defence located anywhere, and it is new to the register.**
- **Level 4** — a reasoned appellate decision squarely rejecting the argument on adviser status, applying the *Lowe* publisher framework and expressly adopting *Terry's Tips* and *In re Weiss Research*; held below 5 only because it is a state intermediate court construing the Colorado Securities Act.
- **Application note — and the distinction is real and load-bearing.** *Rome* is the case a sceptical reader will reach for, so it must be stated at full strength and then distinguished precisely. **At full strength:** a follower who could exclude named securities and cap position size still could not defeat adviser status, and the court called the tailoring question "immaterial." **The distinction:** the fact the court actually relied on is absent from the configuration and its absence is architectural, not cosmetic. Ditto Trade executed "**without need for further instruction or approval**," and followers were "**often not aware of the trades until after they have occurred**." The configuration inverts both: the member is shown **the complete composed order** on a runtime-owned approval surface rendered in the signed runtime's own process, and **nothing is transmitted without one explicit tap or swipe** that mints an immutable instruction record bound to the exact displayed terms. Awareness before the fact and approval before the fact are the two facts *Rome* found missing. **What the configuration cannot take from *Rome* is any comfort from the member's exclusions and caps** — the follower in *Rome* had those, and they counted for nothing once discretion was found. Note finally the ¶ 33 holding, which is the closest state-law analogue to *Ranieri Partners* already in the register: a compliant publication alongside a non-compliant service does not launder the service.

---

### S3-28 · Commodity Trend Service, Inc. v. CFTC, 233 F.3d 981 (7th Cir. 28 Nov. 2000) · official reporter text at https://static.case.law/f3d/233/html/0981-01.html · **independently retrieved and verified by this track's author, 7 Sep 2026**

- **Type:** court opinion (US Court of Appeals, Seventh Circuit)
- **Date / status:** Good law.
- **Verbatim quote, pin-cited:**

> "However, at least two reasons exist for deciding that the word 'client' in the CEA is not limited to personalized relationships or brokers. **First, the CEA has a broader scope than the IAA.** In *Lowe*, the Supreme Court held that impersonal advisors are excluded from the key definition of 'investment adviser' ('IA') in the IAA because they fit within the exception for publishers. 15 U.S.C. § 80b-2(a)(11)(D); 472 U.S. at 206. While some persons are excluded from the definition of an IA only if their advice concerning securities is solely incidental to their other activities, **the exception[] for publishers is not so limited.** 15 U.S.C. § 80b-2(a)(11). **Thus, bona fide publishers are not IAs even if their entire business concerns giving impersonal securities trading advice. Moreover, because impersonal advisors are excluded from the definition of IAs, they are wholly exempt from the IAA** because the antifraud and other provisions of that Act apply only to IAs. **By contrast, the CEA exempts publishers from the definition of CTA only if their giving of advice concerning the commodities markets is solely incidental to their publishing business.** 7 U.S.C. § 1a(5). **Impersonal publishers such as CTS … are included within the definition of CTA, even though an analogous publisher would be excluded from the definition of IA.**"
> — 233 F.3d at 988 (emphasis added)

> Footnote 1, at 995: "The CFTC originally appealed the district court's decision that the registration requirements of § 6m are unconstitutional as applied to CTS, **but voluntarily dismissed that appeal.** The CFTC has recently adopted a rule exempting from registration CTAs that do not direct client accounts and provide only impersonal trading advice. 17 C.F.R. § 4.14(a)(9)."

- **What it establishes:** **A federal appellate court holding that the CEA is broader than the Advisers Act on precisely the axis this track has been working**, because the Advisers Act's publisher exclusion is **not** qualified by "solely incidental" while the CEA's is. Impersonal advice that makes a person a CTA would **not**, on this reasoning, make an analogous publisher an investment adviser.
- **Q1:** **SUPPORT — and it is the most structurally important support in the file, because it changes the weight of every CEA entry.**
- **Level 4** — reasoned federal appellate holding on the relationship between the two statutes; held below 5 because the statement is made in construing the CEA's antifraud reach, and because it describes the *publisher* exclusion, whose availability to the configuration is a separate question this track does not decide.
- **Application note — this requires a downward revision of the CEA line's weight against Q1, and I am making it explicitly.** This file's headline adverse authority, *CFTC v. Donelson* (S3-14), and its supporting cast — *Hall* (S3-15), *R&W* and *Taucher* (in P7), *Vartuli*, and CFTC Letters 03-26 and 09-27 — are **all CEA cases**. *CTS* says, in terms, that the CEA reaches impersonal advisers **because its publisher carve-out is narrower than the Advisers Act's**, and that "an analogous publisher would be excluded from the definition of IA." **The consequence for the register: the CEA line cannot be transplanted to Q1 without confronting this holding.** What survives transplantation is *Donelson*'s **factual** observation — that customer confirmation of each trade did no work — which is an observation about which facts a tribunal found salient, not a statutory holding. What does **not** survive is any inference that because impersonal signal vendors are CTAs, they are therefore investment advisers. **This is the single largest correction this sweep produced, and it runs in the configuration's favour.** It does not decide anything: whether the configuration is a "bona fide publisher" within § 202(a)(11)(D) is a different question, on which *Lowe* (already in the register) is the authority and on which the configuration's per-member, per-instrument, timed output is materially unlike a newsletter.

---

### S3-29 · SEC v. Pirate Investor LLC, 580 F.3d 233 (4th Cir. 2009) · official reporter text at https://static.case.law/f3d/580/html/0233-01.html · **independently retrieved and verified by this track's author, 7 Sep 2026**

- **Type:** court opinion (US Court of Appeals, Fourth Circuit)
- **Date / status:** Good law. Liability under § 10(b) affirmed on other grounds.
- **Verbatim quotes, pin-cited:**

> "Appellants sold investment advice; **ultimately, the decision to purchase securities rested squarely with those who received the solicitation** and USEC Special Report."
> — 580 F.3d at 247 (emphasis added)

> "Indeed, we believe that **the lack of a trading relationship serves to distinguish this case from one of the cases relied on by the SEC and the district court, *SEC v. Terry's Tips, Inc.*, 409 F. Supp. 2d 526 (D. Vt. 2006).** Like Appellants, the defendant in *Terry's Tips* was an online financial advisor who made trading recommendations. Significantly, however, the SEC's case against the defendant in *Terry's Tips* revolved around misrepresentations relating to the defendant's provision of **auto-trading** services. In an auto-trading arrangement, subscribers authorize an online financial adviser to direct trades on their behalf — the customers often are not aware of the trades until after they have already occurred. **In such a scenario, the adviser is no longer merely a purveyor of information to investors who can choose to invest or not invest. Rather, in such a relationship investors explicitly delegate their decision-making authority to the online investment advisor**; the parties' relationship becomes one that would necessarily contemplate trading in securities. **The parties in this case contemplated no such arrangement.**"
> — 580 F.3d at 247-48 (emphasis added)

- **What it establishes:** A federal appellate court drawing the dividing line **between a "purveyor of information to investors who can choose to invest or not invest" and investors who "explicitly delegate their decision-making authority"** — and placing *Terry's Tips* on the delegation side **because of auto-trading**.
- **Q1 / Q3:** **SUPPORT, and it modifies an authority already in the register.**
- **Level 4** — published federal appellate opinion; the passage is reasoning distinguishing a case relied on below, not a holding on adviser status.
- **Application note — this changes how *Terry's Tips* reads.** P7's register carries *SEC v. Terry's Tips* (with *Park*) for the "menu of nine" line. **The Fourth Circuit has since read *Terry's Tips* as an auto-trading case** — i.e. as resting on subscribers who "authorize an online financial adviser to direct trades on their behalf" and who "often are not aware of the trades until after they have already occurred." On that reading *Terry's Tips* is materially further from the configuration than its unqualified citation suggests, because the configuration's member is aware of and approves each order before transmission. Note the symmetry with S3-27: *Rome* cites *Terry's Tips* for the **same** auto-trading description and reaches the adverse result on the delegation side of the line. **The two cases together locate the line, and they locate it at awareness-and-approval before the trade — not at who configured the tool.** That is the axis on which the configuration's approval surface does its work, and it is the axis on which *Rome* is distinguishable.

---

### S3-30 · Risley v. Universal Navigation Inc., 690 F. Supp. 3d 195 (S.D.N.Y. 29 Aug. 2023), aff'd, No. 23-1340-cv (2d Cir. 26 Feb. 2025) (**summary order — non-precedential**) ◇ *(quotes taken from the research assistant's retrieval of the district-court docket and the summary order via the RECAP archive; **not independently re-opened by this track's author**)*

- **Type:** court opinion (federal district court, affirmed by non-precedential summary order)
- **Date / status:** Dismissal affirmed. **The appellate disposition is a summary order and carries no precedential weight in the Second Circuit.**
- **Verbatim quotes, pin-cited:**

> "**The smart contracts are simply standardized computer codes that allow the Protocol to fill in the terms for individual trades between and controlled by its users.**"
> — 2d Cir. summary order at 9 ◇

> "[T]he core and router contracts at issue here write foundational code that executes a constant formula across the Protocol — **the formula merely differs based on the inputs** (that is, the pairs in a given pool)."
> — 690 F. Supp. 3d, Dkt. 90 at 32 ◇

> "**[I]t defies logic that a drafter of computer code underlying a particular software platform could be liable under Section 29(b) for a third-party's misuse of that platform.**"
> — 690 F. Supp. 3d, Dkt. 90 at 31 ◇, adopted at 2d Cir. summary order 10

- **Q2:** **SUPPORT.** Software whose output "merely differs based on the inputs," with trades "controlled by its users," did not generate broker-dealer or exchange liability through Exchange Act § 29(b).
- **Level 2** — a district-court dismissal affirmed by a **non-precedential** summary order, in a private § 29(b) rescission action rather than an SEC registration proceeding, and in a crypto/DeFi setting.
- **Application note:** The phrase "the formula merely differs based on the inputs" is the closest judicial articulation located to the configuration's engine layer — a fixed rule whose output varies only with member-supplied inputs. But the weight is low and must not be overstated: non-precedential, private-plaintiff, and about a permissionless protocol with no membership, no credentials and no per-order surface. Flagged ◇ because I did not re-open the docket myself.

---

## Adverse register

| # | Authority | Threat 1–5 | Does the configuration distinguish it? (blunt) |
|---|---|---|---|
| S3-14 | **CFTC v. Donelson (Long Leaf), No. 23-1809 (7th Cir. 5 Sept. 2024)** | **5** | **Only partly, and not on the fact that matters.** The customer confirmed *every* trade and it counted for nothing. The configuration distinguishes it on **content** (Long Leaf "recommended transactions"; the configuration highlights nothing, picks nothing, ranks by neutral labels) and on **compensation** (per-trade commission vs flat monthly membership). It does **not** distinguish it on user control, per-order approval, or the vendor's absence from the execution decision — those facts were present in *Donelson* and were passed over. Anyone whose argument leans on the member's tap is leaning on the discarded fact. |
| S3-01 | **17 C.F.R. § 275.203A-2(e)(2)** (internet adviser exemption definition) | **5** | **No.** A codified Commission rule defines software output "based on personal information each client supplies" as *investment advice*. The configuration can say its member supplies the **decision rule** rather than **facts about himself**, and that is a real textual difference — but **no located authority draws that distinction**, and the rule's structure treats client-supplied inputs as constitutive of advice, not exculpatory. |
| S3-12 | **Fiduciary Interpretation, 84 FR 33669 (2019)** | **5** | **No.** "[T]he relationship in all cases remains that of a fiduciary to the client." Client-set parameters narrow *scope of duties*; they do not change *what the actor is*. This is the cleanest statement of the pattern and it forecloses the intermediate move. |
| S3-02 | **89 FR 24693 (2024 adopting release)** | **5** | **No.** The Commission re-adopted this construction in 2024 and drew its line at software-generated vs human-directed — an axis orthogonal to user configuration. It had the occasion to carve out user-configured tools and did not. |
| S3-07 | **Reg BI adopting release, 84 FR 33318** | **4** | **Partly.** "[S]ome 'control' should not absolve the broker-dealer" is adverse; the self-directed/unsolicited carve-out is supportive. Reconciled by the recommendation inquiry — which turns on **specificity about a particular security**, where a `{instrument, side, fired_at}` signal sits at the adverse end (fn.182). |
| S3-06 | **Solely Incidental Interpretation, 84 FR 33681** | **4** | **Two-edged; do not cite it one-sided.** Item (vii) ("specific parameters established by the customer") and item (i) (price/time on a definite order) are the configuration's envelope almost verbatim — **but the Commission calls them investment discretion**, merely temporary or limited. Adverse to the Q3 claim that no discretion exists at all. And the whole interpretation is available only to a **registered broker-dealer**. |
| S3-16 | **CFTC Staff Letter 03-26 (2003)** | **3** | **No, on its key sentence.** Registration required "even if the CTA is not authorized to effect transactions without the client's specific authorization." Per-transaction client authorization expressly held insufficient. Distinguishable on per-trade commission and solicitation, both present there and absent here. |
| S3-23 | **FINRA Rule 2111(b)** | **3** | **No — the structure is the problem.** Where an SRO wanted to give effect to customer independence it did so expressly and **confined it to institutional accounts**. Second instance of this pattern after *S3 Matching Technologies*. The configuration is retail. |
| S3-03 | **IM Guidance Update 2017-02** | **3** | **No.** The one place a regulator addresses "the client chose it himself" in automated advice, the answer is that the adviser should *add* commentary — obligations increase, not lapse. Weight raised by the Commission's citation of it at 84 FR 33669 n.27. |
| S3-15 | **CFTC v. Hall, 49 F. Supp. 3d 444 (2014)** | **3** | **Partly.** Flat monthly subscription fee did not save him — the CTA definition does not care about the form of compensation. Distinguishable because Hall admitted **directing accounts**, which the configuration does not do. |
| S3-17 | **CFTC Staff Letter 09-27 (2009)** | **3** | **No.** "[T]he CTA definition is not dependent on whether a person provides advice on a discretionary basis." Who pulls the trigger is not the test. CEA, staff-level. |
| S3-10 | **Rafael Pinchas, 54 S.E.C. 331 (1999)** + *Follansbee*, 681 F.2d 673 (9th Cir.) | **3** | **Yes, on the stated ratio.** The defence ("the customers ordered him, or gave him permission") was expressly made and rejected — but rejected on **customer incapacity to evaluate**, a fact absent from a member who writes his own thresholds. Note *Follansbee* is Ninth Circuit law, which governs Washington State. |
| S3-09 | **17 C.F.R. § 270.3a-4** | **3** | **No.** In the Commission's model-portfolio rule, client control is a **condition of a safe harbor for discretionary advisory programs** — never a reason a program is non-advisory. Note the proviso: client control there is *negative* (restrict/exclude), and the Commission did **not** require clients to be able to compel purchases. The configuration inverts this and no authority addresses the inversion. |
| S3-08 | **FINRA Rule 2214** | **3** | **No.** Applies "whether customers use the member's tool independently or with assistance from the member" — three times. Independent customer operation makes no difference to the rule. Limited: a disclosure rule presupposing a member, imposing no status consequence. |
| S3-27 | **Rome v. Mandel, 405 P.3d 387 (Colo. App. 2016)** | **4** | **Yes, on the fact the court actually relied on — but not on configuration.** The follower could *exclude named securities* and *cap position size* and it counted for nothing: tailoring was "immaterial." What the court relied on was that execution occurred "without need for further instruction or approval" and followers were "often not aware of the trades until after they have occurred." **The configuration inverts exactly those two facts** — the complete composed order is displayed on a runtime-owned surface and nothing transmits without an explicit per-order act. **Take no comfort from the member's own exclusions and caps; the *Rome* follower had both.** |
| S3-26 | **PDA proposing release, 88 FR 53960 at 53972 and 53977-78** (WITHDRAWN) | **2** | **Largely, but note the structure.** Withdrawn, so no force. Its adverse limbs treat customizability as generating a **firm-side** diligence duty ("through the choices it makes when customizing the technology") and an investor's request to restrict the technology as a **recordkeeping artefact** (53997) — never as an investor-side answer. But 53972's qualifier is "**tailored** investment recommendations," the same tailoring axis as S3-20, not a who-configured-it axis. **The same release's 53975 is the strongest supporting passage in the track.** Cite it whole or not at all. |
| S3-24 | **In re Betterment LLC, IA-6288 (2023)** | **3** | **Not on the fact that matters, and this one is factual rather than legal.** "[F]or at least 150 accounts, TLH was disabled although clients had enabled it." The client's own switch was defeated for nearly three years by the vendor's code. The configuration's journal, policy versioning and pre-trade approval surface are exactly the controls that would surface such a divergence — but the configuration **cannot claim member control is self-executing**; it is a property of company-maintained code. |
| S3-19 | **NFA Interpretive Notice 9055** | **2** | **No, by omission.** Customer selection of a system and restriction to "signals that meet particular parameters" relieves the **intermediary**; for the **developer**, status "still depends on the particular facts of each case." Also supplies a commercial-pressure channel (Bylaw 1101) with no securities-law analogue. |

## Direct answers

### A · Is there any authority anywhere in which a defence resting on user configuration **succeeded**?

**The answer must be split by question, and the earlier single-word answer in this file was too blunt.**

**On Q1 (ADVISER status) — No.** No court, no Commission, no ALJ and no SRO tribunal has ever accepted a defence resting on user configuration as an answer to investment-adviser or commodity-trading-advisor status. Where it was squarely put, it was squarely rejected: *Rome v. Mandel* (S3-27, tailoring "immaterial" where the follower could exclude securities and cap size), *CFTC v. Hall* (S3-15), *CFTC v. Donelson* (S3-14), *Rafael Pinchas* (S3-10).

**On Q2 (BROKER status) — Yes, twice, and the register already holds one of them.** But both succeeded on a theory of **user control at the moment of the transaction**, not on user *configuration* of a rule beforehand:
- ***SEC v. Coinbase, Inc.***, No. 23 Civ. 4738 (KPF) (S.D.N.Y. 27 Mar. 2024), Dkt. 105 at 82-83 — already in P7's register for the Wallet holding. The § 15(a) claim as to Wallet was **dismissed**: "Coinbase has no control over a user's crypto-assets or transactions via Wallet, which product simply provides the technical infrastructure for users to arrange transactions on other DEXs in the market. … **Only a user has control over her own assets, and the user is the sole decision-maker when it comes to transactions.**" ◇ *(quoted from the assistant's RECAP retrieval; not re-opened by this track's author — but the holding is already independently in the register from P7.)*
- ***Risley v. Universal Navigation*** (S3-30) — same theory, weaker vehicle (non-precedential summary order).

**The distinction that decides this, and it is not a quibble.** In *Coinbase Wallet* and *Risley* the user **held the keys, chose the venue, and made each decision**; the vendor had no control at the moment of the trade. That is a **custody-and-control** theory. It is not the proposition that a user who *pre-set the rule* thereby removes the vendor from the definition. **No decision anywhere holds that.** The configuration's Q2 posture shares a great deal with the *Coinbase Wallet* facts — credentials only in the member's local vault, orders through the member's own broker under his own credentials, no company-level trading credential, no routing or venue selection, no netting or batching — and that is why the Wallet holding already sits in the register as support. **Its Q1 posture shares nothing with them, because neither case was about advice.**

**And note what *Coinbase* tells us about *GEL Direct*** (already in the register as adverse). *Coinbase* distinguishes *GEL Direct Trust* expressly, and in doing so names what tipped it: the *GEL Direct* complaint alleged the defendant "'**exercised discretion**' and '**provided trading instructions on behalf of its customers**,' including directives on '**price and volume**'" (Dkt. 105 at 82 ◇). Also at fn. 20: "**Facilitation or bringing together parties to transact, however, is not enough to warrant broker registration under Section 15(a).**" That materially narrows *GEL Direct*'s reach — it was a discretion-and-instructions case, not a mere-facilitation case.

**But the honest answer is not a bare "no," and the qualification is the most valuable thing in this track.** Two *non-adjudicative* documents come close, both on the commodities side, and they are of very different quality. Taken in ascending order of worth:

- the **Nadex Advisory Notice** (S3-18) — a derivatives exchange's self-certified advisory, undercut by a Commissioner's dissent, and resting on *origin* rather than configuration; and
- the **Rule 4.14(a)(9) adopting release** (S3-20) — **a Commission rulemaking document**, currently in force, in which a user's own selection is expressly held not to make the resulting advice "tailored." This one was found only on independent verification and is stronger than anything previously in the register on this point.

Neither is a "yes," and the reason both fall short is the same reason that runs through Direct Answer B: each concerns **what the vendor must do** (register, or not), never **what the vendor is**. Detail follows.

**The near-miss, stated at its highest and then read honestly (S3-18).** The **Nadex Advisory Notice 2015_01**, deemed certified by the CFTC effective 15 Dec. 2015 under CEA §5c(c)(1) and Rule 40.6(a), says that a technology provider submitting orders "based upon those signals **and parameters customized by the trader** is not likely required to register with the CFTC as a CTA." That is the only sentence located in the whole of P8 Track 3 in which a user-configuration fact appears in a conclusion favourable to a vendor. Four things must be said about it, none of which can be softened:

1. It is a **derivatives exchange's own advisory**, self-certified. "Deemed certified" means the Commission did not stay it. It is not a Commission interpretation, not a staff letter, not an adjudication, and it binds no one.
2. It is **CEA**, not securities law.
3. Commissioner Pham stated in a **dissent** on 29 Aug. 2023 that the Commission had, in the *SignalPush* consent order, "for the first time since the Nadex Advisory Notice … chang[ed] this interpretation." **The dissent did not carry**, and the majority issued no reasoned document either adopting or repudiating the notice. I verified the *SignalPush* consent order in the primary PDF: it contains **zero** occurrences of "select," "choose," "parameters," "customiz" or "originate." The Commission neither applied nor distinguished the Nadex line; it simply did not engage it.
4. **Most important — the Nadex sentence does not rest on configuration.** Its stated reason is origin: "**as the trade advice does not originate from the technology provider**," the technology "merely facilitat[ing] the flow of information between the signal provider, the trader, and the Exchange." The customization clause describes the technology's behaviour; the because-clause is that the advice came from *someone else*. On its own words the notice protects a **conduit for a third party's advice** — structurally the configuration's *runtime*, not its *engine*, which originates the signal.

**The strongest supporting text, found on verification, and why it still is not a "yes" (S3-20).** The Rule 4.14(a)(9) adopting release, 65 FR 12938 (10 Mar. 2000) — the CFTC's own post-*Taucher*, post-*R&W* rulemaking — contains at Example C a website on which **the user's own indicated preference determines which advice he receives** ("[u]sers who indicate that their preference is agricultural futures contracts receive different advice from those who indicate that financial futures contracts are their preference"), and holds that the advice is **not** "based on, or tailored to" the client's circumstances because "the CTA is **merely allowing its clients to select which advisory services they wish to purchase.**" Example E goes further: the vendor *polls* the users and *adapts its output to them*, and the advice is still not tailored. **This is the only official agency document located anywhere in P8 Track 3 in which a user's own selection is expressly held not to make the resulting output tailored, and it went the vendor's way.**

It is still not an answer of "yes" to Framing Question A, for a reason that is structural rather than quibbling: **Rule 4.14(a)(9) is an exemption from *registration* for persons who *are* commodity trading advisors.** Footnote 15 of the release says so in terms — each CTA in the examples "remains subject to requirements of the Act and the Commission's regulations that apply to all CTAs **without regard to registration**," including §4o. So the release does not hold that user selection means the vendor is not an advisor; it holds that an advisor whose advice is not tailored to particular clients' positions need not register. Footnote 14 adds that the examples are "illustrative and not intended to be statements of law." And the Advisers Act has **no counterpart to Rule 4.14(a)(9)** — the configuration cannot import it.

**The other apparent success is not one (S3-21).** In *CFTC v. Wall Street Underground*, 281 F. Supp. 2d 1260, 1268 (D. Kan. 2003), the court held "[t]here is no evidence in the record to support a finding that defendants Web and Asaro acted as CTAs." That succeeded because "[n]either defendant Web nor its employees made specific buy and sell recommendations to clients" — **a no-recommendation holding, not a user-configuration holding.** In the same case the system's authors *were* held to be CTAs.

**Two partial wins, neither on this ground.** *Taucher v. Born* won constitutional as-applied relief while **losing** the statutory point at *475 (already in P7's register, and now reconfirmed by the Seventh Circuit in *Donelson* — see below). *Donelson* itself had the §6m(1) registration count **vacated and remanded**, but on the Reg. 4.14(a)(6) introducing-broker exemption, a question of statutory text about IB business with nothing to do with user configuration.

**What this means for the register.** Across every forum searched — federal courts, SEC administrative proceedings and Commission opinions, CFTC enforcement and staff letters, NFA, FINRA rules, and state listings — **no tribunal has ever accepted "the user configured it" as an answer to ADVISER status, and the only broker-status successes rest on user control of keys and decisions at the moment of the trade rather than on prior configuration.** It has been raised expressly and rejected at least three times in terms (*Pinchas*, *Hall*, *Donelson*), and passed over in silence where it was structurally present (*Donelson*'s per-trade customer confirmation; *SignalPush*'s customer-side configuration). Its absence from the win column is documented, not inferred: the searches and endpoints are at "Negative findings" and "Search log" below.

**One honest qualification that runs the other way.** The absence of a *success* is not the same as a body of *considered rejections*. In most of these matters the argument lost alongside facts the configuration does not share — per-trade commissions, solicitation, actual recommendations, account direction, customer incapacity. **No decision located anywhere has squarely confronted, and rejected, a vendor whose user wrote the decision rule itself, took no per-trade compensation, made no recommendation and directed no account.** That question remains open in the sense that nobody has answered it — which is the same gap Q1 already records, now confirmed from the adverse side.

### B · Is there a pattern in which fact does the work?

**Yes, and it is consistent across every forum searched. Stated factually, as a description of the cases, not as a legal conclusion:**

**The operative fact is almost never who configured the tool. It is one of four things, in this order of frequency:**

**1 · The specificity and content of the communication — whether it identifies a particular security.** This is the dominant axis and it appears in every corpus.
- Reg BI: exclusions apply "as long as they do not include … a recommendation of a **particular security or securities**"; and "the more individually tailored the communication … about a security or group of securities, the greater the likelihood" (84 FR 33318 at 33335, 33337-38); fn.182: "as an allocation recommendation becomes narrower or more specific, the recommendation gets closer to becoming a recommendation of particular securities."
- FINRA Rule 2111.03: same formulation.
- *Wall Street Underground*: the parties who "made [no] specific buy and sell recommendations" were not CTAs; the system's authors were.
- *Donelson*: liability rests on Long Leaf having "recommended transactions to consumers."
- CFTC Rule 4.14(a)(9) and its adopting release: the exemption axis is **tailoring** — "based on, or tailored to, the … positions or other circumstances or characteristics of particular clients."
- Already in the register and consistent: NASD NTM 01-23's "content, context, and manner of presentation"; *Weiss Research*'s signals that "often only identify the investment."

**2 · Compensation — its presence, and in the securities line its transaction-based character.** *Donelson* (per-trade commission); *Neovest* (already in register); CFTC Letter 03-26 (per-trade commissions as an AP). Note the counter-instance that must be recorded: in the **CEA** line the *form* of compensation is expressly irrelevant — *Hall* (flat monthly subscription, still a CTA) and CFTC Letter 09-27 ("[n]or is it dependent on compensation being received from … a discretionary basis or the results of the performance"). **The flat-fee structure is a stronger card under the Exchange Act than under the CEA.**

**3 · The customer's capacity to evaluate — not the customer's formal control.** *Pinchas*: the defence that the customers "ordered him, or gave him permission" failed because Wang could not read English and Schimel had elementary-school arithmetic. *Follansbee*, 681 F.2d at 676-77 (9th Cir.): control exists where the customer "is unable to evaluate his recommendations and to exercise an independent judgment." **FINRA Rule 2111(b)** codifies the same variable from the other direction — relief requires that the customer be "capable of evaluating investment risks independently" **and** affirmatively say so. So does *S3 Matching Technologies*. **Both codified reliefs are confined to institutional customers.**

**4 · Whether the advice originated with the vendor.** This is the axis on which the *only* favourable text turns: Nadex's "as the trade advice does not originate from the technology provider." It also underlies the internet-adviser rule's "generated by the operational interactive website's software-based models."

**What the pattern is NOT.** It is not personalization simpliciter — *Donelson* holds flatly that "[e]ven if *Taucher* or *AVCO* drew a line between personal and impersonal advice, **the text of the statute does not**." It is not timing alone — that was *R&W*'s ground but nothing since has repeated it. It is not the presence or absence of discretion — CFTC Letter 09-27 says so expressly, and the Solely Incidental Interpretation treats customer-parameter-bounded action as *a species of* discretion rather than its absence. And it is emphatically **not who supplied the inputs**: where regulators addressed client-supplied inputs at all, they wrote them into the *definition* of the regulated activity (§ 275.203A-2(e)(2)), made them a *condition* of a safe harbor for admittedly advisory programs (Rule 3a-4), made them *irrelevant* to a tool rule's application (FINRA Rule 2214's "whether customers use the member's tool independently"), or held that they change *scope of duty* but not *status* (84 FR 33669).

**5 · Added after the court sweep — the sharpest formulation, and it subsumes much of the above.** Read across the *decided cases* specifically (as distinct from the rules and releases), the sentence the outcome turned on was almost always about **who moves the money at the moment of the trade**, not about who configured the box beforehand:
- *Rome v. Mandel*: the follower could exclude tickers and cap size, yet the vendor was "effectively exercising discretion," execution occurred "without need for further instruction or approval," and followers were "often not aware of the trades until after they have occurred" → licence required, tailoring **"immaterial."**
- *Coinbase* (Wallet): the user holds the key, picks the venue, and is "**the sole decision-maker when it comes to transactions**" → not a broker.
- *Risley*: code "fill[s] in the terms for individual trades **between and controlled by its users**" → not liable.
- *Hall*: "at no time did [he] give advice that was tailored to even one individual" did not save him — **because he directed accounts.**
- *Pirate Investor*: the line is drawn between "a purveyor of information to investors who can choose to invest or not invest" and investors who "**explicitly delegate their decision-making authority**."
- *Wall Street Underground*: order acceptance, payment collection and FCM referral did not make a CTA — **absence of specific buy/sell recommendations did.**

**The one-sentence version.** Across every matter located, **user configuration has never been the fact that decided anything. What decides is what the output says about which security and on what side, whether the vendor or the user is the one acting at the moment of the trade, what the vendor is paid, and whether the customer could evaluate what he was told.** The configuration's per-order approval surface goes to the second of those; its neutral, unhighlighted, un-picked presentation goes to the first; its flat fee to the third. **The `side` field in the signal is the unresolved element of the first, and no located authority resolves it.**

### C · The brief's subject-area questions, answered one by one

- **Stock and fund screeners / screening tools:** No enforcement action, court decision or adjudication located in any forum. CourtListener returned **COUNT 0** for `"stock screener" "investment adviser"` and **COUNT 0** for `"screening tool" "investment adviser" registration`. The only governing texts are FINRA Rule 2214 (S3-08) and NASD NTM 01-23 (already in register). See NF-5.
- **Alert services / price-point alerts:** **No adjudication located anywhere** — and this is now the best-supported line in the track. NASD NTM 01-23 fn.18 (already in the register) remains the only authority and it is favourable. **It is now corroborated at Commission level by S3-26**: in 88 FR 53975 the Commission described an investor-signed-up-for, investor-**customizable** alert keyed to the securities on the investor's own **watch list** as having "generally been viewed as outside the scope of 'recommendations'," cited NTM 01-23 twice for it, proposed a new rule to capture such communications — **and that rule was withdrawn on 17 June 2025.** The Commission thought it needed new rulemaking to reach a customer-configured alert and does not have it. **The unresolved variable is the `side` field**: the Commission's example is an alert about *news affecting* a security, not a buy/sell direction, and NTM 01-23's price-point holding is expressly "without more." No located authority says whether a side is "more."
- **Robo-adviser onboarding questionnaires:** Fully worked at S3-03, S3-04, S3-05, S3-22, S3-24, S3-25, the rule at S3-01/S3-02, and the complete 2022-2026 enumeration at NF-11. **Answer to the brief's framing:** on the face of every order, the client controlled *only his own answers*, plus in *Wealthfront* some "client directed transactions" and in *Betterment* a single on/off election; the vendor controlled the questionnaire, the model, the allocation, the rebalancing, the discretion — **and the code that reads the client's election.** **Not one of the eleven actions in the window turned on a configuration fact, and not one contested adviser status; every respondent was already registered.** *Wealthfront* and *Hedgeable* turned on false statements; *Schwab* on an undisclosed conflict in a **vendor-set** parameter; *Fair Invest* on a personalization claim that was wholly false; *Betterment* on a client election the vendor's code silently defeated for three years. **The brief's prediction that this line is "the richest vein" for a user-configuration defence is not borne out** — the line is being litigated on disclosure and service delivery, never on status. Its real contribution to P8 is S3-01: a codified rule whose definition of software-generated advice *presupposes* client-supplied inputs. **And the check on this is complete, not partial:** a full enumeration of 2,640 administrative-proceeding rows and 1,335 litigation releases found no thirteenth matter and no user-configuration defence anywhere in the period.
- **DIY tools / self-directed platforms / DEPs:** The DEP RFI (S3-11) asked and answered nothing; a complete variant-checked sweep confirms it never uses "parameters," "self-directed," "screener," "watch list" (any spelling) or "investor-directed" — see the surviving half of NF-2. **Correction to the earlier record: two rule proposals did come out of the RFI**, both citing File No. S7-10-21 — the **PDA proposal** (88 FR 53960, S7-12-23), **withdrawn**; and the **internet-adviser exemption proposal** (88 FR 50076, S7-13-23), which was **adopted** as 89 FR 24693 and is in force as S3-01/S3-02. So the DEP RFI's one surviving legislative product is the very rule that supplies this track's most adverse entry. The PDA proposal (S3-13) was withdrawn 17 June 2025 by 90 FR 25531; **its own text does contain Commission articulations of user choice** — at 53975, 53972, 53977-78, 53984, 53997 and 54007 — all at **S3-26**. See NF-1, NF-2 and its correction box.
- **Model-portfolio / strategist arrangements:** Rule 3a-4 (S3-09) is the governing instrument, and in it client control is a *condition* of a safe harbor for discretionary advisory programs. NFA IN 9055 (S3-19) is the commodities analogue and gives the customer-selection relief to the **intermediary**, leaving the developer's status open.
- **PDA proposal status:** **Confirmed withdrawn**, 17 June 2025, by **90 FR 25531** (doc. 2025-11110, Rel. Nos. 33-11377; 34-103247; IA-6885; IC-35635; File No. S7-12-23), the Commission stating it "does not intend to issue final rules" and that any future action requires "a new proposed rule." **Not on the forward agenda** (NF-2a). **Three dates appear on the face of primary documents and none reconciles with the Regulatory Flexibility Agenda's 04/21/25**: the withdrawal document is signed "Dated: June 12, 2025"; its DATES caption withdraws the proposals "as of June 17, 2025"; and the SEC's own rule page for S7-12-23 lists an issue date of June 12, 2025. **No primary document reconciling them was located, and none is guessed at here.** As to what survives the withdrawal: **materially more than the earlier draft of this file recorded** — see S3-26 and the correction box at NF-2.
- **CFTC/NFA parallel — what came after *R&W* and *Taucher*:** *Donelson* (7th Cir. 2024) is the answer and it is adverse (S3-14). Also *Hall* (S3-15), CFTC Letters 03-26 and 09-27 (S3-16, S3-17), Rule 4.14(a)(9) and its adopting release (S3-20), NFA IN 9055 (S3-19), and the Nadex/SignalPush/Pham cluster (S3-18). **Note for the register:** *Donelson* reconfirms P7's reading of *Taucher* at *475 and expressly labels the contrary reading a misreading — so *Taucher* has become **more** adverse since P7, not less.

---

## Negative findings

Each records where I looked, the endpoint, the query and the result. Absence is documented, never inferred.

**NF-1 · Nothing came of the DEP request for comment.** Federal Register API, `federalregister.gov/api/v1/documents.json` with `conditions[term]="digital engagement practices"` and `conditions[agencies][]=securities-and-exchange-commission`: **COUNT 8**. The eight are: three Sunshine Act meeting notices (89 FR 13774, 88 FR 84001, 88 FR 39274); the DEP RFI itself (86 FR 49067, 1 Sept. 2021); the PDA proposed rule (88 FR 53960); the internet-adviser exemption proposal and adopting release (88 FR 50076, 89 FR 24693); and the adviser cybersecurity proposal (87 FR 13524). **CORRECTED on a File-Number trace.** Searching by **File No. S7-10-21** rather than by subject term returns **3** SEC documents: the RFI itself (86 FR 49067); the **PDA proposal** (88 FR 53960, File No. S7-12-23) — **withdrawn**; and the **internet-adviser exemption proposal** (88 FR 50076, File No. S7-13-23) — **adopted**, final rule IA-6578, 89 FR 24693 (9 Apr. 2024), citing the RFI at 88 FR 50080 and again at 89 FR 24694.

**So the DEP RFI did produce law — one withdrawn proposal and one adopted rule — and the adopted one is S3-01/S3-02, the most adverse entry in this track.** An earlier draft of this file said the RFI "produced no rule"; that was wrong, and it was wrong because the sweep was by subject term rather than by File Number. The Commission describes the RFI's yield in its own words at 88 FR 53969-70: "The Commission received over 2,300 public comments, including submissions provided through an online 'feedback flyer' that accompanied the Request," and "[i]n view of Commission staff observations, our experience administering our existing rules … and comments received in response to the Request, we are proposing to update the regulatory framework …". **What remains true is that no rule addressing user-set parameters came out of it, in either direction.**

**NF-2 · Neither the DEP RFI nor the PDA proposing release addresses user-set parameters, in either direction.** Full-text term sweeps of the Federal Register raw text of each:

| Term | 86 FR 49067 (DEP RFI) | 88 FR 53960 (PDA proposal) |
|---|---|---|
| "parameters" | **0** | **0** |
| "self-directed" | **0** | **2** (both recitations of comment-letter positions, not Commission statements) |
| "user-defined" | **0** | **0** |
| "investor input" | — | **0** |
| "investor chooses" / "investor's choice" / "investor selects" | — | **0** each |
| "watchlist" / "watch list" | **0** / **0** | — |
| "investor-directed" | **0** | — |
| "screen" | **1** (unrelated) | — |
| "alert" | **4** (all citations to staff "Risk Alert" publications; none a price or condition alert) | — |

**NF-2a · The PDA proposal has not returned and is not on the forward agenda.** SEC Regulatory Flexibility Agenda 91 FR 53164 (14 Aug. 2026), full-text sweep: "predictive data analytics" **0**, "digital engagement" **0**, "artificial intelligence" **0**. Federal Register API, SEC documents mentioning "predictive data analytics" published on or after 18 June 2025: **COUNT 1**, and that one is the 2025 agenda item recording the withdrawal. See S3-13.

> ### ⚠ CORRECTION TO THIS NEGATIVE FINDING — recorded rather than quietly amended
>
> **An earlier draft of this file stated that "the brief's hypothesis that the PDA proposing release contains a surviving staff articulation about a user 'choosing' an output is not borne out. There is no such passage." THAT STATEMENT WAS WRONG, and the error was mine.**
>
> **Cause:** my phrase-level sweep searched `watchlist` as one word. **88 FR 53960 writes "watch list" as two words.** Re-running every spelling variant gives: `watch list` — **DEP RFI 0, PDA release 1 (at p. 53975)**; `watchlist` — 0 / 0; `watch-list` — 0 / 0. The same asymmetry holds for `electronic librar` (0 / 1, p. 53975) and `research page` (0 / 1, p. 53975).
>
> **What the miss cost:** the single most on-point passage in this track for the alert line — 88 FR 53975, now at **S3-26**, in which the Commission describes an investor-signed-up-for, investor-customizable, watch-list-keyed alert as having "generally been viewed as outside the scope of 'recommendations'." **It runs in the configuration's favour**, so the error was suppressing a supporting finding, not an adverse one — but the direction is irrelevant to the fact that a documented negative was stated on an incomplete sweep.
>
> **Methodological lesson for the register:** a phrase-level term sweep is only as good as its orthography. Where a negative finding is going to be *relied on*, run **spelling and spacing variants** (`watch\s*-?\s*list`), and read the semantic-neighbourhood hits rather than only the exact phrases. My original sweep of 88 FR 53960 counted "choice" 9, "choose" 6, "select" 13, "customize" 2 **and did not read them** — that is where the finding was hiding.
>
> **Corrected consequence, on a complete sweep:** the PDA proposing release **does** contain Commission articulations bearing on user choice and user customization — at **53975** (supportive, above), **53972**, **53977-78**, **53984**, **53997** and **54007**, all set out at S3-26 and all independently verified verbatim and page-located. Of the 36 `choic*/choos*/select*/customiz*` hits in the release, **five are Commission articulations and thirty-one are noise** (cited literature, document titles, footnotes, or the *firm's* discretion rather than the investor's). The "self-directed" ×2 finding stands as originally recorded: both are at p. 53970 and both are the Commission summarizing commenters, not Commission text.
>
> **Also corrected, against the same primary text:** a report to this track stated that "investment analysis tool" appears **7 times** in 88 FR 53960 at pp. 53966, 53972 and 54004. **It appears 3 times, on 2 lines (both near p. 54004), plus the phrase at p. 53972.** And a quoted passage attributed to p. 54002 beginning "investors are free to choose a firm…" **could not be located: `free to choose` returns 0 occurrences in the release.** That passage is **not** relied on anywhere in this file. Both corrections were caught by checking the retrieval against the primary text.

**The DEP RFI negative finding, by contrast, SURVIVES the corrected sweep and is extended.** Over the full 21 pages of 86 FR 49067 (49067-49087, all page markers verified present): `screener` **0**; `watch list` / `watchlist` / `watch-list` **0** in every variant; `investment analysis` **0**; `investor-directed` **0**; `self-directed` **0** in Commission text; `parameters` **0**; `electronic library` **0**; `research page` **0**; `alert*` **5**, all five citations to staff Risk Alerts at p. 49085. **The DEP RFI genuinely does not discuss screeners, watchlists, price alerts or investor-directed features by those names, in either direction.**

**NF-3 · The internet-adviser exemption's enforcement history runs the opposite way from a user-configuration defence.** Every matter collected in 89 FR 24693 n.25 — *In re Boveda Asset Management, Inc.*, IA-6016 (6 May 2022); *Ajenifuja Investments, LLC*, IA-5110 (12 Feb. 2019); *Strategic Options, LLC*, IA-5689 (24 Feb. 2021); *In re RetireHub, Inc.*, IA-3337 (15 Dec. 2011) — is a case of an adviser found **ineligible for the exemption because it was not automated enough** (no interactive website, or advice given outside it). **Not one is a case of a vendor arguing that user configuration removed it from adviser status.** The enforcement pressure on this rule is "you were not the algorithm you claimed to be," never "your users configured it, so you are not an adviser."

**NF-4 · No authority located anywhere addresses affirmative client selection of securities in a program.** Rule 3a-4(a)(3)'s proviso states that "nothing in this section requires that a client have the ability to require that particular securities or types of securities **be purchased** for the account." Client control in the Commission's model-portfolio rule is negative only — restrict, exclude, designate what must not be bought. The configuration inverts this: the member's own settings determine affirmatively which instrument qualifies and on which side. **No located rule, release, letter or decision addresses that inversion.** This is a genuine gap and it is not resolved in either direction.

**NF-5 · No court decision located anywhere connecting screening tools to adviser status.** CourtListener v4 `/api/rest/v4/search/?type=o`: `"stock screener" "investment adviser"` → **COUNT 0**; `"screening tool" "investment adviser" registration` → **COUNT 0**; `"watch list" "investment adviser" unregistered software` → **COUNT 0**. See also the parallel commodities-side zeros at NF-6.

**NF-6 · Multiple zero-result sweeps in the commodities line.** CourtListener v4, `type=o`: `"signal service" AND CFTC` → **COUNT 0**; `"automated trading system" AND "commodity trading advisor"` → **COUNT 0**; `"trade signals" AND "commodity trading advisor"` → **COUNT 0**; `"trading bot" AND "commodity trading advisor"` → **COUNT 0**. Citator sweep of *Vartuli*, `"228 F.3d 94"` → **COUNT 9**, all pre-2004 — **Vartuli has no modern progeny**. Citator sweep of *Taucher*, `"53 F. Supp. 2d 464"` → **COUNT 16**, of which the only post-2005 substantive citer is *Donelson* (S3-14).

**NF-7 · No CFTC action located against a crypto/algorithmic "trading bot" vendor on CTA registration grounds other than *SignalPush*.** CFTC press-release and site search sweeps: CFTC Rel. 8434-21 (14 platforms, 29 Sept. 2021, incl. "Smarter Signals") charged **FCM** registration failures, not CTA; Rel. 8976-24 likewise FCM. The 2024 Customer Advisory "AI Won't Turn Trading Bots into Money Machines" (PR 8854-24) is investor education and states **no registration position**.

**NF-8 · Washington State: topical search is not possible on the Division of Securities listing.** `dfi.wa.gov/securities-enforcement-actions` (HTTP 200, 47,335 bytes, retrieved 7 Sep 2026) exposes filters for **Order Type** and **Year** and a free-text box labelled "Search by respondent" — i.e. **respondent-field matching only**, the same limitation the shared context records for the SEC's listings. Orders for 2024 and earlier sit behind a separate "View enforcement actions from 2024 and earlier" link. **I could not topically sweep Washington orders for a user-configuration defence, and I do not assert that none exists.** *In re Solium* remains the Washington authority already in the register. `dfi.wa.gov/securities/enforcement-actions` (the URL given in some sources) returns **HTTP 404**; the working path is `/securities-enforcement-actions`.

**NF-9 · NFA disciplinary decisions could not be swept.** `nfa.futures.org/basicnet/` and the BASIC disciplinary search return HTTP 200 but are ASP.NET/JavaScript form applications; decisions are not full-text searchable over HTTP. **I did not sweep NFA Business Conduct Committee decisions for system-vendor CTA matters and make no claim about their contents.** NFA's *rulebook* was reachable and IN 9055 was retrieved from it (S3-19).

**NF-10 · No SEC Commission opinion or ALJ initial decision located in which a software or tool vendor raised a user-configuration status defence.** The Commission-opinion line I did reach (*Pinchas*, S3-10) is a **human broker** case; the defence there was "the customer ordered me to," not "the customer configured the software." **No matter located anywhere applies the de facto control doctrine to software**, in either direction — which parallels the shared context's record that no authority applies Exchange Act §3(a)(35) to software in either direction.

**NF-11 · Complete enumeration of SEC robo / automated-advice enforcement, 2022 – 7 Sep 2026, and what it does NOT contain.** A full sweep of the SEC's administrative-proceedings listing (2,640 rows) and litigation releases (1,335 releases) for the period yields **eleven** qualifying actions:

| Year | Actions |
|---|---|
| 2022 | *Wahed Invest* IA-5959; *Charles Schwab* 34-95087 / IA-6047 (S3-22) |
| 2023 | *Betterment* IA-6288 (S3-24); *Titan Global Capital Management* IA-6380 |
| 2024 | *Delphia (USA)* IA-6573; *Global Predictions* IA-6574; *Rimar Capital* 33-11316; *Wahed Invest II* IA-6763; *Fair Invest / Parekh* 33-11329 / IA-6776 (S3-25) |
| 2025 | *Two Sigma Investments / Two Sigma Advisers* 34-102207 / IA-6824 |
| 2026 (to 7 Sep) | *Ally Invest* IA-6954 |

**Not one of the eleven turns on a user-configuration fact, and not one contests adviser status.** Every respondent was a registered adviser. The grounds are: false or misleading advertising and Form ADV statements (*Wahed* ×2, *Schwab*, *Delphia*, *Global Predictions*, *Rimar*, *Fair Invest*), service defects and compliance-programme failures (*Betterment*, *Titan*), model-governance and fiduciary duty (*Two Sigma*), and custody/disclosure. **The "AI-washing" pair — *Delphia* and *Global Predictions*, both 18 Mar. 2024 — are claims-of-capability cases: the vice is overstating what the algorithm did, which is the opposite of the configuration's marketing rule (software tools, never a trading, execution or signal service).**

**Documented zero in the federal courts.** Across all **1,335** litigation releases 2022-2026, **"robo-advis*" appears 0 times.** Twenty-five releases mention algorithms, AI or automated trading; **all twenty-five are offering frauds or Ponzi schemes in which a fictitious algorithm was the marketing lure** (Ellison-Meade/Baycap, Tadrus Capital, ONPASSIVE, GenesisAI, Terraform's "algorithmic stablecoin," and others). **None involves a registered adviser delivering software-generated advice.** Consequence for the register: **the entire body of robo and automated-advice enforcement in this period sits in administrative proceedings, not in federal court** — so there is no judicial construction of any of it, and every entry in the robo line is a settled order whose findings are, by their own terms, "not binding on any other person or entity."

**Examined in primary text and excluded as non-qualifying:** *CMG Capital Management Group* IA-5945 (backtested-performance advertising; the algorithm is the strategy, not the advice channel); *Van Eck Associates* IC-35132 / IA-6560 (BUZZ NextGen AI US Sentiment Index ETF — finding turned on undisclosed influencer compensation, not the index algorithm); *Boveda Asset Management / Witherspoon* IA-6016/6017 and *Nashid Ali / Gainvest* IA-6600 (internet-adviser registration **eligibility**, not software-generated advice — consistent with NF-3); *Empower Advisory Group* 34-103809 / IA-6911 and *Vanguard Advisers* IA-6912 (human advisers; zero occurrences of "robo" or "algorithm" in the Vanguard order).

**NF-12 · Wealthfront (IA-5086) and Hedgeable (IA-5087) have not been cited in any SEC enforcement action since 2022.** Independent enumeration of the 2022-2026 corpus returns **zero** citations to either. Hedgeable appears **once**, and not as a citation: *Michael Ross Kane*, IA-6310, AP 3-21433 (18 May 2023), ¶ A recites that Kane "was also the President, CEO, and Head of Business for Hedgeable, Inc., Hydrogen's predecessor entity, which was registered with the Commission as an internet investment adviser from 2009 through December 2018" — a follow-on bar arising from a crypto market-manipulation judgment, which neither cites nor discusses the 2018 order.

**Precision notes for the register.** *Schwab* carries **only** 34-95087 and IA-6047 — **there is no Securities Act release number for it**; any citation with a "33-" number is wrong. *Wahed 2024* (IA-6763) **never uses the word "robo"** (zero occurrences) — it is a Marketing Rule action that happens to be against a robo firm, and should be kept distinct from IA-5959, which does characterize the business as a robo-adviser on its face.

**NF-13 · ⚠ CORPUS DEFECT — CourtListener's opinion index is incomplete, and every zero-count in this file must be read subject to this.** The court sweep established, by direct test, that **two of the most relevant modern decisions are absent from CourtListener's `type=o` (opinion full-text) index**:
- `"Coinbase" AND "Wallet" AND "broker"` → **COUNT 2**, and **neither is *SEC v. Coinbase***.
- `"smart contract" AND "unregistered" AND "broker"` → **COUNT 3**, and **none is *Risley***.

Both were obtained instead from the **RECAP archive on archive.org**. Separately, **SEC and CFTC administrative decisions are outside `type=o` entirely**, and CourtListener's own opinion *pages* are behind an AWS WAF challenge (reporter text was therefore taken from the **Harvard Caselaw Access Project static bulk archive**, `static.case.law`, which carries reporter page markers). **Consequence, stated plainly: every "COUNT 0" reported in this file — mine at NF-5 and NF-6, and the sweep's — is a zero in an incomplete corpus, not a zero in United States law.** The file's negative findings on screeners, alerts, robo-advisers and trading bots should be read as "not located in the sources searched, which are documented and are known to be incomplete."

**NF-14 · Whole subject-matter categories are empty of case law, on a wide sweep.** Across 18 mandated queries plus 45 self-added ones, the following returned zero or nothing on point: **stock screeners** (`"stock screener"` = 0 in the entire opinion corpus); **screening tools** (`"screening tool" AND "investment adviser"` = 0, against a calibration count of 420 for `"screening tool"` alone — the term is indexed, it simply never appears in adviser cases); **alert services** (= 0); **robo-advisers** (`"robo-adviser"`, `"robo adviser"`, `"roboadviser"`, `"robo-advisor"`, `"robo advisor"`, `"roboadvisor"` — **all 0; there is no robo-adviser case law in the corpus at all**); **AI advisers** (`"artificial intelligence" AND "investment adviser"` = 1, a Georgia auto-finance case); **copy/mirror trading** (= 1, a terrorism-financing case); **trading bots** (= 0); **expert advisors** (= 0); **black-box trading systems** (= 0); **gamification / digital engagement practices** (= 0). Calibration queries confirm the index is live and phrase search works (`"investment adviser"` = 1,721; `"investment advisers act"` = 813; `"unregistered investment adviser"` = 30; `Vartuli` = 107).

**NF-15 · The hypothesised defence phrasings do not exist in any opinion.** `"customer selected the criteria"` = **0**; `"we only provided the tool"` = **0**; `"merely a tool" AND "investment adviser"` = **0**; `"the customer made the investment decision" AND "investment adviser"` = **0**; `"non-discretionary" AND "unregistered investment adviser"` = **0**; `"ultimate decision" AND "unregistered investment adviser"` = **0**; `"algorithm" AND "investment adviser" AND "202(a)(11)"` = **0**; `"automated investment" AND "investment adviser" AND unregistered` = **0**. **Courts have never had to write these sentences, in either direction.** That is the strongest available statement of the gap Q1 records — the question has not been litigated, rather than litigated and lost.

**NF-16 · The *Vartuli* / *R&W* / *Taucher* citing universe is closed.** `"Vartuli" AND "investment adviser"` = **7**, the entire citing set being AVCO / CTS / R&W / Taucher. `"R & W Technical" OR "R&W Technical"` = **13**, citing universe CTS, Levy, United Investors Group, R.J. Fitzgerald, Tokyo Joe. `"228 F.3d 94"` = 9, **all pre-2004**. **No modern progeny.** The one post-2005 substantive citer of *Taucher* is *Donelson* (S3-14). *CFTC v. United Investors Group*, 440 F. Supp. 2d 1345 (S.D. Fla. 2006), was retrieved and is a telephone boiler room — off point.

**NF-17 · The auto-trading / lead-trader line is one appellate case deep.** `"lead trader"` = **4**, of which exactly **one** is a securities case (*Rome*). `"trading system" AND "unregistered" AND "investment adviser"` = **3**, two of them *Taucher*. **S3-27 carries essentially the whole load of that line, and it is a state intermediate appellate decision on state law.**

**NF-18 · Three leads could not be retrieved** — no free full text obtainable; CourtListener HTML is WAF-blocked and Justia/Leagle return HTTP 403: ***Sherter v. Ross Fialkow Capital Partners***, 31 Mass. L. Rptr. 98 (Mass. Super. 2013) — **the only hit for `"software" AND "unregistered investment adviser"`**, and therefore the most interesting of the three; ***Schneider v. Kansas Securities Comm'rs*** (Kan. App. 2017); and ***State v. Terry's Tips, Inc.*** (Vt. Super. 2005), a **separate state decision** from the federal case already in the register. All three are in the ◇ list.

## Search log

| # | Source / query | Endpoint | Date | Result / access note |
|---|---|---|---|---|
| 1 | Wealthfront order IA-5086 | `sec.gov/litigation/admin/2018/ia-5086.pdf` | 7 Sep 26 | 200, 236,744 B. Retrieved, converted, read in full |
| 2 | Hedgeable order IA-5087 | `sec.gov/litigation/admin/2018/ia-5087.pdf` | 7 Sep 26 | 200, 186,716 B. Retrieved, read in full |
| 3 | FR term "digital engagement practices", SEC only | `federalregister.gov/api/v1/documents.json` | 7 Sep 26 | **COUNT 8** — see NF-1 |
| 4 | FR unrestricted "digital engagement practices" | same | 7 Sep 26 | COUNT 1,719 — mostly noise; restricted query used instead |
| 5 | Internet adviser exemption adopting release | `federalregister.gov/.../2024/04/09/2024-06865.txt` | 7 Sep 26 | 200, 162,715 B. Read §§ II.A, II.B, n.25, n.32 |
| 6 | Codified rule text 275.203A-2 | `ecfr.gov/api/versioner/v1/full/2026-09-01/title-17.xml?section=275.203A-2` | 7 Sep 26 | First attempt **HTTP 406** — "requires response compression." Retried with `--compressed` → 200, 2,494 B. **Access note for the register: eCFR API requires an Accept-Encoding header.** |
| 7 | IM Guidance Update 2017-02 | `sec.gov/investment/im-guidance-2017-02.pdf` | 7 Sep 26 | 200, 128,102 B. Read in full |
| 8 | Reg BI adopting release | `federalregister.gov/.../2019/07/12/2019-12164.txt` | 7 Sep 26 | 200, 1,597,471 B. **Access note: file is byte-flagged binary; `grep` silently returns "Binary file matches" and counts read as zero. Use `grep -a`.** |
| 9 | Reg BI term sweep (`grep -a`) | local | 7 Sep 26 | "self-directed" 10; "unsolicited" 7; "investment analysis tool" 4; "01-23" 1; "computer software program" 0 |
| 10 | Solely Incidental Interpretation | `federalregister.gov/.../2019/07/12/2019-12209.txt` | 7 Sep 26 | 200, 74,255 B. "temporary or limited discretion" ×7 — read all |
| 11 | Fiduciary Interpretation (doc-number probe) | `federalregister.gov/.../2019/07/12/{2019-12208,-12207,-12206}.txt` | 7 Sep 26 | 12208 → 200, 124,735 B (= 84 FR 33669). 12207, 12206 → **404** |
| 12 | Fiduciary Interpretation term sweep | local | 7 Sep 26 | "self-directed" 0; "client-directed" 0; "scope of the relationship" 6 — read all |
| 13 | Rule 3a-4 codified text | `ecfr.gov/api/.../title-17.xml?section=270.3a-4` | 7 Sep 26 | 200, 1,845 B. Read in full |
| 14 | SEC withdrawal of proposed rules | `federalregister.gov/api/v1/documents.json?conditions[term]="Withdrawal of Proposed Regulatory Actions"` | 7 Sep 26 | **COUNT 1** — doc 2025-11110, 90 FR 25531, 17 Jun 2025 |
| 15 | Withdrawal document full text | `federalregister.gov/.../2025/06/17/2025-11110.txt` | 7 Sep 26 | 200, 17,612 B. **First attempt at doc number 2025-11052 → 404**; correct number obtained from the API, not guessed |
| 16 | PDA proposing release | `federalregister.gov/.../2023/08/09/2023-16377.txt` | 7 Sep 26 | 200, 566,920 B. Term sweep at NF-2 |
| 17 | DEP RFI | `federalregister.gov/.../2021/09/01/2021-18901.txt` | 7 Sep 26 | 200, 177,935 B. Term sweep at NF-2; questions 1.19, 3.6–3.10 read |
| 18 | Commission opinion — Faber | `sec.gov/litigation/opinions/34-49216.htm` | 7 Sep 26 | 200, 107,136 B. "non-discretionary" 0, "control" 1 — **not on point, not used** |
| 19 | Commission opinion — Pinchas | `sec.gov/litigation/opinions/34-41816.htm` | 7 Sep 26 | 200, 118,390 B. "control" ×8 — read all; **on point**, S3-10 |
| 20 | Commission opinion — Pinchas (.txt path) | `sec.gov/litigation/opinions/3441816.txt` | 7 Sep 26 | **404** — use the `34-NNNNN.htm` form |
| 21 | FINRA Rule 2214 live | `finra.org/rules-guidance/rulebooks/finra-rules/2214` | 7 Sep 26 | **HTTP 429 then 403**, 5,826 B, body = "Just a moment… Enable JavaScript and cookies to continue" — **Cloudflare JS challenge. P7's note that individual FINRA notices render server-side NO LONGER HOLDS.** |
| 22 | FINRA Rule 2111 live | `finra.org/rules-guidance/rulebooks/finra-rules/2111` | 7 Sep 26 | **HTTP 429** — same challenge |
| 23 | Wayback availability, FINRA 2214 | `archive.org/wayback/available?url=…/2214` | 7 Sep 26 | Snapshot **20260215151413** available |
| 24 | FINRA Rule 2214 via Wayback | `web.archive.org/web/20260215151413/…/2214` | 7 Sep 26 | 200, 115,790 B. **Full rule text recovered** — S3-08 |
| 25 | Wayback availability, FINRA 2111 | `archive.org/wayback/available?url=…/2111` | 7 Sep 26 | `archived_snapshots: {}` — **empty**; the availability API missed it |
| 26 | Wayback **CDX** index, FINRA 2111 | `web.archive.org/cdx/search/cdx?url=…/2111&output=json&filter=statuscode:200&from=2025` | 7 Sep 26 | 5 snapshots returned. **Access note: when the `available` API returns empty, the CDX index still works — use it.** |
| 27 | FINRA Rule 2111 via Wayback | `web.archive.org/web/20250218115433/…/2111` | 7 Sep 26 | 200, 118,289 B. **Full rule text incl. (b), .01–.03 recovered** — S3-23 |
| 28 | CourtListener `"stock screener" "investment adviser"` | `courtlistener.com/api/rest/v4/search/?type=o` | 7 Sep 26 | **COUNT 0** |
| 29 | CourtListener `"screening tool" "investment adviser" registration` | same | 7 Sep 26 | **COUNT 0** |
| 30 | CourtListener `"watch list" "investment adviser" unregistered software` | same | 7 Sep 26 | **COUNT 0** |
| 31 | CourtListener `"trading signals" "investment adviser"` | same | 7 Sep 26 | **COUNT 3** — *Rome v. Mandel* (Colo.) and two others; none on user configuration |
| 32 | CourtListener — 4 further queries | same | 7 Sep 26 | **Rate-limited; JSON parse failures.** CourtListener enforces ~50 queries/hour and a parallel sweep was consuming the budget. Backed off; the securities-side CourtListener sweep was run by a dedicated researcher (see its own log) |
| 33 | SEC AP listing, `?populate=Schwab` | `sec.gov/enforcement-litigation/administrative-proceedings?populate=Schwab` | 7 Sep 26 | 200, 83,268 B → detail link `sec.gov/enforce/34-95087-s` |
| 34 | Schwab detail page | `sec.gov/enforce/34-95087-s` | 7 Sep 26 | 200, 71,137 B → PDF href `/litigation/admin/2022/34-95087.pdf` (taken from the row, not constructed) |
| 35 | Schwab 2022 order | `sec.gov/litigation/admin/2022/34-95087.pdf` | 7 Sep 26 | 200, 436,199 B. Read — S3-22 |
| 36 | *Donelson* slip opinion | `govinfo.gov/content/pkg/USCOURTS-ca7-23-01809/pdf/USCOURTS-ca7-23-01809-0.pdf` | 7 Sep 26 | 200, 341,925 B, 24 pp. **Read in full; slip op. 15–18 verified verbatim** — S3-14 |
| 37 | Nadex Advisory Notice 2015_01 | `cftc.gov/filings/orgrules/rule120115nadexdcm001.pdf` | 7 Sep 26 | 200, 419,954 B. **"parameters customized by the trader" verified verbatim at p.4** — S3-18 |
| 38 | Pham dissenting statement | `cftc.gov/PressRoom/SpeechesTestimony/phamstatement082923` | 7 Sep 26 | 200, 42,324 B. **Verified verbatim** — S3-18 |
| 39 | *SignalPush* consent order | `cftc.gov/media/9186/enfryanmastenconsentorder082923/download` | 7 Sep 26 | 200, 967,868 B, 12 pp. **Verified ¶¶20–25.** Term sweep: "select" 0, "choose" 0, "parameters" 0, "customiz" 0, "originate" 0 |
| 40 | CFTC Staff Letter 09-27 | `cftc.gov/csl/09-27/download` | 7 Sep 26 | 200, 50,333 B. **Verified verbatim at p.3** — S3-17 |
| 41 | CFTC Staff Letter 03-26 | `cftc.gov/…/documents/letter/03-26.pdf` | 7 Sep 26 | 200, 22,962 B. **Verified verbatim** — S3-16 |
| 42 | *CFTC v. Hall* official reporter | `static.case.law/f-supp-3d/49/html/0444-01.html` | 7 Sep 26 | 200, 56,615 B. **Verified verbatim at 449-50, 452** — S3-15 |
| 43 | Washington DFI enforcement (published path) | `dfi.wa.gov/securities/enforcement-actions` | 7 Sep 26 | **HTTP 404** |
| 44 | Washington DFI enforcement (working path) | `dfi.wa.gov/securities-enforcement-actions` | 7 Sep 26 | 200, 47,335 B. **Respondent-field search only** — see NF-8 |
| 45 | FR "Regulation Best Interest" RULE documents | `federalregister.gov/api/v1/documents.json` | 7 Sep 26 | COUNT 14 — located 84 FR 33318, 84 FR 33681, 84 FR 33669 |
| 46 | FR "Standard of Conduct for Investment Advisers" | same | 7 Sep 26 | COUNT 49 — dominated by SRO filings; the interpretation was located by doc-number probe instead (row 11) |
| 47 | *CFTC v. Wall Street Underground* official reporter | `static.case.law/f-supp-2d/281/html/1260-01.html` | 7 Sep 26 | 200, 66,591 B. **Verified verbatim** at 1268 and Findings of Fact §II.A — ◇ cleared, S3-21 |
| 48 | NFA Interpretive Notice 9055 | `nfa.futures.org/rulebooksql/rules.aspx?RuleID=9055&Section=9` | 7 Sep 26 | 200, 158,160 B. **All quoted passages verified verbatim**; one punctuation correction — ◇ cleared, S3-19 |
| 50 | FINRA 2111 live, full browser headers | `finra.org/rules-guidance/rulebooks/finra-rules/2111` | 7 Sep 26 | **HTTP 403**, 3,460 B, `<title>Just a moment...</title>` — Cloudflare block confirmed on a second attempt with complete browser headers and `--compressed`. ◇ stands; needs a browser route |
| 51 | FR, SEC docs "predictive data analytics" ≥ 18 Jun 2025 | `federalregister.gov/api/v1/documents.json` | 7 Sep 26 | **COUNT 1** — 90 FR 45652, the agenda item recording the withdrawal |
| 59 | *Commodity Trend Service* official reporter | `static.case.law/f3d/233/html/0981-01.html` | 7 Sep 26 | 200, 82,631 B. **IAA/CEA asymmetry at 988 verified verbatim** — S3-28 |
| 60 | *Rome v. Mandel* official reporter | `static.case.law/p3d/405/html/0387-01.html` | 7 Sep 26 | 200, 87,155 B. **¶¶6, 7, 32, 33, 40 verified verbatim** — S3-27 |
| 61 | *SEC v. Pirate Investor* official reporter | `static.case.law/f3d/580/html/0233-01.html` | 7 Sep 26 | 200, 130,079 B. **247-48 verified verbatim** — S3-29 |
| 62 | CourtListener defence-phrasing sweep, 63 queries | `courtlistener.com/api/rest/v4/search/?type=o` | 7 Sep 26 | Run by a dedicated researcher over ~3 h (rate limit 5/min AND 50/hour). All counts at NF-13 to NF-17. **Corpus defect established by direct test — see NF-13** |
| 56 | PDA release, spelling-variant re-sweep | local, `pda.txt` | 7 Sep 26 | `watch list` **1** (p.53975) vs `watchlist` **0** — **the miss that produced the NF-2 correction.** `electronic librar` 1; `research page` 1; `investment analysis tool` **3 occurrences on 2 lines** (a report claiming 7 was wrong); `free to choose` **0** (a quoted passage attributed to p.54002 could not be located and is not relied on) |
| 57 | PDA release, page-marker location of key passages | local, `pda.txt` | 7 Sep 26 | Lines mapped to `[[Page NNNNN]]` markers: **53972, 53975, 53977, 53984** all confirmed exactly. Passages at 53997 and 54007 verified verbatim |
| 58 | Documents citing File No. S7-10-21 | Federal Register API | 7 Sep 26 | **3** — the DEP RFI itself; the PDA proposal (withdrawn); the internet-adviser exemption proposal 88 FR 50076 (**adopted** as 89 FR 24693) |
| 53 | *Betterment* order IA-6288 | `sec.gov/files/litigation/admin/2023/ia-6288.pdf` | 7 Sep 26 | 200, 283,384 B, 12 pp. **¶¶18-19 verified verbatim** — S3-24 |
| 54 | *Fair Invest / Parekh* order | `sec.gov/files/litigation/admin/2024/33-11329.pdf` | 7 Sep 26 | 200, 193,332 B, 9 pp. **¶¶16.b, 18, 20 verified verbatim** — S3-25 |
| 55 | SEC AP listing full enumeration 2022-2026 (2,640 rows) + litigation releases (1,335) | `sec.gov/enforcement-litigation/…` | 7 Sep 26 | Run by a dedicated researcher; **"robo-advis*" = 0 across all litigation releases** — NF-11. **Access note: sec.gov rate-limits at ~10 req/s and returns its block page with HTTP 200 and a ~5,151-byte HTML body — detect it by FILE TYPE, not status code. The AP listing caps at 100 rows/page and `&month=0` returns HTTP 403.** |
| 52 | SEC Regulatory Flexibility Agendas | `federalregister.gov/.../2025/09/22/2025-18321.txt`; `.../2026/08/14/2026-16619.txt` | 7 Sep 26 | 52,312 B and 34,102 B. 2025 agenda item 328 records withdrawal (date 04/21/25); **2026 agenda: 0 hits for PDA / digital engagement / AI** |
| 49 | Rule 4.14(a)(9) adopting release | `cftc.gov/files/foia/fedreg00/foi000310a.pdf` | 7 Sep 26 | 200, 143,046 B. **Verified — and a prior mis-reading corrected.** `pdftotext -layout` interleaves the three FR columns and inverts Example E's holding; extraction **without** `-layout` gives the true text. Example C located on this pass — ◇ cleared, S3-20 |

*The CFTC/NFA sweep and the securities-side CourtListener sweep were run by dedicated researchers; their own full query logs with counts are held with their reports and the material relied on above was re-verified by this track's author against the primary text in rows 36–42.*

## ◇ list — resting on secondary or unverified-live confirmation

| Item | Why flagged | What is needed |
|---|---|---|
| **FINRA Rule 2214** (S3-08) | Read from a **Wayback snapshot dated 15 Feb. 2026**, not live. finra.org returned HTTP 403 behind a Cloudflare JS challenge on 7 Sep 2026. | Confirm the live text via a browser route. The rule is long-standing and no amendment is known, but currency as at 7 Sep 2026 is **not** verified. |
| **FINRA Rule 2111** (S3-23) | Read from a **Wayback snapshot dated 18 Feb. 2025**, not live. Same Cloudflare block. | Same. Paragraph (b) and Supp. Mat. .02/.03 are load-bearing for the "institutional-only relief" pattern. |
| ***Risley v. Universal Navigation*** (S3-30) | Quotes taken from the assistant's RECAP retrieval of the district-court docket and the 2d Cir. summary order; **not re-opened by this track's author**. Also **non-precedential** on appeal. | Re-open Dkt. 90 at 31-32 and the summary order at 9-10 via the RECAP archive. |
| ***SEC v. Coinbase*** Wallet holding, Dkt. 105 at 82-83 and fn. 20 | The Wallet holding is **already in P7's register**, but the *specific* quotes used in Direct Answer A — the "sole decision-maker" sentence, the *GEL Direct* distinction, and fn. 20 on facilitation — come from the assistant's RECAP retrieval and were **not re-opened by this track's author**. | Re-open `archive.org/download/gov.uscourts.nysd.599908/gov.uscourts.nysd.599908.105.0.pdf`. **The *GEL Direct* narrowing is load-bearing and should be verified before it is relied on.** |
| ***Sherter v. Ross Fialkow Capital Partners***, 31 Mass. L. Rptr. 98 (Mass. Super. 2013) | **Not retrieved** — no free full text; the ONLY hit for `"software" AND "unregistered investment adviser"` (NF-18). | A paid database or a Massachusetts court route. **Highest-value unresolved lead in the file.** |
| ***Schneider v. Kansas Securities Comm'rs*** (Kan. App. 2017) | **Not retrieved** (NF-18). | Same. |
| ***State v. Terry's Tips, Inc.*** (Vt. Super. 2005) | **Not retrieved** (NF-18); a separate state decision from the federal *Terry's Tips* in the register. | Same. |
| ~~NFA Interpretive Notice 9055 (S3-19)~~ | **◇ CLEARED 7 Sep 2026.** Independently retrieved (HTTP 200, 158,160 B) and all quoted passages verified verbatim. Note: the NFA *rulebook* is reachable over plain HTTP even though NFA's BASIC disciplinary search is not (NF-9). One punctuation correction was made against the verified text. | — |
| ~~Rule 4.14(a)(9) adopting release, 65 FR 12938 (S3-20)~~ | **◇ CLEARED 7 Sep 2026.** Independently retrieved (HTTP 200, 143,046 B) and verified. **Correction recorded:** the PDF is three-column and `pdftotext -layout` interleaves the columns, producing text in which Example E appears to read "this CTA is **not** exempt." Extraction without `-layout` gives the true reading — Examples C, D and E are all **exempt**. **Access note for the register: never read a multi-column Federal Register PDF with `-layout`.** Verification also surfaced **Example C**, which no prior report had identified and which is the strongest supporting text in the track. | — |
| ~~*CFTC v. Wall Street Underground*, 281 F. Supp. 2d 1260 (S3-21)~~ | **◇ CLEARED 7 Sep 2026.** Independently retrieved at `static.case.law/f-supp-2d/281/html/1260-01.html` (HTTP 200, 66,591 B) and verified verbatim: the holding at 1268 and the findings-of-fact sentence "Neither defendant Web nor its employees made specific buy and sell recommendations to clients." Ground confirmed as absence of specific recommendations, **not** user configuration. | — |
| **CFTC Staff Letters 08-12, 08-07, 95-82** | 08-12 read by the assistant; **08-07 and 95-82 were not read in original** — 95-82 is known only through the *Donelson* court's description of it. | Not relied on for any proposition above except as *Donelson* characterises 95-82, which is quoted from the slip opinion. Retrieve if the IB line is pursued. |
| **NFA disciplinary / BCC decisions** | **Not swept at all** — JavaScript application, not searchable over HTTP (NF-9). | A browser route, if the commodities line is to be closed. |
| **Washington State orders before 2025** | **Not swept** — respondent-field search only (NF-8). | A browser route or a bulk source, if the Washington line is to be closed beyond *Solium*. |
| **Nadex Advisory Notice — current status** | Verified in the primary certification submission and quoted in a Commissioner's dissent. **Whether Nadex (now Crypto.com Derivatives North America) still publishes it, and whether the CFTC has since spoken, is not established.** Pham's assertion that the Commission "changed this interpretation" is **a dissenting Commissioner's characterisation**, not a Commission finding. | Check whether the advisory remains in the exchange's current rulebook, and whether any post-2023 CFTC document addresses it. **Framing Question A's "near-miss" depends on this.** |

---

*End of S3.*

*Provenance note — all three commissioned sweeps have landed and are fully integrated.* They produced S3-24 (Betterment), S3-25 (Fair Invest), S3-26 (the PDA release's articulations), S3-27 (Rome v. Mandel), S3-28 (Commodity Trend Service), S3-29 (Pirate Investor), S3-30 (Risley), and NF-1's correction, NF-2's correction, and NF-11 through NF-18. **Every quote relied on was independently re-verified against the primary text by this track's author before being written in, except the five items listed in the ◇ table.** That verification discipline caught five errors: an over-count of "investment analysis tool"; a quoted passage attributed to 88 FR 54002 that does not exist; an **inverted holding** produced by `pdftotext -layout` on a three-column Federal Register PDF; a negative finding of my own stated on a sweep that missed a spelling variant; and a claim in this file's own earlier draft that the DEP RFI "produced no rule," which a File-Number trace disproved.

*Two revisions were forced by the final sweep and both are recorded in place rather than smoothed over.* **First, Direct Answer A was too blunt** — it is "no" on adviser status but "yes, twice" on broker status, where *Coinbase* (Wallet) and *Risley* succeeded on a **user-control-at-the-moment-of-trade** theory rather than a user-configuration theory. **Second, the CEA line's weight against Q1 must be marked down**, because *Commodity Trend Service* (S3-28) holds that the CEA is broader than the Advisers Act on precisely this axis: impersonal publishers are CTAs "even though an analogous publisher would be excluded from the definition of IA." That downgrade touches this file's own headline adverse entry, *Donelson*, and it runs in the configuration's favour.

*Standing caveat on every negative finding in this file.* **NF-13 establishes by direct test that CourtListener's opinion index is incomplete** — it does not contain *SEC v. Coinbase* or *Risley*, and contains no SEC or CFTC administrative decisions at all. Every "COUNT 0" here means "not located in the documented sources," never "does not exist in United States law." Three retrievable-in-principle leads remain unread (NF-18), one of which — *Sherter v. Ross Fialkow* — is the sole hit for `"software" AND "unregistered investment adviser"` and should be obtained before this track is treated as closed.

*A note on method, for the coordinator.* Six findings in this file exist only because a retrieval was checked against the primary text rather than accepted: the Rule 4.14(a)(9) release's **Example C** (the strongest supporting text in the track, identified in no report); Example E's **inverted** holding; the stronger operative sentence in CFTC Letter 03-26; the **"watch list" spelling variant** that had hidden 88 FR 53975; the File-Number trace that corrected NF-1; and the *CTS* passage that downgrades the entire CEA line. **The shared context's rule — a lead is never a citation — earned its place six times in one track.**


---

# S4 · TRACK 4 — Standing mode as its own legal architecture

**Commission P8. Bears on Q3 (customer instruction) and Q2 (broker characterization).**
Retrieval dates are the dates each document was actually fetched. All fetching for this track was done **7 September 2026** unless a register entry says otherwise.

**Scope note.** This track examines the *standing execution* track only — the configuration in which the member configures earlier, the machine detects, the machine composes, and the machine sends, with no per-order human act. That is a different legal architecture from the V1 per-order configuration, and it is researched as such.

**Two corrections to the brief's own premises, established at the outset:**

1. The Investment Adviser Association no-action letter is dated **21 February 2017**, not 7 February 2017. The document bears the date 21 February 2017 and responds to an incoming letter dated 15 February 2017. More importantly, **its holding runs the opposite way from the way the brief frames it**: the staff *disagreed* with the IAA and held that a standing letter of authorization **does** confer custody. The relief granted was narrow — no surprise examination — not a holding that the standing instruction remains the client's own. See RE-4.3-04.
2. **WAC 460-24A-220 is the Washington *investment adviser* dishonest-or-unethical-practices rule, not a broker-dealer rule.** Washington's broker-dealer analogue was **repealed** effective 13 October 2024 and replaced. The current broker-dealer provision is WAC 460-20C-210(6). Its text differs from FINRA Rule 3260(d)(1) in two material respects. See RE-4.3-07 and RE-4.3-08.

---

## Headline findings

Stated up front so the register can be read against them. Each is sourced below; none is a legal conclusion.

**1 · There IS a supportive end to the GEL Direct Trust line, and it is a Commission rule rather than a staff letter.** 17 C.F.R. §240.10b5-1(c)(1)(i)(B)(2) provides in its own text that a person's pre-adopted plan may have "included a written formula or **algorithm, or computer program**, for determining the amount of securities to be purchased or sold and the price at which and the date on which the securities were to be purchased or sold" — and the rule describes what results, throughout, as **the adopter's own purchase or sale**. The Commission's gloss in Rel. 33-7881 is that such a person may "plan securities transactions in advance … and then **carry out those pre-planned transactions at a later time**." Against *GEL*'s inference of discretion from a six-second interval, this is the counterweight. **It is an analogy** — Rule 10b5-1 answers whether a trade was *on the basis of* material nonpublic information, and merely presupposes the attribution rather than deciding it. (RE-4.4-01, RE-4.4-02)

**2 · Three independent instruments converge on the same exposed variable: TIMING.** The SLOA letter's footnote 1 turns on discretion "as to the **amount, payee, and timing**"; Rule 10b5-1(c)(1)(i)(B)(2) requires the formula to determine amount, price **and the date**, which Rel. 33-7881 defines as a *day of the year*; Regulation M's attribution test turns on control over "prices or amounts, the **timing** of, or the manner in which" purchases are made. In the configuration every other parameter — sizing, order type, price band, instrument, side, account, broker — traces to an explicit member setting. **Timing does not: it is determined by when a member-authored rule fires against live market data.** Three instruments, three different bodies of law, one shared pressure point. (RE-4.3-04, RE-4.4-01, RE-4.4-02, RE-4.4-04)

**3 · On "who can be the grantee," there is no authority either way — but the drafting chain is uniform and traceable.** No located instrument says a grantee must be a natural person; none says a grantee may be a program. But FINRA Rule 3260(b) says "a stated **individual** or individuals"; 17 C.F.R. §240.17a-3(a)(17)(ii) says "each **natural person** to whom discretionary authority was granted"; and adopting release 34-44992 **footnote 21 sources the federal natural-person wording expressly to "NYSE Rule 408 and NASD Rule 2510(b)"** — i.e. the federal rule inherited the human-grantee assumption from the SRO rules rather than reasoning to it. A grant to a program breaches no located express prohibition; it produces an instrument for which the federal recordkeeping rule **has no field**. (RE-4.3-01, RE-4.3-02, RE-4.2-01, DA-4.3(f))

**3a · The design's central argument has already been made twice and lost both times — once to the Commission, once to its staff.** In ***Michael Pino***, Rel. 34-74903 (2015), the respondent argued he "simply tried '**to sell something based on a strategy that's been well in place, that to me is not discretion**.'" The Commission held: "**a customer's approval of a general strategy does not meet the requirements of the 'time and price discretion' exception**," and located the definiteness requirement on **the customer's grant**, not on the resulting order. *Murphy* (2013) and *Sathianathan* (2006) are to the same effect. **Per-order V1 distinguishes this cleanly — the member is consulted before every execution, which is exactly what Pino failed to do. Standing mode does not distinguish it on the reasoning at all.** (RE-4.2-02, A0)

**4 · The design's core intuition is the exact argument the SEC staff rejected in 2017.** The IAA argued that a *bounded* standing authorization is different in kind from an open one — expressly contrasting it with trustee discretion and with "a full power of attorney … or broad discretionary authority." The staff answered: "**We disagree.**" A client-signed, bounded, revocable standing authorization under which another party later instructs the custodian **does** confer custody, notwithstanding that the actor "is authorized to act merely as an agent for the client." Relief was granted only from the surprise examination, on seven conditions. **This is the single most adverse finding in the track and the configuration does not distinguish it on reasoning — only on subject matter.** (RE-4.3-04, A1)

**5 · The delay has no support. This is a finding the design needs.** No authority was located, anywhere searched, stating that an interval between signal and submission bears on **who decided**. The only mandated delay between instruction and execution in federal securities law — Rule 10b5-1's cooling-off period — exists, in the Commission's own words, because it "**reduces the risk that corporate insiders could benefit from any material nonpublic information**." That is an informational rationale, not an attributional one, and read strictly it is mildly adverse. A longer interval weakens one evidentiary route to a *GEL*-style inference; it does not relocate the decision. (RE-4.4-03, NF-3, DA-4.4(b))

**3b · A regulator has already been asked to permit standing instructions here, and refused.** In **Rel. 34-49883 at 7** (17 Jun 2004), commenters asked NASD to clarify that the written instruction lifting Rule 2510(d)(1)'s day limit "**allows customers to issue general 'standing' instructions, rather than issuing written instructions on an order-by-order basis. NASD declined to adopt this position.**" NASD's stated standard is "**trade-specific**," and anything broader "may [be granted] pursuant to a fully executed trading authorization" — i.e. it exits the exception entirely and re-enters Rule 3260(b) with its "stated individual or individuals." **This is the most directly on-point adverse authority located in the whole track for the standing track specifically, and the configuration does not distinguish it.** (RE-4.2-03, A0a)

**3c · The rulebook's own word for the configuration's envelope is "investment discretion."** FINRA Rule 4512(a)(3) exempts from a recordkeeping duty "**investment discretion granted by a customer as to the price at which or the time to execute an order**." And the Commission's most recent word, ***DiPaola***, Rel. 34-105568 (**28 May 2026**) n.8: "**determining the price at which a trade occurs is an exercise of discretion subject to only a limited exception.**" **Any framing that treats bounded price-and-time latitude as "not discretion" is using a characterisation no instrument supports.** *DiPaola*'s main-text test — discretion is trading "**without first receiving approval for the trades**" — is, however, a line **per-order V1 sits cleanly on the safe side of.** (RE-4.2-04, RE-4.2-05, A0b, A0c)

**6 · FINRA Rule 3260(d)(1) cannot carry standing mode, for a reason the brief did not anticipate.** Time-and-price authority "will be considered to be in effect **only until the end of the business day** on which the customer granted such discretion, absent a specific, written contrary indication **signed and dated by the customer**." A standing authority is by definition not day-limited, so the default form of the exception does not reach it, and the only escape is itself a signed, dated customer writing — which routes straight back to finding 3. The day limit is lifted outright **only for institutional accounts** under Rule 4512(c) — the second authority in the register gated on institutional status, after *S3 Matching*. And the brief's framing of the exception's subject needs correcting: **the subject is "This Rule," not "a member."** (RE-4.2-01, DA-4.2)

**7 · Two currency corrections that stale sources would miss.** Washington **repealed** its broker-dealer and salesperson unethical-practices rules (WAC 460-21B-060, 460-22B-090) effective **13 October 2024**; the replacement, WAC 460-20C-210(6), omits **both** FINRA's "definite amount of a specified security" requirement **and** its business-day limit, making it materially broader on three axes. And the SEC's 2023 *Safeguarding Advisory Client Assets* proposal was **formally withdrawn on 17 June 2025**, so Rule 206(4)-2 is unchanged and the 2017 SLOA letter interprets a rule still in force. (RE-4.3-08, RE-4.3-05a)

---

## Register entries

### RE-4.3-01 · 17 C.F.R. §240.17a-3(a)(17)(ii) (Records to be made by certain exchange members, brokers and dealers) · https://www.ecfr.gov/api/versioner/v1/full/2026-09-01/title-17.xml?part=240&section=240.17a-3 · retrieved 7 Sep 2026

- **Type:** rule (federal regulation)
- **Date / status:** current as of the eCFR snapshot dated 2026-09-01; good law
- **Verbatim quote, pin-cited:**

> "(ii) If an account is a discretionary account, a record containing the dated signature of each customer or owner granting the authority and the dated signature of each natural person to whom discretionary authority was granted."
>
> — 17 C.F.R. §240.17a-3(a)(17)(ii)

Context of the enclosing paragraph, which scopes the whole of (a)(17):

> "(17) For each account with a natural person as a customer or owner:"
>
> — 17 C.F.R. §240.17a-3(a)(17)

- **What it establishes:** The books-and-records rule requires, for a discretionary account, a record bearing two dated signatures: the customer's, and that of "each natural person to whom discretionary authority was granted." The rule's text describes the grantee as a natural person. It does not contain an express sentence prohibiting a grant to a non-natural person; the natural-person wording appears as the description of whose signature must be captured.
- **Q3:** ADVERSE (the operative recordkeeping obligation is drafted around a human grantee, and a grant to software produces no natural person whose signature could be recorded)
- **Q2:** NEUTRAL
- **Level 2** — a rule of the Commission, directly on the record required for a discretionary grant; but it is a recordkeeping obligation addressed to the member/broker/dealer, not a rule stating who may be a grantee.
- **Application note:** In standing mode the member would be granting a bounded authority to a locally installed runtime. Under this text the broker's own record for a discretionary account must carry "the dated signature of each natural person to whom discretionary authority was granted." If the grantee is a program, there is no natural person whose dated signature the broker could record. The rule does not say what follows from that. Note also that the whole of (a)(17) is scoped to accounts "with a natural person as a customer or owner" — that scoping is about the *customer*, and (ii) sits inside it. The configuration's member is a natural person customer, so (a)(17) applies on its face.

---

### RE-4.3-02 · Exchange Act Release No. 34-44992, *Books and Records Requirements for Brokers and Dealers Under the Securities Exchange Act of 1934* (17 Oct 2001), 66 FR 55818 · https://www.sec.gov/files/rules/final/34-44992.htm · retrieved 7 Sep 2026

- **Type:** release (adopting release)
- **Date / status:** adopting release for the rule quoted at RE-4.3-01; good law as the source of that text
- **Verbatim quote, pin-cited:**

> "For discretionary accounts, firms also must include as part of the account record the dated signature of each customer granting the discretionary authority and the dated signature of each natural person21 to whom discretionary authority was granted."
>
> — Rel. 34-44992, § II (discussion of Rule 17a-3(a)(17)), text accompanying footnote 21

**Footnote 21 in full:**

> "21   See NYSE Rule 408 and NASD Rule 2510(b)."
>
> — Rel. 34-44992, n.21

And from the cost/burden discussion:

> "In addition, the amendments require that, if the account is a discretionary account, the firm must obtain (i) the signature of the customer granting discretion, (ii) the date discretion was granted, and (iii) the signature of the person to whom discretion was granted."
>
> — Rel. 34-44992, § V (Paperwork Reduction Act / cost-benefit discussion)

- **What it establishes:** The Commission sourced the "natural person" formulation in Rule 17a-3(a)(17)(ii) directly to two SRO rules — NYSE Rule 408 and NASD Rule 2510(b), the latter being the predecessor of FINRA Rule 3260(b), the rule requiring "prior written authorization to a stated individual or individuals." In the burden discussion the Commission restated the same requirement using the unqualified word "person."
- **Q3:** ADVERSE
- **Level 2** — the Commission's own adopting release, expressly explaining the provenance of the operative words.
- **Application note:** This is a clean drafting chain: the federal books-and-records phrase "each natural person to whom discretionary authority was granted" is expressly footnoted to the SRO rule that speaks of authorization "to a stated individual or individuals." Both instruments describe a human grantee, and the Commission adopted the federal wording *because* the SRO rules already read that way. **This is drafting-by-assumption, not an express prohibition.** Neither the release nor the rule contains a sentence saying a grantee must be a natural person or that a program may not be one. The Commission was capturing existing SRO practice, not adjudicating the question. Recorded as adverse because the register must not soften it: every operative instrument in the chain is written on the assumption of a human grantee, and none contemplates any other kind.

---

### RE-4.3-03 · 17 C.F.R. §240.17a-3(a)(6)(i)(A) and (a)(7)(i) (order tickets) · https://www.ecfr.gov/api/versioner/v1/full/2026-09-01/title-17.xml?part=240&section=240.17a-3 · retrieved 7 Sep 2026

- **Type:** rule (federal regulation)
- **Date / status:** current; good law
- **Verbatim quote, pin-cited:**

> "(6)(i) A memorandum of each brokerage order, and of any other instruction, given or received for the purchase or sale of a security, except for the purchase or sale of a security-based swap, whether executed or unexecuted.
>
> (A) The memorandum must show the terms and conditions of the order or instructions and of any modification or cancellation thereof, the account for which entered, the time the order was received, the time of entry, the price at which executed, the identity of each associated person, if any, responsible for the account, **the identity of any other person who entered or accepted the order on behalf of the customer, or, if a customer entered the order on an electronic system, a notation of that entry**; and, to the extent feasible, the time of execution or cancellation. … **An order entered pursuant to the exercise of discretionary authority by the member, broker or dealer, or associated person thereof, must be so designated.** The term instruction must include instructions between partners and employees of a member, broker or dealer. **The term time of entry means the time when the member, broker or dealer transmits the order or instruction for execution.**"
>
> — 17 C.F.R. §240.17a-3(a)(6)(i)(A) (emphasis added to the three operative clauses)

And the parallel provision for principal transactions with customers:

> "the identity of any other person who entered or accepted the order on behalf of the customer, or, if a customer entered the order on an electronic system, a notation of that entry. … An order with a customer other than a member, broker or dealer entered pursuant to the exercise of discretionary authority by the member, broker or dealer, or associated person thereof, must be so designated."
>
> — 17 C.F.R. §240.17a-3(a)(7)(i)

- **What it establishes:** The order-ticket rule sets up an express binary. Either (a) some **other person** "entered or accepted the order on behalf of the customer," in which case that person's *identity* must be recorded; or (b) **the customer** "entered the order on an electronic system," in which case only "a notation of that entry" is required. Separately, the rule's discretion flag runs only to discretion exercised "by the member, broker or dealer, or associated person thereof" — not to discretion exercised by a third party.
- **Q3:** SUPPORT in part / ADVERSE in part — see application note
- **Q2:** NEUTRAL
- **Level 2** — a Commission rule stating in operative text how an electronically entered customer order is to be characterised on the ticket.
- **Application note:** This is the closest thing located in any federal instrument to a *characterisation test for who entered an order*. The dichotomy it draws — "any other person who entered … on behalf of the customer" versus "a customer entered the order on an electronic system" — is precisely the line the standing-mode design sits on. **Supporting reading:** in per-order mode the member's own tap on the runtime-owned surface, followed by transmission under his own credentials, looks like the second branch, and the rule asks for no more than a notation. **Adverse reading:** in *standing* mode there is no member act at the moment of entry, and the entity that composes and sends is not the customer; the rule's first branch asks for "the identity of any other person who entered … the order on behalf of the customer," and the runtime has no identity the rule contemplates. **The rule does not resolve which branch software falls into, and no located authority applies it to software.** Note additionally that the discretion designation is drafted only for the member/BD/associated person, so a third party's discretion is not something this ticket rule flags at all.

---

### RE-4.1-01 · SR-CBOE-2004-35, Exchange Act Rel. No. 34-49916 (24 Jun 2004), 69 FR 40423 (2 Jul 2004) — CBOE Rule 6.53 contingency orders · https://www.federalregister.gov/documents/full_text/text/2004/07/02/04-15083.txt · retrieved 7 Sep 2026

- **Type:** SRO rule filing, Commission notice, full text in the Federal Register
- **Date / status:** 2004. **Status caveat:** OCO was subsequently deleted from CBOE Rule 6.53(h) by SR-CBOE-2019-017, Rel. 34-85657, 84 FR 16855 (22 Apr 2019). The definitional language survives as Commission-published description.
- **Verbatim quote, pin-cited — 69 FR at 40423, the "Contingency Orders" block:**

> "Market-if-Touched (CBOE Rule 6.53(c)(i)) and Stop (stop-loss) Orders (CBOE Rule 6.53(c)(iii))—**These orders are not executable until the market reaches a specified 'trigger' price, at which point each converts to a market order.** As such, they are not available to trade and have no standing in the quoted markets until the specified price trigger is reached. …
>
> Stop Limit Order (CBOE Rule 6.53(c)(iv))—A Stop-Limit order is not 'triggered' until the option contract trades or is bid (offered) at or above (below) the stop price, at which point it converts to a limit order. …
>
> **Not Held Orders (CBOE Rule 6.53(g))—A Not Held order is a discretionary order with instructions granting the agent flexibility as to the price and or time of execution.** CBOE Rule 8.85(b)(vi) prohibits DPMs from representing discretionary orders, including Not Held orders.
>
> One-Cancels-the-Other Orders ('OCO') (CBOE Rule 6.53(h))—**An OCO order is comprised of two or more orders designated for treatment as a collective unit.** The execution of any one of the component orders cancels the other(s). …
>
> All or None Orders ('AON') (CBOE Rule 6.53(i))—While an AON can be a limit order, **instructions require the order be executed in its entirety or not at all.** …
>
> Fill or Kill Orders ('FOK') (CBOE Rule 6.53(j))—While a FOK order can be a limit order, **instructions require it be executed in its entirety immediately upon representation** and, if not executed, the order is to be treated as cancelled."

- **What it establishes:** In a single block of Commission-published text, stop, stop-limit, market-if-touched, OCO, AON and FOK are all characterised as **customer-supplied "instructions" and "order conditions"** triggered by "a specified 'trigger' price," while exactly one type — the Not Held order — is separated out as "**a discretionary order with instructions granting the agent flexibility as to the price and or time of execution.**"
- **Q3:** SUPPORT — the strongest single passage located on question 4.1
- **Level 4** — Commission-published SRO filing; definitional description rather than holding, and the OCO provision has since been deleted.
- **Application note:** On this document's own vocabulary the line runs between **a condition the customer specified in advance** and **flexibility granted to an agent** — not between a human act and a machine act. Every conditional type on the customer side of that line is executed later by the exchange's machine when the trigger is met, and none of them is thereby treated as the exchange's or the broker's discretion. That is directly supportive of the proposition that machine execution of a customer-specified condition does not relocate the decision. **The disanalogy that must be stated: in every one of these types the machine that fires the condition is the *exchange's own matching system*, operating on an order the customer has already placed and that already has standing (or, for stops, has been lodged) in the broker's or exchange's book. In standing mode no order exists until the runtime composes one. The CBOE passage is about a condition attached to an existing order; standing mode is about a condition that causes an order to be created.** No located authority addresses the second case.

---

### RE-4.1-02 · Nasdaq Equity Rule 4703(g) (Discretion Order Attribute) and Rule 4702, as filed in SR-NASDAQ-2015-024, Exchange Act Rel. No. 34-74558 (20 Mar 2015), 80 FR 16050 (26 Mar 2015) · https://www.federalregister.gov/documents/full_text/text/2015/03/26/2015-06891.txt · retrieved 7 Sep 2026

- **Type:** SRO rule filing, Commission notice
- **Date / status:** 2015 text. **The Discretion attribute was amended by SR-NASDAQ-2021-072, FR Doc. 2021-21987 (8 Oct 2021); the current wording was not retrieved.** ◇
- **Verbatim quotes, pin-cited:**

> "The definition of the term 'Order' is being amended to mean **an instruction to trade a specified number of shares in a specified System Security submitted to the Nasdaq Market Center by a Participant.** An 'Order Type' is **a standardized set of instructions associated with an Order that define how it will behave** with respect to pricing, execution, and/or posting to the Nasdaq Book when submitted to Nasdaq. An 'Order Attribute' is **a further set of variable instructions that may be associated with an Order to further define how it will behave** …"
>
> — 80 FR at 16051

> "Upon entry, an Order is processed to determine whether it may execute against any contra-side Orders on the Nasdaq Book **in accordance with the parameters applicable to the Order Type and Order Attributes selected by the Participant** … The Order may then be posted to the Nasdaq Book if consistent with **the parameters of the Order Type and Order Attributes selected by the Participant.**"
>
> — 80 FR at 16051

> "**Discretion is an Order Attribute under which an Order has a non-displayed discretionary price range within which the entering Participant is willing to trade; such an Order may be referred to as a 'Discretionary Order.'** Thus, an Order with Discretion has both a price (for example, buy at $11) and a discretionary price range (for example, buy up to $11.03). … **A Participant may also specify a limit price beyond which the discretionary price range may not extend.**"
>
> — 80 FR at 16065 (proposed Rule 4703(g))

- **What it establishes:** In the Nasdaq rulebook, "Discretion" names a **price range the entering Participant sets and can cap**, attached to that Participant's own order. It is not authority delegated to anyone. Order behaviour throughout is "a set of instructions" and "parameters … selected by the Participant."
- **Q3:** SUPPORT
- **Level 4** — Commission-published SRO rule text, definitional; superseded in wording by the 2021 amendment (◇).
- **Application note:** This confirms the vocabulary point flagged in the brief. **US securities regulation uses "discretionary order" for a customer-set price band and "discretionary authority" for a grant of authority to a person, and they are different objects.** The configuration's envelope — narrow price-and-time latitude within a member-set price band, never broadened — is structurally the first thing, not the second. **But see RE-4.1-03: the vocabulary is not stable across SROs, and an argument that leans on it must confront the counter-usage.**

---

### RE-4.1-03 · NYSE Rule 70.25 (d-Quotes), as characterised in SR-NYSE-2013-71, Exchange Act Rel. No. 34-71330 (16 Jan 2014), 79 FR 3896 (23 Jan 2014) · https://www.federalregister.gov/documents/full_text/text/2014/01/23/2014-01251.txt · retrieved 7 Sep 2026

- **Type:** SRO rule filing, Commission notice
- **Verbatim quote, pin-cited:**

> "See NYSE Rule 70.25 (**defining d-Quotes as discretionary instructions with respect to a Floor broker's agency interest file (e-Quotes)**)."
>
> — 79 FR 3896, n.7

> "A d-Quote designated with a midpoint modifier **would use its discretion** to execute up to the midpoint but could execute at a less-aggressive price."
>
> — 79 FR 3896, n.8

- **What it establishes:** NYSE uses "discretionary instructions" for a **Floor broker's** agency interest — discretion held by a registered agent within a price range. That is the opposite usage from Nasdaq's customer-set Discretionary Order.
- **Q3:** ADVERSE / cautionary
- **Level 3** — a footnote characterisation in a Commission-published filing.
- **Application note:** **Recorded because it must not be suppressed.** The same adjective carries both senses across two SROs in the same market. Any argument that reasons from Nasdaq's "Discretionary Order" to the conclusion that customer-set price latitude is definitionally not discretionary authority is equivocating on a word that the rulebooks themselves use inconsistently. The vocabulary point at RE-4.1-02 is real but it is **not** a rule of construction.

---

### RE-4.1-04 · *In the Matter of EDGA Exchange, Inc. and EDGX Exchange, Inc.*, Exchange Act Rel. No. 34-74032 (12 Jan 2015), AP File No. 3-16332 · https://www.sec.gov/litigation/admin/2015/34-74032.pdf · retrieved 7 Sep 2026

- **Type:** SEC settled administrative and cease-and-desist order (§§19(h)(1), 21C)
- **Verbatim quote, pin-cited:**

> "An important category of exchange rules are those that govern the exchange's order types. **Order types are the primary means by which market participants communicate their instructions for the handling of their orders to the exchange.** … It is essential that an exchange operate in compliance with its own rules regarding order types so that the exchange's members and all other participants in trading that occurs on an exchange can understand on what terms and conditions their trading will be conducted."
>
> — Rel. 34-74032, ¶3

- **What it establishes:** The Commission characterises order types generically as the mechanism by which **the market participant** communicates **its own** instructions for the handling of **its own** orders. The order is the participant's; the machine that executes the type is the exchange's.
- **Q3:** SUPPORT
- **Level 4** — a Commission-level order, but the sentence is framing in a case about order-type disclosure, not a holding on discretion.

---

### RE-4.1-05 · *In the Matter of New York Stock Exchange LLC et al.*, Exchange Act Rel. No. 34-72065 (**1 May 2014** — note the brief's date of 12 May is incorrect), AP File No. 3-15860 · https://www.sec.gov/litigation/admin/2014/34-72065.pdf · retrieved 7 Sep 2026

- **Type:** SEC settled administrative order
- **Verbatim quote, pin-cited** (quoting the approved routing-broker rules NYSE Rule 17, Amex Equities Rule 17, Arca Equities Rule 7.41):

> "1. The Routing Broker(s) will receive routing instructions from the Exchange, to route orders to other market centers and report such executions back to the Exchange. **The Routing Broker(s) cannot change the terms of the order or the routing instructions, nor does the Routing Broker(s) have any discretion about where to route an order.**"
>
> — Rel. 34-72065, n.8

- **What it establishes:** In SEC-approved exchange rule text quoted by the Commission, an intermediary that transmits orders is characterised as **non-discretionary precisely because it cannot change the terms of the order.**
- **Q2 / Q3:** SUPPORT
- **Level 3** — the quoted text is an exchange rule condition on an *affiliated registered broker-dealer*, not a statement about unregistered software.
- **Application note:** The test the quoted rule uses — can the transmitting party change the terms of the order? — is one the configuration is architecturally built to fail in the right direction: the instruction record is bound to the exact displayed terms and the engine "can never fabricate the yes or alter the order after it." **Two cautions.** First, the routing broker is a registered broker-dealer; the sentence describes why *its* activity is not discretionary, not why an unregistered party is not a broker. Second, and correcting the brief: **this order does not define order types at all.** A full-text search returned zero hits for "order type," "stop order," "conditional" and "contingent."

---

### RE-4.1-06 · *Disclosure of Order Handling Information*, Exchange Act Rel. No. 34-84528 (2 Nov 2018), 83 FR 58338 · https://www.sec.gov/rules/final/2018/34-84528.pdf · retrieved 7 Sep 2026 — **and** SEC Division of Trading and Markets, *Responses to FAQs Concerning Rule 606 of Regulation NMS* (16 Aug 2019)

- **Type:** release (adopting release) plus staff FAQ
- **Verbatim quote, pin-cited:**

> "**If the broker-dealer exercises discretion with regard to how an order is routed and ultimately executed, such as (but not limited to) by determining particular venue destinations for an order, choosing among different trading algorithms, adjusting or customizing algorithm parameters, or performing other similar tasks involving its own judgment as to how and where to route and execute orders**, the broker-dealer is required to provide the information required by Rule 606(b)(3) … **If, by contrast, the broker-dealer simply forwards its customers' orders on to another broker-dealer and that second broker-dealer exercises all discretion in determining where and how to route and execute the orders, then the first broker-dealer is not required to provide disclosures** …"
>
> — Rel. 34-84528 at 70 (83 FR 58357)

From the staff FAQ (which carries this header verbatim: "These responses, like all staff guidance, **have no legal force or effect**"):

> "A broker-dealer exercises discretion over how an order is routed and ultimately executed **through its decision making and its participation in choices related to the use and configuration of algorithms, smart order routers, and other trading strategies**."
>
> — Rule 606 FAQ, Issue 1

- **What it establishes:** The only place the Commission has defined discretion over an automated thing, it defined it as **configuration**: "choosing among different trading algorithms, adjusting or customizing algorithm parameters."
- **Q3:** **CUTS BOTH WAYS — and the adverse edge is sharp**
- **Level 4** for the release; **Level 2** for the FAQ (no legal force by its own terms).
- **Application note:** **This is the most double-edged authority in the track and must not be reported one-sidedly.**
  **The supporting edge:** the test locates discretion in *whoever configures the parameters.* In the configuration every decision-relevant parameter traces to an explicit member setting — thresholds, weights, universe, sizing, price band, order type, time-in-force, account. On this test the configuring party, and therefore the discretion, is the member.
  **The adverse edge:** the Commission's sentence says that **adjusting or customising algorithm parameters *is* an exercise of discretion.** A configuration whose central defence is "every parameter is the member's own" is, on this release's vocabulary, describing a member who is *exercising discretion* — which is fine when the member is the customer, but it also means the act of parameter-setting is not a discretion-free zone. If any company-side default, preset or ranking were ever to determine a parameter, this release supplies the Commission's own words for what that would be. **The configuration's "no presets, no imports, no 'most users choose'" rule is doing more work than it may appear: on this authority, presets would be discretion.**
  **Critical limitation, stated:** the word "discretion" here is **Rule 606(b)(3) order-routing discretion**, not Exchange Act §3(a)(35) investment discretion, and **no located source equates the two.** A full-text search of Rel. 34-84528 for "3(a)(35)" returned **zero hits.** Do not conflate them.

---

### RE-4.1-07 · SEC Office of Investor Education and Advocacy, *All About Auto-Trading* (8 Jun 2009) · https://www.sec.gov/about/reports-publications/investorpubsautotradinghtm · retrieved 7 Sep 2026

- **Type:** SEC investor alert (staff investor-education publication; no stated legal force)
- **Verbatim quote, pin-cited:**

> "In an 'auto-trading' program, you establish an account at a brokerage firm that has agreed to accept trading instructions from the investment newsletter. In order to allow 'auto-trading' in your account, **you must sign an agreement with the broker authorizing it to accept trading instructions directly from the investment newsletter and to execute trades in your account without first getting your permission.** The broker will make trades in your account without consulting you about the price, the type of security, the amount and when to buy or sell."
>
> "'Auto-trading,' like any other arrangement that allows someone else to trade in your account **without first asking your permission**, can be highly risky."
>
> "**Generally, the SEC considers firms that publish investment newsletters and that also engage in 'auto-trading' to be investment advisers.**"
>
> — *All About Auto-Trading*, opening paragraphs and "Check Out the Newsletter"

- **What it establishes:** The only located SEC statement naming the exact boundary this track asks about. The defining feature of auto-trading is that the broker executes **without first getting the customer's permission**, on instructions from a third party. And the SEC states flatly that it generally considers a newsletter publisher that *also* engages in auto-trading to be an investment adviser.
- **Q1:** **ADVERSE** — publishing plus auto-trading yields adviser characterisation, stated without qualification
- **Q3:** SUPPORT on where the line is drawn
- **Level 2** — an investor alert from 2009 with no legal force, no reasoning and no citation. **But it is the only SEC document located anywhere that states the boundary in terms.**
- **Application note:** **This authority is the single most direct statement located of what standing mode looks like from the SEC's side, and it is not favourable.** The V1 per-order configuration sits on the *far* side of the stated boundary on the permission axis: one explicit tap per order on a runtime-owned surface means the trade does not occur "without first getting your permission." **Standing mode sits on the near side of that boundary on the permission axis by design** — the whole point of standing execution is that no per-order permission is sought. What distinguishes the configuration from the auto-trading paradigm is not permission but the other two elements: there is no third party sending trading instructions to the broker (the runtime is the member's own, on his own machine, under his own credentials), and the broker has signed no agreement to accept instructions from anyone but the member. **Whether those distinctions carry is not addressed by this document or by any other located source.** The adverse Q1 sentence is aggravated, not relieved, by the configuration's economics: the alert's target is a *publisher* that also auto-trades, and the engine layer is signal publication.

---

### RE-4.1-08 · *In the Matter of Wedbush Securities Inc., Jeffrey Bell, and Christina Fillhart*, Exchange Act Rel. No. 34-73652 / IA-3971 (20 Nov 2014), AP File No. 3-15913 · https://www.sec.gov/litigation/admin/2014/34-73652.pdf · retrieved 7 Sep 2026

- **Type:** SEC settled order making findings and imposing sanctions
- **Verbatim quotes, pin-cited:**

> "Wedbush began providing 'sponsored' market access to customer firms in 2004, which allowed **customer firms and their traders to send orders** that bypassed Wedbush's trading systems and were routed directly to exchanges and other trading venues under a Wedbush MPID. **Sponsored access customers were able to send orders that bypassed Wedbush's systems by using online trading platforms or software programs that the customer either owned directly or leased from a third-party platform provider, referred to as a service bureau.**"
>
> — Rel. 34-73652, ¶13

> "**Customers had access to set and revise the risk settings**, and could disable risk settings intended to prevent violations of specific regulatory requirements … **In addition to Wedbush not having exclusive control over the settings, Wedbush's customers, rather than Wedbush, leased the trading platforms from third parties and Wedbush had no contractual relationship with the platform providers.**"
>
> — Rel. 34-73652, ¶24

- **What it establishes:** The closest located enforcement record to the third-party-software fact pattern: customer-side and vendor-supplied software, configured by the customer, transmitting orders, with **no contractual relationship between broker and vendor.** The Commission consistently describes the orders as sent by "customer firms and their traders." It charged the broker and two of its officers. **It charged no platform provider or service bureau.**
- **Q2 / Q3:** SUPPORT on the characterisation; **Level 1 for any inference from the non-charging**
- **Level 4** for the descriptive language; **Level 1** for the omission.
- **Application note:** The Commission's own narrative names the **customer** as the sender even where the composing and transmitting software belonged to or was leased by the customer from a third party. That is directly supportive on Q3. **But the order gives no reasoning for not charging the vendors, and the shared context forbids inferring safety from silence — so the non-charging establishes nothing.** The configuration also differs materially: Wedbush's customers used *sponsored access under the broker's MPID, bypassing the broker's own systems*, whereas the configuration's member trades through the broker's **own published retail API under his own credentials**, with Rule 15c3-5 pre-trade control intact at the broker. That difference cuts in the configuration's favour.

---

### RE-4.1-09 · NASD Notice to Members 98-66 (Aug 1998) · https://www.finra.org/sites/default/files/NoticeDocument/p004876.pdf · retrieved 7 Sep 2026

- **Type:** SRO notice
- **Date / status:** 1998; concerns SelectNet, a decommissioned system
- **Verbatim quote, pin-cited:**

> "Recently, several members have inquired about the permissibility under NASD rules … for **a member to permit its customers to enter orders into the member's own electronic system and to re-transmit those orders directly and electronically, without the manual entry of such order by a person associated with the member**, into the SelectNet system through an API arrangement. … **The customer is then able to enter orders through this member-provided electronic entry point** … This Notice clarifies that such activity is permissible under NASD rules …"
>
> "Members providing a SelectNet electronic pass-through service to customers must provide a letter to Nasdaq that acknowledges that **they are acting as agents for the nonmember in submitting the order through their facilities** … **Any member providing this service must submit all such orders as an agent on behalf of the customer inputting the order.**"
>
> — NASD NTM 98-66, "Customer Access To SelectNet" and item 1

- **What it establishes:** The earliest located SRO treatment of automated customer order entry through an API. The customer is repeatedly named as **the entering party** ("the customer inputting the order"); the member is the **agent**; and the absence of manual entry by an associated person is **expressly permitted rather than treated as discretion.**
- **Q3:** SUPPORT
- **Level 3** — a 1998 notice about a decommissioned system, addressed to the member, never applied to a non-broker software vendor.
- **Application note:** The sentence "without the manual entry of such order by a person associated with the member" is the point: an SRO expressly blessed order entry with no human in the loop at the member, and located the order with the customer throughout. **What it does not address is the case where a third party's software, rather than the customer's own keystroke, produced the order.**

---

### RE-4.1-10 · FINRA Regulatory Notice 16-21 (May 2016), *Registration of Associated Persons Who Develop Algorithmic Trading Strategies* · https://www.finra.org/rules-guidance/notices/16-21 · retrieved 7 Sep 2026

- **Type:** SRO guidance under an approved rule (Rel. 34-77551, 81 FR 21914, SR-FINRA-2016-007)
- **Verbatim quote, pin-cited:**

> "Under the rule, an '**algorithmic trading strategy' is an automated system that generates or routes orders (including sending orders for routing and order-related messages, such as cancellations), but does not include an automated system that solely routes orders, in their entirety, to a market center.**"
>
> "Similarly, **an algorithm that solely generates trading ideas or investment allocations, including an automated investment service that constructs portfolio recommendations, but that is not equipped to automatically generate orders or order-related messages to effectuate such trading ideas into the market (whether independently or via a linked router), would not constitute an algorithmic trading strategy under the rule.** However, if an order router or investment algorithm performs additional functions that include the generation or routing of orders or order-related messages, such system would be considered an 'algorithmic trading strategy.'"
>
> "**In such cases where the design and development of an algorithmic trading strategy was performed solely by a third-party, the registration requirement would not be triggered with respect to the firm's activities relating to the design or development of such algorithm.**"
>
> — FINRA RN 16-21, "Scope of 'Algorithmic Trading Strategy'" and "Third-Party Algorithms"

- **What it establishes:** FINRA draws an explicit line between a system that **generates or routes orders** and one that **solely generates trading ideas or investment allocations** and is "not equipped to automatically generate orders or order-related messages to effectuate such trading ideas into the market."
- **Q1 / Q2 / Q3:** SUPPORT on the signals-versus-orders line; **ADVERSE on the parenthetical**
- **Level 4** — SRO guidance under an approved rule, but its subject is **which of a member firm's associated persons must hold a Securities Trader registration.** It says nothing about whether a customer's use of non-member software is the customer's own instruction.
- **Application note:** The signals-versus-orders line is exactly the boundary the configuration's integration contract enforces: the engine sends `{rule_id, rule_version, instrument, side, fired_at, source_id, source_signature}` and the contract *rejects* quantity, order type, price, price band, re-peg rule, time-in-force and account. On FINRA's formulation the engine "solely generates trading ideas" and is "not equipped to automatically generate orders." **The parenthetical is the problem: "whether independently or via a linked router."** FINRA expressly pulls an idea-generator into scope where it is *coupled* to something that effectuates the idea into the market. **In V1 per-order mode the coupling is broken by the member's own tap. In standing mode there is no such break, and the engine's signal reaches an order-composing runtime with no human act between them.** Whether a locally installed runtime the member controls, holding no engine credentials and reachable by no engine code path, is "a linked router" for this purpose is **not addressed by RN 16-21 or by any located authority.** This is the sharpest single question standing mode raises under FINRA's own vocabulary.

---

### RE-4.1-11 · FINRA Rule 2360(b)(18)(A)(i) (Options — Discretionary Accounts) · https://www.finra.org/rules-guidance/rulebooks/finra-rules/2360 · retrieved 7 Sep 2026

- **Type:** SRO rule
- **Verbatim quote, pin-cited:**

> "(i) No member and no person associated with a member shall exercise any discretionary power with respect to trading in option contracts in a customer's account, **or accept orders for option contracts for an account from a person other than the customer**, except in compliance with the provisions of Rule 3260 and unless:
> a. The written authorization of the customer required by Rule 3260 shall specifically authorize options trading in the account; and
> b. the account shall have been accepted in writing by a Registered Options Principal or Limited Principal—General Securities Sales Supervisor."
>
> — FINRA Rule 2360(b)(18)(A)(i)

- **What it establishes:** FINRA's options rule regulates **two** things in one sentence: exercising discretionary power, **and accepting an order "from a person other than the customer."** Both require Rule 3260 compliance plus specific written options authorisation.
- **Q3:** **ADVERSE**
- **Level 5** — operative SRO rule text.
- **Application note:** **This is the one located rule that reaches order *acceptance* from a non-customer without requiring any exercise of discretion at all.** It is an options rule and does not reach equities, so it does not bind the configuration's likely instrument set directly. But it demonstrates that the SRO rulebook already contains the concept the configuration most needs to avoid — a duty triggered simply by an order arriving *from someone other than the customer*, irrespective of whose decision it was. **If the analysis ever extends to options, or if the concept is read across, the question stops being "was this discretion?" and becomes "did this order come from the customer?"** — a question standing mode answers less comfortably than per-order mode. Note also that no definition of a "conditional" or "contingent" order appears anywhere in Rule 2360: a full-text search returned **zero** hits for both terms, contrary to the brief's expectation.

---

### RE-4.2-01 · FINRA Rule 3260 (Discretionary Accounts), full text · https://web.archive.org/web/20260331204822/https://www.finra.org/rules-guidance/rulebooks/finra-rules/3260 · **Wayback snapshot dated 31 March 2026**, retrieved 7 Sep 2026

- **Type:** SRO rule
- **Date / status:** current. Rule history as shown on the page: "Amended by SR-FINRA-2019-009 eff. May 8, 2019. Amended by SR-NASD-2002-162 and SR-NASD-2004-116 eff. Jan. 31, 2005. Amended by SR-NASD-92-14 eff. Dec. 10, 1992. Selected Notices: 75-33, 76-30, 91-39, 91-80, 92-25, 93-1, 04-71."
- **Access note:** `finra.org` returned **HTTP 429** and then **HTTP 403** to direct requests during this track's execution (search log 23, 46). The text below is from a Wayback Machine snapshot of FINRA's own page, timestamped **20260331204822**. It is FINRA's own rendering, not a secondary source, but it is a **31 March 2026 snapshot rather than a 7 September 2026 live read**, and is flagged as such.
- **Verbatim quote, pin-cited — the full rule:**

> "**(a) Excessive Transactions**
>
> No member shall effect with or for any customer's account in respect to which such member or his agent or employee is vested with any discretionary power any transactions of purchase or sale which are excessive in size or frequency in view of the financial resources and character of such account.
>
> **(b) Authorization and Acceptance of Account**
>
> No member or registered representative shall exercise any discretionary power in a customer's account unless such customer has given **prior written authorization to a stated individual or individuals** and the account has been accepted by the member, as evidenced in writing by the member or the partner, officer or manager, duly designated by the member, in accordance with Rule 3110.
>
> **(c) Approval and Review of Transactions**
>
> The member or the person duly designated shall approve promptly in writing each discretionary order entered and shall review all discretionary accounts at frequent intervals in order to detect and prevent transactions which are excessive in size or frequency in view of the financial resources and character of the account.
>
> **(d) Exceptions**
>
> **This Rule shall not apply to:**
>
> (1) discretion as to the price at which or the time when an order given by a customer for the purchase or sale of **a definite amount of a specified security** shall be executed, **except that the authority to exercise time and price discretion will be considered to be in effect only until the end of the business day on which the customer granted such discretion, absent a specific, written contrary indication signed and dated by the customer.** This limitation shall not apply to time and price discretion exercised in an institutional account, as defined in Rule 4512(c), pursuant to valid Good-Till-Cancelled instructions issued on a 'not-held' basis. **Any exercise of time and price discretion must be reflected on the order ticket;**
>
> (2) bulk exchanges at net asset value of money market mutual funds ('funds') utilizing negative response letters provided: …"
>
> — FINRA Rule 3260(a)–(d)(1) (emphasis added)

- **What it establishes:** (i) The written-authorization requirement in (b) runs "to a stated individual or individuals," and requires a **second** element — acceptance of the account by the member, evidenced in writing. (ii) The time-and-price exception in (d)(1) requires the order to be for "a definite amount of a specified security"; it is **day-limited** by default, expiring "at the end of the business day on which the customer granted such discretion," unless there is "a specific, written contrary indication signed and dated by the customer"; the day limit is lifted only for **institutional accounts** as defined in Rule 4512(c), on GTC not-held instructions. (iii) Any exercise of time-and-price discretion "must be reflected on the order ticket."
- **Q3:** ADVERSE (see application note)
- **Level 1** — the operative SRO rule text, from FINRA's own page.
- **Application note — and a correction to the brief's framing of question 4.2(d).** The brief asks whether "the exemption run[s] to 'a member or a person associated with a member' only," and asks for the subject of the sentence. **The subject of the exception sentence is not a member. It is "This Rule."** Paragraph (d) reads "This Rule shall not apply to: (1) discretion as to the price at which or the time when an order given by a customer … shall be executed …". It is drafted as a **scope limitation on the Rule**, not as a permission granted to a class of actors. What supplies the member-limitation is the *Rule's own operative paragraphs*: (a) binds "No member," (b) binds "No member or registered representative," and (c) binds "The member or the person duly designated." So the correct factual statement is: **FINRA Rule 3260 imposes duties only on members and registered representatives, and (d)(1) removes a category of conduct from those duties. Neither the duties nor the exception is addressed to anyone else, because the Rule as a whole is not.**
  Stated factually, and without drawing the legal conclusion the shared context forbids: a non-member is not within the class the Rule regulates, so there is nothing in Rule 3260 for a non-member to be exempted *from*, and (d)(1) is not a definition of what does or does not constitute discretion at large — it is a statement of what this Rule does not reach. **A non-member invoking (d)(1) as a *characterisation* — "what we do is only time-and-price discretion, which the rules treat as not requiring written authority" — is borrowing the vocabulary of a rule that does not address it, and no located authority says whether the characterisation travels outside the Rule's own subject class.** That is a gap, not a bar, and it is the same gap identified at DA-4.3(f) for the state rules.
  **Three further points bear directly on standing mode.** First, **(d)(1) is day-limited.** Time-and-price authority expires at the end of the business day on which it was granted unless the customer signs and dates a specific written contrary indication. A *standing* authority is by definition not day-limited, so the default form of (d)(1) does not accommodate standing mode; the written-contrary-indication route does, and it requires a customer signature and date — which returns the analysis to the written-authorization and natural-person questions at RE-4.3-01 and RE-4.2-01(b). Second, **the escape from the day limit is conditioned on an institutional account** under Rule 4512(c), on GTC not-held instructions. The configuration's members are retail. This is the same institutional-account condition that constrains the *S3 Matching Technologies* letter already in the register — **the second time an otherwise-apposite authority turns out to be gated on institutional status.** Third, (d)(1) requires "a definite amount of a specified security," which the configuration's envelope is expressly built to satisfy, and requires that any exercise of time-and-price discretion "be reflected on the order ticket" — a duty falling on the member firm, i.e. the member's own broker, not on the runtime.
  **Comparison to the state rules is now sharp.** Washington's current broker-dealer carve-out, WAC 460-20C-210(6) (RE-4.3-08), reads "unless the discretionary power relates solely to the time and/or price for the execution of orders" — **no definite-amount requirement, no day limit, and no institutional-account gate.** On the face of the two texts, Washington's carve-out is materially broader than FINRA's on all three axes.

---

### RE-4.3-04 · *Investment Adviser Association*, SEC Staff No-Action Letter, Investment Advisers Act §206(4) and Rule 206(4)-2 (21 Feb 2017) · https://www.sec.gov/divisions/investment/noaction/2017/investment-adviser-association-022117-206-4.htm · retrieved 7 Sep 2026

- **Type:** no-action letter (Division of Investment Management, Chief Counsel's Office; signed Aaron T. Gilbride, Senior Counsel)
- **Date / status:** issued 21 February 2017, responding to an incoming letter dated 15 February 2017. No later letter withdrawing or modifying it was located (see Negative finding NF-4)
- **Verbatim quotes, pin-cited:**

The question presented:

> "Your letter dated February 15, 2017 requests clarification that an investment adviser does not have custody as set forth in Rule 206(4)-2 ('Custody Rule') under the Investment Advisers Act of 1940 ('Advisers Act') if it acts pursuant to a standing letter of instruction or other similar asset transfer authorization arrangement established by a client with a qualified custodian ('SLOA')."

The facts as represented — note the characterisation language:

> "It is common for a client to grant its registered investment adviser the limited power in a SLOA to disburse funds to one or more third parties as specifically designated by the client. After granting the investment adviser this limited authorization, the client then instructs the qualified custodian for the client's account to accept the investment adviser's direction on the client's behalf to move money to the third party designated by the client on the SLOA. The qualified custodian takes that instruction in writing directly from the account holder (the investment adviser's client), and the investment adviser's authority is limited by the terms of that instruction. **The investment adviser is authorized to act merely as an agent for the client. The client retains full power to change or revoke the arrangement.**"

**The staff's disposition — this is the part the brief's framing inverts:**

> "**We disagree.** An investment adviser with power to dispose of client funds or securities **for any purpose other than authorized trading** has access to the client's assets. We believe that a letter of instruction or other similar asset transfer authorization arrangement established by a client with a qualified custodian would constitute an arrangement under which an investment adviser is authorized to withdraw client funds or securities maintained with a qualified custodian upon its instruction to the qualified custodian. **An investment adviser that enters into such an arrangement with its client would therefore have custody of client assets and would be required to comply with the Custody Rule.** Notwithstanding this view, staff of the Division of Investment Management would not recommend enforcement action to the Commission under Section 206(4) of, and Rule 206(4)-2 under, the Advisers Act against an investment adviser if that adviser does not obtain a surprise examination where it acts pursuant to such an arrangement under the following circumstances:"

**THE SEVEN REPRESENTATIONS, VERBATIM AND IN ORDER** (the letter presents them as an unnumbered bulleted list; the numbering below is added for reference and is not in the original):

> **1.** "The client provides an instruction to the qualified custodian, in writing, that includes the client's signature, the third party's name, and either the third party's address or the third party's account number at a custodian to which the transfer should be directed."
>
> **2.** "The client authorizes the investment adviser, in writing, either on the qualified custodian's form or separately, to direct transfers to the third party either on a specified schedule or from time to time."
>
> **3.** "The client's qualified custodian performs appropriate verification of the instruction, such as a signature review or other method to verify the client's authorization, and provides a transfer of funds notice to the client promptly after each transfer."
>
> **4.** "The client has the ability to terminate or change the instruction to the client's qualified custodian."
>
> **5.** "The investment adviser has no authority or ability to designate or change the identity of the third party, the address, or any other information about the third party contained in the client's instruction."
>
> **6.** "The investment adviser maintains records showing that the third party is not a related party of the investment adviser or located at the same address as the investment adviser."
>
> **7.** "The client's qualified custodian sends the client, in writing, an initial notice confirming the instruction and an annual notice reconfirming the instruction."

The closing reservation:

> "This conclusion is based on all of the facts and representations set forth in your letter. You should note that any different facts or representations might require a different conclusion. Further, this response expresses our position only with respect to enforcement action, and does not express any legal conclusion on the issues presented."

**Footnote 1 — the most load-bearing sentence in the letter for this track:**

> "[1] The staff understands that there is no standardized format for a SLOA. Investment advisers, qualified custodians and their clients have developed a wide variety of SLOAs for third-party transfers, each of which could implicate the Custody Rule **depending on the extent of the adviser's discretion to act**. For example, **an arrangement that is structured so that the investment adviser does not have discretion as to the amount, payee, and timing of transfers under a SLOA would not implicate the Custody Rule.**"

Footnote 8, which sources the "access" proposition:

> "[8] Custody of Funds or Securities of Clients by Investment Advisers, Investment Advisers Act Release No. 2176 (Sep. 25, 2003), text accompanying footnote 10."

**From the incoming letter** (Investment Adviser Association to Douglas J. Scheidt, Associate Director and Chief Counsel, 15 Feb 2017, at p.2), retrieved at `https://www.sec.gov/divisions/investment/noaction/2017/investment-adviser-association-022117-206-4-incoming.pdf`, 7 Sep 2026 — **the argument the staff rejected, stated in the requester's own words:**

> "The limited authority of an adviser under an SLOA arrangement is different, for example, from an investment adviser serving as a trustee with power to disburse funds out of the account to any third party if, in the view of the trustee, it was consistent with the purpose of the trust. **It is also in contrast to an arrangement, such as general bill-paying or check-writing authority, in which an adviser has a full power of attorney on an account or broad discretionary authority to withdraw client funds upon the adviser's direction to the qualified custodian and make disbursements to any third party on behalf of the client.**"

- **What it establishes:** A written, bounded, client-established standing authorization under which another party later transmits instructions to a custodian **is** an arrangement conferring custody on that party, notwithstanding that the client signed it, bounded it, can revoke it, and the actor "is authorized to act merely as an agent for the client." Relief was granted only from the surprise-examination requirement, and only on seven conditions. Separately, footnote 1 states that where the actor has **no discretion as to amount, payee and timing**, the Custody Rule is not implicated at all.
- **Q3:** ADVERSE on the main holding; SUPPORT on footnote 1
- **Q2:** NEUTRAL (this is an Advisers Act custody question, not a §3(a)(4) question)
- **Level 2** — staff no-action position, no legal force, expressly disclaiming any legal conclusion; but it is the SEC staff's only sustained written treatment of a bounded written standing authority executed later by another party.
- **Application note:** This is the closest instrument in US securities law to a bounded standing authority granted in writing and executed later by another party, and it must be read for what it actually says. Three things bear directly on standing mode.
  **First, and adverse:** every feature the configuration relies on to argue that a standing instruction remains the member's own — the client's signature, the written bound, the client's power to revoke, the actor's status as "merely… an agent for the client" — was **present in the SLOA facts and did not prevent a finding of custody.** The staff said "We disagree" to exactly that argument. A design memo that treats bounded-plus-revocable-plus-written as self-evidently keeping the instruction the customer's own is contradicted by the only staff letter on the point.
  **Second, and supporting:** footnote 1 supplies the dividing line the design actually needs. Discretion "as to the **amount, payee, and timing**" is what implicates the rule; an arrangement structured so the actor has none of those does not implicate it. In standing mode the runtime composes from the member's own local policy: sizing, order type, price band, re-peg rule, time-in-force, account and instrument are all typed by the member; the *timing* is determined by the engine's signal firing against the member's own thresholds. The amount and the instrument trace to member settings. **Timing is the exposed variable** — it is the one parameter in footnote 1's triad that the member does not fix in advance to a specific value, and it is the parameter the machine determines. Footnote 1 is a conjunctive list ("the amount, payee, and timing"), and no located authority says whether all three must be absent or whether any one suffices.
  **Third:** the sentence "An investment adviser with power to dispose of client funds or securities **for any purpose other than authorized trading** has access to the client's assets" expressly carves *authorized trading* out of what counts as access. Trading authority, on the staff's own formulation, is not what makes an actor a custodian. That distinguishes the whole custody line from the trading-authority question and is worth stating plainly rather than importing custody reasoning wholesale.
  **Disanalogy to state:** the SLOA line concerns **asset transfers to third parties**, not trading. Its seven representations are built around a *payee* — an element with no counterpart in standing mode, where nothing moves to a third party and the member's own account is both source and destination. Representations 1, 5 and 6 are payee-identity controls and do not map. Representations 2, 3, 4 and 7 do map, and they are the ones the design should be measured against: a separate written authorization (rep 2), verification by the account-holding institution plus a prompt per-event notice to the client (rep 3), a client power to terminate or change (rep 4), and an initial plus **annual reconfirmation** notice sent by the custodian (rep 7). The configuration's journal, emergency stop and approval surface address parts of 3 and 4; **nothing in the configuration corresponds to rep 7's annual reconfirmation, and rep 3's verification and notice are performed by the *custodian*, not by the actor holding the authority.**

---

### RE-4.3-05 · 17 C.F.R. §275.206(4)-2(d)(2) (Custody of funds or securities of clients by investment advisers — definition of custody) · https://www.ecfr.gov/api/versioner/v1/full/2026-09-01/title-17.xml?part=275&section=275.206(4)-2 · retrieved 7 Sep 2026

- **Type:** rule (federal regulation)
- **Date / status:** current as of the eCFR snapshot dated 2026-09-01
- **Verbatim quote, pin-cited:**

> "(2) *Custody* means holding, directly or indirectly, client funds or securities, or having any authority to obtain possession of them. You have custody if a related person holds, directly or indirectly, client funds or securities, or has any authority to obtain possession of them, in connection with advisory services you provide to clients. Custody includes:
>
> (i) Possession of client funds or securities (but not of checks drawn by clients and made payable to third parties) unless you receive them inadvertently and you return them to the sender promptly but in any case within three business days of receiving them;
>
> (ii) **Any arrangement (including a general power of attorney) under which you are authorized or permitted to withdraw client funds or securities maintained with a custodian upon your instruction to the custodian;** and
>
> (iii) Any capacity (such as general partner of a limited partnership, managing member of a limited liability company or a comparable position for another type of pooled investment vehicle, or trustee of a trust) that gives you or your supervised person legal ownership of or access to client funds or securities."
>
> — 17 C.F.R. §275.206(4)-2(d)(2)

- **What it establishes:** The operative definition on which the SLOA letter turns. Sub-paragraph (ii) is drafted around an arrangement permitting withdrawal "upon your instruction to the custodian," and expressly includes a general power of attorney.
- **Q3:** NEUTRAL / context
- **Level 1** — a Commission rule, quoted for the definitional text the SLOA letter applies.
- **Application note:** The configuration involves no withdrawal of funds or securities and no third-party payee; trade-capable credentials sit only in the member's own local vault and nothing is disbursed anywhere. Sub-paragraph (ii) is not engaged on its face. Recorded because RE-4.3-04 cannot be read without it, and because the staff's "other than authorized trading" carve-out is a gloss on this definition.

---

### RE-4.2-02 · *In the Matter of the Application of Michael Pino*, Exchange Act Rel. No. 74903 (7 May 2015), Admin. Proc. File No. 3-15935 — Opinion of the Commission · https://www.sec.gov/litigation/opinions/2015/34-74903.pdf · read from Wayback snapshot `20220716171013`, retrieved 7 Sep 2026

- **Type:** Opinion of the Commission on review of FINRA disciplinary action
- **Date / status:** 7 May 2015; good law. Caption: "Discretionary Trading without Written Authorization / Conduct Inconsistent with Just and Equitable Principles of Trade"
- **Access note:** `sec.gov` returned **HTTP 429** repeatedly during this track (search log 64–65). Read from the Internet Archive snapshot of sec.gov's own PDF, 159,699 bytes, 10 pages, 53,813 characters extracted.
- **Verbatim quotes, pin-cited — heading and holding at slip op. 11–13:**

> "**B. The 'time and price discretion' exception to Rule 2510 does not apply here.**
>
> Pino argued in the proceeding below that the customer had granted 'time and price discretion' over the earnings strategy sales transactions when the customer agreed to the initial purchases of securities.17 **But a customer's approval of a general strategy does not meet the requirements of the 'time and price discretion' exception to Rule 2510.**18 NASD Rule 2510 does not apply to a registered representative exercising 'discretion as to the price at which or the time when an order given by a customer for the purchase or sale of a definite amount of a specified security shall be executed.'19 Further, 'time and price discretion will be considered to be in effect only until the end of the business day on which the customer granted such discretion, absent a specific, written contrary indication signed and dated by the customer.'20
>
> **We find that the time and price discretion exception does not apply to the ninety-three violative sales transactions in the customer's accounts. Pino did not meet the exception's requirements because he was not granted discretion by the customer as to the sale of definite amounts of specified securities in the customer's accounts, and Pino was not granted such discretion on the same business day that he executed the sales transactions.**"

**Footnote 17 — the respondent's own characterisation, and the Commission's rejection of it:**

> "17 In fact, during the hearing, Pino characterized his earnings strategy trading as not being an exercise of discretion, stating that he simply tried '**to sell something based on a strategy that's been well in place, that to me is not discretion.**'"

**Footnote 18 — the supporting chain:**

> "18 See Murphy, 2013 WL 3327752, at *8 (**stating that approval of a covered call strategy did not mean that trading would come within the time and price discretion exception**); Raghavan Sathianathan, Exchange Act Release No. 54722, 2006 WL 3228694, at *12 (Nov. 8, 2006) (**rejecting applicant's claim that the time and price discretion exception applied where a representative and customer had 'discussed a general strategy' to buy and sell a specific security, but did not discuss the amounts of the security to be purchased and sold**)."

**Footnote 21:**

> "21 See Sathianathan, 2006 WL 3228694, at *12 (**holding that Rule 2510(d) exception does not apply where customer and broker have not agreed as to the specific amounts of the transaction and where purchases are made pursuant to a 'general strategy'**)."

**And on the day limit, at slip op. 13:**

> "Second, none of the sales in the customer's accounts occurred on the same business day as the purchases.24 … And when a NAC panelist mentioned the requirement that time and price discretion must be exercised on the same business day that it is granted, Pino said, '**then I'm guilty of the charge . . . [and] there's no need going further with this.**'"

Related authorities identified in the same chain: *William J. Murphy*, Exchange Act Rel. No. 69923 (2 Jul 2013), 2013 WL 3327752, at *8; *Raghavan Sathianathan*, Exchange Act Rel. No. 54722 (8 Nov 2006), 2006 WL 3228694, at *12. Both were subsequently retrieved in full and are quoted directly at RE-4.2-06 (◇5 closed).

- **What it establishes:** The Commission's own holding on what **exceeds** the time-and-price exception. Two independent failure modes, either of which defeats the exception: **(1) the customer did not grant discretion as to "definite amounts of specified securities"** — approval of a *general strategy* is not enough; and **(2) the discretion was not granted on the same business day as execution.**
- **Q3:** **ADVERSE — the most directly adverse authority located in this track**
- **Level 1** — an Opinion of the Commission, on review, squarely construing the provision, with a supporting chain of two earlier Commission opinions.
- **Application note:** **This answers question 4.2(b) and it answers it badly for standing mode.**
  **First and most directly:** the argument the respondent made is, in substance, the argument standing mode rests on. Pino said he "simply tried *to sell something based on a strategy that's been well in place, that to me is not discretion.*" The Commission rejected it in terms: "**a customer's approval of a general strategy does not meet the requirements of the 'time and price discretion' exception.**" *Murphy* rejected the same argument for a covered-call strategy; *Sathianathan* rejected it where the representative and customer "discussed a general strategy … but did not discuss the amounts." **A configuration in which the member approves a rule set in advance and the machine later sells pursuant to it is, on the face of these three opinions, approval of a general strategy — not a grant of discretion over "a definite amount of a specified security."**
  **Second:** the "definite amount of a specified security" requirement is not satisfied by the *order* being definite at the moment of execution. It requires that **the customer granted the discretion as to a definite amount of a specified security.** Pino failed it "because he did not speak with the customer before executing these sales transactions." The configuration's envelope makes the *composed order* definite as to security and quantity — but in standing mode the member is not consulted before the order exists, and the definiteness is supplied by the member's *policy* rather than by a per-transaction grant. **The opinions locate the definiteness requirement on the grant, not on the order.** That distinction is the whole of the difference between per-order mode and standing mode, and these opinions put it on the adverse side.
  **Third:** the day limit was applied as an independent, dispositive ground, and the respondent conceded it. See A3a.
  **What it does not decide:** every one of these cases concerns a **registered representative** exercising discretion in a customer's account at his member firm, with an oral or implied grant and no writing. None involves software, a written standing authorization, a member-authored rule set, or a customer-operated runtime. The configuration's per-order V1 mode, in which the member affirmatively taps each composed order on a runtime-owned surface, does not present the fact pattern these opinions address at all — there, the customer *is* consulted before every execution, which is precisely what Pino failed to do.

---

### RE-4.2-03 · SEC Rel. No. 34-49883, *Order Approving Proposed Rule Change (SR-NASD-2002-162)* (17 Jun 2004) · https://www.sec.gov/files/rules/sro/nasd/34-49883.pdf · retrieved 7 Sep 2026

- **Type:** SEC approval order — the order that created the day limit in 2510(d)(1)
- **Date / status:** final; good law
- **Verbatim quotes, pin-cited:**

> "Commenters also requested that NASD clarify that the requirement to obtain written instructions for the exercise of time and price discretion beyond the business day it was granted **allows customers to issue general 'standing' instructions, rather than issuing written instructions on an order-by-order basis. NASD declined to adopt this position.**"
>
> — Rel. 34-49883 at 7

> "In Amendment No. 1, NASD pointed out that **the current text of NASD Rule 2510(d) clearly limits the exercise of time and price discretion to 'the purchase or sale of a definite amount of a specified security. . . .'** NASD noted that **any written authorization granting time and price discretion must comply with this established, trade-specific standard** and that customers who wish to grant more extensive discretionary authority to their registered representatives may do so pursuant to a fully executed trading authorization."
>
> — Rel. 34-49883 at 7

> "Currently, NASD Rule 2510(d)(1) **allows members to exercise time and price discretion** on orders for the purchase or sale of a definite amount of a specified security without prior written authorization from the customer and prior written approval by the member, but does not specify the duration of such discretionary authority. The Commission believes that NASD's proposal to limit the time for such discretion to the end of the business day on which it was granted, absent a signed authorization from the customer providing otherwise, is appropriate. **Such a control should limit the opportunity for misapplication of discretionary authority, thus furthering investor protection.**"
>
> — Rel. 34-49883 at 33 (the Commission's own statement)

- **What it establishes:** **The written extension that lifts the day limit was expressly held to require order-by-order instructions, not general standing instructions.** Commenters asked for standing instructions; NASD refused; the Commission approved the rule on that footing. The standard is, in NASD's own word, "**trade-specific**." Anything broader requires "a fully executed trading authorization" — i.e. it exits the exception entirely and re-enters Rule 3260(b), with its "stated individual or individuals."
- **Q3:** **ADVERSE — this is the most directly on-point adverse authority located in the entire track for standing mode**
- **Level 3** — a Commission approval order; the "trade-specific" sentence is the Commission reporting NASD's position, the p.33 passage is the Commission speaking in its own voice.
- **Application note:** **The design's standing track asks for exactly what was requested and refused here.** In standing mode the member's local policy fixes price band, re-peg rule and time-in-force in advance and re-applies them to every order — a standing parameter set. The one route by which FINRA Rule 3260(d)(1)'s day limit can be lifted for a retail account is "a specific, written contrary indication signed and dated by the customer," and **this order records that the regulator declined to let that be a general standing instrument rather than an order-by-order one.** The configuration does not distinguish this authority; it answers a different question (it re-obtains a human act each order in V1), which is precisely the thing standing mode removes. **Recorded at threat 5.**

---

### RE-4.2-04 · FINRA Rule 4512(a)(3) (Customer Account Information) · https://www.finra.org/rules-guidance/rulebooks/finra-rules/4512 · retrieved 7 Sep 2026

- **Type:** SRO rule (operative text)
- **Date / status:** good law; amended by SR-FINRA-2019-009 eff. 8 May 2019
- **Verbatim quote, pin-cited:**

> "(3) for discretionary accounts maintained by a member, in addition to compliance with subparagraph (1) and, to the extent applicable, subparagraph (2) above, and Rule 3260, the member shall maintain a record of the dated, signature of each named, associated person of the member authorized to exercise discretion in the account. **This recordkeeping requirement shall not apply to investment discretion granted by a customer as to the price at which or the time to execute an order given by a customer for the purchase or sale of a definite dollar amount or quantity of a specified security.** Nothing in this Rule shall be construed as allowing members to maintain discretionary accounts or exercise discretion in such accounts except to the extent permitted under the federal securities laws."
>
> — FINRA Rule 4512(a)(3)

And the institutional-account definition to which Rule 3260(d)(1) cross-refers:

> "(c) For purposes of this Rule, the term 'institutional account' shall mean the account of: (1) a bank, savings and loan association, insurance company or registered investment company; (2) an investment adviser registered either with the SEC under Section 203 of the Investment Advisers Act or with a state securities commission …; or (3) any other person (whether a natural person, corporation, partnership, trust or otherwise) with **total assets of at least $50 million**."
>
> — FINRA Rule 4512(c)

- **What it establishes:** **The FINRA rulebook itself labels time-and-price latitude "investment discretion granted by a customer."** It is not characterised as an absence of discretion; it is characterised as discretion relieved of one recordkeeping consequence. And Rule 4512(c) fixes the institutional threshold at **$50 million in total assets** — the gate on Rule 3260(d)(1)'s only route out of the day limit.
- **Q1 / Q3:** **ADVERSE — the single most adverse text located on the characterisation question**
- **Level 5** — operative SRO rule text.
- **Application note — three divergences from Rule 3260(d)(1), none reconciled by any located source:**

| | FINRA 3260(d)(1) | FINRA 4512(a)(3) |
|---|---|---|
| Label | "discretion as to the price at which or the time when…" — "investment" never appears | "**investment discretion** granted by a customer as to the price at which or the time to execute an order" |
| Quantity formula | "a **definite amount** of a specified security" | "a **definite dollar amount or quantity** of a specified security" |
| Day limit | **Present** | **Absent** |
| Order-ticket requirement | **Present** | **Absent** |
| Institutional GTC carve-out | **Present** | **Absent** |

  **The two provisions describe the same latitude and do not contradict each other, but they are not a single coherent definition, and the label cuts against the configuration.** FINRA proposed harmonising 3260's "definite amount" to 4512's "definite dollar amount or quantity" **twice** — RN 09-63 (2009) and RN 15-22 (2015), Attachment A — and neither proposal was adopted. **A design that describes its envelope as "not discretion, merely price-and-time latitude" is using a characterisation the FINRA rulebook itself does not use.**

---

### RE-4.2-05 · *In the Matter of the Application of Jason Lynn DiPaola*, Exchange Act Rel. No. 34-105568, Admin. Proc. 3-21402 (**28 May 2026**) · https://www.sec.gov/files/litigation/opinions/2026/34-105568.pdf · retrieved 7 Sep 2026

- **Type:** Opinion of the Commission on review of FINRA disciplinary action — **the most recent Commission statement located on this subject, four months before this register's date**
- **Verbatim quotes, pin-cited (at pp. 6–7):**

> "**The Commission has held that one exercises such discretion for purposes of Rule 3050 when the person makes trades in someone else's account without first receiving approval for the trades.** … **The Commission has also held in other contexts that, even when the representative has communicated with a customer and discussed a general trading strategy, the representative exercises discretion if the representative and customer did not discuss the individual trades.** That was the case here."

> "n.8 · Cf. Michael Pino … (noting that **determining the price at which a trade occurs is an exercise of discretion subject to only a limited exception to discretionary trading requirements under FINRA rules**)."

- **What it establishes:** As of May 2026 the Commission's operative formulations are (i) discretion is making trades "**without first receiving approval for the trades**"; (ii) a general trading strategy plus no discussion of the individual trades **is** discretion; and (iii) at n.8, "**determining the price at which a trade occurs is an exercise of discretion subject to only a limited exception.**"
- **Q1 / Q2 / Q3:** **ADVERSE**
- **Level 5** — an Opinion of the Commission, and the most recent located.
- **Application note:** **Two edges, and they point in opposite directions for the two modes.** The Commission's dividing line — trades made "**without first receiving approval for the trades**" — is the line V1 per-order mode is built to sit on the safe side of: the member approves each complete composed order on a runtime-owned surface before it goes. **That is a clean, current, Commission-stated test that per-order mode satisfies on its face.** **Standing mode does not satisfy it**, because standing execution is by definition trading without per-order approval, on a general strategy, with the individual trades never discussed. And footnote 8 is the most directly adverse single sentence located for the configuration's price band and re-peg rule: **determining the price at which a trade occurs is itself an exercise of discretion**, saved only by a "limited exception" whose conditions are set out at RE-4.2-01 and which is day-limited and retail-gated.

---

### RE-4.2-06 · *Dep't of Enforcement v. William J. Murphy, Carl M. Birkelbach and Birkelbach Investment Securities, Inc.*, FINRA NAC, Complaint No. 2005003610701 (20 Oct 2011) · https://www.finra.org/sites/default/files/NACDecision/p124827.pdf · retrieved 7 Sep 2026 — **and** *William J. Murphy*, Exchange Act Rel. No. 34-69923 (2 Jul 2013), *aff'd sub nom. Birkelbach v. SEC*, 751 F.3d 472 (7th Cir. 2014)

- **Type:** SRO appellate tribunal decision, sustained on Commission review
- **Verbatim quote, pin-cited — the NAC at pp. 15–16, and this is the affirmative gloss:**

> "**There is no evidence, however, that Murphy and AL discussed time limits or price ranges with respect to specific orders, let alone which specific options series or quantities to purchase or how frequently to trade.** Instead, Murphy discussed with AL only her overall request to execute a covered call strategy. **Such general strategy discussions did not establish time and price discretion.** … Moreover, although Murphy made numerous trades that were not covered calls, he and AL never discussed effecting any such options trades …, let alone any **parameters that governed the time and price limitations on executing such trades. We therefore reject respondents' argument that any of Murphy's trading fell within the time and price discretion exception.**"

And the Commission on review, at pp. 12–13:

> "**For the exception to apply, Lowry would have had to direct Murphy to buy or sell a definite amount of a security, but there is no evidence that she ever gave Murphy any such direction. Put another way, Murphy's trading did not involve the exercise of discretion only over the timing and prices related to the options transactions in Lowry's account, but also over the type and quantity of options transacted.**"
>
> — Rel. 34-69923 at 12

- **What it establishes:** Two things. **The exclusivity requirement:** the latitude must extend to **nothing but** price and time — any latitude over *type* or *quantity* destroys the exception. And **the affirmative description**, which is the only located statement of what a compliant grant contains: "**time limits or price ranges with respect to specific orders**" and "**parameters that governed the time and price limitations on executing such trades.**"
- **Q3:** ADVERSE on the holding; **the affirmative gloss is the most SUPPORT-shaped sentence in the whole adjudicated line**
- **Level 3** for the NAC; **Level 5** for the Commission's affirmance.
- **Application note:** "Time limits or price ranges with respect to specific orders" and "parameters that governed the time and price limitations on executing such trades" is close to a verbatim description of the configuration's envelope — price band, re-peg rule, time-in-force, day-limited, per order. **This is the closest fit located anywhere between the configuration's envelope and any tribunal's description of what the exception properly contains.** Two cautions that must not be dropped: it is a **negative-space** description — the NAC was listing what was *missing* — and it **says nothing about who may hold those parameters.** Note also, for citation accuracy: *Birkelbach v. SEC*, 751 F.3d 472 (7th Cir. 2014), affirmed, but a full-text review confirms **the Seventh Circuit opinion contains no reference to time-and-price discretion, Rule 2510, or "definite amount."** No court has construed the words of the exception.

---

### RE-4.3-05a · *Withdrawal of Proposed Regulatory Actions*, Rel. Nos. 33-11377; 34-103247; **IA-6885**; IC-35635 (17 Jun 2025), 90 FR 25531 · https://www.federalregister.gov/documents/full_text/text/2025/06/17/2025-11110.txt · retrieved 7 Sep 2026

- **Type:** release (notice of withdrawal of proposed rules)
- **Date / status:** effective 17 June 2025; current
- **Verbatim quote, pin-cited:**

> "SUMMARY: The Securities and Exchange Commission ('Commission') is formally withdrawing certain notices of proposed rulemaking issued between March 2022 and November 2023. **The Commission does not intend to issue final rules with respect to these proposals.** If the Commission decides to pursue future regulatory action in any of these areas, it will issue a new proposed rule."
>
> "DATES: The Commission is withdrawing the proposed rules published at … **88 FR 14672 (March 9, 2023)** … as of June 17, 2025."
>
> — 90 FR 25531, 25531 (Summary and Dates)

The withdrawn item is identified in the body under its own heading:

> "*Safeguarding Advisory Client Assets*
>
> On March 9, 2023, the Commission published a proposed new rule under the Advisers Act to address how investment advisers safeguard client assets.\3\ …
>
> \3\ 88 FR 14672 (Mar. 9, 2023). The Commission published a release reopening the comment period for this rule proposal on Aug. 30, 2023. Safeguarding Advisory Client Assets; Reopening of Comment Period, 88 FR 59818 (Aug. 30, 2023)."
>
> — 90 FR 25531, at the "Safeguarding Advisory Client Assets" heading and n.3

- **What it establishes:** The 2023 *Safeguarding Advisory Client Assets* proposal (Rel. IA-6240, 88 FR 14672), which would have replaced Rule 206(4)-2 and which proposed to treat discretionary trading authority as triggering the safeguarding regime, was **formally withdrawn on 17 June 2025**, with the Commission stating it does not intend to issue final rules on it.
- **Q3:** NEUTRAL — but materially changes the currency of the surrounding law
- **Level 1** — a Commission release stating the disposition of its own rulemaking.
- **Application note:** This closes a currency question that would otherwise sit under the whole of the custody analysis. **Rule 206(4)-2 as quoted at RE-4.3-05 remains the operative custody rule; the proposal that would have superseded it is dead.** It follows that the IAA SLOA letter (RE-4.3-04) is a staff position interpreting a rule that is still in force and still worded as it was in 2017 — so the letter's adverse reasoning at A1 cannot be discounted as commentary on superseded law. It also means the 2023 proposal's treatment of discretionary trading authority has no operative force and should not be cited as if it did. Any analysis relying on the 2023 proposal as a signal of the Commission's direction is now unsupported: the Commission said it does not intend to finalise it.

---

### RE-4.3-06 · 12 C.F.R. §1005.10(b) (Regulation E — preauthorized transfers) and Official Interpretations, Supplement I, comment 10(b)-5 · https://www.ecfr.gov/api/versioner/v1/full/2026-09-01/title-12.xml?part=1005&section=1005.10 and …&appendix=Supplement I to Part 1005 · retrieved 7 Sep 2026

- **Type:** rule (federal regulation) plus official agency commentary
- **Date / status:** current as of the eCFR snapshot dated 2026-09-01
- **Verbatim quotes, pin-cited:**

> "(b) *Written authorization for preauthorized transfers from consumer's account.* Preauthorized electronic fund transfers from a consumer's account may be authorized only by a writing signed or similarly authenticated by the consumer. The person that obtains the authorization shall provide a copy to the consumer."
>
> — 12 C.F.R. §1005.10(b)

> "(c) *Consumer's right to stop payment*—(1) *Notice.* A consumer may stop payment of a preauthorized electronic fund transfer from the consumer's account by notifying the financial institution orally or in writing at least three business days before the scheduled date of the transfer."
>
> — 12 C.F.R. §1005.10(c)(1)

Official Interpretations, Supplement I to Part 1005, under the heading "10(b) Written Authorization for Preauthorized Transfers From Consumer's Account":

> "3. *Written authorization for preauthorized transfers.* The requirement that preauthorized EFTs be authorized by the consumer 'only by a writing' cannot be met by a payee's signing a written authorization on the consumer's behalf with only an oral authorization from the consumer."
>
> "5. *Similarly authenticated.* The similarly authenticated standard permits signed, written authorizations to be provided electronically. The writing and signature requirements of this section are satisfied by complying with the Electronic Signatures in Global and National Commerce Act, 15 U.S.C. 7001 et seq., which defines electronic records and electronic signatures. Examples of electronic signatures include, but are not limited to, digital signatures and security codes. A security code need not originate with the account-holding institution. **The authorization process should evidence the consumer's identity and assent to the authorization.** The person that obtains the authorization must provide a copy of the terms of the authorization to the consumer either electronically or in paper form. **Only the consumer may authorize the transfer and not, for example, a third-party merchant on behalf of the consumer.**"
>
> "6. *Requirements of an authorization.* An authorization is valid if it is readily identifiable as such and the terms of the preauthorized transfer are clear and readily understandable."
>
> — Supplement I to 12 C.F.R. Part 1005, comments 10(b)-3, 10(b)-5, 10(b)-6

- **What it establishes:** An express federal model of a standing authorization that remains the consumer's own: it must be in a writing signed or "similarly authenticated" by the consumer; electronic form is expressly sufficient via E-SIGN; the standard for the authorization process is that it "evidence the consumer's identity and assent"; the authorization is valid if "readily identifiable as such and the terms … are clear and readily understandable"; and the consumer retains a stop-payment right exercisable up to three business days before a scheduled transfer.
- **Q3:** SUPPORT — **as an analogy, expressly labelled**
- **Level 4** — this is consumer financial-services law under the EFTA, not securities law. It binds no securities actor and no securities regulator has adopted it. It is offered as a structural comparator only.
- **Application note (ANALOGY — labelled).** Reg E is the clearest instrument located in federal law in which a standing authorization, configured once and executed repeatedly later by another party's systems, is treated throughout as *the consumer's own* authorization. Three features map onto the configuration's standing-mode design with unusual precision: (i) an express electronic-form standard tied to E-SIGN, with the substantive test being **identity plus assent** — which is exactly what the configuration's immutable instruction record, bound to member, account, scope, timestamp and nonce, is built to evidence; (ii) a requirement that the terms be "clear and readily understandable" and the authorization "readily identifiable as such" — which is what the runtime-owned approval surface displaying the complete composed order is built to satisfy; and (iii) a durable consumer power to stop. **The disanalogies are substantial and must be stated:** Reg E governs funds transfers, not securities transactions; it imposes no registration consequence on anyone; comment 10(b)-5's closing sentence ("Only the consumer may authorize the transfer and not, for example, a third-party merchant on behalf of the consumer") is a limit on *who may give* the authorization, not a statement that a machine may *execute* under it; and nothing in Reg E addresses whether the party executing the standing authorization thereby becomes a regulated intermediary. **The contrast is the finding:** Reg E tells you exactly what form a standing authorization must take and expressly blesses electronic execution. The securities instruments surveyed in this track — FINRA Rule 3260(b), 17 C.F.R. §240.17a-3(a)(17)(ii), WAC 460-20C-210(6), WAC 460-24A-220(5) — say "written," "prior written," "dated signature," and stop. **None of them contains an express electronic-form standard.** See NF-5.

---

### RE-4.3-07 · WAC 460-24A-220 (Washington — Dishonest or unethical business practices, investment advisers) · https://app.leg.wa.gov/WAC/default.aspx?cite=460-24A-220 · retrieved 7 Sep 2026

- **Type:** state administrative rule
- **Date / status:** current
- **Verbatim quotes, pin-cited:**

The lead-in, which fixes whom the rule binds:

> "If you are an investment adviser, investment adviser representative, or a federal covered adviser, you are a fiduciary and have a duty to act primarily for the benefit of your clients. … in accordance with RCW 21.20.020 (1)(c) and 21.20.110 (1)(g) you must not engage in dishonest or unethical business practices including, but not limited to, the following:"

> "(2) Exercising any discretion in placing an order for the purchase or sale of securities for a client without obtaining written discretionary authority from the client within ten business days after the date of the first transaction placed pursuant to oral discretionary authority, **unless the discretion relates solely to the price at which, or the time when, an order involving a definite amount of a specified security must be executed, or both.**"

> "(4) Placing an order to purchase or sell a security for the account of a client without authority to do so."

> "(5) **Placing an order to purchase or sell a security for the account of a client upon instruction of a third party without first having obtained a written third-party trading authorization from the client.**"
>
> — WAC 460-24A-220, lead-in and subsections (2), (4), (5)

- **What it establishes:** Washington's investment-adviser conduct rule contains both a time-and-price carve-out from the written-discretionary-authority requirement and a separate, unqualified requirement of a "written third-party trading authorization" before placing an order on a third party's instruction.
- **Q3:** ADVERSE (a written authorization is required whenever the order is placed on a third party's instruction, with no carve-out) / NEUTRAL as to grantee identity
- **Level 2** — a current Washington rule; the technical lead's place of business is Washington State.
- **Application note:** Three textual points. **First**, the rule binds *investment advisers*, not broker-dealers — the brief's premise that WAC 460-24A-220(5) is "the written third-party trading authorization" generally is imprecise; it is the adviser-side one. **Second**, subsection (5)'s trigger is "upon instruction of a third party," and the duty falls on *the person placing the order*. In standing mode the entity placing the order is the member's own runtime acting on the member's own local policy, using the member's own credentials, into the member's own account. Whether the engine's signal makes the runtime's submission an order placed "upon instruction of a third party" is not addressed by any located Washington authority. **Third**, subsection (2)'s time-and-price carve-out **contains no day limit** — unlike FINRA Rule 3260(d)(1), which by its terms does not extend beyond the business day on which the discretion was granted. It does, however, retain the "definite amount of a specified security" requirement. Note the contrast with the Washington *broker-dealer* rule at RE-4.3-08, which retains neither.

---

### RE-4.3-08 · WAC 460-20C-210(6) and WAC 460-20C-220(11) (Washington — Dishonest or unethical practices, broker-dealers and salespersons) · https://app.leg.wa.gov/WAC/default.aspx?cite=460-20C-210 and …=460-20C-220 · retrieved 7 Sep 2026

- **Type:** state administrative rule
- **Date / status:** **current — and new.** The predecessor provisions, WAC 460-21B-060 (broker-dealers) and WAC 460-22B-090 (salespersons), were **repealed by WSR 24-19-055, filed 12 Sep 2024, effective 13 Oct 2024**, and replaced by chapter 460-20C WAC.
- **Verbatim quote, pin-cited:**

> "(6) Exercising any discretionary power in effecting a transaction for a customer's account without first obtaining written discretionary authority from the customer, **unless the discretionary power relates solely to the time and/or price for the execution of orders;**"
>
> — WAC 460-20C-210(6) (broker-dealers)

> "(11) Exercising any discretionary power in effecting a transaction for a customer's account without first obtaining written discretionary authority from the customer, unless the discretionary power relates solely to the time and/or price for the execution of orders;"
>
> — WAC 460-20C-220(11) (salespersons)

And the adjacent, separate prohibition:

> "(5) Executing a transaction on behalf of a customer without authorization to do so;"
>
> — WAC 460-20C-210(5)

Repeal history, from the WAC chapter disposition listing:

> "460-21B-060 Dishonest or unethical business practices—Broker-dealers. … Repealed by WSR 24-19-055, filed 9/12/24, effective 10/13/24. Statutory Authority: RCW 21.20.070 and 21.20.450."
>
> — WAC dispositions listing, chapter 460 index, https://app.leg.wa.gov/WAC/default.aspx?cite=460-22B, retrieved 7 Sep 2026

- **What it establishes:** Washington's current broker-dealer time-and-price carve-out is materially **broader** than FINRA Rule 3260(d)(1) in two respects: it contains **no business-day limit**, and it contains **no "definite amount of a specified security" requirement.** It reads simply that the discretionary power must relate "solely to the time and/or price for the execution of orders."
- **Q3:** SUPPORT (a broader carve-out than the federal SRO rule, in the state that matters most to the configuration)
- **Level 2** — current Washington rule, retrieved from the state's own server-rendered rulebook, with repeal-and-replacement history verified.
- **Application note:** This is a genuinely new finding and it cuts in the configuration's favour on one axis and must be reported carefully on another. **Favourable:** Washington's broker-dealer rule tracks the NASAA model formulation ("time and/or price"), and omits both of the limitations that make FINRA Rule 3260(d)(1) narrow. The configuration's envelope — once a definite order exists, the runtime may exercise only the narrow price-and-time latitude the member's own policy granted, via price band and re-peg rule — sits inside "solely to the time and/or price for the execution of orders" on the face of the Washington text without needing the order to be day-limited. **Unfavourable / must not be softened:** the carve-out is a carve-out from a *conduct prohibition addressed to registered broker-dealers and salespersons.* It tells a registered firm when it need not obtain written authority. It is not a statement that an unregistered actor exercising the same latitude is outside the definition of a broker-dealer, and it does not speak to who may hold the authority. Its subject is a registrant, exactly as FINRA Rule 3260(d)(1)'s subject is a member. **Also note:** because these rules were repealed and replaced in October 2024, any secondary source or prior analysis citing WAC 460-21B-060 or WAC 460-22B-090 as current Washington law is stale.

---

### RE-4.3-09 · RCW 21.20.005(12) (Washington Securities Act — definition of "person") · https://app.leg.wa.gov/rcw/default.aspx?cite=21.20.005 · retrieved 7 Sep 2026

- **Type:** state statute
- **Date / status:** current
- **Verbatim quote, pin-cited:**

> "(12) 'Person' means an individual, a corporation, a partnership, a limited liability company, a limited liability partnership, an association, a joint-stock company, a trust where the interest of the beneficiaries are evidenced by a security, an unincorporated organization, a government, or a political subdivision of a government."
>
> — RCW 21.20.005(12)

- **What it establishes:** The Washington Securities Act's definition of "person" is a closed enumeration of a natural individual and legal entities. Software is not among the enumerated items, and the definition contains no residual catch-all such as "or any other entity."
- **Q3:** NEUTRAL — see application note
- **Level 3** — a current state statutory definition, but one that does not textually govern the operative words in the trading-authorization rules.
- **Application note:** Reported precisely because the obvious inference is not available. The Washington provisions that matter here do **not** use the defined term. WAC 460-20C-210(6) speaks of "written discretionary authority from the customer" without naming a grantee at all; WAC 460-24A-220(5) speaks of "instruction of a third party" and "a written third-party trading authorization," again without invoking "person." So RCW 21.20.005(12) does not, on its face, operate to exclude software from being a grantee under those rules — the rules simply do not use the term. What the definition does establish is that when the Washington legislature enumerated who can be an actor under the Act, it listed humans and legal entities and nothing else. **That is a drafting observation, not a holding, and no located Washington authority applies the definition to software in either direction.**

---

### RE-4.4-01 · 17 C.F.R. §240.10b5-1(c)(1) (Trading "on the basis of" material nonpublic information — affirmative defences) · https://www.ecfr.gov/api/versioner/v1/full/2026-09-01/title-17.xml?part=240&section=240.10b5-1 · retrieved 7 Sep 2026

- **Type:** rule (federal regulation)
- **Date / status:** current as of the eCFR snapshot dated 2026-09-01, as amended by Rel. 33-11138 (Dec 2022)
- **Verbatim quote, pin-cited:**

> "(c) *Affirmative defenses.* (1)(i) Subject to paragraph (1)(ii) of this section, a person's purchase or sale is not on the basis of material nonpublic information if the person making the purchase or sale demonstrates that:
>
> (A) Before becoming aware of the information, the person had:
>
> (*1*) Entered into a binding contract to purchase or sell the security,
>
> (*2*) **Instructed another person to purchase or sell the security for the instructing person's account,** or
>
> (*3*) Adopted a written plan for trading securities;
>
> (B) The contract, instruction, or plan described in paragraph (c)(1)(i)(A) of this section:
>
> (*1*) Specified the amount of securities to be purchased or sold and the price at which and the date on which the securities were to be purchased or sold;
>
> (*2*) **Included a written formula or algorithm, or computer program, for determining the amount of securities to be purchased or sold and the price at which and the date on which the securities were to be purchased or sold;** or
>
> (*3*) Did not permit the person to exercise any subsequent influence over how, when, or whether to effect purchases or sales; provided, in addition, that any other person who, pursuant to the contract, instruction, or plan, did exercise such influence must not have been aware of the material nonpublic information when doing so; and
>
> (C) **The purchase or sale that occurred was pursuant to the contract, instruction, or plan.** A purchase or sale is not 'pursuant to a contract, instruction, or plan' if, among other things, the person who entered into the contract, instruction, or plan altered or deviated from the contract, instruction, or plan to purchase or sell securities (whether by changing the amount, price, or timing of the purchase or sale), or entered into or altered a corresponding or hedging transaction or position with respect to those securities."
>
> — 17 C.F.R. §240.10b5-1(c)(1)(i) (emphasis added)

The cooling-off conditions added in 2022:

> "(B) If the person who entered into the contract, instruction, or plan is: … (*2*) Not the issuer and not a director or officer (as defined in § 240.16a-1(f) …) of the issuer, no purchases or sales occur until the expiration of a cooling-off period that is 30 days after the adoption of the contract, instruction or plan;"
>
> — 17 C.F.R. §240.10b5-1(c)(1)(ii)(B)(2)

- **What it establishes:** An express Commission rule contemplating that a person may, in advance, adopt a written plan whose operative content is "a written formula or **algorithm, or computer program**," determining amount, price and date; that the resulting transactions are executed later without the person's involvement; and that those transactions are throughout described as **"a person's purchase or sale"** and **"the purchase or sale that occurred … pursuant to the contract, instruction, or plan."** The rule also expressly contemplates instructing "another person to purchase or sell the security **for the instructing person's account**."
- **Q3:** SUPPORT — **as an analogy, expressly labelled**
- **Q2:** NEUTRAL
- **Level 3** — a Commission rule with the operative words in its own text, and therefore stronger than any staff letter; but it is an insider-trading affirmative defence, and it is being read across to an attribution question it was not written to answer.
- **Application note (ANALOGY — labelled).** **This is the supportive end of the GEL Direct Trust line, and it is a rule of the Commission rather than a staff position.** Its significance is structural rather than holding-based. Throughout paragraph (c)(1), the transaction executed later by the formula, algorithm or computer program is described without qualification as *the adopting person's own purchase or sale*. The rule never entertains the possibility that interposing an algorithm between the person's decision and the execution transfers the transaction to somebody else; it locates the person's decision at the moment of adoption and asks only whether the person was aware of material nonpublic information *then*. The Commission's framing in the adopting release (RE-4.4-02) is to the same effect. Against *GEL Direct Trust*'s inference of discretion from a six-second interval, Rule 10b5-1(c)(1)(i)(B)(2) is the counterweight: **a federal rule whose text says in terms that a computer program may determine the amount, the price and the date, and that what results is still the adopter's own trade.**
  **The disanalogies must be stated and are real.** (i) Rule 10b5-1 answers "was this trade *on the basis of* MNPI," not "*whose* trade is it" and not "is the executing party a broker." It presupposes the attribution rather than deciding it — which is precisely why it is useful evidence of the drafting assumption and precisely why it is not a holding. (ii) The affirmative defence protects *the adopter*; it says nothing about the regulatory status of whoever or whatever runs the program. Nothing in Rule 10b5-1 suggests the operator of the algorithm escapes §15(a) or §202(a)(11) — the rule simply does not address that party. (iii) Condition (B)(3)'s proviso expressly contemplates that "any other person who, pursuant to the contract, instruction, or plan, did exercise such influence" may exist — so the rule does acknowledge a second actor with influence, and subjects that actor to its own awareness test.
  **Mapping to the configuration.** The standing-mode design corresponds closely to branch (B)(2): the member's local policy is a written specification, versioned and journaled, from which the runtime derives amount, price band and timing. The engine's rule set, authored by the member, is the formula. Branch (C)'s anti-deviation condition — a trade is not "pursuant to" the plan if the person "altered or deviated from" it "by changing the amount, price, or timing" — maps onto the configuration's policy-version journaling and its "envelope is never broadened" constraint. **The point of strain is branch (B)(2)'s requirement that the formula determine "the amount … and the price at which **and the date on which**" — the date. A signal-driven standing mode does not fix dates in advance; it fires when a member-authored condition is met. Whether a condition-triggered date satisfies "the date on which" is not addressed by the rule text, the adopting release, or any located authority.** This is the same exposed parameter that footnote 1 of the SLOA letter identifies as "timing" (RE-4.3-04). **Two independent instruments, approached from different directions, isolate the same variable: timing.** That convergence is the most useful analytic result in this track.

---

### RE-4.4-02 · Securities Act Release No. 33-7881, *Selective Disclosure and Insider Trading* (15 Aug 2000), 65 FR 51716 · https://www.sec.gov/files/rules/final/33-7881.htm · retrieved 7 Sep 2026

- **Type:** release (adopting release for Rule 10b5-1)
- **Date / status:** good law as the adopting release; paragraph (c)(1) later amended by Rel. 33-11138
- **Verbatim quotes, pin-cited:**

> "Second, the person must demonstrate that, with respect to the purchase or sale, the contract, instructions, or plan either: (1) expressly specified the amount, price, and date; (2) **provided a written formula or algorithm, or computer program, for determining amounts, prices, and dates**; or (3) did not permit the person to exercise any subsequent influence over how, when, or whether to effect purchases or sales; provided, in addition, that any other person who did exercise such influence was not aware of the material nonpublic information when doing so.110"

> "Taken as a whole, the revised defense is designed to cover situations in which a person can demonstrate that **the material nonpublic information was not a factor in the trading decision.** We believe this provision will provide appropriate flexibility to those who would like to **plan securities transactions in advance** at a time when they are not aware of material nonpublic information, and then **carry out those pre-planned transactions at a later time**, even if they later become aware of material nonpublic information.115"

> "The revised language responds to commenters' concerns by providing appropriate flexibility to persons who wish to structure securities trading plans and strategies when they are not aware of material nonpublic information, and do not exercise any influence over the transaction once they do become aware of such information."
>
> — Rel. 33-7881, § III.B (discussion of Rule 10b5-1(c)), text accompanying nn.108-115

And the Commission's definitions of the three specified elements:

> "We are adopting, substantially as proposed, the definition of 'amount',112 which means either a specified number of shares or a specified dollar value of securities. We have revised the definition of 'price' and added a definition of 'date.' As adopted, 'price' means market price on a particular date or a limit price or a particular dollar price.113 **'Date' means either the specific day of the year on which a market order is to be executed, or a day or days of the year on which a limit order is in force.**114"
>
> — Rel. 33-7881, § III.B

- **What it establishes:** The Commission's own account of the algorithm/computer-program branch: the person "plan[s] securities transactions in advance" and then "carr[ies] out those pre-planned transactions at a later time." The trading decision is located at the moment of planning. The Commission also defined "date" restrictively — a specific day of the year, or the days on which a limit order is in force.
- **Q3:** SUPPORT — **as an analogy, expressly labelled**
- **Level 3** — the Commission's adopting release, explaining its own operative words; but again answering the MNPI question, not the attribution question.
- **Application note (ANALOGY — labelled).** The phrase "**carry out those pre-planned transactions at a later time**" is the Commission speaking, in its own voice, of the *adopter* as the one who carries out a transaction that in fact a computer program executed while the adopter did nothing. That is as close as any located federal source comes to saying that software executing a person's own pre-adopted specification is that person acting. It is offered for exactly that and no more. **The adverse counterweight is in the same passage:** the Commission's definition of "date" — "the specific day of the year on which a market order is to be executed, or a day or days of the year on which a limit order is in force" — is a *calendar* definition. It does not contemplate a date determined by a market condition. A standing mode that fires on a signal does not specify a day of the year in advance. **On the Commission's own definition of the term, a condition-triggered standing instruction does not obviously satisfy the "date" element of branch (B)(2), and no located authority addresses the gap.** This must not be softened: the single strongest supportive text in the track has a defined term in it that the configuration's standing mode does not cleanly meet.

---

### RE-4.4-03 · Securities Act Release No. 33-11138, *Insider Trading Arrangements and Related Disclosures* (14 Dec 2022), 87 FR 80362 · https://www.sec.gov/files/rules/final/2022/33-11138.pdf · retrieved 7 Sep 2026

- **Type:** release (adopting release for the 2022 amendments to Rule 10b5-1)
- **Date / status:** good law
- **Verbatim quote, pin-cited:**

> "…a period (a 'cooling-off period') between the adoption of a Rule 10b5-1 plan and the date on which trading can commence **reduces the risk that corporate insiders could benefit from any material nonpublic information of which they may have been aware when adopting the plan.**"
>
> — Rel. 33-11138, § II.A (discussion of the proposed cooling-off periods), at PDF p.15, text accompanying n.36

- **What it establishes:** The Commission's stated rationale for the only mandated delay between the adoption of a trading instruction and its execution found anywhere in federal securities law. The rationale is **informational**: the delay decorrelates the instruction from any material nonpublic information the adopter held at adoption.
- **Q3:** ADVERSE to the design's delay theory — see application note and DA-4.4(b)
- **Level 2** — the Commission's adopting release, stating its own purpose for a delay requirement.
- **Application note:** The configuration contemplates a built-in delay between signal and submission in standing mode, specifically to answer *GEL Direct Trust*'s inference of discretion from a six-second interval. **This release is the closest federal analogue to a mandated delay, and its rationale does not support that use.** The cooling-off period exists to sever a link to *information*, not to establish *who decided*. On the Commission's reasoning a longer interval says nothing about attribution; it says the adopter was less likely to have been trading on what he knew at adoption. Read strictly, the release is mildly adverse to the design's premise, because it shows that when the Commission did impose a delay between instruction and execution, it did so for an entirely different reason and said nothing about whose decision the resulting trade was. See DA-4.4(b) and NF-3.

---

### RE-4.4-04 · 17 C.F.R. §242.100 (Regulation M — definitions of "agent independent of the issuer" and "plan") and §242.102(c) · https://www.ecfr.gov/api/versioner/v1/full/2026-09-01/title-17.xml?part=242&section=242.100 · retrieved 7 Sep 2026

- **Type:** rule (federal regulation)
- **Date / status:** current as of the eCFR snapshot dated 2026-09-01
- **Verbatim quotes, pin-cited:**

> "*Agent independent of the issuer* means a trustee or other person who is independent of the issuer. The agent shall be deemed to be independent of the issuer only if:
>
> (1) The agent is not an affiliate of the issuer; and
>
> (2) **Neither the issuer nor any affiliate of the issuer exercises any direct or indirect control or influence over the prices or amounts of the securities to be purchased, the timing of, or the manner in which, the securities are to be purchased, or the selection of a broker or dealer** (other than the independent agent itself) through which purchases may be executed; *Provided, however*, That the issuer or its affiliate will not be deemed to have such control or influence solely because it revises not more than once in any three-month period the source of the shares to fund the plan[,] the basis for determining the amount of its contributions to a plan, or the basis for determining the frequency of its allocations to a plan, **or any formula specified in a plan that determines the amount or timing of securities to be purchased by the agent.**"
>
> — 17 C.F.R. §242.100(b), definition of "agent independent of the issuer"

> "*Plan* means any bonus, profit-sharing, pension, retirement, thrift, savings, incentive, stock purchase, stock option, stock ownership, stock appreciation, **dividend reinvestment**, or similar plan; or any dividend or interest reinvestment plan or employee benefit plan as defined in § 230.405 of this chapter."
>
> — 17 C.F.R. §242.100(b), definition of "plan"

- **What it establishes:** Regulation M contains an operative federal test for attributing plan purchases between a party who sets a formula in advance and a party who executes it. The axes of that test are **control or influence over prices, amounts, timing, manner, and broker selection**. The rule expressly tolerates "any formula specified in a plan that determines the amount or timing of securities to be purchased by the agent," provided the formula-setter revises it no more than once in any three-month period. Dividend reinvestment plans fall within the defined term "plan."
- **Q3:** SUPPORT — **as an analogy, expressly labelled**
- **Level 4** — a rule about manipulation during distributions, with an attribution test built for a different purpose; the direction of attribution is the reverse of the configuration's.
- **Application note (ANALOGY — labelled).** This is the only located federal rule that sets out, in operative text, an **enumerated list of the factors that determine whose market activity a formula-driven, machine-executed plan purchase is.** Those factors are prices, amounts, timing, manner and broker selection. Applied to the configuration's facts as a checklist — which is all it can be — every one of them traces to the member: sizing, price band and order type are typed by the member into local policy; the instrument and side derive from the member's own thresholds and universe; broker selection is the member's own broker under the member's own credentials, with the configuration performing no routing or venue selection; and manner is fixed by the member's policy. **Timing is again the exposed axis**, and again it is the one the machine determines — the third instrument in this track to isolate it.
  **The disanalogy is important and inverts the direction.** Regulation M's test asks whether an agent is *independent of* the formula-setter, in order to attribute purchases **away from** the issuer. The configuration wants the opposite: to attribute the purchase **to** the member. Read structurally rather than directionally, the rule stands for the proposition that *whoever controls prices, amounts, timing, manner and broker selection is the party whose activity it is* — and on that reading the member is that party. **But the rule has never been applied outside distributions, no located authority uses it as a general attribution test, and its three-month revision limit has no counterpart in the configuration, whose members may revise policy at will.** That last point is a genuine mismatch: Regulation M tolerates a formula only if the formula-setter keeps his hands off it for three months at a time.

---

## Adverse register

| # | Authority | Threat 1–5 | Does the configuration distinguish it? |
|---|---|---|---|
| A1 | **IAA SLOA letter (21 Feb 2017), staff's "We disagree"** — a client-signed, bounded, revocable standing authorization under which another party later instructs the custodian **does** confer custody; the actor being "merely… an agent for the client" did not prevent that. **The requester expressly argued the bounded-vs-open distinction** — contrasting a limited SLOA against trustee discretion and against "a full power of attorney … or broad discretionary authority" — **and the staff rejected it** | **5** | **No, not on the reasoning.** Every structural feature the standing-mode design leans on — writing, bounds, revocability, agency framing — was present and was held insufficient. **The design's core intuition, that a *bounded* standing authority is different in kind from an open one, is the exact argument the IAA made and the exact argument the staff answered with "We disagree."** The configuration distinguishes on *subject matter* only: nothing is withdrawn and there is no third-party payee, so Rule 206(4)-2(d)(2)(ii) is not engaged on its face, and the staff's own "other than authorized trading" carve-out removes trading authority from "access." That is a real distinction, but it is a distinction about custody, not a rebuttal of the letter's reasoning about whether a bounded standing authorization remains the client's own. **It does not.** |
| A2 | **17 C.F.R. §240.17a-3(a)(17)(ii)** + **Rel. 34-44992 n.21** — "the dated signature of each natural person to whom discretionary authority was granted," expressly sourced to NASD Rule 2510(b) / NYSE Rule 408 | **4** | **Partly, and only by architecture.** In per-order V1 nobody is granted discretionary authority, so the record is never required. In **standing mode the problem is direct and unavoidable**: if the member grants a bounded standing authority to a program, the broker's discretionary-account record has no natural person whose dated signature it can carry. The configuration cannot distinguish this by conduct; it can only avoid triggering it, which is a design constraint, not an answer. |
| A3 | **FINRA Rule 3260(b)** — "prior written authorization to **a stated individual or individuals**," plus written acceptance of the account by the member | **4** | **No.** The noun for the grantee is "individual." The configuration's per-order answer is that no member grants anything to anyone; but **in standing mode the member does grant something to *something*, and the only vocabulary the SRO rulebook supplies for the grantee of a trading authorization is "individual."** Note the rule also requires a second element the configuration has no way to produce: acceptance of the account by the member, evidenced in writing — a step involving the member's own broker, with whom the configuration has no agreement. |
| A0 | ***Michael Pino***, Rel. 34-74903 (7 May 2015), with ***Murphy*** (2013) and ***Sathianathan*** (2006) — "**a customer's approval of a general strategy does not meet the requirements of the 'time and price discretion' exception**"; the definiteness requirement attaches to **the customer's grant**, not to the resulting order; and the respondent's own losing formulation was "*to sell something based on a strategy that's been well in place, that to me is not discretion*" | **5** | **No — and this is the sharpest adverse authority in the track.** The losing argument is the standing-mode argument. In **per-order V1 the configuration does distinguish it cleanly**: the member is consulted before every execution, which is exactly what Pino failed to do, and each tap supplies a grant definite as to security and quantity. **In standing mode it does not distinguish at all on the reasoning** — a rule set approved in advance is, on the face of three Commission opinions, approval of a general strategy. The only untested distinctions are that these cases involve a registered representative, an oral grant, and no writing; none involves software or a written standing authorization. |
| A0a | **Rel. 34-49883 at 7** — commenters asked that the written extension lifting the day limit be allowed as **general "standing" instructions rather than order-by-order; "NASD declined to adopt this position"**; the standard is "**trade-specific**" | **5** | **No — and this is the most directly on-point adverse authority in the track for standing mode.** The design's standing track asks for precisely what was requested and refused. The only route out of the day limit for a retail account is "a specific, written contrary indication signed and dated by the customer," and the regulator declined to let that be a standing instrument. Anything broader, NASD said, requires "a fully executed trading authorization" — which exits the exception and re-enters Rule 3260(b) and its "stated individual or individuals." **V1 per-order mode answers a different question (it re-obtains a human act each order); standing mode meets this head-on and loses on the text.** |
| A0b | **FINRA Rule 4512(a)(3)** — "**investment discretion** granted by a customer as to the price at which or the time to execute an order" | **5** | **No.** The FINRA rulebook itself labels this latitude *investment discretion*. There is no distinguishing move available on the text. The most that can be said is that 4512(a)(3) is a recordkeeping provision and its label is not an Exchange Act §3(a)(35) determination — **but no located source says that.** A design that describes its envelope as "not discretion" is using a characterisation the rulebook does not use. |
| A0c | ***DiPaola***, Rel. 34-105568 (**28 May 2026**) — discretion is trading "**without first receiving approval for the trades**"; a general strategy plus no discussion of individual trades **is** discretion; n.8: "**determining the price at which a trade occurs is an exercise of discretion subject to only a limited exception**" | **5** | **Per-order V1: yes, cleanly and currently** — the member approves each complete composed order before it goes, which is the far side of the Commission's own stated line, in its most recent word on the subject. **Standing mode: no** — it is by definition trading without per-order approval on a general strategy. And n.8 is the most directly adverse sentence located for the price band and re-peg rule: setting the price **is** discretion, saved only by an exception that is day-limited and retail-gated. |
| A3a | **FINRA Rule 3260(d)(1)'s day limit** — time-and-price authority is "in effect only until the end of the business day on which the customer granted such discretion, absent a specific, written contrary indication signed and dated by the customer" | **4** | **No — this is the direct hit on standing mode.** A standing authority is by definition not day-limited. The default form of (d)(1) therefore does not accommodate standing mode at all. The only route that does is the customer's "specific, written contrary indication **signed and dated**" — which is a written, signed, dated customer instrument, returning the analysis straight to A2 and A3. **The configuration cannot have both a standing authority and the unmodified benefit of (d)(1).** |
| A3b | **FINRA Rule 3260(d)(1)'s institutional gate** — the day limit is lifted only "in an institutional account, as defined in Rule 4512(c), pursuant to valid Good-Till-Cancelled instructions issued on a 'not-held' basis" | **4** | **No.** The configuration's members are retail. This is the **second** authority in the register whose otherwise-apposite relief is gated on institutional status — *S3 Matching Technologies* is the first, conditioned on the same Rule 4512(c). **A pattern worth naming: where the rules do accommodate machine-mediated latitude, they do it for institutional accounts.** |
| A3c | **FINRA Rule 4512(a)(3)** read with 3260(d)(1)'s "Any exercise of time and price discretion must be reflected on the order ticket" | **3** | **No.** Time-and-price latitude **is** investment discretion; 3260(d)(1) merely does not require *written pre-authorisation* for it when a member exercises it on a definite, day-limited order. Any framing that treats bounded price-and-time latitude as "not discretion" misreads the rule. The configuration should not rely on that framing. |
| A4 | **Rel. 33-7881's definition of "date"** — "the specific day of the year on which a market order is to be executed, or a day or days of the year on which a limit order is in force" | **3** | **No.** The track's single strongest supportive text (Rule 10b5-1(c)(1)(i)(B)(2)) carries a defined term the configuration's signal-triggered standing mode does not cleanly satisfy. A condition-triggered date is not a day of the year. Unaddressed by any located authority — which is the only thing that keeps this at 3 rather than 4. |
| A5 | **Rel. 33-11138** — the only mandated delay between instruction and execution in federal securities law exists to sever an **informational** link, not to establish who decided | **3** | **No.** The configuration's built-in delay is designed to answer *GEL*'s six-second inference. The one federal instrument that mandates such a delay gives a rationale that does not transfer. The delay may still be evidentially useful, but **no located authority says a delay bears on attribution.** See NF-3. |
| A6 | **WAC 460-24A-220(5)** — placing an order "upon instruction of a third party" without a written third-party trading authorization is an unethical practice; **no carve-out** | **3** | **Partly.** The rule binds investment advisers and the duty falls on the order placer. In standing mode the order placer is the member's own runtime under the member's own credentials into the member's own account. Whether an engine signal makes that an order placed "upon instruction of a third party" is **not addressed by any located Washington authority** — an open question, not a distinction. |
| A7 | **Regulation M's three-month revision limit** on a plan formula | **2** | **No.** The configuration lets members revise local policy at will, with journaling. The only located federal rule that expressly tolerates a machine-executed formula conditions that tolerance on the formula-setter not touching it more than quarterly. |
| A8 | **SEC, *All About Auto-Trading* (8 Jun 2009)** — auto-trading is defined by the broker executing "**without first getting your permission**" on instructions from a third party; and "**Generally, the SEC considers firms that publish investment newsletters and that also engage in 'auto-trading' to be investment advisers.**" | **4** | **Per-order V1: yes, cleanly** — one explicit tap per order means trades do not occur without the member's permission, which is the alert's own defining feature. **Standing mode: no, not on the permission axis** — standing execution is by design the absence of per-order permission. The surviving distinctions are that no third party sends instructions to the broker (the runtime is the member's own, under his own credentials) and the broker has agreed to accept instructions from no one but the member. **Neither distinction is addressed by this document or any other located source.** The Q1 sentence is aggravated by the configuration's shape: the alert's target is a *publisher* that also auto-trades, and the engine layer is signal publication. |
| A9 | **Rel. 34-84528 at 70 / Rule 606 FAQ** — discretion over an automated thing is defined as "choosing among different trading algorithms, **adjusting or customizing algorithm parameters**" | **3** | **Two-edged, and the configuration should not cite it one-sidedly.** It locates discretion in *whoever configures*, which in the configuration is the member — supportive. But it also means **parameter-setting is itself named "discretion" in a Commission release**, so the "every parameter is the member's own" defence describes a member exercising discretion, and any company-side preset would be the company exercising it. **The configuration's "no presets, no imports, no 'most users choose'" rule is load-bearing on this authority.** Mitigating: this is Rule 606(b)(3) *routing* discretion; a full-text search of the release for "3(a)(35)" returns **0 hits**, and no source equates the two. |
| A10 | **FINRA RN 16-21** — an idea-generating algorithm escapes the definition only if "**not equipped to automatically generate orders or order-related messages to effectuate such trading ideas into the market (whether independently or via a linked router)**" | **4** | **Per-order V1: yes** — the member's tap breaks the coupling, and the engine's integration contract rejects quantity, order type, price, TIF and account. **Standing mode: no** — the signal reaches an order-composing runtime with no human act between them, and the parenthetical expressly reaches an idea-generator *coupled* to something that effectuates. Whether a member-controlled local runtime holding no engine credentials, reachable by no engine code path, is "a linked router" is **not addressed by RN 16-21 or any located authority.** This is the sharpest question standing mode raises in FINRA's own vocabulary. |
| A11 | **FINRA Rule 2360(b)(18)(A)(i)** — prohibits a member exercising discretion "**or accept[ing] orders for option contracts for an account from a person other than the customer**" absent Rule 3260 compliance plus specific written options authorisation | **3** | **Not on the reasoning; only by instrument scope.** This is an options rule and does not bind equities. But it shows the rulebook already contains the concept the configuration most needs to avoid: **a duty triggered simply by an order arriving from someone other than the customer, irrespective of whose decision it was.** If the analysis extends to options, the question stops being "was this discretion?" and becomes "did this order come from the customer?" — which standing mode answers less comfortably than per-order mode. |
| A12 | **NYSE Rule 70.25 (d-Quotes)** — "discretionary instructions with respect to a **Floor broker's** agency interest file" | **2** | **No, and it undercuts a tempting argument.** Nasdaq's "Discretionary Order" (a customer-set price band) and NYSE's "discretionary instructions" (a registered agent's flexibility) use the same adjective in opposite senses in the same market. **The vocabulary contrast at RE-4.1-02 is real but is not a rule of construction, and an argument that leans on it is equivocating.** |

---

## Direct answers

*(Sections 4.1 and 4.2 are answered from the dedicated researchers' returns and are integrated below; 4.3 and 4.4 were worked directly.)*

### DA-4.1 · Where the line runs between a conditional order the customer gave and discretion exercised by software

*The dedicated 4.1 researcher's return supplies the exchange rule filings and the order-type definitions. What follows is the part answerable from authorities retrieved directly in this track, and it should be read as the floor of the answer, not its whole.*

**The clearest line located anywhere in federal law is in the order-ticket rule, and it is a binary about who entered the order.** 17 C.F.R. §240.17a-3(a)(6)(i)(A) requires the memorandum to show:

> "the identity of any other person who entered or accepted the order on behalf of the customer, **or**, if a customer entered the order on an electronic system, a notation of that entry"

The same words appear in (a)(7)(i) for principal transactions with customers. **The rule contemplates exactly two cases and gives them different treatment:** where another *person* entered the order on the customer's behalf, that person must be *identified*; where the *customer* entered it on an electronic system, a bare *notation* suffices. The rule offers no third category, and it does not say which side software falls on.

**A second line in the same provision is equally important and points the other way from what a design might hope.** The discretion flag reads:

> "An order entered pursuant to the exercise of discretionary authority **by the member, broker or dealer, or associated person thereof**, must be so designated."

The order ticket's discretion designation is therefore drafted **only** for discretion exercised by the member, the broker-dealer or an associated person. A third party's discretion is not something this rule flags at all. Factually: the federal order-ticket rule has a field for "the broker exercised discretion" and a field for "the customer entered this himself," and **no field for "a third party's software composed and submitted this pursuant to the customer's standing configuration."**

**Third, the rule fixes when the order is treated as entered:**

> "The term *time of entry* means the time when the member, broker or dealer transmits the order or instruction for execution."

Time of entry is located at the *broker's* transmission for execution, not at the moment the customer's instruction was formed. In the configuration, the member's broker transmits under the member's own credentials, and pre-trade risk control under Rule 15c3-5 sits with that broker.

**Fourth, from the SRO side:** FINRA Rule 3260(d)(1) ends with "**Any exercise of time and price discretion must be reflected on the order ticket**" — tying the SRO's time-and-price concept back into the same federal ticket rule, and confirming that time-and-price latitude is a thing that gets *recorded as discretion*, not a thing that is treated as no discretion at all. See DA-4.2(e).

**Fifth — HALF A, the broker-side conditional order types. The exchange rulebooks attribute the condition to the customer, uniformly.** Cboe Rule 5.6(c), and by cross-reference Cboe BZX Rule 21.1(d)(11)/(12), C2 Rule 6.10(c) and Cboe EDGX Rule 21.1(d)(11)/(12): a stop order becomes a market order at "the stop price **specified by the User**." Nasdaq (80 FR at 16051): an Order is "an instruction to trade … submitted … **by a Participant**," and execution proceeds "in accordance with the parameters applicable to the Order Type and Order Attributes **selected by the Participant**." NYSE Rule 13, as recited at 80 FR 79366: "an order to buy or sell a stock at the market once the price of the stock reaches a specified price known as the 'stop price'" (note: **Stop Orders were deleted from NYSE Rule 13 in 2016**). And the Commission's own framing at Rel. 34-74032 ¶3: "**Order types are the primary means by which market participants communicate their instructions for the handling of their orders to the exchange.**"

**The single clearest placement of the line is CBOE's, at 69 FR 40423** (RE-4.1-01). In one block of Commission-published text, stop, stop-limit, market-if-touched, OCO, AON and FOK are all described as customer "**instructions**" and "**order conditions**" triggered by "a specified '**trigger**' price" — and exactly one type is separated out: "**A Not Held order is a discretionary order with instructions granting the agent flexibility as to the price and or time of execution.**" **On that document's vocabulary the line runs between a condition the customer specified in advance and flexibility granted to an agent — not between a human act and a machine act.**

**Sixth — the vocabulary contrast is real but unstable, and must not be over-used.** Nasdaq Rule 4703(g) confirms the point flagged in the brief: "**Discretion is an Order Attribute under which an Order has a non-displayed discretionary price range within which the entering Participant is willing to trade**," and "**A Participant may also specify a limit price beyond which the discretionary price range may not extend.**" That is a customer-set, customer-capped price band — structurally what the configuration's envelope is. **But NYSE uses the same adjective the other way:** NYSE Rule 70.25 d-Quotes are "discretionary instructions with respect to a **Floor broker's** agency interest file" (79 FR 3896 n.7). **The rulebooks are not consistent, so the contrast is evidence, not a rule of construction** (RE-4.1-03).

**Seventh — HALF B, third-party software. Two authorities name the customer as the entering party even where software did it.** NASD NTM 98-66 blessed customers entering orders through an API "**without the manual entry of such order by a person associated with the member**," calling the member "**an agent on behalf of the customer inputting the order**." And *Wedbush*, Rel. 34-73652 ¶13, describes "**customer firms and their traders to send orders** … by using online trading platforms or software programs that the customer either owned directly or leased from a third-party platform provider." The Commission charged the broker and two officers; **it charged no platform provider — but gave no reason, so nothing follows from that.**

**Eighth — what cuts the other way in Half B.** Rel. 34-84528 at 70 defines discretion over an automated thing as "choosing among different trading algorithms, **adjusting or customizing algorithm parameters**" — which locates discretion in whoever configures, but also **names parameter-setting as discretion** (RE-4.1-06, A9). FINRA RN 16-21 exempts an algorithm that "solely generates trading ideas" only where it is "**not equipped to automatically generate orders … (whether independently or via a linked router)**" — and standing mode couples the signal to an order-composing runtime with no human act between (RE-4.1-10, A10). And the SEC's own auto-trading alert draws its line at execution "**without first getting your permission**," which is what standing mode is (RE-4.1-07, A8).

**What this track can and cannot say.** It can say that the federal order-ticket rule draws its line between "another person entered on the customer's behalf" and "the customer entered on an electronic system," that the exchange rulebooks uniformly attribute a conditional order's trigger to the User or Participant who specified it, and that the CBOE passage separates conditional orders from agent discretion on exactly that basis. The configuration's per-order mode is built to sit on the customer side of every one of those lines. **It cannot say which side standing mode sits on**, because in standing mode there is no member act at the moment of entry and the composing party is not the customer.

**And one structural disanalogy applies to the whole of Half A and must be stated plainly: in every broker-side conditional order type — stop, stop-limit, MIT, OCO, bracket — the machine that fires the condition is the exchange's or the broker's own matching system, acting on an order the customer has already placed. The condition attaches to an existing order. In standing mode no order exists until the runtime composes one; the condition causes an order to be created. No located authority addresses the second case, in either direction.** That gap is the honest centre of question 4.1.

**Finally, three of the brief's own expectations were not borne out** and are recorded so they are not repeated: FINRA Rule 2360 contains **no** definition of a conditional or contingent order (0 hits for both terms); Rel. 34-72065 does **not** define order types (0 hits for "order type," "stop order," "conditional," "contingent") and is dated **1 May 2014**, not 12 May; and the Equity Market Structure Concept Release, Rel. 34-61358, contains **no** statement of whose order or whose decision an algorithmic order type is — its only relevant passage says algorithms route child orders "in accordance with the particular trading strategy **chosen by the customer**," while describing the algorithm itself as a broker service.

### DA-4.2 · What FINRA Rule 3260(d)(1) covers, and what falls outside it

*The dedicated 4.2 researcher's return is integrated where marked. The rule text was independently retrieved by the lead analyst via a Wayback snapshot of FINRA's own page after `finra.org` returned 429 then 403 — see RE-4.2-01 and search log 23, 46, 52.*

**(a) What "a definite amount of a specified security" requires, and the day limit.** From the text at RE-4.2-01: the exception reaches "discretion as to the price at which or the time when an order given by a customer for the purchase or sale of **a definite amount of a specified security** shall be executed." Three observations from the words themselves. **The amount must be definite and the security specified** — the exception is drafted for an order that already exists as to instrument and quantity, with only execution price and timing left open. **The price need not be unstated**; the rule does not say so. What the rule says is that the *discretion* must be "as to the price … or the time" — the discretion is over execution price and timing, which presupposes those are not fixed, but the rule does not impose a requirement that the customer state no price. **The day limit is a default, not an absolute:** "the authority to exercise time and price discretion will be considered to be in effect only until the end of the business day on which the customer granted such discretion, **absent a specific, written contrary indication signed and dated by the customer.**" So (d)(1) *is* day-limited unless the customer signs and dates a written indication to the contrary — and that escape hatch is itself a written, signed, dated customer instrument, which routes straight back to the written-authorization and natural-person questions. The day limit is lifted altogether only "in an institutional account, as defined in Rule 4512(c), pursuant to valid Good-Till-Cancelled instructions issued on a 'not-held' basis." **The configuration's members are retail, so the institutional route is unavailable to them.**

**(b) What has been held to EXCEED time-and-price discretion. — ANSWERED, and adversely.**

The controlling line is three Opinions of the Commission on review of NASD/FINRA disciplinary action: ***Michael Pino***, Rel. 34-74903 (7 May 2015); ***William J. Murphy***, Rel. 34-69923 (2 Jul 2013), 2013 WL 3327752, at *8; and ***Raghavan Sathianathan***, Rel. 34-54722 (8 Nov 2006), 2006 WL 3228694, at *12. *Pino* is quoted in full at RE-4.2-02.

**The holding, verbatim:** "**a customer's approval of a general strategy does not meet the requirements of the 'time and price discretion' exception to Rule 2510.**" The Commission found two independent grounds, either sufficient: the representative "**was not granted discretion by the customer as to the sale of definite amounts of specified securities**," and he "**was not granted such discretion on the same business day that he executed the sales transactions.**"

**Why it matters more than the brief anticipated:** the losing argument is the argument standing mode makes. Pino's own words, recorded at footnote 17: he "simply tried '**to sell something based on a strategy that's been well in place, that to me is not discretion.**'" *Murphy* rejected the same reasoning for a covered-call strategy; *Sathianathan* rejected it where representative and customer "discussed a general strategy … but did not discuss the amounts."

**And the definiteness requirement attaches to the grant, not to the order.** Pino failed it "because he did not speak with the customer before executing these sales transactions." The configuration's envelope makes the *composed order* definite; these opinions ask whether the *customer's grant* was definite as to amount and security. In per-order mode the member's tap supplies exactly that, per order. **In standing mode it is supplied by policy set in advance — which is what these three opinions call a general strategy.**

**Limits, stated:** all three concern a registered representative acting on an oral or implied grant in a customer's account at his firm. None involves software, a written standing authorization, or a member-authored rule set. Article III case law is not where this rule lives — CourtListener returns only 2 opinions for `"time and price discretion"`, 1 for `"discretion as to time and price"`, and 1 for `"NASD Rule 2510"` (NF-1) — it is litigated in FINRA fora and on SEC review, which CourtListener does not index. *Murphy* and *Sathianathan* were subsequently retrieved in full, together with the underlying FINRA NAC decision in *Murphy* — see RE-4.2-06 (◇5 closed).

**(c) Is there anything applying 3260/2510 to software at all? — NO. Nothing, in any forum, in either direction. The absence is symmetric.** Documented at NF-1 and NF-15.

The decisive counts. **CourtListener** (`type=o`): `"discretion as to the price at which or the time"` → **0**; `"definite amount of a specified security"` → **0**; `"2510(d)(1)"` → **0**; `"3260(d)(1)"` → **0**; `"FINRA Rule 3260"` → **0**; `"time or price discretion"` → **0**; `"time and price discretion" software` → **0**; `"time and price discretion" algorithm` → **0**; `"automated" "discretionary authority" broker-dealer software` → **0**. **Federal Register API:** `"3260(d)(1)"` → **0** — *no Federal Register document has ever cited FINRA Rule 3260(d)(1)*; `"FINRA Rule 3260" software` → **0**; `"time and price discretion" "computer program"` → **0**; `"2510(d)" software` → **0**; `"2510(d)" robo` → **0**.

**Mechanical full-text counts on the documents where one would most expect a link, and there is none:**
- **Rel. IA-5249 / 34-86031** (solely incidental, 2019): `software` → **0**; `algorith*` → **0**; `automat*` → **0**; `robo` → **0**; `3260` → **0**; `2510` → **1** (a bare cross-reference at n.53).
- **Reg BI adopting release, 84 FR 33318:** `time and price` → **0**; `2510` → **0**; `3260` → **0**.
- **FINRA, *Report on Digital Investment Advice* (Mar 2016)** — FINRA's flagship publication on automated advice tools: `2510` → **0**; `3260` → **0**; `time and price` → **0**.
- **FINRA's own Rule 3260 page:** all four content tabs — Notices, Guidance, News Releases, FAQs — render the literal string "**No Results Found**." The only attached material is seven historic NASD notices, newest 2004.

**And the closest analogue in the whole P8 register never invokes the rule at all.** The *CommandTRADE / GlobalTec* no-action letter — locally installed, user-programmable software that in automatic mode transmitted complete orders to the user's own broker with **no human act per order** — was retrieved in full, both the staff response and the incoming request. **In both documents: `2510` → 0 occurrences, and `discretion` (any form) → 0 occurrences.** The staff granted relief to fully unattended order-transmitting software **without the word "discretion" appearing anywhere in either document.** That is a fact about the analytical frame the staff used — §15(a) broker status, not discretionary-account analysis — and **not** a holding that the exception applies or that no discretion existed.

**The one near-miss, and it is not software.** *Guang Lu*, Rel. 34-51047 (14 Jan 2005) is the only located proceeding where the *medium* of order entry was argued to matter under Rule 2510. The Commission held the rule "**does not distinguish between online and other trading activity**," and that Rule 3050(c) applies "**regardless of how or where the associated person effectuates the trades.**" That concerns a channel used by a registered person, not a product used by a customer — but it forecloses any argument that the software medium alters the analysis.

**(d) Does the exemption run to members only? — the brief's framing needs correcting twice over.**

**First correction: the phrase the brief expected does not exist in the rule.** "A member or a person associated with a member" appears **nowhere** in FINRA Rule 3260. A mechanical count over the rule's operative text returns **`associated` → 0 occurrences.** The phrase exists only in **proposals that were never adopted** — RN 09-63 (2009) and RN 15-22 (2015), whose Attachment A would have read "**A member or an associated person may exercise discretion** as to the time or price of execution…". Both were abandoned; see S42-09 n.11 and RE-4.2-01's amendment history.

**Second correction: the exception sentence has no personal subject at all.** Its grammatical subject is "**discretion**," and its verb is passive — "shall be executed" — with no named actor. The only person named in (d)(1) is "**a customer**," who is the *giver of the order*, not the exerciser of the discretion. And the carve-out is from "**This Rule**," whose own addressees are, verbatim: "**No member**" (a); "**No member or registered representative**" (b); "**The member or the person duly designated**" (c).

**Where regulators have supplied a subject, they have supplied a member every time — six times out of six:**
- Rel. 34-49883 at 33 (the Commission): "NASD Rule 2510(d)(1) **allows members to exercise** time and price discretion…"
- NASD NTM 04-71: "**Rule 2510(d)(1) allows members to exercise** time and price discretion…"
- FINRA RN 15-22 at 6: "an exception … **for the exercise of discretion by a firm or an associated person**…"
- FINRA RN 15-22, Attachment A (never adopted): "**A member or an associated person may exercise discretion**…"
- *Sathianathan*, 34-54722 at 15: "Conduct Rule 2510(d)(1) provides that **these requirements** do not apply to…"
- *Pino*, 34-74903 at 12: "**NASD Rule 2510 does not apply to a registered representative exercising** 'discretion as to the price at which or the time when…'"

**And the federal analogue is drawn the same way, with no exception at all.** 17 C.F.R. §240.15c1-7, which FINRA itself cites as the federal counterpart (S42-09 n.12), reaches only "**any broker, dealer or municipal securities dealer**" and **contains no time-and-price exception whatsoever.**

Stated factually, as the shared context requires, and without drawing the conclusion: **FINRA Rule 3260 imposes duties on members and registered representatives and on no one else. Paragraph (d)(1) removes a category of conduct from those duties. It is a scope limitation on a rule, not a general definition of what is or is not discretion.** On its face the sentence speaks to the application of this Rule; it does not purport to characterise conduct by persons the Rule does not reach. A non-member is not in the class the Rule regulates, so there is nothing in Rule 3260 for a non-member to be exempted from. **What that means for a non-member relying on (d)(1) as a *characterisation* is that the reliance is on vocabulary borrowed from a rule addressed to someone else, and no located authority states whether that characterisation travels outside the Rule's subject class.** The same is true of every state analogue located in this track (WAC 460-20C-210(6), WAC 460-24A-220(2)): each is a carve-out from a conduct prohibition addressed to a registrant.

**(e) Rule 4512(a)(3) and 3260(d)(1) consistency.** Full texts and a divergence table at RE-4.2-04. In short: **Rule 4512(a)(3) calls this latitude "investment discretion granted by a customer"** and exempts it from one *recordkeeping* duty; Rule 3260(d)(1) never uses the words "investment discretion" and exempts from a different set of duties, with a day limit, an order-ticket requirement and an institutional carve-out that 4512(a)(3) does not carry. They do not contradict, but they are **not a single coherent definition**, and the quantity formulas differ ("definite amount" vs "definite dollar amount or quantity"). FINRA proposed harmonising them twice and never did. **A design that reads (d)(1) as establishing that bounded price-and-time latitude "is not discretion" is reading it wrongly. The FINRA rulebook's own word for it is "investment discretion." It is discretion that this particular SRO rule does not require written pre-authorisation for — when exercised by a member, on a definite order, within the business day.** The Commission's most recent word is to the same effect: "**determining the price at which a trade occurs is an exercise of discretion subject to only a limited exception**" (*DiPaola*, Rel. 34-105568 (28 May 2026), n.8 — RE-4.2-05).

**(f) Two further corrections to the brief's premises, established from the filings.**
- **There is no SEC approval order for FINRA Rule 3260.** The brief asked for one. NASD Rule 2510 was renumbered into the consolidated rulebook by **SR-FINRA-2019-009, a Notice of Filing and Immediate Effectiveness** under §19(b)(3)(A), 84 FR 15646 (16 Apr 2019), eff. 8 May 2019, adopted "**without any substantive changes**." The filing page lists exactly two documents and no approval order. **The Commission said nothing about the scope of the time-and-price exception in connection with the transfer.**
- **NASD 2510(d)(1) and FINRA 3260(d)(1) are textually identical in every operative word.** The only differences anywhere in the rule are two cross-references: in (b), "Rule 3010" → "Rule 3110"; in (d)(1), "Rule 3110(c)(4)" → "Rule 4512(c)". **Every decision construing 2510(d)(1) therefore construes the words now in 3260(d)(1)** — which matters, because all of the adjudicated authority is under the old number. The four operative elements have been in the text continuously since at least 1991 (NASD Rules of Fair Practice, Art. III, §15(d)(1), as reproduced in NTM 91-80, 92-25 and 93-1); everything added in 2005 is a *restriction*.

### DA-4.3 · Written-authorization and natural-person requirements attaching to a bounded standing authority granted to software

**(a) FINRA Rule 3260(b).** Retrieved and quoted in full at RE-4.2-01. The operative sentence:

> "No member or registered representative shall exercise any discretionary power in a customer's account unless such customer has given **prior written authorization to a stated individual or individuals** and the account has been accepted by the member, as evidenced in writing by the member or the partner, officer or manager, duly designated by the member, in accordance with Rule 3110."

Two elements, not one: a customer's prior written authorization **to a stated individual or individuals**, *and* acceptance of the account by the member evidenced in writing. The noun for the grantee is "individual." The rule's subject is "No member or registered representative" — the duty is the member's, and the authorization is a precondition to the *member's* exercise of discretion.

**(b) 17 C.F.R. §240.17a-3(a)(17)(ii).** Quoted in full at RE-4.3-01. It requires "a record containing the dated signature of each customer or owner granting the authority and the dated signature of each natural person to whom discretionary authority was granted." Adopting release 34-44992 restates it and footnotes it, at n.21, to "NYSE Rule 408 and NASD Rule 2510(b)." **The federal natural-person wording is derived from the SRO rules, not independently reasoned.** Neither the rule nor the release contains any sentence stating that a grantee must be a natural person, or addressing what happens if the grantee is not one. The requirement is expressed as a recordkeeping obligation on the broker, and its natural-person language describes whose signature is captured.

**(c) WAC 460-24A-220(5) and the Washington chain.** Three findings, one of them a correction.
 - WAC 460-24A-220 is the **investment adviser** rule, not a broker-dealer rule (RE-4.3-07). Its (5) requires a "written third-party trading authorization" and has no carve-out. Its (2) has a time-and-price carve-out that **retains** "definite amount of a specified security" but **has no business-day limit.**
 - The Washington **broker-dealer** analogue is WAC 460-20C-210(6), new since 13 October 2024, when WAC 460-21B-060 and WAC 460-22B-090 were repealed by WSR 24-19-055 (RE-4.3-08). Its carve-out — "unless the discretionary power relates solely to the time and/or price for the execution of orders" — **omits both** the "definite amount of a specified security" requirement and the business-day limit. It is materially broader than FINRA Rule 3260(d)(1). Anything citing the repealed rules as current Washington law is stale.
 - On **form**, the Washington instruments say "written" and stop. No Washington DFI interpretation on the form of a third-party trading authorization was located (NF-5). The P7 chain through RCW 1.80.060(3) was not extended in this track — it was assigned to the state researcher who could not be launched within the concurrency cap, and is carried forward as an open item (see "Not covered" below).

**(d) Advisers Act Rule 206(4)-2 and the SLOA line.** The custody definition is at RE-4.3-05; the letter at RE-4.3-04. **The letter's holding runs against the brief's framing.** The staff said "We disagree": a SLOA **does** confer custody, and the relief was only from the surprise examination, on seven conditions. The seven are reproduced verbatim at RE-4.3-04. Mapping them: reps 1, 5 and 6 are **payee-identity controls with no counterpart** in a configuration where nothing moves to a third party. Reps 2, 3, 4 and 7 map, and are the measure: a separate written authorization; **verification and prompt per-event notice performed by the custodian**; a client power to terminate or change; and an **initial plus annual reconfirmation notice from the custodian.** The configuration's journal, emergency stop and approval surface cover parts of reps 3 and 4. **Nothing in the configuration corresponds to rep 7's annual reconfirmation, and reps 3 and 7 are duties of the *custodian*, which in the configuration is the member's own broker — a party the configuration does not control and has no agreement with.** The most useful sentence in the letter is footnote 1: an arrangement structured so the actor "does not have discretion as to the **amount, payee, and timing** of transfers … would not implicate the Custody Rule." And the most useful sentence for separating custody from trading is the staff's own: an actor with power to dispose of assets "**for any purpose other than authorized trading**" has access — i.e. authorized trading is not access.

**(e) State equivalents and the NASAA model.** Partially covered. Washington is done (RE-4.3-07, RE-4.3-08, RE-4.3-09). The current Washington broker-dealer text ("solely to the time and/or price for the execution of orders") is **the NASAA model formulation** — Washington adopted the model wording, dropping FINRA's two narrowing elements. The NASAA model rule itself was not retrieved from NASAA's own publication within this track (NF-6); the finding that Washington's text is the model formulation rests on the identity of the wording with the formulation quoted in the brief and with the sampled state rules, and is marked ◇ pending retrieval of NASAA's own document. **The multi-state sample was not completed** — see "Not covered."

**(f) WHO CAN BE THE GRANTEE? — the crux.**

**There is no authority either way. That is the finding, and it is documented rather than inferred.**

More precisely, three things are true at once and must not be collapsed:

1. **No located instrument states that the grantee of a trading authorization must be a natural person.** No rule, release, letter or decision retrieved in this track contains a sentence to that effect. Searched and documented at NF-1 and NF-2.
2. **No located instrument states that the grantee may be a program, an automated system or a non-person.** Equally absent. Same searches.
3. **Every operative instrument is nonetheless *drafted* on the assumption of a human or at least a legal-person grantee, and the drafting chain is traceable.** FINRA Rule 3260(b) says "a stated individual or individuals." 17 C.F.R. §240.17a-3(a)(17)(ii) says "each natural person to whom discretionary authority was granted," and Rel. 34-44992 n.21 sources that phrase expressly to NASD Rule 2510(b) and NYSE Rule 408. RCW 21.20.005(12) defines "person" as a closed list of an individual and legal entities with no residual catch-all. The Washington trading-authorization rules do not use the defined term at all, and name no grantee: WAC 460-20C-210(6) says only "written discretionary authority from the customer," and WAC 460-24A-220(5) says "a third party."

The honest statement of the position is therefore: **the vocabulary available in every relevant instrument for the grantee of a trading authorization is the vocabulary of persons — "individual," "natural person," "third party" — and in the two federal instruments that name the grantee at all, the words are "individual" and "natural person." No instrument tests the assumption, because no instrument was written against a fact pattern in which the grantee is software.** A grant to a program does not violate any located express prohibition; it produces an instrument for which the federal recordkeeping rule has no field, and to which the SRO rule's noun does not apply on its face.

**One further point, which the brief asks for and which cuts against reliance.** The subject of FINRA Rule 3260's exemptions is a member or a person associated with a member; the subject of WAC 460-20C-210(6) is a registered broker-dealer; the subject of WAC 460-24A-220 is an investment adviser. **Every time-and-price carve-out located in this track is drafted as a carve-out from a conduct prohibition addressed to a registrant.** Factually, and without drawing the legal conclusion: these sentences tell a *registered firm* when it need not obtain written authority. On their face they are addressed to registrants and speak to no one else. A non-registrant invoking a time-and-price carve-out is not invoking a provision written to it, and no located authority says whether the characterisation travels. That is a gap, not a bar.

### DA-4.4 · Is there a supportive end to the GEL Direct Trust line?

**(a) Yes — and it is a rule of the Commission, not a staff letter.**

**17 C.F.R. §240.10b5-1(c)(1)(i)(B)(2)** is the supportive end. Its exact words:

> "Included a written formula or algorithm, or computer program, for determining the amount of securities to be purchased or sold and the price at which and the date on which the securities were to be purchased or sold"

and the transactions that result are described throughout paragraph (c)(1) as **"a person's purchase or sale"** and as **"the purchase or sale that occurred … pursuant to the contract, instruction, or plan."** The Commission's own gloss in Rel. 33-7881 is that such a person may "plan securities transactions in advance … and then **carry out those pre-planned transactions at a later time.**"

Against *GEL Direct Trust*'s inference of discretion from a six-second interval, this is the counterweight: **an express federal rule contemplating that a computer program determines amount, price and date, and treating the resulting trade as the adopter's own.** It is stronger than a staff letter because it is a rule, and weaker than a holding because it decides a different question — whether a trade was "on the basis of" material nonpublic information — and merely *presupposes* the attribution rather than deciding it. **Label: analogy.**

Secondary supportive material, all analogical and all labelled: **12 C.F.R. §1005.10(b)** and comment 10(b)-5 (RE-4.3-06), an express model of a standing authorization that remains the consumer's own, with an electronic-form standard of **identity plus assent**; and **17 C.F.R. §242.100**'s "agent independent of the issuer" test (RE-4.4-04), the only located federal rule enumerating the factors that determine whose activity a formula-driven machine-executed plan purchase is — prices, amounts, timing, manner, broker selection.

**And the convergence is the finding.** Three instruments approached from three directions — the SLOA letter's footnote 1 ("amount, payee, and **timing**"), Rule 10b5-1(c)(1)(i)(B)(2) read with Rel. 33-7881's calendar definition of "**date**", and Regulation M's control test ("prices or amounts, the **timing** of, or the manner in which") — each isolate **timing** as the parameter that decides whose transaction it is, and **timing is the one parameter that standing mode necessarily delegates to the machine.** Everything else in the configuration traces to a member setting. Timing does not: it is determined by when a member-authored rule fires against live market data. **That is the exposed axis, and it is exposed on all three instruments independently.**

**(b) The delay question — no supportive authority exists, and the nearest analogue is mildly adverse.**

**No authority was located, in any source searched, holding or stating that an interval between a signal and an order's submission bears on who made the decision.** Documented at NF-3.

The nearest instrument is Rule 10b5-1(c)(1)(ii)(B)'s cooling-off period — the only mandated delay between the adoption of a trading instruction and its execution in federal securities law. The Commission's stated rationale, at Rel. 33-11138, is that a delay "reduces the risk that corporate insiders could benefit from any material nonpublic information of which they may have been aware when adopting the plan." **That is an informational rationale, not an attributional one.** On the Commission's reasoning a longer interval says nothing about who decided; it says the adopter was less likely to be trading on what he knew. The one federal delay requirement therefore does not support the design's premise, and read strictly is mildly adverse to it, because it shows what a regulator says when it does impose such a delay — and attribution is not it.

**This is a finding the design needs, stated plainly: the built-in delay is not supported by any located authority as bearing on who decided. It may still have evidential value in rebutting an inference of the *GEL* kind — an inference is not a rule, and what was inferred from six seconds may be harder to infer from longer — but that is an argument about the persuasiveness of an inference, not a legal proposition with a source behind it.** Note also the asymmetry the design should confront: *GEL* used a short interval to infer discretion **in the actor**. A longer interval does not by itself relocate the decision to the customer; it only weakens one evidentiary route to the opposite conclusion. Nothing located fills that gap.

**(c) The other candidate lines.** Dividend reinvestment is within Regulation M's defined term "plan" (RE-4.4-04), and Rule 102(c) excepts plan distributions, with the "agent independent of the issuer" test supplying the attribution axes. Automatic investment plans, systematic withdrawal plans, direct stock purchase plans, the CommandTRADE/GlobalTec chain and the prime-brokerage standing-instruction context were assigned to the dedicated 4.4 researcher, who could not be launched within the concurrency cap; they were partially covered directly and are otherwise carried forward. See "Not covered."

---

## Negative findings

Each records the endpoint, the exact query, and the count. Absence is documented, never inferred.

**NF-1 · No case law applies discretionary-authority analysis to broker-dealer software.**
Endpoint: `https://www.courtlistener.com/api/rest/v4/search/?q=<query>&type=o` (CourtListener v4 search API, open, no token). Queried 7 Sep 2026.

| Query (exact) | Count |
|---|---|
| `"automated" "discretionary authority" broker-dealer software` | **0** |
| `"natural person" "discretionary authority" "17a-3"` | **0** |
| `"time and/or price" discretion broker` | **0** |
| `"time and price discretion"` | **2** — *Galarneau v. Merrill Lynch, Pierce, Fenner & Smith Inc.* (1st Cir. 2007); *Johnson v. Merrill Lynch, Pierce, Fenner* (Ala. Civ. App. 1981). Neither involves software. |
| `"discretion as to time and price"` | **1** — *SEC v. Pasternak* (D.N.J. 2008). Does not involve software. |
| `"NASD Rule 2510"` | **1** — *O'Malley v. Boris* (Del. 1999). Does not involve software. |
| `"Rule 3260"` | **2** — *Thomas v. Trento* (Pa. Super. 1999); *Royal Bedding Co. v. Lorenz* (Pa. Super. 1989). Both are Pennsylvania civil-procedure matters; neither concerns FINRA Rule 3260. |
| `"standing instruction" broker discretion securities` | **3** — none on point. |

Conclusion recorded as a finding: **across these eight queries, no opinion applying time-and-price discretion analysis, or FINRA Rule 3260 / NASD Rule 2510, to software was located.**

**NF-2 · Broad queries return keyword noise, not on-point law — recorded so the low counts above are not mistaken for a thin search.**
Same endpoint, same date.

| Query (exact) | Count | Note |
|---|---|---|
| `"discretionary authority" "computer program"` | **116** | Top results are criminal-sentencing and state civil matters (*Akin*, Tex.; *State v. Junior*, Tenn. Crim. App.; *Taunton*, Tex. App.). Not securities attribution. |
| `"discretionary authority" seconds broker order` | **869** | Unfiltered keyword co-occurrence; top results include *In re Series 7 Broker Qualification Exam Scoring Litig.* and NLRB matters. Not on point. |
| `discretion inferred interval order execution broker` | **415** | Top results are workers'-compensation and labour matters. Not on point. |
| `"delay between" "the decision" trade discretion` | **493** | Top results are FTC, patent and customs matters. Not on point. |
| `"who made the decision" algorithm securities order` | **7** | *Mediostream v. Microsoft*, *Hasso v. Hapke*, *BMG v. Cox* — none on securities attribution. |
| `"trading authorization" "third party" broker written` | **18** | *Burket v. Lippitt*; *Tischler v. Fahnestock*; *Straits Fin. v. Ten Sleep Cattle*; *Kidder Peabody v. Unigestion*. None addresses who may hold the authorization or whether it may be held by software. |

**NF-3 · No authority that a delay bears on who decided.**
Sources searched: CourtListener v4 (queries in NF-1 and NF-2, specifically `"delay between" "the decision" trade discretion` = 493, `discretion inferred interval order execution broker` = 415, `"discretionary authority" seconds broker order` = 869 — all keyword noise, no on-point result in the returned sets); and full text of Rel. 33-11138 (`https://www.sec.gov/files/rules/final/2022/33-11138.pdf`, retrieved 7 Sep 2026, 606,338 characters extracted), in which "cooling-off" occurs **237 times**, "algorithm" **8 times** and "computer program" **5 times**, and in which the stated rationale for the delay is informational (quoted at RE-4.4-03). **No sentence in that release ties a delay to the identity of the decision-maker.** No SEC release, FINRA notice or judicial opinion was located treating an interval between signal and submission as bearing on attribution. **This is a genuine gap and the design should treat it as one.**

**NF-4 · No later letter modifying or withdrawing the IAA SLOA letter was located within this track.**
Endpoints tried: `https://www.sec.gov/divisions/investment/noaction/2017/investment-adviser-association-022117-206-4-2.htm` → **HTTP 404, 53,435 bytes** (SEC's standard not-found page; note the size, per the shared context's warning to check size not status); `https://www.sec.gov/investment/investment-adviser-association-022117-2064-2` → **HTTP 404, 53,435 bytes**; `https://www.sec.gov/divisions/investment/noaction/2017/investment-adviser-association-022117-206-4.htm` → **HTTP 200, 14,861 bytes, full text retrieved.** The incoming letter was retrieved at `…-206-4-incoming.pdf` → **HTTP 200, 109,728 bytes.** **Extended by a direct search of the Division of Investment Management's own no-action index.** Endpoint: `https://www.sec.gov/divisions/investment/im-noaction.shtml`, retrieved 7 Sep 2026, **HTTP 200, 220,858 bytes, parsed to 1,442 unique href/link-text entries.** Filtering on `adviser association`, `standing`, `custody`, `206-4` and `206(4)-2`, the Investment Adviser Association appears **four** times, at:
- `/divisions/investment/noaction/iaa120205.htm` (2005)
- `/divisions/investment/noaction/2007/iaa092007.pdf` (2007)
- `/divisions/investment/noaction/2016/investment-adviser-association-042516-206(4).htm` (25 Apr 2016)
- `/divisions/investment/noaction/2017/investment-adviser-association-022117-206-4.htm` (**21 Feb 2017 — the SLOA letter**)

**The 2017 letter is the most recent IAA letter on the index. No later IAA letter, and no later letter bearing a "standing" or SLOA title, appears anywhere in the 1,442 entries.** Combined with the letter's own page carrying no supersession note, this materially strengthens the finding: on the issuing Division's own published index, **nothing supersedes, extends or withdraws the SLOA letter.**

**Custody-rule FAQ checked directly.** Endpoint: `https://www.sec.gov/divisions/investment/custody_faq_030510.htm`, retrieved 7 Sep 2026, **HTTP 200**, 87,315 characters of text extracted. (The modern path `sec.gov/rules-regulations/staff-guidance/division-investment-management-frequently-asked-questions/staff-responses-questions-about-custody-rule` serves the identical document.) Searched for `standing letter`, `SLOA`, and `letter of instruction`: **0 occurrences of each.** The only two matches for the string `standing` are both inside the word "out**standing**" ("holders of the outstanding securities of the issuer"), at character offsets 61,403 and 63,377 — verified by inspecting the surrounding text.

**The FAQ page bears: "Last Reviewed or Updated: Feb. 21, 2017."** That is **the same date as the SLOA letter itself.** So the staff's custody FAQ was last touched on the very day the SLOA letter issued and **still contains no standing-letter-of-authorization entry.**

**◇2 is closed.** Across the Division's no-action index (1,442 entries), the letter's own page, and the custody-rule FAQ, **nothing supersedes, extends, narrows or interprets the 21 February 2017 SLOA letter.** It stands exactly as written — including its "We disagree." The IM Guidance Update series was not separately enumerated, which is the one remaining aperture, but a Guidance Update revising a position this central would ordinarily be reflected in the FAQ, and the FAQ is silent.

**NF-5 · No express electronic-form standard in any securities instrument located in this track.**
FINRA Rule 3260(b) ("prior written authorization"), 17 C.F.R. §240.17a-3(a)(17)(ii) ("the dated signature"), WAC 460-20C-210(6) ("written discretionary authority"), WAC 460-24A-220(5) ("a written third-party trading authorization") — **each says "written" or "signature" and stops.** None contains anything comparable to Regulation E Official Interpretations comment 10(b)-5, which expressly states that the standard "permits signed, written authorizations to be provided electronically" and that the requirements "are satisfied by complying with the Electronic Signatures in Global and National Commerce Act, 15 U.S.C. 7001 et seq." **The contrast is the finding: consumer payments law says expressly what form a standing authorization may take; the securities instruments are silent.** No Washington DFI interpretation on the form of a third-party trading authorization was located, but the DFI endpoint sweep was assigned to the state researcher who could not be launched — so this is recorded as **not yet fully searched**, not as an established absence.

**NF-6 · NASAA's own publication of the model rule was not retrieved within this track.**
The finding that WAC 460-20C-210(6)'s formulation ("solely to the time and/or price for the execution of orders") is the NASAA model wording rests on the identity of that wording with the formulation recited in the brief, not on NASAA's own document. **Marked ◇.** Retrieval of the NASAA model rule from nasaa.org, and the multi-state sample, were assigned to the state researcher who could not be launched within the concurrency cap.

**NF-15 · Rule 3260 / NASD Rule 2510 has never been applied to software, in any forum, in either direction.**
Full query tables at DA-4.2(c). Endpoints: **CourtListener v4** (`courtlistener.com/api/rest/v4/search/?type=o`) — 22 queries, 9 returning **0**, including every query pairing the rule with software or algorithms; `"time and price discretion"` returns only **2** opinions in the entire corpus (*Galarneau*, 1st Cir. 2007; *Johnson v. Merrill Lynch*, Ala. Civ. App. 1981), neither involving software. **Federal Register API** — 17 term queries: `"3260(d)(1)"` → **0** (*no FR document has ever cited it*); `"FINRA Rule 3260"` → **19**, all Rule 17d-2 allocation plans, i.e. mechanical lists with no substance; `"2510(d)(1)"` → **13**, all 2003–2008 NASD amendments plus options exchanges adopting parallel rules; `"FINRA Rule 3260" software` → **0**; `"time and price discretion" "computer program"` → **0**; `"2510(d)" software` → **0**; `"2510(d)" robo` → **0**. **Mechanical full-text counts:** Rel. IA-5249 (`software` 0, `algorith*` 0, `automat*` 0, `robo` 0, `3260` 0, `2510` 1 — a bare cross-reference); Reg BI adopting release (`2510` 0, `3260` 0, `time and price` 0); FINRA *Report on Digital Investment Advice* (`2510` 0, `3260` 0, `time and price` 0); **CommandTRADE/GlobalTec staff letter *and* incoming request (`2510` → 0, `discretion` → 0 in both).** FINRA's own Rule 3260 page renders "**No Results Found**" on all four content tabs. **The absence is symmetric: no favourable authority and no adverse authority.**

**NF-16 · No SEC approval order for FINRA Rule 3260 exists.**
`finra.org/rules-guidance/rule-filings/sr-finra-2019-009` (HTTP 200) lists exactly two documents — "Text of the Proposed Rule Change" and "Notice of Filing and Immediate Effectiveness." The rule was adopted under §19(b)(3)(A), 84 FR 15646 (16 Apr 2019), "without any substantive changes." **The brief's request for "the SEC approval release for FINRA Rule 3260 (SR-FINRA-2009-xxx)" rests on a filing that does not exist**, and the Commission said nothing about the exception's scope in connection with the transfer.

**NF-17 · No court has construed the words of 2510(d)(1) / 3260(d)(1).**
CourtListener: `"discretion as to the price at which or the time"` → **0**; `"definite amount of a specified security"` → **0**; `"2510(d)(1)"` → **0**; `"3260(d)(1)"` → **0**. The two federal appellate decisions in the line are ***Birkelbach v. SEC***, 751 F.3d 472 (7th Cir. 2014) — full text reviewed, **containing no reference to time-and-price discretion, Rule 2510, or "definite amount"** — and ***Sathianathan v. SEC***, 304 F. App'x 883 (D.C. Cir. 2008), a nonprecedential summary affirmance.

**NF-18 · No NASD or FINRA interpretive letter on 2510(d)(1) was located; FINRA's letter index and disciplinary database are not machine-reachable.**
`finra.org/rules-guidance/guidance/interpretive-letters` → HTTP 200, 114,234 B, but **client-rendered**: `2510` / `3260` / `discretion` → **0 occurrences** in the server HTML. A rule-letter URL surfaced by search returned **HTTP 404** via curl (three UAs) and via WebFetch. `finra.org/rules-guidance/oversight-enforcement/finra-disciplinary-actions-online` → HTTP 200, 95,150 B, client-rendered with **no exposed API**; three endpoint guesses returned 404, 404 and a connection failure (000). **A systematic AWC sweep for 3260(d)(1) charges was therefore not possible — an open item, worked around via FINRA's server-served monthly disciplinary PDFs.** Also: NASD NTM **75-33 and 76-30** — the two oldest notices FINRA itself lists against Rule 3260 — both return **HTTP 404**; their content is **UNVERIFIED**.

**NF-19 · Six respondent names supplied in the brief were checked and eliminated as off point.**
*Rafael Pinchas* (Rel. 34-41816), *Michael Frederick Siegel* (34-58737) and *Dane S. Faber* (34-49216) were each retrieved in full and mechanically searched: `2510` → **0**, `time and price` → **0**, `definite amount` → **0** in all three. No SEC opinion discussing Rule 2510 or time-and-price discretion was located under *Gerald E. Donnelly*, *Keith L. DeSanto* or *John M. Reynolds*. **The brief's candidate list did not survive verification; the actual line is *Sathianathan* → *Murphy* → *Pino* → *DiPaola*.**

**NF-10 · No SEC or FINRA statement was located that a customer-entered stop, conditional or algorithmic order is NOT the exercise of discretionary authority by the broker.**
The proposition is **structurally implied** — the designation duties in 17 C.F.R. §240.17a-3(a)(6)(i) and (a)(7)(i) attach only to discretion "by the member, broker or dealer, or associated person thereof"; FINRA Rule 4512(a)(3) runs its record duty to "each named, associated person of the member"; FINRA Rule 3260(b) to "a stated individual or individuals"; and the exchange definitions attribute the trigger parameter to the User/Participant — **but it is stated nowhere.**
Sources searched in full text: §240.17a-3, §240.15c3-5, §242.600, §240.3b-16; FINRA Rules 5310, 4512, 3260, 3110, 2360; FINRA RN 15-09, 15-46, 16-21; NASD NTM 98-66; Rel. 34-61358, 34-63241, 34-72065, 34-73652, 34-74032, 34-84528; the Rule 606 and Rule 15c3-5 staff FAQs; and *All About Auto-Trading*.
Federal Register API, `conditions[term]=<term>&conditions[agencies][]=securities-and-exchange-commission`, 7 Sep 2026:

| exact term | count |
|---|---|
| `"customer's own trading system"` | **0** |
| `"third-party trading software"` | **0** |
| `"third-party trading platform"` | **0** |
| `"customer-supplied algorithm"` | **0** |
| `"does not constitute discretion"` | **0** |
| `"not the exercise of discretion" order` | **0** |
| `"conditional order" "discretionary authority"` | **1** — *ESC Strategic Funds / Equitable Securities Corp.*, 3 Nov 1995, an Investment Company Act application; not on point |

**NF-11 · No no-action letter concerning third-party retail trading, order-management or conditional-order software appears on the SEC Division of Trading and Markets no-action index.**
Endpoint: `https://www.sec.gov/rules-regulations/no-action-interpretive-exemptive-letters/division-trading-markets-no-action`, retrieved 7 Sep 2026, **HTTP 200, 571,466 bytes.** Filtered for `software`, `platform`, `order entry`, `routing`, `technology`, `system`: **40 lines returned; every substantive hit is an ECN/ATS or exchange-facility letter** — Attain, BRUT, OnTrade, Tradebook, Track, GlobeNet, Island, REDI, RAES, AUTOM, Large Order Utility, POSIT, Market Systems Inc. **This extends, and does not repeat, P7's negative finding on vendor no-action relief.**

**NF-12 · No source located reconciles Rule 606(b)(3) routing "discretion" with Exchange Act §3(a)(35) investment discretion.**
Full-text search of Rel. 34-84528 (752,527 characters extracted) for `3(a)(35)` → **0 hits.** The release and the 16 Aug 2019 staff FAQ use "discretion" throughout with no cross-reference to §3(a)(35) or to §240.17a-3(a)(17)(ii). **The two concepts are not equated by any located authority and must not be conflated.**

**NF-13 · FINRA Regulatory Notice 15-09 and FINRA Rule 3110 contain no guidance on third-party or customer-side order-entry software.**
RN 15-09 (`finra.org/rules-guidance/notices/15-09`, HTTP 200, 120,019 B): grep for `third-party`, `third party`, `vendor` → **0 hits.** Rule 3110 (`finra.org/rules-guidance/rulebooks/finra-rules/3110`, HTTP 200, 150,717 B): grep for `third-party|third party|vendor|outsourc|software` → only a Form U4 verification service-provider reference at (e) and the branch-office clause at (f)(2)(A)(ii)g ("All orders are entered through the designated branch office **or an electronic system established by the member**"). **Neither addresses customer-side or vendor order-entry software.**

**NF-14 · CourtListener results for conditional-order and trading-software terms.**
Endpoint `courtlistener.com/api/rest/v4/search/?type=o&q=…`, 7 Sep 2026:

| query | count | note |
|---|---|---|
| `"stop-loss order" AND "discretionary authority"` | **3** | *Uzyel v. Kadisha* (Cal. App. 2010); *First American Discount Corp. v. Jacobs* (Ill. App. 2001) ×2 |
| `"stop order" AND "discretionary account"` | **3** | *Indosuez Carr Futures v. CFTC* (7th Cir. 1994); *In re Nassbridges*; *In re Cannon* |
| `"conditional order" AND "discretionary authority"` | **19** | top hits all non-securities (criminal and state civil) |
| `"one-cancels-the-other"` | **7** | **none securities** |
| `"trailing stop" AND "discretionary"` | **2** | — |
| `"automated trading software" AND "broker-dealer"` | **0** | — |
| `"stop loss order" AND "customer instruction"` | **0** | — |
| `"algorithmic order" AND "discretionary authority"` | **0** | — |

**Five further queries returned HTTP 429 on every attempt across four runs** (1.5 s, 20 s, 25 s and 70 s inter-query delays): `"trading software" AND "discretionary authority"`; `"order management system" AND "discretionary authority"`; `"third-party trading platform"`; `"auto-trading" AND newsletter`; `"bracket order" AND securities`. **These remain UNRUN — the court-decision coverage on third-party trading software is incomplete and must not be reported as an established absence.** See ◇8.

**NF-8 · No later letter extends, narrows or withdraws the CommandTRADE / GlobalTec relief.**
The brief asks whether any later letter in that chain extends it. Endpoints and results:
- `https://www.sec.gov/divisions/marketreg/mr-noaction.shtml` (the Division of Trading and Markets no-action index; fetched with `curl -L` per the shared context's 301 note) → **HTTP 200, 138,058 bytes**, containing **738 unique no-action letter links.** `CommandTRADE` appears in exactly **one** unique href: `/divisions/marketreg/mr-noaction/commandtrade122805.htm`. **No second, later or superseding CommandTRADE or GlobalTec entry exists on the index.**
- `https://www.sec.gov/divisions/marketreg/mr-noaction/commandtrade122805.htm` → **HTTP 200**, letter retrieved. The page footer reads "**Modified: 01/06/2006**" and the document contains **no withdrawal, supersession, modification or revocation note.** Its closing reservation is the standard one: "This position is based on the facts presented and the representations you have made, and **any different facts, including any change in the operation of the CT Platform**, as defined in your letter[,] might require a different response. Furthermore, this response only expresses the Staff's position on enforcement action and does not purport to express any legal conclusions on the question presented."
- EDGAR full-text search: `https://efts.sec.gov/LATEST/search-index?q=%22CommandTRADE%22` returned **HTTP 500** (server error, not a zero result — recorded as a failed endpoint, not as an absence). `…q=%22GlobalTec%22` returned **HTTP 200 with 115 hits**, all corporate filings from 2002–2005 unrelated to the no-action letter. EDGAR full-text search indexes filings, not staff letters, so it is not a probative endpoint for this question either way.

**A methodological point that makes the absence probative rather than merely silent.** The same index carries an entry titled "**OnTrade, Inc./NexTrade ECN: Withdrawal of No-Action Position**" at `/divisions/marketreg/mr-noaction/ontrade011106-withdrawal.htm`. **The Division therefore does publish withdrawals of no-action positions as distinct, titled entries on this very index.** The absence of any comparable CommandTRADE withdrawal entry is accordingly evidence of a kind, not merely an absence of evidence — a withdrawal, had one occurred, would be the sort of thing this index records.

**Finding, stated with its limits:** on the Division's own index of 746 unique letter entries, the CommandTRADE relief stands alone and unmodified; the letter itself bears no supersession note; and the index demonstrably records withdrawals when they happen. **That is meaningful evidence the relief has not been formally withdrawn. It is not evidence that anything later extends it — nothing does.** The letter's own reservation that "any change in the operation of the CT Platform … might require a different response" remains the operative limit, and the configuration is not the CT Platform.

**NF-9 · No dividend-reinvestment, automatic-investment, systematic-withdrawal or direct-stock-purchase-plan letter appears on the Division of Trading and Markets no-action index.**
Endpoint: `https://www.sec.gov/divisions/marketreg/mr-noaction.shtml`, retrieved 7 Sep 2026, HTTP 200, 138,058 bytes, parsed to **746 unique href/link-text pairs.** Filtered on the terms `dividend`, `reinvest`, `automatic`, `systematic`, `withdraw`, `purchase plan`, `standing`, `plan admin`, `transfer agent`. **Matches: 4, none on point** — *OnTrade/NexTrade* (a withdrawal notice), *Serono S.A.* (a tender offer), *Dividend Capital Total Realty Trust* (matched on the word "Dividend" in the entity's name), and a CBOE trade-through exemption.

**Extended to the Investment Management index.** Endpoint: `https://www.sec.gov/divisions/investment/im-noaction.shtml`, retrieved 7 Sep 2026, HTTP 200, 220,858 bytes, **1,442 unique entries.** Filtered on `dividend`, `reinvest`, `automatic`, `systematic`. **Matches: none on point.** Every `dividend` hit is either a fund's name (*Eaton Vance Tax-Advantaged Dividend Income Fund*, *SPDR S&P Dividend ETF*, *Vanguard Dividend Appreciation Index Fund*, *First Trust Dividend and Income Fund*, *Lazard World Dividend & Income Fund*, *Delaware Enhanced Global Dividend and Income Fund*) or a Rule 14a-8 shareholder-proposal omission letter. `Automatic` matched only a section anchor ("Automatic Bar"). **No dividend-reinvestment or automatic-investment-plan letter addressing whose instruction the periodic purchase is appears on either index.**

**Finding, with its limit clearly stated:** across the Trading and Markets index (746 entries) and the Investment Management index (1,442 entries) — **2,188 entries in total** — no no-action letter was located treating a DRIP, AIP, systematic withdrawal plan or DSPP purchase as the investor's own standing instruction. Trading and Markets is where a "is the plan administrator a broker" letter would sit, and Investment Management is where a fund-plan letter would sit, so the two indexes cover the likely locations. **But Corporation Finance's index was not searched**, and DRIP letters directed at *issuers* would plausibly sit there. This negative finding is bounded accordingly and must not be read as establishing that no DRIP/AIP relief exists anywhere. See "Not covered," item 5.

**NF-7 · Access notes for endpoints that failed.**
- `ecfr.gov/api/versioner/v1/full/...` returns **HTTP 406, 171 bytes** — `{"message":"This endpoint requires response compression. Send an Accept-Encoding header that permits compression."}` — unless called with `curl --compressed`. This is **not** documented in the shared context's access notes and cost several failed calls; recorded here for the other tracks. With `--compressed` plus `Accept: application/xml`, the endpoint returns clean XML.
- `ecfr.gov/current/title-17/chapter-II/part-240/section-240.17a-3` returns **HTTP 200 but only 10,596 bytes** — a JavaScript shell, not the rule text. The identical byte count was returned for the Part 275 URL, which is the tell. **Use the versioner API, not the /current/ HTML path.**
- `sec.gov/rules/final/34-44992.htm` returns **HTTP 200 at 10,918 bytes** (a stub); `sec.gov/files/rules/final/34-44992.htm` returns **HTTP 200 at 56,448 bytes** and is the full document. The same pattern held for Rel. 33-7881 (10,812 bytes stub vs 62,366 bytes full). **Prefer the `/files/` path.**
- `finra.org/rules-guidance/rulebooks/finra-rules/3260` returned **HTTP 429 (rate limited), 5,633 bytes** when fetched concurrently with another track's sweep of the same host, and then **HTTP 403, 3,383 bytes** on a retry with a browser User-Agent. FINRA rate-limits aggressively under parallel access and then blocks. **Workaround that succeeded: the Wayback Machine.** `archive.org/wayback/available?url=…` returned snapshot `20260331204822`, and `web.archive.org/web/20260331204822/https://www.finra.org/…/3260` returned **HTTP 200, 24,632 bytes with the complete rule text.** This is FINRA's own page, archived — not a secondary source — but it is a 31 March 2026 snapshot rather than a live read, and RE-4.2-01 is flagged accordingly. **Recommended to the other tracks: when finra.org blocks, go to Wayback rather than recording the rule as unretrievable.**

---

## Search log

| # | Source / query | Endpoint | Date | Result / access note |
|---|---|---|---|---|
| 1 | IAA SLOA letter, primary URL guess with `-2` suffix | `sec.gov/divisions/investment/noaction/2017/investment-adviser-association-022117-206-4-2.htm` | 7 Sep 2026 | HTTP 404, 53,435 B (SEC not-found page) |
| 2 | IAA SLOA letter, corrected URL | `sec.gov/divisions/investment/noaction/2017/investment-adviser-association-022117-206-4.htm` | 7 Sep 2026 | **HTTP 200, 14,861 B — full text.** Date on document: 21 Feb 2017 |
| 3 | IAA SLOA letter, alternate path | `sec.gov/investment/investment-adviser-association-022117-2064-2` | 7 Sep 2026 | HTTP 404, 53,435 B |
| 4 | IAA incoming letter (PDF) | `…/investment-adviser-association-022117-206-4-incoming.pdf` | 7 Sep 2026 | HTTP 200, 109,728 B, valid PDF; 19,329 chars extracted |
| 5 | IAA incoming, alternate name | `…/iaa-022117-incoming.pdf` | 7 Sep 2026 | HTTP 404, 53,435 B |
| 6 | 17 C.F.R. §240.17a-3, eCFR HTML | `ecfr.gov/current/title-17/chapter-II/part-240/section-240.17a-3` | 7 Sep 2026 | HTTP 200 but 10,596 B — JS shell, no rule text |
| 7 | 17 C.F.R. §275.206(4)-2, eCFR HTML | `ecfr.gov/current/title-17/chapter-II/part-275/section-275.206(4)-2` | 7 Sep 2026 | HTTP 200, identical 10,596 B — confirms JS shell |
| 8 | eCFR versioner API, no compression | `ecfr.gov/api/versioner/v1/full/<date>/title-17.xml?part=240&section=240.17a-3` | 7 Sep 2026 | **HTTP 406, 171 B** — requires `Accept-Encoding` compression. Retried at 3 dates, all 406 |
| 9 | eCFR versioner API, `--compressed` | same, date 2026-09-01 | 7 Sep 2026 | **HTTP 200, 39,567 B XML — full §240.17a-3.** (a)(6)(i)(A), (a)(7)(i), (a)(17)(ii) extracted |
| 10 | eCFR versioner, custody rule | `…title-17.xml?part=275&section=275.206(4)-2` | 7 Sep 2026 | HTTP 200, 17,062 B — (d)(2) extracted |
| 11 | eCFR versioner, Rule 10b5-1 | `…title-17.xml?part=240&section=240.10b5-1` | 7 Sep 2026 | HTTP 200 — full (c)(1) extracted incl. "algorithm, or computer program" |
| 12 | eCFR versioner, Reg E §1005.10 | `…title-12.xml?part=1005&section=1005.10` | 7 Sep 2026 | HTTP 200 — (b) and (c)(1) extracted |
| 13 | eCFR versioner, Reg E Supplement I | `…title-12.xml?part=1005&appendix=Supplement I to Part 1005` | 7 Sep 2026 | HTTP 200, 122,371 B — comments 10(b)-3, -5, -6 extracted |
| 14 | eCFR versioner, Reg M §242.102 | `…title-17.xml?part=242&section=242.102` | 7 Sep 2026 | HTTP 200 — (b) exceptions, (c) Plans extracted; "dividend" not in §242.102 itself |
| 15 | eCFR versioner, Reg M §242.100 | `…title-17.xml?part=242&section=242.100` | 7 Sep 2026 | HTTP 200 — "agent independent of the issuer" and "plan" definitions extracted |
| 16 | govinfo CFR fallback for 17a-3 | `govinfo.gov/content/pkg/CFR-2024-title17-vol4/xml/CFR-2024-title17-vol4-sec240-17a-3.xml` | 7 Sep 2026 | HTTP 200, 43,808 B — 2024 annual edition; held as fallback, not relied on |
| 17 | Rel. 34-44992, standard path | `sec.gov/rules/final/34-44992.htm` | 7 Sep 2026 | HTTP 200 but 10,918 B — stub |
| 18 | Rel. 34-44992, `.txt` | `sec.gov/rules/final/34-44992.txt` | 7 Sep 2026 | HTTP 404, 313 B |
| 19 | Rel. 34-44992, `/files/` path | `sec.gov/files/rules/final/34-44992.htm` | 7 Sep 2026 | **HTTP 200, 56,448 B — full text, 181,322 chars.** n.21 located |
| 20 | Rel. 33-7881, `/files/` path | `sec.gov/files/rules/final/33-7881.htm` | 7 Sep 2026 | **HTTP 200, 62,366 B — full text, 189,821 chars.** "algorithm" at 2 offsets |
| 21 | Rel. 33-7881, standard path | `sec.gov/rules/final/33-7881.htm` | 7 Sep 2026 | HTTP 200, 10,812 B — stub, 0 hits for "algorithm" |
| 22 | Rel. 33-11138 (2022 amendments) | `sec.gov/files/rules/final/2022/33-11138.pdf` | 7 Sep 2026 | HTTP 200, 2,245,915 B; 606,338 chars extracted. "cooling-off" ×237, "algorithm" ×8, "computer program" ×5 |
| 23 | FINRA Rule 3260 | `finra.org/rules-guidance/rulebooks/finra-rules/3260` | 7 Sep 2026 | **HTTP 429 rate-limited, 5,633 B** under concurrent access. Left to Track 4.2 |
| 24 | WAC 460-24A-220 | `app.leg.wa.gov/WAC/default.aspx?cite=460-24A-220` | 7 Sep 2026 | HTTP 200, 120,235 B — full rule; lead-in and (2), (4), (5) extracted |
| 25 | WAC 460-24A-200 | `app.leg.wa.gov/WAC/default.aspx?cite=460-24A-200` | 7 Sep 2026 | HTTP 200, 143,262 B — (1)(i) and (1)(dd) extracted |
| 26 | WAC chapter 460-22B index | `app.leg.wa.gov/WAC/default.aspx?cite=460-22B` | 7 Sep 2026 | HTTP 200, 358,207 B — **revealed WAC 460-21B-060 and 460-22B-090 repealed by WSR 24-19-055, eff. 13 Oct 2024** |
| 27 | WAC title 460 chapter list | `app.leg.wa.gov/WAC/default.aspx?cite=460` | 7 Sep 2026 | HTTP 200, 113,137 B — identified ch. 460-20C as the replacement chapter |
| 28 | WAC chapter 460-20C section list | `app.leg.wa.gov/WAC/default.aspx?cite=460-20C` | 7 Sep 2026 | HTTP 200, 120,731 B — located -210 and -220 |
| 29 | WAC 460-20C-210 | `app.leg.wa.gov/WAC/default.aspx?cite=460-20C-210` | 7 Sep 2026 | HTTP 200 — (5) and (6) extracted |
| 30 | WAC 460-20C-220 | `app.leg.wa.gov/WAC/default.aspx?cite=460-20C-220` | 7 Sep 2026 | HTTP 200 — (10) and (11) extracted |
| 31 | RCW 21.20.005 | `app.leg.wa.gov/rcw/default.aspx?cite=21.20.005` | 7 Sep 2026 | HTTP 200 — (12) "Person" definition extracted |
| 32–39 | CourtListener, 8 targeted phrase queries | `courtlistener.com/api/rest/v4/search/?q=…&type=o` | 7 Sep 2026 | Counts at **NF-1**; two queries returned HTTP 429 on first attempt and were retried with backoff |
| 40–45 | CourtListener, 6 broad queries | same | 7 Sep 2026 | Counts at **NF-2**; recorded to show the low counts in NF-1 are not a thin search |
| 46 | FINRA Rule 3260, browser User-Agent retry | `finra.org/rules-guidance/rulebooks/finra-rules/3260` | 7 Sep 2026 | **HTTP 403, 3,383 B.** Blocked under a browser UA after the earlier 429. Host left to Track 4.2 |
| 47 | EDGAR full-text search, `"NYSE Rule 408"` | `efts.sec.gov/LATEST/search-index?q=%22NYSE%20Rule%20408%22` | 7 Sep 2026 | HTTP 200 — **4 hits**, all corporate exhibits, none reproducing the rule text. EDGAR FTS covers filings only, not SRO rulebooks |
| 48 | EDGAR full-text search, `"discretionary power in customers' accounts"` | `efts.sec.gov/LATEST/search-index?q=…` | 7 Sep 2026 | HTTP 200 — **0 hits.** NYSE Rule 408 text **not retrieved; marked UNVERIFIED** (see ◇3) |
| 49 | Federal Register API, `FINRA Rule 3260 Discretionary Accounts` | `federalregister.gov/api/v1/documents.json?conditions[term]=…` | 7 Sep 2026 | HTTP 200 — count **25**, all Rule 17d-2 allocation plans and unrelated SRO filings. The 3260 adopting filing was not surfaced this way |
| 50 | Federal Register API, `Safeguarding Advisory Client Assets` (SEC) | same | 7 Sep 2026 | HTTP 200 — count **287**; surfaced the proposal (2023-03-09), its comment reopening (2023-08-30), and a **2025-06-17 "Withdrawal of Proposed Regulatory Actions"** |
| 54 | SEC Trading & Markets no-action index | `sec.gov/divisions/marketreg/mr-noaction.shtml` (with `-L`) | 7 Sep 2026 | HTTP 200, 138,058 B — **746 unique href/text entries; `CommandTRADE` appears in exactly 1.** Index demonstrably carries withdrawal entries (*OnTrade/NexTrade*). See NF-8 |
| 59 | Same index, filtered for DRIP/AIP/systematic/DSPP terms | same | 7 Sep 2026 | **4 matches, none on point** (OnTrade withdrawal; Serono tender offer; "Dividend Capital" as an entity name; CBOE trade-through). See NF-9 |
| 60 | SEC Investment Management no-action index | `sec.gov/divisions/investment/im-noaction.shtml` | 7 Sep 2026 | HTTP 200, 220,858 B — **1,442 unique entries.** IAA appears 4× (2005, 2007, 2016, **2017 SLOA**); **2017 is the latest.** No DRIP/AIP standing-instruction letter. See NF-4, NF-9 |
| 122–140 | 4.2 researcher: FINRA Rules 3260, 4512; NASD Rule 2510 (retired, `nasdr-rules` path — the `nasd-rules` path 404s); NTM 04-71, 91-39, 91-80, 92-25, 93-1; RN 09-63, 11-19, 15-22, 19-13, 26-15; SR-FINRA-2019-009 filing page + NOF PDF | finra.org | 7 Sep 2026 | All HTTP 200 after backoff. **NTM 75-33 and 76-30 → HTTP 404** (NF-18). Rule 3260 page: 4 content tabs all "No Results Found" |
| 141–150 | 4.2 researcher: SEC Rels. 34-49883, 34-50477, 34-54722 (*Sathianathan*), 34-69923 (*Murphy*), 34-74903 (*Pino*), 34-51047 (*Guang Lu*), **34-105568 (*DiPaola*, 28 May 2026)** | sec.gov/files/litigation/opinions/ and /rules/sro/nasd/ | 7 Sep 2026 | All HTTP 200 (one 429 retried). See RE-4.2-03, RE-4.2-05, RE-4.2-06 |
| 151–153 | 4.2 researcher: NAC *Murphy/Birkelbach* decision + 5 further candidate NAC decisions | finra.org/sites/default/files/NACDecision/ | 7 Sep 2026 | HTTP 200 ×6 — **only p124827 mentions time-and-price; the other five do not** |
| 154–156 | 4.2 researcher: *Pinchas* 34-41816, *Siegel* 34-58737, *Faber* 34-49216 | sec.gov | 7 Sep 2026 | HTTP 200 ×3 — **all off point**, `2510`/`time and price`/`definite amount` → 0 each (NF-19) |
| 157 | 4.2 researcher: CommandTRADE staff letter + incoming request | sec.gov/divisions/marketreg/mr-noaction/commandtrade122805.htm and …122305-incoming.pdf | 7 Sep 2026 | HTTP 200 ×2 — **`2510` → 0 and `discretion` → 0 in both** |
| 158 | 4.2 researcher: 17 C.F.R. §240.15c1-7 | ecfr.gov renderer API | 7 Sep 2026 | HTTP 200 — addressed only to brokers/dealers; **no time-and-price exception at all** |
| 159 | 4.2 researcher: FINRA interpretive-letters index | finra.org/rules-guidance/guidance/interpretive-letters | 7 Sep 2026 | HTTP 200, 114,234 B but **client-rendered**; `2510`/`3260` → 0. Rule-letter URL → **404** (curl ×3 UAs, WebFetch). **UNVERIFIED** (NF-18) |
| 160–163 | 4.2 researcher: FINRA Disciplinary Actions Online + 3 API endpoint guesses | finra.org; api.finra.org; services.finra.org | 7 Sep 2026 | 200 client-rendered, then **404, 404, 000** — no machine route (NF-18) |
| 164 | 4.2 researcher: sec.gov search endpoint | `secsearch.sec.gov/search?affiliate=secsearch&query=…` | 7 Sep 2026 | **HTTP 202, 0 bytes — unusable** |
| 165–181 | 4.2 researcher: Federal Register API, 17 term queries | federalregister.gov/api/v1/documents.json | 7 Sep 2026 | Counts at DA-4.2(c) / NF-15; **`"3260(d)(1)"` → 0** |
| 182–203 | 4.2 researcher: CourtListener v4, 22 queries | courtlistener.com/api/rest/v4/search/?type=o | 7 Sep 2026 | Counts at NF-15/NF-17; **3 queries unrun** on the 50/hour cap (◇11) |
| 204 | 4.2 researcher: *Galarneau* primary text, 4 endpoints | Justia ×2, media.ca1.uscourts.gov, govinfo | 7 Sep 2026 | **403, 403, 404, HTML shell — not obtained.** Quote rests on FindLaw only (◇12) |
| 64 | SEC opinion Rel. 34-74903 (*Pino*), direct | `sec.gov/files/litigation/opinions/2015/34-74903.pdf` | 7 Sep 2026 | **HTTP 429** (×6 across two runs incl. a 5-attempt backoff loop) — sec.gov rate-limited under concurrent track load |
| 65 | Same opinion via Wayback | `web.archive.org/web/20220716171013/https://www.sec.gov/litigation/opinions/2015/34-74903.pdf` | 7 Sep 2026 | **HTTP 200, 159,699 B, 10 pp., 53,813 chars — full opinion recovered.** See RE-4.2-02 |
| 66 | Web search (locator only), SEC opinions on 2510 time-and-price | web search, `allowed_domains=sec.gov` | 7 Sep 2026 | Located Rel. 34-74903 and 34-69923; citation rests on the primary PDF actually retrieved at row 65 |
| 67–79 | 4.1 researcher: eCFR §§240.17a-3, 242.600, 240.15c3-5, 240.3b-16; FINRA Rules 5310/4512/3260/2360/3110; RN 15-09/15-46/16-21; NASD NTM 98-66 | ecfr.gov API (`--compressed`), finra.org (backoff loop) | 7 Sep 2026 | All HTTP 200. finra.org required a retry loop; browser UA returned **HTTP 403**, custom UA with backoff succeeded |
| 80–92 | 4.1 researcher: Rel. 34-72065, 34-74032, 34-61358, 34-63241, 34-73652, 34-84528; Rule 606 and 15c3-5 staff FAQs; auto-trading alert; TM no-action index | sec.gov | 7 Sep 2026 | All HTTP 200. See RE-4.1-04 to RE-4.1-08, NF-11 |
| 93–99 | 4.1 researcher: Federal Register full-text for SR-NASDAQ-2015-024, SR-NASD-2003-165, SR-NYSE-2015-60, SR-CBOE-2004-35, SR-CBOE-2019-017, SR-CBOE-2019-027, SR-NYSE-2013-71 | federalregister.gov/documents/full_text/text/… | 7 Sep 2026 | All HTTP 200. See RE-4.1-01 to RE-4.1-03 |
| 100 | Cboe BZX equities rulebook PDF | `cdn.cboe.com/resources/regulation/rule_book/BZX_Equities_Rule_Book.pdf` | 7 Sep 2026 | **HTTP 403, 263 B** even with a browser UA — BZX Rule 11.9 "Discretionary Order" **UNVERIFIED** (◇6) |
| 101 | Rel. 34-78102 | `sec.gov/rules/final/2016/34-78102.pdf` | 7 Sep 2026 | HTTP 301 → **HTTP 404, 53,435 B.** FR API shows its 10 citing documents are all pre-trade-risk-control filings, **not** order types — the brief's "(Regulation SCI/order types?)" is **not confirmed** (◇7) |
| 102–108 | 4.1 researcher: FR API zero-count probes (see NF-10) | federalregister.gov/api/v1/documents.json | 7 Sep 2026 | counts 0, 0, 0, 0, 0, 0, 1 |
| 109–121 | 4.1 researcher: CourtListener, 13 queries over 4 runs | courtlistener.com/api/rest/v4/search/ | 7 Sep 2026 | 8 returned counts (NF-14); **5 blocked HTTP 429 on every attempt — UNRUN** (◇8) |
| 62 | SEC custody-rule FAQ | `sec.gov/divisions/investment/custody_faq_030510.htm` | 7 Sep 2026 | HTTP 200, 87,315 chars — **0 hits for "standing letter", "SLOA", "letter of instruction"**; both "standing" matches are "outstanding". Footer: "**Last Reviewed or Updated: Feb. 21, 2017**". Closes ◇2 |
| 63 | Custody FAQ, modern path | `sec.gov/rules-regulations/staff-guidance/…/staff-responses-questions-about-custody-rule` | 7 Sep 2026 | HTTP 200 — serves the identical document |
| 61 | IM no-action index, alternate paths | `sec.gov/investment/investment-company-no-action-letters` ; `sec.gov/divisions/investment/noaction.htm` | 7 Sep 2026 | HTTP 404 (53,435 B) and HTTP 200 (1,342 B stub) respectively — **neither usable.** Note: the 404 page is 53,435 B, large enough to pass a naive size check; this is exactly the trap the shared context warns about |
| 55 | CommandTRADE letter | `sec.gov/divisions/marketreg/mr-noaction/commandtrade122805.htm` | 7 Sep 2026 | HTTP 200 — letter text; footer "Modified: 01/06/2006"; **no withdrawal/supersession note** |
| 56 | CommandTRADE letter, `/files/` variant | `sec.gov/files/divisions/marketreg/mr-noaction/commandtrade122805.htm` | 7 Sep 2026 | HTTP 404, 53,435 B — the `/files/` trick does **not** apply to no-action letters, only to rule releases |
| 57 | EDGAR FTS `"CommandTRADE"` | `efts.sec.gov/LATEST/search-index?q=%22CommandTRADE%22` | 7 Sep 2026 | **HTTP 500 server error** — failed endpoint, recorded as such, not as a zero result |
| 58 | EDGAR FTS `"GlobalTec"` | same pattern | 7 Sep 2026 | HTTP 200 — **115 hits**, all 2002–2005 corporate filings, none the letter. EDGAR FTS does not index staff letters |
| 52 | Wayback availability probe for FINRA Rule 3260 | `archive.org/wayback/available?url=finra.org/rules-guidance/rulebooks/finra-rules/3260` | 7 Sep 2026 | HTTP 200 — closest snapshot **20260331204822**, status 200 |
| 53 | Wayback snapshot of FINRA Rule 3260 | `web.archive.org/web/20260331204822/https://www.finra.org/rules-guidance/rulebooks/finra-rules/3260` | 7 Sep 2026 | **HTTP 200, 24,632 B — full rule text (a)–(d)(2) recovered**, incl. amendment history. See RE-4.2-01. Snapshot dated 31 Mar 2026, not a live read |
| 51 | FR raw text of the withdrawal notice | `federalregister.gov/documents/full_text/text/2025/06/17/2025-11110.txt` | 7 Sep 2026 | HTTP 200, 5,129 B — **confirms 88 FR 14672 withdrawn as of 17 Jun 2025.** See RE-4.3-05a |

---

## ◇ list — resting on secondary confirmation only, flagged for primary verification

| ◇ | Proposition | Why flagged | What would close it |
|---|---|---|---|
| ◇1 | That WAC 460-20C-210(6)'s "solely to the time and/or price for the execution of orders" is the **NASAA model rule** formulation | The Washington primary text was retrieved and is quoted; the attribution of that wording to the NASAA model rests on the formulation recited in the P8 brief, not on NASAA's own publication | Retrieve the current NASAA model rule on Dishonest or Unethical Business Practices of Broker-Dealers and Agents from nasaa.org and quote its discretionary-authority paragraph verbatim with its subsection letter |
| ~~◇2~~ | ~~That no later staff letter, FAQ or IM Guidance Update modifies the IAA SLOA letter~~ | **CLOSED 7 Sep 2026.** Verified against three primary endpoints: the IM no-action index (1,442 entries — 2017 is the latest IAA letter), the letter's own page (no supersession note), and the custody-rule FAQ (**0** occurrences of "standing letter", "SLOA" or "letter of instruction"; last reviewed **21 Feb 2017**, the letter's own date). See NF-4 | Residual aperture only: the IM Guidance Update series was not enumerated item-by-item |
| ~~◇4~~ | ~~FINRA Rule 3260 text read from a 31 March 2026 Wayback snapshot, not a live page~~ | **CLOSED 7 Sep 2026 by independent retrieval.** The 4.1 researcher reached `finra.org/rules-guidance/rulebooks/finra-rules/3260` **live** (HTTP 200, 93,584 bytes) using a backoff loop, and the (b) and (d)(1) text returned is **verbatim identical** to the Wayback text at RE-4.2-01. Two independent retrievals by different routes agree word for word | — |
| ~~◇5~~ | ~~*Murphy* (34-69923) and *Sathianathan* (34-54722) quoted only via *Pino*'s footnotes~~ | **CLOSED 7 Sep 2026.** Both opinions retrieved in full from `sec.gov/files/litigation/opinions/`, together with the underlying **FINRA NAC decision in *Murphy*** (Complaint No. 2005003610701, `finra.org/sites/default/files/NACDecision/p124827.pdf`). Direct quotations now appear at RE-4.2-06 | — |
| ◇11 | **Three CourtListener queries never executed** — `"time or price discretion" broker`; `"Rule 3260" FINRA discretionary account`; `"time and price discretion" "not held"` | CourtListener enforces 5 requests/minute and 50/hour; the cap was hit on three attempts including a 25-minute backoff | Re-run with an API token. **Mitigating: `"time and price discretion"` alone returns only 2 opinions in the entire corpus, so these narrower queries cannot exceed those 2** |
| ◇12 | ***Galarneau v. Merrill Lynch***, 504 F.3d 189 (1st Cir. 2007), n.3 — distinguishing illegal "pure discretion" (no prior approval) from "time and price discretion" (exact time/price, *with* prior approval), which "**is not illegal**" | Four primary endpoints failed: Justia ×2 → **403**; media.ca1.uscourts.gov → **404**; govinfo → HTML shell (the case is not in the USCOURTS collection). CourtListener's Opinions API requires a token (**401**); its HTML page returned **202, 0 bytes**. **The quote rests on FindLaw only** | Westlaw/Lexis, a CourtListener token, or a 1st Cir. clerk copy of No. 06-2455. **Would be weak SUPPORT if verified** — the only Article III gloss locating the line at *prior approval*, which is where per-order V1 sits |
| ◇13 | **NASD NTM 75-33 and 76-30** — the two oldest notices FINRA itself lists against Rule 3260 | Both return **HTTP 404** on finra.org | NASD Manual archive or a library holding. **Mitigating: NTM 91-39, 91-80, 92-25 and 93-1 all concern negative-response letters and money-market bulk exchanges — paragraph (d)(2) material — and none mentions time-and-price** |
| ◇14 | **A systematic FINRA AWC sweep for 3260(d)(1) charges** | FINRA Disciplinary Actions Online is client-rendered with no exposed API; three endpoint guesses returned 404/404/000 (NF-18). Worked around via FINRA's server-served monthly disciplinary PDFs, which surfaced two settled matters (*Mancusi* 2015048159201; *Stopkey* 2018059872901) — **but that is not a systematic sweep** | Browser route to FINRA DAO |
| ◇15 | **FINRA OGC interpretive letter of 15 May 2008**, surfaced by search as attached to Rule 2510 | URL returns **404** via curl (3 UAs) and WebFetch; the interpretive-letters index is client-rendered (NF-18) | Browser route, or the subscription FINRA Manual |
| ◇6 | **Cboe BZX Rule 11.9 "Discretionary Order," and Cboe BZX 21.1(d)(11)/(12), C2 6.10(c), Cboe EDGX 21.1(d)(11)/(12)** | The BZX rulebook PDF returned **HTTP 403** even with a browser UA (search log 100). The options stop/stop-limit definitions are confirmed only by cross-reference in the Cboe Rule 5.6(c) mapping table at RE-4.1-01/A-15, not from the rulebooks themselves | Retrieve via a browser route, or via Federal Register filings that reproduce the rule text. **The point is already carried by Nasdaq Rule 4703(g)**, so this is corroboration, not load-bearing |
| ◇7 | **Rel. 34-78102 identity** | `sec.gov/rules/final/2016/34-78102.pdf` returned HTTP 404. All 10 Federal Register documents citing it do so in the context of exchange pre-trade risk controls, not order types. **The brief's parenthetical "(Regulation SCI/order types?)" is not confirmed** | Locate the release by number in the Federal Register and confirm its subject |
| ◇8 | **Five CourtListener queries never executed** — `"trading software" AND "discretionary authority"`; `"order management system" AND "discretionary authority"`; `"third-party trading platform"`; `"auto-trading" AND newsletter`; `"bracket order" AND securities` | HTTP 429 on every attempt across four runs with escalating delays (NF-14). **The court-decision coverage on third-party trading software is therefore incomplete, and NF-14's zero counts must not be read as covering these terms** | Re-run with a CourtListener API token or after the other tracks release the host |
| ◇9 | **Nasdaq Rule 4703(g) current wording** | RE-4.1-02 quotes the **2015** text from SR-NASDAQ-2015-024. The Discretion attribute was amended by **SR-NASDAQ-2021-072**, FR Doc. 2021-21987 (8 Oct 2021), which was located but not retrieved | Pull FR Doc. 2021-21987 and confirm the operative wording of the Discretion attribute as amended |
| ◇10 | **NYSE Rule 13 and NYSE Arca Rule 7.31 current text** | RE-4.1-01's NYSE stop-order definition comes from SR-NYSE-2015-60, **the filing that deleted Stop Orders from Rule 13** effective 2016. The currently operative text was not retrieved | Retrieve from the NYSE rulebook. Note the definition is quoted as recited history, and is flagged as such in the register entry |
| ◇3 | **NYSE Rule 408 — text not retrieved.** Rel. 34-44992 n.21 cites "NYSE Rule 408 and NASD Rule 2510(b)" as the source of the "natural person" grantee formulation. The *citation* is verbatim and verified (RE-4.3-02); the *rule text* of NYSE Rule 408 is not | EDGAR full-text search returned 4 hits for `"NYSE Rule 408"` (none reproducing the rule) and 0 for `"discretionary power in customers' accounts"` (search log 47–48). EDGAR FTS indexes filings, not SRO rulebooks. NYSE member-conduct rules were substantially transferred to FINRA in 2007–08 and Rule 408 may no longer be current | Retrieve NYSE Rule 408 as it stood in 2001 from the NYSE rulebook archive or from an SEC release reproducing it, and confirm whether it is still in force. **Marked UNVERIFIED.** The drafting-chain finding at DA-4.3(f) does not depend on it — NASD Rule 2510(b)'s "stated individual or individuals" carries that point on its own — but half of the Commission's cited basis is currently unread |

---

## Not covered — carried forward as open items

Stated explicitly so the coordinator does not mistake absence of coverage for absence of authority. **Four of the six researchers commissioned for this track could not be launched: the harness's concurrent-subagent cap (20) was saturated by other P8 tracks throughout this track's execution.** The 4.1 researcher completed and its return is fully integrated (RE-4.1-01 to RE-4.1-11, NF-10 to NF-14, ◇5–◇10).

**The 4.2 researcher also completed, and its return is fully integrated** (RE-4.2-03 to RE-4.2-06, NF-15 to NF-19, ◇11–◇15, and the corrections at DA-4.2(d) and (f)). Its findings **corrected three of the brief's premises and one of the lead analyst's own formulations**: the phrase "a member or a person associated with a member" appears nowhere in Rule 3260 (`associated` → 0 occurrences); there is **no SEC approval order** for the rule; and six of the seven respondent names the brief supplied are off point. It also supplied the single most on-point adverse authority for the standing track, Rel. 34-49883 at 7 (RE-4.2-03), which the lead analyst did not have.

**Both commissioned researchers therefore completed. Four were never launched.** The following were assigned to those four and were only partially covered by direct work:

1. **The multi-state survey** (NY, CA, TX, FL, IL, MA, DE) and the **NASAA model rules** in their own publication. Washington is complete; no other state was sampled. **No sampling method can be claimed for a survey that was not performed.**
2. **The RCW 1.80 (Washington UETA) extension** — whether "law" in RCW 1.80.060(3) reaches Washington administrative rules, and the RCW 1.80.010 definitions. P7's chain is neither extended nor confirmed here.
3. **Washington DFI Securities Division** interpretive statements, policy statements and orders on the form of a third-party trading authorization. NF-5's Washington half is therefore *not yet searched*, not an established absence.
4. **The federal grantee sweep** via SEC full-text search (efts.sec.gov) for any release or letter addressing whether a grantee may be a non-person. DA-4.3(f) rests on the instruments retrieved here plus the CourtListener counts at NF-1; it is not backed by an EDGAR full-text sweep.
5. **AIPs, systematic withdrawal plans, DSPPs, and prime-brokerage standing instructions** (question 4.4's candidate list items 1, 2 and 7). Only the Regulation M / DRIP branch was worked directly. The Trading and Markets no-action index was searched and returned nothing on point (NF-9), **but the Corporation Finance and Investment Management no-action indexes were not searched** — that is where a DRIP or plan-administrator letter would most likely sit. *(Item 3, the CommandTRADE/GlobalTec later chain, was closed directly — see NF-8: nothing extends, narrows or withdraws it.)*
6. **Advisers Act Rel. IA-2968** (the 2009 custody-rule adopting release) on what constitutes authority over client assets. *(The companion question — the status of the 2023 Safeguarding proposal, IA-6240 — was closed directly: it was formally withdrawn on 17 June 2025. See RE-4.3-05a.)*

Items 1–4 bear on DA-4.3; items 5–6 bear on DA-4.4. **None of them can strengthen the adverse findings at A1–A3, which rest on primary text already retrieved and quoted in full.**


---

# S5 · TRACK 5 — Ranking as recommendation: what is "more"?

**Commission P8. Bears on Q1 (adviser characterization); secondarily Q3.**
All retrievals 7 September 2026 unless stated. Every quote below was taken from the primary text at the URL given, not from a summary.

**The question.** NASD NTM 01-23 permits a search tool to rank securities by criteria the customer selected, and permits a customer-requested price-point alert, in each case "without more." This track establishes what "more" is: which specific presentation features have been held to tip a screener, ranking, list, alert or watchlist into a recommendation, and which have been held not to.

**Headline finding.** The discriminator in the located authority is **not** prominence. It is a two-axis test: **(1) does the output key to this individual customer's own attributes, and (2) does it resolve to specific securities rather than to classes?** Highlighting, colour, evaluative superlatives, firm-chosen subject matter and even active transmission have all been tolerated on the permitted side of the line; personalization plus specificity has been held to cross it standing alone, with no emphasis of any kind. Every feature list a regulator has published about visual emphasis, colour, confetti, badges, leaderboards and default-on notifications — the SEC's 2021 DEP release — asks questions and answers none of them, and the one rulemaking that would have reached those features was **withdrawn (issued 12 June 2025, published 17 June 2025, 90 FR 25531)** with the statement that the Commission "does not intend to issue final rules."

**Second headline finding — three regulators tried to move the line by rulemaking, and all three stopped.** (i) The **SEC** proposed the predictive-data-analytics rule in 2023 precisely because, on its own economic analysis, DEP-style practices "**might not constitute recommendations**" — and **withdrew it** in June 2025 stating it "does not intend to issue final rules." (ii) **NASAA** drafted model-rule text deeming any "means, method or mechanism to **feature or promote**" a specific security a recommendation, carried it through a September 2023 proposal and a November 2024 re-proposal, and **did not adopt it** in the April 2025 rule. (iii) **New Jersey** let its fiduciary-rule proposal expire on 1 January 2022, naming gamification as a reason the question was unsettled, and fell back on "existing regulations and enforcement authority." The line is where it was because every attempt to move it was abandoned — not because anyone decided it was correctly placed.

**Third headline finding — the framework has now been applied to a document, once.** For twenty-five years both poles of the answer rested on the worked hypotheticals of a single 2001 SRO policy statement, and this register was drafted on that footing. That changed on **27 May 2026**. In ***In re David Lerner Associates, Inc.***, Exchange Act Rel. No. 105556, the Commission found that a **firm-designed three-page template listing three to five specific securities**, pre-populated for a named customer, **was a recommendation** — on the two factors this track identifies, individual tailoring and influence to trade particular securities — over the firm's express and maintained position that it was not, and held that **five separate disclaimers did not change the answer**, including a rewrite from "suggested investments" to "examples of potential investments." It is a settled order, not a litigated holding, and by its own terms binds nobody else. But it is the first time any US regulator has applied the 01-23 framework to a **document rather than a conversation**, and it **confirms the two-axis test rather than displacing it.** Beyond it, the record remains thin: *Siegel* (SEC 2008, aff'd 592 F.3d 147 (D.C. Cir. 2010)) is the only post-2000 federal appellate application of the factors and its facts are a live oral pitch; every other Reg BI action rests on human recommendations with the element assumed; and **CourtListener returns 0 opinions for "stock screener" recommendation, "focus list" recommendation broker, "investment analysis tool", gamification securities, and "digital engagement practices"** (counts and caveats at S5-37 and N21). The one attempt to litigate curated lists and push notifications as recommendations — Massachusetts against Robinhood — was expressly reserved by the Supreme Judicial Court as "a dispute of material fact" (492 Mass. 696, 5 n.7 (2023)) and settled away with the fiduciary count dropped. **On screeners, rankings, watchlists and gamification specifically, the line is still drawn only in guidance and has never been tested.**

---

## Register entries

### S5-01 · NASD Notice to Members 01-23, "Online Suitability — Suitability Rule and Online Communications" (18 Mar 2001) · https://www.finra.org/rules-guidance/notices/01-23 · retrieved 7 Sep 2026
- **Type:** SRO policy statement (filed with SEC 19 Mar 2001; immediately effective on filing under Exchange Act §19(b)(3)(A) and SEC Rule 19b-4(f)(1))
- **Date / status:** In force. Expressly preserved as still-applicable guidance by FINRA RN 12-25 A2 (S5-07). Adopted by citation in the Reg BI adopting release, 84 FR 33335 n.161 (S5-12).
- **Level 1** — the single most directly on-point authority located in either direction; a published, still-current SRO policy statement whose worked examples are the only place any US regulator has drawn the line between a permitted screener and a prohibited one.

This is the governing text for the whole track and P7 captured only its headline. The operative content is its **eight worked examples** — four outside the definition, four within — and its five guidelines. All are reproduced verbatim below because the boundary lives in the differences between them, not in the abstract test.

**The test (¶ "Scope of the Term 'Recommendation'"):**
> "As illustrated by the examples provided below, the 'facts and circumstances' determination of whether a communication is a 'recommendation' requires an analysis of the content, context, and presentation of the particular communication or set of communications. The determination of whether a 'recommendation' has been made, moreover, is an objective rather than a subjective inquiry. An important factor in this regard is whether—given its content, context, and manner of presentation— a particular communication from a broker/dealer to a customer reasonably would be viewed as a 'call to action,' or suggestion that the customer engage in a securities transaction."

> "Another principle that members should keep in mind is that, in general, the more individually tailored the communication to a specific customer or a targeted group of customers about a security or group of securities, the greater likelihood that the communication may be viewed as a 'recommendation.'" (n.11)

> "[T]his current Policy Statement does not (1) alter member obligations under the suitability rule or (2) establish a 'bright line' test for determining whether a communication does or does not constitute a 'recommendation' for purposes of the suitability rule. No single factor discussed below, standing alone, necessarily dictates the outcome of the analysis." (Executive Summary)

#### OUTSIDE the definition — the four permitted configurations, verbatim

**(1) Research library.**
> "A member creates a Web Site that is available to customers or groups of customers. The Web Site has research pages or 'electronic libraries' that contain research reports (which may include buy/sell recommendations from the author of the report), news, quotes, and charts that customers can obtain or request."

*Note: third-party buy/sell ratings may be carried without the carrier making a recommendation, where the customer obtains or requests them.*

**(2) The ranking search engine — the source of the "criteria the customer selected" language.**
> "A member has a search engine on its Web Site that enables customers to sort through the data available about the performance of a broad range of stocks and mutual funds, company fundamentals, and industry sectors. The data is not limited, for instance, to, and does not favor, securities in which the member makes a market or has made a 'buy' recommendation. Customers use and direct this tool on their own. Search results from this tool may rank securities using any criteria selected by the customer, and may display current news, quotes, and links to related sites." (n.13)

*Four conditions are embedded in this example: (a) broad universe; (b) no favouring of the member's own book or ratings; (c) "customers use and direct this tool on their own"; (d) ranking criteria **selected by the customer**.*

**(3) The screener — the vendor-chosen-criteria axis, stated as its converse.**
> "A member provides research tools on its Web Site that allow customers to screen through a wide universe of securities (e.g., all exchange-listed and Nasdaq securities) or an externally recognized group of securities (e.g., certain indexes) and to request lists of securities that meet broad, objective criteria (e.g., all companies in a certain sector with 25 percent annual earnings growth). The member does not impose limits on the manner in which the research tool searches through a wide universe of securities, nor does it control the generation of the list in order to favor certain securities. For instance, the member does not limit the universe of securities to those in which it makes a market or for which it has made a 'buy' recommendation. Similarly, **the algorithms for these tools are not programmed to produce lists of securities based on subjective factors that the member has created or developed**, nor do the algorithms, for example, produce lists that favor those securities in which the member makes a market or for which the member has made a 'buy' recommendation." (emphasis added)

*This is the most important single sentence located in the entire track. The safe harbour is conditioned on the algorithm **not** being programmed on subjective factors **the member created or developed**. It is the vendor-chosen-criteria axis, expressed as a negative condition. Note also that the criteria are described as "broad, objective criteria" and the universe as "wide" or "externally recognized."*

**(4) Subscribed watchlist alerts — push converted to pull.**
> "A member allows customers to subscribe to e-mails or other electronic communications that alert customers to news affecting the securities in the customer's portfolio or on the customer's 'watch list.' Such news might include price changes, notice of pre-scheduled events (such as an imminent bond maturation), or generalized information. **The customer selects the scope of the information that the firm will send to him or her.**" (emphasis added)

*This is the located authority that a customer's standing request converts a push into a pull. The operative fact is that the customer, not the firm, sets the scope of what is sent.*

#### WITHIN the definition — the four prohibited configurations, verbatim

**(1) Targeted encouragement.**
> "A member sends a customer specific electronic communication (e.g., an e-mail or pop-up screen) to a targeted customer or targeted group of customers encouraging the particular customer(s) to purchase a security." (n.14)

**(2) Sector call plus a "buy"-rated list.**
> "A member sends its customers an e-mail stating that customers should be invested in stocks from a particular sector (such as technology) and urges customers to purchase one or more stocks from a list with 'buy' recommendations."

**(3) Personalized inputs producing a specific-securities list — THE LEAST AGGRESSIVE CROSSING.**
> "A member provides a portfolio analysis tool that allows a customer to indicate an investment goal and input personalized information such as age, financial condition, and risk tolerance. The member in this instance then sends (or displays to) the customer a list of specific securities the customer could buy or sell to meet the investment goal the customer has indicated." (n.15)

*There is no urging, no evaluative label, no highlighting, no superlative, no colour, no badge, and no unsolicited push in this example — the customer operated the tool. It crosses on two facts alone: **personalized inputs in, specific securities out**. Note the parenthetical "(or displays to)": a passive on-screen display is treated identically to an active send.*

**(4) Data-mining then pushing suggestions.**
> "A member uses data-mining technology (the electronic collection of information on Web Site users) to analyze a customer's financial or online activity—whether or not known by the customer—and then, based on those observations, sends (or 'pushes') specific investment suggestions that the customer purchase or sell a security."

#### The five guidelines, verbatim

> "A member cannot avoid or discharge its suitability obligation through a disclaimer where the particular communication reasonably would be viewed as a 'recommendation' given its content, context, and presentation. NASD Regulation, however, encourages members to include on their Web Sites (and in other means of communication with their customers) clear explanations of the use and limitations of tools offered on those sites." (n.16)

> "Members should analyze any communication about a security that reasonably could be viewed as a 'call to action' and that they direct, or appear to direct, to a particular individual or targeted group of individuals—as opposed to statements that are generally made available to all customers or the public at large—to determine whether a 'recommendation' is being made." (n.17)

> "Members should scrutinize any communication to a customer that suggests the purchase, sale, or exchange of a security—as opposed to simply providing objective data about a security—to determine whether a 'recommendation' is being made." (n.18)

> "A member's transmission of unrequested information will not necessarily constitute a 'recommendation.' However, when a member decides to send a particular customer unrequested information about a security that is not of a generalized or administrative nature (e.g., notification of a stock split or a dividend), the member should carefully review the circumstances under which the information is being provided, the manner in which the information is delivered to the customer, the content of the communication, and the original source of the information. **The member should perform this review regardless of whether the decision to send the information is made by a representative employed by the member or by a computer software program used by the member.**" (emphasis added)

> "Members should be aware that the degree to which the communication reasonably would influence an investor to trade a particular security or group of securities—[e]ither through the context or manner of presentation or the language used in the communication—may be considered in determining whether a 'recommendation' is being made to the customer."

#### The footnotes that do the work

**n.13 (attached to the ranking search engine)** — does *not* qualify the ranking permission. It addresses hyperlinks only:
> "Note, however, that hyperlinks conceivably could create suitability obligations, depending, for example, on the information provided to and from the hyperlinked site, the extent to which a member endorses the content of the hyperlinked site, the nature of the firm's relationship to the hyperlinked site, and other attendant facts and circumstances."

**n.14 — THE MOST AGGRESSIVE PRESENTATION EXPRESSLY PERMITTED.**
> "Note that there are instances where sending a customer an electronic communication that **highlights a particular security (or securities)** will not be viewed as a 'recommendation.' For instance, while each case requires an analysis of the particular facts and circumstances, a member generally would not be viewed as making a 'recommendation' when, pursuant to a customer's request, it sends the customer (1) electronic 'alerts' (such as account activity alerts, market alerts, or price, volume, and earnings alerts) or (2) **research announcements (e.g., a firm's 'stock of the week')** that are not tailored to the individual customer, as long as neither—given their content, context, and manner of presentation—would lead a customer reasonably to believe that the firm is suggesting that the customer take action in response to the communication." (emphasis added)

*This single footnote permits: a list of **one**; **chosen by the firm** on the firm's own subjective criteria; carrying an **evaluative superlative label** ("stock of the week"); **actively transmitted** to the customer; and expressly **"highlight[ing] a particular security."* The three conditions are (i) pursuant to a customer's request, (ii) not tailored to the individual customer, and (iii) content/context/manner would not lead a customer reasonably to believe the firm is suggesting action.*

**n.15 — narrowing, and aggregation.**
> "Note, however, that a portfolio analysis tool that merely generates a suggested mix of general classes of financial assets (e.g., 60 percent equities, 20 percent bonds, and 20 percent cash equivalents), **without an accompanying list of securities that the customer could purchase to achieve that allocation**, would not trigger a suitability obligation. On the other hand, **a series of actions which may not constitute 'recommendations' when considered individually, may amount to a 'recommendation' when considered in the aggregate.** For example, a portfolio allocator's suggestion that a customer could alter his or her current mix of investments followed by provision of a list of securities that could be purchased or sold to accomplish the alteration could be a 'recommendation.'" (emphasis added)

**n.16 — what a disclaimer can and cannot do.**
> "Although, as noted previously, a broker/dealer cannot disclaim away its suitability obligation, informing customers that generalized information provided is not based on the customer's particular financial situation or needs may help clarify that the information provided is not meant to be a 'recommendation' to the customer. Whether the communication is in fact a 'recommendation' would still depend on the content, context, and presentation of the communication."

**n.17 — segmentation of the audience.**
> "We note that there are circumstances where the act of sending a communication to a specific group of customers will not necessarily implicate the suitability rule. For instance, a broker/dealer's business decision to provide only certain types of investment information (e.g., research reports) to a category of 'premium' customers would not, **without more**, trigger application of the suitability rule. Conversely, members may incur suitability obligations when they send a communication to a large group of customers urging those customers to invest in a security." (emphasis added)

**n.18 — the price-point alert.**
> "As with the other general guidelines discussed in this Policy Statement, the presence of this factor alone does not automatically mean that a 'recommendation' has been made. For example, where a customer affirmatively requests to be alerted (by e-mail or pop-up screen) when a security reaches a specific price-point, when a company issues an earnings release, or when an analyst changes his or her recommendation of a particular security, the broker/dealer's decision to send the customer the requested information, **without more**, would not necessarily trigger a suitability obligation." (emphasis added)

**n.10 — the accompanying message is the variable.**
> "For example, if a broker/dealer transmitted a research report to a customer at the customer's request, that communication may not be subject to the suitability rule; whereas, if the same broker/dealer transmitted the very same research report with an accompanying message, either oral or written, that the customer should act on the report, the suitability analysis would be different."

- **What it establishes:** Ranking, screening, listing, highlighting and alerting are all permitted presentations; what tips them over is (i) the member supplying the subjective selection criteria, (ii) the output being keyed to the individual customer's own attributes, (iii) narrowing to specific securities, (iv) an accompanying suggestion to act, or (v) the aggregate of steps that are individually innocuous.
- **Q1:** SUPPORT, with sharply defined limits.
- **Application note:** The configuration lands **between** two of 01-23's own examples, and the register should say so rather than claiming either. It matches the permitted **"outside" example (3)** on the axis that example makes decisive: every threshold, weight, score, inclusion rule, universe, side mapping and sort key traces to an explicit member setting, which is the express converse of the disqualifier ("algorithms … not programmed to produce lists of securities based on subjective factors that **the member has created or developed**"), and there is no favouring of any book or rating. Neutral sort labels and the absence of highlighting sit inside example (2) and well inside n.14. But it matches the prohibited **"within" example (3)** on the other axis: the output is keyed to one member's own parameters and resolves to a **specific instrument and side** — personalization-in, specificity-out — and "(or displays to)" forecloses any argument that passive display differs from sending. The distinguishing fact is **who authored the mapping**: in "within" example (3) the customer supplies raw personal facts and the *member's* tool decides what they imply, whereas here the member wrote the rule. **01-23 does not address that combination, and no located authority distinguishes a rule the user wrote from one adopted or supplied for him** — the same gap the shared context records at Q1. Treat this as the strongest available argument, not as a settled distinction.

---

### S5-02 · NASD Notice to Members 96-60, "Clarification of Members' Suitability Responsibilities Under NASD Rules with Special Emphasis on Member Activities in Speculative and Low-Priced Securities" (Sept 1996) · https://www.finra.org/rules-guidance/notices/96-60 · retrieved 7 Sep 2026
- **Type:** SRO notice to members
- **Date / status:** In force as guidance; expressly preserved by FINRA RN 12-25 A2 ("The prior guidance and interpretations generally remain applicable"); clarified on other grounds by *Clarification of NtM 96-60* (Mar 1997), cited at 01-23 n.9.
- **Level 2** — the broadest adverse formulation of "recommendation" located anywhere, and it is still live.
- **Verbatim quote, pin-cited:**
> "A member's suitability obligation under Rule 2310 applies only to securities that have been recommended by the member. It would not apply, therefore, to situations in which a member acts solely as an order-taker for persons who, on their own initiative, effect transactions without a recommendation from the member (See SEC Release No. 34-27160, August 22, 1989). However, a broad range of circumstances may cause a transaction to be considered recommended, and **this determination does not depend on the classification of the transaction by a particular member as 'solicited' or 'unsolicited.'** In particular, **a transaction will be considered to be recommended when the member or its associated person brings a specific security to the attention of the customer through any means, including, but not limited to, direct telephone communication, the delivery of promotional material through the mail, or the transmission of electronic messages.**" (emphasis added)

- **What it establishes:** On its face, *any* means by which a member brings a *specific security* to a customer's attention is a recommendation, and the firm's own "unsolicited" labelling is irrelevant.
- **Q1:** ADVERSE — and materially so. A screener that surfaces a specific security literally "brings a specific security to the attention of the customer through [a] means."
- **Application note:** This is the strongest adverse text in the track and it is **not** distinguished by the configuration's neutral labels, absence of highlighting or member-authored parameters — none of which 96-60 makes relevant. The only reconciliation available is chronological and specific-over-general: 01-23 (2001) is later, is directed specifically at online tools, and expressly places screeners, ranking search engines and firm-selected "stock of the week" announcements **outside** the definition. If 96-60 were read literally, 01-23's four "outside" examples could not stand. **No located authority performs that reconciliation expressly.** Flag as an unresolved tension, not as a resolved one.

---

### S5-03 · FINRA Rule 2111 (Suitability), incl. Supplementary Material .02, .03 and .08 · https://www.finra.org/rules-guidance/rulebooks/finra-rules/2111 · retrieved 7 Sep 2026
- **Type:** SRO rule
- **Date / status:** In force; amended by SR-FINRA-2020-007 eff. 30 Jun 2020 (adding .08).
- **Level 2**
- **The rule does NOT define "recommendation."** Confirmed by reading the full rule text: paragraph (a) uses "a recommended transaction or investment strategy" without defining the term, and no Supplementary Material defines it. FINRA states this expressly in RN 12-25 A2 (S5-07) and again to the Commission: *"defining the term 'recommendation' is unnecessary and would raise many complex issues in the absence of specific facts of a particular case."* (quoted in Reg BI adopting release, 84 FR 33335 n.165, citing Exchange Act Release No. 37588, 61 FR 44100, 44107 (Aug. 27, 1996)).
- **Supp. Mat. .02 (Disclaimers), in full:**
> ".02 Disclaimers. A member or associated person cannot disclaim any responsibilities under the suitability rule."
- **Supp. Mat. .03 (Recommended Strategies), operative chapeau and (c)–(d):**
> "However, the following communications are excluded from the coverage of Rule 2111 **as long as they do not include (standing alone or in combination with other communications) a recommendation of a particular security or securities**: (a) General financial and investment information, including (i) basic investment concepts, such as risk and return, diversification, dollar cost averaging, compounded return, and tax deferred investment, (ii) historic differences in the return of asset classes (e.g., equities, bonds, or cash) based on standard market indices, (iii) effects of inflation, (iv) estimates of future retirement income needs, and (v) assessment of a customer's investment profile; … (c) Asset allocation models that are (i) based on generally accepted investment theory, (ii) accompanied by disclosures of all material facts and assumptions that may affect a reasonable investor's assessment of the asset allocation model or any report generated by such model, and (iii) in compliance with Rule 2214 (Requirements for the Use of Investment Analysis Tools) if the asset allocation model is an 'investment analysis tool' covered by Rule 2214; and (d) Interactive investment materials that incorporate the above." (emphasis added)
- **Supp. Mat. .08:** > ".08 Regulation Best Interest. This Rule shall not apply to recommendations subject to SEA Rule 15l-1 ('Regulation Best Interest')."
- **What it establishes:** A second, rule-level source (beyond 01-23) that a disclaimer cannot discharge the obligation; and an express safe harbour for interactive materials and asset allocation models that is forfeited the moment the output includes "a recommendation of a particular security or securities," **including in combination with other communications**.
- **Q1:** MIXED — .03 is SUPPORT for class-level output; the chapeau's "standing alone or in combination" is ADVERSE for anything resolving to named instruments.
- **Application note:** The configuration's output is an instrument and a side. That is "a particular security," so the .03 safe harbour is unavailable on its face. The "in combination with other communications" clause is the rule-level analogue of 01-23 n.15's aggregation principle and reaches a sequence of individually neutral surfaces.

---

### S5-04 · FINRA Rule 2214 (Requirements for the Use of Investment Analysis Tools) · https://www.finra.org/rules-guidance/rulebooks/finra-rules/2214 · retrieved 7 Sep 2026
- **Type:** SRO rule
- **Date / status:** In force; adopted SR-NASD-2003-13 eff. 15 Feb 2005 (as IM-2210-6); last amended SR-FINRA-2017-036 eff. 22 Jan 2018.
- **Level 2**
- **Definition, verbatim (paragraph (b)):**
> "For purposes of this Rule and any interpretation thereof, an 'investment analysis tool' is an interactive technological tool that produces simulations and statistical analyses that present the likelihood of various investment outcomes if certain investments are made or certain investment strategies or styles are undertaken, thereby serving as an additional resource to investors in the evaluation of the potential risks and returns of investment choices."
- **Paragraph (a), verbatim:**
> "(a) General Considerations. This Rule provides a limited exception to Rule 2210(d)(1)(F). No member may imply that FINRA endorses or approves the use of any investment analysis tool or any recommendation based on such a tool. A member that offers or intends to offer an investment analysis tool under this Rule (whether customers use the member's tool independently or with assistance from the member) must provide FINRA's Advertising Regulation Department ('Department') access to the investment analysis tool upon request."
- **Paragraph (c), verbatim in full — the conditions:**
> "(c) Use of Investment Analysis Tools and Related Written Reports and Retail Communications. A member may provide an investment analysis tool (whether customers use the member's tool independently or with assistance from the member), written reports indicating the results generated by such tool and related retail communications only if the tool, written report or related retail communication:
> (1) describes the criteria and methodology used, including the investment analysis tool's limitations and key assumptions;
> (2) explains that results may vary with each use and over time;
> (3) if applicable, describes the universe of investments considered in the analysis, **explains how the tool determines which securities to select, discloses if the tool favors certain securities and, if so, explains the reason for the selectivity**, and states that other investments not considered may have characteristics similar or superior to those being analyzed; and
> (4) displays the following additional disclosure: 'IMPORTANT: The projections or other information generated by [name of investment analysis tool] regarding the likelihood of various investment outcomes are hypothetical in nature, do not reflect actual investment results and are not guarantees of future results.'" (emphasis added)
- **Paragraph (d), verbatim:**
> "(d) Disclosures. The disclosures and other required information discussed in paragraph (c) must be clear and prominent and must be in written (which may be electronic) narrative form."
- **Supp. Mat. .04, verbatim — the member/tool allocation:**
> ".04 Compliance with Other Applicable Laws and Rules. As in all cases, a member's compliance with this Rule does not mean that the member is acting in conformity with other applicable laws and rules. **A member that offers an investment analysis tool under this Rule (whether customers use the member's tool independently or with assistance from the member) is responsible for ensuring that use of the investment analysis tool and all recommendations based on the investment analysis tool (whether made via the automated tool or a written report) comply**, as applicable, with FINRA's suitability rule (Rule 2111), the other provisions of Rule 2210 …, the federal securities laws …, the SEC rules (including, but not limited to, Securities Act Rule 156) and other FINRA rules." (emphasis added)
- **Supp. Mat. .06, verbatim — the favouring disclosure:**
> ".06 Investment Analysis Tools that Favor Certain Securities. The disclosure required by paragraph (c)(3) must indicate, among other things, whether the investment analysis tool searches, analyzes or in any way favors certain securities within the universe of securities considered **based on revenue received by the member in connection with the sale of those securities or based on relationships or understandings between the member and the entity that created the investment analysis tool**. The disclosure also must indicate whether the investment analysis tool is limited to searching, analyzing or in any way favoring securities in which the member makes a market, serves as underwriter, or has any other direct or indirect interest. Members are not required to provide a 'negative' disclosure (i.e., a disclosure indicating that the tool does not favor certain securities)." (emphasis added)
- **Supp. Mat. .05, verbatim — the incidental-reference gradation:**
> ".05 Incidental References to Investment Analysis Tools. A retail communication that contains only an incidental reference to an investment analysis tool (e.g., a brochure that merely mentions a member's tool as one of the services offered by the member) need not include the disclosures required by this Rule and would not need to be filed with the Department, unless otherwise required by the other provisions of Rule 2210. A retail communication that refers to an investment analysis tool in more detail but does not provide access to the tool or the results generated by the tool must provide the disclosures required by paragraphs (c)(2) and (c)(4), but may exclude the disclosures required by paragraphs (c)(1) and (c)(3)."

- **Answering the brief's question — are 2214's conditions on the tool or on the member?** **Both, and the rule is drafted to make the distinction unstable on purpose.** Paragraph (c)'s chapeau is addressed to the member ("A member may provide … only if"), but the conditions attach to the artefact: "**the tool, written report or related retail communication**" must describe, explain, disclose and display. Paragraph (a)'s access obligation and Supp. Mat. .02's modification power run against the **member**. Supp. Mat. .04 puts responsibility for "all recommendations based on the investment analysis tool (whether made via the automated tool or a written report)" on the **member that offers** it. The recurring parenthetical "(whether customers use the member's tool independently or with assistance from the member)" appears four times and is there precisely to deny that unassisted customer operation relieves the member.
- **What it establishes:** (i) FINRA contemplates in terms that an **automated tool can itself make a recommendation** ("recommendations … made via the automated tool"); (ii) a tool that **favours certain securities** triggers a **disclosure** obligation, not automatically a recommendation finding; (iii) the disclosures must be "clear and prominent" — a presentation mandate, but a mandate to disclose, not a cure.
- **Q1:** MIXED. Supp. Mat. .04's "recommendations … made via the automated tool" is ADVERSE to any argument that automation as such prevents a recommendation. The favouring-as-disclosure structure is SUPPORT for the proposition that vendor-side selectivity is not per se a recommendation.
- **Application note:** The configuration's engine does not "produce simulations and statistical analyses that present the likelihood of various investment outcomes," so it is likely outside 2214(b)'s definition entirely — which means it gets neither 2214's burdens nor its limited exception to Rule 2210(d)(1)(F). Rule 2111.03(c)(iii) conditions the asset-allocation safe harbour on 2214 compliance *if* the model is a covered tool; a tool outside the definition cannot use that route either.

---

### S5-05 · NASD Notice to Members 04-86, "SEC Approves Interpretive Material 2210-6 Regarding Requirements for the Use of Investment Analysis Tools" (Dec 2004) · https://www.finra.org/rules-guidance/notices/04-86 · retrieved 7 Sep 2026
- **Type:** SRO notice announcing SEC approval of IM-2210-6 (predecessor of Rule 2214)
- **Date / status:** Superseded in form by Rule 2214; retained as the "Selected Notice" for 2214.
- **Level 3** — lineage only; the operative text is now in 2214.
- **Verbatim:**
> "Members must keep in mind that compliance with IM-2210-6 does not mean that the member is acting in conformity with other applicable laws and rules. A member that offers an investment analysis tool under IM-2210-6 (whether customers use the member's investment analysis tool independently or with assistance from the member) is responsible for ensuring that use of the tool and all recommendations based on the tool (whether made via the automated tool or a written report) comply …"
> "The Advertising Department's review of investment analysis tools generally will focus on whether the member has made the proper disclosures. Members are cautioned that they may not imply that NASD endorses or approves the use of any investment analysis tool or any recommendation based on such a tool." (n.7)
- **What it establishes:** The "recommendations … made via the automated tool" formulation dates from 2004 and has survived every amendment since; and the regulator's own review of these tools "will focus on whether the member has made the proper disclosures," not on whether the tool's output is a recommendation.
- **Q1:** NEUTRAL / mild SUPPORT.

---

### S5-06 · FINRA Rule 2210(d)(1) (Communications with the Public — Content Standards) · https://www.finra.org/rules-guidance/rulebooks/finra-rules/2210 · retrieved 7 Sep 2026
- **Type:** SRO rule
- **Date / status:** In force.
- **Level 3** — does not address the recommendation line, but constrains presentation directly and independently.
- **Verbatim, (d)(1)(A)–(F):**
> "(A) All member communications must be based on principles of fair dealing and good faith, must be fair and balanced, and must provide a sound basis for evaluating the facts in regard to any particular security or type of security, industry, or service. No member may omit any material fact or qualification if the omission, in light of the context of the material presented, would cause the communications to be misleading.
> (B) No member may make any false, exaggerated, unwarranted, promissory or misleading statement or claim in any communication. …
> (C) **Information may be placed in a legend or footnote only in the event that such placement would not inhibit an investor's understanding of the communication.**
> (D) Members must ensure that statements are clear and not misleading within the context in which they are made, and that they provide balanced treatment of risks and potential benefits. …
> (E) Members must consider the nature of the audience to which the communication will be directed and must provide details and explanations appropriate to the audience.
> (F) **Communications may not predict or project performance, imply that past performance will recur or make any exaggerated or unwarranted claim, opinion or forecast**; provided, however, that this paragraph (d)(1)(F) does not prohibit: (i) A hypothetical illustration of mathematical principles, provided that it does not predict or project the performance of an investment or investment strategy; (ii) An investment analysis tool, or a written report produced by an investment analysis tool, that meets the requirements of Rule 2214 …" (emphasis added)
- **What it establishes:** Evaluative labels ("best", "top opportunity", "strong buy") are separately exposed under (d)(1)(F) as an "exaggerated or unwarranted claim, opinion or forecast" **irrespective of whether they make the communication a recommendation**; and (d)(1)(C) is an express rule against burying a qualification in a legend — the presentation-law analogue of 01-23's disclaimer guideline.
- **Q1:** NEUTRAL on the recommendation line; relevant as a second, independent constraint on labels.
- **Application note:** This rule binds members, not unregistered software vendors. It is included because it shows that where a US regulator has legislated about evaluative labels at all, it did so as a content-standards matter and not by making the label a recommendation trigger.

---

### S5-07 · FINRA Regulatory Notice 11-02, "Know Your Customer and Suitability" (Jan 2011), at 2–3 · https://www.finra.org/rules-guidance/notices/11-02 · retrieved 7 Sep 2026
- **Type:** SRO regulatory notice
- **Date / status:** In force; "Selected Notice" to Rule 2111.
- **Level 2**
- **Verbatim, in full (the passage P7 records only in part):**
> "The determination of the existence of a recommendation has always been based on the facts and circumstances of the particular case. That remains true under the new rule. FINRA reiterates, however, that several guiding principles are relevant to determining whether a particular communication could be viewed as a recommendation for purposes of the suitability rule.
> For instance, a communication's content, context and presentation are important aspects of the inquiry. The determination of whether a 'recommendation' has been made, moreover, is an objective rather than subjective inquiry. An important factor in this regard is whether-given its content, context and manner of presentation-a particular communication from a firm or associated person to a customer reasonably would be viewed as **a suggestion that the customer take action or refrain from taking action** regarding a security or investment strategy. In addition, the more individually tailored the communication is to a particular customer or customers about a specific security or investment strategy, the more likely the communication will be viewed as a recommendation. Furthermore, **a series of actions that may not constitute recommendations when viewed individually may amount to a recommendation when considered in the aggregate. It also makes no difference whether the communication was initiated by a person or a computer software program.** These guiding principles, together with numerous litigated decisions and the facts and circumstances of any particular case, inform the determination of whether the communication is a recommendation for purposes of FINRA's suitability rule." (emphasis added)
- **What it establishes:** Restates 01-23's framework at rule-consolidation, adds "or refrain from taking action," and states the person/software equivalence as a general principle rather than (as in 01-23) only in the context of deciding to send unrequested information.
- **Q1:** ADVERSE on the automation point; NEUTRAL otherwise.

---

### S5-08 · FINRA Regulatory Notice 12-25, "Additional Guidance on FINRA's New Suitability Rule" (May 2012), A2, A8, n.41, n.42 · https://www.finra.org/rules-guidance/notices/12-25 · retrieved 7 Sep 2026
- **Type:** SRO regulatory notice (FAQ format)
- **Date / status:** In force; "Selected Notice" to Rules 2111 and 2214.
- **Level 2**
- **A2 (that FINRA does not define the term, and that pre-2012 guidance survives):**
> "Although FINRA does not define the term 'recommendation,' it has offered several guiding principles that firms and brokers should consider when determining whether particular communications could be viewed as recommendations. FINRA has extensively addressed those guiding principles in past Regulatory Notices, and cases have applied them to specific facts. Some SEC releases and FINRA cases and interpretive letters also have explained that a broker-dealer's use or distribution of marketing or offering materials ordinarily would not, by itself, constitute a 'recommendation' for purposes of the suitability rule. **The prior guidance and interpretations generally remain applicable**, and firms and brokers should review those existing resources for assistance in understanding the breadth of the term 'recommendation.'" (emphasis added)
- **A8, closing paragraph — THE NUMBER-OF-ITEMS AUTHORITY:**
> "In this regard, firms should note that, **as an allocation recommendation becomes narrower or more specific, the recommendation gets closer to becoming a recommendation of particular securities** and, thus, subject to the suitability rule, **depending on a variety of factors (including the number of issuers that fall within the broker-dealer's allocation recommendation)**. Accordingly, broker-dealers should assess whether allocation recommendations involving certain types of sub-categories of broader market sectors or even more limited groupings are so specific or narrow that they constitute recommendations of particular securities." (emphasis added; the parenthetical is n.41's host sentence)
- **n.42, verbatim in full:**
> "In Notice to Members 01-23 (Apr. 2001), FINRA explained 'that a portfolio analysis tool that merely generates a suggested mix of genera[l] classes of financial assets' would not, by itself, trigger a suitability obligation under NASD Rule 2310; however, **the more a general class is narrowed (e.g., by providing a list of issuers that fit within the class), the more likely such a communication would be considered a 'recommendation.'** Id. at 6 n.15. Firms should use a similar approach to analyzing whether particular recommendations are eligible for the Rule 2111.03 safe-harbor provision." (emphasis added)
- **A8, safe-harbour paragraph:**
> "Under this provision, the suitability rule would not apply, for example, to a general recommendation that a customer's portfolio have certain percentages of investments in equity securities, fixed-income securities and cash equivalents, if the recommendation is based on an asset allocation model that meets the above criteria **and the firm does not recommend a particular security or securities in connection with the allocation**. The suitability rule also would not apply to a firm's allocation recommendation regarding broad-based market sectors (e.g., agriculture, construction, finance, manufacturing, mining, retail, services, transportation and public utilities, and wholesale trade)." (emphasis added)
- **A3 (implicit recommendations — the limit):**
> "FINRA and the SEC have held, for example, that brokers who effect transactions on a customer's behalf without informing the customer have implicitly recommended those transactions, thereby triggering application of the suitability rule. Although such holdings continue to act as precedent regarding those issues, the new rule does not broaden the scope of implicit recommendations. The new rule, for example, does not apply to implicit recommendations to hold a security or securities. Thus, the new rule's 'hold' language would not apply when a broker remains silent regarding security positions in an account. **The hold recommendation must be explicit.**" (emphasis added)
- **What it establishes:** This is the located authority on **narrowing and on the number of items**. FINRA does not fix a number; it makes the count of issuers one of "a variety of factors," and describes a continuum from asset classes → broad market sectors → sub-categories → "more limited groupings" → particular securities. The tipping point is qualitative: whether the grouping is "so specific or narrow that [it constitutes] recommendations of particular securities."
- **Q1:** ADVERSE for any tool that resolves to named instruments; SUPPORT for class- or sector-level output.
- **Application note:** No located authority says a list of one differs in kind from a list of twenty. 12-25 A8 makes the number a factor bearing on whether a **class-level** recommendation has collapsed into a securities-level one; once the output is already a named instrument, the count is spent — one named instrument is already "a particular security" under Rule 2111.03's chapeau. The configuration's output is a named instrument, so the narrowing analysis does not assist it: it starts past the end of that continuum.

---

### S5-09 · FINRA Regulatory Notice 22-08, "Complex Products and Options" (Mar 2022), n.60, and the questions at pp. 12–17 · https://www.finra.org/rules-guidance/notices/22-08 · retrieved 7 Sep 2026
- **Type:** SRO regulatory notice and request for comment
- **Date / status:** Published Mar 2022; the request-for-comment portion is closed. FINRA has not adopted a rule on the platform questions it asked.
- **Level 2 for n.60; Level 4 for the questions (a regulator's unanswered questions are not authority).**
- **n.60, verbatim — the clearest statement that a self-directed platform can operate without recommending:**
> "See Reg BI Adopting Release at 33376. Note that Reg BI and FINRA Rule 2111 apply when a broker-dealer or its associated persons make securities recommendations (including, in the case of Reg BI, recommendations of types of accounts); **neither Reg BI nor Rule 2111 apply in the absence of a recommendation, such as where a retail investor invests entirely on their own accord in complex products through a self-directed account.**" (emphasis added)
- **The platform question, verbatim (p. 15):**
> "Given the uptick in transactions in options and other complex products through self-directed platforms, many of which are designed to provide retail customers with easy access to an array of financial products, are additional guardrails needed for these types of platforms, including for example, **in cases where communications through the platform do not rise to the level of a 'recommendation' under Reg BI**?" (emphasis added; n.80 cross-refers to the SEC's DEP release)
- **The push-notification questions, verbatim (pp. 13 and 16):**
> "Should targeted communications, such as push notifications to self-directed retail customers regarding complex products, be subject to specific restrictions? For example, should they be restricted unless certain conditions have been satisfied, including that the account has been approved for complex products?"
> "Should targeted communications, such as push notifications to self-directed retail customers, regarding options be subject to specific restrictions? …"
- **What it establishes:** As of 2022 FINRA's own working premise was that communications through a self-directed platform **may well not** rise to the level of a recommendation — which is why it was asking whether separate guardrails were needed. It also classes push notifications as "targeted communications," but only in a question, and imposes nothing.
- **Q1:** SUPPORT (n.60 and the framing of the platform question).
- **Application note:** n.60 is the most directly favourable sentence located in any FINRA document, but it is a footnote describing the rules' scope, not an application to any facts. Its subject is the **investor** ("invests entirely on their own accord"), not the software.

---

### S5-10 · FINRA, "2021 Report on FINRA's Examination and Risk Monitoring Program" (Feb 2021), Communications with the Public — "New Digital Platforms With Interactive and 'Game-Like' Features" · https://www.finra.org/sites/default/files/2021-02/2021-report-finras-examination-risk-monitoring-program.pdf · retrieved 7 Sep 2026
- **Type:** SRO examination report
- **Date / status:** Published Feb 2021. Superseded annually in form; not withdrawn.
- **Level 3** — this is FINRA asking firms a question, not answering it.
- **Verbatim (Exam Findings / questions):**
> "If your firm offers an app to customers that includes an interactive element, **does the information provided to customers constitute a 'recommendation' that would be covered by Reg BI**, which requires a broker-dealer to act in a retail customer's 'best interest,' or suitability obligations under FINRA Rule 2360 (Options)? If so, how does your firm comply with these obligations?"
> "If your firm's app platform design includes 'game-like' aspects that are intended to influence customers to engage in certain trading or other activities, how does your firm address and disclose the associated potential risks to your customers?" (emphasis added)
- **Verbatim (Emerging Digital Communication Risks):**
> "Some online broker-dealers' apps—as well as those offered by other financial services and consumer-oriented businesses—include interactive and 'game-like' features, as well as related forms of advertising and marketing. Such features affect many aspects of how firms interact and communicate with customers, from initial advertisements through the opening of accounts, **recommendations and the presentation of different investment choices**. While such features may improve customers' access to firm systems and investment products, they may also result in increased risks to customers if not designed with the appropriate compliance considerations in mind. Firms must evaluate these features to determine whether they meet regulatory obligations to: … comply with any Reg BI and Form CRS requirements **if any communications constitute a 'recommendation'** …" (emphasis added)
- **What it establishes:** FINRA identified app interactivity and game-like design as raising the recommendation question in Feb 2021 and, as of this retrieval, has published no answer to it.
- **Q1:** NEUTRAL — a documented open question, cited so that the absence of an answer is on the record rather than inferred.

---

### S5-11 · SEC, "Request for Information and Comments on Broker-Dealer and Investment Adviser Digital Engagement Practices…", Release No. 34-92766, 86 FR 49067 (published 1 Sep 2021; issued 27 Aug 2021) · https://www.federalregister.gov/documents/2021/09/01/2021-18901/ · retrieved 7 Sep 2026
- **Type:** Commission request for information and comment (**not** a rule, not an interpretation)
- **Date / status:** Comment period closed. **No rule, interpretation or guidance was ever adopted from it.** The one rulemaking that followed (S5-12) was withdrawn.
- **Level 3** — a Commission document that catalogues the features but adopts no position; it asks questions and answers none.
- **Note on the citation in the brief:** the release is dated 27 Aug 2021 but was **published 1 Sep 2021** at 86 FR 49067. Both dates are correct for different purposes; FINRA RN 22-08 n.80 cites it as "(August 27, 2021), 86 FR 49067 (September 1, 2021)".
- **The enumeration, verbatim:**
> "Examples of digital engagement practices include: Social networking tools; games, streaks and other contests with prizes; points, badges, and leaderboards; notifications; celebrations for trading; visual cues; ideas presented at order placement and other curated lists or features; subscriptions and membership tiers; and chatbots."
> "DEPs … broadly include behavioral prompts, differential marketing, game-like features, and other design elements or features designed to engage retail investors."
- **Points, Badges, and Leaderboards, verbatim — note who sets the criteria:**
> "Certain platforms also offer badges as visual markers of achievement as well as leaderboards to rank individuals based on **performance-based criteria developed by the firm**." (emphasis added)
- **Notifications, verbatim — default-on, top movers, frequency:**
> "Some digital platforms may use notifications via email, text, or other means (e.g., push notifications on mobile devices). **In some cases, investors can opt-in or opt-out of notifications; in others, notifications may be set by default with no ability to opt-out.** Investors may receive notifications indicating a certain stock is up or down, **noting a list of stocks qualifying as top 'movers'** (i.e., largest percentage change in price), or reminding them that it has been a certain number of days since they last engaged in a trade. Notifications may also be used to attempt to reassure investors during periods of market volatility." (emphasis added)
- **Celebrations for Trading, verbatim:**
> "Some digital platforms may have embedded animations and graphics, such as digital confetti or crowds applauding, that 'celebrate' when investors enter orders to purchase stock or options."
- **Visual Cues, verbatim — highlighting, prominence, colour:**
> "Interface design elements may provide visual cues, **including by displaying certain information more prominently than other information**. In some cases, visual cues are targeted specifically to the investor. For example, some digital platforms' user interfaces **shift the coloration of the entire screen between green and red** based on an investor's portfolio performance. Some digital platforms present relevant news or other pieces of information to the user immediately once the portfolio turns negative." (emphasis added)
- **Ideas Presented at Order Placement and Other Curated Lists, verbatim:**
> "Some digital platforms may present 'ideas' prior to allowing the investor to place an order. These ideas may involve curated lists or features, news headlines, etc."
- **The Commission's statement of the legal position, verbatim (Standard of Conduct bullet and n.31):**
> "**The use of a DEP by a broker-dealer may, depending on the relevant facts and circumstances, constitute a recommendation for purposes of Reg BI.** Whether a 'recommendation' has been made is interpreted consistent with precedent under the federal securities laws and how the term has been applied under FINRA rules." (emphasis added)
> n.31: "Reg BI Adopting Release … at 33337. The determination of whether a recommendation has been made turns on the facts and circumstances of a particular situation. Id. at 33335 ('Factors considered in determining whether a recommendation has taken place include whether a communication "reasonably could be viewed as a 'call to action'" and "reasonably would influence an investor to trade a particular security or group of securities." The more individually tailored the communication to a specific customer or a targeted group of customers about a security or group of securities, the greater the likelihood that the communication may be viewed as a "recommendation."') (citation omitted); **see also NASD Notice to Members 01-23 (Apr. 2001) (Online Suitability--Suitability Rules and Online Communications) (providing examples of electronic communications that are considered to be either within or outside the definition of 'recommendation')**. To the extent that a broker-dealer makes a recommendation, as that term is interpreted by the Commission under Reg BI, to a retail customer through or in connection with a DEP, Reg BI would apply to the recommendation." (emphasis added)
- **The questions the Commission asked about recommendations, verbatim:**
> "1.19 Do retail investors believe they are receiving investment advice or recommendations from DEPs or certain types of DEPs? If so, please explain. …"
> "3.6 Do broker-dealers consider the observable impacts of DEPs when determining if they are making 'recommendations' for purposes of Reg BI? How does the fact that a DEP might impact the behavior of a statistically significant number of retail investors affect this determination? What statistical concepts, tools, and quantitative thresholds do broker-dealers use in making this determination?"
> "3.7 **Are there particular types of DEPs that broker-dealers avoid using because they would be recommendations?** If so, which DEPs and why? …" (emphasis added)
> "3.9 Are there particular types of DEPs that investment advisers avoid using because they would constitute providing investment advice? If so, which DEPs and why? …"
- **What it establishes:** (i) The Commission's catalogue of the exact features this track was asked about — highlighting, colour, badges, leaderboards, top-movers lists, curated lists, default-on push notifications, frequency prompts, confetti. (ii) Its only legal statement about them is that a DEP "**may**, depending on the relevant facts and circumstances, constitute a recommendation," interpreted by reference to **01-23 and the Reg BI adopting release** — i.e. the Commission's answer to "what is more?" is to point back at 01-23. (iii) Question 3.6 floats an **observable-behavioural-impact** test ("statistically significant number of retail investors") that exists nowhere in adopted law.
- **Q1:** NEUTRAL, tending SUPPORT — a Commission-level confirmation that 01-23 is the operative framework for exactly these features, and that nothing has been added to it.
- **Application note:** The configuration deploys none of the catalogued features: no badges, leaderboards, streaks, confetti, celebration animation, colour shifts, prominence differentials, curated lists, ideas at order placement, or default-on notifications. Its sort labels are neutral and nothing is highlighted. On the DEP catalogue it is at the null end. But the catalogue carries no legal consequence of its own — absence from it establishes nothing, and must not be cited as if it did.

---

### S5-12 · SEC, "Conflicts of Interest Associated With the Use of Predictive Data Analytics by Broker-Dealers and Investment Advisers", Release Nos. 34-97990 / IA-6353, 88 FR 53960 (9 Aug 2023) — **WITHDRAWN** · https://www.federalregister.gov/documents/2023/08/09/2023-16377/ · retrieved 7 Sep 2026
- **Type:** Proposed rule — **withdrawn**
- **Date / status:** **WITHDRAWN.** *Withdrawal of Proposed Regulatory Actions*, Release Nos. 33-11377; 34-103247; IA-6885; IC-35635, **issued 12 June 2025** ("Dated: June 12, 2025" / "By the Commission"), **published 17 June 2025** at **90 FR 25531–25533**, File No. S7-12-23. Both dates verified in the document text at https://www.federalregister.gov/documents/full_text/text/2025/06/17/2025-11110.txt (retrieved 7 Sep 2026). Confirmed still withdrawn as of 7 Sep 2026; no re-proposal located.
- **Level 4 as law (it is not law); Level 2 as evidence of the Commission's stated view of the recommendation line in 2023.**
- **The withdrawal, verbatim:**
> "SUMMARY: The Securities and Exchange Commission ('Commission') is formally withdrawing certain notices of proposed rulemaking issued between March 2022 and November 2023. **The Commission does not intend to issue final rules with respect to these proposals.** If the Commission decides to pursue future regulatory action in any of these areas, it will issue a new proposed rule." (90 FR 25531)
> "DATES: The Commission is withdrawing the proposed rules published at … **88 FR 53960 (August 9, 2023)** …" (90 FR 25531)
- **Proposed definitions, verbatim (proposed 17 CFR 240.15l-2(a) and 275.211(h)(2)-4(a)):**
> "**Covered technology** means an analytical, technological, or computational function, algorithm, model, correlation matrix, or similar method or process that optimizes for, predicts, guides, forecasts, or directs investment-related behaviors or outcomes."
> "**Investor interaction** means engaging or communicating with an investor, including by exercising discretion with respect to an investor's account; providing information to an investor; or soliciting an investor; except that the term does not apply to interactions solely for purposes of meeting legal or regulatory obligations or providing clerical, ministerial, or general administrative support."
- **THE OPERATIVE ADMISSION — the Commission's own economic analysis, verbatim:**
> "These include the requirements of the investment adviser's fiduciary duty obligations toward clients; and the broker-dealer's Conflict of Interest Obligation under Reg BI for recommendation interactions. However, **some interactions covered by the proposed conflicts rules would not constitute recommendations for the purposes of Reg BI**, and might not receive the same investor protection benefits as recommendations. Relative to the baseline, the proposed conflicts rules would impose requirements specific to the use of covered technologies in investor interactions. The proposed conflicts rules' conflict of interest obligations would cover **the entirety** of investment advisers' interactions with investors, and for broker-dealers **the entirety** of their interactions with retail investors." (emphasis added)
> "[Behaviour-influencing practices analogous to gambling-industry strategies] **might not constitute recommendations, and therefore might not face the same obligations that recommendations would.** In addition, given that these strategies exploit psychological biases and innate tendencies of the investor rather than information deficiencies or asymmetries, **even comprehensive, accurate, and legible disclosure might be less effective** at ensuring disinterested investor interactions …" (emphasis added)
- **What it establishes:** This is the single most useful document located for Question A's negative half. In 2023 the Commission proposed to regulate DEPs and predictive technology **precisely because**, on its own analysis, such practices "might not constitute recommendations" and therefore fell outside Reg BI. That is the Commission stating that gamified, behaviour-influencing, algorithmically-personalized presentation does **not**, without more, cross the recommendation line under existing law. And the proposal that would have changed that was withdrawn with the statement that the Commission "does not intend to issue final rules."
- **Q1:** **SUPPORT — strong.** The recommendation line as of 7 Sep 2026 is where 01-23 and the Reg BI adopting release left it; the Commission tried to move past it by rulemaking, and abandoned the attempt.
- **Level-1 caution:** a withdrawn proposal's economic analysis is not law and does not bind. It is admissible here as the Commission's own contemporaneous characterisation of the **existing** legal baseline, which is what makes it useful. Cite it for what the baseline was, never for what the rule would have been.
- **Application note:** The proposed "covered technology" definition — "algorithm, model … that optimizes for, predicts, guides, forecasts, or directs investment-related behaviors or outcomes" — would plainly have captured the configuration's engine. Its withdrawal removes that exposure prospectively but establishes that the Commission had the configuration's genus in view and chose to describe it as something *other than* recommending.

---

### S5-13 · Regulation Best Interest adopting release, Release No. 34-86031, 84 FR 33318 (12 Jul 2019), at 33335, 33338 n.182, 33402 · https://www.federalregister.gov/documents/full_text/text/2019/07/12/2019-12164.txt · retrieved 7 Sep 2026
- **Type:** Commission rule adopting release
- **Date / status:** In force.
- **Level 1**
- P7 already holds page 79 & n.161 of the slip release adopting the 01-23 framework. The Federal Register pin-cites for that passage and the additional passages are given here.
- **At 84 FR 33335 — the factors, verbatim:**
> "[Whether a recommendation has taken] place is not susceptible to a bright line definition. Factors considered in determining whether a recommendation has taken place include whether the communication 'reasonably could be viewed as a "call to action"' and 'reasonably would influence an investor to trade a particular security or group of securities.' The more individually tailored the communication to a specific customer or a targeted group of customers about a security or group of securities, the greater the likelihood that the communication may be viewed as a 'recommendation.' We continue to believe this general framework regarding what is a recommendation is appropriate, and for the reasons discussed in the Proposing Release, are taking this approach." (n.161–162)
- **At 84 FR 33335 — the self-directed carve-out, verbatim (twice stated):**
> "[Regulation Best Interest does not] … (3) **apply to self-directed or otherwise unsolicited transactions by a retail customer, whether or not she also receives separate recommendations from the broker-dealer.**"
> "Nor does Regulation Best Interest apply to self-directed or otherwise unsolicited transactions by a retail customer, whether or not he or she also receives separate recommendations from the broker-dealer." (emphasis added)
- **At 84 FR 33335 n.165 — FINRA's refusal to define the term, verbatim:**
> "Similarly, FINRA has stated that 'defining the term "recommendation" is unnecessary and would raise many complex issues in the absence of specific facts of a particular case.' Exchange Act Release No. 37588, 1996 SEC LEXIS 2285, at *29 (Aug. 20, 1996), 61 FR 44100, 44107 (Aug. 27, 1996)."
- **At 84 FR 33338 n.182 — the Commission adopts the narrowing principle:**
> "In this regard, **as an allocation recommendation becomes narrower or more specific, the recommendation gets closer to becoming a recommendation of particular securities** and, thus, subject to the suitability rule. See FINRA Regulatory Notice 12-25 at FAQ 8." (emphasis added)
- **At 84 FR 33338 — the education carve-out applied, verbatim:**
> "Thus, for example, a general conversation about retirement planning, such as providing a company's retirement plan options to a retail customer, would not, by itself, rise to the level of a recommendation. Similarly, where a broker-dealer informs a retail customer that he or she needs to take a required minimum distribution under the Internal Revenue Code, we would not interpret such communication, by itself, to rise to the level of a recommendation."
- **At 84 FR 33402 n.853 — automated recommendations without a human, verbatim:**
> "[N]ote, however, that a retail customer may receive automated advice without involvement of an associated person of the broker-dealer. For example, **a broker-dealer may generate recommendations through an asset allocation model.** FINRA Regulatory Notice 12-25; See also FINRA Report on Digital Investment Advice (Mar. 2016)." (emphasis added)
- **What it establishes:** The Commission adopted 01-23's framework wholesale, adopted 12-25's narrowing principle by citation at n.182, expressly excluded self-directed and unsolicited transactions from Reg BI, and expressly contemplated that recommendations can be generated by a model with no human involved.
- **Q1:** MIXED — the self-directed carve-out is SUPPORT; n.182 and n.853 are ADVERSE.
- **Application note:** "Self-directed or otherwise unsolicited" is the Commission's own framing and it is the closest federal text to the configuration's premise. But the carve-out is addressed to the **broker-dealer's** obligations toward its customer; it says nothing about whether a **third party** supplying the signal is advising. It does not reach Q1.

---

### S5-14 · FINRA, "Report on Digital Investment Advice" (Mar 2016), at 2 and 8 · https://www.finra.org/sites/default/files/digital-investment-advice-report.pdf · retrieved 7 Sep 2026
- **Type:** SRO report (effective-practices report; not a rule and not an interpretation)
- **Date / status:** Published Mar 2016; not withdrawn. Cited by the Commission at Reg BI 84 FR 33402 n.853.
- **Level 3** — a report of practices, expressly not a rule; useful for how FINRA locates the recommendation.
- **Verbatim, at 2 ("A Brief History of Digital Investment Advice"):**
> "Financial professionals have used digital investment advice tools for years. These tools help financial professionals at each point in the value chain described above, for example, to develop an investor profile, to prepare proposals and sales materials, to develop an asset allocation or **to recommend specific securities to an investor**. Those recommendations may be for individual securities, a customized portfolio or a pre-packaged portfolio for investors with a given profile. … **The tools financial professionals use may be developed by their firms, acquired from third-party vendors by their firm or, in some cases, acquired by the financial professionals themselves.**" (emphasis added)
- **Verbatim, at 8:**
> "FINRA reinforces that **a registered representative using a digital advice tool to help develop a recommendation must comply with requirements of the suitability rule and cannot rely on the tool as a substitute** for the requisite knowledge about the securities or customer necessary to make a suitable recommendation." (emphasis added)
- **What it establishes:** FINRA describes third-party-vendor tools that "recommend specific securities" and then places the suitability obligation on **the registered representative using the tool**, not on the tool or its vendor. The report contains no suggestion that the third-party vendor thereby recommends.
- **Q1:** SUPPORT — mild but structurally on point: the located regulator treats the tool as an instrument of the user's recommendation, and locates the obligation with the user.
- **Application note:** The report's addressees are members and their associated persons; it says nothing about whether a vendor selling such a tool to a non-member natural person is advising. It does confirm that FINRA has had third-party-vendor-supplied security-selection tools squarely in view since 2016 and has never suggested the vendor is the recommender.

---

### S5-15 · FINRA Regulatory Notice 10-06, "Social Media Web Sites — Guidance on Blogs and Social Networking Web Sites" (Jan 2010), A2–A3 · https://www.finra.org/rules-guidance/notices/10-06 · retrieved 7 Sep 2026
- **Type:** SRO regulatory notice (Q&A format)
- **Date / status:** In force; cited as still-applicable guidance at FINRA RN 12-25 n.24.
- **Level 3**
- **Verbatim, A2 — 01-23 is the operative test for any online communication:**
> "Q2: If a firm or its personnel recommends a security through a social media site, does this trigger the requirements of NASD Rule 2310 regarding suitability?
> A2: Yes. Whether a particular communication constitutes a 'recommendation' for purposes of Rule 2310 will depend on the facts and circumstances of the communication. **Firms should consult Notice to Members (NTM) 01-23 (Online Suitability) for additional guidance concerning when an online communication falls within the definition of 'recommendation' under Rule 2310.**
> Various social media sites include functions that make their content widely available or that limit access to one or more individuals. **Rule 2310 requires a broker-dealer to determine that a recommendation is suitable for every investor to whom it is made.**" (emphasis added)
- **Verbatim, A3 — the promote/recommend gap, acknowledged:**
> "Firms also should consider adopting policies and procedures governing communications that **promote** specific investment products, **even if these communications might not constitute a 'recommendation' for purposes of our suitability rule or otherwise.**" (emphasis added)
- **What it establishes:** Nine years after 01-23 and two years before RN 12-25, FINRA's answer to "when is an online communication a recommendation?" was still to send firms to 01-23. And FINRA expressly recognises a category of communications that **promote** a specific security without constituting a recommendation — the same gap the Commission later described at 88 FR 53960 (S5-12).
- **Q1:** SUPPORT — a second regulator statement that promotion of a specific product and recommendation of it are distinct categories; and confirmation that 01-23 is the live test.
- **Application note:** A2's second paragraph is adverse in a different direction: where a recommendation *is* made, breadth of audience is no defence — it must be suitable "for every investor to whom it is made." That bears on any mass-distributed signal, and it is the same point as 01-23 n.17's second sentence.

---

### S5-16 · FINRA Regulatory Notice 17-18, "Guidance on Social Networking Websites and Business Communications" (25 Apr 2017), A3–A5 · https://www.finra.org/rules-guidance/notices/17-18 · retrieved 7 Sep 2026
- **Type:** SRO regulatory notice (Q&A format)
- **Date / status:** In force.
- **Level 3** — bears on **attribution** of a third party's list, not on the recommendation line itself.
- **The adoption/entanglement test, verbatim (A3):**
> "By sharing or linking to specific content, **the firm has adopted the content** and would be responsible for ensuring that, when read in context with the statements in the originating post, the content complies with the same standards as communications created by, or on behalf of, the firm." (emphasis added)
- **The "ongoing link" safe harbour, verbatim (A5) — the two critical factors:**
> "Whether a firm has adopted the content of an independent third-party website or any section of the website through the use of a link is fact dependent. **Two factors are critical to the analysis: (1) whether the link is 'ongoing' and (2) whether the firm has influence or control over the content of the third-party site.**
> The firm has not adopted the content if the link is 'ongoing,' meaning:
> • the link is continuously available to investors who visit the firm's site;
> • investors have access to the linked site whether or not it contains favorable material about the firm; and
> • the linked site could be updated or changed by the independent third-party and investors would nonetheless be able to use the link.
> **However, if the firm has any influence or control over the content of the third-party site, then the firm would be entangled with its content.** Further, language introducing the ongoing link must conform to the content standards of the communications rules …" (emphasis added)
- **The transitive-link limit, verbatim (A4):**
> "Solely by sharing or linking to content that contains links, a firm would not be responsible for the content available at such links. … In general, if a firm shares or links to content that in turn links to other content **over which the firm has no influence or control**, the firm would not have adopted the other content. In contrast, if a firm shares or links to content that in turn links to other content over which the firm has influence or control, the firm would then have adopted that other content. In addition, **where the firm shares or links to content that itself serves primarily as a vehicle for links, or where content available through such links forms the entire basis of the article, the firm would have adopted the other content** …" (emphasis added)
- **What it establishes:** FINRA's own adoption/entanglement test for third-party content, with a three-element definition of an "ongoing" link that avoids adoption, turning on continuous availability, indifference to whether the content favours the firm, and third-party control of updates.
- **Q1:** SUPPORT for the external-list element specifically, on the "ongoing link" configuration; ADVERSE on the "vehicle for links" limb.
- **Application note:** The configuration's external-list design — after one explicit member enable act the member's runtime fetches the publisher's list **directly from the publisher's own endpoint**, with the company never mirroring, caching, relaying or re-serving it — maps onto all three "ongoing" elements and onto "no influence or control." The adverse limb is A4's last sentence: a surface whose content "**serves primarily as a vehicle for links**" or where the linked content "**forms the entire basis**" of it is adopted notwithstanding. A runtime whose qualifying universe is, in substance, the third party's list is squarely within that description. Note also that 17-18 governs a **member's** attribution under Rule 2210, not an unregistered vendor's status; it is the FINRA-side analogue of the SEC attribution authorities already in P7's register (IA-5653 at 21; 73 FR 45862 at 45870-71), and it reads consistently with them.
- **Negative note:** RN 17-18 contains **one** occurrence of the word "recommend" in its entire text, and it is a reference to a 2014 retrospective review recommending more guidance — not a discussion of the recommendation element. It adds nothing to the Answer-A gap.

---

### S5-17 · SEC Division of Examinations, Examination Priorities — FY2022, FY2023, FY2024, FY2025, FY2026 · https://www.sec.gov/files/&lt;year&gt;-exam-priorities.pdf · retrieved 7 Sep 2026
- **Type:** Staff examination priorities (no legal force; not Commission action)
- **Date / status:** Annual; each superseded by the next. All five retrieved and searched.
- **Level 4** — staff statements of examination focus. Useful as evidence that a sweep exists and of how the staff frames the question; **not** authority for any proposition of law.
- **This answers the brief's question whether there is a sweep on "digital engagement": there is, and it ran FY2022 → FY2023, went dark in FY2024, and reappeared in a different form in FY2025.**

**FY2022, at 17, verbatim** (page located by counting the document's own page footers in the extracted text; the passage falls after the "16 | U.S. SECURITIES AND EXCHANGE COMMISSION" footer):
> "RIA and broker-dealer examinations will focus on firms that are, or claim to be, offering new products and services or employing new practices (e.g., fractional shares, 'Finfluencers,' or digital engagement practices) to assess whether: (1) operations and controls in place are consistent with disclosures made and the standard of conduct owed to investors and other regulatory obligations; **(2) advice and recommendations, including by algorithms, are consistent with investors' investment strategies and the standard of conduct owed to such investors**; and (3) controls take into account the unique risks associated with such practices." (emphasis added)

**FY2023, at 16, verbatim — the staff treats the recommendation question as open:**
> "Broker-dealer and RIA examinations will also focus on firms that employ digital engagement practices and the related tools and methods to assess whether: **(1) recommendations were made or advice was provided** (e.g., through the use of social media marketing and social trading platforms); (2) representations are fair and accurate; (3) operations and controls in place are consistent with disclosures made to investors; (4) any advice or recommendations are in the best interest of the investor taking into account the investor's financial situation and investment objectives; and (5) risks associated with such practices are considered, including the impact these practices may have on certain investors, such as seniors." (emphasis added)
> n.2: "For purposes of these examinations, the term 'digital engagement practices' includes tools with behavioral prompts, differential marketing, game-like features (commonly referred to as gamification), and other design elements or features designed to engage with retail investors on digital platforms (e.g., websites, portals, and applications), as well as the analytical and technological tools and methods."

**FY2025, verbatim:**
> "Examinations may also focus on recommendations: **(1) using automated tools or other digital engagement practices**; (2) related to opening different account types, such as option, margin and self-directed IRA accounts …" (emphasis added)

**FY2024 and FY2026: zero occurrences of "digital engagement", "gamification", "game-like" or "behavioral prompt"** (grep counts 0 and 0 over the full extracted text of each).

- **What it establishes:** (i) A sweep on digital engagement practices existed and was announced in terms for FY2022 and FY2023. (ii) In FY2023 the staff listed **"whether recommendations were made or advice was provided"** as the *first* thing examiners would assess about DEP firms — i.e. the staff itself treats the recommendation question as unsettled on these facts. (iii) By FY2025 the framing had shifted from "were recommendations made?" to policing "recommendations … using automated tools," assuming the answer. (iv) The topic disappears entirely from FY2024 and FY2026.
- **Q1:** NEUTRAL. Evidence of regulatory attention and of an unresolved question; no legal proposition.
- **Application note:** **No published outcome of either sweep was located** — no risk alert, no report of observations, and no enforcement action identified in this track as arising from the FY2022/FY2023 DEP examinations. That absence is recorded at N8, not inferred as safety. Note also that FY2022's phrase "advice and recommendations, **including by algorithms**" is the staff assuming, without analysis, that an algorithm can advise or recommend — consistent with RN 11-02 and Rule 2214 Supp. Mat. .04, and adverse to any argument resting on automation as such.

---

### S5-18 · FINRA Regulatory Notice 11-39, "Social Media Websites and the Use of Personal Devices for Business Communications" (Aug 2011), §§ 3–4 · https://www.finra.org/rules-guidance/notices/11-39 · retrieved 7 Sep 2026
- **Type:** SRO regulatory notice (Q&A format)
- **Date / status:** In force. **Retrieved directly, closing the ◇ item where S5-16 had quoted it only at second hand through RN 17-18.** Both propositions attributed to it there are confirmed verbatim.
- **Level 3**
- **§ 3, Links to Third-Party Sites, verbatim in full:**
> "Firms may not establish a link to any third-party site that the firm knows or has reason to know contains false or misleading content. A firm should not include a link on its website if there are any red flags that indicate the linked site contains false or misleading content. Additionally, a firm is responsible under NASD Rule 2210 for content on a linked third-party site if the firm has **adopted** or has become **entangled** with its content. For example, a firm may be deemed to have 'adopted' third-party content if it **indicates on its site that it endorses the content** on the third-party site. A firm could be deemed to have become 'entangled' with a third-party site if, for example, it **participates in the development of the content** on the third-party site." (emphasis added)
- **⭐ § 4, Data Feeds, verbatim in full — a vendor-criteria diligence obligation:**
> "Firms must adopt procedures to manage data feeds into their own websites. FINRA is aware of situations in which firms have received data feeds that were inaccurate. Firms must be familiar with the proficiency of the vendor of the data and its ability to provide data that is accurate as of the time it is presented on the firm's website. **Firms also must understand the criteria followed by vendors in gathering or calculating the types of data that the firm intends to feed into its website, in order to determine whether the vendor is performing this function in a reasonable manner.** Firms also should regularly review aspects of these data feeds for any red flags that indicate that the data may not be accurate, and should promptly take necessary measures to correct any inaccurate data." (emphasis added)
- **What it establishes:** Two things not found elsewhere. (i) The adoption/entanglement test has concrete triggers: **endorsement** on the firm's own site, and **participation in developing** the third party's content. (ii) Where a member ingests a **vendor's data feed**, the member must "understand the **criteria followed by vendors** in gathering or calculating" it — but the obligation is framed entirely as one of **accuracy diligence**, and imposed on the **member**. Nothing suggests that vendor-chosen criteria make either the vendor or the member a recommender.
- **Q1:** SUPPORT — a third occurrence of the vendor-criteria axis being noticed and given a job other than triggering a recommendation (see Answer B).
- **Application note:** The two entanglement triggers are useful and adverse-adjacent: endorsement, and participation in developing the third party's content. The configuration's external-list design has the company neither endorsing nor participating — the member's runtime fetches the publisher's list directly, and the company "never mirrors, caches, relays or re-serves it." Conversely, § 4 shows that where a member does ingest a feed, the diligence burden lands on the **member**, which is consistent with the configuration's allocation.

### S5-19 · FINRA Regulatory Notice 12-29, "Communications With the Public" (SEC approval of new Rule 2210), (Aug 2012) · https://www.finra.org/rules-guidance/notices/12-29 · retrieved 7 Sep 2026
- **Type:** SRO regulatory notice announcing SEC approval of the consolidated communications rules
- **Date / status:** In force; the operative text is now Rule 2210 itself (S5-06).
- **Level 4** — **retrieved and read; contributes nothing to the recommendation line.** Recorded so the check is on the record. Its 19 occurrences of "recommend" concern the communications rules' filing and content requirements, not the definition of a recommendation. No register proposition rests on it.

### S5-20 · FINRA Regulatory Notice 24-09, "FINRA Reminds Members of Regulatory Obligations When Using Generative Artificial Intelligence and Large Language Models" (27 Jun 2024) · https://www.finra.org/rules-guidance/notices/24-09 · retrieved 7 Sep 2026
- **Type:** SRO regulatory notice
- **Date / status:** In force. **The most recent FINRA guidance located on algorithmic output and the communications/supervision rules.**
- **Level 3**
- **Technology neutrality, verbatim:**
> "FINRA reminds its member firms that FINRA's rules–**which are intended to be technology neutral**–and the securities laws more generally, **continue to apply when member firms use Gen AI or similar technologies in the course of their businesses, just as they apply when member firms use any other technology or tool.**" (Summary)
> "FINRA intends for its rules and guidance to be technologically neutral and to function dynamically with evolutions in technology and member firms' processes. The rules apply when member firms use AI, including Gen AI or similar technologies, in the course of their business, just as they apply when member firms use any other technology or tool." (Discussion)
- **⭐ The person/software equivalence, extended to Rule 2210, verbatim:**
> "For example, **FINRA has provided guidance that the content standards of Rule 2210 (Communications with the Public) apply whether member firms' communications are generated by a human or technology tool**, and that guidance discusses the specific application of …" (emphasis added)
- **On the limits of what has been decided, verbatim:**
> "The rules applicable to Gen AI use will depend on how a member firm deploys the technology, and **FINRA will consider issuing further guidance on how particular rules may apply with respect to specific use cases.**"
- **What it establishes:** As of mid-2024 FINRA's position on algorithmic output remains **technology neutrality** plus the human/machine equivalence — the same answer it gave in NTM 01-23 (2001) and RN 11-02 (2011), now extended expressly to Rule 2210's content standards. It announces no new test and defers use-case guidance to the future.
- **Q1:** ADVERSE on the automation point (a fourth independent source for the human/machine equivalence); NEUTRAL otherwise.
- **Application note:** Technology neutrality cuts both ways and should not be reported as purely adverse: it means an algorithm is neither automatically a recommender nor automatically not one. The consequence for this track is that **automation adds nothing to either side of the ledger** — the analysis returns to content, context and manner of presentation, i.e. to 01-23.

### S5-21 · NASAA, Comment Letter to the SEC on File No. S7-10-21 (Digital Engagement Practices), Melanie Senter Lubin, NASAA President, 1 Oct 2021, 7 pp. · https://www.sec.gov/comments/s7-10-21/s71021-9316149-260067.pdf · retrieved 7 Sep 2026
- **Type:** Comment letter from the association of state securities regulators — **advocacy, not law**
- **Date / status:** Filed; final. **Nothing in it was ever adopted** (see S5-22).
- **Level 4 as authority; Level 2 as the fullest articulation anywhere of the maximal position** on exactly this track's question.
- **Access note:** HTTP 200 with a declared-contact User-Agent; **HTTP 403 with a browser User-Agent** — the reverse of the usual pattern. nasaa.org itself is **entirely geo-blocked** (HTTP 403, Sucuri Block ID **GEO02**), so this SEC comment file is the reachable primary source.
- **§ I.3, whose heading is itself the claim — "DEPs That Encourage Trading Should Be Deemed Recommendations", at 3:**
> "**Features such as alerts and top investment lists, especially when foisted onto investors through frequent push notifications, can prompt irrational trading decisions by triggering a false sense of urgency, a sense of excitement, or a 'fear of missing out.'**"
> "Some firms may argue that trading on their applications or platforms is self-directed, and therefore not subject to regulatory safeguards including registrant standards of conduct. **That argument must be challenged directly. Applications or platforms that encourage trading through prompts and 'nudges' are making recommendations, even if they are limited to recommendations simply to trade.** DEPs that constantly pull their customers' attention serve only to urge those customers repeatedly to consider whether they should trade, for whatever reason offered by the DEP feature. **A reasonable person can recognize these prompts as calls to action. Conversely, it is not reasonable to accept that anything but an individualized recommendation to purchase or sell a particular security qualifies as a recommendation.**"
> "For instance, the Commission could clarify that **DEPs that are 'reasonably designed' to affect investor behavior, or that have the effect of doing so, qualify as recommendations. NASAA does not believe that an investor makes an independent investment decision in a non-discretionary or self-directed account when the application or platform on which that account sits encourages the investor to act.**" (emphasis added)
- **On curated lists, at 4:**
> "NASAA also has concerns with '**ideas presented at order placement and other curated lists or features.' These features also constitute advice or recommendations.** Securities should not be marketed and sold to investors as add-on purchases like bags of candy at the check-out stand."
> "**Suggestions to copy the purchases and sales of particular traders or 'finfluencer's' are calls to action either by design or effect and should therefore be deemed recommendations.** The use of social media tools that, for instance, **notify a customer as to 'what your friends have recently purchased'** also have the potential to amplify a herd mentality…"
- **On automation, at 2 (§ I.1):**
> "**In our view, these principles apply regardless of whether a recommendation comes from a person, an algorithm, or some other technology.**"
- **⭐ The authority NASAA relies on, n.5 at 3:**
> "See NASD Notice to Members 01-23 (Apr. 2001) (outlining recommendations as a call to action in a case-by-case inquiry); Frequently Asked Questions on Regulation Best Interest, SEC (Jan. 10, 2020)…"
- **What it establishes:** The maximal position — every push notification, alert, top-investment list, curated list and order-placement "idea" is a recommendation, "even if … limited to recommendations simply to trade," and self-directed status is no answer. **And NASAA grounds it entirely in NTM 01-23**, the same 2001 document that is this track's spine.
- **Q1:** ADVERSE **as advocacy**. It is the theory a state regulator would run. It has no legal force, was not adopted by the Commission, and NASAA's own attempt to enact it by model rule failed (S5-22).
- **Application note:** NASAA's rejection of the narrow reading — "it is not reasonable to accept that **anything but an individualized recommendation** to purchase or sell a particular security qualifies as a recommendation" — is aimed squarely at the position that only personalized, security-specific output counts. That is the position Answer A derives from 01-23. NASAA is arguing against it, which confirms both that the narrow reading is the orthodox one and that state regulators dislike it. Note also that NASAA's own framing would catch the configuration: a timed signal about a specific security is, in its terms, "a call to action … by design or effect."

### S5-22 · NASAA Model Rule, *Dishonest or Unethical Business Practices of Broker-Dealers and Agents* — proposed subpart 1d(5) (5 Sep 2023; re-proposed Nov 2024) **NOT ADOPTED** in the rule as amended **7 April 2025** · retrieved 7 Sep 2026 via exact-timestamp Wayback replay (nasaa.org returns HTTP 403, Sucuri GEO02)
- **Type:** Model rule of an association of state regulators (not binding anywhere until a state adopts it)
- **Date / status:** **The operative provision was dropped.** Proposed 5 Sep 2023 → retained verbatim in the Nov 2024 re-proposal → **absent from the adopted 7 April 2025 text.**
- **Level 2 as a negative finding** — this is the only located instance of any US regulator attempting to answer "what is more?" **by rule**, and it failed.
- **The proposed text, verbatim (proposed subpart 1d(5), 5 Sep 2023; identical at p. 13 of the Nov 2024 redline):**
> "The obligations set forth in this section do not apply to unsolicited transactions that a broker-dealer or agent execute for a customer in a self-directed or nondiscretionary account. **If the broker-dealer or agent utilized any means, method or mechanism to feature or promote an account type, specific security or investment strategy to a retail customer, whether directly or through a third-party, then that transaction will not be deemed an unsolicited transaction, but rather will be deemed a recommendation** to which all of the foregoing obligations set forth in this subsection apply." (emphasis added)
- **The accompanying explanation, verbatim (§ (e)):**
> "With the advent of fintech and proliferation of sophisticated algorithmic digital engagement practices that feed on and cater to the unique personal attributes of individual retail investors … securities regulators are updating their guidance about what qualifies as a recommendation for purposes of Reg BI. **Subpart 1d(5) specifies that the requisite 'call to action' occurs and a 'recommendation' is made where 'broker-dealer or agent utilized any means, method or mechanism to feature or promote an account type, specific security, or investment strategy to a retail customer, whether directly or through a third-party….'**"
- **⭐ The adopted rule (Adopted 23 May 1983; Amended 16 May 2022, **7 April 2025**), 5 pp. — full-text counts: "unsolicited" = 0 · "self-directed" = 0 · "digital" = 0 · "gamif" = 0 · "feature or promote" = 0.** What was adopted is conventional:
> "c. Recommending to a customer the purchase, sale or exchange of any security without reasonable grounds to believe that such transaction or recommendation is suitable for the customer …
> d. When making a recommendation to a retail customer, placing the financial or other interest of the broker-dealer or agent ahead of the interest of the retail customer … or otherwise failing to comply with the obligations set forth in Regulation Best Interest…"
- **What it establishes:** The association of state securities regulators drafted express rule text making **any means, method or mechanism to "feature or promote" a specific security** a recommendation — the precise doctrinal move that would answer this track's question — carried it through a proposal and a re-proposal, and **did not adopt it.** As of 7 September 2026 there is no model rule, and therefore no state rule derived from one, deeming featured or promoted content a recommendation.
- **Q1:** **SUPPORT — strong, and structurally parallel to S5-12.** The same pattern appears twice: a regulator concludes existing law does not reach presentation, proposes a rule that would, and abandons it. The SEC did it federally (PDA proposal, withdrawn June 2025); NASAA did it at state-model level (subpart 1d(5), not adopted April 2025).
- **◇ Caveat, carried honestly:** **no NASAA adopting release, committee report or explanatory statement addressing the removal was located.** nasaa.org is fully geo-blocked and the relevant landing pages have **no Wayback snapshots** (`archived_snapshots: {}`). The *fact* of non-adoption is verified by word-count comparison of the adopted text; the *reason* is unknown, and must not be characterised as a considered rejection of the theory. It may have been dropped for any number of reasons.

### S5-23 · Advisers Act Rule 206(4)-1(e)(8)(ii)(A) and adopting release IA-5653, 86 FR 13024 — **"interactive analysis tools"** · https://www.ecfr.gov/current/title-17/chapter-II/part-275/section-275.206(4)-1 ; https://www.sec.gov/rules/final/2020/ia-5653.pdf · retrieved 7 Sep 2026
- **Type:** Commission rule and adopting release
- **Date / status:** In force. Rule at 86 FR 13142, as amended 87 FR 22447 (Apr 2022); the (e)(8) provisions were **not** touched by that amendment (verified by direct text comparison).
- **Level 2**
- **⚠️ Correction to the commissioning brief:** the tool conditions are **not** in Rule 206(4)-1(d)(6). Paragraph (d)(6) is the *hypothetical performance* condition set. The interactive-analysis-tool provisions sit entirely inside the **definition of "hypothetical performance"** at **(e)(8)(ii)(A)**, with the four conditions at **(e)(8)(ii)(A)(1)–(4)**. There is **no separately defined term "interactive analysis tool"** anywhere in the rule — the definition is embedded in the exclusion. *(Release n.704 cites a "final rule 206(4)-1(e)(8)(iii)" that does not exist in the rule as published; the material it describes is at (e)(8)(i)(C). Recorded as a citation defect in the release, not a substantive point.)*
- **Rule text, verbatim:**
> "**(ii) Hypothetical performance does not include: (A) An interactive analysis tool where a client or investor, or prospective client, or investor, uses the tool to produce simulations and statistical analyses that present the likelihood of various investment outcomes** if certain investments are made or certain investment strategies or styles are undertaken, thereby serving as an additional resource to investors in the evaluation of the potential risks and returns of investment choices; **provided that the investment adviser:**
> **(1)** Provides a description of the criteria and methodology used, including the investment analysis tool's limitations and key assumptions;
> **(2)** Explains that the results may vary with each use and over time;
> **(3)** If applicable, describes the universe of investments considered in the analysis, **explains how the tool determines which investments to select, discloses if the tool favors certain investments and, if so, explains the reason for the selectivity**, and states that other investments not considered may have characteristics similar or superior to those being analyzed; and
> **(4)** Discloses that the tool generates outcomes that are hypothetical in nature" (emphasis added)
- **Answering the brief's question on the adviser side — the conditions attach to the ADVISER, expressly.** The rule says "provided that **the investment adviser**", and IA-5653 repeats the formulation verbatim at 86 FR 13082. The *trigger* attaches to the tool and the investor ("where a client or investor … **uses the tool**"); the *obligations* attach to the adviser. This is the same split as FINRA Rule 2214 (S5-04).
- **IA-5653 at 86 FR 13082 (release pp. 214–216) — the lineage, verbatim:**
> "…we noted that FINRA permits investment analysis tools as a limited exception from FINRA's general prohibition of projections of performance, subject to certain conditions and disclosures … **the final rule will exclude the performance generated by investment analysis tools from the definition of hypothetical performance and will import a definition of 'investment analysis tool' from FINRA Rule 2214 with slight modifications.**"
> "We will adopt this definition, but **will require that a current or prospective investor must use the tool (i.e., input information into the tool or provide information to the adviser to input into the tool).**"
- **The rationale, verbatim — customer operation is the reason for the exclusion:**
> "**We do not view these tools as presenting the same investor risks that model portfolios do because they typically present information about various investment outcomes based on the investor's situation and require the investor to interface directly with the tool.**"
- **⭐ THE SINGLE MOST USEFUL SENTENCE LOCATED ON THE ADVISER SIDE, verbatim:**
> "In providing an interactive analysis tool, an adviser should consider which disclosures are necessary in order to comply with the general prohibitions of the final marketing rule. **For example, to comply with the first general prohibition, the adviser should neither imply nor state that the interactive tool, alone, can determine which securities to buy or sell.**" (emphasis added)
- **On whether each output is itself an advertisement, verbatim:**
> "**The fact that an interactive tool uses the same underlying assumptions does not mean that outputs the tool generates are advertisements (because the adviser or investor inputs investor-specific information).** We believe that there are adequate investor protection guardrails in place to allow advisers to provide interactive analysis tools."
- **The education carve-out, at 86 FR 13082 n.708:**
> "Under the final rule, general educational communications that rely on public information and do not reference specific advisory products or services offered by the adviser would not qualify as advertisements. … For example, the following would not be considered hypothetical performance …: a presentation of performance that illustrates how a portfolio allocated 60% to equities and 40% to bonds would have performed over the past 50 years as compared to a portfolio composed of 40% equities and 60% bonds."
- **Also directly relevant to ranking, Rule 206(4)-1(a)(5)–(6):**
> "(5) Include a reference to specific investment advice provided by the investment adviser where such investment advice is **not presented in a manner that is fair and balanced**; (6) **Include or exclude performance results, or present performance time periods, in a manner that is not fair and balanced**;"
- **What it establishes:** On the adviser side the Commission (i) adopted FINRA's tool regime wholesale, (ii) made **customer operation of the tool** the express reason the output escapes the hypothetical-performance regime, (iii) confirmed that per-investor outputs are **not** each an advertisement, and (iv) drew the line at the adviser implying **"that the interactive tool, alone, can determine which securities to buy or sell."**
- **Q1:** **SUPPORT — the most useful adviser-side text located.** The Commission tells advisers not to *imply* that a tool alone can determine which securities to buy or sell; the prohibition is on the **claim**, and the whole regime presupposes that tools which *do* produce security-level output can lawfully be offered subject to disclosure.
- **Application note:** The configuration's marketing rule ("software tools, never a trading, execution or signal service") sits on the right side of the "neither imply nor state that the interactive tool, alone, can determine which securities to buy or sell" line, and its per-order approval surface is the structural denial of "alone". Note the countervailing point: (e)(8)(ii)(A) is a **definition of hypothetical performance in advertising**, not a definition of advice; nothing here says a tool is not advising. It is favourable on marketing and framing, not on status.

### S5-24 · 17 C.F.R. § 275.203A-2(e)(2) — algorithmic output on supplied personal information **defined as investment advice** · https://www.ecfr.gov/current/title-17/chapter-II/part-275/section-275.203A-2 · retrieved 7 Sep 2026
- **Type:** Commission rule (internet-adviser registration exemption)
- **Date / status:** In force.
- **Level 2**
- **Verbatim:**
> "For purposes of this paragraph (e), 'operational interactive website' means a website, mobile application, or similar digital platform through which the investment adviser provides digital investment advisory services on an ongoing basis to more than one client … For purposes of this rule, '**digital investment advisory service' is investment advice to clients that is generated by the operational interactive website's software-based models, algorithms, or applications based on personal information each client supplies through the operational interactive website.**" (emphasis added)
- **What it establishes:** The clearest Commission **rule text** equating an interactive platform's algorithmic output with **investment advice**. Note the two elements: output generated by **software-based models, algorithms or applications**, and generated **"based on personal information each client supplies."**
- **Q1:** **ADVERSE — and it is the closest rule-level match to the configuration's architecture located in this track.** It is the personalization axis of Answer A, restated as a Commission definition rather than an SRO example.
- **Application note:** This is a definition written **for the purposes of an exemption from the prohibition on state-registered advisers registering federally** — it defines who may use that exemption, not who is an adviser. It does not by its terms extend the Advisers Act to anyone. But its structure is exactly the configuration's: an algorithm producing output from personal information the user supplies. Read with 01-23's "within" example (3) (S5-01) and with *Taucher*'s holding at *475 (P7 register), this is the second independent instance of a US authority treating user-supplied parameters as **no obstacle** to the output being advice. **It should be logged as a material adverse addition to Q1, and it is not distinguished by anything in the configuration.**

### S5-25 · FINRA AWCs in which the app or website presentation itself was the charged communication · retrieved 7 Sep 2026
Four settled matters, none of which turns on a "recommendation" finding. **In all four, the theory is Rule 2210 content standards or Rule 3110 supervision — obligations that do not depend on a recommendation at all.**
- **Stockpile Investments, Inc.**, AWC No. 2022076787601 (29 Sep 2025; censure + $50,000). **The only located matter in which the app interface is expressly enumerated among the "retail communications" subject to Rule 2210.** ◇ **The AWC PDF itself is UNVERIFIED** — ~32 constructed `fda_documents` URL variants all returned HTTP 200 with a Cloudflare interstitial. Text below is from FINRA's own *Disciplinary and Other FINRA Actions*, **November 2025, at 4** (https://www.finra.org/sites/default/files/2025-11/disciplinary-actions-november-2025.pdf, HTTP 200), corroborated by BrokerCheck firm report 156170:
> "…the firm consented to the sanctions and to the entry of findings that it distributed retail communications concerning crypto assets or crypto asset-related services that failed to clearly disclose that crypto assets were not offered through a registered broker-dealer or which did not provide a fair and balanced presentation of the benefits and risks of the products discussed. **The findings stated that the communications included a webpage, email, and the firm's mobile application interface and related promotional materials.**" (emphasis added)
- **Webull Financial LLC**, AWC No. 2021072231801 (accepted 8 May 2025; censure + $1,600,000) · https://www.finra.org/sites/default/files/fda_documents/2021072231801%20Webull%20Financial%20LLC%20CRD%20289063%20AWC%20vr.pdf (HTTP 200). ◇ *Scanned PDF with degraded OCR; `[sic]` marks OCR corruption and exact orthography is UNVERIFIED.* At 9:
> "From May 2019 to September 2023, Webull Financial did not review, approve, or retain its registered representatives' retail communications posted in an onlinc [sic] interactive electronic fomm [forum] **maintained by an affiliate of the finn [firm], which was accessible through the finn's [firm's] mobile application and website.** … **Certain posts contained links to tbe finn's [the firm's] website where users could trade those securities through Webull Financial brokerage accounts.**"
- **Merrill Lynch, Pierce, Fenner & Smith Inc.**, AWC No. 2022073414901 (accepted 18 Jun 2026; censure + $175,000) · https://www.finra.org/sites/default/files/fda_documents/2022073414901%20Merrill%20Lynch%2C%20Pierce%2C%20Fenner%20%26%20Smith%20Incorporated%20CRD%207691%20AWC%20lp.pdf (HTTP 200). **A disclosure duty owed to self-directed customers, with no recommendation alleged**, at 1 and 3:
> "Between January 2021 and September 2023, Merrill Lynch failed to provide material disclosures regarding municipal securities purchased with market discounts for 4,181 transactions **involving 1,072 self-directed customer accounts.**"
> "**The firm's written procedures did not address the firm's obligation to provide time of trade disclosures regarding market discounts to customers who used the firm's self-directed platform.**"
> n.3: "In December 2022, the firm provided a general disclosure to customers on its self-directed platform … **However, this disclosure did not address whether market discounts were applicable to specific securities and was provided for all municipal securities transactions, regardless of whether the security had a market discount.**"
- **Interactive Brokers LLC**, AWC No. 2021071984801 (21 Aug 2025; censure + $650,000) · https://www.finra.org/sites/default/files/fda_documents/2021071984801%20Interactive%20Brokers%20LLC%20CRD%2036418%20AWC%20lp.pdf (HTTP 200). **The only located FINRA definition of "Self-Directed Customers"**, at 1:
> "Between November 2019 and December 2024, Interactive Brokers failed to exercise reasonable due diligence before approving **certain customer accounts that were not managed or advised by financial advisors or other third-parties (Self-Directed Customers)** to trade options."
- **Q1:** MIXED. Stockpile is ADVERSE on framing — the interface is a communication. Merrill is ADVERSE in a distinct and important way: **a platform-wide generic disclosure was insufficient precisely because it was not security-specific**, which cuts against curing anything by a general legend. All four are SUPPORT on the central point that FINRA reaches app presentation **without** finding a recommendation.
- **Application note:** Merrill is the one to carry forward. It establishes that where a duty is owed, a **generic, always-shown, platform-level disclosure does not discharge it** — the disclosure must attach to the specific security. That is the operational form of the disclaimer rule in 01-23 and Rule 2111.02.

### S5-26 · Robert W. Cook (President & CEO, FINRA), *Statement Before the Financial Services Committee, U.S. House of Representatives* (6 May 2021) · https://www.finra.org/media-center/speeches-testimony/statement-financial-services-committee-us-house-representatives · retrieved 7 Sep 2026
- **Type:** Congressional testimony by the SRO's chief executive — **not law, not guidance**
- **Level 4** — cited for the taxonomy and for one footnote that states the boundary plainly.
- **The taxonomy, verbatim:**
> "These features – commonly described as 'gamification' features – include a range of technologies and techniques designed to influence investor behavior, including 'games' at sign-up; social networking tools; streaks with prizes, such as free stock; points, badges and **leaderboards**; and **push notifications.** … Our 2021 Report … cautioned member firms that the use of gamification features must be carefully evaluated to ensure that they meet all applicable regulatory obligations, including, for example, **whether the use of a feature may constitute a 'recommendation' under Reg BI.**"
- **⭐ n.264, verbatim:**
> "**Differences in platform design and the nature of communications may affect whether a firm provides a 'recommendation' for purposes of Reg BI. In the absence of a 'recommendation,' self-directed trading by retail investors does not implicate Reg BI.**" (emphasis added)
- **And expressly assigning the question elsewhere:**
> "These areas include, for example: … and **determining whether certain communications with retail investors constitute recommendations covered by the SEC's Regulation Best Interest (Reg BI).**"
- **What it establishes:** FINRA's chief executive told Congress in 2021 that **platform design may affect whether there is a recommendation**, that absent one Reg BI is not implicated, and that resolving the question is the SEC's to do. It has not been resolved.
- **Q1:** SUPPORT on n.264; NEUTRAL otherwise. Weight is low — testimony, not guidance.

### S5-27 · Washington State — WAC 460-24A-220 and *In re Murakami / GoTradeSignals* · retrieved 7 Sep 2026
**In scope: the technical lead's place of business is Washington State.**
- **WAC 460-24A-220** (Unethical business practices — investment advisers and federal covered advisers; WSR 19-03-133, eff. 18 Feb 2019; in force) · https://app.leg.wa.gov/WAC/default.aspx?cite=460-24A-220
  **Direct answer: it does not address tools.** Full-text search returned **0** hits for screener, alert, app, software, digital, algorithm, gamif, platform.
> Chapeau: "If you are an investment adviser, investment adviser representative, or a federal covered adviser, **you are a fiduciary and have a duty to act primarily for the benefit of your clients.** … you must not engage in dishonest or unethical business practices including, but not limited to, the following:"
> "(1) Recommending to a client … the purchase, sale or exchange of any security **without reasonable grounds to believe that the recommendation is suitable** for the client on the basis of information furnished by the client after reasonable inquiry concerning the client's investment objectives, financial situation and needs…"
> **⭐ "(9) Providing a report or recommendation to any advisory client prepared by someone other than you without disclosing that fact. (This prohibition does not apply to a situation where you use published research reports or statistical analyses to render advice or where you order such a report in the normal course of providing service.)"** (emphasis added)
  *Note (9): a Washington-specific **attribution** rule for third-party output, with an express carve-out for **published research reports or statistical analyses**. It is the closest Washington analogue to the external-list element, and it is a disclosure rule, not a status rule.*
  **Structural note:** WAC 460-21B-060 (BD dishonest practices) and 460-22B-090 (salespersons) were **repealed by WSR 24-19-055, eff. 13 Oct 2024**; the successor chapter is **460-20C**. ◇ **Chapter 460-20C was NOT retrieved** — whether the successor broker-dealer rule addresses digital features is **unknown**.
- ***In re Murakami; GoTradeSignals***, Order No. S-15-1626-15-SC01, Statement of Charges (Wash. DFI Sec. Div., 16 Jun 2016); resolved by Consent Order No. S-15-1626-16-CO01 (7 Mar 2019) · https://dfi.wa.gov/documents/securities-orders/S-15-1626-15-SC01.pdf (HTTP 200)
> "¶5. Between approximately January 2011 and the present, Murakami has published the GoTradeSignals subscription-based newsletter. This newsletter is disseminated by email, and **contains recommendations to buy or sell particular options products.** … Subscribers are charged monthly fees ranging from approximately $99 to $499 per month."
> "¶6. **Murakami promoted auto-trading of the GoTradeSignals newsletter, which resulted in the provision of investment advice for compensation to subscribers.** The majority of GoTradeSignals newsletter subscribers opened auto-traded brokerage accounts. Through this arrangement, Murakami's subscribers authorized their broker to automatically execute trades in their brokerage account using the trade signals contained in Murakami's newsletter."
> "¶7. **By disseminating a subscription-based newsletter with specific trading instructions to investors with auto-traded accounts, GoTradeSignals and Murakami have operated as an unregistered investment adviser and investment adviser representative.**"
> "¶12 (quoting respondent's own site): 'Autotrade with GoTradeSignals. Autotrading provides hands free trading to our subscribers with a **direct connection between GoTradeSignals' trading technology and the subscriber's broker.**'"
- **What it establishes:** Washington's own securities division has charged a **subscription trading-signal service** as an unregistered investment adviser, on facts combining (i) a flat periodic subscription fee, (ii) signals identifying particular instruments and side, and (iii) **auto-trading through a direct connection to the subscriber's broker**.
- **Q1:** **ADVERSE — and it is Washington, which is in scope.** This is the closest state analogue to the configuration's genus located in this track.
- **Application note:** The distinguishing facts are real but must be stated precisely. *GoTradeSignals* rested on **auto-trading with no per-order human act** ("hands free trading", "automatically execute"), which is the opposite of the configuration's one-tap approval surface and its express exclusion of standing execution from V1. But ¶5 and ¶7 rest on the **newsletter's content** — "recommendations to buy or sell particular options products", "specific trading instructions" — and the charge is framed as "disseminating a subscription-based newsletter with specific trading instructions **to investors with auto-traded accounts**", which couples the two. **Nothing in the order says which element was load-bearing**, and it was resolved by consent, so nothing was adjudicated. ◇ The Consent Order (S-15-1626-16-CO01) was retrieved (HTTP 200, 475 lines) but **no operative paragraph was pin-cite quoted — UNVERIFIED**; it should be read before this entry is relied on.

### S5-28 · SEC adviser-side enforcement and staff guidance treating tool output as the advice · retrieved 7 Sep 2026
- ***In re Global Predictions, Inc.***, Advisers Act Rel. No. **6574**, AP File No. 3-21895 (18 Mar 2024; settled) · https://www.sec.gov/files/litigation/admin/2024/ia-6574.pdf — **the closest fit located**:
> "¶2. Global Predictions registered with the Commission as an internet investment adviser pursuant to Rule 203A-2 … It states that it provides non-discretionary investment advice for compensation to retail clients **through its website application, PortfolioPilot.com**"
> "¶3. …Global Predictions offers investment advisory services through PortfolioPilot, **an interactive online platform, which makes investment allocation recommendations to clients. According to the Form ADV brochure, PortfolioPilot makes allocation recommendations utilizing algorithms.** PortfolioPilot allows clients to interface with its platform using a chatbot that communicates allocation recommendations, but the chatbot does not generate allocation recommendations."
> "¶6. Global Predictions also represented on its public website **a demonstrative graphic of its user interface including hypothetical performance that was not based on actual client data**…"
  *The Commission describes the platform's algorithmic output as "the allocation recommendations," and treats a screenshot of the tool's own UI as an advertisement containing hypothetical performance. Note: the respondent had **registered as an adviser**; status was not contested.*
- **SEC Division of Investment Management, IM Guidance Update No. 2017-02, "Robo-Advisers" (Feb 2017)** · https://www.sec.gov/investment/im-guidance-2017-02.pdf — **staff guidance; expressly no legal force or effect**:
> at 1: "A client that wishes to utilize a robo-adviser enters personal information and other data into an interactive, digital platform … **Based on such information, the robo-adviser generates a portfolio for the client** and subsequently manages the client's account."
> at 6: "**We have observed that robo-advisers may provide investment advice based primarily, if not solely, on client responses to online questionnaires.** … Given this limited interaction, when considering whether its questionnaire is designed to elicit sufficient information to support its suitability obligation, a robo-adviser may wish to consider … **[w]hether the questions elicit sufficient information to allow the robo-adviser to conclude that its initial recommendations and ongoing investment advice are suitable and appropriate** for that client…"
- **Also retrieved and read, contributing little:** *In re Delphia (USA) Inc.*, IA-6573 (18 Mar 2024) (Form ADV claims about advice "powered by" connected accounts and questionnaire responses); *In re Wealthfront Advisers LLC*, IA-5086 (21 Dec 2018) (**advertising case about statements *describing* software behaviour — no language treating tool output as itself advice**); *In re Hedgeable, Inc.*, IA-5087 (21 Dec 2018) (a self-created "Robo-Index" **ranking** published on a website, treated as an **advertisement**, not a recommendation); *In re Charles Schwab & Co.*, 34-95087 / IA-6047 (13 Jun 2022, $187m) (cash allocations "pre-set in order to reach minimum revenue targets"; **the word "questionnaire" appears 0 times**).
- **Q1:** ADVERSE, with a consistent limit: in every one of these the respondent was **already a registered investment adviser**, and status was never contested. They show the Commission comfortably describing algorithmic output as "recommendations" and "advice" — but none decides whether producing such output *makes* someone an adviser.
- **Application note:** Read with S5-24, the adviser-side pattern is consistent: where personal information goes in and security- or allocation-level output comes out, the Commission calls the output advice without argument. That is the same axis as 01-23's "within" example (3). **No located SEC action addresses a vendor that is not a registered adviser**, which is the gap this configuration sits in.

---

## The Massachusetts / Robinhood matter (S5-29 → S5-33)

**Scope note.** P8's scope is US federal law plus Washington State. Massachusetts is included because this brief expressly directed it. Nothing below binds outside Massachusetts, and the Consent Order binds nobody but Robinhood. It is nevertheless **the only place in the located material where a regulator litigated curated lists, rankings, push notifications and gamification as recommendations** — which is why it matters, and also why its outcome matters so much.

**Four corrections to the commissioning brief's premises, each verified against primary text:**
1. The SJC decided **25 August 2023**, not 2024. Cite is **492 Mass. 696**, SJC-13381 (argued 3 May 2023; rescript 22 Sep 2023).
2. The brief says "the rule was struck down and then appealed." Correct — but the appeal **REVERSED**: the rule was **upheld**, not struck down on appeal.
3. The rule took effect **6 March 2020** (Mass. Register Issue 1412), not 8 March; enforced from 1 September 2020.
4. 950 CMR **12.205 was NOT amended** in the rulemaking — the adopting release says so in terms. The implementing hooks are 12.204(1)(a)4. and 12.204(1)(a)29.

### S5-29 · *In the Matter of Robinhood Financial, LLC*, Administrative Complaint, Docket No. E-2020-0047 (Mass. Sec. Div., Enforcement Section, 16 Dec 2020); **Amended Administrative Complaint** (21 Oct 2021) · https://www.sec.state.ma.us/divisions/securities/download/MSD-Robinhood-Financial-LLC-Complaint-E-2020-0047.pdf and …/MSD-Robinhood-Amended-Complaint-Docket%20No-%20E-2020-0047.pdf · retrieved 7 Sep 2026
- **Type:** State administrative complaint — **an allegation, never adjudicated**
- **Date / status:** Superseded by the Amended Complaint; the proceeding was **settled with prejudice** by Consent Order in January 2024 (S5-30). **No finding of fact was ever entered on any of it.**
- **Level 4 as authority** (a pleading proves nothing) — **Level 2 as the only articulated regulatory theory of UI-as-recommendation in existence.**
- **THE CENTRAL PASSAGE — the list-as-recommendation analogy (Summary § II, at 4–5; identical in both versions):**
> "In an effort to encourage trading, Robinhood provides lists of securities on its application, including lists of the most-traded securities on Robinhood's platform and the most popular securities traded by Robinhood customers. **This is no different from a broker-dealer agent handing a list of securities to a customer, pretending to be surprised when the customer purchases securities from that list, and then proclaiming that he made no recommendations to the customer.**" (emphasis added)
- **The lists, § VI.D — heading verbatim:** "**D. Robinhood Provides Lists to Encourage Customers to Purchase Securities Without any Consideration of Suitability**"
> "¶35 [amended]. Robinhood's application includes a 'first list' that includes stocks 'chosen based on their popularity on Robinhood's platform.' This list is provided on the home screen of the application and is one of the first items that a new customer sees."
> "¶36. Robinhood's application provides a section titled 'Popular Lists' … **(1) 100 Most Popular; (2) Top Movers;** (3) Technology; … (30) Banking."
> "¶37. The lists have the potential to influence the securities that new, unsophisticated customers with no investment experience purchase."
> "¶38. **Despite providing these lists to all customers by default**, Robinhood does not conduct a suitability analysis of the securities contained in the lists for customers." (emphasis added)
> "¶40. By promoting securities through the use of lists without conducting suitability analyses for customers, Robinhood encouraged risky, unsuitable trading …"
- **Push notifications, ¶¶49–52 (amended):**
> "¶50. Customers receive **daily** push notifications regarding the change in value of stocks in their accounts."
> "¶51. A customer that has not yet traded in their account may receive a push notification that states: '**Top Movers: Choosing stocks is hard. [flexing bicep emoji] Get started by checking which stock prices are changing the most.**' Upon clicking on the push notification, the customer redirects to the aforementioned Top Movers list."
> "¶52. Customers may also receive a push notification that states, '**Popular Stocks: Can't decide which stocks to buy? [thinking emoji] Check out the most popular stocks on Robinhood.**' Upon clicking on the push notification, the customer redirects to the aforementioned 100 Most Popular list."
- **Gamification, ¶¶41–48 (amended):**
> "¶42. **Each time a customer makes a trade on Robinhood's platform, confetti rains down on the screen of the application**, instilling a sense of celebration and accomplishment as a result of simply buying or selling securities."
> "¶45. Robinhood provided customers with the ability to improve their position on the early access waitlist by '**tapping**' a fake debit card displayed in the application **up to 1,000 times per day** …"
> "¶46. … '**out of taps today! Come back tomorrow if you're feeling tappy.**'"
- **The fiduciary conversion, § VI.H — the load-bearing paragraphs:**
> "¶90. **By providing lists to encourage customers to purchase securities without any consideration of suitability, Robinhood failed to consider the investment experience or objectives of its customers.**"
> "¶91. **By employing a number of strategies to encourage and incentivize customers to engage continuously and repeatedly with the Robinhood application, Robinhood facilitated frequent, risky, and unsuitable trading in Massachusetts customer accounts.**" (emphasis added)
- **Counts:** Count I — M.G.L. c. 110A § 204(a)(2)(G) (unethical or dishonest conduct). **Count II — the 950 CMR 12.207 fiduciary count.** Count III — § 204(a)(2)(J) (failure to supervise). *Hold that structure: the Consent Order keeps I and III and drops II.*
- **What it establishes:** The only fully articulated regulatory theory located anywhere that curated lists, rankings, "top movers", "most popular" and list-linked push notifications are, in combination, tantamount to recommendations. It rests on an **analogy**, not a test.
- **Q1:** ADVERSE **as a theory**; of no weight as authority.
- **Application note:** Two allegations in ¶¶37–38 are the ones that transfer: that lists "have the potential to influence" what inexperienced customers buy (which is 01-23's "reasonably would influence" factor and the DEP release's Q 3.6 behavioural test), and that they were provided "**to all customers by default**" — the vendor-set default. The configuration has no lists, no defaults (fields start empty; "no presets, no imports, no 'most users choose'"), and no highlighting. But its signal *is* a specific instrument surfaced to the member, which is the thing the analogy attacks.
- **Two negative findings recorded here so they are not later assumed:** (i) **"People also bought" appears in none of the primary documents** — the complaints, the Consent Order, the SJC opinion, the Superior Court decision, the FINRA AWCs or the SEC order: **0 hits across all of them**. Massachusetts framed social proof as *popularity / most-traded*, never as peer-purchase. (ii) **No count or frequency of push notifications is alleged anywhere.** The only frequency word is "daily" (¶50). What the Division quantified was *trading* volume, not notification volume. Any "N notifications sent" figure is **not from this record** and must be treated as UNVERIFIED.

### S5-30 · *In the Matter of Robinhood Financial LLC*, **Consent Order**, Docket Nos. E-2020-0047 and E-2022-0006 (Mass. Sec. Div., on or about 18 Jan 2024) · https://www.sec.state.ma.us/divisions/securities/download/RH-Consent-Order.pdf · retrieved 7 Sep 2026
- **Type:** State administrative consent order (settlement; no adjudication)
- **Date / status:** **Final; settles E-2020-0047 with prejudice.** Robinhood "**neither admits nor denies**" the UI/gamification allegations (Section VI(A)); it admits only the separate cybersecurity allegations (Section VI(B)). Exact day is **handwritten and OCR-illegible**; bracketed by the Offer of Settlement (17 Jan 2024), the PDF CreationDate (18 Jan 2024) and the first Wayback capture (22 Jan 2024) — **the precise day is UNVERIFIED**.
- **Level 3** — a negotiated outcome, not a holding, but it is the only *disposition* in existence.
- **⭐ THE DECISIVE FINDING FOR THIS TRACK — the fiduciary/recommendation theory was abandoned.** Verified occurrence counts across the full 26-page order: **"fiduciary" = 0 · "950 CMR 12.207" = 0 · "best interest" = 0 · "solicit" = 0.** "recommend*" appears 11 times and **not once in the securities sense** — every instance is either the customer-referral program, the FINRA/anti-phishing context, or the independent-consultant undertakings ("make recommendations concerning…"). Section VII contains **two** counts, not three: Count I under § 204(a)(2)(G) now hooked to **950 CMR 12.204** ("high standards of commercial honor and just and equitable principles of trade"), and Count II under § 204(a)(2)(J) (failure to supervise). **The complaint's 12.207 fiduciary count was not carried into the settlement.**
- **The features restated as a SUPERVISION failure — ¶31, verbatim chapeau:**
> "Prior to the Complaint, Robinhood developed digital engagement features and prompts, **but did not implement procedures reasonably designed to supervise these features and prompts in a manner necessary to protect customers in Massachusetts**, including the supervision of: i. A 'First List' that includes stocks 'chosen based on their popularity on Robinhood's platform' … ii. A section titled 'Popular Lists' … such as the '100 Most Popular' list; iii. Push notifications … iv. [the Top Movers notification] … v. [the Popular Stocks notification] … vi. **Digital confetti raining down from the top of the screen after a customer's first trade**; vii. An offer of free stock rewards … required customers to **mimic the motion of 'scratching off' a lottery ticket** … viii. The ability … to improve their position on an early access waitlist by 'tapping' …" (emphasis added)
*The wrong has moved from the feature to the governance of the feature. Note also the narrowing at ¶31(vi): the Order says confetti appeared "after a customer's **first** trade," where the complaint alleged "**each time**."*
- **⭐ THE REMEDY — § VIII ¶ C, verbatim. This is the most operationally useful text in the whole track:**
> "For Massachusetts customers, Robinhood shall:
> **a. Add disclosures to lists on its platform that are based on Robinhood data** … **indicating that the list is based on Robinhood data and not directly related to overall market data**;
> **b. Remove all emojis from the life-cycle of a transaction**;
> c. Permanently cease the future use of any **waitlist tapping feature** …;
> **d. Permanently cease the future use of confetti … or other celebratory imagery directly tied to frequency of trading**;
> **e. Permanently cease the future use of generalized push notifications highlighting specific lists** …; and
> f. Permanently cease **features that mimic games of chance** …" (emphasis added)
- **Remediation already taken, ¶32:** confetti ceased **31 Mar 2021**; scratch-off ceased **5 Apr 2021**; waitlist tapping ceased; the list-linked push notifications ceased **January 2022**.
- **Fine:** $7,500,000. **No restitution, no disgorgement, and no registration revocation** — items E, F and K of the prayer for relief were not obtained.
- **What it establishes:** A regulator that pleaded lists-as-recommendations settled without the recommendation theory, and framed the surviving remedy in three telling ways: a curated list is curable by **provenance disclosure** (¶C(a) — the list may stay if the customer is told it reflects the firm's own data, not the market); celebratory imagery is barred only where **"directly tied to frequency of trading"** (¶C(d) — a causal-nexus test, not an aesthetic ban); and what is prohibited outright is a **push notification that highlights a specific list** (¶C(e)) — push plus highlighting plus narrowing, the three features combined.
- **Q1:** **SUPPORT, on the disposition** — the fiduciary/recommendation theory was pleaded and then dropped. **ADVERSE, on the remedy's premises** — a state regulator obtained a permanent bar on list-highlighting push notifications without ever having to prove they were recommendations, via supervision and commercial-honor hooks instead.
- **Application note:** ¶C(a) is the closest thing located anywhere to a **cure by attribution**: label the list with whose data it reflects. That maps onto the configuration's separate-attribution requirement for external sources. ¶C(d)'s "directly tied to frequency of trading" is a nexus test the configuration would satisfy trivially (no celebration of any kind). ¶C(e) is the one that bites hardest on any push-notification design.

### S5-31 · *Robinhood Financial LLC v. Secretary of the Commonwealth & another*, **492 Mass. 696** (2023), SJC-13381 (argued 3 May 2023; decided **25 Aug 2023**; rescript 22 Sep 2023) · slip op. at https://storage.courtlistener.com/pdf/2023/08/25/robinhood_financial_llc_v._secretary_of_the_commonwealth.pdf · retrieved 7 Sep 2026
- **Type:** State supreme court opinion (Wendlandt, J.)
- **Date / status:** **GOOD LAW.** Reverses *Robinhood Fin., LLC v. Galvin*, Suffolk Sup. Ct. No. 2184CV00884 (Ricciuti, J., Memorandum of Decision 30 Mar 2022; final Judgment entered 18 Aug 2022), which had declared 950 CMR 12.207(1)(a), 12.204(1)(a)(4) and 12.204(1)(a)(29) unlawful. **That judgment is reversed and has no legal effect.** **No petition for certiorari was ever filed** — U.S. Supreme Court docket **23A416** shows only an application to extend time, granted by Justice Jackson to 22 Jan 2024, with an empty `RelatedCaseNumber` field on a docket regenerated 11 Aug 2025; Robinhood submitted its Offer of Settlement to Massachusetts on 17 Jan 2024, five days before the deadline.
- **Level 2** — a state supreme court holding, binding in Massachusetts only, and on the *validity* of the rule rather than its application.
- **The holding, verbatim:**
> "This case concerns the question whether, by promulgating the fiduciary duty rule, the Secretary overstepped the bounds of the authority granted to him under MUSA. **We conclude that he did not.** We further conclude that the fiduciary duty rule does not override the common-law protections available to investors, that MUSA is not an impermissible delegation of legislative power, and that **the rule is not preempted** by … Regulation Best Interest. **We therefore reverse the judgment entered by a Superior Court judge … and we remand the matter for further proceedings.**"
- **⭐ n.5 — how the SJC characterised the Division's UI theory, verbatim:**
> "The Secretary claimed that Robinhood encouraged 'frequent, risky, and unsuitable trading' by '[i]nexperienced [i]nvestors,' **published investment categories like '100 Most Popular' or 'Top Movers,'** and implemented '[s]trategies to [e]ncourage and [i]ncentivize' customer engagement with its trading platform; **each such practice, the Secretary alleged, was tantamount to making investment recommendations to customers.**" (emphasis added)
- **⭐ The body at 4–5, and n.7 — THE COURT EXPRESSLY DECLINED TO DECIDE IT:**
> "In particular, the Secretary alleged that **Robinhood provided investment recommendations to its Internet-based customers** without considering whether those recommendations were in each customer's best interest … **Robinhood denies the allegations, maintaining that, as a 'self-directed' brokerage firm, it does not make investment recommendations or provide investment advice.**"
> "⁷ **We address only the purely legal issues presented on appeal, which are unaffected by this dispute of material fact.**" (emphasis added)
- **Reg BI as a floor, at 46–47, verbatim:**
> "… we conclude that **the Regulation Best Interest constitutes a regulatory floor that does not foreclose State regulation to more clearly protect investors.** … **Robinhood has not met its high burden to demonstrate otherwise.**"
- **On the Secretary's rulemaking authority:**
> "**MUSA authorizes the Secretary to define the phrase 'unethical or dishonest conduct or practices,' so long as he does so consistent with the purpose of MUSA to protect investors; his determination that the fiduciary duty rule was necessary for that purpose is owed deference**, where, as here, the conclusion is supported by the extensive regulatory record."
> "… where broker-dealers **have themselves adopted new business models inconsistent with their traditional roles and prior industry norms**, to carry out his charge under MUSA to protect investors …"
- **What it establishes:** A state may validly write a rule under which the UI-as-recommendation question is *litigable*, and Reg BI does not preempt it. **The substantive question — whether lists, rankings and push notifications are recommendations — was expressly classified as a disputed question of material fact and remanded.** It was then settled away (S5-30). **No tribunal anywhere has ever decided it.**
- **Q1:** MIXED. **SUPPORT** in that the highest court to consider the question refused to hold that curated lists and gamification are recommendations, and recorded the self-directed firm's denial without disturbing it. **ADVERSE** in that it confirms a state regulator has authority to define the standard of conduct more broadly than Reg BI, and that Reg BI is a floor — so federal analysis does not exhaust the question in any state.
- **Application note:** n.7 is the single most important sentence in the Massachusetts record for this track. It means the whole Robinhood episode — the most prominent attack ever mounted on UI-as-recommendation — produced **no holding on the merits**. It is a live theory that has never been tested.

### S5-32 · 950 CMR 12.207, *Fiduciary Duty of Broker-dealers and Agents* (eff. 6 Mar 2020; enforced from 1 Sep 2020) · Mass. Register Issue 1412 · retrieved 7 Sep 2026
- **Type:** State regulation, promulgated under M.G.L. c. 110A § 412(a)
- **Date / status as of 7 September 2026: IN FORCE, unamended since adoption, judicially upheld.** Establishing document: the official codified CMR chapter PDF at mass.gov, whose Wayback CDX **SHA-1 digest is byte-identical (`L57L36JBLVURZ52WQ54MMXIYQUQJDDAR`) across six captures from 20 May 2024 through 14 February 2026**. Corroborated by mass.gov regulation-page metadata ("Date: 03/06/2020", captured 10 Apr 2026), by Cornell LII ("Adopted by Mass Register Issue 1412, eff. 3/6/2020" — a single entry, "No prior version found"), and by the Division's own fiduciary-rule page (captured 20 Feb 2026). Not vacated (the Superior Court judgment was reversed); not amended; not superseded (Reg BI is a floor).
- **Level 2** (Massachusetts only)
- **Operative text, verbatim:**
> "**(1)** The following practices are a non-exclusive list of practices by a broker-dealer or agent which shall be deemed 'unethical or dishonest conduct or practices' for purposes of M.G.L. c. 110A, § 204(a)(2)(G): **(a)** Failing to act in accordance with a fiduciary duty to a customer **when providing investment advice or recommending an investment strategy, the opening of or transferring of assets to any type of account, or the purchase, sale, or exchange of any security.**"
> "**(2)(a)** The **duty of care** requires a broker-dealer or agent to use the care, skill, prudence, and diligence that a person acting in a like capacity and familiar with such matters would use … [including] 1. The risks, costs, and conflicts of interest related to all recommendations made and investment advice given; 2. The customer's investment objectives, risk tolerance, financial situation, and needs; and 3. Any other relevant information."
> "**(2)(b)** The **duty of loyalty** requires a broker-dealer or agent to: 1. Disclose all material conflicts of interest; 2. Make all reasonably practicable efforts to avoid conflicts of interest …; and **3. Make recommendations and provide investment advice without regard to the financial or any other interest of any party other than the customer.**"
> "**(2)(c) Disclosing conflicts alone does not meet or demonstrate the duty of loyalty.**"
> "**(2)(d)** It shall be **presumed to constitute a breach of the duty of loyalty** for a broker-dealer or agent to recommend any investment strategy … **if the recommendation is made in connection with any sales contest.**"
> "**(3)** … the term '**customer**' shall include **current and prospective customers** …"
> "**(6)** 950 CMR 12.207 shall be enforced as of September 1, 2020."
- **The duration limit, from the Division's Adopting Release (21 Feb 2020) at 2–3, verbatim:**
> "In Section 12.207(1)(a) of the Final Regulations, **the duty runs during the period in which incidental advice is made in connection with the recommendation of a security to the customer. The duty has not been deemed to be ongoing except as set out in Section 12.207(1)(b) of the Final Regulations.**"
- **The Division's own FAQ on unsolicited trades, verbatim:**
> "**Are unsolicited trades subject to the fiduciary conduct standard?** The fiduciary conduct standard applies **in connection with recommendations or advice provided by a broker-dealer**. Activities of a broker-dealer in connection with unsolicited trades will be subject to applicable federal and state conduct rules"
- **⭐ NEGATIVE FINDING — the trigger term is undefined.** Exhaustive search of the complete official 950 CMR 12.200 chapter (1,593 extracted lines): **there is no definition of "recommendation," "recommend," "investment strategy," "investment advice" or "advice" anywhere in the chapter** — not in 12.207, not in 12.204, not in 12.205. The only definition inside 12.207 is the *negative* definition of "customer" at 12.207(3).
- **What it establishes:** The most aggressive state standard of conduct in the country turns on an undefined trigger — "when providing investment advice or recommending." That is exactly why Robinhood could maintain it made no recommendations, and exactly why the SJC classified the question as one of fact.
- **Q1:** ADVERSE in Massachusetts; NEUTRAL federally.
- **Application note:** The duty attaches only "in connection with the recommendation of a security," is not ongoing, and by the Division's own FAQ does not reach unsolicited trades. Everything therefore turns on the undefined word — and Massachusetts has never obtained a ruling on it.
- **◇ Currency caveat, carried honestly:** the freshest direct evidence of the rule's state is 14 Feb 2026 (byte-identical official PDF), 20 Feb 2026 (Division FAQ) and 10 Apr 2026 (mass.gov metadata). mass.gov and sec.state.ma.us both block programmatic access (Akamai / Incapsula), and the Massachusetts Register is subscription-gated, so **the live position on 7 September 2026 could not be verified directly and Register issues could not be searched at all.** Nothing suggests a change in the five-month gap, but if this becomes load-bearing it needs a human with a browser.

### S5-33 · The federal and SRO Robinhood actions — **none of them reached UI presentation**
Three separate proceedings against the same firm on overlapping facts, each searched in full. All three are recorded here because their **silence** is the finding.
- **FINRA AWC No. 2020066971201** (accepted 30 Jun 2021; censure, **$57m fine + $12.6m restitution**) · https://www.finra.org/sites/default/files/2021-06/robinhood-financial-awc-063021.pdf (direct fetch HTTP 403; retrieved via Wayback capture 20260225190341) · retrieved 7 Sep 2026.
  **Verified counts across the full document: "gamif" = 0 · "confetti" = 0 · "presentation" = 0.** "recommend" appears 6 times, **every one** inside the independent-consultant undertakings. "suitab" appears 4 times, all about customers giving *false suitability information* on options applications. The interface is mentioned once, as marketing background: *"a user interface 'designed to … appeal to a new generation of investors who are more comfortable trading on smartphones.'"* All ~30 uses of "display" concern **data accuracy** (*"Robinhood displayed to many customers negative cash balances that were twice as large as they actually were"*), not persuasive design. The options-approval finding is framed as supervision: *"in practice, the firm relies on computer algorithms, with limited oversight by firm principals … known by Robinhood as 'option account approval bots' … because the bots do not take into account all information available to the firm, Robinhood has routinely approved customers for options trading who did not meet the firm's eligibility criteria."* **Notably, FINRA charged the free-stock scratch-off as a misleading advertisement under Rule 2210 — the same feature Massachusetts charged as gamification.** Same facts, two theories, and FINRA chose the disclosure theory.
- **SEC Rel. Nos. 33-10906 / 34-90694**, Admin. Proc. File No. 3-20171 (17 Dec 2020; **$65m penalty**) · https://www.sec.gov/files/litigation/admin/2020/33-10906.pdf · retrieved 7 Sep 2026.
  **Verified counts: "gamif" = 0 · "confetti" = 0 · "user interface" = 0 · "notification" = 0 · "digital engagement" = 0 · "suitab" = 0.** "recommend" appears 12 times, all in the consultant undertakings. This is a payment-for-order-flow and best-execution matter. The only "presentation" it reaches is the truthfulness of a website FAQ — a disclosure-accuracy theory, orthogonal to the recommendation question.
- **FINRA AWC No. 2019060756501** (Robinhood Financial LLC and Robinhood Securities LLC, signed 6 Mar 2025) · https://www.finra.org/sites/default/files/2025-03/robinhood-AWC-030725.pdf (direct HTTP 403; via Wayback capture 20260803160427) · retrieved 7 Sep 2026. **The most recent FINRA action located; nothing later through September 2026.**
  Its presentation-adjacent count concerns **paid influencers**: *"From November 2019 through March 2023, RHF paid certain influencers who promoted the firm in social media communications … approximately 75 influencers at least $2.7 million."* → *"**Influencers' posts promoting RHF were retail communications of RHF subject to FINRA Rule 2210.**"* → the posts were *"exaggerated, promissory, and not fair and balanced."* This is attribution-of-third-party-content plus supervision, consistent with RN 17-18 (S5-16). **It does not turn on "recommendation."**
- **What all three establish:** Both federal regulators had the same firm, the same period and the same app in front of them, imposed $122.5m in combined sanctions, and **neither ever charged the interface as making recommendations.** Each chose a theory it could prove — disclosure accuracy, best execution, supervision, advertising content.
- **Q1:** SUPPORT — a documented, quantified federal silence on the precise question, on the most-scrutinised retail interface in the market.
- **Application note:** This is a genuine negative finding with the counts to back it, not an inference from absence. It should be read with N2 and with S5-12: the federal regulators declined to charge presentation as recommendation, the Commission then proposed a rule that would have reached presentation without needing the recommendation element, and it withdrew that rule in June 2025.

---

---

## Enforcement and adjudication on the recommendation element (S5-34 → S5-37)

### S5-34 · ★ *In re David Lerner Associates, Inc.*, Exchange Act Release No. **105556**, Admin. Proc. File No. 3-22645 (SEC, **27 May 2026**) · https://www.sec.gov/files/litigation/admin/2026/34-105556.pdf · retrieved 7 Sep 2026
- **Type:** SEC settled administrative and cease-and-desist proceeding — **Commission findings made on an Offer of Settlement**, expressly "not binding on any other person or entity" (Order n.1). **Not a litigated holding.**
- **Date / status:** Final. **This is the single most important authority located in the entire track, and it did not exist when the shared context was written.**
- **Independently re-verified at source by me, not taken on report:** fetched HTTP 200, 238,302 bytes; caption reads "SECURITIES EXCHANGE ACT OF 1934 / Release No. 105556 / May 27, 2026 / ADMINISTRATIVE PROCEEDING / File No. 3-22645 / In the Matter of DAVID LERNER ASSOCIATES, INC. / ORDER INSTITUTING ADMINISTRATIVE AND CEASE-AND-DESIST PROCEEDINGS PURSUANT TO SECTIONS 15(b)(4) AND 21C OF THE SECURITIES EXCHANGE ACT…". Paragraphs 20, 27 and 33 checked word-for-word against the PDF text layer.
- **Level 1** — the only located matter in which a regulator applied the 01-23 / Reg BI framework to a **standardized, firm-designed template document listing securities**, where the respondent **expressly contested** the recommendation element and **disclaimers were held not to cure**.
- **What the communication was:** a **three-page, firm-designed template** ("Customized Investment Plan" / CIP), pre-populated for a named customer, listing **three to five specific securities** with dollar amounts, share counts, price per share and estimated distribution, plus a pie chart and a bar chart.
- **⭐ The operative finding, verbatim (¶¶ 32–33):**
> "32. '[T]he determination of whether a broker-dealer has made a recommendation that triggers application of' Regulation BI 'turn[s] on the facts and circumstances of the particular situation' and 'is not susceptible to a bright line definition.' … Relevant factors include 'whether the communication "reasonably could be viewed as a 'call to action'" and "reasonably would influence an investor to trade a particular security or group of securities."' Id. 'The more individually tailored the communication to a specific customer or a targeted group of customers about a security or group of securities, the greater the likelihood that the communication may [be] viewed as a "recommendation."' Id. …
> **33. CIPs are 'recommendations' under Regulation BI because they are 'individually tailored . . . to a specific customer,' "'reasonably would influence an investor to trade a particular security or group of securities,'" and "'reasonably could be viewed as a "call to action."'" Id. at 33335.**"
- **⭐ The element was actually contested, verbatim (¶¶ 24–26):**
> "24. … **DLA took the position that CIPs were not 'recommendations' and, therefore, were not subject to Regulation BI.** For the same reason, DLA did not make any changes to its CIP Policy in response to Regulation BI. **Notwithstanding its position that CIPs were not recommendations, DLA trained its registered representatives to use CIPs to persuade prospective and existing retail customers to make the investments listed therein.**
> 25. From January 2021 until March 2022, the Commission's Division of Examinations examined DLA and identified several Regulation BI deficiencies … **the Deficiency Letter cited DLA for failing to treat CIPs as recommendations** …
> 26. After receiving the Deficiency Letter, **DLA maintained its position that CIPs were not recommendations** under Regulation BI and did not make any changes to its CIP Policy or Regulation BI Policy." (emphasis added)
- **⭐ THE DISCLAIMER FINDING — the strongest located anywhere, verbatim (¶ 27):**
> "27. DLA did, however, make certain changes to the CIP template in November 2022. On the cover page, DLA added a footer about investments carrying risk, that past performance does not guarantee future results, and to read prospectuses before investing. … [DLA] changed the final sentence in the opening paragraph from '**We have prepared these suggested investments for your consideration**' to '**We have prepared these examples of potential investments for your consideration**.' Lastly, on the third page, DLA added … certain disclosures, including that '[t]he potential investments listed above are **examples of the types of products** [DLA] has available to help you achieve your investment goals,' '**for illustrative purposes only**,' and 'based on information currently provided by you to DLA including, but not limited to, your investment objective(s), risk tolerance, time horizon and liquidity needs,' and that 'your DLA [registered representative] will gather additional information, as needed, from you to ultimately insure that any potential recommendations are in your best interests.' **These changes to the CIP template did not alter that the CIPs were recommendations.**" (emphasis added)
- **The pre-existing disclaimers, which also did not cure, verbatim (¶ 21):**
> "21. The third and last page of each CIP contained certain disclosures, including that the CIP '**is not an offer to purchase securities**,' '[e]xact investments recommended **can only be determined when we learn more** about your financial goals and objectives,' and '**neither DLA, nor its [registered representatives], are acting as fiduciaries** in connection with this proposed investment plan.'"
- **The number of items, verbatim (¶ 20):**
> "20. Below the opening paragraph, the CIP then presented a table detailing a set of suggested investments, including, for each suggested investment, the name of the security, a specific amount to invest, the number of shares that would be purchased for that investment amount, the price per share, and the estimated distribution. **Each CIP typically listed potential investments in three to five specific securities, generally including at least one DLA proprietary product.**"
- **Scale and conversion, verbatim (¶ 28):**
> "28. Between June 30, 2020 and September 15, 2024, DLA registered representatives prepared, and branch managers approved, approximately **2,500 CIPs** for retail customers. **Within thirty days of being presented with a CIP, hundreds of retail customers purchased some or all of the investments listed in the CIP.** In the aggregate, these purchases totaled approximately **$78 million**, generating approximately $2.5 million in transaction fees…"
- **The remediation, verbatim (¶ 29):**
> "29. In April 2026, DLA revised its written policies and procedures. Those changes included a new written policy requiring DLA registered representatives to '**presume that the contents of [the] CIP constitute[] a recommendation**' and to ensure such contents meet 'the obligations of Reg[ulation] BI, in particular its Care Obligation.'"
- **Note on the charge:** the CIP finding supports a **Compliance Obligation** violation (Rule 15l-1(a)(2)(iv)), not a Care Obligation violation on the CIPs themselves.
- **What it establishes:** A regulator has now applied the 01-23 / Reg BI framework to a **document, not a conversation** — a firm-designed template listing three to five securities — and found it a recommendation on the two factors this track identifies: **individual tailoring** and **influence to trade particular securities**. And it held that **five separate disclaimers did not change the answer**, including the substitution of "examples of potential investments" for "suggested investments."
- **Q1:** **ADVERSE — the most significant adverse addition in this track.**
- **Application note, stated precisely.** The CIP was (i) **prepared by the firm's representatives** and pushed ("to persuade … customers to make the investments listed therein"), (ii) **pre-populated for a named customer** from information the customer gave the firm, and (iii) resolved to named securities with quantities and prices. The configuration differs on (i) — nothing is prepared by anyone to persuade, and the composed order originates in the member's own rule. It does **not** differ on (ii) or (iii): the output is keyed to that member's parameters and names an instrument. **DLA therefore confirms the two-axis test of Answer A rather than displacing it — and it confirms it in a Commission order rather than a 2001 hypothetical.** The disclaimer finding is the one to carry: on these facts "for illustrative purposes only," "not an offer to purchase securities," "we are not acting as fiduciaries" and a rewrite from "suggested" to "examples" were **all** ineffective. Any reliance on framing language in the configuration's UI should be assessed against ¶ 27, not against the softer statement in 01-23 n.16.

### S5-35 · *Michael Frederick Siegel*, Exchange Act Release No. 58737, Admin. Proc. File No. 3-12659 (SEC, 6 Oct 2008), *aff'd*, *Siegel v. SEC*, 592 F.3d 147 (D.C. Cir. 2010) · https://www.sec.gov/files/litigation/opinions/2008/34-58737.pdf ; https://www.sec.gov/files/litigation/opinions/2010/siegel-court-appeal-opinion-011210.pdf · retrieved 7 Sep 2026
- **Type:** Commission opinion on appeal from NASD, affirmed by the D.C. Circuit — **a litigated holding**
- **Date / status:** Good law. Later Commission opinion on remand at Rel. 34-62324 (18 Jun 2010).
- **Level 2** — the leading post-2000 articulation of the element, and **the only federal appellate decision post-2000 located applying it**. Its facts are a live oral pitch, so it does not reach tools; it matters because it is the appellate spine under 01-23 and because of its disclaimer holding.
- **Commission opinion at 10–11, verbatim:**
> "Whether the communication between a registered representative and a customer constitutes a recommendation is a "'facts and circumstances' inquiry to be conducted on a case-by-case basis." Such an inquiry "requires an analysis of the **content, context, and presentation** of the particular communication." NASD has stated that factors considered in conducting this inquiry include whether the communication "reasonably could be viewed as a 'call to action'" and "reasonably would influence an investor to trade a particular security or group of securities.""
  *Footnotes 14, 15 and 16 all cite NASD Notice to Members 01-23.*
- **⭐ Disclaimer and active discouragement did not cure — Commission opinion at 12, verbatim:**
> "Siegel also claims that he told the Downers not to invest simply because he was investing and that they would be on their own if they did decide to invest and that he discouraged Huntington Downer from investing in World ET by advising him that 'he would have to wait until the company went public.' **Yet, these statements do not change the conclusion that he made a recommendation.**"
  *And at 5: "Siegel represented that he was not recommending World ET securities to his customers." — a written representation to his own firm that he was not recommending; still a recommendation.*
- **D.C. Circuit at 15–16, verbatim:**
> "In conducting its inquiry into whether Siegel recommended World ET investments to the Downers … the SEC properly considered the "'content, context, and presentation'" of Siegel's communications, and whether, **as an objective matter**, Siegel's communication "'reasonably could have been viewed as a call to action' and 'reasonably would influence an investor to trade a particular security or group of securities.'""
> "**But this explanation does not speak to the question of whether Siegel's communications with the Downers could be perceived by a reasonable person in the Downers' position as a 'suggestion to invest'** in World ET…"
- **⭐ Commission opinion n.21 — a firm-wide promotional campaign as a recommendation factor, verbatim:**
> "21/ Cf. *Gordon Scott Venters*, 51 S.E.C. 292, 294 (1993) (finding that applicant made a recommendation within the meaning of NASD Conduct Rule 2310 **where customer's interest in investment was whetted by salesperson's and firm's promotional campaign**); *F.J. Kaufman and Co. of Va.*, 50 S.E.C. 164, 172 (1989) …" (emphasis added)
- **What it establishes:** The 01-23 factors are not merely SRO guidance — they were adopted by the Commission and **affirmed by the D.C. Circuit** as the test, and the inquiry is expressly objective. And a person who says he is not recommending, who tells the customer they are "on their own," and who actively discourages the investment, still recommends.
- **Q1:** ADVERSE on the disclaimer point; NEUTRAL on tools (the facts are a live oral pitch).
- **Application note:** n.21's "promotional campaign … whetted" line is the closest located authority for the proposition that **firm-level marketing feeding a specific security to a customer bears on the recommendation analysis** — relevant to any argument that the surrounding product framing is separable from the signal itself.

### S5-36 · Reg BI adopting release, 84 FR **33334–33335 & n.155**, and **n.176** — push, pull, and the standing arrangement · retrieved 7 Sep 2026
Supplements S5-13 with the passages that bear directly on the brief's push-versus-pull question.
- **The carve-out, verbatim (84 FR 33334–35):**
> "We confirm that … Regulation Best Interest would not: (1) Extend beyond a particular recommendation or generally require a broker-dealer to have a continuous duty to a retail customer or impose a duty to monitor; (2) require the broker-dealer to refuse to accept a customer's order that is contrary to the broker-dealer's recommendation; or (3) **apply to self-directed or otherwise unsolicited transactions by a retail customer, whether or not she also receives separate recommendations from the broker-dealer.**"
- **n.176 (84 FR 33337), verbatim:**
> "Regulation Best Interest does not extend beyond a particular recommendation, for example, by imposing a general broker-dealer duty to monitor a customer's account or **by applying the duty to unsolicited orders.**"
- **⭐ n.155 (84 FR 33335) — THE authority on a standing arrangement, and it runs the other way, verbatim:**
> "However … it is our position that when a broker-dealer **agrees with a retail customer to provide account monitoring services**: (1) The broker-dealer would be required to disclose the material facts (including scope and frequency) of those services …, and (2) such **agreed-upon account monitoring services involve an implicit recommendation to hold** (i.e., an implicit recommendation not to buy, sell, or exchange assets pursuant to that securities account review) **at the time agreed-upon monitoring occurs**, which is a recommendation 'of any securities transaction or investment strategy involving securities' covered by Regulation Best Interest." (emphasis added)
- **Corroborated in examination practice** — Risk Alert, "Observations from Broker-Dealer Examinations Related to Regulation Best Interest" (30 Jan 2023), https://www.sec.gov/files/exams-reg-bi-alert-13023.pdf: firms failed to surveil for "**implicit hold recommendations based on monitoring the customer's account (if the firm has agreed to such monitoring)**."
- **What it establishes:** **This is the direct answer to the brief's question whether a standing request converts a push into a pull — and the answer is the opposite of the one hoped for.** 01-23's outside example (4) and n.18 show a customer's standing request making a *push* acceptable. Reg BI n.155 shows a standing *agreement to monitor* converting silence into a **recurring implicit recommendation at each monitoring occurrence**. The two are reconcilable — one is about who set the scope of information sent, the other about an agreed service — but the register must not report the push-to-pull conversion without n.155 beside it.
- **Q1:** MIXED; n.155 is ADVERSE and should be logged as such.
- **Application note:** The configuration has **no agreement to monitor and no account review** — the engine evaluates the member's own rule and the runtime composes on the member's own policy; nobody agrees to review his account. But n.155's structure is that a **standing arrangement plus a recurring evaluation** produces a recommendation at each occurrence, and the configuration is a standing arrangement with a recurring evaluation. The distinction available is that n.155's subject is a **broker-dealer's agreed service to its own customer**, not a third party's software. That distinction is real and it is untested.

### S5-37 · The enforcement and case-law sweep — what is there, and what is verifiably not · retrieved 7 Sep 2026
- **The Reg BI enforcement corpus, verified against primary text.** Apart from S5-34, every located Reg BI action rests on **live human recommendations**, with the recommendation element assumed rather than contested: *Salomon Whitney LLC (SW Financial)*, 34-98619 (28 Sep 2023); *Laidlaw and Company (UK) Ltd.*, 34-98983 (20 Nov 2023); *LifeMark Securities Corp.* / *Wolterstorff*, 34-100615 & -100616 (29 Jul 2024); *First Horizon Advisors*, 34-101071 (18 Sep 2024); *PHX Financial*, 34-101361 (16 Oct 2024); *Citigroup Global Markets / Citi International Financial Services*, 34-98609 (Sep 2023, Form CRS delivery, not the element). Representative, *Laidlaw* ¶ 3: > "…two of its registered representatives … **made a series of recommendations to six retail customers** without a reasonable basis…"
- ***SEC v. Western International Securities, Inc.***, No. 2:22-cv-04119 (C.D. Cal.) — **the first Reg BI case, and it produced no ruling on the element.** ⚠️ **Date correction to the commissioning brief: the complaint was filed 15 June 2022** (caption: "Filed 06/15/22"); the press release is 16 June 2022, **not 27 June**. **Settled by consent**: Litigation Release No. 26065 (31 Jul 2024) — > "Without admitting or denying the allegations … Western has consented to the entry of a final judgment that would permanently enjoin it from violating Reg BI and orders Western to pay disgorgement … totaling $34,468, plus prejudgment interest, as well as a civil penalty of $160,000." **There is no motion-to-dismiss or summary-judgment opinion on the recommendation element.** Its one list-adjacent passage, Compl. ¶ 55: > "Prior to adding the June 2020 issuance of L Bonds to its **list of approved investments** for registered representatives to recommend, Western's Chief Compliance Officer … performed due diligence." — a product shelf, not a customer-facing list.
- **CourtListener v4 counts (`?q=…&type=o`, anonymous, 7 Sep 2026).** Reported in full, including the failures:

| Query | HTTP | COUNT |
|---|---|---|
| `"Notice to Members 01-23"` | 200 | **2** |
| `"content, context and manner of presentation"` | 200 | **0** |
| `"investment analysis tool"` | 200 | **0** |
| `"Regulation Best Interest" recommendation` | 200 | **2** |
| `"recommended list" suitability` | 200 | **12** |
| `"focus list" recommendation broker` | 200 | **0** |
| `"stock screener" recommendation` | 200 | **0** |
| `"watch list" broker recommendation` | 200 | **15** |
| `"call to action" recommendation security` | 200 | **61** |
| `gamification securities` | 200 | **0** |
| `"digital engagement practices"` | 200 | **0** |
| `"Terry's Tips"` | 200 | **4** |
| `"Tokyo Joe"` | 200 | **9** |
| `"menu of nine"`; `cites:(2404954)`; `cites:(2290926)`; `"reasonably would influence an investor to trade"`; `"99 F. Supp. 2d 889"`; `"409 F. Supp. 2d 526"` | **429** | **NOT OBTAINED** — body: `Rate limit exceeded: 50/hour`, then `Expected available in 82721 seconds` (≈23 h daily cap, shared per IP) |

  **On inspection, none of the non-zero counts is a recommendation-element case on tool or list facts.** The 12 "recommended list" and 15 "watch list" hits are FHFA/RMBS, insider-trading, condominium, election-law and antitrust matters. The 2 `"Regulation Best Interest" recommendation` hits are *XY Planning Network v. SEC* (2d Cir. 2020, an APA challenge to the rule) and *Robinhood Financial LLC v. Secretary of the Commonwealth* (Mass. SJC 2023, S5-31 — state-law validity, not the federal element).
- **Why one zero is misleading and must not be cited:** `"content, context and manner of presentation"` returned **0** because that is FINRA RN 11-02's wording. NTM 01-23 and *Siegel* say "**content, context, and presentation**" — no "manner of". **The correct string was never run.** Do not report that zero.
- **Later citations to *Park* / *Terry's Tips*:** two candidates identified — *SEC v. Pirate Investor LLC*, 580 F.3d 233 (4th Cir. 2009) and *Joseph v. Equity Edge, LLC*, 192 P.3d 573 (Colo. App. 2008) — **both UNVERIFIED**; the citing passages could not be read (CourtListener HTML returns HTTP 202 with 0 bytes to curl; the opinions API returns HTTP 401; Justia HTTP 403; `cites:()` queries HTTP 429). Both are Advisers Act / 10b-5 **publisher** cases, so any citation is more likely on the publisher's exclusion than on the list/menu point.
- **Q1:** The corpus is SUPPORT in the aggregate — twenty-six years of enforcement has produced **one** matter on document-and-list facts (S5-34) and none at all on screeners, watchlists, rankings or gamification — but that support is bounded by the exhaustiveness failures at N21.


## Adverse register

| Authority | Threat | Does the configuration distinguish it? |
|---|---|---|
| **NASD NTM 96-60** — "a transaction will be considered to be recommended when the member … brings a specific security to the attention of the customer **through any means**"; "does not depend on the classification … as 'solicited' or 'unsolicited'" | **5** | **No.** This is the broadest adverse text located and it is still live (RN 12-25 A2 preserves it). Neutral labels, no highlighting and member-authored parameters are all irrelevant to it. The only answer is that 01-23 is later and specifically about online tools, and that its four "outside" examples would be impossible if 96-60 were read literally. **No located authority performs that reconciliation.** Do not present the tension as resolved. |
| **NTM 01-23, "within" example (3)** — customer inputs age/financial condition/risk tolerance; tool displays "a list of specific securities the customer could buy or sell" | **5** | **Partly, and the distinction is real but untested.** The structural match is close: parameters in, a specific instrument out, displayed on screen ("or displays to" is expressly covered). But the match is not exact, and the difference is the one axis 01-23 itself makes load-bearing. In "within" example (3) **the member authored the mapping**: the customer supplies raw personal facts (age, financial condition, risk tolerance) and *the member's tool* decides which securities those facts imply. In the configuration the member authors the mapping himself — thresholds, weights, scores, inclusion rules, universe, side mapping and sort key all trace to his own settings — which is the configuration described in **"outside" example (3)**, whose safe harbour turns on the algorithms "not [being] programmed to produce lists of securities based on subjective factors that the member has created or developed." **The configuration therefore sits between the two examples: personalized like the prohibited one, member-authored-criteria-free like the permitted one.** 01-23 does not address that combination, and **no located authority distinguishes a rule the user wrote from one the vendor wrote for him** (the shared context records the same gap at Q1). Do not report this as a clean distinction: it is the strongest available argument and it rests on reading across two examples that were never meant to be combined. |
| ★ ***In re David Lerner Associates, Inc.***, Rel. 34-105556 (SEC, 27 May 2026) — a firm template listing 3–5 securities held a recommendation; **five disclaimers did not cure** | **5** | **Only partly, and this is the most serious adverse item in the track.** The configuration differs on **origination**: the CIP was prepared by the firm's representatives and pushed, with reps trained "to persuade … customers to make the investments listed therein" (¶24), whereas the composed order originates in the member's own rule and nobody persuades. It does **not** differ on the two factors the Commission actually relied on in ¶33 — **individually tailored to a specific customer**, and **reasonably would influence an investor to trade a particular security**. ¶27 forecloses reliance on framing language: "not an offer to purchase securities", "for illustrative purposes only", "not acting as fiduciaries", and a rewrite from "suggested investments" to "examples of potential investments" all failed together. **Assume UI framing language does nothing.** |
| *Siegel*, Rel. 34-58737 (SEC 2008), *aff'd*, 592 F.3d 147 (D.C. Cir. 2010) — "these statements do not change the conclusion that he made a recommendation" | **3** | **No, on the disclaimer point.** A person who said he was not recommending, told the customer they were "on their own," and actively discouraged the investment still recommended; and the D.C. Circuit confirmed the inquiry is **objective**, judged by "a reasonable person in the [customer's] position." Facts are a live oral pitch, so it does not reach tools — but it is the appellate footing for the 01-23 factors, and it is the third independent source foreclosing cure by disclaimer. |
| **Reg BI adopting release, 84 FR 33335 n.155** — an agreed account-monitoring service is "an implicit recommendation to hold … at the time agreed-upon monitoring occurs" | **4** | **Partly, and it must not be omitted.** The configuration involves **no agreement to monitor and no account review** — nobody undertakes to review the member's account. But n.155's structure is *standing arrangement + recurring evaluation = a recommendation at each occurrence*, and the configuration is a standing arrangement with a recurring evaluation. The available distinction — that n.155 addresses a broker-dealer's agreed service to its own customer, not a third party's software — is real and **untested**. Do not cite 01-23's push-to-pull examples without this beside them. |
| **FINRA Rule 2111.03 chapeau** — safe harbour lost if the communication includes "(standing alone **or in combination with other communications**) a recommendation of a particular security or securities" | **4** | **No.** The output is a named instrument. The safe harbour is unavailable on its face, and the "in combination" clause reaches the engine UI + approval surface + journal as a sequence. |
| **NTM 01-23 n.15 / RN 11-02 — aggregation** — "a series of actions that may not constitute recommendations when viewed individually may amount to a recommendation when considered in the aggregate" | **4** | **No.** The configuration is by construction a sequence: signal → composed order → approval surface. Each step is defensible alone. Aggregation is the doctrine that attacks exactly that architecture, and it is stated in three separate sources (01-23 n.15, RN 11-02, Rule 2111.03 chapeau). |
| **RN 11-02 / NTM 01-23 guideline 4** — "It also makes no difference whether the communication was initiated by a person or a computer software program" | **4** | **No.** Forecloses any argument resting on automation as such. Consistent with *Vartuli* (P7). |
| **FINRA Rule 2214 Supp. Mat. .04** — member responsible for "all recommendations based on the investment analysis tool (**whether made via the automated tool** or a written report)" | **3** | **Partly.** FINRA contemplates in terms that an automated tool can make a recommendation. But 2214 addresses a *member's* responsibility for a tool it offers; it does not characterise a non-member vendor. The engine also appears to fall outside 2214(b)'s definition (it produces no simulations or likelihood-of-outcome statistics), so it gets neither the burden nor the limited exception. |
| **RN 12-25 A8 & n.42; Reg BI 84 FR 33338 n.182** — narrowing toward particular securities | **3** | **No, but it is spent.** The narrowing continuum runs from asset classes to particular securities. The configuration's output *starts* at a particular security, past the end of the continuum. The count of items therefore cannot help it — but neither does the narrowing doctrine add anything beyond Rule 2111.03's chapeau. |
| **Reg BI 84 FR 33402 n.853** — "a broker-dealer may generate recommendations through an asset allocation model" | **3** | **Partly.** Establishes model-generated recommendations exist. Addressed to a broker-dealer's own model, not a third party's. |
| **SEC DEP release Q 3.6** — floats an observable-behavioural-impact test ("statistically significant number of retail investors") | **2** | **Yes, for now.** It is a question in a withdrawn-lineage request for comment, never adopted anywhere. But it is the only articulated alternative test on the record, and it would be indifferent to neutral labelling. |
| **NTM 01-23 guideline 1; Rule 2111 Supp. Mat. .02** — a disclaimer cannot discharge the obligation | **3** | **No.** Two independent sources. Any reliance on a "this is not advice" legend is foreclosed, and Rule 2210(d)(1)(C) separately bars burying the qualification in a legend. |
| **Mass. Sec. Div. v. Robinhood** — "no different from a broker-dealer agent handing a list of securities to a customer … and then proclaiming that he made no recommendations" | **3** | **Partly.** The theory attacks exactly the move of surfacing specific instruments while disclaiming recommendation. But it was **never adjudicated**: the SJC classified it as a disputed question of fact (492 Mass. at 5 n.7) and the Division then settled without the fiduciary count. It is a live theory with no holding behind it. The configuration is also materially unlike the pleaded facts — no lists, no defaults, no highlighting, member-authored criteria — but the analogy's force does not depend on those features. |
| **Mass. Consent Order § VIII ¶C(e)** — permanent bar on "generalized push notifications highlighting specific lists" | **3** | **Yes, on the facts** — the configuration pushes nothing to a list and highlights nothing. **No, on the method**: a regulator obtained a permanent injunction against a presentation feature **without ever proving it was a recommendation**, using supervision and commercial-honor hooks instead. That route is available against any registrant regardless of where the recommendation line sits. |
| ***Robinhood Fin. LLC v. Sec'y of the Commonwealth*, 492 Mass. 696 (2023)** — Reg BI is "a regulatory floor that does not foreclose State regulation" | **3** | **No.** Establishes that federal analysis does not exhaust the question in any state, and that a state may define "unethical or dishonest conduct" more broadly, with deference. Washington State's own position is a separate track's subject; this authority makes that question live rather than academic. |
| **950 CMR 12.207(1)(a)** — fiduciary duty "when providing investment advice or recommending", with **"recommendation" undefined anywhere in the chapter** | **3** | **No.** An undefined trigger cannot be distinguished on its terms. Mitigated by the Division's own FAQ ("The fiduciary conduct standard applies in connection with recommendations or advice provided by a broker-dealer … unsolicited trades will be subject to applicable federal and state conduct rules") and by the Adopting Release's statement that the duty "has not been deemed to be ongoing." Massachusetts only. |
| **17 C.F.R. § 275.203A-2(e)(2)** — "'digital investment advisory service' is investment advice … generated by the … software-based models, algorithms, or applications **based on personal information each client supplies**" | **4** | **No.** This is Commission **rule text**, not an SRO example, and its structure is the configuration's exactly: an algorithm producing output from personal information the user supplies. The only distinction available is that the definition is written for the purposes of an **exemption from the federal-registration prohibition** — it defines who may use that exemption, not who is an adviser, and does not by its terms extend the Advisers Act to anyone. Read with 01-23's "within" example (3) and *Taucher* at *475, this is the **second independent instance** of a US authority treating user-supplied parameters as no obstacle to the output being advice. **Log as a material adverse addition to Q1.** |
| ***In re Murakami / GoTradeSignals***, Wash. DFI No. S-15-1626-15-SC01 (16 Jun 2016) — subscription signal newsletter held an unregistered investment adviser | **4** | **Partly, and this one is in Washington, which is in scope.** Distinguishing facts are real: the charge turned on **auto-trading** — "hands free trading", "automatically execute trades" — with no per-order human act, the opposite of the configuration's one-tap approval surface and its exclusion of standing execution from V1. But ¶¶5 and 7 rest on the newsletter's **content** ("recommendations to buy or sell particular options products", "specific trading instructions") **coupled** to auto-traded accounts, and **nothing in the order says which element was load-bearing**. Resolved by consent; nothing adjudicated. ◇ The consent order was retrieved but not pin-cite quoted — read it before relying on this. |
| **NASAA comment letter, File No. S7-10-21 (1 Oct 2021)** — "it is not reasonable to accept that **anything but an individualized recommendation** to purchase or sell a particular security qualifies as a recommendation" | **3** | **No, and note what it targets.** NASAA is arguing directly against the narrow reading this register derives from 01-23. It is advocacy with no legal force, the Commission adopted none of it, and NASAA's own attempt to enact it by model rule failed (S5-22). But it is the theory a state regulator would run, and on its terms a timed signal about a specific security is "a call to action … by design or effect." |
| **FINRA AWC No. 2022073414901 (Merrill Lynch, 2026)** — a generic platform-wide disclosure held insufficient because not security-specific | **3** | **No.** The operational form of the disclaimer rule: where a duty is owed, an always-shown platform-level legend does not discharge it. Reinforces 01-23 guideline 1, Rule 2111.02 and Rule 2210(d)(1)(C). |
| **FINRA AWC No. 2022076787601 (Stockpile, 2025)** — "the communications included … the firm's **mobile application interface**" | **2** | **Partly.** Establishes that an app interface is itself a "retail communication" under Rule 2210 — but Rule 2210 binds **members**, and the theory is content standards, not recommendation. ◇ The AWC itself is UNVERIFIED; text is from FINRA's own newsletter summary. |

---

## Direct answers

### A. The most aggressive presentation permitted, and the least aggressive held to cross

**Most aggressive permitted — NASD NTM 01-23 n.14:** a broker-dealer's own **"stock of the week"** research announcement, sent electronically to customers.

> "Note that there are instances where sending a customer an electronic communication that **highlights a particular security (or securities)** will not be viewed as a 'recommendation.' For instance … a member generally would not be viewed as making a 'recommendation' when, pursuant to a customer's request, it sends the customer (1) electronic 'alerts' … or (2) **research announcements (e.g., a firm's 'stock of the week')** that are not tailored to the individual customer, as long as neither—given their content, context, and manner of presentation—would lead a customer reasonably to believe that the firm is suggesting that the customer take action in response to the communication."
> — NASD NTM 01-23 n.14, https://www.finra.org/rules-guidance/notices/01-23, retrieved 7 Sep 2026

Read against the facts, that permits, simultaneously: **a list of one**; **the security chosen entirely by the firm**, on the firm's own undisclosed subjective criteria; **an evaluative superlative label** ("stock of the *week*"); **express highlighting** of that security; and **active transmission** to the customer. Its three conditions are (i) sent pursuant to a customer's request, (ii) **not tailored to the individual customer**, and (iii) content/context/manner would not lead a customer reasonably to believe the firm is suggesting action.

The runner-up on the permitted side is the ranking search engine (01-23 outside example 2) — but n.14 is materially more aggressive, because there the **firm** picks the security and labels it, whereas in example 2 the customer picks the criteria and the machine ranks a broad universe.

**Least aggressive held to cross — NASD NTM 01-23, "within" example (3):**

> "A member provides a portfolio analysis tool that allows a customer to indicate an investment goal and input personalized information such as age, financial condition, and risk tolerance. The member in this instance then sends (or displays to) the customer a list of specific securities the customer could buy or sell to meet the investment goal the customer has indicated."
> — NASD NTM 01-23, "within" example 3, same URL and date

What is **absent** from that example is the point: no urging, no "buy" rating, no evaluative label, no superlative, no highlighting, no colour, no badge, no ranking, no unsolicited push (the customer operated the tool), no firm opinion, and no narrowing claim. It crosses on exactly two facts — **personalized inputs in, specific securities out** — and the parenthetical "(or displays to)" makes clear that a passive on-screen display is treated the same as an active send.

**The gap between them.** The two examples are not separated by prominence, emphasis, colour, labelling, list length, or who initiated the communication. On every one of those axes the *permitted* case is the more aggressive: n.14's "stock of the week" is a highlighted, superlatively-labelled, firm-selected list of one that the firm sends; example (3) is an unlabelled, unhighlighted, customer-operated screen. The operative difference is a **two-axis test**:

1. **Personalization** — does the output key to *this* customer's own attributes? n.14 is expressly conditioned on the announcement being **"not tailored to the individual customer."** Example (3) is defined by the customer's age, financial condition and risk tolerance going in. 01-23's general principle states the axis directly: *"the more individually tailored the communication to a specific customer or a targeted group of customers about a security or group of securities, the greater likelihood that the communication may be viewed as a 'recommendation.'"*
2. **Specificity** — does the output resolve to named securities rather than to classes? 01-23 n.15 and RN 12-25 A8/n.42 make asset-class output safe and named-issuer output unsafe, with the number of issuers "one of a variety of factors."

So the permitted ceiling is high on *every* presentational axis and the prohibited floor is low on *every* presentational axis. **"More," on the located material, is not more emphasis. It is personalization crossed with specificity.** A tool may shout, provided it shouts the same thing at everybody and the customer asked to hear it; it may not whisper a name derived from this customer's own data.

**The adviser side independently confirms both axes, in Commission rule text.** This matters because it means the two-axis test is not an artefact of one 2001 SRO document. On the **permitted** axis, the Commission excluded interactive analysis tools from the hypothetical-performance regime for the express reason that such tools "**require the investor to interface directly with the tool**" (IA-5653, 86 FR 13082) — customer operation, doing real regulatory work, exactly as in 01-23's "outside" example (2); and it confirmed that per-investor outputs are **not** each an advertisement "because the adviser or investor inputs investor-specific information." On the **prohibited** axis, 17 C.F.R. § 275.203A-2(e)(2) defines "digital investment advisory service" as "**investment advice** … generated by the … software-based models, algorithms, or applications **based on personal information each client supplies**" — personalization-in, advice-out, stated as a definition. The Commission's own line, drawn between them, is on the **claim** rather than the output: "the adviser should **neither imply nor state that the interactive tool, alone, can determine which securities to buy or sell**" (86 FR 13082).

**The least aggressive presentation a regulator has ACTUALLY CHARGED — *David Lerner Associates* (SEC, 27 May 2026).** The 01-23 poles are hypotheticals. This is the real-world floor, and it is close to the hypothetical one. The communication was a **three-page firm template** listing **three to five specific securities** with amounts, share counts, prices and estimated distributions, pre-populated for a named customer. No superlative, no ranking, no "best", no colour, no badge, no gamification. The Commission's finding, verbatim: > "**CIPs are 'recommendations' under Regulation BI because they are 'individually tailored . . . to a specific customer,' \"'reasonably would influence an investor to trade a particular security or group of securities,'\" and \"'reasonably could be viewed as a \"call to action.\"'\"**" (¶ 33). It sits slightly *above* 01-23's "within" example (3) on aggressiveness, because the CIP was pushed by a representative trained "to persuade" (¶ 24) whereas 01-23's example is customer-operated. So example (3) remains the least aggressive crossing on the located material; **DLA is the least aggressive that has actually been charged**, and it lands on the same two axes. **Its disclaimer holding is the most important operational output of this whole track.** Five separate disclaimers failed: "is not an offer to purchase securities"; "[e]xact investments recommended can only be determined when we learn more"; "neither DLA, nor its [registered representatives], are acting as fiduciaries"; "for illustrative purposes only"; and a rewrite of "We have prepared these **suggested investments** for your consideration" to "We have prepared these **examples of potential investments** for your consideration." The Commission's answer was one sentence: > "**These changes to the CIP template did not alter that the CIPs were recommendations.**" (¶ 27). This is materially stronger than 01-23 n.16, which had left room for a disclaimer to "help clarify." **After DLA, framing language should be assumed to do nothing.**

**Where the Robinhood record fits — and why it does not move either pole.** The most aggressive presentation ever actually deployed and challenged in the located material is Robinhood's: a "First List" on the home screen chosen by firm-popularity data, a "100 Most Popular" and "Top Movers" list supplied "to all customers by default," push notifications that said "*Choosing stocks is hard*" and "*Can't decide which stocks to buy?*" and deep-linked straight into those lists, confetti on trades, a scratch-off free-stock reveal, and a tap-to-advance waitlist. Massachusetts pleaded that this was "no different from a broker-dealer agent handing a list of securities to a customer … and then proclaiming that he made no recommendations." **It never became a holding.** The SJC recorded the theory (492 Mass. at 4 n.5), recorded Robinhood's denial that as a "self-directed" firm it recommends anything, and then expressly refused to resolve it: "*We address only the purely legal issues presented on appeal, which are unaffected by this dispute of material fact*" (id. at 5 n.7). The Division then settled in January 2024 **with no fiduciary count, no mention of 950 CMR 12.207, and zero occurrences of "fiduciary", "best interest" or "solicit" in the order.** Meanwhile FINRA and the SEC, looking at the same app in the same period and imposing $122.5m between them, charged disclosure accuracy, best execution, supervision and advertising content — and never charged the interface as recommending (S5-33, with counts).

So Robinhood does not become the "most aggressive permitted": nobody permitted it, and the firm withdrew the features. Nor does it become the "least aggressive prohibited": nothing was adjudicated, and the consent bars rest on supervision and commercial-honor hooks. **The poles remain where 01-23 put them in 2001.** What the Robinhood record adds is a warning about method: a regulator obtained a permanent bar on "generalized push notifications highlighting specific lists" **without ever having to prove they were recommendations.** Where the target is a registrant, the recommendation line can simply be bypassed.

Two further qualifications that must travel with this answer:
- **NTM 96-60 cuts across it.** Its rule — a transaction is recommended when the member "brings a specific security to the attention of the customer **through any means**," regardless of "solicited"/"unsolicited" labelling — is inconsistent with 01-23's permitted side if read literally, and it has never been expressly reconciled. See S5-02.
- **Both poles still come from the same 2001 document, and that remains a weakness.** *David Lerner* (S5-34) now corroborates the prohibited pole in a Commission order, and *Siegel* (S5-35) puts the factors themselves on appellate footing. But **the permitted ceiling — n.14's highlighted, firm-selected, superlatively-labelled "stock of the week" — has never been tested by anyone**, and no decision or order located anywhere applies the framework to a screener, ranking, watchlist, leaderboard or gamified interface. See N1.
- **Push-to-pull does not run cleanly in one direction.** 01-23 outside example (4) and n.18 show a customer's standing request making a push acceptable. **Reg BI n.155 runs the other way**: an agreed account-monitoring service produces "an implicit recommendation to hold … at the time agreed-upon monitoring occurs" — a standing arrangement plus a recurring evaluation generating a recommendation each time. Report the two together, never the first alone (S5-36).

### B. Does any authority distinguish customer-chosen from vendor-chosen ranking criteria?

**The exact phrase is unique to 01-23.** A normalized (whitespace-collapsed, case-folded) full-text search for "criteria selected by the customer", "selected by the customer", "criteria the customer", "customer selects", "customer-selected", "criteria developed by the firm", "criteria followed by vendors" and "who selects" was run across **33 retrieved primary texts**: the Reg BI adopting release (84 FR 33318, 1.6 MB), the DEP release (86 FR 49067), the withdrawn PDA proposal (88 FR 53960, 567 KB) and the withdrawal notice (90 FR 25531); FINRA Rules 2090, 2111, 2210 and 2214; NASD NTMs 96-60, 01-23 and 04-86; FINRA RNs 10-06, 11-02, 11-39, 12-25, 12-29, 16-41, 17-18, 19-31, 21-17, 21-19, 22-08, 23-17 and 24-09; the FINRA 2021 Examination Report, the FINRA 2016 Digital Investment Advice report, and the FINRA Annual Regulatory Oversight Reports for 2025 and 2026; and the SEC Division of Examinations priorities for FY2022–FY2026. **Exactly three files returned any hit, and they are mutually exclusive:** `txt_n_01-23.txt` — "criteria selected by the customer" ×1, "selected by the customer" ×1, "customer selects" ×1; `dep.txt` — "criteria developed by the firm" ×1; `txt_n_11-39.txt` — "criteria followed by vendors" ×1. **Every other file returned zero.** Method and full file list at search log #50.

**But the axis is load-bearing twice within 01-23, not once**, and P7's summary captures only the first instance:
1. Outside example (2): *"Search results from this tool may rank securities using any criteria selected by the customer."*
2. Outside example (3), stated as its converse and as an express condition of the safe harbour: *"the algorithms for these tools are **not programmed to produce lists of securities based on subjective factors that the member has created or developed**, nor do the algorithms … produce lists that favor those securities in which the member makes a market or for which the member has made a 'buy' recommendation."*

The second is the stronger form: it makes **vendor-authored subjective selection criteria** a disqualifier from the safe harbour, not merely an absent virtue. Example (2) also carries *"Customers use and direct this tool on their own."*

**Outside 01-23, the axis appears five times — and never once as a recommendation trigger:**
- **FINRA Rule 2214(c)(3) and Supp. Mat. .06** regulate exactly this axis — *"explains how the tool determines which securities to select, discloses if the tool favors certain securities and, if so, explains the reason for the selectivity"*; and .06's list of favouring grounds (member revenue, relationships with the tool's creator, market-making, underwriting). But 2214 makes vendor-side selectivity a **disclosure obligation**, expressly not a prohibition: *"Members are not required to provide a 'negative' disclosure."* Nothing in 2214 says a favouring tool is thereby making a recommendation.
- **The SEC's DEP release** uses the mirror phrase descriptively for leaderboards — *"leaderboards to rank individuals based on performance-based criteria developed by the firm"* — and attaches no legal consequence to it.
- **Advisers Act Rule 206(4)-1(e)(8)(ii)(A)(3)** — the SEC's own import of the FINRA 2214 language — requires the adviser to "explain[] **how the tool determines which investments to select**, disclose[] **if the tool favors certain investments** and, if so, explain[] the reason for the selectivity." Again a **disclosure** condition, and again attached to the **adviser**, not a status trigger. Note that the Commission made **customer operation** the express reason for the whole exclusion: the tool escapes the hypothetical-performance regime because such tools "**require the investor to interface directly with the tool**" (86 FR 13082) — which is the *customer-directs-the-tool* half of 01-23's example (2), now carrying real regulatory weight on the adviser side.
- **FINRA RN 11-39 § 4 (Data Feeds)** requires a member ingesting a vendor's feed to "**understand the criteria followed by vendors in gathering or calculating**" the data — the axis again, but framed as **accuracy diligence** owed by the **member**, with no suggestion that vendor-chosen criteria make anyone a recommender.
- **Datastream International Inc. (15 Mar 1993)**, already in P7, carries the staff's "who selects the search criteria" axis — but in the **§15(a) broker** analysis, not the recommendation analysis. Its bearing is on Q2, not Q1. S5-04 and S5-11 change how it reads only by showing that the axis recurs across three separate regulatory contexts (broker status, tool disclosure, DEP description) while being made dispositive in none of them except 01-23.

**Finding, stated plainly.** For the *recommendation* question, the customer-chosen / vendor-chosen distinction is load-bearing **only in NASD NTM 01-23**, where it appears in two of the four permitted examples, once affirmatively and once as an express disqualifier. Everywhere else it has been noticed and given a different job — disclosure (Rule 2214), description (DEP release), or broker status (Datastream). **No court, no Commission opinion, no enforcement order and no FINRA adjudication located in this track has applied it.** It rests on a single 2001 SRO policy statement, and its weight is exactly the weight of that document — which the Commission did, however, adopt by citation at 84 FR 33335 n.161 and again endorse at 86 FR 49067 n.31.

*Application note (no conclusion drawn).* The configuration's design — every threshold, weight, score, inclusion rule, universe, side mapping, trading window, evaluation frequency and sort key traced to an explicit member setting or a separately attributed external source, with neutral sort labels and nothing highlighted — is built precisely along the axis that 01-23 makes load-bearing, and along the axis that Rule 2214.06 makes disclosable. It does not address the axis 01-23's "within" example (3) makes decisive, which is personalization-to-specificity, and on which the configuration sits on the adverse side.

---

## Presentation-feature table

Direction key: **IN** = tipped it into a recommendation · **OUT** = kept it out · **NA** = catalogued or asked about, never decided.

| # | Feature | Authority | Direction | Verbatim phrase | Citation |
|---|---|---|---|---|---|
| 1 | Ranking by criteria **the customer** selected | NASD NTM 01-23, outside ex. 2 | **OUT** | "Search results from this tool may rank securities using any criteria selected by the customer" | NTM 01-23, outside example 2 |
| 2 | Customer operates and directs the tool unaided | NASD NTM 01-23, outside ex. 2 | **OUT** | "Customers use and direct this tool on their own." | NTM 01-23, outside example 2 |
| 3 | Algorithm programmed on **vendor-created subjective factors** | NASD NTM 01-23, outside ex. 3 | **IN** (by express condition) | "the algorithms for these tools are not programmed to produce lists of securities based on subjective factors that the member has created or developed" | NTM 01-23, outside example 3 |
| 4 | Universe limited to / list generated to **favour** the member's own book or ratings | NASD NTM 01-23, outside ex. 3 | **IN** (by express condition) | "nor does it control the generation of the list in order to favor certain securities … the member does not limit the universe of securities to those in which it makes a market or for which it has made a 'buy' recommendation" | NTM 01-23, outside example 3 |
| 5 | Tool favours certain securities — vendor economics, market-making, underwriting | FINRA Rule 2214(c)(3), Supp. Mat. .06 | **NA** — triggers **disclosure**, not a recommendation finding | "discloses if the tool favors certain securities and, if so, explains the reason for the selectivity"; "Members are not required to provide a 'negative' disclosure" | Rule 2214(c)(3); Supp. Mat. .06 |
| 6 | Broad universe / externally recognized group; "broad, objective criteria" | NASD NTM 01-23, outside ex. 3 | **OUT** | "screen through a wide universe of securities (e.g., all exchange-listed and Nasdaq securities) or an externally recognized group of securities (e.g., certain indexes) and to request lists of securities that meet broad, objective criteria" | NTM 01-23, outside example 3 |
| 7 | **Highlighting a particular security** | NASD NTM 01-23 n.14 | **OUT** (subject to 3 conditions) | "sending a customer an electronic communication that highlights a particular security (or securities) will not be viewed as a 'recommendation'" | NTM 01-23 n.14 |
| 8 | **Evaluative superlative label**, firm-chosen ("stock of the week") | NASD NTM 01-23 n.14 | **OUT** (if not tailored + customer requested) | "research announcements (e.g., a firm's 'stock of the week') that are not tailored to the individual customer" | NTM 01-23 n.14 |
| 9 | Evaluative label as a **content-standards** matter ("best", "top", forecast) | FINRA Rule 2210(d)(1)(F) | **NA** for recommendation; separately **prohibited** as content | "Communications may not predict or project performance … or make any exaggerated or unwarranted claim, opinion or forecast" | Rule 2210(d)(1)(F) |
| 10 | **"Buy"-rated list** + urging purchase from it | NASD NTM 01-23, within ex. 2 | **IN** | "urges customers to purchase one or more stocks from a list with 'buy' recommendations" | NTM 01-23, within example 2 |
| 11 | Third-party buy/sell ratings held in a library the customer requests | NASD NTM 01-23, outside ex. 1 | **OUT** | "research reports (which may include buy/sell recommendations from the author of the report) … that customers can obtain or request" | NTM 01-23, outside example 1 |
| 12 | **List of ONE** | NASD NTM 01-23 n.14 | **OUT** (as "stock of the week") | "a firm's 'stock of the week'" | NTM 01-23 n.14 |
| 13 | **Number of items / narrowing** | FINRA RN 12-25 A8 & n.42; adopted at Reg BI 84 FR 33338 n.182 | **IN** as it narrows — no threshold given | "as an allocation recommendation becomes narrower or more specific, the recommendation gets closer to becoming a recommendation of particular securities … depending on a variety of factors (including the number of issuers that fall within the broker-dealer's allocation recommendation)" | RN 12-25 A8; n.42; 84 FR 33338 n.182 |
| 14 | Asset **classes** only, no accompanying securities list | NASD NTM 01-23 n.15; FINRA Rule 2111.03(c); RN 12-25 A8 | **OUT** | "a suggested mix of general classes of financial assets … without an accompanying list of securities that the customer could purchase to achieve that allocation, would not trigger a suitability obligation" | NTM 01-23 n.15 |
| 15 | **Personalized inputs → list of specific securities** | NASD NTM 01-23, within ex. 3 | **IN** — the least aggressive crossing located | "input personalized information such as age, financial condition, and risk tolerance. The member … then sends (or displays to) the customer a list of specific securities the customer could buy or sell" | NTM 01-23, within example 3 |
| 16 | Passive **on-screen display** vs active send | NASD NTM 01-23, within ex. 3 | **IN** — treated identically | "sends (**or displays to**) the customer" | NTM 01-23, within example 3 |
| 17 | **Individual tailoring** generally | NASD NTM 01-23; RN 11-02; Reg BI 84 FR 33335 | **IN**, on a sliding scale | "the more individually tailored the communication to a specific customer or a targeted group of customers about a security or group of securities, the greater the likelihood that the communication may be viewed as a 'recommendation'" | 84 FR 33335; NTM 01-23; RN 11-02 |
| 18 | **Behavioural data-mining** then pushing suggestions | NASD NTM 01-23, within ex. 4 | **IN** | "uses data-mining technology … to analyze a customer's financial or online activity—whether or not known by the customer—and then, based on those observations, sends (or 'pushes') specific investment suggestions" | NTM 01-23, within example 4 |
| 19 | **Push vs pull — standing request converts push to pull** | NASD NTM 01-23, outside ex. 4 | **OUT** | "A member allows customers to subscribe to e-mails … that alert customers to news affecting the securities in the customer's portfolio or on the customer's 'watch list.' … **The customer selects the scope of the information that the firm will send to him or her.**" | NTM 01-23, outside example 4 |
| 20 | **Customer-requested price-point / earnings / rating-change alert** | NASD NTM 01-23 n.18 | **OUT** "without more" | "where a customer affirmatively requests to be alerted … when a security reaches a specific price-point … the broker/dealer's decision to send the customer the requested information, without more, would not necessarily trigger a suitability obligation" | NTM 01-23 n.18 |
| 21 | **Unrequested** (pushed) information | NASD NTM 01-23, guideline 4 | **NA** — not automatic; triggers a four-part review | "A member's transmission of unrequested information will not necessarily constitute a 'recommendation.' However … the member should carefully review the circumstances under which the information is being provided, the manner in which the information is delivered …, the content of the communication, and the original source of the information." | NTM 01-23, guideline 4 |
| 22 | **Push notifications** to self-directed customers | FINRA RN 22-08, pp. 13, 16 | **NA** — asked, never answered | "Should targeted communications, such as push notifications to self-directed retail customers … be subject to specific restrictions?" | RN 22-08 |
| 23 | **Audience segmentation** (e.g. "premium" tier) | NASD NTM 01-23 n.17 | **OUT** "without more" | "a broker/dealer's business decision to provide only certain types of investment information … to a category of 'premium' customers would not, without more, trigger application of the suitability rule" | NTM 01-23 n.17 |
| 24 | Mass communication **urging** investment | NASD NTM 01-23 n.17 | **IN** | "members may incur suitability obligations when they send a communication to a large group of customers urging those customers to invest in a security" | NTM 01-23 n.17 |
| 25 | **Accompanying message** to act on otherwise-neutral content | NASD NTM 01-23 n.10 | **IN** | "if the same broker/dealer transmitted the very same research report with an accompanying message … that the customer should act on the report, the suitability analysis would be different" | NTM 01-23 n.10 |
| 26 | **Aggregation** of individually innocuous steps | NASD NTM 01-23 n.15; RN 11-02; Rule 2111.03 chapeau | **IN** | "a series of actions that may not constitute recommendations when viewed individually may amount to a recommendation when considered in the aggregate"; "(standing alone or in combination with other communications)" | RN 11-02; NTM 01-23 n.15; Rule 2111.03 |
| 27 | **Person vs computer software** as the initiator | NASD NTM 01-23 guideline 4; RN 11-02 | **NA** — expressly irrelevant | "It also makes no difference whether the communication was initiated by a person or a computer software program." | RN 11-02 at 2–3 |
| 28 | Recommendation **made via an automated tool** | FINRA Rule 2214 Supp. Mat. .04; Reg BI 84 FR 33402 n.853 | **IN** — automation is no answer | "all recommendations based on the investment analysis tool (whether made via the automated tool or a written report)"; "a broker-dealer may generate recommendations through an asset allocation model" | Rule 2214.04; 84 FR 33402 n.853 |
| 29 | **Disclaimer** | NASD NTM 01-23 guideline 1 & n.16; FINRA Rule 2111 Supp. Mat. .02 | **NA** — cannot cure; may clarify | "A member cannot avoid or discharge its suitability obligation through a disclaimer"; ".02 Disclaimers. A member or associated person cannot disclaim any responsibilities under the suitability rule." | NTM 01-23 guideline 1; Rule 2111.02 |
| 30 | Qualification buried in a **legend or footnote** | FINRA Rule 2210(d)(1)(C) | **NA** — separately prohibited | "Information may be placed in a legend or footnote only in the event that such placement would not inhibit an investor's understanding of the communication." | Rule 2210(d)(1)(C) |
| 31 | **Bringing a specific security to the customer's attention by any means** | NASD NTM 96-60 | **IN** — broadest formulation located | "a transaction will be considered to be recommended when the member or its associated person brings a specific security to the attention of the customer through any means"; "does not depend on the classification of the transaction … as 'solicited' or 'unsolicited'" | NTM 96-60 |
| 32 | **Self-directed / unsolicited** transaction | Reg BI 84 FR 33335; FINRA RN 22-08 n.60 | **OUT** | "Nor does Regulation Best Interest apply to self-directed or otherwise unsolicited transactions by a retail customer"; "neither Reg BI nor Rule 2111 apply in the absence of a recommendation, such as where a retail investor invests entirely on their own accord … through a self-directed account" | 84 FR 33335; RN 22-08 n.60 |
| 33 | **Visual prominence / one item shown more prominently than another** | SEC DEP release, 86 FR 49067 | **NA** — catalogued, never decided | "Interface design elements may provide visual cues, including by displaying certain information more prominently than other information." | 86 FR 49067 |
| 34 | **Colour** (screen shifts green/red on portfolio performance) | SEC DEP release | **NA** | "some digital platforms' user interfaces shift the coloration of the entire screen between green and red based on an investor's portfolio performance" | 86 FR 49067 |
| 35 | **Badges, points, leaderboards** — ranked on firm-set criteria | SEC DEP release | **NA** | "badges as visual markers of achievement as well as leaderboards to rank individuals based on performance-based criteria developed by the firm" | 86 FR 49067 |
| 36 | **"Top movers" lists** delivered by notification | SEC DEP release | **NA** | "noting a list of stocks qualifying as top 'movers' (i.e., largest percentage change in price)" | 86 FR 49067 |
| 37 | **Default-on notifications with no opt-out** | SEC DEP release | **NA** | "in others, notifications may be set by default with no ability to opt-out" | 86 FR 49067 |
| 38 | **Frequency / inactivity prompts** | SEC DEP release | **NA** | "reminding them that it has been a certain number of days since they last engaged in a trade" | 86 FR 49067 |
| 39 | **Confetti / celebration animation** | SEC DEP release | **NA** | "embedded animations and graphics, such as digital confetti or crowds applauding, that 'celebrate' when investors enter orders" | 86 FR 49067 |
| 40 | **Curated lists / "ideas" at order placement** | SEC DEP release | **NA** | "Some digital platforms may present 'ideas' prior to allowing the investor to place an order. These ideas may involve curated lists or features" | 86 FR 49067 |
| 41 | Gamified, behaviour-influencing practice **generally** | SEC PDA proposal (withdrawn), 88 FR 53960 | **OUT** by the Commission's own analysis of the existing baseline | "These practices might not constitute recommendations, and therefore might not face the same obligations that recommendations would"; "some interactions covered by the proposed conflicts rules would not constitute recommendations for the purposes of Reg BI" | 88 FR 53960 (econ. analysis); withdrawn 90 FR 25531 |
| 42 | **"Call to action" / would influence an investor to trade** | Reg BI 84 FR 33335; NTM 01-23; RN 11-02 | **IN** — the master factor | "whether a communication 'reasonably could be viewed as a "call to action"' and 'reasonably would influence an investor to trade a particular security or group of securities'" | 84 FR 33335 & n.161 |
| 43 | Hyperlink to a tool on another site | NASD NTM 01-23 n.13 | **NA** — separate analysis | "hyperlinks conceivably could create suitability obligations, depending … on the extent to which a member endorses the content of the hyperlinked site" | NTM 01-23 n.13 |
| 44 | **Implicit / silent** hold | FINRA RN 12-25 A3 | **OUT** | "the new rule's 'hold' language would not apply when a broker remains silent regarding security positions in an account. The hold recommendation must be explicit." | RN 12-25 A3 |
| 45 | **Adoption of a third party's content by linking** | FINRA RN 17-18 A3, A5 | **IN** unless the link is "ongoing" and the firm has no influence or control | "By sharing or linking to specific content, the firm has adopted the content"; "Two factors are critical … (1) whether the link is 'ongoing' and (2) whether the firm has influence or control over the content of the third-party site" | RN 17-18 A3, A5 |
| 46 | A surface that is **primarily a vehicle for links** to others' content | FINRA RN 17-18 A4 | **IN** | "where the firm shares or links to content that itself serves primarily as a vehicle for links, or where content available through such links forms the entire basis of the article, the firm would have adopted the other content" | RN 17-18 A4 |
| 47 | **Promotion** of a specific product short of recommending it | FINRA RN 10-06 A3; SEC PDA proposal | **OUT** — a recognised distinct category | "communications that promote specific investment products, **even if these communications might not constitute a 'recommendation'** for purposes of our suitability rule or otherwise" | RN 10-06 A3 |
| 48 | Breadth of audience as a defence, once a recommendation exists | FINRA RN 10-06 A2 | **IN** — no defence | "Rule 2310 requires a broker-dealer to determine that a recommendation is suitable for **every investor to whom it is made**" | RN 10-06 A2 |
| 49 | **"100 Most Popular" / "Top Movers" curated lists**, provided to all customers by default | Mass. Sec. Div. v. Robinhood, Am. Compl. ¶¶35–40 | **ALLEGED IN — never adjudicated** | "This is no different from a broker-dealer agent handing a list of securities to a customer, pretending to be surprised when the customer purchases securities from that list, and then proclaiming that he made no recommendations"; "Despite providing these lists to all customers by default…" | Am. Compl. Summary at 4–5; ¶¶35–40 |
| 50 | The same, as characterised by the reviewing court | *Robinhood Fin. LLC v. Sec'y of the Commonwealth*, 492 Mass. 696, 4 n.5 & 5 n.7 (2023) | **NA — EXPRESSLY NOT DECIDED** | "each such practice, the Secretary alleged, **was tantamount to making investment recommendations** to customers"; "**We address only the purely legal issues presented on appeal, which are unaffected by this dispute of material fact.**" | 492 Mass. at 4 n.5, 5 n.7 |
| 51 | **Push notification that highlights a specific list** | Mass. Consent Order § VIII ¶C(e) | **BARRED by consent — no recommendation finding made** | "Permanently cease the future use of **generalized push notifications highlighting specific lists**" | Consent Order § VIII ¶C(e) |
| 52 | **Curated list cured by provenance disclosure** | Mass. Consent Order § VIII ¶C(a) | **OUT, if attributed** | "Add disclosures to lists on its platform that are based on Robinhood data … **indicating that the list is based on Robinhood data and not directly related to overall market data**" | Consent Order § VIII ¶C(a) |
| 53 | **Celebration animation** (confetti) | Mass. Consent Order § VIII ¶C(d) | **BARRED where causally tied to trading frequency** | "Permanently cease the future use of confetti … **or other celebratory imagery directly tied to frequency of trading**" | Consent Order § VIII ¶C(d) |
| 54 | **Emojis in the transaction life-cycle** | Mass. Consent Order § VIII ¶C(b) | **BARRED by consent** | "Remove all emojis from the life-cycle of a transaction" | Consent Order § VIII ¶C(b) |
| 55 | **Features mimicking games of chance** (scratch-off, tapping) | Mass. Consent Order § VIII ¶C(c), (f) | **BARRED by consent** | "Permanently cease features that mimic games of chance" | Consent Order § VIII ¶C(c), (f) |
| 56 | The **same free-stock scratch-off**, charged federally | FINRA AWC No. 2020066971201 | **NOT charged as a recommendation** — charged as a misleading advertisement under Rule 2210 | (AWC: "gamif" = 0, "confetti" = 0, "presentation" = 0 across the full document) | AWC 2020066971201 |
| 57 | Automated **approval bots** deciding customer eligibility | FINRA AWC No. 2020066971201 | **IN** as a supervision failure, not as a recommendation | "in practice, the firm relies on computer algorithms, with limited oversight by firm principals … 'option account approval bots'" | AWC 2020066971201 |
| 58 | **Paid influencer posts** promoting the firm | FINRA AWC No. 2019060756501 (6 Mar 2025) | **IN** as the firm's own retail communication — not as a recommendation | "**Influencers' posts promoting RHF were retail communications of RHF subject to FINRA Rule 2210.**" | AWC 2019060756501 |
| 59 | **Any means, method or mechanism to "feature or promote" a specific security** | NASAA proposed model rule subpart 1d(5) (Sep 2023; re-proposed Nov 2024) — **NOT ADOPTED** 7 Apr 2025 | **PROPOSED IN, THEN DROPPED** | "If the broker-dealer or agent utilized any means, method or mechanism to feature or promote an account type, specific security or investment strategy to a retail customer … then that transaction will not be deemed an unsolicited transaction, but rather **will be deemed a recommendation**" | NASAA proposed subpart 1d(5); absent from the adopted 7 Apr 2025 rule |
| 60 | **Prompts and "nudges" that encourage trading** | NASAA comment letter, File No. S7-10-21 (1 Oct 2021) at 3 | **ADVOCATED IN — never adopted** | "Applications or platforms that encourage trading through prompts and 'nudges' **are making recommendations, even if they are limited to recommendations simply to trade**" | NASAA S7-10-21 at 3 |
| 61 | **Alerts and top-investment lists delivered by frequent push** | NASAA S7-10-21 at 3 | **ADVOCATED IN — never adopted** | "Features such as alerts and top investment lists, especially when foisted onto investors through frequent push notifications, can prompt irrational trading decisions by triggering … a 'fear of missing out.'" | NASAA S7-10-21 at 3 |
| 62 | **"Ideas at order placement" / curated lists** | NASAA S7-10-21 at 4 | **ADVOCATED IN — never adopted** | "'ideas presented at order placement and other curated lists or features.' **These features also constitute advice or recommendations.**" | NASAA S7-10-21 at 4 |
| 63 | **"What your friends have recently purchased" / copy-trading** | NASAA S7-10-21 at 4 | **ADVOCATED IN — never adopted** | "Suggestions to copy the purchases and sales of particular traders or 'finfluencer's' are calls to action either by design or effect and should therefore be deemed recommendations" | NASAA S7-10-21 at 4 |
| 64 | **Algorithmic output generated from personal information the user supplies** | 17 C.F.R. § 275.203A-2(e)(2) | **IN — by Commission rule text** | "'digital investment advisory service' **is investment advice** to clients that is generated by the operational interactive website's software-based models, algorithms, or applications **based on personal information each client supplies**" | 17 CFR 275.203A-2(e)(2) |
| 65 | **Customer-operated interactive analysis tool** | Advisers Act Rule 206(4)-1(e)(8)(ii)(A); IA-5653, 86 FR 13082 | **OUT** of the hypothetical-performance regime, on four adviser-side conditions | "An interactive analysis tool **where a client or investor … uses the tool** …; provided that **the investment adviser**: (1)…(4)"; "**require the investor to interface directly with the tool**" | 206(4)-1(e)(8)(ii)(A); 86 FR 13082 |
| 66 | **Claiming a tool alone can pick securities** | IA-5653, 86 FR 13082 | **IN** — prohibited as a claim | "the adviser should **neither imply nor state that the interactive tool, alone, can determine which securities to buy or sell**" | 86 FR 13082 |
| 67 | **Per-investor tool outputs as separate advertisements** | IA-5653, 86 FR 13082 | **OUT** | "The fact that an interactive tool uses the same underlying assumptions **does not mean that outputs the tool generates are advertisements** (because the adviser or investor inputs investor-specific information)" | 86 FR 13082 |
| 68 | **Tool that favours certain investments** (adviser side) | Rule 206(4)-1(e)(8)(ii)(A)(3) | **NA** — triggers disclosure, not a recommendation finding | "explains how the tool determines which investments to select, **discloses if the tool favors certain investments and, if so, explains the reason for the selectivity**" | 206(4)-1(e)(8)(ii)(A)(3) |
| 69 | **The app interface itself as a "retail communication"** | FINRA AWC No. 2022076787601 (Stockpile, 29 Sep 2025) ◇ | **IN** as a communication — **not** as a recommendation | "the communications included a webpage, email, and **the firm's mobile application interface** and related promotional materials" | *Disciplinary and Other FINRA Actions*, Nov 2025, at 4 |
| 70 | **In-app forum posts carrying links to trade the security discussed** | FINRA AWC No. 2021072231801 (Webull, 8 May 2025) ◇ | **IN** as an unsupervised retail communication — not as a recommendation | "**Certain posts contained links to t[h]e f[i]r[m]'s website where users could trade those securities** through Webull Financial brokerage accounts" | Webull AWC at 9 |
| 71 | **Generic platform-wide disclosure offered in place of a security-specific one** | FINRA AWC No. 2022073414901 (Merrill Lynch, 18 Jun 2026) | **INSUFFICIENT** | "this disclosure **did not address whether market discounts were applicable to specific securities** and was provided for all municipal securities transactions, regardless of whether the security had a market discount" | Merrill AWC at 3 n.3 |
| 72 | **Self-directed status as an answer to Reg BI** | FINRA CEO testimony (6 May 2021) n.264 | **OUT** — where there is no recommendation | "**In the absence of a 'recommendation,' self-directed trading by retail investors does not implicate Reg BI.**" | Cook Statement, n.264 |
| 73 | **Subscription trading-signal newsletter naming instrument and side, wired to auto-trading** | *In re Murakami / GoTradeSignals*, Wash. DFI No. S-15-1626-15-SC01 (16 Jun 2016) | **IN** — unregistered investment adviser (state; settled, not adjudicated) | "By disseminating a subscription-based newsletter with **specific trading instructions** to investors with **auto-traded accounts**, GoTradeSignals and Murakami have operated as an unregistered investment adviser" | S-15-1626-15-SC01 ¶7 |
| 74 | **Third-party-prepared report or recommendation supplied to a client** | WAC 460-24A-220(9) | **NA** — disclosure duty, with an express carve-out | "Providing a report or recommendation … prepared by someone other than you **without disclosing that fact**. (This prohibition does not apply … where you use **published research reports or statistical analyses** to render advice…)" | WAC 460-24A-220(9) |
| 75 | **Platform's algorithmic allocation output** | *In re Global Predictions, Inc.*, IA-6574 (18 Mar 2024) | **IN** — described as recommendations (status uncontested; respondent already registered) | "an interactive online platform, **which makes investment allocation recommendations to clients** … PortfolioPilot makes allocation recommendations **utilizing algorithms**" | IA-6574 ¶3 |
| 76 | **A standardized firm template listing 3–5 named securities with amounts, share counts and prices** | *In re David Lerner Associates*, Rel. 34-105556 (SEC, 27 May 2026) ¶¶ 20, 33 | **IN** | "**CIPs are 'recommendations' under Regulation BI because they are 'individually tailored . . . to a specific customer,'** "'reasonably would influence an investor to trade a particular security or group of securities,'" and "'reasonably could be viewed as a "call to action."'" | 34-105556 ¶ 33 |
| 77 | **Disclaimers on such a template** — "illustrative purposes only", "not an offer", "not acting as fiduciaries", "examples of potential investments" instead of "suggested investments" | *David Lerner* ¶¶ 21, 27 | **NO EFFECT** | "**These changes to the CIP template did not alter that the CIPs were recommendations.**" | 34-105556 ¶ 27 |
| 78 | **A firm's own maintained position that its document is not a recommendation** | *David Lerner* ¶¶ 24–26 | **NO EFFECT** | "DLA took the position that CIPs were not 'recommendations' … After receiving the Deficiency Letter, DLA **maintained its position** … and did not make any changes" | 34-105556 ¶¶ 24, 26 |
| 79 | **Saying you are not recommending, and actively discouraging the trade** | *Siegel*, Rel. 34-58737 at 12; 592 F.3d 147 | **NO EFFECT** | "**Yet, these statements do not change the conclusion that he made a recommendation.**" | 34-58737 at 12 |
| 80 | **A firm-wide promotional campaign that "whetted" the customer's interest** | *Siegel* n.21, citing *Gordon Scott Venters*, 51 S.E.C. 292, 294 (1993) | **IN** — as a factor | "where customer's interest in investment was **whetted by salesperson's and firm's promotional campaign**" | 34-58737 n.21 |
| 81 | **A standing agreement to monitor, plus recurring evaluation** | Reg BI adopting release, 84 FR 33335 n.155; corroborated in the 30 Jan 2023 Risk Alert | **IN** — a recommendation at each occurrence | "agreed-upon account monitoring services **involve an implicit recommendation to hold** … **at the time agreed-upon monitoring occurs**" | 84 FR 33335 n.155 |
| 82 | **Unsolicited orders** | Reg BI adopting release, 84 FR 33337 n.176 | **OUT** | Reg BI does not extend "by applying the duty to unsolicited orders" | 84 FR 33337 n.176 |
| 83 | **A firm's internal "list of approved investments"** (product shelf) | *SEC v. Western International Securities*, Compl. ¶ 55 | **NOT ADDRESSED** — never a customer-facing list | "Prior to adding the June 2020 issuance of L Bonds to its **list of approved investments** for registered representatives to recommend…" | Compl. ¶ 55 |

---

## Negative findings

Each documents where I looked, with the endpoint and the query. Absence is documented, not inferred.

**N1 · One regulator has now applied NTM 01-23's framework to document-and-list facts; none has applied it to a screener, ranking, watchlist or gamified interface.** **Correcting this register's earlier drafting:** *In re David Lerner Associates, Inc.*, Rel. 34-105556 (27 May 2026) (S5-34) applies the 01-23 / Reg BI factors to a firm-designed template listing three to five securities and finds a recommendation. *Siegel*, Rel. 34-58737 (SEC 2008), *aff'd*, 592 F.3d 147 (D.C. Cir. 2010) (S5-35) applies the same factors, and is the only post-2000 federal appellate application located — on live oral-pitch facts. **But no located decision or order applies them to a screener, a ranking, a watchlist, a "top movers" list, a leaderboard or a gamified interface**, and on that narrower question both poles of Answer A still rest on 2001 hypotheticals. Corpus searched by me directly: FINRA Rules 2090/2111/2210/2214; NASD NTMs 96-60, 01-23, 04-86; FINRA RNs 10-06, 11-02, 11-39, 12-25, 12-29, 16-41, 17-18, 19-31, 21-17, 21-19, 22-08, 23-17, 24-09; the FINRA 2021 Examination Report; the FINRA 2016 Digital Investment Advice report; FINRA Annual Regulatory Oversight Reports 2025 and 2026; Reg BI adopting release (84 FR 33318, complete); DEP release (86 FR 49067, complete); PDA proposal (88 FR 53960, complete) and its withdrawal (90 FR 25531); SEC exam priorities FY2022–FY2026. Plus the commissioned sweeps at N15–N21.

**N2 · No US authority located that attaches a legal consequence to visual emphasis, colour, badges, leaderboards, confetti, top-movers lists, default-on notifications, or delivery frequency in the recommendation analysis.** The SEC's DEP release catalogues every one of them (S5-11, table rows 33–40) and states only that a DEP "**may** … constitute a recommendation," referring the reader back to 01-23 and the Reg BI adopting release. FINRA's 2021 exam report asks firms the same question and gives no answer (S5-10). RN 22-08 asks whether push notifications should be restricted and imposes nothing (S5-09). The only rulemaking that would have reached these features was **withdrawn on 17 June 2025** with the statement that the Commission "does not intend to issue final rules with respect to these proposals" (90 FR 25531). Endpoints: federalregister.gov API `conditions[term]="digital engagement practices"` → **count 8** (four of them Sunshine Act meeting notices); the four substantive documents are the DEP release, the PDA proposal, and two internet-adviser-exemption releases. Retrieved 7 Sep 2026.

**N3 · The phrase "criteria selected by the customer" and its variants appear nowhere in the corpus except NTM 01-23.** Normalized (whitespace-collapsed, case-folded) search across **33 retrieved primary texts** — every FINRA rule and notice listed in this register, the Reg BI adopting release, the DEP release, the PDA proposal and its withdrawal notice, the FINRA 2021 Examination Report, the FINRA 2016 Digital Investment Advice report, the FINRA 2025 and 2026 Annual Regulatory Oversight Reports, and the SEC Division of Examinations priorities for FY2022–FY2026. **Exactly three files returned a hit, and they are mutually exclusive:** NTM 01-23 ("criteria selected by the customer" ×1, "selected by the customer" ×1, "customer selects" ×1); the DEP release ("criteria developed by the firm" ×1, describing leaderboards); FINRA RN 11-39 ("criteria followed by vendors" ×1, a data-feed accuracy obligation). **All 30 other files returned zero.** See Answer B and search log #50 (which supersedes the narrower earlier sweep at #23).

**N4 · FINRA Rule 2111 does not define "recommendation," and FINRA has said so deliberately.** Verified by reading the complete rule and all eight items of Supplementary Material at the rulebook URL. Confirmed by FINRA RN 12-25 A2 ("Although FINRA does not define the term 'recommendation'…") and by FINRA's own statement to the Commission quoted at 84 FR 33335 n.165 ("defining the term 'recommendation' is unnecessary and would raise many complex issues in the absence of specific facts of a particular case").

**N5 · The "FINRA 2021 report on gamification" named in the commissioning brief does not exist under that description.** Regulatory Notice 21-19 is *Short Interest Position Reporting Enhancements*, not gamification (verified: https://www.finra.org/rules-guidance/notices/21-19, retrieved 7 Sep 2026, full text fetched and read). The actual FINRA 2021 primary text on game-like features is the **2021 Report on FINRA's Examination and Risk Monitoring Program** (Feb 2021), Communications with the Public section — catalogued here as S5-10. Two further FINRA documents surfaced under this heading (`2021_SF_Gamification.pdf`, `2022_AC_Gamification.pdf`) are **conference panel materials**, not guidance, and are **not** relied on for any proposition in this register.

**N6 · finra.org's HTTP 429 is a Cloudflare managed challenge, NOT rate limiting — correcting my own earlier characterisation.** The 429 body was captured and read: `Just a moment...` / `Enable JavaScript and cookies to continue` / `window._cf_chl_opt = {… cType: 'managed', … cZone: 'www.finra.org'}` / `a.src = '/cdn-cgi/challenge-platform/h/g/orchestrate/chl_page/v1?ray=…'`. A real browser clears it in about 8 seconds. It is **not** confined to query strings: three monthly-newsletter PDF URLs with no query string and roughly 75 constructed `fda_documents` URLs also returned HTTP 200 **with the Cloudflare interstitial instead of a PDF**. My paced retries below did eventually succeed, which is consistent with a challenge that fires probabilistically rather than a fixed quota — but **"wait and retry" is not a reliable remedy, and anyone repeating this work should plan on a browser route.** The description of these failures as "rate limiting" in the earlier drafting of this register was wrong and is corrected here.

**N6a · The sweep as actually constrained.** On a first batched pass, notices 10-06, 11-39, 12-29, 17-18, 19-31, 16-41, 21-17, 23-17 and 24-09 all returned **HTTP 429 Too Many Requests**. A paced retry (60–90 s between requests, up to 4 attempts each) ultimately recovered **all five** of the priority set plus 04-86: **04-86**, **10-06** (→ S5-15), **17-18** (→ S5-16), **19-31**, **11-39** (→ S5-18, on the third attempt) and **12-29** (→ S5-19). A final pass then recovered **16-41**, **21-17**, **23-17** and **24-09** as well. **Every FINRA notice in the candidate set has now been retrieved and read; none remains unverified.** 16-41, 21-17 and 23-17 are null for this track (see the ◇ list for their counts and, in two cases, their actual subjects). **The ◇ item recording second-hand reliance on RN 11-39 is now closed** — it was retrieved directly and both propositions attributed to it through RN 17-18 are confirmed verbatim.

**RN 19-31 (Disclosure Innovations in Advertising and Other Communications with the Public, 19 Sep 2019) was retrieved in full (103,743 B) and read: it produced no material on the recommendation line and is deliberately not given a register entry.** Its subject is the prominence and layering of *required disclosure*, not whether a communication is a recommendation. Its one presentation-relevant sentence is: *"FINRA recognizes that there are multiple ways to address the prominence of required information, and electronic media and design innovations may open new possibilities."* Its only other bearing is a reminder that *"a post-sale communication that recommends additional purchases"* is treated differently from one that merely reports on a holding. Its reference to Rule 2214 is a related-rules sidebar link, not substantive text. Recorded here so that the check is on the record rather than the notice merely being absent. Do not treat their absence from this register as a finding about their content. On the evidence of 10-06 and 17-18 — the two closest of the set, both recovered — the social-media/digital-communications line of notices routes the recommendation question back to NTM 01-23 rather than adding to it, but that is an inference from two of nine and is not asserted as a finding.

**N7 · No FINRA notice located that answers the question FINRA itself has repeatedly asked.** FINRA raised the app-interactivity/recommendation question in the 2021 Exam Report (S5-10), asked in RN 22-08 whether platform communications that "do not rise to the level of a 'recommendation'" need separate guardrails and whether push notifications should be restricted (S5-09), and in RN 10-06 (2010) and RN 17-18 (2017) referred firms back to NTM 01-23. Across every FINRA document retrieved in this track, **NTM 01-23 remains the most recent SRO text that actually decides which tool presentations are and are not recommendations.** Twenty-five years of subsequent guidance restates it, cites it, or asks questions around it.

**N8 · A digital-engagement examination sweep was announced for FY2022 and FY2023 (S5-17); no published outcome of it was located in this track.** No Risk Alert, no "examination observations" report, and no enforcement action tied to the DEP sweep was found in the material retrieved here. Endpoints searched by me: sec.gov/files/2022-, 2023-, 2024-, 2025-, 2026-exam-priorities.pdf (all five HTTP 200, sizes 7.6 MB / 9.5 MB / 5.9 MB / 0.9 MB / 1.7 MB, each converted with `pdftotext -layout` and grepped for "digital engagement", "gamification", "game-like", "behavioral prompt" — counts 1 / 1 / **0** / 2 / **0**). The DEP topic is absent from FY2024 and FY2026 entirely. **This is a documented absence in one source family only.** A dedicated sweep of Risk Alerts and of the Reg BI enforcement docket was commissioned separately and is pending; until it reports, no zero may be asserted for SEC enforcement or for Risk Alerts.

**N9 · No tribunal anywhere has ever decided whether a curated list, ranking, "top movers" list or list-linked push notification is a recommendation.** The one attempt — Massachusetts against Robinhood — was pleaded (S5-29), expressly reserved as a "dispute of material fact" by the Supreme Judicial Court (492 Mass. at 5 n.7), remanded, and then settled in January 2024 on supervision and commercial-honor grounds with the fiduciary count dropped and **zero occurrences of "fiduciary", "950 CMR 12.207", "best interest" or "solicit"** in the consent order (S5-30). No petition for certiorari was filed (U.S. Sup. Ct. docket 23A416: an extension application granted to 22 Jan 2024, empty `RelatedCaseNumber`, docket regenerated 11 Aug 2025). **The theory is live and untested.** *Method limits: the post-remand Suffolk Superior Court docket for No. 2184CV00884 could not be reached — masscourts.org returns HTTP 000 to non-browser clients, ma-appellatecourts.org returns HTTP 403 (Cloudflare), and no Wayback capture of the trial docket exists after Nov 2022. How and when the remanded civil action terminated is therefore **NOT ESTABLISHED**; what is established is that the judgment invalidating the rule was reversed.*

**N10 · Neither federal regulator charged Robinhood's interface as making recommendations, and the counts are documented.** FINRA AWC No. 2020066971201 (Jun 2021): "gamif" = 0, "confetti" = 0, "presentation" = 0; "recommend" ×6, all in consultant undertakings. SEC Rel. 33-10906 / 34-90694 (Dec 2020): "gamif" = 0, "confetti" = 0, "user interface" = 0, "notification" = 0, "digital engagement" = 0, "suitab" = 0; "recommend" ×12, all in consultant undertakings. FINRA AWC No. 2019060756501 (Mar 2025), the most recent located: the presentation count is paid-influencer posts treated as the firm's own retail communications under Rule 2210, not as recommendations. **This is a quantified silence on the most-scrutinised retail interface in the market, not an inference from absence.** *Limits: SEC administrative proceedings for 2024–2026 were not swept exhaustively for further Robinhood orders; efts.sec.gov full-text endpoints were not exercised in that pass. No claim is made either way.*

**N11 · "People also bought" appears in none of the primary Robinhood documents.** Searched: original complaint, amended complaint, consent order, Superior Court decision, SJC opinion, both FINRA AWCs, and the SEC order — **0 hits in all eight.** Massachusetts framed social proof as *popularity / most-traded* ("First List … chosen based on their popularity on Robinhood's platform"; "100 Most Popular"), never as peer-purchase.

**N12 · No count or frequency of push notifications is alleged in the Robinhood record** — the only frequency word is "daily" (Am. Compl. ¶50); what the Division quantified was trading volume, not notification volume. Any "N notifications sent" figure circulating elsewhere is not from these documents and is UNVERIFIED.

**N13 · FINRA has dropped digital engagement practices from its annual oversight reports.** FINRA's Annual Regulatory Oversight Reports for **2025** and **2026** each contain **zero** occurrences of "digital engagement", "gamification", "game-like" and "01-23" (full-text extraction of both PDFs, 1.5 MB each, retrieved 7 Sep 2026). This mirrors the SEC's pattern at N8 (topic present FY2022–FY2023, absent FY2024 and FY2026). Read together: **both regulators raised the question of whether app presentation makes recommendations, neither answered it, and both have since stopped asking it in their published programmes.** That is documented absence in two specific source families, not a conclusion about exposure.

**N14 · The Reg BI adopting release never addresses lists, screeners or watchlists, and its "menu" language is about something else.** Full-text term counts over the complete release (84 FR 33318–33492, 1,597,471 bytes, retrieved 7 Sep 2026): **"list of securities" 0 · "screener" 0 · "watch list" 0 · "watchlist" 0 · "alert" 1** (and that one is unrelated). "menu of" appears **27** times, but every occurrence read is about a firm's **product shelf** — "a broker-dealer's menu of products offered (sometimes referred to as shelf space)", "a limited menu of proprietary funds", "whether and how to restrict their menu of investment options" — i.e. the limited-menu **conflict-of-interest** problem under the Care and Conflict of Interest Obligations. **It is not the "menu of nine" sense of *Park* and *Terry's Tips*** (already in P7), and it does not bear on whether presenting a menu is itself a recommendation. Worth noting neutrally: the release consistently speaks of recommendations made *from* a limited menu ("protecting the interests of retail customers **when recommendations are made from such limited** [menus]"), which treats the menu as the inventory and the recommendation as a separate act — but the Commission nowhere says so as a holding, and it should not be cited as if it had.

**N15 · The FINRA Disciplinary Actions Online database was NEVER QUERIED — no zero from it may be reported, in either direction.** Its architecture was established: server-rendered Drupal 10.5.12 (not a SPA); it accepts **no** URL query parameter (`?fda_search=churning` renders the empty landing form, confirmed in a real browser as well as by curl); there is **no JSON/API endpoint**; it is a CSRF-protected POST webform (`form_id=webform_submission__finra_disciplinary_actions_onli_node_9274_add_form`) gated by a **required Terms of Use checkbox** — "By selecting this box, I agree to the Terms of Use. (Required)" — which sets `disciplinary-actions-agreed=true`. **The researcher declined to accept FINRA's Terms of Use on the client's behalf without instruction, which is the correct call.** Consequence: every FINRA "zero" in this register comes from the substitutes at N16, not from FINRA's own database. **This gate is one click from open and should be opened before any final reliance.**

**N16 · Substitute FINRA sweep — 83 monthly newsletters, and it is a hard zero on this track's subject.** FINRA's monthly *Disciplinary and Other FINRA Actions* newsletters report every FINRA AWC, OHO and NAC action in the period. **93 downloaded, 90 valid PDFs, 83 text-extracted, covering June 2019 – August 2026.** Keyword sweep across all 83 returned **zero files** for: gamification, leaderboard, confetti, top mover, watchlist, screener / stock screener, curated, most popular, ranked list, people also bought, push notification, trending, digital engagement, recommended list, focus list, buy list, top pick, featured list, highlighted list, stock list, user interface, order entry screen, app design, and execution-only. ("watch list" hit 5 files and "ranking" 4 — all unrelated, AML/OFAC watch lists and arbitrator rankings.) Productive terms were **influencer (7 files)**, **self-directed (7 files)** and **mobile application (5 files)** → S5-25. `constituted a recommendation` hit **1** file (Canaccord Genuity, private placements — not an interface). `did not make recommendations` / `non-recommending`: **0**.
*Two limits, stated plainly:* (i) this searches FINRA's own **summaries** of AWCs, so a sanction resting on a ranking or screener described only in the underlying AWC would not surface; (ii) **three months are blind — April 2021, August 2023 and November 2024** returned HTTP 200 with the Cloudflare interstitial. Strong evidence of absence, not proof.

**N17 · State sweeps: three states swept with hard zeros, four states not swept at all.** **Texas** — 26 index pages, **247 administrative orders 2016–2026**; sweep for gamification, screener, digital engagement, curated, watchlist, trading signal, push notification, leaderboard, top mover, trading app, software, algorithm → **all zero** (Robinhood = 1). **Wisconsin** — **1,070 orders 1998–2026**; same sweep → **zero**. **Washington** — 2002–2026 archive plus the 2025–26 database; only *GoTradeSignals* (S5-27) responsive. **California DFPI** and **Washington** Robinhood consent orders, both readable in full text, contain **zero** occurrences of gamification, solicit, curated, confetti, screener, watchlist and top movers; both rest on supervisory failures, outages, options/margin diligence and customer service. **NOT SWEPT: New York (zero queries run), Alabama (order index is a JS nav shell with no links), Vermont (index not located), New Jersey (Incapsula JS stub; `nj.gov/oag/bos` 404).** Those four are **not-founds, not confirmed absences.** *Limit: the Texas and Wisconsin sweeps searched index/summary text, not the full text of each order.*

**N18 · New Jersey abandoned its fiduciary rule while expressly naming gamification as the reason the question is open.** NJ OAG press release, 24 Dec 2021 (https://www.njoag.gov/new-jersey-bureau-of-securities-proposal-for-fiduciary-rule-will-expire-as-bureau-continues-efforts-to-protect-investors-in-an-evolving-market/, HTTP 200): the 2019 proposal (N.J.A.C. 13:47A-6.4) expired 1 Jan 2022. Verbatim: *"the use of gaming features (for example, point scoring and competition with other investors) to increase trading activity, a practice known as 'gamification.'"* and *"the Investor Advocate at the Securities and Exchange Commission ('SEC') has questioned **whether investor protection standards should turn on whether a broker-dealer makes a specific recommendation** – as parts of the Bureau's 2019 proposal do."* The Bureau said it "will not hesitate to use its **existing** regulations and enforcement authority." **A third instance of the S5-12 / S5-22 pattern: a regulator identifies presentation as the problem, declines to solve it by rule, and falls back on existing authority.**

**N19 · "Interactive analysis tool" / "investment analysis tool" appears nowhere in the SEC's Marketing Rule FAQs or in any of its four Marketing Rule Risk Alerts.** Marketing Rule FAQ page (https://www.sec.gov/investment/marketing-faq, HTTP 200, 98,846 B): **0** hits for "interactive analysis", "investment analysis tool", "calculator", "screener" and bare "tool". The 2022 announcement, 2023 phase-3, 2024 observations and 2025 observations Risk Alerts (all HTTP 200): **0** hits each. **The Commission has issued no interpretive gloss on Rule 206(4)-1(e)(8)(ii)(A) since adoption.**

**N20 · EDGAR full-text search is useless for this question, and that is worth recording so it is not re-tried.** `efts.sec.gov/LATEST/search-index?q="interactive analysis tool"` returned **HTTP 200, 3 hits — all corporate filings** (e.g. a Bayer 20-F). **EDGAR FTS does not index enforcement releases, staff guidance or risk alerts.** Separately, `search.usa.gov` and `secsearch.sec.gov` both returned **HTTP 202 with 0 bytes** to non-browser clients, and the parameterised listing searches failed (`/admin-proceedings?search=` → HTTP 403; `/litreleases?search=` → HTTP 404).

**N21 · The two exhaustiveness attempts on SEC enforcement FAILED, and their zeros are worthless.** A machine enumeration of every SEC administrative order since the Reg BI compliance date harvested 71 listing pages (**7,096 rows**, 2016-03-31 → 2026-09-04) and isolated **3,663 order PDFs dated on or after 30 June 2020**; the full-text scan for `15l-1|Regulation Best Interest` returned **HTTP 429 on essentially every request** (3,586 NOTEXT on the first run, 4,191 on the second) even at 3 workers with 4× retry and 1.2 s spacing, because other processes were hitting sec.gov concurrently. The same happened to a sweep of the Commission-opinions corpus: 58 listing pages (**5,445 rows**, 1997-09-22 → 2026-09-01), **2,122 non-procedural opinion PDFs**, scan defeated by 429. **The Reg BI action list at S5-37 is verified but NOT provably exhaustive, and no zero from either bulk scan may be reported.** URL lists are on disk (`…/scratchpad/secl/ap_urls.txt`, `…/scratchpad/opin/op_urls.txt`) and both scans can be re-run from a quiet host.

**N22 · CourtListener's anonymous quota was exhausted mid-sweep, and one apparent zero is an artefact.** The anonymous limit is **5/min AND 50/hour AND a daily cap, shared per IP**; the last responses read `Rate limit exceeded: 50/hour` and `Expected available in 82721 seconds` (≈23 h). Counts obtained are at S5-37. **Not obtained:** `"menu of nine"`, `cites:(2404954)`, `cites:(2290926)`, `"reasonably would influence an investor to trade"`, `"99 F. Supp. 2d 889"`, `"409 F. Supp. 2d 526"`. **⚠️ The 0 returned for `"content, context and manner of presentation"` is an artefact of the wrong string** — that is FINRA RN 11-02's wording; NTM 01-23 and *Siegel* say "content, context, **and presentation**" without "manner of", and the correct string was never run. **Do not cite that zero.** The `/opinions/{id}/` endpoint requires a token (HTTP 401), CourtListener opinion HTML returns HTTP 202 with 0 bytes to curl, and Justia returns HTTP 403 — so the two candidate later-citing cases for *Park* / *Terry's Tips* (*SEC v. Pirate Investor LLC*, 580 F.3d 233 (4th Cir. 2009); *Joseph v. Equity Edge, LLC*, 192 P.3d 573 (Colo. App. 2008)) remain **UNVERIFIED**.

**N23 · Two independent investigations agree the FINRA disciplinary search is unusable, for two different reasons — and neither produced a query result.** One established a **required Terms-of-Use checkbox** it declined to accept on the client's behalf (N15). The other got past the form — POSTing `fda_search=churning` returns **HTTP 302** to `…/finra-disciplinary-actions?search=churning`, so **URL parameters are honoured** — but the results page is **not server-rendered**: HTTP 200, 73,121 bytes, `<tr>` count **0**, `views-row` **0**, `view-content` **0**, `pager` **0**, `AWC` **0**, `<main>` region **1 character long**, with no `/views/ajax`, `/api/`, Solr or Elasticsearch endpoint anywhere in the source or in `drupalSettings`. A separate egress path (WebFetch) confirmed no results render. finra.org then blocked the host entirely (429 → 403 Cloudflare). **The control query "churning" never once returned a result. No FINRA disciplinary count or zero is reported anywhere in this register from that database.** It requires a real browser session.

**N24 · Correction to the brief's NAC URL, and the NAC corpus is 97% unexamined.** `finra.org/rules-guidance/adjudication-decisions/nac-decisions` returns **HTTP 404**. The live URL is `https://www.finra.org/rules-guidance/adjudication-decisions/national-adjudicatory-council-nac` — 25 decisions per page, **33 pages (~825 decisions)**, paginated `?page=N-1`. **Page 1 only was enumerated** (none of those 25 involves a list, tool or automated communication); pages 2–33 were unreachable behind Cloudflare. **This is a 97% gap in the NAC corpus and it is not an absence.**

**N25 · A lead worth chasing, flagged UNVERIFIED.** A search result referenced a 1999 NASD NAC decision, ***Dep't of Enforcement v. Kunz***, for the proposition that **distributing an issuer's offering document did not by itself constitute a recommendation** — a "held NOT to be a recommendation" holding on impersonal-document facts, which is the direction this track most lacks. It is pre-2000 (outside the brief's window) and the decision text could not be reached (finra.org HTTP 403). **Marked ◇; not relied on anywhere.** Note it would sit alongside FINRA RN 12-25 A2's statement that "a broker-dealer's use or distribution of marketing or offering materials ordinarily would not, by itself, constitute a 'recommendation'."

**All commissioned sweeps have now reported.** Massachusetts is at S5-29 → S5-33; the FINRA-disciplinary, state-regulator and Marketing-Rule strand at S5-21 → S5-28 and N15 → N20; the enforcement and adjudication strand at S5-34 → S5-37 and N21 → N25. **What remains open is not unstarted work but blocked work**, and each blockage is recorded with its endpoint and response: the FINRA disciplinary database (client-rendered behind Cloudflare, plus a Terms-of-Use gate — N15, N23); 97% of the NAC corpus (N24); the two SEC bulk scans (N21); six CourtListener queries including the corrected "content, context, and presentation" string (N22); New York, Alabama, Vermont and New Jersey (N17); and NASAA's reason for dropping subpart 1d(5) (S5-22).

---

## Search log

| # | Source / query | Endpoint | Date | Result / access note |
|---|---|---|---|---|
| 1 | FINRA Rule 2214 | finra.org/rules-guidance/rulebooks/finra-rules/2214 | 7 Sep 2026 | HTTP 200, 102,939 B — full rule + all 6 Supp. Mat. items, server-rendered |
| 2 | FINRA Rule 2111 | …/finra-rules/2111 | 7 Sep 2026 | HTTP 200, 110,079 B — full rule + .01–.08 |
| 3 | FINRA Rule 2210 | …/finra-rules/2210 | 7 Sep 2026 | HTTP 200, 148,715 B — full rule incl. (d)(1)(A)–(F) |
| 4 | FINRA Rule 2090 | …/finra-rules/2090 | 7 Sep 2026 | HTTP 200, 92,401 B — no bearing on tools; not used |
| 5 | NASD NTM 01-23 | finra.org/rules-guidance/notices/01-23 | 7 Sep 2026 | HTTP 200, 124,075 B — **full text incl. all 8 examples, 5 guidelines and endnotes 1–19** |
| 6 | FINRA RN 11-02 | …/notices/11-02 | 7 Sep 2026 | HTTP 200, 124,755 B — guiding-principles passage at pp. 2–3 recovered |
| 7 | FINRA RN 12-25 | …/notices/12-25 | 7 Sep 2026 | HTTP 200, 184,853 B — A2, A3, A8, nn. 41–43 recovered |
| 8 | FINRA RN 22-08 | …/notices/22-08 | 7 Sep 2026 | HTTP 200, 247,836 B — n.60, n.80 and the platform/push-notification questions recovered |
| 9 | FINRA RN 21-19 | …/notices/21-19 | 7 Sep 2026 | HTTP 200, 227,638 B — **is short-interest reporting, NOT gamification**; zero hits for gamif/game-like/leaderboard/badge/digital engagement. See N5 |
| 10 | NASD NTM 96-60 | …/notices/96-60 | 7 Sep 2026 | HTTP 200, 93,462 B — "brings a specific security to the attention" passage recovered |
| 11 | FINRA notices 21-17, 19-31, 16-41, 12-29, 04-86, 17-18, 23-17, 24-09 (batched) | …/notices/<n> | 7 Sep 2026 | **HTTP 429** on all eight — rate limit hit after 6 successful fetches |
| 12 | Federal Register API — `conditions[term]="digital engagement practices"` | federalregister.gov/api/v1/documents.json | 7 Sep 2026 | **count 8**; substantive: 86 FR 49067 (DEP), 88 FR 53960 (PDA), 88 FR 50076 & 89 FR 24693 (internet advisers); 4 × Sunshine Act notices |
| 13 | SEC DEP release full text | federalregister.gov/documents/full_text/text/2021/09/01/2021-18901.txt | 7 Sep 2026 | 177,935 B; 25 occurrences of "recommendation"; all feature definitions recovered |
| 14 | Federal Register API — `"Withdrawal of Proposed Rules"` + SEC | federalregister.gov/api/v1/documents.json | 7 Sep 2026 | **count 4**; identified 90 FR 25531 (17 Jun 2025) |
| 15 | SEC withdrawal notice full text | …/full_text/text/2025/06/17/2025-11110.txt | 7 Sep 2026 | 17,612 B — confirms 88 FR 53960 withdrawn; Release Nos. 33-11377/34-103247/IA-6885/IC-35635 |
| 16 | SEC PDA proposal full text | …/full_text/text/2023/08/09/2023-16377.txt | 7 Sep 2026 | 566,920 B — definitions and economic-analysis admissions recovered (note: FR text is line-wrapped; phrase search requires whitespace normalization) |
| 17 | Reg BI adopting release full text | …/full_text/text/2019/07/12/2019-12164.txt | 7 Sep 2026 | 1,597,471 B — pin-cites verified by counting `[[Page N]]` markers: 33335 (factors; self-directed), 33338 (n.182 narrowing; education), 33402 (n.853 model-generated) |
| 18 | FINRA notices 04-86, 10-06, 17-18, 12-29, 19-31, 11-39 — paced retry, 20 s between | finra.org/rules-guidance/notices/<n> | 7 Sep 2026 | 04-86 **HTTP 200, 111,199 B**; the other five **HTTP 429**. See N6 |
| 19 | WebSearch: FINRA 2021 gamification report (domain-limited to finra.org) | web search | 7 Sep 2026 | Identified the 2021 Exam Report as the primary FINRA text; also surfaced two conference PDFs (not relied on) |
| 20 | FINRA 2021 Exam & Risk Monitoring Report PDF | finra.org/sites/default/files/2021-02/2021-report-finras-examination-risk-monitoring-program.pdf | 7 Sep 2026 | HTTP 200, 449,252 B; `pdftotext -layout`; game-like passages at report lines 103, 980–984, 1052–1066 |
| 21 | FINRA 2021 Exam Report, Communications-with-the-Public HTML section | finra.org/rules-guidance/guidance/reports/2021-…/communications-with-public | 7 Sep 2026 | **HTTP 429** — substituted the PDF at #20, which carries the same text |
| 22 | FINRA gamification conference PDFs | finra.org/sites/default/files/2021-10/2021_SF_Gamification.pdf; …/2022-05/2022_AC_Gamification.pdf | 7 Sep 2026 | HTTP 200, 415,238 B / 2,468,635 B — **conference panel materials, not guidance; not relied on** (N5) |
| 23 | Phrase sweep: "criteria selected by the customer" / "selected by the customer" / "criteria the customer" / "customer selects" / "customer-selected" / "criteria developed by the firm" | local normalized search over regbi.txt, dep.txt, pda.txt + all 10 retrieved FINRA rule/notice texts | 7 Sep 2026 | **Hits only in txt_n_01-23.txt** (3 variants, 1 each) and dep.txt ("criteria developed by the firm", 1). All other files **0**. See N3 |
| 24 | FINRA Report on Digital Investment Advice (Mar 2016) | finra.org/sites/default/files/digital-investment-advice-report.pdf | 7 Sep 2026 | HTTP 200, 285,481 B; `pdftotext -layout`; "recommend specific securities" passage at report p. 2, rep-responsibility passage at p. 8 → S5-14. (Two other path guesses returned HTTP 404 with a 77,746 B error page — a reminder to check size, not status) |
| 25 | FINRA notices 10-06, 17-18, 19-31, 11-39, 12-29 — paced retry, 60–90 s, 4 attempts each | finra.org/rules-guidance/notices/<n> | 7 Sep 2026 | **19-31 HTTP 200, 103,743 B — read, no recommendation-line content (N6)**; **10-06 HTTP 200, 119,230 B** → S5-15; **17-18 HTTP 200, 113,921 B** → S5-16; 19-31, 11-39, 12-29 still in retry / unverified (N6) |
| 26 | RN 17-18 — occurrences of "recommend" | local grep over extracted text | 7 Sep 2026 | **1 hit**, and it refers to a 2014 retrospective review recommending more guidance — not the recommendation element. Recorded as a negative result, not an omission |
| 27 | SEC Division of Examinations priorities FY2022–FY2026 | sec.gov/files/<year>-exam-priorities.pdf | 7 Sep 2026 | All five HTTP 200 (7.6/9.5/5.9/0.9/1.7 MB). `pdftotext -layout` + grep "digital engagement"/"gamification"/"game-like"/"behavioral prompt" → counts **FY2022 1, FY2023 1, FY2024 0, FY2025 2, FY2026 0** → S5-17, N8 |
| 28 | Mass. Sec. Div. v. Robinhood — original & amended administrative complaints | sec.state.ma.us/divisions/securities/download/MSD-Robinhood-Financial-LLC-Complaint-E-2020-0047.pdf ; …/MSD-Robinhood-Amended-Complaint-Docket%20No-%20E-2020-0047.pdf | 7 Sep 2026 | HTTP 200, 2.78 MB / 424 KB. Original PDF carries **two overlapping OCR layers** — amended version used for quotation where texts are identical |
| 29 | Mass. Consent Order (E-2020-0047, E-2022-0006) | sec.state.ma.us/divisions/securities/download/RH-Consent-Order.pdf | 7 Sep 2026 | HTTP 200, 1.0 MB, 26 pp. Term counts: **"fiduciary" 0 · "12.207" 0 · "best interest" 0 · "solicit" 0**; "recommend*" 11, none in the securities sense. Execution day handwritten and OCR-illegible |
| 30 | *Robinhood Fin. LLC v. Sec'y of the Commonwealth*, SJC-13381 slip opinion | mass.gov/files/documents/2023/08/25/y13381.pdf → **HTTP 403** (Akamai WAF); obtained from storage.courtlistener.com/pdf/2023/08/25/… | 7 Sep 2026 | HTTP 200, 204,331 B, SHA-1 f586f058aa77fdea61a7fda270513550b503adf2. Citation **492 Mass. 696**, decided 25 Aug 2023, rescript 22 Sep 2023 — verified against the SJC's own docket via Wayback capture 20231119171129 |
| 31 | Superior Court Memorandum of Decision (30 Mar 2022) + trial docket | mass.gov/doc/robinhood-financial-llc-v-william-f-galvin-dar-29119/download → **HTTP 403**; via Wayback 20250901031007 | 7 Sep 2026 | HTTP 200, 1.68 MB — recovered as Exhibit C to the Application for Direct Appellate Review (DAR-29119), which also carries the Superior Court docket. Final Judgment entered **18 Aug 2022**; notice of appeal 6 Sep 2022 |
| 32 | U.S. Supreme Court docket 23A416 | supremecourt.gov/docket/docketfiles/html/public/23A416.html ; /rss/cases/JSON/23A416.json | 7 Sep 2026 | Both HTTP 200. **Two entries only**; extension granted by Justice Jackson to 22 Jan 2024; `RelatedCaseNumber: []`; docket regenerated 11 Aug 2025 → **no cert petition filed** |
| 33 | 950 CMR 12.200 codified chapter (incl. 12.204, 12.207) | mass.gov/doc/950-cmr-12-…/download → **HTTP 403**; via Wayback capture 20260214190202 | 7 Sep 2026 | HTTP 200, 216,383 B. Cross-checked against the Division's adopted text (sec.state.ma.us/sct/sctfiduciaryconductstandard/Amended-Regulations.pdf, Wayback 20200904014812) — word-level similarity **0.9873**, all variances codification conventions |
| 34 | 950 CMR 12.207 currency check — Wayback CDX digest comparison | web.archive.org CDX, 6 captures 20 May 2024 → 14 Feb 2026 | 7 Sep 2026 | **SHA-1 identical across all six** (L57L36JBLVURZ52WQ54MMXIYQUQJDDAR) → unamended. Corroborated by mass.gov metadata (capture 10 Apr 2026) and Cornell LII ("No prior version found") |
| 35 | Definition sweep of 950 CMR 12.200 for "recommendation"/"recommend"/"investment advice"/"investment strategy"/"advice" | local grep, 1,593 extracted lines | 7 Sep 2026 | **0 definitions.** Only definition inside 12.207 is the negative definition of "customer" at 12.207(3) |
| 36 | FINRA AWC No. 2020066971201 (Robinhood, Jun 2021) | finra.org/sites/default/files/2021-06/robinhood-financial-awc-063021.pdf → **HTTP 403**; via Wayback 20260225190341 | 7 Sep 2026 | HTTP 200. Counts: **gamif 0 · confetti 0 · presentation 0**; recommend ×6 all in consultant undertakings. (The `fda_documents/…AWC va.pdf` path fails HTTP 404; correct suffix is `…AWC rjr.pdf`) |
| 37 | FINRA AWC No. 2019060756501 (Robinhood, Mar 2025) | finra.org/sites/default/files/2025-03/robinhood-AWC-030725.pdf → **HTTP 403**; via Wayback 20260803160427 | 7 Sep 2026 | HTTP 200. Influencer-post finding under Rule 2210. **Most recent FINRA action located; nothing later through Sep 2026** |
| 38 | SEC Rel. 33-10906 / 34-90694, AP File 3-20171 | sec.gov/files/litigation/admin/2020/33-10906.pdf | 7 Sep 2026 | HTTP 200, 444,308 B. Counts: **gamif 0 · confetti 0 · user interface 0 · notification 0 · digital engagement 0 · suitab 0** |
| 39 | CourtListener v4 — `"Robinhood Financial"` | courtlistener.com/api/rest/v4/search/?type=o | 7 Sep 2026 | **count 6** — located SJC-13381 |
| 40 | CourtListener v4 — `caseName:(Robinhood)` | same | 7 Sep 2026 | **count 9** — confirms one Massachusetts appellate Robinhood case |
| 41 | CourtListener v4 — `"Robinhood Financial LLC" AND "Secretary of the Commonwealth"` | same | 7 Sep 2026 | **count 1** — exact target |
| 42 | CourtListener v4 — `"492 Mass. 696"` | same | 7 Sep 2026 | **count 4** — citing references |
| 43 | CourtListener v4 — `"950 CMR 12.207"` and `"fiduciary duty rule" "Regulation Best Interest"` | same | 7 Sep 2026 | **THROTTLED — counts NOT obtained.** HTTP 200 body `{"detail":"Request was throttled. Rate limit exceeded: 50/hour."}`. Anonymous limit is 50 req/hr; `/clusters/` and `/opinions/` endpoints additionally require a token (`Authentication credentials were not provided`) — only `/search/` is anonymous |
| 44 | Massachusetts Division HTML index pages (enforcement-actions.htm, administrative-proceedings.htm, securities-idx.htm) | sec.state.ma.us | 7 Sep 2026 | **HTTP 200 with 842-byte Incapsula challenge / empty body** — HTML pages WAF-blocked; **PDF paths are not blocked**. Wayback CDX of the whole download directory filtered for `rh-` or `robin` returns exactly **3** Robinhood documents |
| 45 | casetext.com CMR library | casetext.com/regulation/… | 7 Sep 2026 | **HTTP 410 Gone** — Casetext's CMR library is retired; drop from future research paths |
| 46 | FINRA RN 11-39 and 12-29 — final paced retry | finra.org/rules-guidance/notices/11-39 ; /12-29 | 7 Sep 2026 | **11-39 HTTP 200, 113,747 B on the 3rd attempt** → S5-18 (closes the second-hand ◇ item); **12-29 HTTP 200, 175,410 B** → S5-19 (read; no recommendation-line content) |
| 47 | FINRA RN 24-09 (Gen AI / LLMs) | finra.org/rules-guidance/notices/24-09 | 7 Sep 2026 | HTTP 200, 103,052 B → S5-20. Technology-neutrality and human/machine-equivalence passages recovered |
| 48 | FINRA Annual Regulatory Oversight Reports 2025 and 2026 | finra.org/sites/default/files/2025-01/2025-annual-regulatory-oversight-report.pdf ; …/2025-12/2026-annual-regulatory-oversight-report.pdf | 7 Sep 2026 | Both HTTP 200 (1.5 MB each). Term counts in BOTH: **"digital engagement" 0 · "gamif" 0 · "game-like" 0 · "01-23" 0**. "recommendation" appears 57× in the 2026 report, none on the tool/list question → **FINRA has dropped the DEP topic from its annual reports** (N13) |
| 49 | FINRA RN 16-41, 21-17, 23-17 — final pass | finra.org/rules-guidance/notices/&lt;n&gt; | 7 Sep 2026 | All **HTTP 200** (119,678 / 135,937 / 96,398 B). All three **null**: 16-41 "recommend" ×5 (none on point), 0 hits for gamification/DEP/watch list/top movers; **21-17 is *Supporting Diversity and Inclusion in the Broker-Dealer Industry* — unrelated**; **23-17 is *FINRA Discontinues Collection of INSITE Data From Clearing Firms* — "recommend" ×0**. Candidate set exhausted |
| 50 | Question-B phrase sweep, expanded corpus: "criteria selected by the customer" / "selected by the customer" / "criteria the customer" / "customer selects" / "customer-selected" / "criteria developed by the firm" / "criteria followed by vendors" / "who selects" | local normalized search over **33 retrieved primary texts** (all FINRA rules and notices above, Reg BI adopting release, DEP release, PDA proposal and withdrawal, FINRA 2021 exam report, FINRA 2016 digital advice report, FINRA 2025 &amp; 2026 oversight reports, SEC exam priorities FY2022–FY2026) | 7 Sep 2026 | **Three files hit, mutually exclusively:** 01-23 (3 variants, 1 each) · DEP release ("criteria developed by the firm" ×1) · RN 11-39 ("criteria followed by vendors" ×1). **All 30 other files zero.** Supersedes the narrower sweep at #23 |
| 51 | Reg BI adopting release term counts: "list of securities" / "screener" / "watch list" / "watchlist" / "alert" / "menu of" | local normalized search over the complete 84 FR 33318–33492 text (1,597,471 B) | 7 Sep 2026 | **0 · 0 · 0 · 0 · 1 · 27.** All 27 "menu of" hits are product-shelf / limited-menu conflict discussion, not the *Park* "menu of nine" sense → N14 |
| 52 | FINRA Disciplinary Actions Online — architecture probe (no query string; `?fda_search=churning`; retry; real Chrome; DOM/JS inspection; API hunt) | finra.org/rules-guidance/oversight-enforcement/finra-disciplinary-actions-online | 7 Sep 2026 | HTTP 200 (95,150 B) bare; **HTTP 429 Cloudflare managed challenge** with any query string; Chrome clears the challenge in ~8 s but the query parameter **is ignored** and the form renders empty. Drupal 10.5.12, POST-only webform, CSRF `form_build_id`, **required Terms-of-Use checkbox**, honeypot `url` field. **No JSON/API endpoint.** → N15 |
| 53 | FINRA site-wide search (discovered in `finra_google_search/js/search.js`), validated with "churning" | finra.org/finra-search?q= | 7 Sep 2026 | **Validated** — many hits incl. OHO Order 23-17 (Venturino). Then 15 topic queries (screener, screening tool, watch list, watchlist, top movers, most popular, curated list, recommended list, focus list, leaderboard, push notification, gamification, digital engagement, game-like, mobile application): **0 disciplinary actions on interface features**; only guidance and testimony |
| 54 | FINRA monthly *Disciplinary and Other FINRA Actions* — bulk enumeration and sweep | finra.org/sites/default/files/YYYY-MM/disciplinary-actions-&lt;month&gt;-&lt;year&gt;.pdf | 7 Sep 2026 | 97 attempted, **93 downloaded, 90 valid PDFs, 83 extracted (Jun 2019 – Aug 2026)**. 24 interface terms → **zero files each**. Productive: influencer 7, self-directed 7, mobile application 5. **Apr 2021, Aug 2023, Nov 2024 blind (Cloudflare)** → N16 |
| 55 | FINRA AWCs retrieved in full | finra.org/sites/default/files/… and /fda_documents/… | 7 Sep 2026 | **HTTP 200:** Robinhood 2021 (933,724 B) · Robinhood 2025 (3,529,441 B) · M1 Finance · TradeZero · Moomoo · Webull 2023 · Webull 2025 (scanned, degraded OCR ◇) · Merrill Lynch · Interactive Brokers. **NOT RETRIEVED (Cloudflare, ~90 constructed URLs):** Stockpile, Digital Brokerage Services, Cobra Trading ◇ |
| 56 | Robinhood AWC term counts | local grep | 7 Sep 2026 | 2021 AWC (123 pp.): **"solicit"/"solicitation" = 0 · Rule 2111 = 0 · Reg BI = 0**; gamif/leaderboard/confetti/top mover/watchlist/screener/ranking/most popular/curated **= 0**; "push notification" ×1. 2025 AWC: same pattern; "solicitation" ×1, only inside quoted Rule 1220(a)(1) |
| 57 | NASAA comment letter, File No. S7-10-21 | sec.gov/comments/s7-10-21/s71021-9316149-260067.pdf | 7 Sep 2026 | **HTTP 200 with a declared-contact UA (262,267 B); HTTP 403 with a Chrome UA** — the reverse of the usual pattern → S5-21 |
| 58 | nasaa.org — every URL, both User-Agents | nasaa.org/… | 7 Sep 2026 | **HTTP 403, Sucuri firewall, Block ID GEO02** ("Access from your Country was disabled by the administrator") — **entire domain geo-blocked**. All NASAA text obtained via SEC comment files or exact-timestamp Wayback `if_` replay |
| 59 | NASAA model rule trace — CDX enumeration then exact-timestamp replay | web.archive.org CDX `nasaa.org/wp-content/uploads/*` (limit 6000) → 3,964 URLs | 7 Sep 2026 | **HTTP 200.** Sep 2023 proposal (subpart 1d(5) present) · Nov 2024 re-proposal (present, redline p. 13) · **adopted 7 Apr 2025 rule: "unsolicited" 0 · "self-directed" 0 · "digital" 0 · "gamif" 0 · "feature or promote" 0** → S5-22. **No adopting release or explanatory statement locatable** (`archived_snapshots: {}`) ◇ |
| 60 | NASAA comment letter, File No. S7-12-23 | sec.gov/comments/s7-12-23/s71223-270579-653282.pdf | 7 Sep 2026 | HTTP 200 — "**NASAA believes some DEPs constitute recommendations**"; notes that "at least one prominent firm and a trade organization maintain that neither Regulation Best Interest nor a fiduciary standard applies to self-directed brokerage" |
| 61 | Texas State Securities Board enforcement docket | ssb.texas.gov/…/enforcement index `?page=0-25` | 7 Sep 2026 | 26 × HTTP 200 → **247 orders 2016–2026**. Sweep (12 interface terms) → **all zero**; robinhood = 1. Robinhood order ENF-23-CDO-1870 retrieved (864,840 B) but **scanned, no text layer — content UNVERIFIED** ◇ |
| 62 | Wisconsin DFI enforcement orders index | dfi.wi.gov/Pages/Securities/…/EnforcementAdministrativeOrders.aspx | 7 Sep 2026 | HTTP 200, 1,545,490 B → **1,070 orders 1998–2026**. Sweep → **all zero**. Robinhood order (3.6 MB) **scanned, pdftotext 0 lines — UNVERIFIED** ◇ |
| 63 | Washington DFI securities orders — year archives 2015–2024 plus 2025–26 database | dfi.wa.gov/documents/securities-orders/… | 7 Sep 2026 | 10 + 6 × HTTP 200. Sweep (16 terms incl. screener, gamif, DEP, push notification, watchlist, top mover, leaderboard, curated, nudge, robo, trading bot, software, algorithm, trading signal, auto-trad, AI/ML) → **only *GoTradeSignals* responsive** → S5-27 |
| 64 | Washington — WAC 460-24A-220; Title 460 index | app.leg.wa.gov/WAC/ | 7 Sep 2026 | HTTP 200, 120,229 B. **0 hits** for screener, alert, app, software, digital, algorithm, gamif, platform. WAC 460-21B-060 and 460-22B-090 **repealed WSR 24-19-055 eff. 13 Oct 2024**; successor ch. **460-20C NOT RETRIEVED** ◇ |
| 65 | California DFPI Robinhood consent order | dfpi.ca.gov/wp-content/uploads/…/Consent-Order-Robinhood-Financial-LLC.pdf | 7 Sep 2026 | HTTP 200, text layer present. **gamif 0 · solicit 0 · curated 0 · confetti 0 · screener 0 · watchlist 0 · top movers 0 · self-directed 0** |
| 66 | New Jersey Bureau of Securities — order index | njconsumeraffairs.gov/bos/Pages/actions.aspx ; nj.gov/oag/bos | 7 Sep 2026 | **HTTP 200 but a 212-byte Incapsula JS stub**; WebFetch empty; nj.gov path **HTTP 404**. **No NJ sweep possible.** Press release retrieved separately (HTTP 200) → N18 |
| 67 | Alabama Securities Commission; Vermont DFR; New York (ag.ny.gov, dfs.ny.gov) | various | 7 Sep 2026 | **Alabama:** administrative-actions page HTTP 200 but a 2,068-char nav shell with no order links; `dlp_search` endpoint identified, **not queried**. **Vermont:** 2 × HTTP 404; legal-actions page HTTP 200 but insurance receiverships only. **New York: NOT SEARCHED — zero queries run.** → N17 |
| 68 | Advisers Act Rule 206(4)-1 and 203A-2 current text | ecfr.gov/current/title-17/chapter-II/part-275/… | 7 Sep 2026 | Declared-contact UA **HTTP 302 → unblock.federalregister.gov**; **Chrome UA HTTP 200** (55,410 B). Confirms tool conditions at **(e)(8)(ii)(A)(1)–(4)**, not (d)(6) → S5-23 |
| 69 | IA-5653 adopting release; FR pagination | sec.gov/rules/final/2020/ia-5653.pdf ; govinfo FR-2021-03-05/pdf/2020-28868.pdf | 7 Sep 2026 | HTTP 200 (2,482,546 B). Release pp. 214–216 = **86 FR 13082**. (First govinfo attempt used doc 2020-**29249** — wrong document; corrected via the Federal Register API, which returned 2 results for "Investment Adviser Marketing" 2021) |
| 70 | SEC Marketing Rule FAQs and four Marketing Rule Risk Alerts | sec.gov/investment/marketing-faq + 4 Risk Alerts | 7 Sep 2026 | All HTTP 200. **0 hits each** for interactive analysis / investment analysis tool / calculator / screener / robo → N19 |
| 71 | EDGAR full-text search; Search.gov; SEC listing-view parameterised search | efts.sec.gov/LATEST/search-index?q= ; search.usa.gov ; secsearch.sec.gov ; /admin-proceedings?search= ; /litreleases?search= | 7 Sep 2026 | EDGAR FTS **HTTP 200, 3 hits — all corporate filings**; does not index enforcement or guidance. Search.gov **HTTP 202, 0 bytes**. Listing searches **HTTP 403 / 404** → N20 |
| 72 | SEC adviser-side enforcement orders | sec.gov/files/litigation/admin/… and /litigation/admin/… | 7 Sep 2026 | **HTTP 200:** IA-6574 (Global Predictions) · IA-6573 (Delphia) · IA-5086 (Wealthfront) · IA-5087 (Hedgeable) · 34-95087 (Schwab) · IA-5959 (Wahed) · IA-5745 (Emperor) · IA-6954 (Ally, caption only ◇). **HTTP 429:** IA-6380/6381 (Titan), IA-2091, IA-6578 ◇. **HTTP 404:** Betterment probes ia-6293/6294 (release numbers inferred, may be wrong) ◇ |
| 73 | IM Guidance Update No. 2017-02 (Robo-Advisers) | sec.gov/investment/im-guidance-2017-02.pdf | 7 Sep 2026 | HTTP 200, 128,102 B → S5-28 |
| 74 | FINRA CEO testimony to House Financial Services Committee (6 May 2021) | finra.org/media-center/speeches-testimony/… | 7 Sep 2026 | HTTP 200 → S5-26, incl. n.264 |
| 75 | ★ *In re David Lerner Associates, Inc.*, Rel. 34-105556 | sec.gov/files/litigation/admin/2026/34-105556.pdf | 7 Sep 2026 | **HTTP 200, 238,302 B** → S5-34. The single most important retrieval in this track |
| 76 | *Siegel* — Commission opinion and D.C. Circuit opinion | sec.gov/files/litigation/opinions/2008/34-58737.pdf ; /2010/siegel-court-appeal-opinion-011210.pdf | 7 Sep 2026 | HTTP 200 (140,097 B / 386,362 B) → S5-35 |
| 77 | SEC Reg BI actions verified against primary text | sec.gov/files/litigation/admin/… | 7 Sep 2026 | HTTP 200: 34-98619 (SW Financial) · 34-98983 (Laidlaw) · 34-100615/-100616 (LifeMark) · 34-101071 (First Horizon) · 34-101361 (PHX) · 34-98609 (Citigroup). **Recommendation element assumed, not contested, in all** → S5-37 |
| 78 | *SEC v. Western International Securities* — complaint and disposition | sec.gov/files/litigation/complaints/2022/comp-pr2022-110.pdf ; /litigation-releases/lr-26065 | 7 Sep 2026 | HTTP 200, 244,694 B. **Complaint filed 15 Jun 2022** (caption "Filed 06/15/22"), press release 16 Jun — **correcting the brief's 27 Jun**. Settled by consent, LR-26065 (31 Jul 2024); **no ruling on the recommendation element** |
| 79 | SEC bulk enumeration — administrative proceedings and Commission opinions | sec.gov/enforcement-litigation/administrative-proceedings?page=0…70 ; /opinions-adjudicatory-orders?page=0…57 ; /litigation-releases?page=0…12 | 7 Sep 2026 | Listings HTTP 200: **7,096 AP rows / 3,663 post-Reg-BI PDFs**; **5,445 opinion rows / 2,122 PDFs**; 2,635 litigation-release rows. **Full-text scans FAILED — HTTP 429 throughout (3,586 then 4,191 NOTEXT). Zeros untrustworthy** → N21 |
| 80 | CourtListener v4 — 13 queries returning counts, 6 throttled | courtlistener.com/api/rest/v4/search/?q=…&amp;type=o | 7 Sep 2026 | Counts in full at S5-37. Throttled queries and the wrong-string artefact at N22. `/opinions/{id}/` → **HTTP 401**; opinion HTML → **HTTP 202, 0 bytes**; Justia → **HTTP 403** |
| 81 | SEC Reg BI Risk Alerts (7 Apr 2020; 30 Jan 2023) | sec.gov/files/Risk%20Alert-%20Regulation%20Best%20Interest%20Exams.pdf ; /files/exams-reg-bi-alert-13023.pdf | 7 Sep 2026 | HTTP 200 (324,085 B / 329,504 B). **Nothing on lists, tools or screeners**; only rollover, account and implicit-hold recommendations. Five other guessed paths returned HTTP 404 |
| 82 | SEC staff "Frequently Asked Questions on Regulation Best Interest" | sec.gov/tm/faq-regulation-best-interest | 7 Sep 2026 | HTTP 200, 122,338 B. Body term counts: "recommendation" 97 · "call to action" 4 · **"tool" 0 · "automat" 0 · "impersonal" 0** |
| 83 | FINRA disciplinary search — POST behaviour and results-page inspection | finra.org/…/finra-disciplinary-actions-online → `…/finra-disciplinary-actions?search=` | 7 Sep 2026 | POST → **HTTP 302** (URL params ARE honoured); GET results page **HTTP 200, 73,121 B with 0 result rows and a 1-character `<main>`**; no AJAX/API endpoint. Then **429 → 403 Cloudflare**. **Control query never succeeded** → N23 |
| 84 | FINRA NAC decisions | finra.org/rules-guidance/adjudication-decisions/nac-decisions (**404**) → /national-adjudicatory-council-nac | 7 Sep 2026 | Brief's URL **404s**. Live URL: 25 per page, **33 pages ≈ 825 decisions**; **page 1 only enumerated**, pages 2–33 blocked → N24 |
| 85 | EDGAR full-text search for enforcement | efts.sec.gov/LATEST/search-index?q=%22Regulation+Best+Interest%22 | 7 Sep 2026 | HTTP 200, 60,646 B, **total 6,234 — all EDGAR *filings*** (prospectus supplements etc.), **not enforcement**. Confirms N20 independently |

---

## ◇ list — resting on secondary confirmation only, or unverified

| Item | Status | What is needed |
|---|---|---|
| ~~FINRA Regulatory Notices 16-41, 21-17, 23-17~~ | **CLOSED — all three retrieved and read; all three null for this track** | 16-41 (26 Oct 2016, SEC approval of the communications-rule amendments): 5 occurrences of "recommend", none on the recommendation line, zero hits for gamification/digital engagement/watch list/top movers. **21-17 is *FINRA Seeks Comment on Supporting Diversity and Inclusion in the Broker-Dealer Industry* (29 Apr 2021) — wholly unrelated; a second mis-identified notice in the commissioning brief's candidate list, after 21-19.** 23-17 is *FINRA Discontinues Collection of INSITE Data From Clearing Firms* (30 Oct 2023) — zero occurrences of "recommend". No FINRA notice remains unretrieved from the candidate set |
| ~~RN 11-39's own text on links to third-party sites~~ | **CLOSED** | Retrieved directly → **S5-18**; both propositions previously attributed to it through RN 17-18 are confirmed verbatim |
| **FINRA Report on Digital Investment Advice (Mar 2016)** | **RETRIEVED** → S5-14 | Closed |
| FINRA RN **10-06** and **17-18** | **RETRIEVED** → S5-15, S5-16 | Closed |
| SEC approval order for Rule 2214 (SR-NASD-2003-13) and for the 2006/2013/2014/2017/2018 amendments | **NOT RETRIEVED** | Would show whether the Commission said anything about tool output as a recommendation when approving; NTM 04-86 (S5-05) is the SRO-side substitute currently relied on |
| The count of comment letters on the DEP release (File S7-10-21) | **NOT RETRIEVED** | sec.gov/comments/s7-10-21/ — no proposition in this register depends on it |
| Reconciliation of **NTM 96-60** with **NTM 01-23** | **NO AUTHORITY LOCATED** | This is a genuine open tension (S5-02), not a retrieval gap. It should be flagged to the coordinator as an unresolved conflict in the adverse register |
| ~~Reg BI enforcement and adjudicated "recommendation" decisions~~ | **REPORTED** → S5-34 → S5-37, N21 → N25 | Closed as a commission; its residual blockages are listed separately below |
| ★ ***David Lerner Associates***, Rel. 34-105556 | **INDEPENDENTLY RE-VERIFIED** — fetched and read at source; ¶¶ 20, 27, 33 checked word-for-word | Closed. No reliance on secondary report |
| The two SEC bulk full-text scans (3,663 AP orders; 2,122 Commission opinions) | **FAILED — HTTP 429 throughout**; 3,586 then 4,191 NOTEXT | URL lists on disk. **The Reg BI action list is verified but not provably exhaustive; no zero from either scan may be reported** (N21) |
| CourtListener: `"menu of nine"`, `cites:(2404954)`, `cites:(2290926)`, `"reasonably would influence an investor to trade"`, `"99 F. Supp. 2d 889"`, `"409 F. Supp. 2d 526"` | **NOT OBTAINED** — anonymous daily quota exhausted (`Expected available in 82721 seconds`) | Re-run after reset or with a free API token |
| ⚠️ CourtListener zero for `"content, context and manner of presentation"` | **ARTEFACT — DO NOT CITE** | Wrong string: that is RN 11-02's wording. NTM 01-23 and *Siegel* say "content, context, **and presentation**". The correct string was never run |
| Later citations to *Park* / *Terry's Tips* — *SEC v. Pirate Investor LLC*, 580 F.3d 233 (4th Cir. 2009); *Joseph v. Equity Edge, LLC*, 192 P.3d 573 (Colo. App. 2008) | ◇ **candidates identified, passages UNVERIFIED** | CourtListener HTML HTTP 202/0 bytes; opinions API HTTP 401; Justia HTTP 403. Both are publisher cases, so any citation is more likely on *Lowe*'s exclusion than the list/menu point |
| FINRA NAC decisions, pages 2–33 of 33 (~800 of ~825 decisions) | **NOT EXAMINED** — Cloudflare 403 | A 97% gap in the NAC corpus, **not** an absence (N24) |
| ***Dep't of Enforcement v. Kunz*** (NASD NAC 1999) — reportedly held that distributing an issuer's offering document was not by itself a recommendation | ◇ **UNVERIFIED lead; not relied on** | Pre-2000 and text unreachable (finra.org 403). Would be a rare "held NOT to be a recommendation" holding on impersonal-document facts — worth chasing with a browser |
| **FINRA Disciplinary Actions Online — never queried** | **GATE OPEN, ONE CLICK** | Blocked only by a required Terms-of-Use checkbox the researcher declined to accept on the client's behalf. **No zero from that database appears in this register.** Accepting the ToU and running the validated 16-query list would convert the N16 newsletter negatives into direct ones. Needs an instruction, not more research |
| **New York (ag.ny.gov, dfs.ny.gov)** | **NOT SEARCHED — zero queries run** | A genuine hole in the state coverage, not an absence |
| **Alabama, Vermont, New Jersey** order indices | **BLOCKED** — AL nav shell with no links (`dlp_search` endpoint identified but not queried); VT index not located; NJ Incapsula JS stub | Not-founds, **not** confirmed absences |
| NASAA's reason for dropping proposed subpart 1d(5) | ◇ **UNKNOWN** — nasaa.org HTTP 403 Sucuri GEO02; landing pages have `archived_snapshots: {}` | The *fact* of non-adoption is verified by word-count comparison of the adopted text; the *reason* is not. **Must not be characterised as a considered rejection of the theory** |
| FINRA AWCs: **Stockpile** 2022076787601, **Digital Brokerage Services** 2022076789701, **Cobra Trading** 2021072501001 | ◇ **AWC PDFs UNVERIFIED** — ~90 constructed `fda_documents` URLs all returned HTTP 200 with a Cloudflare interstitial; DDG/Bing 0 matching URLs | Quoted only from FINRA's own monthly newsletter summaries (Nov 2025 at 4; Feb 2026 at 5; Jun 2024 at 2) and BrokerCheck. Retrieve the AWCs via a browser before relying on S5-25 |
| Webull AWC 2021072231801 orthography | ◇ Scanned PDF, degraded OCR ("Wcbull", "fim1") | Substance legible; exact wording UNVERIFIED — `[sic]` marks corruption |
| Texas Robinhood order **ENF-23-CDO-1870** and Wisconsin Robinhood order — **contents** | ◇ **UNVERIFIED** — both scanned images with no text layer; no OCR binary available | Only the Texas signature block and one boilerplate sentence were extractable |
| WAC chapter **460-20C** (successor Washington broker-dealer rule after WSR 24-19-055) | **NOT RETRIEVED** | Whether the successor BD rule addresses digital features is **unknown** |
| *GoTradeSignals* Consent Order S-15-1626-16-CO01 operative paragraphs | ◇ Retrieved (HTTP 200, 475 lines) but **not pin-cite quoted** | Read before relying on S5-27 |
| FINRA newsletter months **Apr 2021, Aug 2023, Nov 2024** | ◇ **BLIND SPOTS** in the N16 sweep — HTTP 200 + Cloudflare interstitial | Three unswept months in an otherwise continuous Jun 2019 – Aug 2026 run |
| SEC orders IA-6380/6381 (Titan), IA-2091, IA-6578; Betterment order | ◇ **HTTP 429 / HTTP 404** (Betterment release numbers were inferred and may be wrong) | Not retrieved |
| *In re Ally Invest Advisors*, IA-6954 (23 Mar 2026) | ◇ **Caption verified only** | Findings taken from the SEC summary page, not the order |
| Mobile-app "does this constitute a recommendation under Reg BI?" exam question — present in FINRA's 2021, 2022 and 2023 reports, **absent from the 2026 report** | ◇ **Reason not established**; 2024 and 2025 reports not checked | Consistent with N8 and N13, but the gap itself is unexplained |
| **Currency of 950 CMR 12.207 on 7 Sep 2026** | ◇ — established to **14 Feb 2026** (byte-identical official PDF), **20 Feb 2026** (Division FAQ) and **10 Apr 2026** (mass.gov metadata) | mass.gov and sec.state.ma.us block programmatic access (Akamai / Incapsula) and the Massachusetts Register is subscription-gated, so Register issues could not be searched. **A five-month gap to the retrieval date is unclosed.** Nothing indicates a change; if load-bearing, needs a human with a browser |
| **Exact date of the Massachusetts Consent Order** | ◇ — day is **handwritten and OCR-illegible** in both the Division's copy and the CCH mirror | Bracketed by Offer of Settlement 17 Jan 2024 · PDF CreationDate 18 Jan 2024 · first Wayback capture 22 Jan 2024. Cited throughout as "on or about 18 January 2024" |
| **Post-remand disposition of Suffolk Sup. Ct. No. 2184CV00884** | **NOT ESTABLISHED** | masscourts.org HTTP 000 to non-browser clients; ma-appellatecourts.org HTTP 403 (Cloudflare); no Wayback capture of the trial docket after Nov 2022. What *is* established: the judgment invalidating the rule was reversed and has no effect |
| **No cert petition filed** (U.S. Sup. Ct. 23A416) | ◇ — **high confidence, not absolute** | Rests on the application docket's empty `RelatedCaseNumber`, its 11 Aug 2025 regeneration, and the settlement timing. supremecourt.gov offers no full-text docket search, so a petition under an unrelated number cannot be exhaustively excluded |
| CourtListener counts for `"950 CMR 12.207"` and `"fiduciary duty rule" "Regulation Best Interest"` | **NOT OBTAINED** — throttled (50 req/hr anonymous) | Re-run with a token, or after the hour resets. Do not read the absence of a count as a zero |
| SEC administrative proceedings 2024–2026 swept for further Robinhood orders | **NOT SEARCHED** in the Massachusetts pass | efts.sec.gov full-text endpoints not exercised there; partly covered by the pending Reg BI enforcement sweep |


---

# S6 · TRACK 6 — The surface as a legal fact

**Question:** Is there any authority in which **where** the customer's consent or instruction was given — in whose interface, on whose device, rendered by whose process — affected **whose act it was**, or whether it counted as the customer's own instruction?

**Bears on:** Q3 (customer instruction), with spill-over to Q2 (broker characterization).

**Headline:** No authority located — in four regulatory veins and seven attribution decisions read from official court sources — makes the identity of the rendering surface a factor in attribution. Every located instrument and every located decision resolves attribution by **function**: who assented, under whose authority, authenticated by what procedure, evidenced by what record, and above all **could anyone else have placed the mark**.

Three federal securities instruments come close enough to count as near-direct: **NASD NTM 98-66** (the customer "inputting the order" on a surface a third-party service bureau may build and operate), **the books-and-records adopting release, 66 FR 55818** (federal law's only enumeration of order authorship, entirely by person and role, with a computer terminal expressly a mere *proxy* for "the actual identity of the person who entered the order"), and **the Rule 15c3-5 adopting release** ("customers … enter orders" even when those orders bypass the broker's systems entirely). **12 CFR Part 1033** — status-checked and in force — is the closest regulatory model of the architecture, and it allocates consent-screen rendering expressly.

**Three adverse findings, in ascending order of importance.** First, the renderer always acquires duties: in every regime examined, the party that obtains a consent picks up obligations of its own. Second, the surface may be **legally inert** — nothing located attaches any consequence to who draws the window, so the engineering buys evidentiary quality rather than a legal characteristic. Third, and not anticipated by the brief: **in the case law, controlling the rendering system is a liability to be neutralised, not a credential earned.** *Banister* and *Garcia* fail attribution because the asserting party could have produced the mark itself; *Aerotek* succeeds because the credentials were "all unknown to" the proponent and the record was one it "could not modify". A runtime that renders the surface, holds the credentials and mints the record is in the losing posture unless it can **prove** it is locked out of all three.


---

## Register entries

### S6-01 · NASD Notice to Members 98-66, "Nasdaq Clarifies Rules Regarding Electronic Access To SelectNet And SOES By Non-Members And Public Customers" (Aug. 1998) · https://www.finra.org/rules-guidance/notices/98-66 · retrieved 7 Sep 2026 — **DIRECT AUTHORITY** (securities; SRO interpretive notice)
- **Type:** SRO notice / interpretive guidance (NASD, now FINRA)
- **Date / status:** August 1998. Describes systems (SelectNet, SOES) that no longer exist. Not withdrawn; superseded in practice by Rule 15c3-5 and the modern Nasdaq rulebook. Cited as live authority by the Commission in the Rule 15c3-5 adopting release, 75 FR 69792, 69794 n.8 (2010), for the proposition that the member is responsible for trading under its MPID.
- **Verbatim quotes, pin-cited:**

> "Recently, several members have inquired about the permissibility under NASD rules and the Nasdaq Workstation II Subscriber Agreement (NWII Agreement) for a member to permit its customers to enter orders into the member's own electronic system and to re-transmit those orders directly and electronically, **without the manual entry of such order by a person associated with the member**, into the SelectNet system through an API arrangement. In other words, certain members that connect to Nasdaq through an API want to be able to build an electronic access link that the member provides to certain customers. **The customer is then able to enter orders through this member-provided electronic entry point** that flow through the member's network that electronically connects through the Nasdaq API to the Nasdaq SelectNet application. This *Notice* clarifies that such activity is permissible under NASD rules and the NWII Agreement, provided that the member undertakes measures to ensure that all relevant NASD rules and system protections are followed, as described below." (§ "Public Customer / Non-Member Access To SelectNet", introductory ¶)

> "Members providing a SelectNet electronic pass-through service to customers must provide a letter to Nasdaq that acknowledges that they are acting as agents for the nonmember in submitting the order through their facilities and that they are responsible for the order sent through SelectNet. **Any member providing this service must submit all such orders as an agent on behalf of the customer inputting the order.** All orders submitted by customers into SelectNet will have the member's Market Participant Identifier (MPID) attached to them, and the member (Market Maker or ECN) receiving the order through SelectNet will know only that another member has attempted to access its Nasdaq-published price." (¶ 1, "Notice to Nasdaq Acknowledging Responsibility for Orders")

> "Members providing an electronic pass-through of SelectNet orders must use the Nasdaq API between the member's system and Nasdaq's system. **Members may use service bureaus to develop and operate the electronic access capability.** … If a member chooses to use a service bureau to develop the service, the member is nonetheless responsible for ensuring that all NASD rules and NWII Agreement requirements are complied with. **No service bureau is permitted to operate a service on behalf of a member unless the service bureau has entered into an agreement with Nasdaq.**" (¶ 10, "System Setup")

> "Such facilities allow the public customer to enter orders into a member-provided electronic entry device, which flows through the member's network into the member's own computer system and then, **without manual intervention**, into SOES." (§ "Public Customer Access To SOES", introductory ¶)

- **What it establishes:** In the only located SRO instrument addressing an order that is composed on one party's screen and transmitted by another party's system with no human intervention in between, the regulator's vocabulary attributes the order to **"the customer inputting the order"** and treats the surface's owner as an **agent submitting** it. It further contemplates that the surface itself may be **built and operated by a third-party service bureau** without that changing whose order it is — while requiring that service bureau to enter into an agreement with the market.
- **Q3:** SUPPORT (strongly). **Q2:** MIXED — see application note.
- **Level 3.** Reason: SRO interpretive notice, not a Commission release or a court holding; addresses obsolete systems; but expressly cited by the Commission in 2010 and squarely on the fact pattern.
- **Application note:** The configuration inverts the notice's geometry. In NTM 98-66 the surface belongs to the **broker** and the customer inputs on it; in the configuration the surface belongs to a **third party (the runtime)** and the customer inputs on it, then transmission proceeds under the customer's own credentials to the broker. The notice's holding — that the surface's owner is not the order's author, that the author is the person inputting, and that a service bureau may build and operate the surface — travels in the configuration's favour. The notice's *conditions* do not: it required a letter to Nasdaq, a system description, KYC assessment by the member, member supervision of "the entry of unauthorized orders", and an agreement between the **service bureau and Nasdaq**. The configuration has none of those, and no broker in it has undertaken any of them. Note also that in NTM 98-66 the orders bore the **member's** MPID, whereas in the configuration the order goes under the **member's (customer's) own broker credentials** — a further step away from the surface owner.

---

### S6-02 · Rule 15c3-5 Adopting Release, "Risk Management Controls for Brokers or Dealers with Market Access", Exchange Act Rel. No. 34-63241, 75 FR 69792 (Nov. 15, 2010) · https://www.federalregister.gov/documents/full_text/text/2010/11/15/2010-28303.txt · retrieved 7 Sep 2026 — **DIRECT AUTHORITY** (securities; Commission adopting release)
- **Type:** Commission adopting release (final rule)
- **Date / status:** Good law. Rule codified at 17 C.F.R. § 240.15c3-5 (text verified in eCFR, title 17, issue date 3 Sep 2026).
- **Verbatim quotes, pin-cited:**

> "Under these arrangements, the broker-dealer allows its customer—whether an institution such as a hedge fund, mutual fund, bank or insurance company, an individual, or another broker-dealer—to use the broker-dealer's MPID or other mechanism or mnemonic used to identify a market participant for the purposes of electronically accessing an exchange or ATS. Generally, direct market access refers to an arrangement whereby a broker-dealer **permits customers to enter orders** into a trading center but such orders flow through the broker-dealer's trading systems prior to reaching the trading center. In contrast, sponsored access generally refers to an arrangement whereby a broker-dealer **permits customers to enter orders** into a trading center **that bypass the broker-dealer's trading system** and are routed directly to a trading center, **in some cases supported by a service bureau or other third party technology provider**. … In all cases, however, whether the broker-dealer is trading for its own account, is trading for customers through more traditionally intermediated brokerage arrangements, or is allowing customers direct market access or sponsored access, **the broker-dealer with market access is legally responsible for all trading activity that occurs under its MPID**." (75 FR at 69793–94, text accompanying nn.7–8)

> "The independent third party could be another broker-dealer, an exchange or ATS, a service bureau, or other entity that is not an affiliate, and is otherwise independent, of the market access customer. **When evaluating whether a technology provider is independent of the customer, the Commission will look at the substance rather than the form of the relationship.** For example, the Commission would not consider a third party independent from a customer just because it is technically not an affiliate, **if it has a material business or other relationship with the customer** which could interfere with the provision of effective risk management technology to the broker-dealer." (75 FR at 69810)

> "As stated in the Proposing Release, the direct and exclusive control provision is designed to eliminate the practice whereby the broker-dealer providing market access may rely on its customer, a third party service provider, or others, to establish and maintain the applicable risk controls. The Commission believes the potential risks presented by market access are too great to permit a broker-dealer **to delegate the control of these critical risk management systems to the customer or another third party**." (75 FR at 69810–11)

- Rule text, 17 C.F.R. § 240.15c3-5(b) (eCFR, retrieved 7 Sep 2026): > "A broker or dealer with market access, or that provides a customer or any other person with access to an exchange or alternative trading system **through use of its market participant identifier or otherwise**, shall establish, document, and maintain a system of risk management controls and supervisory procedures…"

- **What it establishes:** The Commission's own vocabulary treats the **customer** as the party who "enters orders" in both the direct-market-access case (orders traverse the broker's systems) and the sponsored-access case (orders **bypass the broker's systems entirely** and may be produced by a third-party technology provider's system). Whose system rendered or produced the entry does not change whose order it is. What does carry legal responsibility is the **MPID** — an identifier, i.e. a credential.
- **Q3:** SUPPORT (strongly). **Q2:** NEUTRAL-to-SUPPORT.
- **Level 4.** Reason: Commission adopting release, current, and it uses the "customer enters orders" formulation for precisely the case where the surface is not the broker's.
- **Application note:** This is the strongest located federal statement that a securities order composed and submitted through a system the broker did not build is still the **customer's** order. Two cautions. First, the release is about **who bears risk-control responsibility**, not expressly about attribution of the order as a legal act; the "customer enters orders" language is descriptive framing rather than a holding. Second, the substance-over-form test at 69810 is adverse in one respect: the Commission was willing to look through the formal independence of a technology provider where it "has a material business or other relationship with the customer." In the configuration the runtime's provider has exactly such a relationship (a paid monthly community membership) with the member. That test is directed at a different question (whether a risk-control vendor is independent enough to serve the broker), but it demonstrates the Commission's readiness to disregard formal separation between a customer and the technology provider standing beside him. The configuration's pre-trade risk control sits with the broker, which is where the rule puts it.

---

### S6-03 · "Use of Electronic Media", Securities Act Rel. No. 33-7856 / Exchange Act Rel. No. 34-42728, 65 FR 25843 (May 4, 2000) · https://www.federalregister.gov/documents/full_text/text/2000/05/04/00-11079.txt · retrieved 7 Sep 2026 — **DIRECT AUTHORITY** (securities; Commission interpretive release)
- **Type:** Commission interpretive release
- **Date / status:** Good law. (The sec.gov landing page at `sec.gov/rules/interp/34-42728.htm` is now a metadata stub — HTTP 200, 57,943 bytes, no substantive text; the Federal Register version is the retrievable primary text.)
- **Verbatim quotes, pin-cited:**

> "Under this interpretation, we also believe, and we further clarify today, that an issuer or broker-dealer **may rely on a consent obtained by a third-party document delivery service**, but the issuer or broker-dealer **retains the ultimate responsibility for assuring that the consent is authentic** and for the delivery of required documents." (65 FR at 25846 n.25)

> "As with written or electronic consent, telephonic consent must be obtained in a manner that assures its authenticity." (65 FR at 25846, text accompanying n.23)

> "(1) Investor John Doe gives **XYZ Delivery Service** his informed consent over the telephone using automated touch tone instructions (after accessing the service using a **personal identification number**). … The confirming letter sent by XYZ Delivery Service provides assurance that John Doe consented to the same extent as if he had provided a written or electronic consent. Thus, XYZ Delivery Service's procedures would evidence satisfaction of delivery. We also note that **XYZ Delivery Service has reason to be assured of the authenticity of John Doe's telephonic consent because of his use of a personal identification number**." (65 FR at 25855, Section E, Example 1 and its discussion)

> "In this situation, Jane Doe's consent would be informed regarding the manner, costs and risks of electronic delivery. We also note that **Broker DEF has reason to be assured of the authenticity of Jane Doe's telephonic consent because Jane Doe is well known to Broker DEF**." (65 FR at 25855, Section E, Example 2 discussion)

- **What it establishes:** The Commission expressly contemplates a consent that is **captured on and by a party other than the one who acts on it**, and treats that consent as the investor's own and as valid. What supplies authenticity is a **security procedure** (Example 1: a PIN) or a **prior relationship** (Example 2). What the release allocates by reference to the acting party is **responsibility for authenticity** — which stays with the issuer or broker-dealer, i.e. with the party that acts on the consent, **not** with the party that rendered the surface.
- **Q3:** SUPPORT on validity; **ADVERSE** on the architecture's premise (see application note).
- **Level 4.** Reason: Commission interpretive release, still good law, and it decides the exact structural question — third-party-captured consent, relied on by the acting party.
- **Application note:** This is the closest thing in the securities corpus to direct authority, and it is double-edged in a way the commission should see plainly. The supportive half: consent captured outside the acting party's own surface is the investor's consent, it is relied upon, and authenticity is carried by a **credential** (the PIN), not by the surface. The adverse half: the release allocates responsibility for authenticity to the **broker-dealer**, expressly, and says nothing that would let the renderer's care substitute for the actor's responsibility. On this reading a runtime-owned approval surface, however hardened, does **not** move any responsibility off the broker, and correspondingly does not buy the runtime's operator any legal characteristic. The surface is legally inert here: it buys evidentiary assurance, not a change of status. That is not a finding that the surface is bad — it is a finding that no located authority pays for it.

---

### S6-04 · 12 C.F.R. § 1005.2(m) and Official Interpretation, Supplement I to Part 1005, comment 2(m) · https://www.ecfr.gov/api/versioner/v1/full/2026-09-03/title-12.xml?part=1005 · retrieved 7 Sep 2026 — **ANALOGY** (consumer payments)
- **Type:** Regulation (Reg E) plus Official Interpretations
- **Date / status:** Good law. eCFR title 12 issue date 3 Sep 2026.
- **Verbatim quotes, pin-cited:**

> "(m) 'Unauthorized electronic fund transfer' means an electronic fund transfer **from a consumer's account initiated by a person other than the consumer without actual authority to initiate the transfer** and from which the consumer receives no benefit. The term does not include an electronic fund transfer initiated: (1) By a person who was furnished the access device to the consumer's account by the consumer, unless the consumer has notified the financial institution that transfers by that person are no longer authorized; (2) With fraudulent intent by the consumer or any person acting in concert with the consumer; or (3) By the financial institution or its employee." (12 C.F.R. § 1005.2(m))

> "2. **Authority.** If a consumer furnishes an access device and grants authority to make transfers to a person (such as a family member or co-worker) who exceeds the authority given, the consumer is fully liable for the transfers unless the consumer has notified the financial institution that transfers by that person are no longer authorized." (Supp. I, comment 2(m)-2)

> "3. **Access device obtained through robbery or fraud.** An unauthorized EFT includes a transfer initiated by a person who obtained the access device from the consumer through fraud or robbery." (Supp. I, comment 2(m)-3)

- **What it establishes:** Reg E locates authorization **entirely by function**: who initiated, and whether that person had actual authority. The regulation and its Official Interpretations contain no reference to the interface, application, device or system through which the transfer was initiated. The only surface-adjacent concept in the definition is the **access device** — a credential.
- **Q3:** SUPPORT. **Level 4** (regulation + Official Interpretations, but a different statutory regime — hence ANALOGY).
- **Application note:** Direct read-across: the question the regulation asks of a transfer is the question the configuration wants asked of an order — was it initiated by the account holder, with authority. It does not ask whose screen it happened on.

---

### S6-05 · 12 C.F.R. § 1005.10(b) and Official Interpretation comments 10(b)-2 and 10(b)-5 · same source · retrieved 7 Sep 2026 — **ANALOGY**
- **Type:** Regulation (Reg E) plus Official Interpretations
- **Date / status:** Good law.
- **Verbatim quotes, pin-cited:**

> "**(b) Written authorization for preauthorized transfers from consumer's account.** Preauthorized electronic fund transfers from a consumer's account may be authorized only by a writing signed or similarly authenticated by the consumer. **The person that obtains the authorization shall provide a copy to the consumer.**" (12 C.F.R. § 1005.10(b))

> "2. **Authorization obtained by third party.** The account-holding financial institution does not violate the regulation when a third-party payee fails to obtain the authorization in writing or fails to give a copy to the consumer; rather, **it is the third-party payee that is in violation of the regulation**." (Supp. I, comment 10(b)-2)

> "5. **Similarly authenticated.** The similarly authenticated standard permits signed, written authorizations to be provided electronically. The writing and signature requirements of this section are satisfied by complying with the Electronic Signatures in Global and National Commerce Act, 15 U.S.C. 7001 *et seq.*, which defines electronic records and electronic signatures. Examples of electronic signatures include, but are not limited to, digital signatures and security codes. **A security code need not originate with the account-holding institution.** **The authorization process should evidence the consumer's identity and assent to the authorization.** The person that obtains the authorization must provide a copy of the terms of the authorization to the consumer either electronically or in paper form. **Only the consumer may authorize the transfer and not, for example, a third-party merchant on behalf of the consumer.**" (Supp. I, comment 10(b)-5)

- **What it establishes:** Three things at once. (i) The authorization may be captured by a party **other than** the institution that acts on it — the regulation and commentary assume it routinely is. (ii) The authentication mark **need not come from the acting institution** ("A security code need not originate with the account-holding institution"); what matters is that "the authorization process should evidence the consumer's identity and assent". (iii) The party that **obtains** the authorization thereby carries the regulatory duty, and is the one who violates the rule if the process is defective.
- **Q3:** SUPPORT on (i) and (ii); **ADVERSE** on (iii).
- **Level 4** (Official Interpretations have the force of the regulation for safe-harbour purposes; different regime, hence ANALOGY).
- **Application note:** Comment 10(b)-5 is the single closest sentence located anywhere to a regulator blessing the configuration's authentication design: an authentication mark derived from a secret held by the party that renders the surface, not by the institution that acts on the instruction, is expressly contemplated ("need not originate with the account-holding institution"), and the test applied to the process is functional ("should evidence the consumer's identity and assent"). Comment 10(b)-2 is the clearest located statement of the adverse direction the commission asked about: **the obtainer of the authorization is the party who can violate the rule.** In the configuration the runtime is the obtainer. It acquires, on this analogy, the exposure that goes with obtaining — not the broker's, but its own.

---

### S6-06 · CFPB, "Electronic Fund Transfers FAQs" (Coverage: Financial Institutions; Error Resolution: Unauthorized EFTs) · https://www.consumerfinance.gov/compliance/compliance-resources/deposit-accounts-resources/electronic-fund-transfers/electronic-fund-transfers-faqs/ · retrieved 7 Sep 2026 — **ANALOGY**
- **Type:** Agency compliance aid (not a rule; no safe harbour)
- **Date / status:** Live on the CFPB site as at 7 Sep 2026 (HTTP 200, 196,631 bytes). Individual answers carry per-item date stamps of "Updated June 4, 2021" and "Updated December 13, 2021"; no later revision date appears on any item read. **Status caution, verified this track:** on 12 May 2025 the Bureau published "Interpretive Rules, Policy Statements, and Advisory Opinions; Withdrawal", 90 FR 20084 (FR doc 2025-08286), stating that it "is withdrawing many guidance documents issued since the CFPB assumed its functions in 2011" and that "the Bureau is withdrawing **all guidance documents** to afford staff an opportunity to review", adding that it "does not intend to prioritize the enforcement of such guidance against parties that do not conform to the guidance during the pendency of any withdrawal" (90 FR at 20085, § II). That notice withdrew **every Consumer Financial Protection Circular from 2022-01 through 2024-06**, including Circular 2024-01 on preferencing and steering by digital intermediaries. The EFT FAQs are **not named** in it (the document contains zero occurrences of "FAQ", "frequently asked" or "compliance aid") and the page remains live, but the Bureau's stated posture toward its own non-regulatory guidance is materially weaker than it was in 2021. Weigh this entry accordingly.
- **Verbatim quotes, pin-cited:**

> "**3. Is an EFT from a consumer's account initiated by a fraudster through a non-bank P2P payment provider considered an unauthorized EFT?** Yes. Because the EFT was initiated by a person other than the consumer without actual authority to initiate the transfer – *i.e.*, the fraudster – and the consumer received no benefit from the transfer, the EFT is an unauthorized EFT. 12 CFR 1005.2(m). **This is true even if the consumer does not have a relationship with, or does not recognize, the non-bank P2P payment provider.**" (Error Resolution: Unauthorized EFTs, Q3; updated 13 Dec 2021)

> "**4. If a consumer uses a non-bank P2P payment provider to initiate a debit card 'pass-through' payment from the consumer's account held by a depository institution, is the depository institution considered a financial institution under Regulation E, even though the transfer was initiated through the non-bank P2P payment provider?** Yes. … Here, because the depository institution holds the consumer's deposit account, it is considered a financial institution under Regulation E with full error resolution obligations." (Coverage: Financial Institutions, Q4; updated 13 Dec 2021)

> "Financial institutions include providers of P2P payment and bill payment services, if they directly or indirectly hold an account belonging to a consumer, or **if they issue an access device and agree with a consumer to provide EFT services**." (Coverage: Financial Institutions, Q1; updated 13 Dec 2021)

- **What it establishes:** Across a long run of fact patterns in which the transfer is initiated through a third party's app rather than the account-holding bank's, the Bureau's analysis never turns on whose app it was. The italicised clause in Q3 is an express statement that the identity of, and the consumer's relationship with, the interface provider is **irrelevant** to whether the transfer was authorized.
- **Q3:** SUPPORT. **Level 2** — an FAQ, expressly a compliance aid, no force of law, and last substantively updated in December 2021.
- **Application note:** Supportive on attribution. Adverse on status: Coverage Q1 shows the same regulator pulling the **provider of the surface** into the regime as a "financial institution" whenever it "issue[s] an access device and agree[s] with a consumer to provide EFT services." The configuration's runtime issues no access device and agrees to provide no transfer service — trade-capable credentials are the member's own, held in his own local keychain — so the analogy does not bite on its facts. But it is the same structural move the commission asked to be looked for: the surface's owner is a candidate for regulated status on grounds unrelated to who authorized what.

---

### S6-07 · 12 C.F.R. Part 1033 (Personal Financial Data Rights), subpart D, §§ 1033.401, 1033.411, 1033.421, 1033.431, 1033.441 · https://www.ecfr.gov/api/versioner/v1/full/2026-09-03/title-12.xml?part=1033 · retrieved 7 Sep 2026 — **ANALOGY**
- **Type:** Regulation
- **Date / status check as at 7 September 2026:** **In force.** Part 1033 is present in the eCFR at title 12, issue date 3 Sep 2026 (71,419 bytes of XML retrieved). Rulemaking history from the Federal Register API (agency=CFPB, term=1033, retrieved 7 Sep 2026, COUNT 25): final rule "Required Rulemaking on Personal Financial Data Rights", FR doc **2024-25079**, published **18 Nov 2024** (89 FR 90838); then an **Advance Notice of Proposed Rulemaking**, "Personal Financial Data Rights Reconsideration", FR doc **2025-16139**, published **22 Aug 2025**, 90 FR 40986, comments closed 21 Oct 2025. **No subsequent Federal Register document amending, staying, delaying or vacating Part 1033 appears in the API results**; the only later CFPB item mentioning 1033 is the semiannual Regulatory Agenda notice of 14 Aug 2026 (FR doc 2026-16613). ◇ The E.D. Ky. litigation over the 2024 rule was not reached from a primary docket in this track — see Negative findings.
- **Verbatim quotes, pin-cited:**

> "**§ 1033.401 Third party authorization; general.** To become an authorized third party, the third party must seek access to covered data from a data provider on behalf of a consumer to provide a product or service the consumer requested and: (a) Provide the consumer with an authorization disclosure as described in § 1033.411; (b) Provide a statement to the consumer in the authorization disclosure … certifying that the third party agrees to the obligations described in § 1033.421; and (c) **Obtain the consumer's express informed consent** to access covered data on behalf of the consumer by obtaining an authorization disclosure that is **signed by the consumer electronically or in writing**."

> "**§ 1033.411(a) In general.** To comply with § 1033.401(a), **a third party must provide the consumer with an authorization disclosure** electronically or in writing. The authorization disclosure must be clear, conspicuous, and segregated from other material."

> "**§ 1033.431(a) Responsibility for authorization procedures when the third party will use a data aggregator.** **A data aggregator is permitted to perform the authorization procedures described in § 1033.401 on behalf of the third party** seeking authorization under § 1033.401 to access covered data. **However, the third party seeking authorization remains responsible for compliance with the authorization procedures** described in § 1033.401, and the data aggregator must comply with paragraph (c) of this section."

> "**§ 1033.431(b) Disclosure of the name of the data aggregator.** The authorization disclosure must include **the name of any data aggregator** that will assist the third party seeking authorization under § 1033.401 with accessing covered data and a brief description of the services the data aggregator will provide."

> "**§ 1033.431(c) Data aggregator certification.** … the data aggregator **must certify to the consumer** that it agrees to the conditions on accessing the consumer's data in § 1033.421(a) through (f) and the condition in § 1033.421(i) … before accessing the consumer's data."

- **What it establishes:** A live federal rule that **allocates the rendering of a consent surface** among three parties. The consent screen is drawn and the consent captured by the **third party** (or, under § 1033.431, by a **data aggregator on the third party's behalf**), not by the institution that holds the account and acts on the consent. Rendering by a non-actor does not make the consent anyone else's: it remains the **consumer's** authorization, and it binds the data provider. Responsibility for the procedure stays with the **principal** (the third party), not the renderer. And the renderer must be **named** and must **certify** in its own right.
- **Q3:** SUPPORT (structural). **Level 4** as a regulation; **ANALOGY** because it is a consumer-data regime, not securities.
- **Application note:** This is the closest located regulatory model of the configuration's architecture. Map: consumer = member; data provider (bank) = broker; authorized third party = the party whose product the member is using; data aggregator performing the authorization procedure = the runtime rendering the approval surface. The rule's answer to "whose consent is it when someone else draws the screen?" is unambiguous — the consumer's — and its answer to "does the renderer thereby take on obligations?" is equally unambiguous: **yes**, disclosure of its name, a certification running to the consumer, and the § 1033.421(a)–(f) and (i) conditions. The configuration's runtime is named and locally installed, which sits comfortably with § 1033.431(b); it holds no data credential and re-serves nothing, which is a better posture than the aggregator the rule was written for.

---

### S6-08 · CFPB, Final Rule preamble, "Required Rulemaking on Personal Financial Data Rights", 89 FR 90838 (Nov. 18, 2024), at 90904–05 · https://www.federalregister.gov/documents/full_text/text/2024/11/18/2024-25079.txt · retrieved 7 Sep 2026 — **ANALOGY**
- **Type:** Agency final-rule preamble
- **Date / status:** Good law; see status check at S6-07.
- **Verbatim quotes, pin-cited:**

> "The CFPB explained that **before a data provider grants a third party access to covered data today, the consumer is typically redirected from a third party's interface to the data provider's interface to authenticate the consumer's identity**, usually by providing account credentials. Where consumers provide their credentials directly to the data provider through such an interface, the data provider would generally receive information sufficient to authenticate the consumer's identity for purposes of proposed § 1033.331(b)(1)(i)." (89 FR at 90904)

> "**The CFPB has determined that data providers should not be responsible for obtaining a consumer's authorization for a third party because third parties are in the best position to determine what data elements are reasonably necessary.** However, § 1033.331(b)(1)(iii) does not require a data provider to independently verify the third party has followed each of the § 1033.401 authorization procedures, but instead describes a condition in which the data provider receives **information sufficient to document** such authorization. As discussed in the proposal, **receipt of a copy of the signed authorization disclosure should constitute information sufficient to confirm third party authorization, absent facts to the contrary.**" (89 FR at 90905)

> "In response to bank commenter questions about whether **any particular method of authentication is necessary or sufficient, the final rule does not so specify.** … the CFPB does not believe it is necessary to prescribe a single means of authentication in the final rule." (89 FR at 90905)

- **What it establishes:** A federal regulator, addressing the two-surface architecture head on: the **third party's interface** frames the flow; the **data provider's interface** takes the credentials; and the acting institution's warrant for treating the instruction as the consumer's is a **record** — "a copy of the signed authorization disclosure" — not its own authorship of the screen. The Bureau expressly declined to prescribe who must render what or by what method.
- **Q3:** SUPPORT. **Level 3** (preamble reasoning, not regulatory text; different regime).
- **Application note:** The record-carries-attribution model here is structurally the configuration's: the runtime mints an immutable instruction record bound to the exact displayed terms, member, account, source, scope, timestamp and nonce, and the broker acts on the instruction transmitted under the member's own credentials. The Bureau's "information sufficient to document" standard is the closest located regulatory articulation of what such a record is **for**. Note the split the Bureau drew and the configuration does not: in Part 1033 the **credentials go to the acting institution's own interface**, and only the authorization record comes from the third party's. In the configuration the credentials sit in the member's local vault inside the runtime and the runtime uses them. That is a real difference and it is not covered by anything located.

---

### S6-09 · CFPB, "Personal Financial Data Rights Reconsideration", Advance Notice of Proposed Rulemaking, 90 FR 40986 (Aug. 22, 2025) · https://www.federalregister.gov/documents/full_text/text/2025/08/22/2025-16139.txt · retrieved 7 Sep 2026 — **ANALOGY**
- **Type:** Advance notice of proposed rulemaking (questions only; proposes no text)
- **Date / status:** Comments closed 21 Oct 2025. No follow-on rulemaking document located as at 7 Sep 2026.
- **Verbatim quotes, pin-cited:**

> "As the term is used in section 1033 of the Dodd-Frank Act, a 'consumer' is defined as an individual or an agent, trustee, or representative acting on behalf of an individual. 12 U.S.C. 5481(4). … **The PFDR Rule interpreted the phrase 'representative acting on behalf of an individual' to include third parties that access consumers' data pursuant to certain authorization procedures and substantive obligations.**" (90 FR at 40988, § III)

> "3. Does the statutory reference to an 'agent, trustee, or representative' indicate that 'representative' is intended to encompass **only those representatives that are serving in a fiduciary capacity**? …" (90 FR at 40988, Question 3)

> "7. If a 'representative' under 12 U.S.C. 5481(4) is interpreted not to be required to have fiduciary duties, **what elements are required in establishing that the individual is a 'representative' acting on behalf of the consumer?**" (90 FR at 40988, Question 7)

- **What it establishes:** As of the most recent located rulemaking step, the Bureau itself regards the test for **when a third party is acting on the consumer's behalf** as unsettled and open — and is asking whether it requires fiduciary status. Question 7 is, in this regime's vocabulary, Track 6's own question.
- **Q3:** NEUTRAL, tending ADVERSE (an open question is not a safe harbour). **Level 2** — an ANPRM decides nothing.
- **Application note:** Record it as an open regulatory question, not as support. It is also a caution against leaning on Part 1033's architecture too hard: the very provision that makes the analogy attractive (subpart D's treatment of authorized third parties as the consumer's "representative") is the provision the Bureau has put back on the table.

---

### S6-10 · RCW 62A.4A-201, -202, -203 (Washington's UCC Article 4A) · https://app.leg.wa.gov/RCW/default.aspx?cite=62A.4A-202 · retrieved 7 Sep 2026 — **ANALOGY** (commercial funds transfers), but **Washington statutory law**
- **Type:** State statute (in scope: the technical lead's place of business is Washington)
- **Date / status:** Good law; amended 2023 c 266 §§ 502–504 (effective under notes following RCW 62A.12-101).
- **Verbatim quotes, pin-cited:**

> "**'Security procedure' means a procedure established by agreement of a customer and a receiving bank for the purpose of (1) verifying that a payment order or communication amending or canceling a payment order is that of the customer**, or (2) detecting error in the transmission or the content of the payment order or communication. A security procedure may impose an obligation on the receiving bank or the customer and may require the use of algorithms or other codes, identifying words, numbers, symbols, sounds, biometrics, encryption, callback procedures, or similar security devices. **Comparison of a signature on a payment order or communication with an authorized specimen signature of the customer or requiring a payment order to be sent from a known email address, IP address, or telephone number is not by itself a security procedure.**" (RCW 62A.4A-201)

> "(a) A payment order received by the receiving bank is the authorized order of the person identified as sender **if that person authorized the order or is otherwise bound by it under the law of agency.** (b) If a bank and its customer have agreed that the authenticity of payment orders issued to the bank in the name of the customer as sender will be verified pursuant to a security procedure, **a payment order received by the receiving bank is effective as the order of the customer, whether or not authorized**, if (i) the security procedure is a commercially reasonable method of providing security against unauthorized payment orders, and (ii) the bank proves that it accepted the payment order in good faith and in compliance with the bank's obligations under the security procedure and any agreement or instruction of the customer, evidenced by a record…" (RCW 62A.4A-202(a)–(b))

> "(d) The term 'sender' in this Article includes the customer in whose name a payment order is issued if the order is the authorized order of the customer under subsection (a) of this section, **or it is effective as the order of the customer under subsection (b)** of this section." (RCW 62A.4A-202(d))

- **What it establishes:** Washington's own statutory answer to "whose instruction was it?" is a two-track test — **actual authority or agency** (subsection (a)), failing which **a commercially reasonable security procedure, complied with in good faith** (subsection (b)). Nothing in the test refers to the interface, application or system in which the order was composed. The 2023 amendment to § 4A-201 goes further in the adverse-to-surface direction: **the channel the message came from is expressly declared insufficient by itself** — "requiring a payment order to be sent from a known email address, IP address, or telephone number **is not by itself a security procedure**."
- **Q3:** SUPPORT. **Level 3** — a statute, and Washington's, but a commercial funds-transfer regime that by its own terms does not reach consumer EFTs governed by EFTA, and does not reach securities orders at all.
- **Application note:** The most explicit located statutory rejection of surface-as-attribution. It also names precisely what the configuration should be building toward: a **security procedure agreed between the customer and the party that acts** — which, in the configuration, does not exist between the member and the broker in respect of the runtime's approval act. The runtime's authentication mark is derived from a runtime secret and bound to the order and session nonce; under a § 4A-202(b) analysis that would be a security procedure only if the **acting party** (the broker) had agreed to it. It has not. That gap is worth flagging: the configuration's mark is excellent evidence of what the member did (subsection (a) territory) but it is not a subsection (b) security procedure, because subsection (b) requires the actor's agreement.

---

### S6-11 · 12 C.F.R. § 1026.12(b)(1) n.22 (Regulation Z, "unauthorized use") · https://www.ecfr.gov/api/versioner/v1/full/2026-09-03/title-12.xml?part=1026 · retrieved 7 Sep 2026 — **ANALOGY**
- **Type:** Regulation
- **Date / status:** Good law.
- **Verbatim quote, pin-cited:**

> "For purposes of this section, the term 'unauthorized use' means **the use of a credit card by a person, other than the cardholder, who does not have actual, implied, or apparent authority for such use**, and from which the cardholder receives no benefit."

- **What it establishes:** The third federal consumer-payments regime examined, and the third to define authorization purely by **person and authority**, with no reference to the interface or channel of use.
- **Q3:** SUPPORT. **Level 3.** Corroborative only.
- **Application note:** Cited for the pattern, not for any distinct proposition: across EFTA/Reg E, Reg Z and Washington's Article 4A, the federal and state drafters had three separate opportunities to make the surface a factor and did not take any of them.

---

### S6-12 · NASD Notice to Members 05-48, "Members' Responsibilities When Outsourcing Activities to Third-Party Service Providers" (July 2005) · https://www.finra.org/rules-guidance/notices/05-48 · retrieved 7 Sep 2026 — **DIRECT AUTHORITY** (securities; SRO notice)
- **Type:** SRO notice
- **Date / status:** Live on FINRA's site.
- **Verbatim quote, pin-cited:**

> "NASD is issuing this *Notice* to remind members that, in general, **any parties conducting activities or functions that require registration under NASD rules will be considered associated persons of the member**, absent the service provider separately being registered as a broker-dealer and such arrangements being contemplated by NASD rules … In addition, **outsourcing an activity or function to a third party does not relieve members of their ultimate responsibility for compliance** with all applicable federal securities laws and regulations and NASD and MSRB rules regarding the outsourced activity or function." (Executive Summary / "Third-Party Service Providers")

- **What it establishes:** Where a member outsources a function that would require registration, the provider is drawn in as an **associated person** of the member unless separately registered. Responsibility does not move to the provider; status may.
- **Q3:** NEUTRAL. **Q2:** ADVERSE.
- **Level 3** (SRO notice, current, but predicated on an engagement by a member).
- **Application note:** Its predicate is absent from the configuration — no broker engages the runtime, there is no outsourcing relationship, and the member's broker has not contracted for the surface. Recorded because it is the securities-side statement of the same adverse pattern found in Reg E comment 10(b)-2 and Part 1033 § 1033.431(c): the party that performs the function acquires something, even where the principal keeps responsibility. If a broker ever *did* engage the runtime to render its customers' approval surface, this notice would be the first thing pointed at.

---

### S6-13 · "Books and Records Requirements for Brokers and Dealers Under the Securities Exchange Act of 1934", Exchange Act Rel. No. 34-44992, 66 FR 55818 (Nov. 2, 2001) — the adopting release for the current 17 C.F.R. § 240.17a-3(a)(6)(i) and (a)(7) · https://www.federalregister.gov/documents/full_text/text/2001/11/02/01-27439.txt · retrieved 7 Sep 2026 — **DIRECT AUTHORITY** (securities; Commission adopting release + rule text)
- **Type:** Commission adopting release (final rule), with rule text
- **Date / status:** Good law; the (a)(6)(i) and (a)(7) language quoted below is the operative text adopted here.
- **Verbatim quotes, pin-cited:**

Rule text as adopted (66 FR at 55838):
> "(6)(i) A memorandum of each brokerage order, and of any other instruction, given or received for the purchase or sale of securities … The memorandum shall show the terms and conditions of the order or instructions … the identity of each associated person, if any, responsible for the account; **the identity of any other person who entered or accepted the order on behalf of the customer or, if a customer entered the order on an electronic system, a notation of that entry**; and, to the extent feasible, the time of execution or cancellation. **The memorandum need not show the identity of any person, other than the associated person responsible for the account, who may have entered or accepted the order if the order is entered into an electronic system that generates the memorandum and if that system is not capable of receiving an entry of the identity of any person other than the responsible associated person**; in that circumstance, the member, broker or dealer shall produce upon request by a representative of a securities regulatory authority a separate record which identifies each other person. **An order entered pursuant to the exercise of discretionary authority by the member, broker or dealer, or associated person thereof, shall be so designated.**"

Commission's explanation (66 FR at 55819):
> "This modification was made in response to broker-dealer comment letters that noted some firms do not assign a particular associated person to each account, and **some firms allow customers to enter orders directly into a broker-dealer's systems, such as through an on-line trading account**."

> "If a firm has assigned identification numbers or codes to the persons entering customer orders to comply with the requirement to record the identity of the person entering customer orders, a broker-dealer may record the identification number or code on the order ticket instead of the associated person's name. Further, **if the person entering a customer order has been assigned to a computer terminal but does not have a specific identification number or code, it is acceptable for the broker-dealer to identify the number or code of a computer terminal at which an order was entered. In either case, upon request by a representative of a securities regulatory authority, the firm must provide the actual identity of the person who entered the order.**"

> "With these amendments, paragraphs (a)(6) and (a)(7) require that broker-dealers record the identity of '[any person other than the associated person responsible for the account] who entered or accepted the order on behalf of the customer.' In response to comments by the online brokerage community, the Commission included, after this requirement, the phrase, '**if a customer entered the order on an electronic system, a notation of such entry.**' Because most firms that accept orders through an electronic system already identify, for supervisory purposes, **which orders were entered directly by a customer**, this requirement will not create much additional burden on the firms."

- **What it establishes:** This is the one place in federal securities law that actually **enumerates the possibilities** for who entered an order, and the enumeration is entirely by **person and role**: (1) the associated person responsible for the account; (2) **any other person who entered or accepted the order on behalf of the customer**; (3) the customer himself, in which case all that is required is "a notation of that entry"; plus a separate designation for orders entered under **discretionary authority**. The electronic system appears in the rule only as a **circumstance** ("on an electronic system", "into an electronic system that generates the memorandum") and is **never identified by owner**. The Commission's terminal-identifier passage makes the point explicit: a terminal's number or code is acceptable **as a proxy**, but on request the firm "must provide **the actual identity of the person who entered the order**." The device is a stand-in; the person is the fact.
- **Q3:** SUPPORT on the framework; **ADVERSE** on one branch of it — see application note.
- **Level 4.** Reason: Commission adopting release plus operative rule text, current, and the only located federal enumeration of order authorship.
- **Application note:** The configuration wants to be in branch (3) — "a customer entered the order on an electronic system" — and its facts fit it: the member performs one explicit tap or swipe per order on a complete composed order, and no discretionary authority is granted to anyone, so branch (4) is not engaged either. Two cautions, both real. **First**, branch (2) — "any other person who **entered or accepted the order on behalf of the customer**" — is the branch the configuration must stay out of, and nothing located defines how software that composes the order from the member's own policy and transmits it under his credentials is sorted between (2) and (3). The rule speaks of a "person"; the configuration's runtime is software the member installed and runs locally, and P7 has already recorded that no authority applies § 3(a)(35) to software in either direction. That gap is unclosed. **Second**, the clause about "an electronic system **that generates the memorandum**" shows the Commission contemplating a system that **produces the order record** — but it contemplates it as the broker's system, generating the broker's memorandum, and its concern is that such a system may not be able to capture another person's identity, in which case a separate record must be produced on request. The configuration's runtime also generates a record; nothing located says whose record that is for § 17a-3 purposes, and the broker's own obligation under (a)(6)(i) is unaffected by it.


---

### S6-14 · 12 C.F.R. § 1005.14, "Electronic fund transfer service provider not holding consumer's account" · https://www.ecfr.gov/api/versioner/v1/full/2026-09-03/title-12.xml?part=1005 · retrieved 7 Sep 2026 — **ANALOGY**
- **Type:** Regulation (Reg E)
- **Date / status:** Good law.
- **Verbatim quote, pin-cited:**

> "**(a) Provider of electronic fund transfer service.** A person that provides an electronic fund transfer service to a consumer **but that does not hold the consumer's account** is subject to all requirements of this part if the person: **(1) Issues a debit card (or other access device) that the consumer can use to access the consumer's account** held by a financial institution; and **(2) Has no agreement with the account-holding institution** regarding such access."

> "**(c) Compliance by account-holding institution.** The account-holding institution **need not comply** with the requirements of the Act and this part with respect to electronic fund transfers initiated through the service provider except as follows: …"

- **What it establishes:** This is the located regulation that comes closest to asking the configuration's own structural question — **when does a party standing between the consumer and the account-holding institution get pulled into the regime?** The answer is given by **two functional triggers, and neither is the surface**: the party must (1) **issue an access device** — a credential — and (2) have **no agreement** with the institution that holds the account. Rendering an interface, composing an instruction, or displaying terms appears nowhere in the trigger.
- **Q3:** SUPPORT. **Q2:** SUPPORT (by analogy).
- **Level 4** as a regulation; **ANALOGY** because it is a consumer-payments regime.
- **Application note:** On the closest located regulatory test for "third party in the path", the configuration does **not** trip either limb. Limb (1): the runtime **issues no access device** — trade-capable credentials are the member's own, held in his own local keychain or isolated vault, per member, with no company-level or app-level trading credential in existence. The member accesses his account with credentials the broker issued to him, not with anything the runtime issued. Limb (2) is therefore not reached. This matters because § 1005.14 is the drafters' considered answer to exactly the question the commission is asking, in the one regime where they had to answer it — and the answer is stated in terms of **credentials and inter-institutional agreements**, not interfaces. Read together with S6-13 (the person, not the terminal) and S6-10 (the security procedure, not the channel the message came from), the pattern across three regimes and two sovereigns is consistent to the point of being unanimous.


---

### S6-15 · FINRA Rule 5310, Supplementary Material .08 ("Customer Instructions Regarding Order Handling") and .09(a); and FINRA Rule 3110(f)(2)(A)(ii)(g) · https://www.finra.org/rules-guidance/rulebooks/finra-rules/5310 and /3110 · retrieved 7 Sep 2026 — **DIRECT AUTHORITY** (securities; SRO rules)
- **Type:** SRO rules with supplementary material
- **Date / status:** Current FINRA rulebook as at 7 Sep 2026.
- **Verbatim quotes, pin-cited:**

> "**.08 Customer Instructions Regarding Order Handling.** If a member receives an **unsolicited instruction from a customer** to route that customer's order to a particular market for execution, **the member is not required to make a best execution determination beyond the customer's specific instruction.** Members are, however, still required to process that customer's order promptly and in accordance with the terms of the order." (FINRA Rule 5310, Supp. Mat. .08)

> "(a) **No member can transfer to another person its obligation to provide best execution to its customers' orders.**" (FINRA Rule 5310, Supp. Mat. .09(a))

> "g. **All orders are entered through the designated branch office or an electronic system established by the member** that is reviewable at the branch office;" (FINRA Rule 3110(f)(2)(A)(ii)(g) — a condition for an associated person's primary residence to be excluded from the definition of "branch office")

- **What it establishes:** Two things, pulling in different directions and both worth having.
  (i) Supp. Mat. .08 shows FINRA treating **a customer's own specific instruction as controlling**, to the point of displacing the member's own best-execution judgment. The qualifying features are that the instruction is **unsolicited** and **specific** — features of the instruction itself. Where it was given, and on whose screen, plays no part.
  (ii) Rule 3110(f)(2)(A)(ii)(g) is **the single located rule in which whose system matters** — order entry must run through "an electronic system **established by the member**." It is recorded here precisely because it is the one counter-instance, and because it turns out on inspection not to be about attribution at all: it is one of nine conditions for an associated person's home not to be a "branch office", i.e. a rule about **supervisory geography for the member's own registered people**. It says nothing about whose order it is, and it has no application to a customer.
- **Q3:** SUPPORT on (i); NEUTRAL on (ii). **Q2:** ADVERSE, mildly, on .09(a).
- **Level 2.** Reason: SRO supplementary material; .08 is about best-execution relief rather than attribution, and reaches the question only obliquely.
- **Application note:** Supp. Mat. .08's "unsolicited instruction … specific instruction" is close in shape to what the configuration produces — a per-order act by the member fixing a definite security, quantity, price band and day limit — and FINRA's response to such an instruction is to **defer to it**. Note the limit: .08 relieves the member of a best-execution *determination*; it does not opine on who authored the order. .09(a) is recorded as mildly adverse in the same family as NTM 05-48: the member's own obligations cannot be transferred outward, so nothing the runtime does relieves the broker, and correspondingly nothing the runtime does earns it any of the broker's standing. Rule 3110(f)(2)(A)(ii)(g) should be cited by nobody as a whose-system rule; if it is raised, the answer is that it governs branch-office designation for associated persons.


---

> **Provenance note for entries S6-16 to S6-22.** These were retrieved from **official court sources** — `txcourts.gov` media PDFs, `search.txcourts.gov` opinion media, and `courts.ca.gov/opinions/archive/<DOCKET>.PDF` — reached through the `r.jina.ai` reader proxy where the court's own gateway returns 403 to plain clients (see revised N4). I independently re-fetched and string-verified the load-bearing quotes in *Aerotek* (five probes), *Garza* (four probes) and *Garcia* (four probes) against those official files on 7 Sep 2026; all matched. **Pin-cites are slip-opinion pages, not reporter pages**, except *Ruiz* and *Espejo*, which carry true Cal.App.4th pagination from the Harvard Caselaw Access Project. See the ◇ list.

### S6-16 · *Aerotek, Inc. v. Boyd*, 624 S.W.3d 199 (Tex. 2021) (No. 20-0290, decided 28 May 2021) · https://www.txcourts.gov/media/1452283/200290.pdf · retrieved 7 Sep 2026 — **ANALOGY** (state UETA attribution; not securities)
- **Type:** State supreme court opinion (Hecht, C.J., for eight Justices; Boyd, J., dissenting)
- **Date / status:** Good law. The leading American decision on electronic-signature attribution.
- **Verbatim quotes, pin-cited (slip op.):**

> "Section 322.009(a) provides that an 'electronic signature is attributable to a person if it was the act of the person.' That 'may be shown in any manner, including a showing of the efficacy of any security procedure applied to determine the person to which the electronic record or electronic signature was attributable.'" (slip op. 9)

> "Thus, security procedures may include requiring personal identifying information—such as a social security number or an address—to register for an account; assigning a unique identifier to a user and then tying that identifier to the user's actions; maintaining a single, secure system for tracking user activities that prevents unauthorized access to electronic records; business rules that require users to complete all steps in a program before moving on or completing it; and timestamps showing when users completed certain actions. **These examples are illustrative and not exclusive** under Section 322.009(a)." (slip op. 10)

> "The efficacy of the security procedure provides the link between the electronic record stored on a computer or in a database and the person to whom the record is attributed. **A record that cannot be created or changed without unique, secret credentials can be attributed to the one person who holds those credentials.**" (slip op. 10)

> "To enter the application, a candidate was required to create for himself a unique identifier, a user ID, a password, and security questions, **all unknown to Aerotek**. … The application recorded and timestamped the candidate's every action. … **Once a candidate submitted his application, Aerotek could not modify its contents.**" (slip op. 11)

> "The Employees argue that no evidence supports a finding that they signed the MAAs because Marsh did not 'observe' them doing so. **But Marsh did not need to observe them because the hiring application did, invisibly storing in a database an electronic record of each action the Employees took.**" (slip op. 12)

> "The Employees argue that testimony from a computer programmer, or at least an IT expert, was required to prove the application's operation and security procedures. But Marsh testified that she had helped develop the application and managed its use in hundreds of thousands of instances. **She was sufficiently familiar with the hiring application to give testimony on its actual operation.**" (slip op. 12)

> "The Employees argue that Aerotek cannot conclusively prove they electronically signed the MAAs because 'people onboarding with Aerotek can, from anywhere, create their ID and password, and can also login from anywhere.' **In addition to proving too much, that argument does not account for Aerotek's evidence**, which conclusively established that the only way a person could access each Employee's information was through a secret combination of unique user ID, password, and security questions known only to the Employee." (slip op. 14)

> "**The Employees' simple denials are no evidence otherwise.**" (slip op. 16)

- **What it establishes:** The controlling factor list for whether an electronic act was **the act of the person**, and it is a list of **credential, record and process properties** — exclusivity of credentials, immutability, timestamps, forced-sequence business rules, a tamper-proof audit trail. Whose system it ran on appears nowhere in it. Two of the court's holdings bear directly on Track 6: it **rejected** the lower court's demand for testimony from the **third-party software developer** (whoever built the system need not vouch for it), and it **rejected** the argument that access "from anywhere" — i.e. on any device, in any place — defeats attribution.
- **Q3:** SUPPORT (strongly). **Level 4** — a unanimous-in-result state supreme court decision, universally cited, squarely on "whose act was it"; discounted from 5 only because it is state contract law, not securities law.
- **Application note:** This is the doctrinal frame the configuration's approval act would actually be judged under if the question were litigated as "was this the member's act?" Every factor on the *Aerotek* list is one the configuration can satisfy or exceed: a per-order act, an immutable instruction record bound to the exact displayed terms, a session nonce, timestamps, forced completion of the composed order, a journal that is append-only and replay-safe. **The one factor that requires care is the one the court stressed twice — "all unknown to Aerotek" and "Aerotek could not modify its contents."** See Downside 3 in answer C.

---

### S6-17 · *Ruiz v. Moss Bros. Auto Group, Inc.*, 232 Cal. App. 4th 836 (2014) and *Espejo v. Southern California Permanente Medical Group*, 246 Cal. App. 4th 1047 (2016) · https://www.courts.ca.gov/opinions/archive/E057529.PDF and /B262717.PDF · retrieved 7 Sep 2026 — **ANALOGY** (California UETA; not securities)
- **Type:** State intermediate appellate opinions, both published. The paired cases: *Ruiz* found authentication inadequate, *Espejo* adequate.
- **Date / status:** Good law; the standard pairing cited in every later California case.
- **Verbatim quotes, pin-cited (Cal.App.4th pagination):**

*Ruiz* — the four things the declarant failed to explain:
> "Indeed, Main did not explain that an electronic signature in the name of 'Ernesto Zamora Ruiz' **could only have been placed** on the 2011 agreement … **by a person using Ruiz's 'unique login ID and password'**; that the date and time printed next to the electronic signature indicated the date and time the electronic signature was made; that all Moss Bros. employees were required to use their unique login ID and password when they logged into the HR system and signed electronic forms and agreements; and the electronic signature on the 2011 agreement was, therefore, apparently made by Ruiz on September 21, 2011, at 11:47 a.m." (232 Cal.App.4th at 844)

> "In the face of Ruiz's failure to recall electronically signing the 2011 agreement, **the fact the 2011 agreement had an electronic signature on it in the name of Ruiz, and a date and time stamp for the signature, was insufficient** to support a finding that the electronic signature was, in fact, 'the act of' Ruiz." (id. at 844)

> "As indicated, **the burden of authenticating an electronic signature is not great**." (id. at 844–45)

*Espejo* — what closed the gap:
> "Tellez detailed SCPMG's security precautions regarding transmission and use of an applicant's unique user name and password, as well as the steps an applicant would have to take to place his or her name on the signature line … Based on this procedure, she concluded that the 'name Jay Baniaga Espejo **could have only been placed** on the signature pages … **by someone using Dr. Espejo's unique user name and password**. … Given this process for signing documents and protecting the privacy of the information with unique and private user names and passwords, the electronic signature was made by Dr. Espejo' … **at the date, time, and IP address listed on the documents.**" (246 Cal.App.4th at 1062)

- **What it establishes:** California's operative test is a single question — **could anyone other than the purported signer have placed the mark?** — answered by credential exclusivity plus a declarant who explains *how he knows*. A signature and a timestamp, without an explanation tying them to exclusive credentials, is not enough. Nothing in either opinion asks whose system rendered the screen.
- **Q3:** SUPPORT. **Level 3** each (published state intermediate appellate; different regime).
- **Application note:** The *Ruiz*/*Espejo* line tells the configuration what its journal has to be able to say, in a declarant's voice: that the instruction record for this order **could only** have been minted by the member's own act on the approval surface. The configuration's authentication mark bound to order and session nonce is built to support exactly that sentence — but note *Ruiz*: the artifacts are not self-proving, and someone must be able to explain the procedure. **The burden is expressly "not great."**

---

### S6-18 · *Banister v. Marinidence Opco, LLC*, 64 Cal. App. 5th 541 (2021) (No. A159815, filed 30 Apr. 2021, published 21 May 2021) · https://www.courts.ca.gov/opinions/archive/A159815.PDF · retrieved 7 Sep 2026 — **ANALOGY**
- **Type:** State intermediate appellate opinion, published
- **Date / status:** Good law.
- **Verbatim quotes, pin-cited (slip op.):**

> "For example, a party may establish that the electronic signature was 'the act of the person' by presenting evidence that **a unique login and password known only to that person** was required to affix the electronic signature, along with evidence detailing the procedures the person had to follow to electronically sign the document and the accompanying security precautions." (slip op. 4)

> "Marinidence's evidence did not establish that Bannister was assigned a unique, private user name and password such that she is the only person who could have accessed the onboarding portal and signed the agreement; instead, the evidence showed that **the requisite 'Client ID' and pin code was not employee-specific, and Matson had access to the information necessary to access the onboarding portal via employee personnel records.**" (slip op. 6)

> "The court concluded that '[a]t best,' Marinidence's evidence was of 'equal weight' to Bannister's countervailing evidence that '**Matson had the ability and motive to access [Bannister's] onboarding account.**'" (slip op. 7)

> "**Because Bannister's evidence showed that she was not the only person who could have executed the arbitration agreement**, we disagree that the trial court committed any legal error." (slip op. 8)

- **What it establishes:** Attribution **failed** because a person on the proponent's own side — an HR manager — had the ability to reach the account and place the mark. Shared, non-user-specific credentials defeated attribution. The device facts (the manager's own laptop; the employee "never operated Matson's laptop computer"; remote onboarding without the employee present) are recited as **evidence that another human could have clicked**, not as a rule about whose device it was.
- **Q3:** **ADVERSE** in structure — see application note. **Level 3.**
- **Application note:** *Banister* is the case the configuration must be able to distinguish, and it is the sharpest of the case-law entries. The losing fact was that **the party asserting the signature had the practical ability to produce it**. Transposed: a runtime that renders the approval surface, holds the member's trade credentials in its vault, and mints the instruction record has, on its face, the practical ability to produce the very artifact it later relies on. That is *Banister*'s losing posture, not *Aerotek*'s winning one — unless the configuration can show, as *Aerotek*'s employer could, that the deciding secret is one the runtime's operator never holds and the record is one it cannot modify.

---

### S6-19 · *Garcia v. Stoneledge Furniture LLC*, 102 Cal. App. 5th 41 (2024) (No. A166785, filed 17 May 2024) · https://www.courts.ca.gov/opinions/archive/A166785.PDF · retrieved 7 Sep 2026 — **ANALOGY**
- **Type:** State intermediate appellate opinion, published
- **Date / status:** Good law. Already in P7's register; extended here.
- **Verbatim quotes, pin-cited (slip op.):**

> "On her first day of work in early 2016, she completed onboarding paperwork using **Taleo, a third-party electronic workforce management platform used by RAC**." (slip op. 1)

> "Here, RAC failed to carry its burden because the evidence it provided … **did not show that only Garcia could have placed the electronic signature on the arbitration agreement.**" (slip op. 14)

> "The trial court found that Dale's declaration did not detail the security precautions regarding the use of the Taleo username and password; the arbitration agreement lacked a date, time, or IP address; and **the agreement contained no indication it was created within the Taleo system.** The court also took into consideration and credited Garcia's statements disputing the reliability of the evidence … The court also suggested the declaration lacked sufficient detail regarding the security precautions employed by RAC, **noting that managers had access to arbitration agreements.**" (slip op. 15, and trial-court findings at slip op. 7)

> "We join the legion of courts that have concluded **a denial of signing an arbitration agreement is sufficient to shift the burden.**" (slip op. 12)

- **What it establishes:** **The single most useful case in the set for Track 6's question, and it cuts the opposite way from the architecture's premise.** The signing ran on a **third party's** platform. The court did not treat third-party rendering as a defect or as anything at all. It went the other way: the **absence** of the third-party platform's own markings counted **against** the proponent — "no indication it was created within the Taleo system." Third-party rendering functioned as a **source of corroborating artifacts**, not as a disqualification.
- **Q3:** SUPPORT. **Level 3.**
- **Application note:** A court presented with a two-party architecture — employer asserting, third-party platform rendering — asked only whether the artifacts showed that **only the signer** could have placed the mark, and treated the platform's own tamper-evident markings as **evidence in the proponent's favour when present and a gap when absent.** For the configuration this is the most directly encouraging case located: it implies a runtime-owned surface that stamps its own verifiable markings on the record is producing exactly the artifact a court looks for. It also implies the converse — a record that does not visibly bear the rendering system's own marks is weaker, not neutral.

---

### S6-20 · *Fabian v. Renovate America, Inc.*, 42 Cal. App. 5th 1062 (2019) (No. D075519, filed 19 Nov. 2019, published 4 Dec. 2019) · https://www.courts.ca.gov/opinions/archive/D075519.PDF · retrieved 7 Sep 2026 — **ANALOGY**
- **Type:** State intermediate appellate opinion, published
- **Date / status:** Good law.
- **Premise correction, recorded because my brief assumed otherwise:** *Fabian* is **not**, on the face of the opinion, a third-party-contractor-device case. The words "contractor", "installer", "dealer", "third party", "device", "computer", "tablet", "IP address", "portal", "website" and "platform" appear **zero times**; "DocuSign" appears 18 times. The opinion's own frame is direct telephone solicitation by the lender. Anything about a home-improvement contractor running the envelope is in the record or briefs, **not in this opinion**, and cannot be cited to it.
- **Verbatim quotes, pin-cited (slip op.):**

> "Renovate first contends the Contract bearing Fabian's printed electronic initials and signature is authenticated by DocuSign. **Standing alone, that fact is not sufficient to compel a result in Renovate's favor as a matter of law.**" (slip op. 8)

> "Renovate offered no evidence about the process used to verify Fabian's electronic signature via DocuSign, including **who sent Fabian the Contract, how the Contract was sent to her, how Fabian's electronic signature was placed on the Contract, who received the signed the Contract, how the signed Contract was returned to Renovate, and how Fabian's identification was verified as the person who actually signed the Contract.**" (slip op. 9) *(the "who received the signed the Contract" typo is in the official PDF)*

> "Anderson did not explain, for instance, **who presented Fabian with a physical or electronic copy of the Contract, the specific location where the Contract was signed, the time when the Contract was signed**, or how Anderson ascertained that Fabian was present when the Contract was signed." (slip op. 10–11)

> "Anderson did not explain how Fabian's electronic initials and signature were the 'act of Fabian' by offering evidence that **DocuSign assigned Fabian a unique 'identity verification code'** to initial and sign the Contract." (slip op. 11)

- **What it establishes:** **The closest any located decision comes to making the signing channel legally relevant** — and it stops short of a rule. The court's list is a **chain-of-custody** list: who sent, how sent, how the mark was placed, who received, how it was returned, how identity was verified, who presented, where. That is genuinely about custody of the signing channel. But it is framed as **an evidentiary gap in the proponent's showing**, not as a doctrine that the identity of the rendering party changes the analysis. The implied remedy is *explain your chain*, not *you did not own the screen, so you lose*. A named e-signature vendor is not self-authenticating.
- **Q3:** SUPPORT, with a caution. **Level 3.**
- **Application note:** *Fabian*'s list is the most useful checklist located for what a runtime-owned approval surface should be able to evidence, and the configuration's journal — source → policy version → composed order → exact terms shown → instruction → adapter → broker response — is close to a purpose-built answer to it. The caution: *Fabian* shows that **artifacts without an explanation fail**, and that the party asserting the signature must be able to speak to the whole chain.

---

### S6-21 · *Solcius, LLC & GoodLeap, LLC v. Meraz*, No. 08-22-00146-CV (Tex. App.—El Paso 27 Feb. 2023, no pet.) (mem. op.) and *GoodLeap, LLC v. Garza*, No. 13-25-00224-CV (Tex. App.—Corpus Christi–Edinburg 23 Oct. 2025, no pet.) (mem. op.) · https://search.txcourts.gov (official opinion media; see provenance note) · retrieved 7 Sep 2026 — **ANALOGY**
- **Type:** State intermediate appellate memorandum opinions
- **Date / status:** *Meraz* mandate 19 May 2023. *Garza* mandate 7 Jan. 2026. Both good law; both memorandum opinions.
- **Verbatim quotes, pin-cited (slip op.):**

*Meraz* — the standard and the factors credited:
> "In determining whether an electronic signature can be attributed to an individual, **the Act's focus is on the efficacy of the security procedures inherent in the electronic transaction itself.**" (slip op. 10)

> "[D]ocuments transmitted via DocuSign **can only be opened by an individual with access to the customer provided e-mail address**." (slip op. 14)

> "**The certificate provided an IP address that corresponded to the mobile phone that had been used to sign the agreement.**" (slip op. 15)

> "Meraz … **failed to present any evidence to suggest that the listed IP address for the mobile phone used to complete the electronic transactions was not associated with his device.**" (slip op. 16–17)

*Garza* — the third party's tablet, squarely presented:
> "In April 2022, two door-to-door salesmen employed by Vantage Point Solar, LLC (VPS) visited Garza's home … **he signed and initialed his name electronically on a tablet provided by the salesmen.** The negotiations were done entirely in Spanish." (slip op. 3)

> "While they were at my house, the sales agents showed me the tablet they brought with them and asked me to click several times where they were pointing with their hands. … **I could really only see boxes and lines to mark the screen.**" (Garza affidavit, quoted at slip op. 7–8)

> "**Regardless of whether any enforceable contract was executed during the April 2022 sales pitch**, Garza recognizes in his affidavit that the 'Loan Agreement'—the only agreement which contains the arbitration clause at issue in this appeal—was **a separate agreement with a separate entity**, executed approximately one month after his meeting with the salesmen. Crucially, Garza did not deny … that he electronically signed the 'Loan Agreement' on May 20, 2022." (slip op. 14)

> "In any event, **because Garza did not deny that he electronically signed the 'Loan Agreement,' we need not determine whether Mellott's affidavit was sufficient to show the 'efficacy of any security procedure' verifying Garza's identity.**" (slip op. 13 n.3)

- **What it establishes:** **This is the decisive pair for answer A.** *Garza* is the one located case in which a third party's device was unambiguously the site of the click — a salesman's tablet, in the signer's home, in a language he did not read, showing only "boxes and lines". **The court declined to build any rule on it.** It severed the transaction (the arbitration clause lived in a later, separate agreement with a separate entity) and expressly reserved the efficacy question. In *Meraz* the installer and the lender were separate entities and the court "review[ed] each agreement separately", accepting each proponent's own declarant describing its own process; the only device-linked sentence runs **against** the signer, treating device association as **his** burden to disturb.
- **Q3:** SUPPORT (as documented indifference). **Level 2** each — memorandum opinions, and *Garza* expressly reserves the point.
- **Application note:** A court handed the strongest imaginable whose-device facts declined to decide on them. That is the most honest available answer to the commission's question: **not that courts have rejected a surface-based rule, but that they have had the chance to adopt one and have not.** Note also *Meraz*'s structure — installer and lender as separate entities, each proving its own process — which is close to the configuration's engine/runtime/broker separation, and was unremarkable to the court.

---

### S6-22 · *Ambit Marketing, LLC v. TLC Energy Group, LLC*, No. 05-24-00009-CV (Tex. App.—Dallas 13 Nov. 2024, pet. denied) (mem. op.) · https://search.txcourts.gov (official opinion media) · retrieved 7 Sep 2026 — **ANALOGY**
- **Type:** State intermediate appellate memorandum opinion
- **Date / status:** Petition for review **denied** by the Supreme Court of Texas 5 Sept. 2025; mandate 16 Oct. 2025.
- **Verbatim quotes, pin-cited (slip op.):**

> "**A party's agreement to conduct a particular transaction electronically, however, may not establish its agreement to alter unrelated, material contract terms.**" (slip op. 16)

> "**We must give meaning to the UETA's explicit requirement that for a transaction to fall under the Act, there must be a meeting of the minds; here, that the parties intended to use PowerZone not just as a payment portal, but as the means by which the parties would exchange and execute contractual agreements.**" (slip op. 18)

> "**It is not uncommon for administrative functions, such as providing banking information through a payment portal, to be performed by individuals within a company who are not authorized to bind an entity to material contract terms.**" (slip op. 18–19)

> "In Aerotek and similar cases, prospective employees were 'onboarding' … **not accepting unilateral, material changes to already-existing agreements.**" (slip op. 17)

- **What it establishes:** A gate that sits **before** attribution: the parties must have agreed that **this channel is an execution channel**, not merely an operational one. Credentials were undisputed; the signature still did not bind, because nobody had agreed that clicking through a payment portal was how contracts got made, and because the human at the interface may lack authority to bind.
- **Q3:** **ADVERSE**, and usefully so. **Level 2** (memorandum opinion, but petition denied).
- **Application note:** *Ambit* identifies the one question that must be settled **before** the *Aerotek* factors do any work: **is this surface agreed to be the place where instructions are given?** In the configuration, the member types his own policy during onboarding, enables each source by an explicit logged local act, and places each order by an explicit act on the runtime's approval surface — so the designation is about as express as it could be **as between the member and the runtime**. It is *not* express as between the member and **the broker**, who has agreed only to its own published retail API under the member's own credentials and has agreed nothing about the runtime's surface. That is the same gap S6-10 identifies from the Article 4A side, reached by a different route, and it is the gap most worth closing.


---

## Adverse register

| # | Authority | Threat 1–5 | Does the configuration distinguish it? |
|---|---|---|---|
| A1 | **Reg E Official Interpretation, comment 10(b)-2** — "it is the third-party payee that is in violation of the regulation" where the party that **obtained** the authorization failed to obtain or document it properly (12 C.F.R. pt. 1005, Supp. I) | **4** | **No — and this is the core adverse finding.** The configuration's whole design puts the runtime in the position of the party that obtains the authorization: it draws the screen, displays the terms, captures the tap, and mints the record. Comment 10(b)-2 is the clearest located statement that this position carries its own regulatory exposure, independent of the acting institution's. The configuration cannot distinguish it on structure; it can only distinguish it on regime (Reg E is a consumer-payments rule and there is no securities analogue located) and on the fact that the runtime is locally installed on the member's own machine rather than operated as a service. Neither distinction has been tested. **The commission asked for the downside; this is it.** |
| A2 | **12 C.F.R. § 1033.431(c)** — the party that performs the authorization procedure must itself **certify to the consumer** and comply with § 1033.421(a)–(f) and (i); § 1033.431(b) — it must be **named** in the authorization disclosure | **4** | **No.** In the closest located regulatory model of the configuration's architecture, the renderer of the consent surface is not invisible: it is named to the consumer, it certifies in its own right, and it takes on substantive conditions. The rule does *not* make the consent the renderer's consent — but it does make the renderer a regulated participant. The configuration's runtime is named and locally installed, which is a better posture than the aggregator the rule addresses, but the direction of the rule is that rendering **adds** obligations rather than subtracting them. |
| A3 | **Rel. 33-7856 n.25** — the issuer or broker-dealer "retains the ultimate responsibility for assuring that the consent is authentic" (65 FR at 25846 n.25) | **3** | **Partly — and in a way that undercuts the architecture's premise rather than threatening it.** The Commission put responsibility for authenticity on the party that **acts on** the consent, not on the party that captured it. Read against the configuration, this says: a runtime-owned approval surface, however hardened, does not move responsibility off the broker, and does not confer any legal characteristic on the runtime's operator. The surface is **legally inert** on this authority. That is not a threat of liability; it is a finding that no located authority pays for the engineering. It matters because the configuration's design memo treats the surface as doing legal work. |
| A4 | **Rule 15c3-5 adopting release, 75 FR at 69810** — "the Commission will look at the substance rather than the form of the relationship"; a third party is not independent of the customer merely because it is not an affiliate, if it "has a material business or other relationship with the customer" | **3** | **Partly.** The test is directed at a different question — whether a risk-control vendor is independent enough to serve the broker — and the configuration puts pre-trade risk control with the broker, where the rule wants it. But it establishes the Commission's willingness to disregard formal separation between a customer and the technology provider standing beside him, on a "material business or other relationship" trigger that a paid monthly membership would meet. |
| A5 | **NASD NTM 05-48** — a third party conducting functions requiring registration "will be considered associated persons of the member"; outsourcing "does not relieve members of their ultimate responsibility" | **3** | **Yes, on its predicate.** NTM 05-48 presupposes that a **member engaged** the provider. No broker engages the runtime; there is no outsourcing relationship and no broker has contracted for the surface. Recorded because it is the securities-side expression of the same pattern as A1 and A2, and because it identifies exactly what must never become true: if a broker ever engaged the runtime to render its customers' approval surface, this is the first authority that would be pointed at. |
| A6 | **NASD NTM 98-66, ¶¶ 1, 3, 10** — the conditions attached to customer electronic order entry: a letter to Nasdaq acknowledging responsibility, a system description, KYC assessment, member supervision of "the entry of unauthorized orders", and **an agreement between the service bureau and Nasdaq** | **3** | **No.** The notice's *holding* helps the configuration (see S6-01); its *conditions* do not. Every one of them is a condition the configuration lacks: no notification to any market, no system description filed, no broker supervision of the surface, and no agreement between the surface's builder and anyone. The notice is the closest located securities authority on the fact pattern, and it granted permission **only** on a bundle of conditions the configuration does not share. This mirrors the pattern P7 already recorded for the CommandTRADE and Schwab letters. |
| A7 | **CFPB, EFT FAQs, Coverage: Financial Institutions Q1** — providers of payment services are financial institutions "if they issue an access device and agree with a consumer to provide EFT services" | **2** | **Yes, on its facts.** The runtime issues no access device and agrees to provide no transfer service; trade-capable credentials are the member's own, in his own local keychain, and there is no company-level or app-level trading credential. Recorded because it is a third instance of the same structural move: the surface's owner is a candidate for regulated status on grounds that have nothing to do with who authorized what. |
| A8 | **CFPB ANPRM, 90 FR 40986, Questions 3 and 7** — whether a "representative acting on behalf of an individual" must hold **fiduciary** duties, and "what elements are required in establishing that the individual is a 'representative' acting on behalf of the consumer" | **2** | **No, but it is an open question rather than an adverse holding.** The single provision that makes Part 1033 an attractive analogy — subpart D's treatment of an authorized third party as the consumer's "representative" — is the provision the Bureau has put back on the table. Anything built on the Part 1033 analogy should be built knowing the analogy is under reconsideration as at 7 Sep 2026. |
| A9 | **RCW 62A.4A-202(b)** — a security procedure confers attribution only where the customer and **the party that acts** have agreed to it | **2** | **No.** The configuration's authentication mark is derived from a runtime secret and bound to the order and session nonce, but the broker has not agreed to it and does not verify it. Under a § 4A-202(b) analysis the mark would therefore not be a security procedure at all. It remains excellent evidence of what the member did (subsection (a), actual authority) — which is the track the configuration should be arguing on — but it is not the statutory attribution device it might appear to be. |
| A10 | **17 C.F.R. § 240.17a-3(a)(6)(i)**, branch (2) — the order memorandum must show "the identity of **any other person who entered or accepted the order on behalf of the customer**" (66 FR at 55838) | **4** | **No — this is the sharpest unclosed gap on Q3.** Federal law's enumeration of order authorship has a branch for the customer entering on an electronic system and a branch for "any other person who entered or accepted the order **on behalf of** the customer." Nothing located sorts software that composes an order from the member's own policy and transmits it under his credentials between those two branches. The rule says "person", and P7 has already recorded that **no authority applies § 3(a)(35) to software in either direction** — so the gap cannot be closed by analogy from that side either. The configuration's per-order human act is its best answer, and it is a good one; but it is an argument, not an authority. |
| A12 | ***Banister v. Marinidence Opco, LLC***, 64 Cal. App. 5th 541 (2021), slip op. 6–8 — attribution fails where the party asserting the signature "had the ability and motive to access" the account and the signer "was not the only person who could have executed" the agreement | **5** | **No, not on structure — only on proof.** This is the highest-rated adverse item in the track and the one the brief did not anticipate. The runtime renders the surface, holds the credentials, and mints the record; that is the configuration of a party able to manufacture its own evidence. *Aerotek* shows the escape — credentials "all unknown to" the proponent and a record it "could not modify" — but the escape must be **provable**, not merely true in practice, and someone must be able to explain how it is known. Nothing in the configuration as described establishes that the runtime's **operator** cannot reach the vault or the journal on a member's machine. Until that is provable, the surface's ownership is an exposure. |
| A13 | ***Ambit Marketing, LLC v. TLC Energy Group, LLC***, No. 05-24-00009-CV (Tex. App.—Dallas 2024, pet. denied), slip op. 16–19 — UETA requires "a meeting of the minds … that the parties intended to use [the channel] not just as a payment portal, but as the means by which the parties would exchange and execute contractual agreements" | **3** | **Partly.** As between the **member and the runtime** the designation is about as express as it could be: the member types his own policy, enables each source by an explicit logged act, and places each order by an explicit act on the surface. As between the **member and the broker** it is absent — the broker has agreed to its own published retail API under the member's own credentials and has agreed nothing about the runtime's approval surface. *Ambit* is a gate that operates **before** the *Aerotek* factors do any work. Same gap as A9, reached from a different direction. |
| A11 | **CFPB, 90 FR 20084 (12 May 2025)** — the Bureau withdrew "**all guidance documents**" pending review, including every Circular from 2022-01 through 2024-06, and "does not intend to prioritize the enforcement of such guidance" | **2** | **Not applicable to the configuration, but it degrades part of this register.** It does not touch 12 C.F.R. pts. 1005, 1026 or 1033 or their Official Interpretations, which are regulation. It does mean that the CFPB **non-regulatory** material relied on here (S6-06, the EFT FAQs) sits in a regime where the agency has disclaimed its own guidance wholesale. S6-06 is weighted at Level 2 accordingly, and nothing in the Direct answers rests on it alone. |

---

## Direct answers

### A. Is there **any** authority — direct, not analogy — in which the identity of the rendering surface affected attribution?

**No. None was located, and the searches are documented below.**

Across 50 CourtListener full-text queries; four eCFR parts retrieved in full (12 C.F.R. pts. 1005, 1026, 1033 and 17 C.F.R. § 240.15c3-5); seven Federal Register full texts (65 FR 25843; 66 FR 55818; 75 FR 69792; 89 FR 90838; 90 FR 40986; 90 FR 20084; 90 FR 48710); six FINRA notices and four FINRA rules; the SEC's Rule 15c3-5 FAQs; the CFPB's EFT FAQs; three Washington statutes; and repeated use of the Federal Register document API — **no instrument and no decision was located in which the identity of the party that rendered the screen was a factor in deciding whose act it was.** The targeted queries designed to find exactly that returned zero:

- `"screen" "rendered by" signature attribution electronic agreement` — **COUNT 0**
- `"the interface" "displayed" attribution signature "who prepared"` — **COUNT 0**
- `"who owned the website" electronic assent attribution` — **COUNT 0**
- `"customer instruction" broker "order was entered by" attribution` — **COUNT 0**
- `"hosted payment page" iframe merchant cardholder data` — **COUNT 0**
- `"electronic signature" arbitration third-party vendor portal authentication employee` — **COUNT 0**
- Federal Register, term `"hosted payment page"`, all agencies, all years — **COUNT 0**

**The closest thing to direct authority, on the facts, is NASD Notice to Members 98-66 (S6-01)** — and it points the other way from the architecture's premise. It attributes the order to "**the customer inputting the order**" while the surface belongs to the broker, and it expressly permits a **third-party service bureau to build and operate that surface** (¶10) without the order ceasing to be the customer's.

Two further items rank alongside it and should be read with it:

- **The most authoritative statement of what the law looks at instead** is the books-and-records adopting release and the rule text it adopted, 66 FR 55818 (S6-13). This is the only located federal instrument that **enumerates** who can have entered an order, and it enumerates by **person and role** — the responsible associated person; "any other person who entered or accepted the order on behalf of the customer"; the customer entering "on an electronic system"; and, separately designated, an order entered under discretionary authority. The electronic system appears only as a circumstance and is **never identified by owner**. The Commission's terminal passage settles the point directly: a terminal's identifier is acceptable **as a proxy**, but on request the firm "must provide **the actual identity of the person who entered the order**." The device is a stand-in for a person; it is never the fact itself.
- **The strongest Commission-level statement on the fact pattern** is the Rule 15c3-5 adopting release (S6-02), which calls it "customers … enter[ing] orders" even where the orders **bypass the broker's trading system entirely** and are produced with the support of "a service bureau or other third party technology provider."

**The case law confirms this independently, and in the strongest available form.** Seven attribution decisions were retrieved from official court sources and read (S6-16 to S6-22). **Not one turned on whose system rendered the screen.** The decisive item is *GoodLeap, LLC v. Garza* (Tex. App. 2025): a signature placed on "a **tablet provided by the salesmen**", in the signer's home, in a language he could not read, where he "could really only see **boxes and lines to mark the screen**". A court handed the strongest imaginable whose-device facts **severed the transaction and expressly reserved the efficacy question** — "we need not determine whether Mellott's affidavit was sufficient to show the 'efficacy of any security procedure'" (slip op. 13 n.3). It had the chance to adopt a surface-based rule and declined.

Two further findings foreclose the theory from the other side:
- *Aerotek* **rejected** the lower court's demand for testimony from the **third-party software developer**: an in-house manager who "helped develop the application" was "sufficiently familiar with the hiring application to give testimony on its actual operation" (slip op. 12). It also rejected the argument that access "from anywhere" defeats attribution (slip op. 14). **Who built the system, and on what device it was reached, were both held not to matter.**
- *Garcia v. Stoneledge* ran on "**Taleo, a third-party electronic workforce management platform**" (slip op. 1) and the court treated third-party rendering as entirely unremarkable — indeed the **absence** of that platform's markings counted *against* the proponent: "the agreement contained no indication it was created within the Taleo system" (slip op. 15).

The nearest thing to a contrary case is *Fabian* (S6-20), whose chain-of-custody list — "**who sent** … **who received** … **who presented** … the **specific location** where the Contract was signed" (slip op. 9, 10–11) — is genuinely about custody of the signing channel. But it is framed as an **evidentiary gap in the proponent's showing**, not as a rule that the renderer's identity changes the analysis.

So the honest characterisation stands and is now doubly supported: **the surface is not a fact the law has needed** — not in the securities instruments, and not in the case law that decides "whose act was it" for a living.

The honest characterisation is therefore not that the authorities are silent, but that **they are uniformly indifferent**. The surface is not a fact the law has ever needed. Where a source has had the occasion to name what carries attribution, it has named something else every time.

### B. On the located material, what **does** carry attribution? Ranked by the authority behind each.

**1 · Actual authority — did this person authorize it.** The most authority by a wide margin, and the only ground that appears in every regime examined.
- 12 C.F.R. § 1005.2(m): "initiated by a person other than the consumer **without actual authority** to initiate the transfer" (S6-04).
- 12 C.F.R. § 1026.12(b)(1) n.22: "a person, other than the cardholder, who does **not have actual, implied, or apparent authority** for such use" (S6-11).
- RCW 62A.4A-202(a): "if that person **authorized the order or is otherwise bound by it under the law of agency**" (S6-10).
- Reg E comment 10(b)-5: "**Only the consumer may authorize** the transfer and not, for example, a third-party merchant on behalf of the consumer" (S6-05).
- **66 FR at 55819** (securities, and the only one of these in the right regime): a computer terminal's identifier will do **as a proxy**, but on request the firm "must provide **the actual identity of the person who entered the order**" (S6-13).
- And the case law's master question, stated in near-identical words in four decisions: **could anyone other than the purported signer have placed the mark?** — *Ruiz*, 232 Cal.App.4th at 844 ("could only have been placed … by a person using Ruiz's 'unique login ID and password'"); *Espejo*, 246 Cal.App.4th at 1062; *Garcia*, slip op. 14 ("did not show that only Garcia could have placed the electronic signature"); *Banister*, slip op. 8 ("she was not the only person who could have executed"); *Fabian*, slip op. 10. It is answered by **credential exclusivity**, never by hardware.
This is the configuration's strongest ground and the one its facts are actually built for: one explicit tap or swipe by the member, per order, on a complete composed order, with no standing authority granted to anyone. Note that the securities entry in this rank is the one that most explicitly subordinates the device to the person.

**2 · Credentials and identifiers.** Second-strongest, and the only surface-adjacent concept the sources use.
- Rule 15c3-5(b) and the adopting release: responsibility attaches "through use of its **market participant identifier** or otherwise"; "the broker-dealer with market access is legally responsible for all trading activity that occurs **under its MPID**" (S6-02).
- NTM 98-66 ¶1: "All orders submitted by customers into SelectNet will have the member's **Market Participant Identifier (MPID)** attached to them" (S6-01).
- Reg E § 1005.2(m)(1) and comments 2(m)-2, -3: the **access device** is the operative object (S6-04).
- Rel. 33-7856 Example 1: authenticity assured "because of his use of a **personal identification number**" (S6-03).
Note the direction this cuts for the configuration: orders go under **the member's own broker credentials**, and no company-level or app-level trading credential exists. On the ranking, that is the second-best fact in the configuration after the per-order act itself — and it is a fact about credentials, not about surfaces.

**3 · A security procedure.** Strong where a statute supplies one, but narrower than it looks.
- RCW 62A.4A-202(b): a payment order is "effective as the order of the customer, **whether or not authorized**", where a commercially reasonable security procedure was complied with in good faith (S6-10). Note the condition: § 4A-201 requires the procedure to be "**established by agreement of a customer and a receiving bank**." A procedure the acting party never agreed to is not a security procedure under this section.
- ESIGN/UETA attribution (P7's layer) supplies the same idea without the agreement requirement.
- Reg E comment 10(b)-5: "**A security code need not originate with the account-holding institution**"; the process "should evidence the consumer's identity and assent" (S6-05). This is the one located sentence that expressly blesses an authentication mark supplied by a party other than the actor.
- And *Aerotek*'s controlling and expressly **non-exclusive** list of what a security procedure may include: "requiring personal identifying information … ; assigning a unique identifier to a user and then tying that identifier to the user's actions; maintaining a single, secure system for tracking user activities that prevents unauthorized access to electronic records; business rules that require users to complete all steps in a program before moving on or completing it; and timestamps showing when users completed certain actions" (slip op. 10). Every item is a property of **credentials, records and process**. None is a property of the surface's owner.

**4 · The record — what the acting party received and can document.** Growing, and the most modern of the four.
- 89 FR at 90905: the data provider needs "**information sufficient to document** such authorization", and "receipt of a **copy of the signed authorization disclosure** should constitute information sufficient to confirm third party authorization, absent facts to the contrary" (S6-08).
- 12 C.F.R. § 1033.401(c): consent is obtained "by obtaining an authorization disclosure that is **signed by the consumer** electronically or in writing" (S6-07).
- Rel. 33-7856: the confirming letter and the retained record of consent (S6-03).
This is the rank the configuration's journal and instruction record speak to, and the CFPB's "information sufficient to document" is the closest located articulation of what such a record is for. Note that in Part 1033 the record travels **from** the renderer **to** the actor — which is exactly the configuration's flow.

**5 · The party who acted on the consent.** Carries **responsibility**, not attribution — and this distinction is the single most important one in the whole track.
- Rel. 33-7856 n.25: the issuer or broker-dealer "**retains the ultimate responsibility** for assuring that the consent is authentic" (S6-03).
- Reg E comment 10(b)-2: conversely, where the defect is in **obtaining** the authorization, "it is the **third-party payee** that is in violation" (S6-05).
- 12 C.F.R. § 1033.431(a): "the third party seeking authorization **remains responsible** for compliance with the authorization procedures" even where a data aggregator performs them (S6-07).

**6 · The rendering surface.** **Nothing.** No located source assigns it any weight, in either direction.

### C. Does anything located suggest a **downside** to the runtime-owned surface?

**Yes. Three, and the third — found in the case law and not anticipated by the brief — is the one that should change how the surface is described.**

**Downside 1 — the renderer acquires duties.** This is the pattern the commission asked to be looked for, and it recurs in every regime examined, without exception:

- **Reg E comment 10(b)-2:** where the authorization is defectively obtained, "**it is the third-party payee that is in violation of the regulation**" — the acting institution "does not violate the regulation." Liability follows the obtainer.
- **Reg E comment 10(b)-5:** "**The person that obtains the authorization** must provide a copy of the terms of the authorization to the consumer." A duty, imposed on the renderer by virtue of rendering.
- **12 C.F.R. § 1033.431(b), (c):** the party performing the authorization procedure must be **named** in the disclosure and must **certify to the consumer** in its own right, and must comply with § 1033.421(a)–(f) and (i).
- **12 C.F.R. § 1033.441:** it must maintain written policies and procedures and **retain records for three years**.
- **NASD NTM 98-66 ¶10:** "**No service bureau is permitted to operate a service on behalf of a member unless the service bureau has entered into an agreement with Nasdaq.**"
- **NASD NTM 05-48:** a third party conducting functions requiring registration "**will be considered associated persons of the member**", absent separate broker-dealer registration.
- **CFPB EFT FAQs, Coverage Q1:** a payment-service provider is itself a **financial institution** if it "issue[s] an access device and agree[s] with a consumer to provide EFT services."

The consistent shape is: **rendering the consent surface never transfers the consent to the renderer, but it never leaves the renderer untouched either.** In no located source did the party that drew the screen end up with nothing. The configuration's runtime is better placed than any of these actors on its facts — locally installed on the member's machine, no access device issued, no data or trading credential held at company level, no service relationship with any broker — but the direction of every located instrument is that the obtainer of a consent is a person the law has something to say to.

**Downside 2 — the surface may be legally inert, which makes the engineering unpaid-for.** This is the more consequential finding and it is not a liability risk; it is a design risk.

Rel. 33-7856 n.25 puts responsibility for the authenticity of a consent on **the party that acts on it**, expressly, and says nothing that would let the renderer's care substitute for the actor's responsibility. Rule 15c3-5 puts responsibility on **the MPID holder**. NTM 98-66 puts it on **the member**, and required a **letter to Nasdaq** rather than treating good engineering as self-executing. Part 1033 § 1033.431(a) keeps responsibility with **the principal** even where the aggregator performs the procedure. In none of these does building a better surface move anything.

The adverse reading is therefore not "the runtime becomes a broker because it renders the screen." It is: **no located authority attaches any consequence to who renders the screen, so the separate signed process, the native top-level window, the input isolation, the absence of accessibility and screen-capture access, and the runtime-minted authentication mark buy evidentiary quality and nothing else.** They make it easier to prove what the member did. They do not make the act more the member's than it already was, and they do not make the runtime's operator less of a participant than its other conduct makes it. If the architecture's memo treats the runtime-owned surface as answering the customer-instruction question, that is a level the sources do not support: the question is answered — to the extent it is answered at all — by the **per-order act**, by the **member's own credentials**, and by the **absence of any grant of discretionary authority**, none of which depend on who drew the window.

**Downside 3 — in the case law, controlling the rendering system is a LIABILITY the proponent must neutralise, not a credential it earns. This is the inversion, and it is the most important adverse finding in the track.**

The attribution cases do ask a whose-system question. It just runs the opposite way from the architecture's premise. They ask: **could the party now asserting the signature have produced it itself?** Where the answer is yes, attribution fails.

- ***Banister*** turned on precisely this. Attribution **failed** because the employer's own HR manager "**had the ability and motive to access [Bannister's] onboarding account**" (slip op. 7), the credentials "**w[ere] not employee-specific**", and she "**had access to the information necessary to access the onboarding portal via employee personnel records**" (slip op. 6). The holding: "**Because Bannister's evidence showed that she was not the only person who could have executed the arbitration agreement**" (slip op. 8).
- ***Garcia***'s trial court made the same point in one clause, and the Court of Appeal credited it: the declaration lacked detail on security precautions, "**noting that managers had access to arbitration agreements**" (slip op. 7).
- ***Aerotek*** won on the mirror image of those facts, and the court said so twice: the candidate's credentials were "**all unknown to Aerotek**", and "**Once a candidate submitted his application, Aerotek could not modify its contents**" (slip op. 11).

**Now transpose.** The configuration's runtime renders the approval surface, holds the member's trade-capable credentials in its vault, and mints the instruction record that is later offered as proof of what the member did. On its face that is a party with the practical ability to produce the very artifact it relies on — *Banister*'s losing posture, not *Aerotek*'s winning one. The architecture's answer must be *Aerotek*'s answer, and it must be demonstrable rather than asserted: that the deciding secret is one the runtime's operator **never holds**, and that the record, once minted, is one the operator **cannot modify**. The configuration already has the ingredients — credentials in the member's own local keychain per member, no company-level or app-level trading credential, an append-only journal, a mark bound to order and session nonce — but note what the case law actually requires of them. It is not enough that the operator does not in fact reach in. **It must be the case that it could not**, and someone must be able to explain how that is known (*Ruiz*, 232 Cal.App.4th at 843: "she did not explain how she arrived at that conclusion"; *Garcia*, slip op. 7: "he was not a percipient witness").

The design consequence is concrete and worth stating in one line: **the more the runtime's operator can prove it is locked out of its own surface and its own journal, the stronger the member's act becomes — and the value comes from the lock-out, not from the ownership.** A runtime-owned surface whose operator retains any capacity to mint or alter an instruction record is, on this line of cases, worse than no special surface at all.

**One qualification, and it is the only place located where the surface is legally salient at all.** Across everything searched, the identity of the process in which input is delivered mattered to exactly one kind of question — **who received a communication**, not whose act it was. Washington's own Privacy Act makes it "unlawful … to intercept, or record any … [p]rivate communication … without first obtaining the consent of **all the participants** in the communication" (RCW 9.73.030(1)(a), retrieved 7 Sep 2026 from `app.leg.wa.gov/RCW/default.aspx?cite=9.73.030`), and the statute's line runs between a **participant** in a communication and a stranger recording it. The configuration's decision to give the engine **no accessibility or screen-capture access** to the approval surface is the design choice that keeps the engine on the far side of that line — a stranger to the member's approval act rather than a silent recorder of it. **State this at its true weight: no located authority applies RCW 9.73 to a user's interaction with software on his own machine, and I found none searching for it.** It is recorded because it is the single located instance in which whose process receives the input is a legal fact — and because it is a fact about **receipt**, which is a different question from **authorship**, on which the surface remains irrelevant.

One genuine benefit does survive, and it should be stated precisely rather than overclaimed. Reg E comment 10(b)-5's "**A security code need not originate with the account-holding institution**", together with the "authorization process should evidence the consumer's identity and assent" standard, is the one located regulatory sentence that expressly contemplates an authentication mark supplied by the renderer rather than the actor — and blesses it, on a functional test the configuration's mark would meet. And 89 FR at 90905's "information sufficient to document" identifies what the record is worth to the party that acts on it. Those two together support the **record**, not the **window**.

---

## Negative findings

Each is a finding only because the endpoints and queries are recorded. Nothing below is inferred from silence.

**N1 · No authority located in which the identity of the rendering surface affected attribution.**
Endpoint: `https://www.courtlistener.com/api/rest/v4/search/?type=o&q=…` (CourtListener v4 full-text opinion search, no token). 30 queries in the first sweep plus 20 in the third; full list in the search log. The queries written specifically to catch surface-based attribution reasoning all returned zero:
| Query | COUNT |
|---|---|
| `"screen" "rendered by" signature attribution electronic agreement` | 0 |
| `"the interface" "displayed" attribution signature "who prepared"` | 0 |
| `"who owned the website" electronic assent attribution` | 0 |
| `"customer instruction" broker "order was entered by" attribution` | 0 |
| `"electronic signature" "was not the act of" attribution burden` | 0 |
| `"electronic signature" arbitration third-party vendor portal authentication employee` | 0 |
| `"electronic signature" "human resources portal" arbitration agreement authenticate` | 0 |
| `"electronic signature" "third party administrator" attribution benefits` | 0 |
| `"single sign-on" electronic signature arbitration authentication dispute` | 0 |
| `clickwrap "who clicked" assent attribution electronic` | 0 |
| `"device" "belonged to" "electronic signature" attribution dispute` | 0 |
| `"in whose interface" OR "whose website" electronic signature attribution` | 1, read and rejected as off-point (*In re TransCare*, incidental phrase match) |

**And confirmed on the merits, not merely by null queries:** seven attribution decisions were retrieved from official court sources and read in full (S6-16 to S6-22). None turned on whose system rendered the screen. The strongest single datum is *GoodLeap, LLC v. Garza*, where a third party's tablet was squarely before the court and the court **expressly declined** to reach the efficacy question (slip op. 13 n.3) rather than build a rule on it. *Aerotek* affirmatively **rejected** a requirement of testimony from the third-party developer and **rejected** the relevance of access "from anywhere" (slip op. 12, 14). *Garcia* treated a third party's platform as unremarkable and its markings as corroboration (slip op. 1, 15).

**N2 · No US federal regulatory instrument located on 3-D Secure, bank-hosted authorization widgets, or hosted payment fields as a matter of attribution.**
Endpoint: `https://www.federalregister.gov/api/v1/documents.json?conditions[term]=…`, all agencies, all years, retrieved 7 Sep 2026.
- `"3-D Secure"` — **COUNT 2**. Both retrieved and read in full: FR doc **2016-04654**, 81 FR 11270 (3 Mar 2016), and FR doc **2015-30016**, 80 FR 73760 (25 Nov 2015). Both are **Federal Reserve Board information-collection notices** for the Federal Reserve Payments Study surveys. In each, "3-D Secure" appears only as a **survey response category** — 2016: "the omission of the question to identify the volumes of ``3-D secure'' authentication, which is typically provided by the card networks"; 2015: internet purchases "would be further allocated into ``authenticated (two-factor authentication via 3-D Secure)'' and ``other'' categories." Neither allocates consent, authorization or liability by reference to who renders an authentication screen.
- `"hosted payment page"` — **COUNT 0**.
- `"payment service provider iframe"` — **COUNT 0**.
**Conclusion recorded as a finding:** the US answer to "whose consent is it when the bank renders the consent screen inside the third party's flow?" is not given by any located federal instrument. In the card context it is given by **private network operating regulations**, which are not public primary sources. The only located US federal instrument that allocates consent-screen rendering between an institution and a third party is **12 CFR Part 1033** (S6-07, S6-08), which is an open-banking data rule, not a payments-authentication rule.

**N3 · PCI SSC primary documents not retrievable — marked UNVERIFIED.**
- `https://listings.pcisecuritystandards.org/documents/SAQ_A_v4_x.pdf` → **HTTP 404** (637,333-byte generic HTML error page).
- `https://www.pcisecuritystandards.org/documents/SAQ_A_v4_x.pdf` → **HTTP 404**, same.
- `https://listings.pcisecuritystandards.org/documents/SAQ-A-v4-0.pdf` → **HTTP 404**, same.
- `https://www.pcisecuritystandards.org/document_library/` → **HTTP 200**, 664,643 bytes; parsed; it exposes only three direct PDF links, all on `docs-prv.pcisecuritystandards.org`, and no SAQ link.
- `https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf` → **HTTP 403** (78,161-byte denial page), with and without a `Referer: https://www.pcisecuritystandards.org/document_library/` header and an `Accept: application/pdf` header.
- Five candidate SAQ A paths under `docs-prv.pcisecuritystandards.org/PCI%20DSS/Supporting%20Document/` → **HTTP 403**, all returning the identical 78,161-byte denial page.
**Therefore: the SAQ A / SAQ A-EP eligibility criteria are NOT quoted in this register.** They sit behind a click-through licence acceptance that `curl` cannot pass. I have not reproduced them from any secondary source and no proposition in this deliverable rests on them. **This gap needs a browser route.** Note in any event that SAQ A is an **industry standard, not law**, so even if retrieved it would enter the register as ANALOGY at Level 1–2; N2 is the substantive answer to the vein-5 question.

**N4 · Opinion texts: the aggregator wall was real, and was then overcome via official court sources. Case-law entries are ◇ on pagination only.**
Every commercial route failed:
- `https://www.courtlistener.com/api/rest/v4/opinions/?cluster__id=<id>` → **HTTP 401 Unauthorized** (tested on clusters 4887612 and 9505064). The v4 *opinions* endpoint needs a token; the *search* endpoint does not.
- `https://www.courtlistener.com/api/rest/v3/search/?q=test&type=o` → **HTTP 403**.
- CourtListener opinion HTML → **HTTP 202 with a 0–2,006 byte body** carrying an **AWS WAF JavaScript challenge** (`window.awsWafCookieDomainList`; `challenge.js` on `token.awswaf.com`). Unchanged with a full browser header set.
- `law.justia.com` → **403** Cloudflare "Just a moment..."; `caselaw.findlaw.com` → **403**; `leagle.com` → **403**; `casetext.com` → **410 Gone**; `cite.case.law` → **404**; `casemine.com` → 200 but 14,669 chars of navigation only, judgment behind a login; `scholar.google.com` → 200, 135,525 bytes, bot interstitial with no `scholar_case` links; `search.txcourts.gov` direct → **403** (Microsoft-Azure-Application-Gateway); `www.txcourts.gov/media/...pdf` direct → **403**; `openjurist.org` → **403**.

**What worked, and should be recorded for every future track:**
- **`https://www.courts.ca.gov/opinions/archive/<DOCKET>.PDF`** — official California slip opinions, **not blocked**, direct `curl`. Retrieved *Garcia* (A166785), *Ruiz* (E057529), *Espejo* (B262717), *Banister* (A159815), *Fabian* (D075519). Note `/opinions/documents/` holds only recent opinions and 404s for older ones.
- **`https://r.jina.ai/<blocked-url>`** — a reader proxy that defeats the Azure gateway on `txcourts.gov`, Cloudflare on Justia/FindLaw, and the AWS WAF on CourtListener, returning text with PDF pagination preserved. Retrieved the official *Aerotek* majority (`txcourts.gov/media/1452283/200290.pdf`) and dissent (`/1452284/200290d.pdf`), the official *Garza* and *Meraz* opinion media from `search.txcourts.gov`, and *Banister* from CourtListener.
- **`https://static.case.law/`** — Harvard Caselaw Access Project, open, no key; `…/cal-app-4th/232/html/0836-01.html` gives **reporter-paginated** text with `<a id="pNNN">` anchors. Coverage ends ~mid-2018, so it served *Ruiz* and *Espejo* only. Minor OCR artifacts; every quote taken from it was verified against the official slip PDF.

**Verification I performed personally** on 7 Sep 2026, independent of the research agent: re-fetched the official *Aerotek* PDF and string-matched five load-bearing quotes; re-fetched the official *Garza* opinion media and matched four; re-fetched the official *Garcia* PDF (`courts.ca.gov`) and matched four. **All thirteen probes matched.**

**Residual limitation, and the only reason these entries carry ◇:** pin-cites for *Aerotek*, *Garcia*, *Banister*, *Fabian*, *Meraz*, *Garza* and *Ambit* are **slip-opinion pages, not reporter pages**. *Ruiz* and *Espejo* carry true Cal.App.4th pagination. Where a S.W.3d page is given for *Aerotek* it is because a later Texas court supplied it for that sentence, and the register says which. **No pin-cite in this deliverable is invented.**

**One tool caution:** a generic web-fetch tool returned HTTP 200 for FindLaw but **refused to output the opinion text on copyright grounds**. Opinion text must be pulled with `curl` and read directly, not through a summarising fetcher.

**N5 · CourtListener rate limits, and their effect on this track.**
The unauthenticated v4 search API enforces **5 requests/minute and 50 requests/hour**. The first sweep (30 queries) exhausted the hourly budget; `https://www.courtlistener.com/api/rest/v4/search/?type=o&q=…` then returned `{"detail":"Request was throttled. Rate limit exceeded: 50/hour. Expected available in 2443 seconds."}` (HTTP 429). The third sweep was rescheduled past the reset rather than abandoned. Any future track using CourtListener heavily should obtain a token.

**N6 · No securities-side analogue to Reg E comment 10(b)-2 located.**
No SEC release, staff letter, FINRA rule or FINRA notice was located that places responsibility on the party that **obtained** a customer's authorization where that party is not the broker. The securities sources allocate responsibility to the acting broker (Rel. 33-7856 n.25), to the MPID holder (Rule 15c3-5(b); 75 FR at 69794), or to the member (NTM 98-66 ¶¶ 1, 4; NTM 05-48). Endpoints searched: `finra.org/rules-guidance/notices/<number>` for 98-66, 99-11, 99-12, 01-23, 05-48, 15-09 (all HTTP 200 and parsed) and 11-54, 16-21 (**HTTP 429**, not retrieved — recorded as a gap, not as an absence); Federal Register full texts of 65 FR 25843, 75 FR 69792. **This is a gap in the register, not a safe harbour:** the absence of a securities analogue to comment 10(b)-2 means the adverse question is unanswered in the regime that matters, not answered favourably.

**N7 · FINRA notices 11-54 and 16-21 not retrieved.**
`https://www.finra.org/rules-guidance/notices/11-54` and `/16-21` → **HTTP 429**, 5,616-byte throttle page, after six successful sequential fetches from the same host. Not retried within this track. Marked as an open gap.

---

## Search log

| # | Source / query | Endpoint | Date | Result / access note |
|---|---|---|---|---|
| 1 | `"security procedure" "electronic signature" attribution` | CourtListener v4 search, type=o | 7 Sep 2026 | COUNT 27. Top: Banister v. Marinidence Opco (Cal. Ct. App. 2021); Garcia v. Stoneledge Furniture (Cal. Ct. App. 2024); **Aerotek, Inc. v. Boyd (Tex. 2021)**; Solcius/GoodLeap v. Meraz (Tex. App. 2023) |
| 2 | `Stoneledge Furniture electronic signature arbitration` | same | 7 Sep 2026 | COUNT 3 — Garcia v. Stoneledge; Ramirez v. Golden Queen Mining; Brockman v. Kaiser Foundation Hospitals (Cal. Ct. App. 2025) |
| 3 | `"electronic signature" arbitration "unique login" password authenticate` | same | 7 Sep 2026 | COUNT 4 — Banister; **Ruiz v. Moss Bros. Auto Group** (2014); **Espejo v. So. Cal. Permanente Medical Group** (2016); Kmart Stores of Texas v. Ramirez (2016) |
| 4 | `"electronic signature" arbitration third-party vendor portal authentication employee` | same | 7 Sep 2026 | **COUNT 0** |
| 5 | `"unauthorized electronic fund transfer" "Regulation E" "1005.2(m)"` | same | 7 Sep 2026 | **COUNT 0** |
| 6 | `Zelle "Regulation E" unauthorized transfer` | same | 7 Sep 2026 | COUNT 1 — IMG Holding LLC v. Dimon (Del. Ch. 2024), not on point |
| 7 | `"Regulation E" "electronic fund transfer" "third party" application authorization consumer credentials` | same | 7 Sep 2026 | COUNT 1 — Shames-Yeakel v. Citizens Financial Bank (N.D. Ill. 2009) |
| 8 | `clickwrap "who clicked" assent attribution electronic` | same | 7 Sep 2026 | **COUNT 0** |
| 9 | `"Uniform Electronic Transactions Act" attribution "act of the person"` | same | 7 Sep 2026 | COUNT 21 — incl. Aerotek; Ambit Marketing v. TLC Energy (Tex. App. 2024); Bronson Health Care v. Esurance (Mich. Ct. App. 2023) |
| 10 | `"E-SIGN" "efficacy of any security procedure"` | same | 7 Sep 2026 | COUNT 1 — **GoodLeap, LLC v. Garza** (Tex. App. 13th Dist. 2025) |
| 11 | `"sponsored access" "market access" "Rule 15c3-5"` | same | 7 Sep 2026 | **COUNT 0** |
| 12 | `"order entry system" broker-dealer customer entered order attribution` | same | 7 Sep 2026 | COUNT 4 — eSpeed v. BrokerTec; In re NYSE Specialists; Papyrus Technology v. NYSE. All patent/antitrust, none on attribution |
| 13 | `"3-D Secure" cardholder authentication liability shift` | same | 7 Sep 2026 | **COUNT 0** |
| 14 | `"hosted payment page" iframe merchant cardholder data` | same | 7 Sep 2026 | **COUNT 0** |
| 15 | `"electronic signature" "was not the act of" attribution burden` | same | 7 Sep 2026 | **COUNT 0** |
| 16 | `DocuSign electronic signature attribution dispute authenticate` | same | 7 Sep 2026 | COUNT 10 — **Fabian v. Renovate America** (Cal. Ct. App. 2019); Solcius/GoodLeap v. Meraz; Ruiz; J.B.B. Investment Partners v. Fair; GoodLeap v. Garza |
| 17 | `"electronic signature" "human resources portal" arbitration agreement authenticate` | same | 7 Sep 2026 | **COUNT 0** |
| 18 | `"Regulation E" "payment app" unauthorized "fraud induced"` | same | 7 Sep 2026 | **COUNT 0** |
| 19 | `"Venmo" OR "Cash App" "Regulation E" unauthorized transfer` | same | 7 Sep 2026 | Request errored (throttle); not re-run |
| 20 | `"open banking" "1033" "authorized third party" consumer data` | same | 7 Sep 2026 | **COUNT 0** |
| 21 | `"the interface" "displayed" attribution signature "who prepared"` | same | 7 Sep 2026 | **COUNT 0** |
| 22 | `"electronic record" attribution "in any manner" "including a showing of the efficacy"` | same | 7 Sep 2026 | COUNT 23 — incl. Aerotek; Ambit Marketing; Bronson; Cooper-Dorsey v. Time Warner Cable |
| 23 | `"screen" "rendered by" signature attribution electronic agreement` | same | 7 Sep 2026 | **COUNT 0** |
| 24 | `"customer instruction" broker "order was entered by" attribution` | same | 7 Sep 2026 | **COUNT 0** |
| 25 | `"single sign-on" electronic signature arbitration authentication dispute` | same | 7 Sep 2026 | **COUNT 0** |
| 26 | `"electronic signature" "third party administrator" attribution benefits` | same | 7 Sep 2026 | **COUNT 0** |
| 27 | `"who owned the website" electronic assent attribution` | same | 7 Sep 2026 | **COUNT 0** |
| 28–30 | `"pin" … "act of the person" electronic transfer`; `"Article 4A" "security procedure" … "deemed to be the order of the customer"`; `"deemed the order of the customer" "commercially reasonable"` | same | 7 Sep 2026 | Not reached before the hourly cap; superseded by direct statutory retrieval of RCW 62A.4A-201/-202/-203 |
| 31 | eCFR Part 1005 (Reg E) full XML | `ecfr.gov/api/versioner/v1/full/2026-09-03/title-12.xml?part=1005` | 7 Sep 2026 | HTTP 200, 859,423 bytes. **Note:** this endpoint **requires** `Accept-Encoding` permitting compression (`curl --compressed`); without it, `{"error":"…requires response compression"}`. Latest valid issue date for title 12 was **2026-09-03**; 2026-09-05 was rejected with the valid date named in the error |
| 32 | eCFR Part 1033 (PFDR) full XML | same, `part=1033` | 7 Sep 2026 | HTTP 200, 71,419 bytes — **Part 1033 is in force as at the 3 Sep 2026 issue date**; §§ 1033.401, .411, .421, .431, .441 retrieved |
| 33 | eCFR Part 1026 (Reg Z) full XML | same, `part=1026` | 7 Sep 2026 | HTTP 200, 3,946,980 bytes; § 1026.12(b)(1) n.22 "unauthorized use" retrieved |
| 34 | eCFR Rule 15c3-5 text | `ecfr.gov/api/versioner/v1/full/2026-09-03/title-17.xml?part=240&section=240.15c3-5` | 7 Sep 2026 | HTTP 200, 7,204 bytes; §§ (a)–(d) retrieved |
| 35 | Federal Register: CFPB + term `1033`, newest first, 40 per page | `federalregister.gov/api/v1/documents.json` | 7 Sep 2026 | **COUNT 25.** Final rule 2024-25079 (18 Nov 2024); ANPRM 2025-16139 (22 Aug 2025); Regulatory Agenda 2026-16613 (14 Aug 2026). **No stay, delay, amendment or vacatur document in the results** |
| 36 | FR doc 2025-16139 metadata + full text | `/api/v1/documents/2025-16139.json`; `/documents/full_text/text/2025/08/22/2025-16139.txt` | 7 Sep 2026 | HTTP 200. "Advance notice of proposed rulemaking"; 90 FR 40986; comments closed 21 Oct 2025; § III Questions 1–8 on "representative" retrieved |
| 37 | FR doc 2024-25079 full text (PFDR final rule) | `/documents/full_text/text/2024/11/18/2024-25079.txt` | 7 Sep 2026 | HTTP 200, 1,265,122 bytes; 89 FR 90904–05 passages retrieved |
| 38 | Rel. 33-7856 on sec.gov | `sec.gov/rules/interp/34-42728.htm` | 7 Sep 2026 | HTTP 200, 57,943 bytes — but the page is now a **metadata stub**; after tag-stripping only 3,278 characters, all navigation. **No substantive release text on sec.gov.** `…/34-42728.txt` → HTTP 404 |
| 39 | Rel. 33-7856 via Federal Register | `/api/v1/documents.json?term="Use of Electronic Media"&agency=SEC&date 2000-04-01..2000-06-30` then `/documents/full_text/text/2000/05/04/00-11079.txt` | 7 Sep 2026 | COUNT 3; full text retrieved, 123,199 bytes. n.25 at 65 FR 25846; Section E Examples 1–2 at 65 FR 25855 |
| 40 | Rule 15c3-5 adopting release | `/api/v1/documents.json?term="Risk Management Controls"&agency=SEC&2010-11..2010-12` then `/documents/full_text/text/2010/11/15/2010-28303.txt` | 7 Sep 2026 | COUNT 2; full text retrieved, 299,144 bytes (HTML-wrapped; tags stripped to 298,417 chars). Sponsored-access passage at 75 FR 69793–94; "direct and exclusive control" at 69810–11 |
| 41 | FR term `"3-D Secure"`, all agencies/years | `/api/v1/documents.json` | 7 Sep 2026 | **COUNT 2** — both Federal Reserve information-collection notices; both retrieved in full and read; 3-D Secure appears only as a survey category. See N2 |
| 42 | FR term `"hosted payment page"` | same | 7 Sep 2026 | **COUNT 0** |
| 43 | FR term `"payment service provider iframe"` | same | 7 Sep 2026 | **COUNT 0** |
| 44 | CFPB EFT FAQs | `consumerfinance.gov/compliance/compliance-resources/deposit-accounts-resources/electronic-fund-transfers/electronic-fund-transfers-faqs/` | 7 Sep 2026 | HTTP 200, 196,631 bytes. Live; per-item stamps "Updated June 4, 2021" / "Updated December 13, 2021"; **no later revision date on any item read** |
| 45 | CFPB Circulars index | `consumerfinance.gov/compliance/circulars/` | 7 Sep 2026 | HTTP 200, 163,472 bytes; retrieved but **not parsed for Reg E circulars within this track** — recorded as an unworked lead |
| 46 | RCW 62A.4A-201, -202, -203 | `app.leg.wa.gov/RCW/default.aspx?cite=62A.4A-20x` | 7 Sep 2026 | HTTP 200 (≈109 KB each); full statutory text retrieved; 2023 c 266 §§ 502–504 amendments noted |
| 47 | FINRA NTM 98-66, 99-11, 99-12, 01-23, 05-48, 15-09 | `finra.org/rules-guidance/notices/<n>` | 7 Sep 2026 | HTTP 200 each (99–124 KB); parsed. **NTM 98-66 is the key hit** |
| 48 | FINRA RN 11-54, 16-21 | same | 7 Sep 2026 | **HTTP 429** (5,616-byte throttle page) after six sequential fetches. Not retrieved — see N7 |
| 49 | PCI SSC SAQ A, five candidate paths + document library + PCI DSS v4.0.1 | `listings.pcisecuritystandards.org`, `www.pcisecuritystandards.org`, `docs-prv.pcisecuritystandards.org` | 7 Sep 2026 | HTTP 404 / 403 throughout. See N3 |
| 50 | CourtListener opinions API | `/api/rest/v4/opinions/?cluster__id=4887612` and `=9505064` | 7 Sep 2026 | **HTTP 401 Unauthorized** — token required |
| 51 | CourtListener opinion HTML | `/opinion/4887612/aerotek-…/` | 7 Sep 2026 | **HTTP 202**, 0–2,006 bytes, **AWS WAF JS challenge**. Retried with full browser headers — unchanged |
| 52 | Justia / FindLaw / Leagle / Casetext / cite.case.law / Casemine / Google Scholar / search.txcourts.gov | various | 7 Sep 2026 | 403 / 403 / 403 / 410 / 404 / login-gated / bot interstitial / 403. See N4 |
| 72 | Second CourtListener sweep, 20 queries, run 12:51–12:56 CEST after the hourly cap reset | CourtListener v4 search, type=o | 7 Sep 2026 | Counts below. Six queries returned `None` (throttle errors after retries) and are reported as **unknown, not zero**: `"party to the communication" wiretap third-party code embedded website`; `"4A-202" "effective as the order of the customer" security procedure`; `"who entered the order" broker-dealer discretion customer`; `"the act of the person" "may be shown in any manner" electronic record`; `"initiated by a person other than the consumer" "without actual authority"`; `"investment discretion" software "customer authorized" each order broker` |
| 72a | `"device" "belonged to" "electronic signature" attribution dispute` | same | 7 Sep 2026 | **COUNT 0** — a further documented null on device-based attribution |
| 72b | `caseName:"Stoneledge" "electronic signature" attribution "unique login"` | same | 7 Sep 2026 | **COUNT 0** (the phrase "unique login" does not appear in *Garcia*; the opinion says "unique user ID and confidential password") |
| 72c | `caseName:"GoodLeap" "electronic signature" attribution security procedure` / `caseName:"Solcius" "electronic signature" tablet representative` | same | 7 Sep 2026 | **COUNT 0** each — consistent with S6-21: *Garza* expressly reserved the efficacy question, and neither opinion analyses the tablet for attribution |
| 72d | `"in whose interface" OR "whose website" electronic signature attribution` | same | 7 Sep 2026 | **COUNT 1** — *LaMonica v. Tilton (In re TransCare Corp.)*, Bankr. S.D.N.Y. 2018. **Read and rejected as off-point:** a fraudulent-transfer adversary proceeding; the phrase match is incidental and the opinion contains no surface-attribution analysis |
| 72e | `"electronic signature" "on behalf of" another person attribution arbitration denied` | same | 7 Sep 2026 | COUNT 25 — the general arbitration-attribution corpus; the leading members of it are already in S6-16 to S6-22 |
| 72f | `brokerage account unauthorized online trades password customer attribution` | same | 7 Sep 2026 | COUNT 14 — reviewed; no decision located turning on whose system rendered a trading screen |
| 72g | `caseName:"Aerotek" …`, `caseName:"Espejo" …`, `caseName:"Ruiz" "Moss Bros" …`, `caseName:"Banister" …` | same | 7 Sep 2026 | COUNT 1–3 each; used only to confirm the phrases appear in the indexed opinions. **The quotes in this register come from the official court PDFs, not from these snippets** |
| 63 | *Aerotek v. Boyd* majority + dissent, official | `txcourts.gov/media/1452283/200290.pdf` and `/1452284/200290d.pdf`, via `r.jina.ai` | 7 Sep 2026 | Direct fetch **403** (Azure gateway); via reader proxy **200**, 39,205 B and 17,652 B. **I re-fetched and string-verified five load-bearing quotes myself — all matched** |
| 64 | *Garcia v. Stoneledge*, official CA slip op. | `courts.ca.gov/opinions/archive/A166785.PDF` | 7 Sep 2026 | **200, application/pdf**, direct — not blocked. **Four quotes string-verified by me** |
| 65 | *Ruiz* (E057529), *Espejo* (B262717), *Banister* (A159815), *Fabian* (D075519), official CA slip ops. | `courts.ca.gov/opinions/archive/<DOCKET>.PDF` | 7 Sep 2026 | **200** each. `/opinions/documents/` 404s for older opinions; `/opinions/archive/` is the working pattern |
| 66 | *GoodLeap v. Garza*, official opinion media | `search.txcourts.gov/SearchMedia.aspx?MediaVersionID=323c2945-…&coa=coa13`, via `r.jina.ai` | 7 Sep 2026 | Direct **403**; via proxy **200**, 14 pp. **Four quotes string-verified by me**, incl. slip op. 13 n.3 |
| 67 | *Solcius/GoodLeap v. Meraz*, official opinion media | `search.txcourts.gov/…coa=coa08`, via `r.jina.ai` / Justia PDF mirror | 7 Sep 2026 | Direct **403**; retrieved via proxy, 19 pp. ◇ not independently diffed — see ◇ list |
| 68 | *Ambit Marketing v. TLC Energy*, official slip PDF | `search.txcourts.gov` / Justia mirror, via `r.jina.ai` | 7 Sep 2026 | Retrieved, 22 pp. Docket is 05-**24**-00009-CV; **pet. denied** 5 Sep 2025, mandate 16 Oct 2025 |
| 69 | Harvard Caselaw Access Project | `static.case.law/cal-app-4th/232/html/0836-01.html`; `…/CasesMetadata.json` | 7 Sep 2026 | **200**, open, no key. Reporter-paginated text with `<a id="pNNN">` anchors. Supplied true Cal.App.4th pagination for *Ruiz* and *Espejo*. **Coverage ends ~mid-2018** |
| 70 | Commercial case aggregators | justia / findlaw / leagle / casetext / casemine / cite.case.law / Google Scholar / openjurist | 7 Sep 2026 | 403 / 403 / 403 / 410 / login-gated / 404 / bot interstitial / 403. See revised N4 |
| 71 | Docket corrections found while verifying | — | 7 Sep 2026 | *Banister* is **A159815**; *Fabian* is **D075519** (D074449 → 404); *Ambit* is **05-24-00009-CV**, "pet. denied" not "no pet." |
| 61 | RCW 9.73.030 (Washington Privacy Act) | `app.leg.wa.gov/RCW/default.aspx?cite=9.73.030` | 7 Sep 2026 | HTTP 200, 111,697 bytes; § (1)–(4) retrieved. Cited once, heavily qualified, in Direct answer C. **No authority located applying RCW 9.73 to a user's interaction with software on his own machine** |
| 62 | 18 U.S.C. § 2510 (Wiretap Act definitions) | `uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title18-section2510` | 7 Sep 2026 | **Connection failed, HTTP 000, 0 bytes.** Not retrieved; no proposition in this deliverable rests on it |
| 60 | FINRA Rules 5310, 3110, 4512, 2010 | `finra.org/rules-guidance/rulebooks/finra-rules/<n>` | 7 Sep 2026 | HTTP 200 each (101–151 KB). Rule 5310 Supp. Mat. .08 and .09(a) and Rule 3110(f)(2)(A)(ii)(g) retrieved; see S6-15. **Rule 3110(f)(2)(A)(ii)(g) is the only located rule text conditioning anything on whose electronic system is used, and it is a branch-office rule, not an attribution rule** |
| 58 | SEC Rule 15c3-5 FAQs | `sec.gov/divisions/marketreg/faq-15c-5-risk-management-controls-bd.htm` | 7 Sep 2026 | HTTP 200, 107,139 bytes; parsed to 38,147 chars. Questions 3, 5, 14, 19 read. **Null result on attribution:** the FAQs address risk-control technology and due diligence only, and restate the Adopting Release's "independent of the customer" test. **Nothing on whose order it is when a third party's system produces the entry.** (The newer staff-guidance URL for the same FAQs returned HTTP 404) |
| 59 | Reg E § 1005.14 | eCFR title 12 part 1005 (row 31) | 7 Sep 2026 | Retrieved; see S6-14. Trigger for a non-account-holding EFT service provider is access-device issuance + absence of an agreement with the account-holding institution |
| 54 | FR: `"books and records" "brokers and dealers"`, SEC, Oct–Dec 2001 | `/api/v1/documents.json` then `/documents/full_text/text/2001/11/02/01-27439.txt` | 7 Sep 2026 | COUNT 3; **66 FR 55818** retrieved in full, 199,662 bytes. § 17a-3(a)(6)(i)/(a)(7) rule text at 66 FR 55838; Commission explanation at 55819 |
| 55 | FR: `"Consumer Financial Protection Circular"`, CFPB, newest first, 60/page | `/api/v1/documents.json` | 7 Sep 2026 | **COUNT 36.** Circulars 2022-01 … 2024-07 enumerated. **No CFPB circular on Regulation E, unauthorized transfers or P2P payments exists** — recorded as a negative |
| 56 | FR: `"Interpretive Rules, Policy Statements, and Advisory Opinions; Withdrawal"` | `/api/v1/documents.json` then both raw texts | 7 Sep 2026 | **COUNT 2.** FR doc **2025-08286**, 90 FR 20084 (12 May 2025) — withdraws "all guidance documents", incl. **every Circular 2022-01 through 2024-06**; zero occurrences of "FAQ"/"frequently asked"/"compliance aid"; one Reg E hit, a **Subpart B remittance** bulletin. FR doc **2025-19671**, 90 FR 48710 (28 Oct 2025) — an **FCRA preemption** interpretive rule, zero Reg E/1005 mentions |
| 57 | CFPB circulars index | `consumerfinance.gov/compliance/circulars/` | 7 Sep 2026 | HTTP 200, 163,472 bytes, but **JS-rendered**: only one circular link present in the static HTML. Superseded by row 55 |
| 53 | CourtListener throttle probe | `/api/rest/v4/search/?type=o&q=caseName:"Aerotek" "security procedure"` | 7 Sep 2026 | **HTTP 429** — `Rate limit exceeded: 50/hour. Expected available in 2443 seconds` |

---

## ◇ list — resting on secondary confirmation only, or otherwise needing primary verification

| # | Item | What is solid | What needs verifying |
|---|---|---|---|
| ◇1 | **Pin-cites for *Aerotek*, *Garcia*, *Banister*, *Fabian*, *Meraz*, *Garza*, *Ambit*** | The **text** of every quoted passage is from an official court PDF, and thirteen load-bearing quotes across *Aerotek*, *Garza* and *Garcia* were re-fetched and string-verified by me on 7 Sep 2026. | The **page numbers are slip-opinion pages, not reporter pages.** Anyone citing these in a filing must convert to S.W.3d / Cal.App.5th pagination. Where a 624 S.W.3d page is given for *Aerotek*, it was supplied by a later Texas court for that sentence and the register says which. *Ruiz* and *Espejo* alone carry true reporter pagination (Harvard CAP). |
| ◇2 | ***Meraz* and *Ambit* text** | Retrieved from PDFs described as the official slip opinions. | *Garza* was confirmed byte-identical between the official `search.txcourts.gov` media and the Justia PDF mirror; **that diff was not run for *Meraz* and *Ambit***. A single-sample match is evidence, not proof, that Justia's Texas mirrors are faithful. Re-verify against `search.txcourts.gov` before relying on exact wording. |
| ◇3 | **PCI DSS SAQ A / SAQ A-EP eligibility criteria** | Nothing. **Not quoted anywhere in this deliverable and no proposition rests on them.** | Gated behind a click-through licence; nine URLs returned 404/403 (N3). Needs a browser route. Note it is an **industry standard, not law**, so it would enter at Level 1–2 as ANALOGY even if retrieved. |
| ◇4 | **FINRA Regulatory Notices 11-54 and 16-21** | Nothing rests on them. | **HTTP 429** after six sequential fetches from `finra.org` (N7). Not retrieved; recorded as an open gap, **not** as an absence. |
| ◇5 | **Part 1033 litigation status** (*Forcht Bank / Bank Policy Institute v. CFPB*, E.D. Ky.) | Part 1033 **is in force** in the eCFR at the 3 Sep 2026 issue date, and the Federal Register API shows **no** stay, delay, amendment or vacatur document (S6-07, search-log row 35). | The **court docket itself was not reached** in this track. A litigation-imposed stay that never produced a Federal Register document would not show in my method. Verify on PACER/CourtListener RECAP before relying on "in force". |
| ◇6 | **CourtListener sweep queries 28–30** | The three statutory propositions they targeted were obtained directly from RCW 62A.4A-201/-202/-203 instead. | The queries themselves were never run — the hourly cap hit first (N5). Their COUNTs are unknown, and the search log says so rather than reporting a zero. |
| ◇7 | **Query 19** (`"Venmo" OR "Cash App" "Regulation E" unauthorized transfer`) | — | Errored on throttle and was not re-run. COUNT unknown. Not reported as zero. |
| ◇8 | **RCW 9.73.030 as applied to a user's interaction with local software** | The statutory text is quoted verbatim from `app.leg.wa.gov`. | **No authority applies it to this situation and I located none.** It is offered in answer C explicitly as the single instance where the surface is legally salient *for receipt*, and expressly not as authority on authorship. Do not upgrade it. |
| ◇9 | ***Kerr v. Dillard Store Services***, No. 07-2604-KHV (D. Kan.) | Doc. #116 (17 Aug. 2009), the Rule 52(b) order, was retrieved from `govinfo.gov` and quotes the operative findings: supervisors "could log in to an associate's account … by resetting the associate's confidential password". | The **operative order, Doc. #103 (17 Feb. 2009), was not read.** Offered as a lead only. It reinforces the A12 inversion — the analysis is password security and who else could reach the account — but read Doc. #103 before citing it. |
| ◇10 | **The "Aerotek dissent delivered 28 June 2021" date** | The majority was delivered **28 May 2021**. | The dissent PDF bears "Opinion delivered: June 28, 2021", which may be a typographical artifact in the court's own file. Immaterial to every proposition here, but do not repeat the June date without checking. |

---

## Note to the coordinator

Three things this track leaves for others.

1. **A12 is the finding to escalate.** The brief asked whether the runtime-owned surface could make the operator *more* involved. The answer from the regulatory side is "it gives it duties" (A1, A2). The answer from the **case law** is sharper and was not anticipated: *Banister* and *Garcia* show that **the party which controls the rendering system must affirmatively prove it could not have produced the mark itself**, and *Aerotek* won precisely because the credentials were "all unknown to" the proponent and the record was one it "could not modify". This is a design requirement, not just a litigation risk, and it belongs in front of whoever owns the architecture.
2. **The designation gap** (A9 + A13, from Article 4A and *Ambit* independently): the member has designated the runtime's surface as his instruction channel, but **the broker has not**. Whether that matters is unresolved by anything located, and it is the cleanest question to put to a broker's own terms — which is Track 2/Q3 territory.
3. **Access routes worth propagating** (revised N4): `courts.ca.gov/opinions/archive/<DOCKET>.PDF` is unblocked; `r.jina.ai` defeats the Azure/Cloudflare/AWS-WAF walls on `txcourts.gov`, Justia and CourtListener; `static.case.law` is open for pre-2018 reporter pagination; and CourtListener's unauthenticated search API is capped at **5/min and 50/hour** — any track leaning on it should obtain a token.


---

*Register entries only. No legal conclusions and no advice are offered above; "supports" and "undercuts", and the ADVERSE / SUPPORT / NEUTRAL marks, denote the direction of the evidentiary weight in the material located, and nothing more. Frozen on delivery, 7 September 2026.*