Why Short Interest Data Is Always Two Weeks Old
Short interest is measured twice a month and published on a lag. The FINRA cycle, the measured delay, what moves while a print is pending, and days to cover.
Short interest data is always old for a structural reason: it is not a live feed. Brokers snapshot the shares held short in their accounts on FINRA-scheduled settlement dates, twice a month, mid-month and month-end, then file those totals with FINRA, which compiles every member firm's report and publishes the aggregate roughly eight business days later. Add the vendor and database hop that gets the file to your screen and the freshest short interest number available on any given day describes positioning as it stood one to four weeks ago. This page measures that gap instead of asserting it.
How the reporting lag actually happens
The cycle has four steps, and each one adds days.
- The settlement date. FINRA publishes a schedule of settlement dates, one mid-month, one at month-end. On each, every broker-dealer records the short positions carried in its customer and firm accounts. These are settlement dates, not trade dates: under T+1 settlement a trade struck on Monday settles Tuesday, so the positions counted on a settlement date are the ones whose trades cleared by then.
- The reporting deadline. Each member firm files its per-security short totals with FINRA within the next couple of business days. Nothing is public at this stage; it is a regulatory filing, not a market data feed.
- Compilation. FINRA sums thousands of firm-level reports for every security and assembles one file: a single number per security per settlement date, no intraday history, no venue detail, no per-firm breakout.
- Dissemination. The file goes public roughly eight business days after the settlement date it describes. Vendors then pull it, exchanges republish it, and data warehouses like the one behind this page ingest it.
Nobody is sitting on the number. The delay is the sum of the collection window, the compilation window, and the distribution hop, every step a batch process on a calendar, not a stream.
How long is the lag, in measured days?
Here is every settlement date this warehouse received as a live, incremental delivery, settlement date on one side, the day the rows first appeared here on the other.
The exact SQL behind every number
WITH first_arrival AS (
SELECT settlement_date,
toDate(min(_ingest_time)) AS arrived
FROM global_markets.stocks_short_interest
GROUP BY settlement_date
),
bulk_days AS (
SELECT arrived
FROM first_arrival
GROUP BY arrived
HAVING count() > 5
)
SELECT settlement_date,
toString(arrived) AS arrived_here,
dateDiff('day', settlement_date, arrived) AS publication_lag_days
FROM first_arrival
WHERE arrived NOT IN (SELECT arrived FROM bulk_days)
ORDER BY settlement_dateThe most recent settlement on file, 2026-07-31, arrived here on 2026-08-11, 11 days after the positions it describes were recorded. The one before it took 17 days. Across the whole series the shape is a band, not a constant:
The exact SQL behind every number
WITH first_arrival AS (
SELECT settlement_date,
toDate(min(_ingest_time)) AS arrived
FROM global_markets.stocks_short_interest
GROUP BY settlement_date
),
bulk_days AS (
SELECT arrived
FROM first_arrival
GROUP BY arrived
HAVING count() > 5
),
organic AS (
SELECT settlement_date,
dateDiff('day', settlement_date, arrived) AS lag
FROM first_arrival
WHERE arrived NOT IN (SELECT arrived FROM bulk_days)
)
SELECT count() AS settlements_measured,
min(lag) AS fastest_lag_days,
round(quantileDeterministic(0.5)(lag, cityHash64(settlement_date)), 1) AS median_lag_days,
max(lag) AS slowest_lag_days,
(SELECT count() FROM first_arrival WHERE arrived IN (SELECT arrived FROM bulk_days)) AS settlements_bulk_loaded,
(SELECT toString(max(arrived)) FROM bulk_days) AS bulk_load_date
FROM organicOver 10 incrementally-delivered settlements, the fastest print landed 10 days after its settlement date and the slowest took 26 days; the median is 14 days, the "two weeks old" of the title, measured rather than assumed.
Note what those queries exclude. A warehouse's history is not a record of publication speed: on 2026-03-16 this database loaded 197 settlements at once, in a single backfill of the archive. Ingest timestamps on those rows date the backfill, not the disclosure, and any "lag" computed from them is an artifact of our loading schedule. Only settlements that arrived one at a time, after the archive was in place, measure the real pipeline, those are the rows above.
Where the cycle stands today
The lag is easiest to see in the gap itself: at any moment there is a settlement date that has already happened and has not yet been published. This panel is the live receipt.
The exact SQL behind every number
WITH (SELECT max(settlement_date) FROM global_markets.stocks_short_interest) AS latest
SELECT toString(latest) AS latest_settlement_on_file,
(SELECT count() FROM global_markets.stocks_short_interest
WHERE settlement_date = latest) AS securities_in_that_print,
(SELECT dateDiff('day', latest, toDate(min(_ingest_time))) FROM global_markets.stocks_short_interest
WHERE settlement_date = latest) AS its_publication_lag_days,
(SELECT count() FROM global_markets.stocks_short_interest
WHERE settlement_date > latest AND settlement_date <= latest + 16) AS next_settlement_rows_on_file,
(SELECT count(DISTINCT date) FROM global_markets.stocks_short_volume
WHERE date > latest) AS daily_short_volume_files_since,
(SELECT dateDiff('day', latest, max(date)) FROM global_markets.stocks_short_volume) AS days_from_settlement_to_newest_daily_fileThe newest short interest print on file is the 2026-07-31 settlement, covering 22339 securities and delivered 11 days after the fact. The next settlement in the cycle shows 0 rows: it has not been published, and at the lags measured above that is entirely normal. That column is bounded to zero on purpose. When the print lands, the bound trips and this page is held for an update rather than quietly serving a stale sentence, the same tripwire the June recap carried inline, one cycle on.
Meanwhile the daily short-volume file has published 10 times since that settlement date, its freshest day 14 days newer than the newest short interest snapshot. Two FINRA datasets, two different clocks.
What moves while the print is in the pipeline
The lag is only interesting if prices move inside it. They do. This panel takes the latest settlement, then measures each name's regular-session close on the settlement date against its close on the day the file actually arrived.
The exact SQL behind every number
WITH latest AS (SELECT max(settlement_date) AS d FROM global_markets.stocks_short_interest),
arrived AS (
SELECT toDate(min(_ingest_time)) AS a
FROM global_markets.stocks_short_interest
WHERE settlement_date = (SELECT d FROM latest)
),
daily AS (
SELECT ticker,
toDate(toTimeZone(window_start, 'America/New_York')) AS session,
argMax(toFloat64(close), window_start) AS rth_close
FROM global_markets.delayed_stocks_minute_aggs
WHERE ticker IN ('AAPL', 'TSLA', 'NVDA', 'GME', 'MU')
AND toDate(toTimeZone(window_start, 'America/New_York')) >= (SELECT d FROM latest)
AND toDate(toTimeZone(window_start, 'America/New_York')) <= (SELECT a FROM arrived)
AND toHour(toTimeZone(window_start, 'America/New_York')) * 60
+ toMinute(toTimeZone(window_start, 'America/New_York')) BETWEEN 570 AND 959
GROUP BY ticker, session
)
SELECT si.ticker AS ticker,
round(si.short_interest / 1e6, 1) AS shares_short_m,
round(argMin(d.rth_close, d.session), 2) AS close_at_settlement,
round(argMax(d.rth_close, d.session), 2) AS close_when_published,
round((argMax(d.rth_close, d.session) / argMin(d.rth_close, d.session) - 1) * 100, 1) AS move_while_pending_pct,
count() AS sessions_in_window
FROM global_markets.stocks_short_interest AS si
INNER JOIN daily AS d ON d.ticker = si.ticker
WHERE si.settlement_date = (SELECT d FROM latest)
GROUP BY si.ticker, si.short_interest
ORDER BY abs(move_while_pending_pct) DESC, si.ticker ASCThe window ran 8 trading sessions. The widest mover of the five was GME, which went from $21.72 at the settlement close to $18.83 on the day its short interest print became available, a -13.3% change over a period in which the disclosed short position was, by definition, frozen at 53.7 million shares. The narrowest, AAPL, still moved -1.3%.
That is the practical content of the lag. Any headline reporting "short interest in X" describes the position at the last settlement, everything in the window above is invisible to it. Shorts may have covered into strength or added into weakness; the number cannot say, and will not say until the next print.
Days to cover, worked out with a stale numerator
Days to cover, shares short divided by average daily volume, is the ratio most readers actually meet, and it inherits the staleness twice over: a numerator fixed at the settlement date, and a volume denominator the file itself computed weeks ago. GameStop is the clearest case, since it is both a household name and one of the more crowded liquid tickers.
The exact SQL behind every number
WITH latest AS (SELECT max(settlement_date) AS d FROM global_markets.stocks_short_interest),
arrived AS (
SELECT toDate(min(_ingest_time)) AS a
FROM global_markets.stocks_short_interest
WHERE settlement_date = (SELECT d FROM latest)
),
tape AS (
SELECT count(DISTINCT toDate(toTimeZone(window_start, 'America/New_York'))) AS sessions,
sum(toFloat64(volume)) AS shares
FROM global_markets.delayed_stocks_minute_aggs
WHERE ticker = 'GME'
AND toDate(toTimeZone(window_start, 'America/New_York')) > (SELECT d FROM latest)
AND toDate(toTimeZone(window_start, 'America/New_York')) <= (SELECT a FROM arrived)
AND toHour(toTimeZone(window_start, 'America/New_York')) * 60
+ toMinute(toTimeZone(window_start, 'America/New_York')) BETWEEN 570 AND 959
)
SELECT toString((SELECT d FROM latest)) AS settlement,
round(si.short_interest / 1e6, 1) AS shares_short_m,
round(si.avg_daily_volume / 1e6, 2) AS file_adv_m,
round(si.days_to_cover, 2) AS reported_days_to_cover,
round(tape.shares / tape.sessions / 1e6, 2) AS tape_adv_since_settlement_m,
round(si.short_interest / (tape.shares / tape.sessions), 2) AS days_to_cover_on_recent_volume,
round(abs(si.short_interest / (tape.shares / tape.sessions) - si.days_to_cover), 2) AS days_of_difference,
tape.sessions AS sessions_measured
FROM global_markets.stocks_short_interest AS si, tape
WHERE si.ticker = 'GME'
AND si.settlement_date = (SELECT d FROM latest)Read the row left to right. At the 2026-07-31 settlement, GameStop carried 53.7 million shares short. The file pairs that with an average daily volume of 3.15 million shares and reports 17.06 days to cover, the number a screener shows you.
Now swap the denominator for reality. Over the 7 regular sessions that traded while the print was still in the pipeline, GameStop averaged 10.99 million shares a day on the consolidated tape. The same short position over that volume works out to 4.89 days, 12.17 days from the published ratio, numerator held identical. Only the volume assumption changed. Treat days to cover as a dated ratio built from two dated inputs, not a live measure of how long an exit would take.
Short squeezes: where the lag actually bites
The reason most people search this question at all is the squeeze. In a squeeze the short position is the story, and it is exactly the quantity nobody can see in real time. GameStop in early 2021 is the textbook illustration. The columns below mark each settlement's regular-session close and the close eight trading sessions later, standing in for FINRA's roughly-eight-business-day dissemination target.
The exact SQL behind every number
WITH daily AS (
SELECT toDate(toTimeZone(window_start, 'America/New_York')) AS session,
argMax(toFloat64(close), window_start) AS cl
FROM global_markets.delayed_stocks_minute_aggs
WHERE ticker = 'GME'
AND window_start >= toDateTime('2020-12-01 00:00:00')
AND window_start < toDateTime('2021-03-15 00:00:00')
AND toHour(toTimeZone(window_start, 'America/New_York')) * 60
+ toMinute(toTimeZone(window_start, 'America/New_York')) BETWEEN 570 AND 959
GROUP BY session
),
ranked AS (
SELECT session, cl, row_number() OVER (ORDER BY session) AS n
FROM daily
)
SELECT toString(si.settlement_date) AS settlement,
round(si.short_interest / 1e6, 1) AS shares_short_m,
round(r0.cl, 2) AS close_at_settlement,
round(r8.cl, 2) AS close_8_sessions_later,
round((r8.cl / r0.cl - 1) * 100, 1) AS move_while_pending_pct
FROM global_markets.stocks_short_interest AS si
INNER JOIN ranked AS r0 ON r0.session = si.settlement_date
INNER JOIN ranked AS r8 ON r8.n = r0.n + 8
WHERE si.ticker = 'GME'
AND si.settlement_date >= toDate('2020-12-15')
AND si.settlement_date <= toDate('2021-02-26')
ORDER BY si.settlement_dateFollow the 2021-01-15 settlement. It recorded 61.8 million shares short with the stock at $35.49. Eight sessions later, around when a print like that reaches the public, GameStop closed at $197.44, a 456.3% move. Anyone reading that short interest figure on its publication day was reading a description of a stock that no longer existed at that price.
The next print inverts the trap. The 2021-01-29 settlement recorded 21.4 million shares short, most of the position gone, with the stock at $328.24. By eight sessions later it was $51.19, -84.4%. The covering had already happened before the file that showed it was public. Both halves of the squeeze, the crowding and the unwind, were disclosed after the fact.
The daily cousin, and what it does not tell you
FINRA does publish something daily: short volume, the share of a day's reported volume marked as short-sale executions, out the next morning. It is near-real-time, and it is a different measurement. Short volume counts trading flow, much of it market-maker hedging that is flat by the close, not positions held. A stock can print heavy short volume every day for a week while its short interest goes nowhere. The difference between the two datasets is the difference between the traffic on a road and the cars parked at the end of it; both files are described here in detail.
There is no daily disclosed short interest number in the US. Vendors sell daily estimates modelled from securities-lending and flow data; they are models, not disclosures. The disclosed figure exists twice a month, and it arrives late.
FAQ
Why is short interest data two weeks old?
Brokers snapshot short positions only on FINRA's twice-monthly settlement dates, file the totals a couple of business days later, and FINRA disseminates the compiled file roughly eight business days after the settlement date. Across the settlements this database received as live deliveries, the full pipeline ran 10 to 26 days, with a median of 14 days.
How is short interest calculated and reported by brokers?
Each broker-dealer counts the shares held short in its customer and firm accounts as of the settlement date, aggregates them per security, and files that total with FINRA. FINRA sums the reports from all member firms into one number per security, 22339 of them in the 2026-07-31 print. It is a regulatory tally of positions, not a count of trades.
Is the reporting cycle different for NYSE, Nasdaq or OTC stocks?
No. The same twice-monthly settlement schedule and the same compilation-and-dissemination cycle apply across US listing venues, and the exchanges republish from the FINRA file rather than producing their own count. A stock's listing venue changes nothing about how old its short interest number is.
What is a good or bad short interest percentage?
There is no threshold that makes a stock a good or bad holding, and a high reading is not a forecast. What crowding measures do describe is how large a short position is relative to the stock's tradable volume: GameStop's latest print carries 17.06 reported days to cover, versus low single digits for most liquid names, see the current crowding leaders for the distribution.
Does the reporting lag matter for short squeezes?
It is where the lag matters most. In the 2021-01-15 GameStop settlement, the stock moved 456.3% between measurement and the eight-session mark that approximates publication, and by the 2021-01-29 print the short position had already fallen to 21.4 million shares. Squeeze crowding is confirmed in public data only after the event.
Every panel above ships with the SQL that produced it, expand any one to audit the numbers, or run the settlement calendar on the Strasmore terminal.