Market Data Timestamps: SIP o Exchange Clock?

Ang market data timestamp ay mga orasan na itinatala sa isang trade print habang naglalakbay ito mula sa matching engine na nagsagawa ng execution hanggang sa screen na nagpapakita nito. Ang isang US equity trade ay may tatlong timestamp sa public record, at iba-iba ang sinasagot na tanong ng bawat isa. Kapag inayos mo ang mga print sa parehong araw ayon sa isang orasan at pagkatapos ay ayon sa isa pa, dalawang tunay na magkaibang tape ang makukuha mo.

Ang apat na orasan na dinaraanan ng isang print

Paulit-ulit na nalalagyan ng timestamp ang isang print habang papunta ito sa iyo. Sa pagkakasunod:

1. Matching engine time. Ito ang eksaktong sandali kung kailan pinagpares ng matching engine ng isang venue ang dalawang order. Walang direktang access dito ang mga nasa labas ng venue. Ito ang ground truth kung kailan naganap ang trade, at approximation lamang nito ang bawat sumunod na orasan.
2. Participant time, na tinatawag ding venue o exchange time. Ito ang timestamp na inilalagay ng venue kapag inilalathala nito ang print sa sarili nitong feed, at nasa participant_timestamp field. Sa lahat ng timestamp na aktuwal mong mababasa, ito ang pinakamalapit sa matching engine.
3. SIP time. Ito ang timestamp na inilalagay ng securities information processor kapag umabot ang print sa consolidated tape, ang iisang official feed na pinagsasama ang lahat ng US equity venue. Ito ang sip_timestamp field, at ito ang sinusunod ng sequence ng official tape. Ipinaliliwanag sa SIP kumpara sa direct exchange feeds ang pagkakaiba ng feed na iyon at ng sariling feed ng venue.
4. Capture time. Ito ang timestamp na inilalagay ng sarili mong network card kapag dumating ang packet. Hindi ito lumilitaw sa record ng vendor dahil inilalarawan nito ang sarili mong data path, hindi ang market. Ang mga gawaing Packet capture at replay ay lubos na umaasa sa orasan na ito.

Ang off-exchange prints ay may ikalimang timestamp, trf_timestamp, na nagmamarka kung kailan tinanggap ng trade reporting facility ang report.

Bakit hindi nagtutugma ang market data timestamp sa iba't ibang venue

Ang pagitan ng timestamp ng venue at ng consolidated timestamp ay ang oras na ginugol ng print sa transit at sa queue ng processor. Hindi ito iisang numero. Magkakaiba ang distansya ng bawat venue mula sa processor, pati ang hardware at queue na ginagamit nito. Sinusukat ng panel sa ibaba ang pagitan para sa bawat venue na nag-print ng AAPL sa isang itinakdang half hour noong 10 June 2026.

WITH venues AS
(
    SELECT
        toUInt32(id)                             AS exchange_id,
        any(coalesce(nullIf(acronym, ''), name)) AS venue_name
    FROM global_markets.stocks_exchanges
    WHERE asset_class = 'stocks'
    GROUP BY exchange_id
)
SELECT
    if(v.venue_name = '', concat('Venue ', toString(t.exchange)), v.venue_name) AS venue,
    count()                                                                     AS print_count,
    round(quantileDeterministic(0.5)(
        toFloat64(toUnixTimestamp64Nano(t.sip_timestamp)
                - toUnixTimestamp64Nano(t.participant_timestamp)) / 1000,
        toUInt64(t.sequence_number)), 1)                                        AS median_lag_us,
    round(quantileDeterministic(0.99)(
        toFloat64(toUnixTimestamp64Nano(t.sip_timestamp)
                - toUnixTimestamp64Nano(t.participant_timestamp)) / 1000,
        toUInt64(t.sequence_number)), 1)                                        AS p99_lag_us
FROM global_markets.stocks_trades AS t
LEFT JOIN venues AS v ON v.exchange_id = toUInt32(t.exchange)
WHERE t.ticker = 'AAPL'
  AND t.sip_timestamp >= '2026-06-10 14:30:00'
  AND t.sip_timestamp <  '2026-06-10 15:00:00'
  AND ifNull(toUnixTimestamp64Nano(t.trf_timestamp), 0) = 0
GROUP BY venue
HAVING count() >= 200
ORDER BY median_lag_us DESC
LIMIT 15

Sa mga venue na iyon, ang pinakamalaking median gap sa pagitan ng venue timestamp at consolidated timestamp ay 346.2 microseconds, sa NYSE Arca, Inc.. Ang pinakamaliit na gap sa parehong window ay 13.7 microseconds. Ang p99 column ang dapat pagtuunan ng pansin: para sa parehong pinakamabagal na venue, umabot ito sa 420.8 microseconds. Ipinapakita nito ang tail na hindi nakikita sa median.

Aling timestamp ang dapat gamitin

Sapat na ang apat na panuntunan para sa halos lahat ng sitwasyon.

• Participant time para sa microstructure work at event studies. Ang anumang sumusukat sa nangyari sa isang venue at sa pagkakasunod nito ay dapat gumamit ng venue clock. Hindi magagamit sa ibang orasan ang reconstruction ng order book, na paksa ng MBO kumpara sa MBP order book data.
• SIP time para sa anumang kailangang tumugma sa official tape. Kabilang dito ang regulatory reporting, best execution review, official open at close, at anumang figure na susuriin ng counterparty laban sa consolidated record.
• Capture time lamang para sa pagsukat ng sarili mong path. Sinasabi nito kung gaano katagal bago makarating ang data sa iyong machine. Wala itong sinasabi tungkol sa kung kailan naganap ang trade, at hindi kailanman magtutugma ang resulta nito sa dalawang machine.
• Huwag pagsamahin ang magkakaibang orasan sa iisang dataset. Ang join na nagmamatch ng quotes gamit ang isang orasan laban sa trades gamit ang isa pa ay magbabalik ng mga numerong mukhang kapani-paniwala ngunit pumapalya sa mismong mahahalagang sandali.

Ang parehong mga print, inayos sa dalawang paraan

Dito lumilitaw ang aktuwal na epekto ng sorting. Kinukuha ng panel sa ibaba ang pinakamaraming sampung milliseconds sa half hour na iyon, pinananatili ang unang twelve on-exchange prints ayon sa venue order, at pagkatapos ay niraranggo muli ang parehong twelve ayon sa consolidated tape order. Inaayos ang table ayon sa laki ng paglipat ng bawat print sa pagitan ng dalawang ranking.

WITH
    burst AS
    (
        SELECT intDiv(toUnixTimestamp64Nano(participant_timestamp), 10000000) AS slice_10ms
        FROM global_markets.stocks_trades
        WHERE ticker = 'AAPL'
          AND sip_timestamp >= '2026-06-10 14:30:00'
          AND sip_timestamp <  '2026-06-10 15:00:00'
          AND ifNull(toUnixTimestamp64Nano(trf_timestamp), 0) = 0
        GROUP BY slice_10ms
        ORDER BY count() DESC, slice_10ms ASC
        LIMIT 1
    ),
    sample AS
    (
        SELECT
            participant_timestamp,
            sip_timestamp,
            toUInt64(sequence_number) AS seq,
            toUnixTimestamp64Nano(sip_timestamp)
              - toUnixTimestamp64Nano(participant_timestamp) AS lag_ns
        FROM global_markets.stocks_trades
        WHERE ticker = 'AAPL'
          AND sip_timestamp >= '2026-06-10 14:30:00'
          AND sip_timestamp <  '2026-06-10 15:00:00'
          AND ifNull(toUnixTimestamp64Nano(trf_timestamp), 0) = 0
          AND intDiv(toUnixTimestamp64Nano(participant_timestamp), 10000000)
              IN (SELECT slice_10ms FROM burst)
        ORDER BY participant_timestamp ASC, seq ASC
        LIMIT 12
    ),
    ranked AS
    (
        SELECT
            participant_timestamp,
            sip_timestamp,
            lag_ns,
            row_number() OVER (ORDER BY participant_timestamp ASC, seq ASC) AS participant_rank,
            row_number() OVER (ORDER BY sip_timestamp ASC, seq ASC)         AS sip_rank
        FROM sample
    )
SELECT
    concat('P', leftPad(toString(participant_rank), 2, '0')) AS print_label,
    concat(formatDateTime(toTimeZone(participant_timestamp, 'America/New_York'), '%H:%i:%S'), '.',
           leftPad(toString(intDiv(toUnixTimestamp64Nano(participant_timestamp) % 1000000000, 1000)), 6, '0')) AS venue_clock_et,
    concat(formatDateTime(toTimeZone(sip_timestamp, 'America/New_York'), '%H:%i:%S'), '.',
           leftPad(toString(intDiv(toUnixTimestamp64Nano(sip_timestamp) % 1000000000, 1000)), 6, '0'))         AS tape_clock_et,
    participant_rank,
    sip_rank,
    abs(toInt32(sip_rank) - toInt32(participant_rank)) AS places_moved,
    round(lag_ns / 1000, 1)                            AS sip_lag_delta_us
FROM ranked
ORDER BY places_moved DESC, participant_rank ASC

Ang pinakamalaking agwat sa dalawang rank ng isang print ay 6. Umalis ang print na iyon sa venue nito sa 10:44:17.160712 at nakarating sa tape pagkalipas ng 305.7 microseconds, sa 10:44:17.161018. Mula ito sa position 6 ayon sa venue clock at naging position 12 sa tape. Walang maling ordering sa dalawang ito. Magkaibang tanong ang sinasagot nila. Ang trade sequence study na gumagamit ng tape clock ay magbabasa sa burst na ito sa pagkakasunod na hindi kailanman ginawa ng isang venue. Samantala, ang best execution review na gumagamit ng venue clock ay hindi tutugma sa official record.

Malayo sa event dumarating ang off-exchange prints

Ang trade na isinagawa sa labas ng exchange, sa wholesaler o dark pool, ay iniuulat sa trade reporting facility sa halip na itugma sa isang public book. Nasa report ang execution time, ngunit pagkatapos nito pa lamang ito dumarating sa tape. Ang pagitan ay reporting delay, hindi travel time, at mas malaki ito nang maraming order of magnitude.

WITH off_exchange AS
(
    SELECT
        (toUnixTimestamp64Nano(sip_timestamp)
       - toUnixTimestamp64Nano(participant_timestamp)) / 1000000.0 AS delay_ms
    FROM global_markets.stocks_trades
    WHERE ticker = 'AAPL'
      AND sip_timestamp >= '2026-06-10 14:30:00'
      AND sip_timestamp <  '2026-06-10 15:00:00'
      AND ifNull(toUnixTimestamp64Nano(trf_timestamp), 0) > 0
)
SELECT
    multiIf(delay_ms <     1, 'under 1 ms',
            delay_ms <    10, '1 to 10 ms',
            delay_ms <   100, '10 to 100 ms',
            delay_ms <  1000, '100 ms to 1 s',
            delay_ms < 10000, '1 s to 10 s',
                              'over 10 s')                       AS reporting_delay,
    count()                                                      AS print_count,
    round(100 * count() / (SELECT count() FROM off_exchange), 2) AS share_pct
FROM off_exchange
GROUP BY reporting_delay
ORDER BY min(delay_ms) ASC

Sa mga off-exchange AAPL prints sa window na iyon, 24.8% ang napunta sa under 1 ms bucket. Umaabot ang tail sa 1 s to 10 s bucket, na may 74 prints. Ang print na dumating nang sampung segundo na huli ay dala pa rin ang venue clock time kung kailan ito aktuwal na na-execute, ngunit nasa tape stream ito nang sampung segundo pagkatapos ng panahong iyon. Kapag inayos ayon sa tape time, magmumukha itong kabilang sa maling minuto. Ang mga print na iniuulat sa labas ng normal na sequence ay may sale condition codes na nagsasaad nito. Isa ito sa mga bagay na tinutukoy ng mga trade condition code.

Bakit magkaiba ang mga bar na binubuo ng dalawang tao mula sa parehong trades

Dito nauuwi ang halos lahat ng ticket na nagsasabing “mali ang data.” Ang isang bar ay bucket ng mga print, at nakadepende sa timestamp kung saang bucket mapupunta ang isang print. Binibilang ng panel sa ibaba ang mga print na nagbabago ng bucket kapag lumipat mula venue clock patungo sa tape clock, sa apat na karaniwang haba ng bar.

WITH
    prints AS
    (
        SELECT
            toUnixTimestamp64Nano(participant_timestamp) AS venue_ns,
            toUnixTimestamp64Nano(sip_timestamp)         AS tape_ns
        FROM global_markets.stocks_trades
        WHERE ticker = 'AAPL'
          AND sip_timestamp >= '2026-06-10 14:30:00'
          AND sip_timestamp <  '2026-06-10 15:00:00'
    ),
    grids AS
    (
        SELECT arrayJoin([1, 10, 60, 300]) AS bar_seconds
    )
SELECT
    multiIf(bar_seconds =  1, '1 second',
            bar_seconds = 10, '10 seconds',
            bar_seconds = 60, '1 minute',
                              '5 minutes') AS bar_length,
    countIf(intDiv(venue_ns, toInt64(bar_seconds) * 1000000000)
         != intDiv(tape_ns,  toInt64(bar_seconds) * 1000000000)) AS moved_print_count,
    round(100 * countIf(intDiv(venue_ns, toInt64(bar_seconds) * 1000000000)
                     != intDiv(tape_ns,  toInt64(bar_seconds) * 1000000000)) / count(), 3) AS moved_pct
FROM prints
CROSS JOIN grids
GROUP BY bar_seconds
ORDER BY bar_seconds ASC

Sa 1 second grid, 8.966% ng mga print sa window na iyon ang napupunta sa ibang bar sa ilalim ng dalawang orasan, o 8944 prints sa kabuuan. Kapag pinahaba ang bar sa 5 minutes, bumababa ang bilang sa 0.024%. Mekanikal ang pattern: nagbabago ng bucket ang isang print kapag tumawid ang pagitan ng dalawang timestamp nito sa isang boundary, at mas maraming boundary ang mas maiikling bar. Maaaring parehong tama ang dalawang vendor ngunit maglathala pa rin ng magkaibang volume para sa parehong minuto. Ipinaliliwanag nang sunod-sunod sa kung paano binubuo ang OHLCV bars ang mismong construction.

Ang nanosecond field ay hindi nangangahulugang nanosecond accuracy

Dumarating ang parehong timestamp bilang integer na may nanosecond resolution. Ang resolution ay ang kayang ipahayag ng isang field. Ang accuracy naman ay kung gaano kalapit ang value sa tunay na oras. Magkaibang bagay ang nagtatakda sa dalawang ito.

Ang clock alignment sa buong industriya ay pinamamahalaan ng regulatory tolerance, hindi ng physics. Inaatasan ng clock synchronization rule ng FINRA ang business clocks ng member firms na manatili sa loob ng 50 milliseconds mula sa NIST reference. Mas mahigpit ang ginagamit na standard ng exchanges at processors. Gumagamit sila ng Precision Time Protocol (PTP, standardised as IEEE 1588), na namamahagi ng reference clock sa parehong network na nagdadala ng data at nagpapanatili sa mga machine sa sub microsecond alignment.

Dalawang bagay ang sumusunod dito. Sa loob ng timestamp ng isang organisasyon, makabuluhan ang ordering sa microsecond resolution. Sa pagitan ng mga organisasyon, ang pagkakaiba ng ilang daang nanoseconds sa dalawang timestamp ay nasa loob ng error bar. Ang pagtrato rito bilang tunay na ordering ay pagbasa sa noise bilang signal.

FAQ

Ano ang pagkakaiba ng SIP timestamp at participant timestamp?

Ang participant timestamp ay inilalagay ng venue kapag inilalathala nito ang trade sa sarili nitong feed. Ang SIP timestamp ay inilalagay ng consolidated tape processor kapag umabot ang trade sa official combined feed. Ang pagitan ng dalawa ay transit at queueing time. Karaniwan itong sinusukat sa microseconds para sa on-exchange prints at sa milliseconds o mas matagal pa para sa mga print na iniuulat sa trade reporting facility.

Aling market data timestamp ang dapat gamitin sa backtesting?

Gamitin ang participant timestamp para sa anumang nagmomodelo ng maaaring nakita o nagawa ng isang participant sa isang venue. Gamitin ang SIP timestamp para sa anumang kailangang tumugma sa official consolidated record. Anuman ang piliin mo, gamitin ito sa bawat table sa study, pati sa quotes.

Bakit hindi nagtutugma ang one-minute bars ko sa data provider?

Karaniwang dahilan ang hindi pagtutugma ng orasan. Ang print na may venue timestamp ilang sandali bago ang minute boundary ay maaaring magkaroon ng tape timestamp ilang sandali pagkatapos nito. Dahil dito, mapupunta ang parehong trade sa magkaibang bar sa ilalim ng dalawang convention. Pinapalala ito ng late-reported off-exchange prints.

Accurate ba sa nanosecond ang nanosecond timestamps?

Hindi. Nanosecond resolution ang hawak ng field, ngunit nakadepende ang accuracy sa kung gaano kahusay na naka-synchronize ang orasan ng machine na nagsulat nito. Ang exchange at processor systems na gumagamit ng PTP ay nagpapanatili ng sub microsecond alignment, habang ang business clocks ng broker ay saklaw ng 50 millisecond regulatory tolerance. Hindi makabuluhan ang mga comparison na mas pino kaysa sa tolerance ng mas maluwag na orasan.

May kalakip na SQL ang bawat panel sa itaas na ginamit sa pagbuo nito. Makikita mo kung aling orasan ang pinagmulan ng bawat numero. Para muling ayusin ang sarili mong window ng mga print gamit ang ibang orasan at makita kung paano nagbabago ang tape, itanong ito sa plain English sa Strasmore terminal.