Binance Spot raw trades record individual matched executions. Aggregate trades combine one or more executions from the same taker order when they share the same price and execution time. For the same covered trades, aggregation preserves volume, but an aggregate row count is not an execution count. Keep raw and aggregate IDs separate, and use one representation for each volume calculation.
This distinction matters when a data pipeline switches feeds without changing its metric names. A chart can show the same traded quantity while a trade-count alert suddenly fires less often. The first check is what each row represents, followed by whether both datasets cover the same activity.
The Binance Spot rule has three boundaries
Binance's Spot glossary defines aggregation by taker order, execution time and price. Sharing a price alone is insufficient. One taker order can also produce several aggregate records when its executions cross a price or time boundary. An aggregate therefore represents neither every execution nor necessarily an entire order. Binance Spot aggregation definition.
Do not reconstruct groups by rounding timestamps into your preferred window. That creates a new aggregation method. Even matching visible timestamps and prices cannot establish a shared taker order when the public payload does not identify it.
Product scope matters too. Binance's USDⓈ-M Futures endpoint documents a different rule: grouping market trades within 100 milliseconds by price and taking side. That is not the Spot contract. Keep the product and endpoint definition attached to a dataset before comparing measurements. Binance USDⓈ-M aggregate-trades documentation.
Here, an execution means one public matched trade, counted once. It does not mean two observations because the transaction has both a buyer and seller.
Read the identifier at its own level
Binance Spot exposes raw and aggregate market records through separate interfaces. The official REST and stream schemas distinguish the identities below. Spot REST market endpoints, Spot WebSocket stream schemas.
| Representation | REST identity | WebSocket identity | What one record represents |
|---|---|---|---|
| Raw trade | id in trades or historicalTrades | t in <symbol>@trade | One individual public execution |
| Aggregate trade | a in aggTrades | a in <symbol>@aggTrade | One aggregation group |
| Aggregate boundaries | f and l | f and l | First and last underlying raw trade IDs |
An aggregate ID is not an order ID or a raw trade ID. Preserve its raw boundaries as separate fields. The earlier trade IDs versus order IDs guide addresses account-fill identity; this public-market distinction adds another record level.
In the stream payload, T is trade time and E is event time. The m flag asks whether the buyer was maker. A true value therefore indicates a taker seller; false indicates a taker buyer. Label a side-based metric accordingly. Binance stream field definitions.
Six executions become four aggregate records
The following is an original hypothetical Spot-style tape for ABCUSDT. All six executions have a taker buyer. T0 and T1 are different execution times, illustrated as one millisecond apart. Fees are excluded.
A and B are explanatory taker-order labels supplied by the fixture. They are not fields available in the public trade payload. The example assumes complete knowledge of group membership so that the arithmetic can be checked.
| Raw trade ID | Time | Taker order | Price, USDT/ABC | Quantity, ABC |
|---|---|---|---|---|
| 1001 | T0 | A | 100.00 | 1.2 |
| 1002 | T0 | A | 100.00 | 0.8 |
| 1003 | T0 | A | 100.10 | 0.5 |
| 1004 | T1 | A | 100.10 | 0.4 |
| 1005 | T1 | A | 100.10 | 0.6 |
| 1006 | T1 | B | 100.10 | 1.5 |
Trades 1001 and 1002 share all three grouping conditions. Trade 1003 has a different price. Trades 1004 and 1005 share a group with each other; their later execution time keeps them separate from 1003. Trade 1006 shares their time and price, but belongs to another taker order.
Applying those conditions gives these invented aggregate IDs:
| Aggregate ID | First–last raw IDs | Price, USDT/ABC | Combined ABC | Underlying executions |
|---|---|---|---|---|
| 9001 | 1001–1002 | 100.00 | 2.0 | 2 |
| 9002 | 1003–1003 | 100.10 | 0.5 | 1 |
| 9003 | 1004–1005 | 100.10 | 1.0 | 2 |
| 9004 | 1006–1006 | 100.10 | 1.5 | 1 |
Aggregate records 9003 and 9004 remain separate despite their identical price and time. Combining them locally would conceal a boundary that Binance Spot's rule preserves.
The fixture also shows why aggregate count is not order count. There are two taker orders, four aggregate records and six public executions. These answer three different questions.
Volume survives; count-based measurements change
Raw base quantity is 1.2 + 0.8 + 0.5 + 0.4 + 0.6 + 1.5 = 5 ABC. Aggregate quantity is 2 + 0.5 + 1 + 1.5 = 5 ABC.
Quote notional from the aggregate rows is 2 × 100 + 0.5 × 100.10 + 1 × 100.10 + 1.5 × 100.10 = 500.30 USDT. Multiplying each raw quantity by its own price gives the same result. Volume-weighted average price is therefore 500.30 ÷ 5 = 100.06 USDT/ABC in either representation.
The count falls from six rows to four, a reduction of one-third. Meanwhile, mean quantity per row rises from approximately 5 ÷ 6 = 0.8333 ABC to 5 ÷ 4 = 1.25 ABC: a 50% increase caused entirely by grouping.
A hypothetical rule requiring at least five individual executions would pass on the complete raw tape and fail if fed aggregate row count. A threshold based on average execution size would also change meaning. Rename and revalidate those features when changing the underlying representation.
For this fixture, l − f + 1 gives constituent counts of 2, 1, 2 and 1 because complete consecutive membership was explicitly supplied. In a production dataset, establish the relevant sequence and coverage assumptions before treating a numeric span as an audited count. The documented boundary fields alone do not prove that your collector retrieved every underlying record. Use raw constituents when the execution count needs independent verification.
Aggregation also discards individual sizes within a group. Knowing that 9001 totals two ABC does not reveal the original 1.2/0.8 split. A distribution of individual execution sizes cannot be recovered from the group quantity alone.
Give ingestion a representation-specific key
A conservative public-market key can contain venue, environment, product, symbol, record type and the provider's record ID. This is a local design proposal, not a claim that every dimension is required by a universal Binance uniqueness guarantee.
For example, keep Binance / production / Spot / ABCUSDT / aggregate / 9001 separate from any raw-trade identity. Do not merge records simply because their numeric IDs happen to match. Store IDs without lossy conversion and calculate quantities from decimal values; the decimal precision guide explains that separate parsing concern.
Transport belongs in observation provenance. After mapping their schemas, a REST observation and a WebSocket observation of the same public aggregate should point to one economic record. Keep both retrieval timestamps and original payloads without adding the quantity twice.
Raw trades and their aggregates are different representations of overlapping activity. They can occupy separate tables for analysis, but a volume query must select a single representation for each covered portion. In the fixture, concatenating both tables produces ten rows, ten ABC and 1,000.60 USDT: exactly twice the actual covered volume.
A replay of aggregate 9002 creates a different failure. Without deduplication, aggregate totals become five rows, 5.5 ABC and 550.35 USDT. If the same scoped key instead returns a conflicting quantity, preserve the disagreement for investigation. Quietly replacing it or inventing a second identity removes useful evidence.
Reconcile coverage before comparing totals
A cursor belongs to its record type. Binance Spot's aggTrades fromId refers to aggregate IDs and is inclusive. Resuming at 9004 can therefore return the already stored aggregate again. Passing its last raw ID, 1006, would ask a different question in the wrong namespace. The historicalTrades endpoint instead exposes a raw-trade fromId. Binance REST traversal fields.
Use intentional overlap and scoped deduplication when joining live collection to backfill. The history pagination guide supplies the broader coverage receipt. A correct key prevents repeated observations from inflating volume; it does not restore an interval never collected.
Timestamp units can create a false disagreement. Binance's Spot archive uses microseconds from 1 January 2025 onward, while its WebSocket streams default to milliseconds and offer a microsecond option. Preserve the source unit and normalize it before assigning intervals. Binance public-data formats, Spot stream time units.
When evaluating a VPS versus cloud hosting for a recorder, include durable checkpoints and repeatable imports in the decision. Restarting on a faster machine does not resolve an identity error. Likewise, exchange failover changes the venue namespace and potentially the aggregation method. Another venue's similarly priced trade cannot close a gap in this tape.
Validate the metric you intend to use
Save the following worksheet with a sample import before feeding its measurements into a rule or report.
| Check | Expected evidence |
|---|---|
| Representation | Explicit raw-trade or aggregate-trade label beside every count |
| Economic scope | Same venue, product, symbol and covered interval for volume comparisons |
| Arithmetic | Fixture produces 5 ABC, 500.30 USDT and VWAP 100.06 in both tables |
| Replay | Repeating 9002 leaves four distinct aggregates and five ABC |
| Conflict | A changed quantity under 9002 is surfaced for review |
| Restart | Stored records and their checkpoint survive; overlap adds no extra volume |
| Time parsing | Declared source unit produces the intended UTC interval |
| Missing coverage | Unretrieved periods remain visible instead of appearing as zero activity |
Public market records describe market activity. Account accounting needs account-specific evidence: Binance's authenticated myTrades endpoint includes order association, account-side fields and commission information that this aggregate tape does not supply. Do not infer personal inventory or net fees from public volume. Binance account trade list.
Before using a trade-count threshold, write whether it counts raw executions or aggregate records, run the six-row fixture, and replay one record. Keep the resulting volume, count and coverage receipt together so a later feed change can be checked against the same definition.