On April 13, 2026, the staff of the SEC's Division of Trading and Markets said it will not object to certain crypto front ends operating without broker-dealer registration. If you run a DeFi interface, a self-custodial wallet, or a trading screen for tokenized securities, and you have been geo-blocking US users, that decision is now worth reopening.
Reopen it with the limits in front of you. This is a staff statement, not a Commission rule, and it says of itself that it has no legal force or effect. It answers one question: whether you must register as a broker-dealer under Section 15 of the Securities Exchange Act of 1934. It answers it only for interfaces used to prepare transactions in crypto asset securities. And absent action by the Commission, it will be considered withdrawn five years from the day it was issued.
Within those limits, the staff was specific. It set out twelve circumstances, and they are detailed enough to design a product against.
What the SEC staff said on April 13, 2026
Section 15(a) of the Exchange Act makes it unlawful for a broker to induce or attempt to induce the purchase or sale of any security unless that broker is registered under Section 15(b). Section 3(a)(4) defines a broker as any person engaged in the business of effecting transactions in securities for the account of others. Whether software that displays prices and assembles a transaction payload sits inside that definition has been an open question for front-end teams.
The Staff Statement Regarding Broker-Dealer Registration of Certain User Interfaces Utilized to Prepare Transactions in Crypto Asset Securities answers it conditionally. Where a Covered User Interface Provider takes the measures the statement describes, the staff will not object to that provider operating without registering as a broker-dealer under Section 15(b).
A non-objection is not an exemption
Read footnote 1 before you read anything else. The statement represents the views of the staff. It is not a rule, regulation, guidance, or statement of the Commission, the Commission has neither approved nor disapproved its content, and it has no legal force or effect: it does not alter or amend applicable law, and it creates no new or additional obligations for any person.
So what you have is an enforcement posture. It tells you what the staff says it will not object to. It does not bind the Commission, a court, a state regulator, or a private plaintiff, and the staff can revise its view.
A five-year clock, and an open comment file
The staff calls the statement an interim step while the Commission continues to consider regulatory issues relating to crypto asset securities activities, and the feedback it has received. Absent intervening Commission action, it will be considered withdrawn effective five years from April 13, 2026. Footnote 5 points readers to the Commission's Crypto Task Force for the wider work.
Commissioner Hester Peirce commended the Division the same day, and said she favors a more permanent regulatory approach that addresses the broker definition in light of current market circumstances. The staff has invited public comment on all aspects of the statement under File Number 4-894. If your product sits near the edges of this position, a comment costs you an afternoon.
What counts as a covered user interface
The statement defines a Covered User Interface as an interface provided by a website, browser extension, or other software application, which may be embedded in a wallet or separately available for download. It is designed to assist users engaging in user-initiated crypto asset securities transactions on blockchain protocols or blockchain-based smart contracts, using the user's own self-custodial wallet.
Mechanically, these interfaces convert user-identified transaction parameters, such as buy or sell, volume, the asset, and price or price range, into blockchain-legible commands for signature and transmission through the user's own wallet.
What your interface may do
The staff describes covered user interfaces as useful software, not empty forms. On its account, they may:
- Display market data, including potential execution routes, asset prices, and estimated transaction costs such as gas fees
- Present educational material that helps users formulate and set their transaction parameters, either per transaction or as defaults
- Connect to one or more default trading venues, such as limit order book matching or request-for-quote systems, or to distributed ledger trading systems such as automated market maker liquidity pools and liquidity aggregators
The statement also records that providers generally charge users a fixed percentage per transaction, and that a provider may solicit investors to use the interface.
That last point matters more than founders expect. You may market your product. What you may not do is solicit any specific crypto asset securities transaction. Those are different activities and the statement separates them cleanly.
Self-custodial only
A wallet is self-custodial for these purposes only where neither the wallet provider nor its associated interface has custody of, or access to, the user's encrypted or decrypted private key. The statement expressly does not address the staff's views on providers of custodial wallets held on behalf of an investor with an associated covered user interface.
If you hold keys, you are outside this statement. If your architecture is somewhere in between, whether MPC, smart accounts, or social recovery with a provider-held share, resolve that before you rely on any of this. Our guide to custodial and non-custodial wallets sets out the distinction in more detail.
The gate before any of this: is the asset a security?
The statement addresses only the use of an interface for crypto asset securities transactions, and only crypto asset securities, not interfaces for other securities. A crypto asset is any digital representation of value recorded on a cryptographically secured distributed ledger, and crypto asset securities include tokenized versions of an equity or debt security.
So the analysis runs in this order. Are the assets your users transact in securities under US law? If they are not, Section 15 is not the provision that applies to you and this statement changes nothing. If they are, this is the framework that now describes your position.
For that first question, the statement's own footnote 3 points to the staff's Statement on Tokenized Securities of January 28, 2026, which is where most tokenized real-world asset projects should start. We cover the structuring side in our guide to stock tokenization for founders.
The conditions attached to the staff's position
The statement's own words are "circumstances" and "measures", not "conditions". Read them as conditions anyway. The non-objection applies where you take them, and nothing in the statement suggests that partial compliance earns partial comfort.
There are twelve. Treat the list as a product specification.
Three that catch products already in market
Compensation disqualifies more products than anything else here, and it is a commercial decision before it is a legal one. Your charge has to come from the user and be agnostic to route, venue, counterparty and product. Footnote 12 spells out what that rules out: you may not receive compensation based on the size, value or occurrence of a transaction from anyone other than the user, which precludes payment for order flow. Venue rebates and affiliate kickbacks on execution put you outside the position however neutral your interface looks.
Second, the copy in your interface. A "best route" badge, a "recommended" tag, or a default described as optimal is commentary, and the condition on commentary has no qualifier attached to it.
Third, the nine disclosure categories. These are a build task rather than a policy document, and they are worth listing in full:
- Your role in creating, offering or operating the interface, including a prominent disclaimer that you are not registered with or regulated by the SEC in respect of it
- Your fees, their calculation and their structure
- Material conflicts of interest tied to a crypto asset securities transaction, and your or your affiliates' use of users' trading information
- Any limitations on the assets, market data and venues available through the interface
- The parameters your software uses to prepare instructions and display route data
- Your current cybersecurity policies, procedures and controls, if any
- Your policies protecting user trading information from fraud or manipulation, including MEV strategies, if any
- Your venue integrations, named, with the policies you use to evaluate, onboard and audit them
- Your default transaction parameters, how they are determined, and the risks and conflicts attached
The statement adds that keeping policies, procedures and books and records may help you show you are operating as it describes.
What the statement does not cover
Activities that take you outside it
The staff's position does not extend to a provider that engages in, or holds itself out as providing, any of the following in relation to securities:
- Negotiating terms for any transaction
- Soliciting specific crypto asset securities transactions
- Making investment recommendations or providing advice
- Arranging for financing
- Processing trade documentation
- Conducting independent asset valuations
- Holding, having access to, handling, managing or possessing user funds, securities or stablecoins
- Executing or settling transactions
- Taking or routing orders
Read the last item against the routing conditions above, because the line is fine and it is where product teams get into trouble. Displaying execution routes and letting the user pick one sits inside. Taking the order and routing it yourself does not.
Stablecoins are named alongside funds and securities in the custody carve-out, so a balance you hold on a user's behalf is a separate problem from a key you hold.
Everything that is not Section 15
The staff's view is expressly limited to the application of Section 15 of the Exchange Act. It therefore says nothing about whether your asset is registered or exempt under the Securities Act, whether your venue arrangements raise exchange or alternative trading system questions, investment adviser status, money transmission and state licensing, AML and sanctions obligations, or any non-US regime.
For most teams, broker-dealer status was one line in a longer risk register. This statement clears one line.
What this changes about how you build
Teams used to ask whether they needed a broker-dealer licence. The statement turns that into a design question: can the user keep the decision while the software stays neutral?
Answering it reaches past the interface. Neutral routing changes your revenue model. Affiliate disclosure reaches your group structure and your contracts with venues. Self-custody changes your recovery flows and your support policy. Two products that look identical in a screenshot can land on opposite sides of this statement because their fee flows and venue relationships differ.
In my experience, teams that unblock US users on the strength of a law firm summary fail on compensation or on interface copy. Both were written into the product long before anyone read the statement, and both get expensive to change once venue contracts are signed. Geo-blocking is no longer the only defensible answer, but unblocking is a structuring decision rather than a switch. And with a five-year clock running, this is a window to build inside rather than a regime to depend on.
Your covered user interface self-assessment
Work through these in order. Each answer changes the next question.
- Are the assets your users transact in securities under US law, or tokenized versions of securities?
- Does your interface hold, access or control user private keys, or any user funds, securities or stablecoins?
- Do you take or route orders, execute, or settle, or do you only prepare a transaction the user signs?
- Does any part of your compensation depend on which venue, route, counterparty or product the user picks, or come from anyone other than the user?
- Does your interface rank, badge or comment on execution routes in any way that is not an objective sort?
- Can users change every default transaction parameter you set, and do you explain how?
- Do you disclose your affiliations with any connected venue, and connect to it on the same terms as anyone else?
- Do you have written policies for onboarding and auditing venues, and for reassessing defaults?
How to read the results. A no to 1 means this statement is not your framework and your live questions sit elsewhere. A yes to 2 or 3 puts you outside it, and the structuring conversation starts there rather than with your interface. A yes to 4 or 5 is usually the quickest thing to fix and the most commonly missed. A no to 6, 7 or 8 is a build backlog.
Conclusion about covered user interfaces
The lane the staff described is narrow, conditional and temporary, and it covers one section of one statute. Within it, the specification is unusually concrete, which is what makes it worth acting on.
The teams that benefit will be the ones treating the twelve circumstances as product requirements now. Fee agnosticism, route neutrality, disclosure and self-custody are cheap to design in and expensive to retrofit once you have users and venue contracts.
That is the kind of cross-border structuring problem Legal Nodes is built to solve. Through a single point of contact, we help founders classify their assets, map their transaction and fee flows against the measures the staff set out, and align the corporate structure, venue agreements and interface disclosures before a US launch. If you are building a wallet, a DeFi front end, or a tokenized real-world asset platform, get in touch to pressure-test your architecture against this statement.
Disclaimer: the information in this article is provided for informational purposes only. You should not construe any such information as legal, tax, investment, trading, financial, or other advice.
