SEC 4-927: when should a tokenised stock venue check who can trade?
Letters on SEC File 4-927 ask that tokenised stock venues check wallet eligibility at the trade, not only at onboarding, and keep a signed record of each check.

The Innovation Exemption for tokenised stocks is Exchange Act Release No. 34-106402. The Securities and Exchange Commission (SEC) issued it on September 17, 2026. Venues that use it have to decide who may trade. Nothing in the release chooses between a decision taken when the wallet is admitted and a decision taken again as a trade is about to settle. An allow-list keeps the result from the day the address was put on it. The next morning can bring an Office of Foreign Assets Control (OFAC) designation, a lapsed accreditation or a mandate that has been pulled, with the list still reading yes. File No. 4-927 now has letters asking the Commission to settle the timing before any permanent version. The piece below covers the request, the letters that sit with it, the objection the author is willing to grant, and the check he sells.
Key facts
- Comments on Release No. 34-106402 are on File No. 4-927. The relief lasts until September 17, 2031, and the order names no last day for comments. Symbol caps, the sunset and the synthetic tokens the order leaves out are in our September 24 piece, SEC innovation exemption caps tokenised stocks at 75 and 250 symbols.
- Access standards are required on the permissioned automated market maker (AMM) pools of a Tokenized Securities Venue (TSV). Note 31 still holds the venue to the result when the permissioning is done by someone else.
- If the exemption is made permanent, The Insumer Model's September 17 letter wants the access decision taken against the records as they stand at the trade, plus a signed record a third party can check.
- In Shawn SN's October 12 letter, the screen would run "at the time of each transaction". The fallback cycle in that draft "does not exceed twenty-four (24) hours".
- Vertalo is an SEC-registered transfer agent. Its letter asks that a venue be allowed to depend on the eligibility determination the agent's own work already attaches to the token.
- Douglas Borthwick put the timing question to us. He went through the whole file and found no letter arguing against checking at the time of the trade. InsumerAPI is his. The September 17 letter says the service "returns a signed yes or no", and it says "We sell that service."
Where Release 34-106402 stops
Permissioning, as the order describes it, is wide. The Insumer Model's letter reproduces the line that a pool "may be encoded with criteria or a list of persons to ensure that only certain 'white-listed' or 'allow-listed' crypto asset wallet participant addresses (i.e., wallet addresses that meet certain credentialing requirements) gain access to trading," and the further line that screening "may be done through, for example, active, offchain management or onchain protocols." In the public notice, Item (f) requires a description of "the criteria or standards used to grant a person access."
The text never says the test happens once, and it never says the test happens on each fill. Wallet allow-listing, and OFAC screening with it, were already among the heavier compliance jobs listed for a venue in our September 24 piece. A TSV has to be a US person. Sanctions obligations therefore sit on the venue itself. What the comment file is pressing is narrower: whether a list built at onboarding is enough on its own.
Currency of the check, and who pays
Douglas Borthwick founded The Insumer Model LLC and filed on the day the order was issued. A permanent exemption, as the letter asks for it, would bind the access decision to two properties. The venue would still pick the mechanism. On currency, the letter's demand is that the check "should be made against the current state of the relevant records at the time access is exercised, not only at onboarding." On the record left behind, the letter says each decision "should produce a record that is independently verifiable after the fact." Speed can remain with the on-chain list. He describes that list as working "as a cache of a current-state check, with the check itself as the control."
He replied in writing, on the record, on October 15, 2026. The first question was what makes an allow-list go stale:
The list records who was eligible on the day each address was added. Several things can change after that without the list changing. OFAC can add a person to the sanctions list, and some entries name their crypto addresses; a wallet added the week before is still on the venue's list the morning after. A wallet's keys can be stolen, and the list keeps saying yes to whoever now holds them. Accreditation is the slower version: it is verified at a point in time, and for the non-listed securities some letters on the file want added, the investor's status can lapse while the list stays the same.
This matters more as software starts trading. An AI agent trades from a wallet under authority someone gave it: a firm, a fund or a person. That authority can be narrowed or withdrawn at any moment, often in a single transaction on a public ledger, and the agent can trade many times in the minutes before anyone updates a list. For an agent, the allow-list answers whether its wallet was once approved, not whether it is still allowed to act.
The second question was latency, cost, and who carries it:
The check is one read of current state before the trade settles. In most cases that is quicker than the settlement itself. On cost, a single check from a third-party service is priced in cents; ours is five cents or less per call. Treating the on-chain list as a cache keeps both small: the list still does the fast work, and the current-state check is the control behind it.
The venue should carry it, because the Order puts access standards on the venue. The venue can rely on others to do the work, and should stay responsible for the result. Vertalo's letter on the file argues that a venue should be able to rely on eligibility the issuer's registered transfer agent already enforces on the token, with the venue still responsible. Where a transfer agent enforces the restriction on every transfer, that is a check at the time of the trade, and I think that reliance is reasonable.
The record staff could test without the venue
The third question was what a signed record of each check should contain:
At a minimum: the criterion exactly as it was evaluated (which list or condition, which chain, any threshold), the address, the time and the ledger state it was read at, and the result. Those fields should be signed together, with a key identifier that points to a public key published where staff can fetch it. With that, staff can check two things without the venue's systems: that the record has not been altered since it was signed, and, by reading the public ledger at that point, that the answer was right. The record should not contain the wallet's holdings or history. The venue needs the decision, not a copy of the participant's finances. And since the records have to be kept for the life of the exemption, the signature should be one that can still be checked at the end of that period.
He also wants Item (f) of the public notice to ask what an access check "returns and retains about a participant's address beyond the access decision itself." Separate from his answer, the order's retention period for books and records is three years, counted from the end of the exemption.
Why he wants a condition
The fourth question was why a condition, rather than best practice:
Venues compete on cost and speed, and a check that is optional is the first thing to drop when volumes rise. The Order already handles everything else it cares about this way: halts, notices and books and records are conditions, not suggestions. My letter asks only for two properties, that the check reflects current state and that it leaves a verifiable record. It names no vendor, chain or method, so a venue can meet it with its own systems. A best practice also gives an examiner nothing to test against five years from now.
Shawn SN, SecondaryDAO, Vertalo, and the OKXICE notice
The file is not a one-letter argument. Shawn SN filed on October 12 under the title "Safely Crossing the Rubicon." The letter's own sentence is "On access, a static allow-list goes stale when sanctions lists change." Standards in the draft, "including screening against the Specially Designated Nationals and Blocked Persons List," would be applied by the TSV. The moment of that application would be "at the time of each transaction." If a screen on each trade cannot be done, the cycle "does not exceed twenty-four (24) hours," and wallets would be screened again within 24 hours of any change to that list. Reliance, under the draft, would be "on a signed determination from its screening service that a wallet address is eligible."
Membership interests in income-producing real estate are what SecondaryDAO tokenises. The firm says the platform is not yet operating. In the September 19 letter the sentence is "Eligibility is checked before every trade settles." Each fill needs a signed permit. Before the permit is issued, a policy engine has looked at both counterparties: US-person status, the holding period, the holder cap and investor status.
Vertalo, writing on September 25, starts from the transfer agent rather than the venue. The letter looks at the issuer's registered transfer agent in the case where that agent is the party enforcing the security's transfer restrictions on the token. In that case, it says, "that transfer agent already keeps the record of which wallets are eligible to hold it." What it wants from the SEC is confirmation that the TSV may use the record, "with the TSV remaining responsible under footnote 31." Borthwick's answer, quoted above, calls that reliance reasonable when the restriction is applied on every transfer.
A live notice already shows the switches. The OKXICE TSV notice of October 4 is quoted by Professor Seth C. Oranburg in his October 12 letter. The venue "may burn or revoke a TSV Participant's SBT [soulbound token], and restrict the wallet or remove it from the whitelist." The 63 names are in our October 5 report, OKXICE's SEC notice lists 63 stocks; Cerebras objects. Taking a wallet off the list after the fact is not the same act as testing it before the trade. It is evidence of the controls the notice already describes.
The objection he accepts, and the product he sells
The sixth question asked for the strongest argument against checking at the time of the trade:
That a live check adds a dependency. A list never goes down. A check can, and then the venue has to choose between stopping trading and trading unchecked. Close behind it: for listed stock, a participant's eligibility rarely changes within a day, so a daily refresh may catch nearly everything a per-trade check would, at lower cost and with fewer moving parts. And if many venues rely on the same checker, that checker becomes a single point of failure for all of them. These are real, and they are why I would accept a stated short refresh cycle where a per-trade check is not feasible, as Shawn SN proposes. Where I come out differently is on sanctions and on authority that has been withdrawn, because both change in a single transaction, and a day is long enough for the wrong person, or an agent that has lost its mandate, to trade many times.
The fifth question was how readers should weigh the recommendation:
With my interest in mind. I sell this kind of check, and the letter says so in its second paragraph. Two things readers can check for themselves: the recommendation can be met without buying anything from me, and I am not the only one on the file to reach it. Shawn SN's October 12 letter proposes screening at the time of each transaction, or on a stated refresh cycle of no more than 24 hours where that is not technically feasible, and says the check can return a signed yes or no. SecondaryDAO, which runs its own trading platform, describes in its September 19 letter checking eligibility before every trade settles. [SecondaryDAO’s letter says its platform is not yet operating.]
Three ways the timing could be written
Whether the TSV exemption should be made permanent is a question the order itself asks. Comments have no cut-off. A permanent exemption is what The Insumer Model's letter supports, keeping the conditions the order already imposes for permissioning, for the public ledger, for trading halts, for the public notice and for books and records, and adding the two properties. Between Shawn SN's draft text and Vertalo's transfer-agent route, the Commission has three formulations in front of it. One tests each trade. One tests on a cycle that has a cap. One relies on a restriction enforced on the token. Notices going in now are each venue's own completion of Item (f).
FAQ
Does Release 34-106402 make a venue test the wallet on every trade?
No such rule is in the release. A Tokenized Securities Venue has to have access standards. The public notice is where those standards are described. Screening may run on chain or off chain. Onboarding-only and each-trade are both still open. The Insumer Model and Shawn SN have asked, on File No. 4-927, for the point to be decided if the exemption becomes permanent.
How does an allow-list end up approving a wallet that no longer qualifies?
It stores the answer from the day the address was added, and later events do not rewrite the row. OFAC can publish an entry that names crypto addresses. The keys can pass to someone else. Accreditation can run out. A trading agent's mandate can be cancelled. Until the venue changes the list, the old approval stands.
What is the hard objection to a check on every trade?
The check can be unavailable. The list cannot. A failed check forces a choice between halting and letting the trade through with no test. One checker used by many venues fails for all of them at once. Listed-stock eligibility often holds for a full day, which is the practical case for refreshing on a timetable instead of on each fill. Where a per-trade screen cannot be built, Shawn SN's draft allows as long as 24 hours between screens. Borthwick would take that fallback. He separates sanctions, and a mandate that has been pulled, because either one can flip in a single transaction.
Where does Vertalo's transfer-agent idea fit?
On September 25, Vertalo asked the SEC for confirmation that the venue may take its eligibility cue from the issuer's registered transfer agent, in cases where that agent is already enforcing the restriction on the token. Responsibility would remain with the venue under footnote 31. Where the restriction is applied to every transfer, Borthwick reads the arrangement as a test at the time of the trade. The Commission has not answered.
This article is informational analysis only and does not constitute legal, regulatory, tax, or investment advice. Regulatory frameworks change frequently and interpretation depends on facts and circumstances; primary documents and official regulator guidance always supersede summaries. Firms should consult qualified legal counsel and their relevant supervisory authority before taking any action based on the analysis above.
Reporting by Rick Steves. Filed 22 October 2026, 10:10 GMT.




