Introducing
Mar 5, 2026
TLDR: On February 23, 2026, FINRA's SIPs began reporting fractional share quantities with up to six decimal places. Before this, trades were rounded or truncated to whole numbers. Massive's APIs now expose the new decimal values across WebSocket, REST, and flat file delivery. This post covers what changed, why it matters for anyone building on trade data, and includes a demo that quantifies the impact of the old integer-only reporting on real tickers.
On February 23, 2026, the UTP and CTA SIPs began reporting fractional share quantities for NMS stocks. Until this change, FINRA's trade reporting facilities only supported whole-number share quantities. According to FINRA's March 2024 Trade Reporting Notice, firms reporting a fractional trade for less than one share were required to round up to one, and firms reporting a fractional trade greater than one share were required to truncate to the whole number. A trade for 0.5 shares was reported as 1. A trade for 100.5 shares was reported as 100.
FINRA first announced the fractional share reporting enhancements in March 2024. The effective date was pushed back twice (November 2024, March 2025) before landing on February 23, 2026. The January 14, 2026 Trade Reporting Notice contains the final implementation details.
To be clear, this was a reporting problem, not an execution problem. If you bought 0.5 shares, you received 0.5 shares and paid for 0.5 shares. The trade itself settled correctly. But the consolidated tape, the canonical source of truth for market data, said "1 share." Anyone downstream consuming that tape data was working with distorted inputs.
Researchers Robert Bartlett (UC Berkeley), Justin McCrary (Columbia), and Maureen O'Hara (Cornell) documented the consequences of this practice in two papers: "Tiny Trades, Big Questions: Fractional Shares" in the Journal of Financial Economics (2024) and "A Fractional Solution to a Stock Market Mystery" in the Financial Analysts Journal (2025). They found that 80% of Berkshire Hathaway Class A's reported daily trading volume was phantom volume, a direct artifact of this rounding rule. When brokerages began reporting fractional BRK.A trades to the consolidated tape in early 2021, each micro-purchase (as little as $1 worth, or roughly 0.000002 shares at BRK.A's price) was reported as one full share. Daily reported volume surged from a decade-long average of roughly 375 shares to over 20,000. Across their broader sample, the researchers estimated that overall trading volume was inflated by roughly $200 billion during the study period due solely to the rounding rules. The downstream effects they documented included dislocations in the BRK.A/BRK.B price relationship, corrupted standard liquidity metrics like the Amihud illiquidity measure, and a measurable increase in effective spreads.
Massive's APIs now expose the new decimal values across WebSocket, REST, and flat file delivery. In this post, we'll walk through what changed at the SIP level, why it matters for anyone consuming trade data, and how to use a demo we built that quantifies the impact of the old integer-only reporting.
You can find the full code for the demo in the Massive community repo.
The problem was not subtle. Integer truncation distorted reported volume on every fractional trade.
Two things happened depending on the trade size:
To see how these distortions add up in practice, we built a demo that reconstructs the old integer-only reporting and compares it against the new decimal values. Running it against a full day of TSLA trades (March 2, 2026), the demo identified over 420,000 fractional trades out of 1.4 million total, with a net volume misreporting of roughly 400,000 shares. In notional terms, the gap between what the tape reported and what actually traded was approximately $160 million for a single ticker on a single day. No one lost that money; the trades settled correctly. But any system consuming that volume data (VWAP algorithms, liquidity metrics, volume-profile strategies, financial dashboards) was operating on inputs that were off by that much. These numbers come from the demo's output and will vary by ticker and trading day, but they illustrate the scale of the data gap.
For anyone building quantitative analysis tools, algorithmic trading systems, or financial dashboards that rely on accurate volume data, this is a meaningful change to understand.
Under the new FINRA rules, fractional quantities are reported with up to six decimal places of precision, truncated (not rounded) beyond that point. A trade of 1/3 share, for example, is reported as 0.333333.
All new decimal fields in Massive's API are returned as strings to preserve this exact value. JSON does not guarantee precision for large or fractional numbers, so a value like 0.123456789 can lose precision when parsed as an IEEE 754 float. Use your language's arbitrary-precision decimal type (Python's decimal.Decimal, Java's BigDecimal, etc.) if you need exact arithmetic.
WebSocket Trades: The new
WebSocket Aggregates: The new
REST Trades: The new
REST Snapshots v2: New
REST Snapshots v3: New
Flat Files Trades: The size column now reports decimal values (e.g., 0.500000).
Flat Files Aggregates: The volume column now reports decimal values (e.g., 150.000000).
For WebSocket and REST consumers, this is a non-breaking change. New fields were added alongside existing ones. The old integer fields (s, v, av, size, volume) still work exactly as before. You can migrate on your own schedule.
For flat file consumers, this is potentially breaking. The size and volume columns changed from integers to decimals in place. If your pipeline casts these columns to int, it will either error or silently truncate. Check your parsing logic and update it to handle decimal strings.
The demo is a single
Streams real-time trades and aggregates, identifies fractional quantities, and saves results to CSV. Run it like this:
uv run python main.py websocket # Default: AAPL, 30 seconds uv run python main.py ws AAPL MSFT GOOGL # Multiple tickers uv run python main.py ws AAPL -d 60 # Collect for 60 seconds
The demo connects to the WebSocket using raw mode to access the
Here is example output for Apple on March 5th, 2026:
============================================================== Fractional Share Precision — WebSocket Trade Analysis ============================================================== Tickers: AAPL Duration: 30s Feeds: Trades (T) + Aggregates (A) Before fractional precision, exchanges rounded trade sizes: Sub-1-share (e.g. 0.038) → reported as 1 (inflated) Larger frac (e.g. 52.12) → reported as 52 (deflated) ============================================================== Collecting... 3730 trades (280 fractional), 29 aggs [0s left] ============================================================== Fractional Share Precision — Results ============================================================== Trades received: 3,730 Aggregates received: 29 Fractional trades: 280 (7.5% of total) Time Sym Price Old Rptd Actual Size ───────────── ────── ────────── ───────── ──────────── 19:29:32.721 AAPL $260.80 1 0.025100 19:29:32.721 AAPL $260.86 1 0.002500 19:29:32.721 AAPL $260.80 1 0.069228 19:29:32.721 AAPL $260.88 1 0.191650 19:29:32.721 AAPL $260.78 1 0.031437 19:29:32.721 AAPL $260.95 1 0.002500 19:29:32.721 AAPL $260.91 1 0.019160 19:29:32.721 AAPL $260.95 1 0.111016 19:29:32.721 AAPL $260.78 1 0.007439 19:29:32.721 AAPL $260.78 1 0.136780 ... and 270 more (see CSV) Volume gap: Sub-1-share trades: 275 reported as 1 share (inflated) Larger fractional: 5 with fraction dropped (truncated) Shares: 62.5083 actual, 280 old-reported (-217.4917 hidden) Dollars: $16,283.19 actual, $72,936.58 old-reported ($-56,653.39 hidden) ──────────────────────────────────────────────────────────── Saved files ──────────────────────────────────────────────────────────── /Users/alexnovotny/Projects/community/examples/rest/fractional-share-precision/data/ws_trades_20260305_083114.csv 280 fractional trades /Users/alexnovotny/Projects/community/examples/rest/fractional-share-precision/data/ws_aggs_20260305_083114.csv 1 ticker snapshots ==============================================================
Fetches every trade for one or more tickers on a given date, identifies fractional quantities, and calculates cumulative impact:
uv run python main.py rest # Default: AAPL, most recent business day uv run python main.py rest TSLA --date 2026-03-02 # Specific ticker and date uv run python main.py rest TSLA NVDA --save # Multiple tickers, export CSV
For each ticker, the demo fetches all trades via the REST trades endpoint, reads the
Here is an example output for Apple on March 04, 2026.
============================================================== Fractional Share Precision — REST Trade Analysis ============================================================== Tickers: AAPL Date: 2026-03-04 Before fractional precision, exchanges rounded trade sizes: Sub-1-share (e.g. 0.038) → reported as 1 (inflated) Larger frac (e.g. 52.12) → reported as 52 (deflated) ============================================================== Fetching trades for AAPL on 2026-03-04 ... Fetched 633,481 trades total. ──────────────────────────────────────────────────────────── AAPL ──────────────────────────────────────────────────────────── Total trades: 633,481 Fractional trades: 165,211 (26.1% of total) Time Price Old Rptd Actual Size ────────────── ────────── ───────── ───────────── 19:55:33.023 $262.77 1 0.003947 19:55:33.022 $262.77 1 0.003950 19:55:33.020 $262.77 1 0.003950 19:52:18.595 $262.67 1 0.009511 19:49:19.135 $262.67 1 0.012602 19:45:55.758 $262.84 1 0.009511 19:45:26.470 $262.70 1 0.187852 19:37:55.483 $262.98 1 0.021408 19:37:34.676 $262.99 1 0.037339 19:36:45.400 $262.68 1 0.765931 ... and 165,201 more Volume gap: Sub-1-share trades: 164,014 reported as 1 share (inflated) Larger fractional: 1,197 with fraction dropped (truncated) Shares: 26,028.5902 actual, 182,144 old-reported (-156,115.4098 hidden) Dollars: $6,856,991.22 actual, $48,045,018.28 old-reported ($-41,188,027.06 hidden) ==============================================================
Downloads a partial flat file from S3, identifies fractional quantities in both trades and aggregate bars:
uv run python main.py flatfiles # Default: 2 business days ago uv run python main.py ff --date 2026-02-27 # Specific date uv run python main.py flat --type trades # Trades only uv run python main.py flatfiles --type aggs --save # Aggregates, save CSV
The demo uses HTTP range requests to download only the first 512KB of each gzipped CSV, so you are not pulling multi-gigabyte files just to inspect the format change. It applies the same impact analysis to trades and shows bars with fractional volume for aggregates.
Here is an example flat file output for March 3, 2026:
============================================================== Fractional Share Precision — Flat Files Analysis ============================================================== Date: 2026-03-03 Endpoint: https://files.massive.com Bucket: flatfiles Before fractional precision, exchanges rounded trade sizes: Sub-1-share (e.g. 0.038) → reported as 1 (inflated) Larger frac (e.g. 52.12) → reported as 52 (deflated) ============================================================== ──────────────────────────────────────────────────────────── TRADES flat file (2026-03-03) ──────────────────────────────────────────────────────────── Downloading: us_stocks_sip/trades_v1/2026/03/2026-03-03.csv.gz (first 512KB)... Rows sampled: 50 Fractional trades: 6 (12.0% of sample) Ticker Price Old Rptd Actual Size ──────── ────────── ───────── ───────────── A $121.84 1 0.976673 A $117.49 1 0.016864 A $118.17 1 0.135000 A $118.17 1 0.224440 A $118.17 1 0.400000 A $118.17 1 0.600000 Volume gap: Sub-1-share trades: 6 reported as 1 share (inflated) Larger fractional: 0 with fraction dropped (truncated) Shares: 2.3530 actual, 6 old-reported (-3.6470 hidden) Dollars: $281.63 actual, $712.01 old-reported ($-430.38 hidden) ──────────────────────────────────────────────────────────── AGGREGATES flat file (2026-03-03) ──────────────────────────────────────────────────────────── Downloading: us_stocks_sip/minute_aggs_v1/2026/03/2026-03-03.csv.gz (first 512KB)... Rows sampled: 50 Fractional volume bars: 38 (76.0% of sample) Ticker Close Volume ──────── ────────── ──────────────── A $116.17 32008.673934 A $116.14 2374.216401 A $116.14 4189.767400 A $116.47 2620.012940 A $116.52 1317.440500 A $116.69 1191.619805 A $116.58 1459.690000 A $116.47 2657.881820 A $116.37 3721.122800 A $116.42 1348.173839 ... and 28 more Impact across 50 rows: Volume: 202,882.49 actual, 202,870 old-reported (+12.49 hidden) Dollars: $23,625,296.40 actual, $23,623,842.35 old-reported ($+1,454.04 hidden) ==============================================================
Note that flat files are not available on weekends and are typically published with a one-day delay. The script defaults to 2 business days ago to avoid requesting a file that has not been published yet.
Not seeing fractional trades in the WebSocket demo: Fractional trades are a meaningful percentage of total volume, but you may need a longer collection window. Try -d 60 or more. Make sure the US stock market is open (9:30 AM to 4:00 PM ET, weekdays).
WebSocket authentication errors: Verify MASSIVE_API_KEY is set correctly in .env. Check that your plan includes real-time stock data.
REST demo returns zero fractional trades: Some tickers have fewer fractional trades than others. Try a popular retail ticker like TSLA or AAPL. Make sure the date is a recent business day.
Flat files demo returns "File not found": Flat files are not available for weekends or holidays. Try a recent weekday. Verify your S3 credentials are correct in .env. S3 credentials are separate from your API key.
The examples, demos, and outputs produced with this project are generated by artificial intelligence and large language models. You acknowledge that this project and any outputs are provided "AS IS", may not always be accurate and may contain material inaccuracies even if they appear accurate because of their level of detail or specificity, outputs may not be error free, accurate, current, complete, or operate as you intended, you should not rely on any outputs or actions without independently confirming their accuracy, and any outputs should not be treated as financial or legal advice. You remain responsible for verifying the accuracy, suitability, and legality of any output before relying on it.
Alex Novotny
alexnovotny
See what's happening at Massive
In this post, we'll walk through how Earnings Watcher built its analytics layer on Massive's options chains and snapshots, why Fair Market Value anchors its scanner, and how the same API pattern extended from options into post-earnings drift analysis on the underlying equity.
alexnovotny
Massive's LULD WebSocket channel streams Limit Up/Limit Down price band updates, halts, and resumptions for every NMS stock in real time.
editor
Massive’s Futures APIs are now generally available, providing real-time and historical market data for top U.S. futures (ES, GC, CL) from CME, CBOT, COMEX, and NYMEX, accessible via REST API, Websocket, and flat files.
editor