What A-share Level 2 Data Actually Contains

A-share Level 2 data is the deep market data product for stocks listed in Shanghai and Shenzhen, and it adds four things to Level 1: ten price levels on each side of the book instead of five, the individual order sizes queued at the best price, a stream of every order submitted, and a stream of every execution and cancellation. The book itself arrives as a snapshot on a fixed three second cadence at both exchanges, while the order and trade streams are event by event. If you are arriving from a US order based feed, that split is the first thing to get straight. Our Level 1 versus Level 2 market data primer covers the US side of the same distinction.

What A-share Level 2 contains that Level 1 does not

Level 1 in China is a thin snapshot: last price, cumulative volume, cumulative turnover, and five price levels on each side. Level 2, as the Shanghai exchange describes its own product, adds the following.

• Ten price levels on each side, the BidPx and BidSize arrays and their offer equivalents, against five on Level 1.
• The order queue at the touch: the quantity of each of the top 50 individual orders resting at the best bid and at the best offer.
• Whole book aggregates: total instructed quantity on each side (TotalBidQty and TotalOfferQty) plus the weighted average bid and offer price, computed across the entire book rather than the ten shown levels.
• An order by order stream, 逐笔委托, carrying each incoming order with its price, quantity, side and order type.
• A trade by trade stream, 逐笔成交, carrying each execution, with cancellations delivered on the same channel.
• Cumulative counters inside the snapshot, including the number of trades and the count and value of withdrawn orders.

The two exchanges package the event streams differently. Shenzhen's binary interface separates them into an order message and a trade message, both carried on numbered channels. Shanghai has historically carried its tick data as a single stream with a type flag distinguishing an order add, an order delete and a trade, and it began publishing order level data in 2021, later than Shenzhen. Both interfaces have been revised more than once, and the revision you are decoding against is the authority on field layout. Client libraries rename columns freely, so map any library's column names back to the exchange specification before you trust a field.

Why the three second snapshot cadence matters

A snapshot shows the state of the book at the instant it was taken. Whatever happened between two snapshots is absent from the snapshot series, and the order and trade streams are what recover it. The practical question is how much a three second interval can hold. US quote data answers that question directly.

The panel below walks one pinned session of AAPL quote updates, bucketed by Eastern clock hour, and divides each hour's updates by the number of three second intervals in that hour which carried any quote at all.

SELECT
    formatDateTime(toStartOfHour(toTimeZone(sip_timestamp, 'America/New_York')), '%H:%i') AS et_hour,
    round(count() / 1000.0, 1)                                                            AS quote_updates_thousands,
    round(count() / uniqExact(toStartOfInterval(toTimeZone(sip_timestamp, 'America/New_York'), INTERVAL 3 SECOND)), 1) AS updates_per_3s_window
FROM global_markets.cache_stocks_quotes
WHERE ticker = 'AAPL'
  AND sip_timestamp >= '2026-09-16 08:00:00'
  AND sip_timestamp <  '2026-09-17 00:00:00'
GROUP BY et_hour
ORDER BY et_hour

The tape that session runs from the 04:00 hour through the 19:00 hour Eastern, premarket and after hours included. In the first hour carrying quotes, an active three second interval held 4.1 updates on average; in the last, 21.3. The regular session hours in between dominate the curve, which is the shape a snapshot feed flattens.

Update counts on their own overstate the loss, since plenty of updates leave the best price untouched. The sharper measure is how many different best bid prices a single three second interval contained.

WITH windows AS
(
    SELECT
        toStartOfInterval(toTimeZone(sip_timestamp, 'America/New_York'), INTERVAL 3 SECOND) AS win,
        uniqExact(bid_price)                                                                AS distinct_bids
    FROM global_markets.cache_stocks_quotes
    WHERE ticker = 'AAPL'
      AND sip_timestamp >= '2026-09-16 08:00:00'
      AND sip_timestamp <  '2026-09-17 00:00:00'
      AND bid_price > 0
    GROUP BY win
)
SELECT
    toUInt16(least(distinct_bids, 10))                        AS distinct_best_bids,
    count()                                                   AS windows,
    round(100.0 * count() / (SELECT count() FROM windows), 1) AS share_of_windows_pct
FROM windows
GROUP BY distinct_best_bids
ORDER BY distinct_best_bids

Across the whole session, 24.8% of three second intervals held exactly one best bid price, and a snapshot would have represented those intervals perfectly. At the other end of the curve, 9.1% of intervals held 10 or more distinct best bids, each one collapsed into a single row by a snapshot. The tail is where a fill happens.

Mapping the Chinese field names onto US equivalents

Most of the translation is mechanical once you know which US construct a field belongs to. The depth arrays are market by price; the event streams are market by order, a distinction we unpack in market by order versus market by price data.

• SecurityID is the symbol field. A-share codes are six digits, and the listing exchange is largely implied by the code range rather than carried next to it.
• TransactTime in Shenzhen, and the tick timestamp in Shanghai, are matching engine times. They correspond to a participant timestamp, not to a consolidated tape timestamp.
• BidPx and BidSize are aggregated depth, the same construct as a ten level US depth book.
• In the order stream, Price, OrderQty and Side correspond to price, shares and the buy or sell indicator on an add order message.
• ApplSeqNum in Shenzhen, and the buy and sell order numbers in Shanghai, play the role of the order reference number a US market by order feed assigns to each resting order.
• In the trade stream, LastPx and LastQty are trade price and size, the fields a US print carries.
• A Shenzhen trade message whose ExecType marks a withdrawal, and a Shanghai tick whose type flag marks a delete, correspond to an order cancel message.
• ChannelNo partitions the message flow. It is not a trading venue, and the nearest US analogue, one exchange's own sequenced feed, is a loose fit.

Where there is no US equivalent at all

This is the part that breaks a port.

• Two sided order linkage. A Shenzhen trade message carries both BidApplSeqNum and OfferApplSeqNum, naming the buy order and the sell order behind the print. A US order executed message references the resting order only, and the aggressor stays anonymous.
• Cancellations on the trade channel. A withdrawal arriving as a trade message is a shape no US feed has, and a decoder that routes by channel will drop cancels without complaint.
• A published order queue at the touch. The top 50 order sizes at the best price are a snapshot field here. On a US feed you rebuild that from order level data, or you estimate it.
• Whole book aggregates. Total instructed quantity and the weighted average price across the full book describe the part of the book that no depth feed displays.
• One venue per security. Each A-share lists on exactly one exchange, and the consolidation machinery of US equities, the national best bid and offer, protected quotes, trade through protection and a venue field on every print, has no counterpart.

What this does to queue position and book replay

Queue position estimation in US equities is an inference problem: order based feeds give you one reference per resting order at a venue, and you track your own place by watching adds, cancels and fills. The A-share streams change that problem in four specific ways.

1. Position becomes computable rather than estimated, provided the replay consumes both channels. Adds come from the order stream; the cancels that free space ahead of you arrive as withdrawal messages on the trade stream. A replayer reading only the order stream keeps cancelled size resting forever and overstates the queue in front of your order for the rest of the day.
2. There is no modify or replace message. A size or price change appears as a cancel followed by a fresh order with a new reference, so lifetime logic written around US replace chains has nothing to attach to.
3. Each execution decrements two order references. Replay code that assumes a fill touches one resting order will leave the aggressor's order outstanding.
4. Sequence numbers are scoped to a channel, not to the market. Interleaving channels on sequence number alone produces an ordering of events that never happened. Merge on the transaction timestamp, keep the channel as a tiebreak, and treat the residue as genuinely ambiguous: the published specifications do not fully pin down cross channel ordering, and that is worth checking against the revision you hold.

Two market design features sit on top of all of that. Daily price limits cap the move, ten percent on the main boards and twenty on the STAR Market and ChiNext, with tighter bands on specially treated names, and at a limit price the resting queue is the whole contest. That is where exact position is worth the most and where a three second snapshot hides the most churn. Call auctions open and close the session, snapshot fields carry an indicative match price while one is running, and replay code that assumes continuous matching will mishandle those minutes. Shares bought in a session also cannot be sold until the next one, so there is no same day round trip in the same shares to replay at all. After the close, the dragon tiger list discloses who traded the day's most active names, a disclosure regime with no US analogue.

How much of this bites depends on how fast the instrument trades. Across five household US names over one 30 minute mid morning window, the event rate per three second interval spreads widely.

SELECT
    q.ticker                             AS symbol,
    q.quote_updates_per_3s_window        AS quote_updates_per_3s_window,
    round(q.quote_updates / t.trades, 1) AS quote_updates_per_trade
FROM
(
    SELECT
        ticker,
        count()                                                                            AS quote_updates,
        round(count() / uniqExact(toStartOfInterval(sip_timestamp, INTERVAL 3 SECOND)), 1) AS quote_updates_per_3s_window
    FROM global_markets.cache_stocks_quotes
    WHERE ticker IN ('AAPL', 'KO', 'MSFT', 'NVDA', 'SPY')
      AND sip_timestamp >= '2026-09-16 14:00:00'
      AND sip_timestamp <  '2026-09-16 14:30:00'
    GROUP BY ticker
) AS q
INNER JOIN
(
    SELECT
        ticker,
        count() AS trades
    FROM global_markets.stocks_trades
    WHERE ticker IN ('AAPL', 'KO', 'MSFT', 'NVDA', 'SPY')
      AND sip_timestamp >= '2026-09-16 14:00:00'
      AND sip_timestamp <  '2026-09-16 14:30:00'
    GROUP BY ticker
) AS t ON q.ticker = t.ticker
ORDER BY quote_updates_per_3s_window DESC

Over that window SPY averaged 277.3 quote updates in every three second interval that carried a quote, against 27.2 for MSFT. Per print, the busier name ran 4.9 quote updates for each trade. A three second snapshot preserves a quiet name's book nearly intact and discards most of a busy one's, and the same gradient runs across A-shares: a snapshot replay of a thin listing loses far less than a snapshot replay of an index heavyweight. Keeping all three streams for a working universe is a storage problem of its own, which our local A-share market data lake walkthrough covers.

FAQ

What is the difference between A-share Level 1 and Level 2 data?

Level 1 carries last price, cumulative volume, cumulative turnover, and five price levels on each side. Level 2 extends the book to ten levels, publishes the individual order sizes queued at the best price, adds whole book aggregates, and delivers an order by order stream and a trade by trade stream alongside the snapshot.

How often does A-share Level 2 data update?

The order book snapshot is published on a fixed three second cadence at both Shanghai and Shenzhen. The order and trade streams are event based rather than periodic, so each message arrives as the matching engine produces it.

Can you rebuild the full A-share order book from Level 2 data?

With the order by order and trade by trade streams, yes in principle: adds come from the order stream, and fills and cancellations from the trade stream. With snapshots alone you cannot, since ten levels sampled every three seconds omit every order that arrived and left between two samples.

Do A-share Level 2 trades identify the orders behind them?

In Shenzhen's interface each trade message carries a sequence number for the buy order and one for the sell order, linking a print to both resting orders. US public feeds reference at most the resting side. Treat the Shanghai equivalent as interface specific and confirm it against the revision you are decoding.

Do US queue position models work on A-shares?

Partly. Price and time priority is familiar, and the order reference numbers make a position exact rather than estimated. The rework sits in message handling: cancellations arrive on the trade channel, there is no replace message, each fill touches two order references, and sequence numbers are scoped per channel.

Every panel above ships the SQL that produced it, so you can check the three second arithmetic yourself. To run the same measurements on a name and a session you care about, ask for them in plain English on the Strasmore terminal.