SEC and CFTC Derivatives Definitions Review (2026): What the New Request for Comment Means for Crypto Perps, Swaps, and Builders

SEC and CFTC Derivatives Definitions Review (2026): What the New Request for Comment Means for Crypto Perps, Swaps, and Builders

On June 18, 2026, the SEC and CFTC opened a joint request for public comment on whether the core Title VII derivatives definitions still fit today’s products. If you build or See stablecoin compliance architecture for more.

operate crypto-linked derivatives, this matters because definitional lines determine which rulebook you inherit, which registrations you may need, and how you design custody, See Stablecoin Payments and Onchain RWAs for more.

margin, and reporting. Official release: https://www.sec.gov/newsroom/press-releases/2026-57-sec-cftc-seek-public-comment-further-clarify-harmonize-derivatives-product- See CLARITY Act for more.

definitions See $500B Opportunity for more.

Key Takeaways - The agencies are revisiting swap, security-based swap, and mixed swap definitions, plus how to treat emerging products. - Comments are due 60 days after

Federal Register publication, so teams should treat this as a near-term compliance planning window. - Builders can reduce risk now by designing product modules that can map to

either SEC or CFTC regimes without a full rebuild.

What did the SEC and CFTC actually announce?

The SEC and CFTC said they issued a joint request for comment to update, clarify, and harmonize derivatives product definitions and interpretive issues under Title VII of

Dodd-Frank. They called out definitional boundaries for swaps and security-based swaps, exclusions from the swap definition, treatment of mixed swaps, treatment of novel or

emerging products, and potential alternative compliance. The public comment period remains open for 60 days after publication in the Federal Register. Press release:

https://www.sec.gov/newsroom/press-releases/2026-57-sec-cftc-seek-public-comment-further-clarify-harmonize-derivatives-product-definitions Request page (S7-2026-21):

https://www.sec.gov/rules-regulations/2026/06/s7-2026-21 Quote for context (SEC Chair Paul S. Atkins): Clarification is long overdue on Title VII definitional issues,

including event-based products. Quote for context (CFTC Chair Michael S. Selig): Today’s joint request for public comment presents an opportunity to address longstanding

ambiguities within Title VII of Dodd-Frank that have stifled fair competition and responsible innovation.

Why definitions matter more than headlines for crypto derivatives

In crypto, teams argue whether a product is a perp, a futures contract, or a swap like it’s a branding exercise. Regulators care about economic exposure and legal categories because those categories trigger registration, business conduct standards, reporting, and who you can legally onboard. That is why a definitional harmonization effort can move faster than a full market-structure law while still changing how products get built. If you are building on top of stablecoin collateral and tokenized Treasurys, think of this as the derivatives version of reserve rules. It sets the compliance envelope around your product.

The practical builder question: where do crypto perps and synthetic exposures land?

Perpetual futures products are not a single thing. A perp can behave like a futures contract on a venue, a swap-like bilateral instrument, or a security-based swap if the

underlying exposure resembles a single security or narrow index. The request’s focus on novel or emerging products signals that the agencies want help drawing clearer lines

for instruments that did not exist, or did not scale, when Title VII was implemented. Assume that a ‘crypto perp’ label will not protect you. Your margin model, settlement

design, oracle design, and participant access controls are what will get scrutinized. If you build perps: document your economic exposure, define your customer eligibility

rules, and be ready to explain why your product belongs on one side of the line. Primary source for scope: https://www.sec.gov/newsroom/press-releases/2026-57-sec-cftc-seek-

public-comment-further-clarify-harmonize-derivatives-product-definitions

What ‘alternative compliance’ could mean for infrastructure teams

The agencies also asked about alternative compliance approaches. That phrase can reduce real costs if it allows one regime’s controls to satisfy the other for economically

identical risk. For builders, the implication is architectural: keep a canonical internal ledger of fills, positions, margin, and collateral events, then translate that ledger

into regulator-facing outputs. Do not hard-code one regulator’s fields directly into your internal data model. That is how teams end up stuck. A simple implementation is to

store normalized events, then implement export adapters that map to swap-style reporting or securities-style reporting. Official request page: https://www.sec.gov/rules-

regulations/2026/06/s7-2026-21

Reserve rules, tokenized T-bills, and why the stablecoin piece still connects

Even though this RFC is about derivatives definitions, it collides with the stablecoin story in a simple way: stablecoins and tokenized Treasurys are becoming the base

collateral layer. As collateral becomes more standardized, product innovators can ship new derivatives faster. That is exactly when regulators revisit definitional boundaries.

Galaxy’s analysis is one example of why front-end Treasury demand and collateral plumbing now matter for market design. Galaxy report URL:

https://www.galaxy.com/insights/research/stablecoins-genius-act-bank-deposit-flight-us-dollar-dominance

A compliance-first architecture checklist for builders in 2026

Here is a builder-oriented checklist you can implement without waiting for a final rule: 1) Classification switch: design the product so you can flip between ‘swap-like’ and

‘futures-like’ compliance assumptions without refactoring the entire stack. 2) Participant gating: restrict by geography and customer type at the account and order-routing

layers. 3) Margin and liquidation transparency: log every margin call and liquidation trigger with an audit trail you can export. 4) Oracle hardening: document oracle sources,

circuit breakers, and the process for emergency parameter changes. 5) Reporting readiness: model trades, positions, and valuations so they can feed either swap data reporting

or securities-style reporting. 6) Sanctions and AML: treat screening as a default, not an add-on, even for non-custodial designs. 7) Incident response: have a playbook for

forced pauses, settlement halts, and error corrections.

What to submit in a public comment if you run a derivatives product

If you operate a derivatives venue or build the middleware behind one, do not send a generic letter. Submit concrete examples of instruments that fall into a gray zone, plus a

test that produces predictable outcomes. A productive comment usually includes: (1) an example term sheet, (2) how counterparties interact, (3) settlement mechanics, (4)

collateral and margin approach, and (5) where the current definition breaks. If you are a DeFi team, you can still contribute by describing how smart contracts implement

economic exposure and whether any party is acting like a dealer. Start from the official file page: https://www.sec.gov/rules-regulations/2026/06/s7-2026-21

The operational impact: registrations, reporting, and counterparty eligibility

Definitional lines are expensive because they touch everything: who can trade, what disclosures you need, how you handle conflicts, and what gets reported. If your product

could plausibly move between categories, plan for a future where you may need tighter onboarding and more formal disclosures. That does not mean you need to stop building. It

means you should separate product logic from compliance and distribution layers. Teams that bundle everything into one monolith are the ones who get stuck doing rewrites under

time pressure.

A simple mental model: three layers that decide your regulatory surface area

When people argue whether a crypto perp is a futures contract or a swap, they are really arguing about three layers. Layer 1 is the reference exposure: broad commodity-like

exposure, a narrow basket, or a single security-like return. Layer 2 is the trading model: standardized order book, RFQ, or bilateral negotiation. Layer 3 is settlement and

margin: how collateral is posted, how variation margin is calculated, and how liquidation is handled. Build those layers as modules and you can change posture without

rewriting the business.

Concrete example: designing a perp engine that can survive a classification shift

Imagine you run a perp engine with cross-margin across spot and derivatives. If classification changes, you do not want a rewrite. Split the system into three stable modules:

account and eligibility, risk engine, and reporting. Account and eligibility should own: KYC status, jurisdiction rules, customer type, and feature entitlements. Risk should

own: pricing inputs, margin schedules, liquidation thresholds, and circuit breakers. Reporting should own: immutable trade IDs, position snapshots, valuation methodology, and

export adapters. When the rulebook changes, you swap the reporting adapter and tighten the eligibility rules first. You do not touch the matching engine.

Concrete example: tokenized Treasurys as collateral and the hidden interest-rate risk

Tokenized Treasurys feel like cash, but they embed duration, liquidity, and settlement assumptions. If your margin engine treats them as cash-equivalent, define haircuts that

can widen in stress and document when and how haircuts change. If your collateral is a tokenized fund share, define what happens on redemption delays or transfer restrictions.

Collateral policy shapes liquidation behavior. Liquidation behavior shapes whether your product resembles a standardized venue or a bilateral desk.

Where Autheo fits: neutral rails for compliant onchain finance

Autheo’s goal is to give builders a neutral infrastructure layer that can support compliant onchain products, including applications that need clear audit trails, identity

hooks, and predictable execution. Autheo is not a DAO, and THEO is a utility token used for network functions like staking, compute, storage, AI inference, fees, and identity.

If you want a quick on-ramp, start with the big-picture infrastructure thesis and then the practical developer content. CTA: https://autheo.com

A builder’s next 30 days plan

Week 1: inventory your product surfaces. List every user path that creates exposure: opening a position, topping up margin, withdrawing collateral, and settling PnL. Week 2:

map your data model. Confirm you can reconstruct every position state at any time using immutable events. Week 3: add export adapters. Even if you do not file reports today,

make sure you can emit consistent CSV or JSON outputs for audits. Week 4: write a one-page classification memo. It should state what the product is, what it is not, and which

assumptions would change if regulators classify it differently. This work is boring, but it is cheaper than doing it while you are under enforcement or under a partner’s due

diligence review.