CFTC No-Action Relief for Passive Trading Software Providers
The Commodity Futures Trading Commission has issued a broad no-action position shielding passive software providers from introducing broker registration requirements, a move that directly reshapes the compliance calculus for any firm whose crypto accounting software, wallet application, or DeFi-adjacent tool routes users to regulated derivatives venues. For accounting firms advising clients who build or operate such tools, understanding where this relief starts and stops is no longer optional.
What the CFTC's No-Action Position Actually Says
The agency's Market Participants Division confirmed on 17 September 2026 that it will not recommend enforcement action against qualifying "passive software" providers, or their personnel, for failing to register as introducing brokers (IBs) or associated persons (APs) when their software connects users to CFTC-registered firms and exchanges.
That is a meaningful carve-out. Under the Commodity Exchange Act, any entity that solicits or accepts orders for futures or derivatives on behalf of another is ordinarily required to register as an introducing broker. Registration brings with it capital requirements, ongoing supervisory obligations, and NFA membership dues. For a software team whose product merely routes a click through to a registered counterparty, those obligations have long felt disproportionate and, in practice, legally ambiguous.
The Phantom Precedent and How Thursday's Action Expands It
The CFTC had previously extended a targeted no-action letter to Phantom Technologies in March, covering that firm's self-custodial crypto wallet software under specific conditions. Thursday's position generalises that relief to a wider class of providers rather than leaving every applicant to seek its own individual letter. The Phantom letter itself followed a joint petition in July by Phantom and the Hyperliquid Policy Center asking the CFTC to formally shield non-custodial wallet providers from IB registration and to clarify how existing rules apply to blockchain developers and regulated derivatives firms using on-chain infrastructure.
Core Qualifying Conditions
Relief is not unconditional. Providers must satisfy conditions that limit their functional role in transactions. The most operationally significant restriction is the prohibition on exercising discretion over users' orders. A tool that simply presents a venue, communicates an order, and executes what the user instructs can qualify. One that modifies order parameters, holds funds, selects venues on the user's behalf, or manages positions likely cannot.
Accounting and compliance teams should treat each of these conditions as a binary test when reviewing a client's software architecture, because the relief evaporates the moment any condition is breached.
Scope: Perpetual Contracts, Prediction Markets, and DeFi Connections
The CFTC specifically named perpetual contracts and prediction markets as product types where this relief can apply. Both categories have occupied a grey zone in US derivatives regulation for years. Perpetuals, which have no expiry date and are settled continuously through a funding rate mechanism, are the dominant instrument on most offshore crypto derivatives platforms. Prediction markets have attracted renewed attention following the mainstreaming of event-contract platforms.
For a crypto wallet or DeFi aggregator that wants to surface access to these products through a registered US counterparty, Thursday's position removes a significant barrier. Provided the software stays passive, the developer does not need to join the NFA roster, post capital, or build out the compliance infrastructure of an IB.
What "Passive" Means in Practice
The word "passive" is doing a great deal of legal work here. Advisers should help clients map their software's behaviour against at least these dimensions:
- Order discretion: does the software ever alter the size, price, or timing of an order without explicit user instruction?
- Custody: does the software ever hold or commingle user funds, even temporarily?
- Solicitation: does the software present comparative recommendations that could be construed as soliciting a particular trade rather than simply facilitating a user-initiated one?
- Counterparty selection: does the software route to multiple venues and choose among them on the user's behalf?
A clean "no" across all four dimensions is the target. Any "yes" warrants a closer look at whether the relief applies and, if not, whether IB registration is required.
Regulatory Context: The Post-CLARITY Act Environment
The timing of this no-action position is not coincidental. Two days earlier, a Senate cloture vote on the CLARITY Act received 49 votes, well short of the 60 needed to advance to debate. Following that vote, CFTC Chair Michael Selig and SEC Chair Paul Atkins both signalled publicly that their agencies would press ahead on crypto regulation using existing authority rather than waiting for legislative clarity.
Selig posted on X that the CFTC is "locked in and ready to ship its rules for the new frontier of finance," while Atkins stated the SEC would act "with or without legislation" to provide regulatory certainty for digital assets. Thursday's no-action position and a concurrent SEC sandbox approval for limited on-chain trading of tokenised US equities through permissioned automated market makers represent the first concrete follow-through on those statements.
For firms that had been deferring compliance decisions pending the CLARITY Act, this sequence should close the loop: agency-level rulemaking and no-action guidance are now the operative framework, not legislative hope. Our earlier analysis of how the CLARITY Act's failure shifts compliance responsibility to the CFTC and SEC remains the relevant context here.
Accounting and Audit Implications for B2B Firms
Client Classification and Revenue Recognition
For accounting firms serving software developers or wallet providers, the first question is how to classify the entity and its revenue streams once it operates under this no-action relief. A passive software provider that does not register as an IB is not earning introducing commissions in the regulatory sense. However, if it receives any form of payment tied to order flow, trading volume, or referral fees from the registered counterparty, those amounts need careful classification.
Under US GAAP (ASC 606), the performance obligation question is whether the provider is acting as an agent (passing through a user to a venue) or as a principal (controlling the service before it is transferred). The passive-software criteria map reasonably well onto the agent determination: no discretion, no custody, no counterparty risk. Firms should document this analysis contemporaneously rather than reconstructing it at audit.
Disclosure and Going-Concern Considerations
Any client that has been operating in this space without registering as an IB, pending regulatory clarity, may have had contingent liability disclosures in prior-period financials. With the no-action position now in place, those disclosures may need updating, provided the client can demonstrate it meets the qualifying conditions. Auditors should review whether the conditions are met in substance, not merely in name, before agreeing to remove or modify prior contingency language.
Digital Asset Accounting Software and Record-Keeping
Passive software providers connecting users to regulated derivatives venues will generate transaction data that feeds directly into their users' books. Firms advising CFOs or finance teams at companies that trade perpetuals or event contracts through such tools need to ensure their digital asset accounting software captures the full economics: notional exposure, realised and unrealised gains and losses, funding payments, and any fee rebates. The no-action position does not change the underlying accounting for the trades themselves, only the regulatory classification of the intermediary.
AML and KYC Obligations
One area the no-action position does not address is Bank Secrecy Act compliance. An entity that qualifies for IB registration relief under the Commodity Exchange Act does not thereby escape FinCEN obligations if it falls within the definition of a money services business or is otherwise subject to AML programme requirements. Firms should advise clients not to read this relief as a broader regulatory green light. The IB question and the AML question run on separate tracks.
What CFOs and Finance Teams Should Do Now
If your firm develops, operates, or relies on software that routes users to regulated crypto derivatives venues, the following steps reflect the immediate practical response to Thursday's position.
Conduct a Conditions Audit
Map every function of the software against the CFTC's qualifying conditions. Document the analysis formally. If any function falls outside the passive-software criteria, either remediate the function or seek separate legal advice on IB registration. Do not assume the relief applies without a documented review.
Update Internal Controls and Disclosures
Finance teams should work with legal and compliance to update any existing disclosures about IB registration risk in financial statements or investor communications. Where prior periods carried contingent liabilities related to this question, assess whether those liabilities can now be derecognised, with appropriate audit support.
Review Revenue Recognition Policies
If the firm receives volume-linked or referral-linked payments from registered venues, revisit the agent versus principal determination under ASC 606. Ensure the classification is consistent with the passive-software characterisation the firm is relying on for regulatory relief.
Do Not Conflate This Relief with Broader Deregulation
The no-action position is specific to the IB registration question under the Commodity Exchange Act. It does not address securities laws, FinCEN obligations, state money transmitter licences, or any non-US jurisdiction. The SEC's concurrent sandbox approval for tokenised equities operates under a separate framework entirely. Firms operating across both derivatives and securities-adjacent products need to map each product line to the correct regulatory track. Our coverage of what the CLARITY Act's Senate defeat means for firms navigating SEC and CFTC jurisdiction remains directly relevant to that question.
Source: Cointelegraph
Frequently Asked Questions
Does the CFTC's no-action position mean passive software providers are permanently exempt from IB registration?
No. A no-action position means the agency's staff will not recommend enforcement against qualifying providers under current conditions. It is not a statutory exemption and can be withdrawn or modified. Providers should monitor for any follow-on rulemaking that codifies or narrows the relief.
If our software qualifies as "passive," do we still need to comply with AML and KYC rules?
Potentially yes. The no-action position addresses IB registration under the Commodity Exchange Act only. Separate FinCEN obligations under the Bank Secrecy Act, and any applicable state-level money transmitter requirements, are unaffected. Legal counsel should assess each regulatory track independently.
How should we account for referral or volume-linked payments received from a registered exchange?
Under ASC 606, the key question is whether the software provider acts as an agent or principal. A genuinely passive provider with no discretion, no custody, and no counterparty risk typically points toward agent treatment, meaning revenue is recognised net of any pass-through amounts. Document this analysis thoroughly and have it reviewed at audit.
Do prior-period contingent liability disclosures about IB registration risk need to be restated?
Not restated, but they may need updating in current-period financial statements if the entity can demonstrate it meets the qualifying conditions. Auditors will want to see a documented conditions audit before agreeing to remove or modify prior contingency language.
Does this relief apply to DeFi protocols that use smart contracts rather than traditional software interfaces?
The no-action position references "passive software" broadly, and the CFTC has acknowledged the question of how existing rules apply to blockchain developers using on-chain infrastructure. However, the specific conditions, particularly those around order discretion and custody, may be harder to satisfy for fully autonomous smart contracts. Each protocol's architecture needs individual analysis.