Unusual Options Activity Scanner: What Actually Matters Beyond Volume

Read this article with Options Data API, Options Chain API, Historical Options Data API, Options Volume and Open Interest, Options Flow False Positives, and Option Quote and Trade Conditions.

Product references: Unusual Options Activity Scanner, Option Chain Snapshot docs, Real-Time Options Data API

Abstract

Most unusual options activity scanners are too easy to impress. They sort by raw contract volume, flash a few red and green badges, and imply that every busy option line means informed positioning. In practice, that approach produces too much noise. A contract can print high volume because it is a zero-bid lottery ticket, a routine hedge roll, an earnings-week crowd trade, or a wide-spread line that was never realistically actionable. Volume matters, but volume alone is a weak definition of "unusual."

What matters more is context. How large was the premium that actually changed hands? Was volume large relative to open interest, or was it just a busy contract that is always active? Was the quote tight enough to be tradeable? How short-dated was the contract? Was the line close enough to the underlying to matter, or was it a far-OTM flyer? Those questions are more useful than a simple leaderboard of the day's biggest prints.

This post explains how we think about unusual options activity at CuteMarkets, why the browser scanner is built around a weighted context score rather than a single volume column, what the scanner can detect well, and where you still need quotes and trades to avoid false confidence.

Question

If you want to scan unusual options activity in a way that is actually useful for trading or research, what should you rank beyond raw volume?

My answer is that a practical scanner needs at least five layers:

1. contract volume
2. premium traded
3. volume relative to open interest
4. quote quality
5. time-to-expiration context

And even that is not the whole story. A scanner built from chain snapshots can rank contracts intelligently, but it still cannot fully infer whether flow lifted the ask, hit the bid, or reflected a larger multi-leg structure. The right use case is not "this contract printed, so the market knows something." The right use case is "this contract deserves a second look because it is active in a way that might matter."

Why raw volume fails

The simplest unusual-flow table sorts contracts by day.volume. That is a reasonable first pass, but it breaks in several common cases.

First, raw volume overweights cheap contracts. A contract that trades 20,000 times at 0.03 is not automatically more informative than a contract that trades 1,200 times at 2.40. The first line may represent less capital and less conviction than the second.

Second, raw volume ignores baseline activity. A liquid weekly SPY contract can trade large volume almost every session. That is not unusual. A smaller line that trades 5x its open interest may be much more interesting than a permanently busy front-month contract.

Third, raw volume ignores execution quality. If a contract is quoted 0.10 x 0.25, the scanner should hesitate before treating that line as a clean signal. The print may be real, but the contract is harder to trade and easier to misread.

Fourth, raw volume ignores expiry context. A burst of activity in 0DTE or 1DTE contracts often means something different from the same activity in 45DTE paper. Short-dated contracts concentrate event and gamma behavior. Longer-dated activity often maps more to structure, hedging, or directional positioning.

Finally, raw volume ignores moneyness. Far-OTM contracts can print enough tickets to light up a naive scanner while remaining economically weak. The scanner should let you see when "big volume" is really just cheap optionality attracting attention.

What we rank instead

In the CuteMarkets browser scanner, the contract score is not a magical signal. It is a practical ranking function designed to promote contracts with stronger contextual evidence. The current score uses:

• log-scaled volume
• log-scaled premium
• log-scaled volume/open-interest pressure
• a penalty for wide spreads
• a small boost for shorter-dated contracts
• a boost for contracts with very low open interest that suddenly trade real size

That last piece matters. If open interest is tiny and same-day volume suddenly jumps, the contract may be seeing genuinely new attention rather than just another active day in an already crowded line.

A simplified view of the ranking dimensions looks like this:

This is a ranking system, not a prediction model. It does not claim that a high-scoring contract will outperform. It claims that if you only have time to inspect 20 contracts instead of 2,000, you should prioritize contracts that are busy, meaningful in premium terms, large relative to OI, and not obviously disqualified by poor quote quality.

The minimum fields you need

If you are building your own scanner, you do not need a massive data warehouse to get started. You do need the right fields in one place.

From the chain snapshot, the minimum useful inputs are:

• contract ticker
• contract type
• strike
• expiration date
• latest quote
• latest trade when available
• open interest
• implied volatility
• Greeks when available
• underlying price
• daily volume

That is exactly why chain snapshots are a strong first surface for this problem. They keep contract details, liquidity context, and pricing context together in one payload. In CuteMarkets, the natural starting point is the Option Chain Snapshot endpoint.

A better mental model for "unusual"

When traders say "unusual options activity," they often mean one of four different things:

1. unusually high contract volume
2. unusually large notional premium
3. volume that is large relative to open interest
4. activity concentrated in a specific expiry, strike zone, or directional sleeve

Those are not interchangeable.

Large volume can be routine.

Large premium can still be hedging.

Volume above open interest can suggest new positioning, but it does not prove it.

And aggressive-looking call volume can still be part of a spread or a roll.

A careful scanner should separate "review candidate" from "strong directional conviction." The first is possible from chain context alone. The second usually requires trade tape confirmation, quote behavior, and sometimes even external event context.

What the browser scanner does well

The CuteMarkets Unusual Options Activity Scanner is built for the first job: ranking contracts that deserve inspection.

In practice it is good at:

• surfacing contracts where premium and volume both matter
• highlighting lines where volume exceeds open interest
• penalizing noisy wide-spread contracts
• separating near-dated activity from slower longer-dated flow
• giving enough contract context to decide whether the line looks tradeable

It also tags contracts with small, interpretable labels such as:

• volume > OI
• fresh interest
• large premium
• tight quote
• 0-2DTE
• weekly
• far OTM

Those tags tell you why the line ranked well. A serious scanner needs more than a number. It should explain what kind of unusualness it thinks it found.

What it still cannot prove

There is one limitation worth stating directly. A chain snapshot cannot fully tell you whether the flow was aggressive.

If you only know the latest quote, the latest trade, and the daily totals, you still do not know with certainty whether:

• the trade lifted the ask
• the trade hit the bid
• the print was part of a larger spread
• the order was opening or closing
• the activity was speculative or hedging

This is why unusual-flow scanners are useful but dangerous when oversold. They are discovery tools, not omniscient interpretation engines.

If you want stronger execution-side confirmation, move from chain snapshots into quotes and trades. The chain tells you where to look. The tape tells you more about how the flow actually interacted with the market.

A simple Python example

This compact example pulls one expiration from the CuteMarkets option chain, computes a context-aware score, and ranks contracts by something more useful than raw volume.

import math
import requests

API_KEY = "YOUR_API_KEY"
UNDERLYING = "SPY"
EXPIRY = "2026-05-08"

def quote_price(contract):
    quote = contract.get("last_quote") or {}
    midpoint = quote.get("midpoint")
    if isinstance(midpoint, (int, float)) and midpoint > 0:
        return midpoint

    bid = quote.get("bid")
    ask = quote.get("ask")
    if isinstance(bid, (int, float)) and isinstance(ask, (int, float)) and ask > 0 and ask >= bid:
        return (bid + ask) / 2.0

    last_trade = (contract.get("last_trade") or {}).get("price")
    day_close = (contract.get("day") or {}).get("close")
    fallback = last_trade if isinstance(last_trade, (int, float)) else day_close
    return max(float(fallback or 0), 0.0)

def spread_percent(contract, price):
    quote = contract.get("last_quote") or {}
    bid = quote.get("bid")
    ask = quote.get("ask")
    if not isinstance(bid, (int, float)) or not isinstance(ask, (int, float)):
        return None
    if price <= 0 or ask <= bid:
        return None
    return (ask - bid) / price

def score_contract(volume, open_interest, premium, volume_oi_ratio, spread_pct, dte):
    volume_points = min(28, math.log10(volume + 1) * 7.2)
    premium_points = min(28, math.log10(premium + 1) * 4.6)
    pressure_points = min(26, math.log2(volume_oi_ratio + 1) * 10)
    spread_points = 4 if spread_pct is None else max(0, 10 - spread_pct * 38)
    expiry_points = max(0, 10 - dte / 8)
    empty_oi_boost = 6 if open_interest <= 10 and volume >= 100 else 0
    return round(min(99, volume_points + premium_points + pressure_points + spread_points + expiry_points + empty_oi_boost))

response = requests.get(
    f"https://api.cutemarkets.com/v1/options/chain/{UNDERLYING}/",
    params={
        "expiration_date": EXPIRY,
        "limit": 100,
    },
    headers={"Authorization": f"Bearer {API_KEY}"},
    timeout=30,
)
response.raise_for_status()

rows = []
for contract in response.json().get("results", []):
    details = contract.get("details") or {}
    volume = (contract.get("day") or {}).get("volume") or 0
    open_interest = contract.get("open_interest") or 0
    price = quote_price(contract)
    premium = volume * price * 100
    volume_oi_ratio = volume / max(open_interest, 1)
    dte = 7  # use your own date arithmetic here
    spread_pct = spread_percent(contract, price)

    rows.append({
        "contract": details.get("ticker"),
        "type": details.get("contract_type"),
        "strike": details.get("strike_price"),
        "volume": volume,
        "open_interest": open_interest,
        "premium": premium,
        "volume_oi_ratio": round(volume_oi_ratio, 2),
        "spread_pct": None if spread_pct is None else round(spread_pct * 100, 2),
        "score": score_contract(volume, open_interest, premium, volume_oi_ratio, spread_pct, dte),
    })

rows.sort(key=lambda row: row["score"], reverse=True)

for row in rows[:15]:
    print(row)

This is intentionally simple. It is not a finished production scanner. But it reflects the right principle: inspect contracts using a blend of participation, notional importance, relative pressure, and quote quality rather than by contract count alone.

Common false positives

A scanner becomes more useful when you know what it still gets wrong. The most common false positives are:

Cheap far-OTM lotteries

These often print huge contract counts because the premium is tiny. Raw volume makes them look important. Premium and spread filters usually downgrade them quickly.

Routine front-week crowding

Liquid front-week index and megacap contracts are active almost by default. High volume in those lines may be real but not especially unusual relative to baseline behavior.

Event hedging and rolls

Earnings, macro events, and dealer positioning can create real bursts of activity that are not directional alpha signals. The flow is unusual, but the interpretation is different.

Wide-spread paper

Some lines look dramatic until you inspect the quote. If the contract is too wide to trade sensibly, it should not dominate your scanner just because prints occurred.

Volume above OI without true opening flow

Volume above open interest is a strong clue, not a proof. Intraday OI updates lag. Multi-leg activity also muddies the picture.

How I would actually use the scanner

For live discretionary or semi-systematic work, I would use unusual options activity in a narrow sequence.

First, use the scanner to reduce the search space.

Second, inspect whether the highest-ranked contracts have:

• meaningful premium
• tight enough quotes
• sensible DTE
• moneyness that fits the story

Third, check whether the activity clusters around one strike zone or expiry instead of scattering randomly.

Fourth, confirm with quote and trade context if the contract looks important enough to matter.

Fifth, only then decide whether the flow fits an event, momentum, hedge, or mean-reversion narrative.

This is the right level of respect for unusual options activity. It is a ranking and interpretation problem, not a one-column shortcut to edge.

Takeaway

The main lesson is simple: unusual options activity should be scored, more than counted.

Raw volume is the loudest field in the payload, but not the most informative one. Premium tells you whether capital showed up. Volume versus open interest tells you whether today's flow is large relative to the existing base. Spread quality tells you whether the contract was realistically tradable. DTE tells you whether the activity is immediate or slower-moving. Moneyness tells you whether the scanner is surfacing a serious contract or a cheap flyer.

That is why the CuteMarkets scanner ranks contracts the way it does. The goal is not to tell you what smart money believes. The goal is to tell you which contracts deserve your attention before you move on to quotes, trades, and the actual tape.

If you want to try the browser version first, start with the Unusual Options Activity Scanner. If you want to build your own version, start from the Option Chain Snapshot docs and the Real-Time Options Data API.

Related workflow

For the Unusual Options Activity Scanner: What Actually Matters Beyond Volume workflow, continue through Options Data API, Options Chain API, Historical Options Data API, Options Volume and Open Interest, Options Flow False Positives, and Option Quote and Trade Conditions.

How the terminology applies

For Unusual Options Activity Scanner: What Actually Matters Beyond Volume, the options data workflow should treat Option chain snapshot, Contract snapshot, Volume/OI pressure, Options flow false positive, Scanner artifact, and Historical REST window as operational state rather than glossary decoration. That framing keeps chain selection, contract snapshots, activity filters, quote state, and endpoint access tied to the exact contract the page is discussing.

A developer implementing this Tooling idea should persist Backfill, DTE bucket, Moneyness band, Quote condition, Trade condition, and IV skew beside the result, instead of leaving those words in a term card. It also makes false positives easier to diagnose because a high-activity contract can be separated from a tradable, timestamped, and entitled data object.

The review artifact for Unusual Options Activity Scanner: What Actually Matters Beyond Volume becomes more useful when 0DTE contract, OCC root, Options data API, OPRA-originating data, OCC option symbol, and Bid/ask spread appear in the same body of evidence as the selected rows. When the article moves from concept to implementation, these fields should shape request order, cache boundaries, row labels, and review tables.

In production notes for this options data workflow, Midpoint, Quote/trade condition, Quote vs trade semantics, REST snapshot, WebSocket stream, and Entitlement gate define the checks that decide whether the workflow is reproducible. The result is a scanner or dashboard that explains why a contract was shown, skipped, refreshed, or passed into a downstream research step.

For Unusual Options Activity Scanner: What Actually Matters Beyond Volume, the practical acceptance test is simple: another developer should be able to read the body, identify the exact inputs, reproduce the request sequence, and explain the accepted and rejected rows without relying on the bottom terminology grid. If a phrase appears in the page vocabulary, it should correspond to a stored field, a validation check, a replay step, or an implementation decision in the options data workflow.

This is also the reason the article should not measure success only by the final chart, table, or headline metric. The better standard is whether the data path, timing model, entitlement state, and evidence trail survive review. When those pieces are written directly into the body, the terminology becomes part of the workflow readers can implement.