The Broker Is Becoming an API - New Path for Developers
Updated: 12 hours ago
CFTC Opens a New Path for Developers to Build on Regulated Derivatives Markets
MARKET STRUCTURE | SOFTWARE | DERIVATIVES
The CFTC Is Drawing a New Boundary Between Financial Software and Financial Intermediation
A new staff letter gives qualifying developers a path to build wallets, trading interfaces, market aggregators and other applications that connect users to regulated derivatives markets without automatically registering as introducing brokers. The opportunity is substantial — but so are the boundaries.
September 17, 2026
For decades, accessing a regulated derivatives market generally meant entering through a recognizable piece of financial infrastructure.
A futures commission merchant held the customer relationship.
An introducing broker solicited or referred business.
An exchange operated the market.
A clearing organization stood behind settlement.
Software existed throughout the system, but it was usually treated as infrastructure supporting the intermediary rather than as an independent distribution layer.
That distinction is beginning to change.
On September 17, the Commodity Futures Trading Commission’s Market Participants Division issued Staff Letter 26-25, establishing a broadly available no-action position for qualifying providers of what the agency calls “passive software.”
Under specified conditions, CFTC staff says it will not recommend enforcement action against those software providers — or relevant personnel — for failing to register as introducing brokers or associated persons solely because they provide and market software that facilitates trading with registered futures commission merchants, introducing brokers and designated contract markets.
CFTC announcement: Press Release
CFTC Staff Letter 26-25: Staff Letter 26-25
The language is technical.
The implications are not.
For developers, the letter creates a clearer regulatory pathway for building something increasingly important to modern finance:
The interface between the customer and the regulated market.
A wallet could potentially display regulated derivatives.
A mobile application could surface event contracts.
A financial website could become a market-discovery interface.
A software company could build a trading terminal across one or more regulated venues.
A developer could even receive transaction-based compensation under the structure described by the CFTC.
But there is a defining condition running through the entire framework.
The software must remain software.
It cannot quietly become the broker.
WHEN DOES A TRADING INTERFACE BECOME A FINANCIAL INTERMEDIARY?
This problem did not begin with crypto.
The Commodity Exchange Act broadly defines an introducing broker to include a person who, for compensation or profit, engages in soliciting or accepting certain derivatives orders without taking custody of the property securing those positions.
The CFTC has historically interpreted “soliciting or accepting” broadly.
The concept can extend beyond a person literally taking an order. Referring customers to an intermediary and receiving transaction-based or referral compensation can also create introducing-broker questions.
That framework made sense in a world dominated by brokerage desks, sales representatives and telephone orders.
It becomes harder to apply cleanly when the entity sitting between the customer and the market is software.
Consider a modern financial application.
A user opens a wallet.
The wallet displays a regulated futures contract.
The user reviews the price.
The user enters an amount.
The user presses Buy.
The order is transmitted to a registered market participant.
The software developer never touches the customer’s collateral.
No salesperson calls the customer.
No portfolio manager determines whether the transaction should occur.
Yet the developer may have marketed the product, presented the market, routed the user into the regulated ecosystem and received compensation.
That is the regulatory gray area the CFTC is attempting to address.
FROM PHANTOM TO AN INDUSTRY FRAMEWORK
Staff Letter 26-25 did not appear from nowhere.
On March 17, 2026, the CFTC’s Market Participants Division granted similar no-action relief specifically to Phantom Technologies, developer of the widely used Phantom crypto wallet.
Phantom had asked whether it could provide a front-end interface through which users could access CFTC-regulated derivatives without Phantom itself becoming an introducing broker.
The CFTC agreed, subject to conditions.
CFTC Phantom announcement: Press Release
Phantom described the structure as a non-custodial interface connecting users to registered markets while allowing users to submit orders directly to the regulated partner.
Phantom would not hold customer funds.
Phantom explanation: Explanation
The March letter, however, had an important limitation.
It belonged to Phantom.
Other software developers could not simply point to Phantom’s relief and assume that they were automatically protected.
Staff Letter 26-25 changes that.
The CFTC says it received inquiries from other similarly situated passive software providers and concluded that substantially similar relief should be made available more broadly.
That makes the September action materially more important than the Phantom letter alone.
The framework is no longer centered on one company.
It can potentially apply to a much larger class of developers.
The CFTC also makes clear that the model is not limited to crypto software.
WHAT DEVELOPERS MAY BE ABLE TO BUILD
The activities described in Letter 26-25 provide something close to a blueprint for a new generation of regulated financial applications.
A qualifying provider may develop front-end software through which users can:
Review market data.
Aggregate position information.
Examine available products.
Discover CFTC-regulated derivatives.
Access event contracts.
Access perpetual contracts.
Submit orders directly to registered entities.
The software can operate as a standalone application.
It can also be embedded inside another product, including a wallet.
If CFTC-regulated products are embedded alongside other financial services, the interface must clearly indicate when the customer is engaging in regulated derivatives activity.
That may appear to be a minor interface requirement.
In practice, it represents a potentially major shift in derivatives distribution.
The customer no longer necessarily has to begin at the exchange’s website.
The exchange can become infrastructure underneath another company’s application.
The visible consumer experience could belong to a wallet, a fintech company, a trading terminal, a financial-news platform, a portfolio-management service or a specialized market aggregator.
The regulated market remains underneath.
The customer interface moves somewhere else.
WHY THE FEE LANGUAGE MATTERS
One of the most economically important sections of Letter 26-25 concerns compensation.
The CFTC says a passive software provider may enter into agreements with registered entities that share a specified portion of relevant revenue with the software company.
A provider may also contract directly with users and charge transaction-based fees.
That is significant.
Transaction-linked compensation has historically been one of the factors making introducing-broker analysis especially important.
Earlier CFTC technology-provider interpretations were generally more restrictive.
In a 2008 technology-vendor letter, for example, the analysis relied partly on representations that the provider would not recommend particular intermediaries, would not produce express buy or sell signals and would not receive compensation tied to the economics of futures execution.
Staff Letter 08-12: Staff Letter 08-12
The 2026 framework moves further.
A qualifying passive software provider may potentially:
Market relationships with registered firms.
Promote the availability of particular derivatives.
Introduce users to particular registered entities.
Solicit users to engage with those firms.
Receive transaction-linked compensation.
The user, however, must still be able to access the registered firm independently of the software provider.
That distinction matters.
The developer can become a distribution layer.
The developer is not supposed to become the regulated intermediary itself.
THE NEW FINANCIAL STACK
The traditional derivatives distribution model often looks roughly like this:
Customer
Broker or intermediary
Exchange
Clearing organization
The new model could increasingly look like this:
Customer
Consumer application or wallet
Registered FCM, IB or DCM
Exchange infrastructure
Clearing organization
The software layer becomes the experience.
The registered institution remains responsible for the underlying regulated financial activity.
Letter 26-25 is especially clear about customer assets.
The software provider does not take custody of the property securing the derivatives position.
That property remains with the appropriate regulated derivatives infrastructure, such as a futures commission merchant or derivatives clearing organization.
This separation is fundamental.
The developer controls the interface.
The regulated institution controls the regulated account, execution or market infrastructure.
That may become one of the defining architectural principles of future financial software.
THE LINE DEVELOPERS CANNOT CROSS
The word “passive” does most of the regulatory work in this framework.
The CFTC describes a provider that does not:
Hold customer assets.
Control customer assets.
Take custody of customer assets.
Generate express buy or sell signals.
Exercise discretion over order routing.
Exercise discretion over execution.
That produces a fairly intuitive boundary.
Market discovery may fit.
Charts may fit.
Order-entry interfaces may fit.
Wallet integrations may fit.
Software that transmits a customer-directed order may fit.
But once the software independently decides what the customer should buy, where the order should be sent, or when it should execute, the analysis becomes much more complicated.
That distinction becomes particularly important as artificial intelligence begins entering financial applications.
THE AI AGENT PROBLEM
Consider two applications.
In the first application, a user views a gold perpetual contract.
The user chooses the position size.
The user selects Buy.
The user confirms the order.
The application transmits that instruction.
That resembles the passive architecture contemplated by the CFTC.
Now consider a different system.
A user tells an AI agent:
“Manage my commodity exposure.”
The agent analyzes gold, silver, crude oil and interest rates.
It decides gold provides the best opportunity.
It chooses a contract.
It selects a position size.
It chooses a venue.
It waits for a preferred price.
It executes.
That system may still be software.
But it is no longer obviously passive.
The CFTC’s letter specifically draws boundaries around buy and sell signals, discretionary routing and discretionary execution.
That does not mean autonomous trading agents are prohibited.
It does mean developers should not assume this particular no-action letter protects them.
The larger unresolved question is substantial:
When does software stop transmitting human intent and begin exercising financial discretion of its own?
Letter 26-25 does not fully answer that question.
But it begins drawing the border.
NO REGISTRATION DOES NOT MEAN NO COMPLIANCE
Calling the framework “deregulation” would be misleading.
The CFTC is offering relief from one potential registration obligation while imposing significant conditions around the activity.
Users must receive disclosures concerning relationships between the software provider and participating registered firms.
Potential conflicts of interest, including compensation arrangements, may need to be disclosed.
Relevant risk disclosures must also be delivered and acknowledged unless the applicable regulated entity is already responsible for supplying them.
The software provider must maintain evidence of required acknowledgments.
Marketing is another important area.
Letter 26-25 requires qualifying providers to maintain policies and procedures reasonably designed to comply with relevant CFTC and National Futures Association communication standards as though the provider were a registered introducing broker.
NFA Compliance Rule 2-29 covers promotional communications and prohibits practices including material misstatements, deceptive representations and certain high-pressure sales practices.
NFA Compliance Rule 2-29: Compliance Rule 2-29
For developers, this means compliance reaches beyond the execution engine.
Landing pages matter.
Advertisements matter.
Promotional claims matter.
Affiliate programs matter.
Social media content can matter.
The compliance layer becomes part of the product itself.
THE CONDITION DEVELOPERS MAY UNDERESTIMATE
One of the most consequential requirements appears in Condition Seven of the letter.
The passive software provider and each participating registered entity must enter into a written undertaking concerning liability for violations of the Commodity Exchange Act or CFTC regulations associated with the covered activities.
The parties also consent to CFTC jurisdiction relating to relevant investigations and enforcement.
That changes the commercial incentives.
A registered exchange, FCM or other participating firm has a direct reason to care deeply about the behavior of the software providers connected to it.
The likely result is a much more controlled developer ecosystem than a completely open API marketplace.
Registered partners may require:
Application reviews.
Security standards.
Technical certification.
Marketing approval.
Audit rights.
Data-retention requirements.
Incident-response procedures.
Compliance monitoring.
Contractual restrictions.
The CFTC may be making it easier for developers to connect to regulated derivatives infrastructure.
But the institutions assuming regulatory exposure will probably be selective about which developers receive access.
RECORDKEEPING BECOMES A SOFTWARE REQUIREMENT
Letter 26-25 also requires covered providers to maintain records relating to their regulated business and their compliance with the conditions of the relief.
For developers, that has direct architecture implications.
Applications may need durable records of:
Customer disclosure acceptance.
Terms acknowledgments.
Product presentation.
Transaction initiation.
Partner relationships.
Communications.
Marketing approvals.
User actions.
System events.
The compliance system therefore cannot simply be added after the core product is finished.
The application itself becomes part of the regulatory evidence.
This is an important shift for financial software development.
Logging is no longer only a debugging feature.
It can become a compliance requirement.
WHY WALLETS MATTER
Phantom was a logical starting point because modern wallets are no longer merely storage tools.
They are increasingly financial operating systems.
Users can hold assets.
Swap tokens.
Monitor portfolios.
Access applications.
Trade derivatives.
Use prediction markets.
Interact with decentralized finance.
And increasingly move between blockchain-native and regulated financial products from the same interface.
Phantom’s March relief showed how a wallet could potentially connect users to registered derivatives markets without itself becoming the custodian or traditional broker.
The September expansion suggests that the CFTC is beginning to view that model as something larger than a one-company exception.
The implications could extend far beyond crypto wallets.
A banking application could eventually embed hedging products.
A financial-news platform could become interactive.
A portfolio tracker could add execution.
A commodity platform could connect businesses directly to regulated hedging markets.
A treasury-management application could integrate derivatives into an existing corporate workflow.
The number of potential distribution surfaces for regulated markets could expand dramatically.
THE AGGREGATOR OPPORTUNITY
If multiple registered venues expose markets through programmable infrastructure, another business model becomes possible.
The derivatives aggregator.
Instead of forcing a trader to navigate multiple platforms, an application could organize markets by economic function.
Crypto derivatives.
Commodities.
Interest rates.
Precious metals.
Energy.
Economic event contracts.
Weather contracts.
Prediction markets.
The customer might think primarily about the application.
Underneath it, different products could potentially be supplied by different regulated firms.
This resembles a familiar pattern from other technology industries.
Consumers do not necessarily think about every payment processor sitting beneath a commerce application.
They think about the interface.
Financial developers may increasingly compete on:
User experience.
Research.
Discovery.
Visualization.
Analytics.
Workflow.
Personalization.
Market organization.
Registered institutions underneath them may compete on:
Liquidity.
Execution.
Clearing.
Risk management.
Product design.
Market quality.
That is not yet the structure of the entire derivatives industry.
But Letter 26-25 makes it considerably easier to imagine.
WHAT THE LETTER DOES NOT DO
Staff Letter 26-25 should not be interpreted as a general exemption for decentralized finance.
The framework described by the CFTC assumes users are transacting through registered derivatives infrastructure.
It also assumes customer collateral remains within the appropriate regulated custody and clearing structure.
The letter should therefore not be read as blanket permission for:
Unregistered offshore derivatives markets.
Decentralized perpetual protocols.
Synthetic derivatives.
Tokenized contracts outside the regulated framework.
Software that directly controls customer funds.
Phantom made a similar distinction when describing its own relief.
Its March framework concerned connections to registered market partners, not a wholesale exemption for decentralized derivatives.
The CFTC is opening part of the interface layer.
It is not eliminating the regulated market underneath it.
A TEMPORARY BRIDGE, NOT FINAL LAW
The legal status of Letter 26-25 deserves careful treatment.
This is not legislation.
It is not a final CFTC rule.
It is not a permanent Commission regulation.
It is a staff no-action position.
The Market Participants Division says the relief remains applicable until Commission rulemaking or guidance addressing introducing-broker registration requirements for software developers takes effect.
The Division also makes clear that the letter reflects its own view and does not bind the Commission.
The relief can potentially be modified, suspended, terminated or restricted.
That makes the framework both important and transitional.
The CFTC has effectively constructed a bridge between legacy intermediary regulation and increasingly software-defined financial markets.
The eventual permanent rules may differ.
Developers considering significant capital investment around this architecture should understand that distinction.
THE INDUSTRY RESPONSE
The Blockchain Association described the decision as an important clarification for developers building software that connects users to regulated derivatives markets.
Its CEO, Summer Mersinger, argued that the framework focuses more directly on what a technology provider actually does rather than automatically treating the provider as a conventional financial intermediary.
Blockchain Association statement: Blockchain Association Statement
That interpretation captures an important philosophical shift.
Financial regulation has historically focused heavily on institutional categories.
Broker.
Exchange.
Dealer.
Advisor.
Clearinghouse.
But modern software can blur those categories.
A single application can simultaneously resemble a wallet, market terminal, research product, data service and transaction interface.
Letter 26-25 moves the discussion toward a more functional question:
What is the software actually doing?
If the developer controls assets, exercises trading discretion or becomes directly involved in execution decisions, the regulatory analysis changes.
If the developer remains a passive interface layered over registered institutions, full introducing-broker registration may not always be necessary.
That is a more software-native way of thinking about financial regulation.
MARKETS ARE BECOMING PROGRAMMABLE INFRASTRUCTURE
The importance of Letter 26-25 extends beyond one registration category.
Financial markets are increasingly becoming programmable systems.
Exchanges expose APIs.
Market data moves continuously.
Wallets aggregate assets.
Stablecoins move value outside conventional banking hours.
Perpetual futures remove traditional expiration cycles.
Prediction markets turn information into continuously traded contracts.
AI systems increasingly interpret data and user intent.
The user interface no longer necessarily belongs to the institution operating the underlying market.
That changes where competition occurs.
For decades, exchanges and brokerages competed heavily through proprietary distribution.
The future may be more modular.
A regulated exchange provides the market.
A clearinghouse provides settlement.
An FCM provides account infrastructure.
A market-data provider supplies information.
An independent software company provides the interface through which the customer experiences all of it.
The pieces separate.
The stack becomes more composable.
Competition moves upward.
THE NEXT BATTLE MAY BE OVER THE INTERFACE
The most valuable financial company of the next generation may not need to own every layer underneath the customer.
It may need to own the point at which the customer decides what to do.
That is what makes this otherwise technical CFTC staff letter worth watching.
Letter 26-25 does not abolish financial intermediation.
It begins separating intermediation from interface design.
The distinction matters.
A developer may potentially build the screen.
The developer can organize markets.
The developer can display prices and positions.
The developer can introduce users to regulated venues.
The developer can market particular contracts.
The developer may receive transaction-based revenue.
And the developer can transmit the customer’s instruction.
But once the software begins making the financial decision itself, holding customer property or exercising discretion over execution, the architecture changes.
The CFTC has therefore given developers something more useful than a blanket exemption.
It has begun drawing a map.
One side contains financial software.
The other contains financial intermediation.
For a growing number of developers, the border is becoming easier to see.
PULL QUOTE
“The PSP’s software would serve only to passively enable Users to transact in Commission-regulated derivatives products.”
— CFTC Staff Letter 26-25, September 17, 2026
PULL QUOTE
“Software providers covered by the relief do not custody customer assets, exercise discretion over the routing or execution of orders, [or] generate buy or sell signals.”
— Blockchain Association, September 17, 2026
SOURCE DESK & FURTHER READING
U.S. Commodity Futures Trading Commission
CFTC Staff Issues No-Action Position to Providers of Passive Software
September 17, 2026
U.S. Commodity Futures Trading Commission
Staff Letter 26-25
Primary document establishing the new passive-software framework.
U.S. Commodity Futures Trading Commission
Staff Letter 26-09
The March 2026 Phantom Technologies no-action letter that preceded the broader framework.
Phantom
Phantom Secures CFTC No-Action Relief for Access to Regulated Derivatives and Event Contracts
National Futures Association
Compliance Rule 2-29
Promotional material and communications standards referenced by the CFTC framework.
U.S. Commodity Futures Trading Commission
Staff Letter 08-12
Earlier technology-provider guidance illustrating the historical regulatory treatment of software vendors.
Blockchain Association
Statement on the CFTC No-Action Position for Passive Software Providers
September 17, 2026
EDITORIAL NOTE
Staff Letter 26-25 is a no-action position issued by the CFTC’s Market Participants Division. It is not a Commission rule, does not bind the Commission and may be modified or withdrawn.
Whether a particular application qualifies depends on its specific activities, business relationships and technical architecture.
This article is intended for informational and educational purposes and does not constitute legal, investment or compliance advice.
Comments