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. Seven research rounds since July, a formal opinion from securities counsel in June, and the technical integrations and implementations that were built, run and revised along the way, led to the RAPID target architecture. The law was read before anything was frozen; the product was built and put to use as the findings came in. Every constraint below is a legal finding turned into a boundary, a default or a missing feature.
Two laws can reach us. 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 member writes every rule and every number himself. To the second: we cannot send an order; the key exists only on the member's machine, and the member is his broker's customer, not ours.
Why it is robust: each position rests on something a regulator has credited. Locally installed, user-programmed order software (CommandTRADE, 2005). Keys held only by the user (Coinbase Wallet). A customer-defined alert is not a recommendation (NASD 01-23). The one similar company that lost (Neovest) took a fee per trade and recruited customers for its own service. We do neither.
Why it is untested: nobody has judged this combination as a whole. Each part has support; the sum has not. That is why most cards sit at 3, not 2. A no-action letter to the SEC, once the product is frozen and running, is how it gets closed.
What else helps: 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. And the weakest points are not architecture but discipline: no presets, software not service, and Steve introduces the room, not the product. And how we talk about it and market 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.
Market software, never a service; sales only on own website; community = use, not sale; Steve introduces the room, never the product; Schwab condition 1 in all marketing, onboarding, Product Terms
4 because it is the one factor design cannot remove: the product does end in an order, and the Commission has already rejected the exact posture we rely on (Neovest para. 14). Wording and the broker-customer sentence reduce it; nothing eliminates it.
Neovest para. 14 ('independent software provider' branding consistent with solicitation); Schwab 1996 condition 1
If our software is the thing that sends a member's order to the broker, the SEC may say we are acting as a broker without a licence. Our answer: we cannot send anything. The key lives only on the member's machine, and the member approves every order himself.
Trade credentials only in member's local vault; no Company credential; per-order act; no per-trade compensation; no routing/netting/venue choice; broker does 15c3-5; 'you are a customer of your broker, not of us'
3 because the design answers every element (no key, no per-trade fee, per-order act) and two authorities support it, but no court has ruled on software that composes the order rather than just routing it.
Adverse: Neovest (2021), Solium (WA 2020), Vartuli. Support: SEC v. Coinbase (Wallet), CommandTRADE/GlobalTec (2005), Schwab 1996
If we are paid to tell people what to buy or sell, we are an investment adviser and must register. Our answer: the member writes every rule and every number himself, and asks to be alerted. Nobody in the chain recommends anything.
Member authors every rule and value; member requests the alert; no recommendations, presets, rankings or 'suitable'; signal-only engine; no personalization
3 because authorship and member request are what the authorities credit, and we have both, but no authority has ever said that a member-authored rule keeps the software outside the definition.
Adverse: R&W Technical Services, Weiss, Terry's Tips, Park (Tokyo Joe). Support: NASD 01-23 (customer-requested alert), Datastream, Lowe (book only)
Steve picks securities every month using his own judgment. That is advice. It is his, not ours, as long as we never host or transmit the list, and his share is clearly for the name and the members, not for the list.
Bring-your-own: member fetches from Steve's own endpoint, Company never hosts/transmits; 20% expressly for name and relationship; Steve room-only (§4.3); universes are his publication to his members
3 because the exposure is real (curation is advice) but it is his, and our separation is complete on paper. Untested whether a 20% share can ever be read as payment for the list.
IA-1092 (bundled fee); §21C 'cause' (negligence); Ranieri; Apuzzo; Coburn
One monthly fee for everything looks, to a regulator, like a fee for advice. We state in the agreement what the fee actually buys: software, infrastructure and support. Nothing per trade, nothing tied to results.
Fee stated as payment for software, infrastructure, support (§7.1); nothing per trade/AUM/performance; no payment from brokers or issuers
3 because a bundled fee satisfies the element in every case we found. The mitigation is honest description, not removal. It only matters if there is advice somewhere in the chain.
IA-1092 at 10; Weiss; Park; IA-2376 ('special compensation' = other than commissions)
Brian works in Washington, and Washington's rules are wider than the federal ones. A case there (Solium) 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.
Stay outside the federal and WA definitions (same mitigations as above); journal exports a written third-party trading authorization; no §222(d) reliance in WA
3 because Washington's definitions are wider than federal and a similar company lost there. We stay outside by the same means as federally, but the margin is thinner.
RCW 21.20.005(9), .020(1), .040; Solium (2020); WAC 460-24A-220(5)
A company does not protect the founders personally. In past cases the individuals were sanctioned even when a company existed. A working kill switch, documented roles and real monitoring are what the authorities have credited.
Working, documented kill switch and monitoring; role limits actually enforced; Delaware LLC (moves basis, not names); no fraud, no performance claims
3 because in every case found the founders were named even with a company. The kill switch and documented roles are credited, but they reduce, not remove.
§21C 'knew or should have known'; Ranieri/Phillips ($75k + bar); §202(a)(5) 'organized group'
The things we do, and keep doing. The first six are RAPID itself: the construction. The rest are the rules around it. None of these is a risk; each is a decision already built into the product. They are listed so nobody removes one later without knowing why it is there.
Whoever holds the trading credential can send an order. If we cannot send one, we are not the link that sends orders.
Trade-capable credentials live only in the member's local keychain or vault, per member. There is no Company credential, no app-level token, no server that can place an order. Provable by static check. This is the best-supported fact in the whole register.
SEC v. Coinbase (Wallet); CommandTRADE/GlobalTec (2005); Schwab 1996; contrast Neovest, Solium
A complete proposed order is a recommendation. A notice that the member's own rule fired is not.
The engine emits rule_id, instrument, side, time and signature. Nothing else crosses the boundary; the integration contract rejects quantity, price, order type and account. Signal-only alone buys nothing; what carries weight is that the member authored the rule and asked to be told.
R&W Technical Services; NASD Notice 01-23 (customer-requested alert); Coinbase factor 9; Datastream
Whoever supplies the values for an order is making the decision. The values are the member's, entered by him.
Sizing, cash reserve, order type, price band, time-in-force and account come from the member's local policy, typed field by field in onboarding. The runtime applies them mechanically and never supplies a value of its own.
Taucher v. Born (location is inert; authorship is what matters); Vartuli; Datastream factor 2
Compensation tied to trades, volume, assets or results is the strongest sign of a broker and of a financial interest in the member's decisions.
A flat membership fee for software, infrastructure and support. Nothing per trade, per volume, per asset or per result. No payment from brokers or issuers, no payment for order flow. Steve's share is for the name and the members, never for a list.
Rel. 34-90112; Neovest; IA-1092; Datastream (interest argument); Solium (commission share)
The broker is the regulated party. Execution, custody, confirmations and pre-trade risk control belong there, and stay there.
Orders go through the member's broker's own published retail API under the member's own credentials. The broker runs Rule 15c3-5. One member, one account, one broker: no routing, no netting, no venue choice, no batch across members. The member is his broker's customer, not ours.
Rule 15c3-5; Exchange Act §3(a)(4) factors; Schwab 1996 condition 1; CommandTRADE
Whoever acts on a consent must be able to prove it. The journal is that proof, and only that.
Local, append-only, provenance-linked: source, policy version, composed order, exact terms shown, authorization, adapter, broker response. History is never rewritten; corrections are new events. The broker's statement is final truth about execution. The journal is necessary, not status-changing.
Restatement (Third) of Agency §8.06 cmt. b; Rel. 33-7856 n.25; 17 C.F.R. §240.17a-3(a)(17)(ii)
If a member simply clicks 'yes' to settings we suggest, the law treats the settings as ours. So there are no suggested settings.
Fields start empty. No presets, no import, no 'most users choose'. The book stays beside the screen, not on it. Members may save and reload their own settings, never share or import another's. The onboarding is recorded, so the record shows the member typed.
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.
One explicit act per order, in the RAPID panel inside the engine. In version 2, standing execution carries a built-in delay between signal and submission as a system requirement, so no order leaves at machine speed.
SEC v. GEL Direct Trust (2023); Vartuli; Weiss. Support: CommandTRADE/GlobalTec (2005)
Companies have lost on words alone. Marketing text becomes evidence of what the business is.
A canonical word list, enforced by a check in the code before anything is merged. Software the member runs, never a service. No 'automatic', 'recommended', 'beta', 'partner', 'signal service'. 'Place on swipe', not 'Autoplace'.
Vartuli ('automatic', 'no second-guessing'); VCP Financial (2025); Rel. 34-90112
A machine reading a price to evaluate a rule is non-display use, which needs a costlier licence than showing a price on screen.
Prices come from the member's own broker through the API the runtime already holds the member's key for (E*TRADE first, free to account holders; IBKR by the member's own subscription), or from the member's own free data key as fallback. The Company never holds a data credential. The journal stores derived values and the member's terms, never prices. Still to do: read the brokers' terms on third-party display.
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 must be inside the recording. A click beforehand is not enough.
The onboarding recording opens with the question and the member's answer on the recording itself. The click exists too, never instead. Audio is what the rule covers.
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, notice before a trial converts.
Clear disclosure and express consent at sign-up; cancellation as simple as sign-up; notice three days before a trial converts (the strictest state rule, Illinois); seller duties allocated with the billing platform in writing.
ROSCA 15 U.S.C. §8403; RCW 19.56; Illinois auto-renewal rule; FTC click-to-cancel rule vacated (8th Cir. 2025)
Under AGPL, Brian's engine would have to open its source because it talks to the runtime over a network. Under GPL-3.0 it does not.
The runtime is licensed GPL-3.0-only and stays so. The engine connects through a data-only network boundary, separate process, no linking. The engine remains Brian LLC background IP. A common misunderstanding, corrected: open source does not by itself reduce legal exposure. No securities authority gives weight to the licence; what matters is who holds the key and who authored the values. We chose open source for trust and for the ecosystem, not as a legal argument.
GPL-3.0 §0 (interaction without a copy is not conveying), §5; AGPL §13
If a court ever found a licence problem, members could unwind contracts. Direct, honest terms limit what there is to unwind, and keep our customers 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.
Exchange Act §29(b); Agreement §4.4, §11.2; Schwab 1996 condition 1
The member approves in Brian's interface, but our runtime acts on it. Consent must run to the party that acts.
A RAPID-owned panel inside the engine takes the act. The runtime mints the record, bound to the exact terms shown, member, account, source and a nonce; immutable after mint. The engine cannot forge or alter it. The journal can export a written authorization per source. Open formality: the rules speak of a natural person holding the authorization.
Reg E 12 C.F.R. §1005.10(b) (analogy); Aerotek; RCW ch. 1.80; FINRA 3260(b); WAC 460-24A-220(5)
The founders are exposed personally regardless of the company. The one comfort feature the authorities have credited is a working, documented stop with real monitoring. A stop is only a stop if it is drilled and logged; a limit that cannot be shown to have been enforced protects nobody.
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, actor and reason.
| Stop | Who presses | What happens |
|---|---|---|
| Cancel all orders | The member | Every order the runtime has resting at the broker is cancelled. Nothing new is stopped; it is clean-up, not a stop. |
| Emergency stop | The member | The runtime stops accepting signals from every paired source at once, and cancels its own resting orders. Stop needs no confirmation; resume needs a written reason. The end-of-day sweep is the scheduled form of the same thing. |
| Operator halt | The Company | The operator of a hosted engine stops it emitting signals to every paired runtime at once, and the Company can revoke a source's registration so no runtime accepts it. This is the founders' own mechanism: the one that shows a role limit was enforced, not just written. |
Role limits are enforced, not just written. The member's stops answer the member's risk; the operator halt answers Ranieri, where the person in charge was sanctioned for a limit he had written but never made sure was kept.
Ranieri Partners / Phillips (limit written, not enforced; $75k and a bar); §21C 'knew or should have known'; Target Architecture R3.2 (member stops) and R3.3 (operator halt)
The research behind this page. The latest register (P7, 5 September 2026) consolidates all earlier rounds since July, so it is the only one attached: Authority Register P7 (download, 1 MB).