Shared under NDA. This document may be passed on only with the author's consent. And only under an NDA of equal scope.
The law came first. The architecture was built on top of it. Eight research rounds since July, a formal opinion from securities counsel in June, and the integrations that were built, run and revised along the way led to the RAPID target architecture. Nothing was frozen before the law was read. Every constraint in this document is a legal finding turned into a boundary, a default or a missing feature.
The two registers behind this page, P7 and P8, run to about 380,000 words, roughly 850 pages. Between them they cite on the order of 150 to 200 court decisions and regulatory actions, 80 to 100 SEC releases, interpretations and staff letters, six brokers' own account and API contracts read in full, and sixteen comparable products traced through the SEC, Washington State, the CFTC and the private courts. A core of thirty to forty authorities carries the position. Every source is primary, quoted verbatim and linked. It is the scope of a full due diligence, and it was done before anything was built on it.
Advisers: anyone paid to tell people what to buy. Brokers: anyone who is the link that sends other people's orders. Our answer to the first: the engine never says buy or sell. It says which of the member's own rules was met, and the member wrote every rule and every number himself. Our answer to the second: nothing we control can authorize or transmit an order. The key exists only on a machine the member controls, every order is the member's own instruction, nobody holds authority over his account, and the member is his broker's customer, not ours.
Each position rests on something a regulator or a broker has already credited. Locally installed, user-programmed order software, cleared by SEC staff in 2005. Keys held only by the user, upheld by a court. A customer-requested, customer-defined alert is not a recommendation without more, a search tool may rank securities by criteria the customer selected, and the Commission has treated an investor-configured alert on his own watch list as outside recommendations. Six brokers' own contracts treat an order under the member's key as the member's own. The one similar company that lost took a fee per trade and recruited customers for its own service. We do neither.
Nobody has judged this combination as a whole. Each part has support; the sum has not. No authority distinguishes a rule the member wrote from a rule he adopted, and where the key lives is not the legal test for being a broker. Those are our strongest distinguishing facts, not settled law. That is why most cards sit at 3, not 2. A no-action request to the SEC, once the product is frozen and running, is the strongest available route to fact-specific comfort. It is not a legal conclusion.
No fee tied to trades or results. A working kill switch, the one feature the authorities have credited for founders personally. A language list enforced in the code. The weak points are not architecture but discipline: no presets, software not service, Steve introduces the room and never the product, and how we talk about it: as a tool the member runs, not a service that trades for him.
Regulators look at whether a company recruits customers for a service that ends in trades. Our product does end in a trade, so this cannot be designed away. What we can do is sell software, not a service, and say plainly that the member is his broker's customer, not ours.
We sell software the member runs. We never call it a service. We sell only on our own website, never inside the community; in the community we talk about how to use it, not about buying it. Steve introduces the room, never the product. And everywhere the member meets us, in marketing, in onboarding and in the terms, one sentence stays the same: you are a customer of your broker, not of us.
Being a broker has several ingredients, and the SEC weighs them together. One of them is solicitation: do you go out and find people for something that ends in trades? We do. That ingredient cannot be removed by any design, because the product exists to place orders.
The one company closest to us that lost, Neovest, tried the same posture we rely on, calling itself an independent software provider, and the Commission said that branding was consistent with solicitation, not a defence against it (Neovest, 2021, para. 14). Wording does not cure it.
The only cure the research located is the 1996 Schwab letter, where the SEC staff accepted an intermediary on the condition that the customer was the broker's customer, not the intermediary's. That sentence is ours too, and it helps. But Schwab's intermediary only routed messages, and it had a written three-party agreement with the broker. RAPID composes the order, and we have no agreement with any broker. So Schwab is a supporting fact, not a cure.
Nothing in P8 moved this card in either direction. That raises its priority for counsel rather than lowering it.
Neovest, Rel. 34-92285 (2021) para. 14; Schwab no-action letter (1996), condition 1 and its three-party agreement; Rel. 34-90112 (solicitation factor)
One monthly fee for everything looks, to a regulator, like a fee for advice. We say what the fee buys. But we cannot make the fee disappear, and when a member stops paying, the signals stop.
The agreement says what the fee is for: software, infrastructure and support. Nothing per trade, nothing per dollar under management, nothing tied to results. Nobody else pays us, not brokers, not fund issuers. In plan mode the engine is licensed software on the member's own machine, and the fee buys the licence, the updates and the support, never signals.
To be an investment adviser you need three things: advice about securities, a business of giving it, and compensation. This card is only about the third. Under the SEC's 1987 interpretation, compensation means any economic benefit; one bundled fee is enough, and you do not need a separate charge labelled "advice" (IA-1092). Every case we found agrees.
So the honest position is this: we have not removed the compensation element from the product. We have described the fee truthfully. And the design itself shows the link a regulator would draw: the runtime is free, and when membership lapses the hosted engine stops delivering. Asked what the subscriber pays to keep receiving, the answer in per-order mode is the signals.
That is why this is a 4 rather than a 3. But it is a conditional 4. Compensation only matters if there is advice. If card 03 holds, if the signal is not advice, this card never bites. If card 03 falls, this one is conceded. It has no life of its own.
IA-1092 (1987) at 10 ('any economic benefit'; bundled fee suffices); Weiss; Park (Tokyo Joe); IA-2376 ('special compensation' = other than commissions)
If we are paid to tell people what to buy or sell, we are an investment adviser and must register. Our answer: we never tell anyone to buy or sell. The engine says that a rule the member wrote was met on a security he chose to watch. What that rule means is his own setting. Nobody in the chain recommends anything.
The member writes every rule and every number himself, in empty fields, and asks to be told when a rule is met. The engine reports only that: which rule, which security, when. It never says buy or sell; that meaning lives in the member's own settings. There are no presets, no rankings, no "best", no "suitable", nothing about the member himself. The list is shown in the order he chose, with nothing highlighted. And nothing we control decides which security qualifies, when a rule fires, or how the list is sorted; every one of those inputs traces back to a setting the member typed or a list he chose to load.
Start with what a recommendation is. The regulators have said it for twenty years: what matters is content, context and presentation, and above all whether the message is tailored to a specific person. A template naming three to five securities for one customer was a recommendation because it was individually tailored (David Lerner, 2026). A general market letter is not. Our signal is the opposite of tailored: we hold nothing about the member and use nothing about him. That is the axis with the strongest support.
Then the closest thing the Commission has said about our shape. In 2023 the SEC described an alert the investor signs up for, configures himself, and keys to securities on his own watch list as "generally outside the scope of recommendations" (88 FR 53975, citing NASD 01-23 twice). It then proposed a rule to reach such alerts anyway, and withdrew that rule in June 2025. Read together: the Commission thought it needed a new rule to catch this, and then decided not to. That is as close to Commission-level support as a product like ours will get.
Now the two facts we have always leaned on, and why they cannot carry the argument alone. The member wrote the rule, and the member asked to be told. Both are true. But no statute, rule or decision anywhere distinguishes a rule the customer wrote from one he adopted, and the defence "the customer configured it himself" has never won on adviser status (Rome v. Mandel). In one case the customer confirmed every single trade, and it counted for nothing (Donelson). So authorship and request are distinguishing facts. They are not settled law, and they should not be asked to do the work that absence of tailoring does.
One thing we closed by design. Every favourable text concerns an alert about a condition; none concerns an alert that names a direction. Whether "buy" or "sell" is the "more" that turns an alert into advice is answered nowhere. So the signal no longer carries a direction. It is a condition alert, exactly the form the Commission described.
Two corrections to how the adverse cases read. Several of the most-cited cases against us (R&W, Taucher, Vartuli, Donelson, Hall) are commodity cases under a statute that, unlike the Advisers Act, gives publishers no exclusion. Their facts transfer; their conclusion does not (Commodity Trend Service). And Terry's Tips, often cited as an adviser case, was an auto-trading case in the Fourth Circuit's own reading. What is left on the adverse side is real but narrower than it looked.
Why it is still a 3. Nobody has judged this combination. The Commission language is guidance in a rulemaking, not a holding. One notice from 1996 says a security is recommended when it is brought to the customer's attention "through any means", and nothing has reconciled it with the 2001 notice we rely on. The design gives the best answer the form allows. It does not close the question.
Adverse: Rome v. Mandel (2016) (exclusions and position caps 'immaterial'); David Lerner Associates, Rel. 34-105556 (2026) (tailored template; five disclaimers failed); Weiss; Park (Tokyo Joe); §275.203A-2(e)(2); Fiduciary Interpretation, 84 FR 33669. Read down: R&W Technical Services, Donelson, Taucher, Vartuli, Hall (CEA); Commodity Trend Service v. CFTC, 233 F.3d 981, 988 (publisher exclusion absent under CEA); Terry's Tips as read in Pirate Investor (auto-trading). Support: NASD Notice 01-23 (customer-requested alert; customer-selected ranking; 'content, context and presentation'); 88 FR 53975 (2023) and withdrawal (2025); Reg BI, 84 FR 33318 n.182; Datastream; Lowe (publisher). Unreconciled: NASD 96-60 ('through any means')
If our software is the link that sends a member's order to the broker, the SEC may say we are acting as a broker without a licence. Our answer: nothing we control can send an order. The key lives only on a machine the member controls, and every order is the member's own instruction, by his act or by his own plan.
The trading key is stored only on the member's own machine, and we never hold one. Each order is placed on the member's own act, or under a plan he adopted himself and runs himself. We charge nothing per trade. We do not choose where the order goes, we do not pool orders across members, and the member's own broker does the risk checks. The member is his broker's customer, and we say so.
The test. A broker is someone "engaged in the business of effecting transactions in securities for the account of others". The SEC applies it through a list of factors: do you take a fee per trade, do you hold customer money or keys, do you route or pool orders, do you solicit, do you handle settlement. Our design answers every one of them the right way, and the strongest is the key: we have no way to send an order because we have no credential to send it with.
What supports us. The SEC staff cleared this shape in 2005: locally installed, user-programmed software that sent the user's own orders to the user's own broker (CommandTRADE). A court dismissed the broker claim against a self-custody wallet because the user, not the software, controlled the trade at the moment it happened (Coinbase; Risley). And a documented survey of sixteen products in roughly our shape, traced through the SEC, Washington, the CFTC and the private courts, found exactly one status holding, and it rested on six facts we do not share: customer funds held, keys held, a fee per transaction, routing to an affiliate, pooling, and agency (eToro). That is not authority. It is evidence that a visible market has operated for years in our shape without a single challenge on status.
What cuts against us. The key is not the statutory test; the test is conduct, and CommandTRADE rested on a bundle of conditions, not on key custody alone, and said in terms that it was not a legal conclusion. No court has ruled on software that composes the order rather than only routing it. And the nearest commercial analogue, user-written rules, flat subscription, the user's own broker account, was a registered investment adviser from its first day, with discretion. We differ from it in exactly one fact: the member's own act on every order. No product we found pairs all three of our facts, an unaffiliated vendor, the user's own credentials and a per-order act. We are more conservative than every survivor, which also means we are novel rather than proven.
Whose order it is, the brokers have answered. Six brokers, in six separately drafted contracts, treat an order carried by the member's credentials as the member's own, and none conditions that on who composed it or whether a human reviewed it. That question is closed. Whether we are "in the business of effecting transactions" is a different question, and it is still open. Hence 3.
Exchange Act §3(a)(4) ('effecting transactions for the account of others'). Adverse: Neovest (2021), Solium (WA 2020), Vartuli (CEA, see card 03). Support: SEC v. Coinbase (Wallet) and Risley (user control at the moment of trade); CommandTRADE/GlobalTec (2005); Schwab 1996. Context: eToro, Rel. 34-101001 (2024), the one status holding among sixteen surveyed products; P8 survivor and private-litigation tables
Steve picks securities every month using his own judgment. That is advice. It is his, not ours, as long as we never host or carry the list, and his share of the revenue is clearly for the name and the members, not for the list.
The member's own runtime fetches Steve's list straight from Steve's own server. We never store it, never relay it, never show it on our side. Steve's 20% is written down as payment for the community name and the relationship, and he is kept out of the product: he introduces the room, never the software. The list is his publication to his own members.
Where the exposure comes from. Picking securities for people is advice. Steve does it, and the members pay a bundled fee that flows partly to him. If a regulator reads the 20% as payment for the lists, Steve is an adviser being paid through us, and the SEC can reach a company that "causes" someone else's violation through negligence (Section 21C; Ranieri; Apuzzo).
Why it is his and not ours. The separation is complete at the transport layer: not one byte of a list passes through anything we run. The agreement allocates his money to the name and the members, and keeps him room-only.
Why it is still a 3. A regulator looks at the arrangement, not the packets. Our runtime is built to fetch the list, our engine is built to consume it, we contract with Steve, and Steve is paid. Nobody has ruled on whether a revenue share labelled "for the name" can be re-read as payment for the picks. Until someone does, the transport-layer separation is a strong fact and not a closed question.
IA-1092 (bundled fee); Exchange Act §21C ('cause', negligence standard); Ranieri Partners; Apuzzo; Coburn
Brian works in Washington, and Washington's definitions of adviser and broker are wider than the federal ones. A case there went against a company that only sent orders on the customer's request. We have to stay outside Washington's definitions, not just the federal ones.
Everything in cards 03 and 04, applied a second time under the wider state definitions. Nobody is granted authority over the member's account, so the state's rule about written third-party trading authority never comes into play. The runtime exercises no latitude of its own after an order is placed: the member's price limits ride on the broker's own order types, and nothing of ours moves the order afterwards. We do not rely on the federal exemption for advisers with few clients in Washington.
Why Washington is different. The state defines "broker-dealer" and "investment adviser" more broadly than federal law, and it has used that breadth: in Solium (2020) it went after a company whose software only sent orders on the customer's request. Because Brian's place of business is there, the state can reach the Company through him whatever the federal answer is.
What changed in 2024. Washington replaced its broker-dealer conduct rules on 13 October 2024. The new rule on time-and-price latitude drops both of FINRA's limits: it no longer requires that the customer's order name a definite amount, and it has no end-of-day cut-off. That sounds like more room; it is really less certainty, because the federal safe harbour we would otherwise point to does not map onto the state rule. We have answered it by removing the latitude altogether: the runtime never re-pegs and never sweeps, so there is nothing of ours for the wider rule to reach.
Why it is still a 3. We stay outside by the same means as federally, but the definitions are wider, a similar company lost, and no one has tested the new rule against per-order software.
RCW 21.20.005(9), .020(1), .040; Solium (WA DFI, 2020); WAC 460-24A-220(5) (written authority for discretion; not granted); WAC 460-20C-210(6) (in force 13 Oct 2024, replacing WAC 460-21B-060 and 460-22B-090)
A company does not protect the founders personally. In every case we found, the individuals were sanctioned even though a company existed. What the authorities have credited is a working kill switch, documented roles, and real monitoring.
A kill switch that works and is drilled. Role limits that are enforced in the software, not just written in a document. A Delaware company to hold the business. No performance claims and no promises about returns, anywhere.
How founders get named. The SEC can act against anyone who "knew or should have known" that their conduct would contribute to a violation (Section 21C). In Ranieri Partners the person in charge had written a limit on what an unregistered associate could do, never made sure it was kept, and was fined and barred personally. The company was a separate defendant; it did not shield him.
What helps. The one thing the authorities have credited in a founder's favour is a control that provably works: a stop that is documented, tested and observable, and role limits the system enforces. That is why the kill switch is a guardrail and not a feature.
What does not. A Delaware LLC moves the basis of liability; it does not remove names. It is still a 3 because the controls reduce exposure and nothing removes it.
Exchange Act §21C ('knew or should have known'); Ranieri Partners / Phillips (2013) ($75k and a bar); Advisers Act §202(a)(5) ('organized group')
Facts the machine enforces, and rules we keep. Each is something that can be checked: in the code, in a test, in a record. None of them is a legal conclusion; what they are worth in law is argued in the risk cards above, not here. The first six are RAPID itself. The rest are the rules around it. They are listed so nobody removes one later without knowing why it is there.
Whoever holds the trading credential can send an order. We hold none.
The member's trading key is stored only in the keychain or vault on his own computer, or on a server that sits in his own account. We have no key, no token and no server of ours that could place an order. Anyone can check this by reading the code.
This is the single fact most of the position rests on. The SEC staff cleared locally installed software on this basis in 2005, a court dismissed a broker claim against a self-custody wallet on it, and six brokers' own contracts say an order carried by the customer's key is the customer's. It is not, on its own, the legal test for being a broker; that test looks at conduct. But every conduct factor is easier to answer when the answer to "could you send an order?" is no.
SEC v. Coinbase (Wallet); CommandTRADE/GlobalTec (2005); Schwab 1996; six brokers' account terms (guardrail 15); contrast Neovest, Solium
A complete proposed order is a recommendation. An alert that says "buy" may be one. An alert that a rule the member wrote was met is the form the Commission has described as outside recommendations.
The engine sends four things: which rule, which security, when, and its own signature. It cannot send a direction, a quantity, a price, an order type or an account; the connection rejects them. What a rule means, buy or sell, is a setting the member made in his own runtime. The engine only evaluates the member's filters and sorts by the key he chose. Nothing we control decides which security qualifies, when a rule fires or how the list is ordered; every input that affects those can be traced to a setting the member typed or a list he loaded. Sort labels are neutral. Nothing is highlighted. We check this by tracing fired signals back to their inputs, not only by scanning the code for constants.
Two reasons. The first is what a recommendation is: something tailored to a person, or something that tells him what to do. An alert that his own condition was met is neither, and the Commission has said so about alerts an investor configures on his own watch list. The second is that a signal-shaped message was still found to be a recommendation once, under the commodity laws, because the vendor supplied the logic. So the shape alone buys nothing. What matters is that every decision-relevant input is the member's, and that the message names no direction. Both are enforced, not promised.
NASD Notice 01-23 (customer-requested alert; customer-selected ranking criteria); 88 FR 53975 (customizable alert on own watch list); R&W Technical Services (CEA; vendor-supplied logic); Coinbase factor 9; Datastream; Target Architecture R1.2, R1.5
Whoever supplies the values for an order is making the decision. The values are the member's, entered by him.
What each rule means, how much to trade, how much cash to keep back, the order type, the price limits, how long the order lives and which account it goes to: all of it comes from settings the member typed himself, one field at a time, during onboarding. The runtime applies them mechanically. It never supplies a value of its own.
Where the software runs does not decide who is making the decision; who wrote the numbers does. A court said as much about locally installed software whose logic came from the vendor. So the composition has to be the member's, field by field, or moving it to his machine changes nothing.
Taucher v. Born (location is inert; authorship is what matters); Vartuli; Datastream factor 2
Money tied to trades, volume, assets or results is the strongest sign of a broker, and of a financial interest in what the member decides.
One flat fee, for software, infrastructure and support. Nothing per trade, nothing per dollar, nothing per result. No money from brokers, no money from fund issuers, no payment for sending orders anywhere. Steve's share is for the name and the members, never for a list.
Transaction-based compensation is the factor the SEC calls the hallmark of a broker, and it is the fact that sank the two closest companies to us: one took a fee per trade, the other shared commissions. Removing it does not make us safe; it removes the strongest single sign against us.
Rel. 34-90112; Neovest; Solium (commission share); IA-1092; Datastream (interest argument)
The broker is the regulated party. Execution, custody, confirmations and risk checks belong there. So does working the order once it is placed.
Orders go through the member's own broker's published API, with the member's own key. One member, one account, one broker: we never route, pool or choose venues. The order carries the member's own price limits, and if he wants it worked, the broker's own order types do the work (limit, GTC, trailing stop, bracket, OCO), placed on the same swipe. After that the runtime never touches the order: no re-pegging, no end-of-day sweep, no cancel of its own. The member is his broker's customer, and we say so.
Two reasons. The first is the broker test: routing, pooling and venue choice are the things a broker does, so we do none of them. The second came from reading the brokers' contracts. E*TRADE now requires every order sent through its API to rest on a specific instruction from the customer for that particular order, and it names signals and triggers among the things that may not modify or cancel an order without one. A re-peg is a cancel and a new order; a sweep is a cancel. Neither has an instruction behind it. So both are gone, and the broker's own order types carry the member's limits instead.
Rule 15c3-5; Exchange Act §3(a)(4) factors; Schwab 1996 condition 1; CommandTRADE; E*TRADE API Developer License Agreement §4.9 and §1.19; Target Architecture R3.5, R3.8
Whoever acts on an instruction must be able to prove it. The journal is that proof, and only that.
Everything about an order is written to a local journal in the order it happened: the signal, the settings version, the composed order, the exact terms shown, the member's instruction, the adapter, the broker's answer. Nothing is ever rewritten; a correction is a new entry. The broker's statement is the final word on what executed. For the journal to hold up, four more things must be true, and they are requirements, not yet proven: entries are signed, the software release that wrote them is identifiable, the time is trusted, and each instruction is tied to the surface or plan it came from.
An instruction only counts if it can be shown afterwards. Agency law, SEC guidance and broker recordkeeping rules all ask the same thing: what exactly did the customer authorize, when, and can anyone else have produced that record. A local file can be deleted or rewritten, so the journal is evidence only when it can prove it was not. It changes nothing about what we are; it lets us show what the member did.
Restatement (Third) of Agency §8.06 cmt. b; Rel. 33-7856 n.25; 17 C.F.R. §240.17a-3(a)(17)(ii); Target Architecture R4.4
If a member simply clicks "yes" to settings we suggest, the settings are as much ours as his. So there are no suggested settings.
Every field starts empty. No presets, no imports, no "most members choose". The book stays beside the screen, not on it: we never fill a field or show a published number next to one. Members can save and reload their own settings, never share or import another's. Onboarding is recorded, so the record shows the member typed.
The SEC has held that someone who adopts a template is liable as its author, and a Commission release calls the adjusting and customizing of parameters "discretion". On that reading, every parameter we shipped pre-filled would be discretion we exercised. The empty field is what makes "the member wrote every number" true. Whether that changes our status is card 03; no authority yet distinguishes writing a rule from adopting one. But it is the fact the whole card rests on, and it has to be provable.
IA-5653 at 21 (adopter liable as author); Keimer; SEC 2008 layout guidance; Datastream factor 2
Software that acts by itself, or within seconds, is read as making its own decisions. And an instruction is only worth something if we can show the member gave it, and that we could not have given it for him.
One swipe per order, on a screen the runtime draws. That screen has a minimum we have written down and not yet built: it runs in its own signed process, in its own window, the engine cannot read it or inject into it, it shows a mark derived from a secret the engine never sees, the record is created inside the runtime, it fails closed, and we can demonstrate that we ourselves hold no key, no session and no way to write into any member's journal. Whether it runs on the same machine or on the member's phone is not yet decided.
Why per order. A court read a six-second delay between signal and order as the software deciding. A human act in between is the clearest possible answer to "who decided".
Why the surface must be ours, and why that alone is worth nothing. No authority makes it matter whose software drew the screen. The cases that decide "whose act was it" ask something else: could the party now relying on the record have produced it itself? Where it could, the record fails. A runtime that draws the screen, holds the key and writes the record sits in the losing posture until it can show it was locked out of all three. So the surface earns nothing by being ours. It earns everything by our being provably unable to touch it.
Why plan mode is a different thing. We had drawn a "bounded standing authority" for RAPID. That construction is refused: the regulator declined standing instructions, SEC staff answered "We disagree" to a bounded standing authorization, and E*TRADE prohibits it and offers a power of attorney as the only alternative, the exact thing this architecture exists to avoid. What is left is the law's own construction: a plan the member adopts in advance, executed by his own software on a machine only he controls, which the insider-trading rules treat as producing the adopter's own trades. Untested for retail members with third-party software; a counsel question before it ships. Registration is the proven alternative, and it is listed as one.
SEC v. GEL Direct Trust (2023); Vartuli; Weiss; Banister (2021) and Garcia (2024) (attribution fails where the party asserting the act could have produced it); Aerotek (2021) (attribution holds where it could not); NASD 98-66 (a third party may build the order-entry surface); Rel. 34-49883 at 7 (standing instructions declined); Pino, Rel. 34-74903 (2015); IAA SLOA letter (2017) ('We disagree'); E*TRADE §4.9; 17 C.F.R. §240.10b5-1(c)(1)(i)(B)(2) and Rel. 33-7881; Lowe; Target Architecture R2.5
Companies have lost on words alone. Marketing text becomes evidence of what the business is.
One word list, checked by the build before anything ships. Software the member runs, never a service. No "automatic", "recommended", "beta", "partner", "signal service". "Place on swipe", not "Autoplace". Sort labels are neutral, never "best". "Plan" and "instruction", never "authorization" for anything the member does, because nobody is being granted anything.
A court found a product to be an adviser partly on the words "automatic" and "no second-guessing". And no disclaimer repairs a wrong word: in one 2026 case five disclaimers failed together, including a rewrite from "suggested investments" to "examples of potential investments". One old notice is worth knowing because nothing reconciles it with the one we rely on: it says a security is recommended when it is brought to the customer's attention "through any means". The words are evidence; we choose them once.
Vartuli ('automatic', 'no second-guessing'); VCP Financial (2025); Rel. 34-90112; NASD 01-23 ('content, context and presentation'); David Lerner, Rel. 34-105556 (2026); FINRA Rule 2111 Supp. Mat. .02; NASD 96-60 (unreconciled)
A machine reading a price to evaluate a rule needs a costlier data licence than a screen showing the price.
Prices come from the member's own broker, through the same API his key already opens, or from a free data key the member gets himself. We never hold a data credential. The journal stores what the rule computed and what the member set, never the prices themselves. Still to do: read the brokers' terms on showing their data in third-party software.
Exchanges distinguish display use from non-display use, and a rule engine is non-display. If we held the data, we would be the licensee and the fee would be ours. With the member's own key, the licence is his, the way it already is for his broker's app.
Cboe market-data policy, 1 April 2026; exchange derived-data tests; Tiingo §1.6(b) purge-on-lapse
Washington requires everyone in a recording to consent, and the consent has to be inside the recording. A click beforehand is not enough.
The onboarding recording opens with the question, and the member's answer is on the recording itself. The click exists too, never instead.
Washington is an all-party-consent state, and a 2024 decision confirmed that the consent must be captured in the recording, not somewhere else. Brian is there, so the strictest rule is the one we follow.
RCW 9.73.030(3); State v. Fields (2024); 18 U.S.C. §2511(2)(d)
Consumer law on recurring payments: clear terms, easy cancellation, a warning before a trial turns into a charge.
Terms shown and agreed at sign-up. Cancelling is as easy as signing up. A notice three days before a trial converts, which is the strictest state rule. Who does what is written down with the billing platform.
Federal law and several states regulate automatic renewal, and the strictest of them sets the floor for all members. It is unrelated to securities law and it is the kind of thing that generates complaints, which is how regulators find you.
ROSCA 15 U.S.C. §8403; RCW 19.56; Illinois auto-renewal rule; FTC click-to-cancel rule vacated (8th Cir. 2025)
Under AGPL, an engine that talks to the runtime over a network would have to open its own source. Under GPL-3.0 it does not.
The runtime is GPL-3.0-only. The engine talks to it over a network, in its own process, and stays closed. We sign our releases, so our code can be told apart from forks.
A licence is not a legal shield. Regulators do not look at the licence; they look at what you do: who holds the key, who writes the values, who gets paid, who can stop it. An MIT or GPL file limits what a user can claim against the author. It does not change how a regulator sees the author. What keeps an author clear is conduct: he hands over a copy, the recipient runs it with his own keys and values, nobody pays, and the author stays out of it. We chose open source because anyone can read in the code that the key never leaves the member's machine. That is evidence, not a defence.
GPL-3.0 §0, §5; AGPL §13; Lowe (publisher); Coburn (signing keys)
If a court ever found a licensing problem, members could unwind their contracts. Direct, honest terms limit what there is to unwind, and keep our members ours if the community relationship ends.
Product terms signed with the Company on our own website, separate from community membership. The member is his broker's customer for trading and ours for the software. No promises about returns. And, in the terms, no support access to a member's machine: we never log in, and no support case changes that.
Contracts made in violation of the securities laws can be voided by the other side. Keeping the product contract direct, narrow and honest limits that exposure, and keeps the customer relationship where the 1996 Schwab letter needs it: between the member and his broker for trades, between the member and us for software only.
Exchange Act §29(b); Agreement §4.4, §11.2; Schwab 1996 condition 1
The rules on trading authorizations and discretionary accounts apply when someone other than the customer holds power over the account. Here nobody does. Each order is the member's own instruction, given before it is sent.
The runtime records the member's instruction with the exact terms he saw, and cannot be made to change it afterwards. No standing power is granted to us, to the engine or to any builder, and the software never issues a document that would suggest otherwise. After an order is placed, nothing of ours touches it; the member's price limits live in the broker's order types. Written authorizations, and the question of who may hold one, do not arise.
What the rules cover. FINRA's rule on discretion and the SEC's recordkeeping rule apply when a broker or a registered person exercises discretion in a customer's account. Then a written authorization to a named individual is required. Our first draft asked members to sign one for the software. That would have created the very fact those rules exist to regulate: that someone other than the customer holds power. So we removed it. Per-order is a non-discretionary account by definition, and the one thing the rules do allow without authorization, working an order the customer already gave within his price and time, we no longer even do.
What the brokers say. This was our open question, and P8 closed it. Six brokers, six separately drafted contracts, one test: an order carried by the customer's own key is the customer's own order. Schwab: "deemed to have been received from you". IBKR: use of the client's credentials is "conclusive evidence". tastytrade and Alpaca say it in their own words; Fidelity disclaims any duty to look behind the credential. Not one of them asks who composed the order or whether a human reviewed it.
What that tells us. The brokers condition attribution on the key and on nothing else. Not on the approval surface, not on the journal, not on the permission ladder. The key living only with the member is the fact that makes every one of these clauses work in our favour.
Schwab Electronic Services Agreement §12 and Account Agreement §26; Interactive Brokers Client Agreement §4; tastytrade Customer Agreement §4; Alpaca Customer Agreement §16(e)(7); Fidelity Terms of Use; E*TRADE API Developer License Agreement §4.9 (all read 7 September 2026). Rules: FINRA Rule 3260(b), 3260(d)(1); 17 C.F.R. §240.17a-3(a)(17)(ii); WAC 460-24A-220(5); Reg E 12 C.F.R. §1005.10(b) (analogy); Target Architecture R2.4
The founders are exposed personally regardless of the company. The one thing the authorities have credited in a founder's favour is a stop that provably works. A stop only counts if it is drilled and logged.
Three stops, three different hands on them. The first two protect the member; the third protects the founders. Each is documented, tested and observable, and every use is logged with time and actor.
| Stop | Who presses | What happens |
|---|---|---|
| Cancel all orders | The member | Every order the runtime has resting at the broker is cancelled, on the member's act. Nothing new is stopped; it is clean-up. There is no scheduled sweep: day orders expire at the broker, and the member can cancel any order himself at any time. |
| Emergency stop | The member | Sets TRADE to OFF and cancels the runtime's own resting orders. No confirmation needed. TRADE can be switched back on only from desktop Settings, where the member reads and accepts the terms again; that acceptance is journaled with the terms version, time and actor. No written reason is asked for. |
| Operator halt | The Company | For a hosted engine: stops it sending to every runtime at once, and can revoke a source so no runtime accepts it. For a local engine: can withhold or revoke the licence and withdraw a release; cannot reach a running instance, and does not try. This is the founders' own mechanism. |
In Ranieri Partners the person in charge had written a limit, never made sure it was kept, and was fined and barred personally. The lesson is that a limit only protects the person who can prove it was enforced. None of the authorities asks for a reason when the member restarts; what they ask for is a deliberate, documented act by the member himself, and a fresh acceptance of named terms is stronger evidence of that than a free-text explanation.
Ranieri Partners / Phillips (limit written, not enforced; $75k and a bar); §21C 'knew or should have known'; Restatement (Third) of Agency §8.06 (consent record); Target Architecture R3.2 (member stops) and R3.3 (operator halt)
A broker decides whose order it is, and separately whether our software may connect at all. The second question is not answered by anything we do for the member, and it can close a broker to us on its own.
Before an adapter ships, we read that broker's terms for third-party software, do what they require, and write down what we did. Plan mode is switched on only at brokers whose terms allow orders without a per-order instruction. A broker letting us connect is recorded as permission, never as a statement about our legal status.
| Broker | Gate |
|---|---|
| E*TRADE | Vendor key; review with unpublished criteria; no registration requirement. Every order needs a specific instruction from the member for that order, so plan mode is not permitted as the terms stand. That is the negotiation. |
| Schwab | Written approval through its Developer Program. |
| Interactive Brokers | Expects a third party offering automated trading to hold registration, or to explain in a legal opinion why it need not. |
| tastytrade | Prior written approval for software the account holder did not write. |
| Fidelity | Prohibited. No retail trading API. |
| Alpaca | No gate on the customer's own key. Not a candidate, for reasons unrelated to permission. |
Nothing in the legal research found this; the brokers' contracts did. Their permission turns on who wrote the software, whether they approved it, and whether the vendor is registered, none of which has anything to do with who decided the trade. And two brokers say in terms that letting us connect says nothing about our status: Schwab has no obligation to check whether we need to register, and Fidelity makes the third party responsible for deciding its own. So a broker's yes is a door, not an opinion, and it must never be written down as one.
Schwab Electronic Services Agreement §14 and Developer Program Agreement §3; tastytrade API Terms of Service §2(3)(f), §2(3)(g); Fidelity Terms of Use ('Prohibited Uses') and Account Authority form; Interactive Brokers third-party OAuth registration process; E*TRADE API Developer License Agreement §1.19, §4.8, §4.9, §11.8; Alpaca Customer Agreement §10, §16(c) (all read 7 September 2026); Target Architecture R3.9
Auto is lawful when the software is the member's tool, not our service. The test is whether anything of ours sits in the chain when an order is sent. In plan mode it does not.
The engine and the runtime run together on a machine only the member controls: his own computer, or a server in his own cloud account set up from an image we publish. We hold no login, no key and no root on it. We cannot start or stop it. We receive only what he switches on: a heartbeat, a diagnostic bundle without keys or prices, and, if he wants, a summary for the read-only dashboard. Updates are pulled by his machine as signed releases. The engine is licensed software, and the only thing it ever asks us is whether the licence is valid; our licence server has no field for, and no knowledge of, signals or orders. When the licence lapses the engine stops after a short grace, like any subscription software.
Every refusal of automated execution we found concerns authority granted to someone else. None concerns a person running his own software on his own machine. That is the shape the publisher line describes, and the shape the unaffiliated survivors in P8 have run in for years, unregistered and, on a documented search, unchallenged. The two things that could put us back in the chain are a server that answers "may this order go" and a login we could use. We have neither, and both absences can be shown. Whether a licence check keeps us out of the chain is counsel question A5; whether the member's plan is his own instruction is A4.
Lowe (publisher); 17 C.F.R. §240.10b5-1(c)(1)(i)(B)(2) (pre-adopted 'algorithm, or computer program'); P8 survivor table (QuantConnect, TradeStation, Freqtrade); Coburn (signing keys); Target Architecture R1.6, R3.10
The research behind this page. P7 (5 September 2026) consolidates every round since July. P8 (7 September 2026) is additive: it reads the brokers' own contracts, traces sixteen comparable products through the enforcement record, and answers the open question in guardrail 15. Both are attached: Authority Register P7 (download, 1 MB) · Authority Register P8 (download, 1.5 MB).