CFTC Chairman Michael S. Selig used an October 28, 2026 forum to raise a practical problem for autonomous finance: when software identifies opportunities and executes trades for someone, which people or businesses carry the regulatory responsibilities? His questions covered developer registration, liability when an agent misbehaves, and identification of the party it represents. The remarks opened a policy discussion; they did not assign every AI-related loss to a particular party.
The important change is permission to act
In his Frontier Forum remarks, Selig said the approach should consider the functions performed, control exercised and economic reality of a transaction. He also stated that his views did not necessarily represent the Commission. His proposed “know-your-agent,” or KYA, question was not an announced identification regime.
That distinction matters because “AI trading” describes several different arrangements. A research assistant reading public prices does not have the same authority as a service that selects positions and sends orders without individual approval. A chat interface can make those arrangements look similar while the permissions underneath remain very different.
| Arrangement | What the software can do | What to examine |
|---|---|---|
| Analysis | Read and summarize information | Data quality and access boundaries |
| Recommendation | Suggest an order for human approval | Who reviews the proposal |
| Delegated execution | Submit orders within an authorization | Scope, limits and revocation |
The practical question is therefore what a system is allowed to do, who grants that authority, and who can stop it. The model's name or apparent intelligence answers none of those questions.
Registration and compensation are different questions
Registration concerns whether an activity brings a person or business within a regulatory category. Compensation concerns whether someone has a legal claim for a loss and against whom. A registration question does not, by itself, determine a damages claim; nor does a losing trade establish misconduct.
Consider a hypothetical user who authorizes a maximum $1,000 order, but an agent submits $10,000. An investigation would need to reconstruct the instructions, configured limits, order messages and execution. Was the limit never implemented, changed by an operator, bypassed by a software defect, or misunderstood by the user? Those alternatives describe different facts, rather than a single event called “AI failure.”
The model developer, application operator, account holder and execution provider may be separate parties. Relevant duties, contractual terms, actual conduct and applicable law would need examination. This is an analytical framework, not a ruling that all those parties share liability or that one necessarily owes compensation.
It also explains why publishing general software and operating an ongoing trading service should not automatically be treated as the same business. The service's actual role requires closer attention than its marketing label.
Identifying the agent is only half the task
An agent can have a name, wallet address or software identifier without revealing whose funds it is using or who authorized its actions. Selig's identification question concerns the party represented, including situations involving several agents.
A useful operational record would connect the account, the authorization and the action. If one agent delegates a task to another, the chain should remain understandable: who set the mandate, which permissions were passed along, and whether the second system could expand them. These are practical design considerations; the speech did not prescribe a mandatory KYA form or a universal technical standard.
KTX's explanation of Catalyst and AI-agent execution explores why a user instruction, delegated signing and an actual transaction are separate parts of a workflow. Connecting them is useful for incident review even before a dispute reaches a regulator or court.
A complete trading record is more informative than a persuasive explanation generated afterward. Messages about intended actions should be compared with the orders accepted, canceled and filled.
Existing regulated firms still have obligations
A separate starting point already exists for CFTC-regulated entities. The agency's December 2024 staff advisory on AI use reminds registered entities and registrants to meet applicable requirements when using AI directly or through third-party providers. It discusses areas including oversight, systems safeguards, recordkeeping and risk management.
The advisory is a staff statement about existing requirements, not a new binding AI rule. It does not create a universal allocation of liability between every developer and trader. The continued obligations of a regulated institution and the unresolved treatment of a new agent service should therefore be read as different issues.
Operationally, buying a model does not replace decisions about deployment. Someone still needs to define acceptable actions, monitor whether the system follows them and respond to exceptions. Records should distinguish the intended instruction from the action actually performed, rather than treating an AI-generated summary as the complete history.
What changes for traders and product builders?
Before delegating execution, understand which markets, accounts and actions are accessible. A sensible design can separate observation from trading, restrict order size and exposure, and provide a clear method to suspend further activity. The appropriate controls depend on the product; these examples are not a CFTC compliance checklist.
Developers evaluating integrations can review KTX Skills. Its product description distinguishes public market data, available without an API key, from private trading and account capabilities that require one. That makes access scope a concrete decision, rather than an assumption hidden inside the phrase “AI assistant.”
Automation also leaves the underlying instrument's economics intact. The KTX perpetual-futures guide explains funding and leverage: a system that executes quickly can still accumulate funding costs or reach liquidation thresholds. Successful software operation is not the same as a successful investment.
The next meaningful policy developments would be concrete proposals or guidance clarifying scope, identification and accountability. Until then, product evaluation should focus on documented authority, observable behavior and a workable response when actual trading diverges from the mandate.
Frequently asked questions
Does a profitable backtest establish legal compliance?
No. Historical strategy performance does not establish that the service has the registrations, permissions or operating arrangements required for its activities.
Does read-only access remove every risk?
It limits direct trading authority, but inaccurate analysis, inappropriate data access and mistaken reliance can still matter. Review what information the tool can reach.
Does switching off an agent cancel its existing orders?
Do not assume so. Confirm the status of outstanding orders and positions separately. Preventing new instructions is different from canceling accepted orders or closing exposure.
Does a blockchain record guarantee recovery after an error?
No. A transaction record can help establish what happened; recovery depends on the asset, transaction, counterparties and available legal or technical remedies.
This article explains a policy discussion and is not legal or investment advice. AI systems, automated execution and leveraged products involve operational and financial risk.