మార్కెట్ డేటా టైమ్‌స్టాంప్‌లు: SIP vs ఎక్స్ఛేంజ్ క్లాక్‌లు

Market data timestamps అనేవి ఒకే trade print, దాన్ని అమలు చేసిన matching engine నుంచి చూపించే స్క్రీన్‌ వరకు ప్రయాణిస్తున్నప్పుడు దానిపై ముద్రించబడే సమయాలు. US equity tradeకు public recordలో ఇలాంటి మూడు timestamps ఉంటాయి. ప్రతి timestamp వేర్వేరు ప్రశ్నకు సమాధానం ఇస్తుంది. ఒకే రోజు printsను ఒక clock ఆధారంగా, ఆ తర్వాత మరో clock ఆధారంగా క్రమబద్ధీకరిస్తే, మీ చేతిలో వాస్తవంగా రెండు వేర్వేరు tapes ఉంటాయి.

ఒకే print దాటే నాలుగు clocks

ఒక print మీకు చేరే మార్గంలో పలుమార్లు timestamp చేయబడుతుంది. క్రమంగా:

1. Matching engine time. ఒక venueకి చెందిన matching engine రెండు ordersను match చేసిన క్షణం. Venue వెలుపల ఎవ్వరూ ఈ విలువను నేరుగా చూడలేరు. Trade ఎప్పుడు జరిగిందో తెలిపే అసలు సమయం ఇదే. దీని తర్వాత వచ్చే ప్రతి clock దానికి ఒక అంచనా మాత్రమే.
2. Participant time, venue లేదా exchange time అని కూడా పిలుస్తారు. Venue తన స్వంత feedలో printను ప్రచురించినప్పుడు రాసే timestamp ఇది. ఇది participant_timestamp fieldలో ఉంటుంది. మీరు వాస్తవంగా చదవగలిగే timestampsలో matching engineకు అత్యంత సమీపమైనది ఇదే.
3. SIP time. Print consolidated tapeకు చేరినప్పుడు securities information processor రాసే timestamp ఇది. US equity venues అన్నింటి feedsను కలిపే ఏకైక అధికారిక feed consolidated tape. ఇది sip_timestamp field. Official tape sequence దీనినే అనుసరిస్తుంది. ఆ feed మరియు venue స్వంత feed మధ్య తేడాను SIP మరియు direct exchange feedsలో వివరించాం.
4. Capture time. Packet మీ network cardకు చేరినప్పుడు మీ సొంత network card రాసే timestamp ఇది. ఇది vendor recordలో ఎప్పుడూ కనిపించదు, ఎందుకంటే ఇది marketను కాకుండా మీ data pathను వివరిస్తుంది. Packet capture మరియు replay పనులు పూర్తిగా ఈ clockపైనే ఆధారపడతాయి.

Off-exchange printsకు ఐదో timestamp ఉంటుంది: trf_timestamp. Trade reporting facility ఆ reportను స్వీకరించిన సమయాన్ని ఇది సూచిస్తుంది.

Venues మధ్య market data timestamps ఎందుకు భిన్నంగా ఉంటాయి

Venue timestamp మరియు consolidated timestamp మధ్య gap, print ప్రయాణంలో మరియు processor queueలో గడిపిన సమయం. ఇది ఒకే సంఖ్య కాదు. ప్రతి venue processorకు వేర్వేరు దూరంలో ఉంటుంది. Hardware, queue కూడా వేర్వేరుగా ఉంటాయి. 10 June 2026న నిర్దిష్టమైన అరగంటలో AAPLను print చేసిన ప్రతి venueకు ఈ gapను కింది panel కొలుస్తుంది.

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

ఆ venuesలో venue timestamp మరియు consolidated timestamp మధ్య అత్యధిక median gap 346.2 microseconds. అది NYSE Arca, Inc. వద్ద నమోదైంది. అదే windowలో అతి తక్కువ gap ఉన్న venue 13.7 microsecondsతో నడిచింది. గమనించాల్సింది p99 column. అదే అత్యంత నెమ్మదైన venueలో అది 420.8 microsecondsకు చేరింది. Median దాచే tailను ఇది చూపిస్తుంది.

మీరు ఏ timestampను ఉపయోగించాలి

దాదాపు ప్రతి సందర్భాన్ని నాలుగు నియమాలు కవర్ చేస్తాయి.

• Microstructure పని మరియు event studiesకు participant time. Venueలో ఏమి జరిగింది, ఏ క్రమంలో జరిగింది అనే విషయాలను కొలిచే ఏ పని అయినా venue clockపైనే ఉండాలి. MBO మరియు MBP order book dataలో వివరించిన order book reconstructionను మరే ఇతర clockతో ఉపయోగించలేరు.
• Official tapeతో సరిపోల్చాల్సిన ప్రతిదానికి SIP time. Regulatory reporting, best execution review, official open మరియు close, అలాగే counterparty consolidated recordతో తనిఖీ చేసే ఏ figure అయినా SIP timeపైనే ఉండాలి.
• మీ స్వంత pathను కొలవడానికి మాత్రమే capture time. Data మీ machineకు చేరడానికి ఎంత సమయం పట్టిందో ఇది చెబుతుంది. Trade ఎప్పుడు జరిగిందో ఇది చెప్పదు. రెండు machinesలో capture time ఎప్పుడూ ఒకేలా ఉండదు.
• ఒక datasetలో clocksను ఎప్పుడూ కలపవద్దు. ఒక clockపై quotesను, మరో clockపై tradesను match చేసే join చూడటానికి నమ్మదగిన numbers ఇస్తుంది. కానీ కీలకమైన సమయాల్లో తప్పుతుంది.

అదే printsను రెండు విధాలుగా క్రమబద్ధీకరించడం

Sorting చేసినప్పుడు ఈ భావనలోని తేడా స్పష్టమవుతుంది. కింది panel ఆ అరగంటలో అత్యంత రద్దీగా ఉన్న పది millisecondsను తీసుకుంటుంది. అందులో exchange printsలో venue order ప్రకారం మొదటి పన్నెండింటిని ఉంచుతుంది. ఆ తర్వాత అదే పన్నెండు printsను consolidated tape orderలో మళ్లీ rank చేస్తుంది. రెండు rankings మధ్య ప్రతి print ఎంత దూరం కదిలిందో ఆధారంగా table క్రమబద్ధీకరించబడింది.

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

ఒక printకు చెందిన రెండు ranks మధ్య అత్యధిక తేడా 6. ఆ print తన venue నుంచి 10:44:17.160712 వద్ద బయలుదేరి, 305.7 microseconds తర్వాత 10:44:17.161018 వద్ద tapeకు చేరింది. Venue clockలోని 6 స్థానంనుంచి tapeలోని 12 స్థానానికి మారింది. ఈ రెండు orderingsలో ఏదీ తప్పు కాదు. అవి వేర్వేరు ప్రశ్నలకు సమాధానం ఇస్తాయి. Tape clock ఆధారంగా చేసిన trade sequence study, ఏ venue కూడా ఉత్పత్తి చేయని క్రమంలో ఈ burstను చూపిస్తుంది. Venue clock ఆధారంగా చేసిన best execution review official recordతో భిన్నంగా ఉంటుంది.

Off-exchange prints సంఘటనకు చాలా ఆలస్యంగా చేరతాయి

Exchange వెలుపల, wholesaler లేదా dark pool వద్ద అమలైన trade, public bookలో match కాకుండా trade reporting facilityకు report చేయబడుతుంది. Reportలో execution time ఉంటుంది. కానీ అది తర్వాత tapeకు చేరుతుంది. ఈ interval travel time కాదు; reporting delay. ఇది సాధారణ transit delay కంటే అనేక రెట్లు ఎక్కువగా ఉంటుంది.

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

ఆ windowలోని off-exchange AAPL printsలో 24.8%, under 1 ms bucketలోకి వచ్చాయి. Tail 1 s to 10 s bucket వరకు కొనసాగి, అందులో 74 prints ఉన్నాయి. పది seconds ఆలస్యంగా వచ్చిన printపైనా అది వాస్తవంగా అమలైన venue clock timeనే ఉంటుంది. అయితే tape streamలో అది ఆ సమయానికి పది seconds తర్వాత కనిపిస్తుంది. Tape time ఆధారంగా sort చేస్తే అది తప్పు minuteలో కనిపిస్తుంది. సాధారణ sequence వెలుపల report చేసిన printsకు sale condition codes ఉంటాయి. ఈ విషయాన్ని గుర్తించడానికే trade condition codes ఉపయోగపడతాయి.

అదే tradesతో ఇద్దరు వ్యక్తులు వేర్వేరు bars ఎందుకు నిర్మిస్తారు

దాదాపు ప్రతి “data తప్పుగా ఉంది” ticketకు కారణం ఇదే. Bar అనేది prints సమూహం. ఒక print ఏ bucketలోకి వెళ్తుందో అది ఏ timestamp ఆధారంగా bucket చేస్తున్నారనే దానిపై ఆధారపడి ఉంటుంది. Venue clock నుంచి tape clockకు మారినప్పుడు bucket మార్చే printsను కింది panel నాలుగు సాధారణ bar lengthsలో లెక్కిస్తుంది.

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

1 second gridలో, ఆ windowలోని printsలో 8.966% రెండు clocks కింద వేర్వేరు barsలోకి వెళ్తాయి. మొత్తం 8944 prints ప్రభావితమవుతాయి. Barను 5 minutes వరకు పొడిగిస్తే ఆ సంఖ్య 0.024%కు తగ్గుతుంది. నమూనా యాంత్రికంగా ఏర్పడుతుంది. ఒక printకు చెందిన clock gap boundaryను దాటినప్పుడల్లా అది bucketను మార్చుతుంది. Shorter barsలో boundaries ఎక్కువగా ఉంటాయి. అందువల్ల ఇద్దరు vendors సరైనదే చూపించినా, అదే minuteకు వేర్వేరు volumeను ప్రచురించవచ్చు. ఈ నిర్మాణాన్ని OHLCV bars ఎలా నిర్మించబడతాయిలో దశలవారీగా వివరించాం.

Nanosecond field అంటే nanosecond accuracy కాదు

రెండు timestamps nanosecond resolution ఉన్న integersగా వస్తాయి. Resolution అంటే field వ్యక్తపరచగలిగే సూక్ష్మత. Accuracy అంటే ఆ విలువ నిజమైన సమయానికి ఎంత దగ్గరగా ఉందో. ఈ రెండింటిని పూర్తిగా వేర్వేరు అంశాలు నిర్ణయిస్తాయి.

పరిశ్రమవ్యాప్తంగా clocks alignmentను physics కాకుండా regulatory tolerance నియంత్రిస్తుంది. FINRA clock synchronization rule ప్రకారం member firms business clocks, NIST referenceకు 50 millisecondsలోపు ఉండాలి. Exchanges మరియు processors ఇంకా ఎక్కువ ఖచ్చితత్వంతో పనిచేస్తాయి. ఇందుకోసం Precision Time Protocol (PTP, IEEE 1588గా standardised)ను ఉపయోగిస్తాయి. ఇది data తీసుకెళ్లే అదే network ద్వారా reference clockను పంపిణీ చేసి, machinesను sub microsecond alignmentలో ఉంచుతుంది.

దీనివల్ల రెండు విషయాలు స్పష్టమవుతాయి. ఒకే organisationలోని stamps మధ్య microsecond resolution వద్ద ordering అర్థవంతంగా ఉంటుంది. వేర్వేరు organisations మధ్య రెండు stampsకు కొన్ని వందల nanoseconds తేడా ఉంటే, అది error barలోనే ఉంటుంది. దాన్ని నిజమైన orderingగా పరిగణించడం noiseను చదవడమే.

తరచుగా అడిగే ప్రశ్నలు

SIP timestamp మరియు participant timestamp మధ్య తేడా ఏమిటి?

Venue తన స్వంత feedలో tradeను ప్రచురించినప్పుడు participant timestampను రాస్తుంది. ఆ trade official combined feed అయిన consolidated tapeకు చేరినప్పుడు consolidated tape processor SIP timestampను రాస్తుంది. ఈ రెండింటి మధ్య gap transit మరియు queueing time. Exchangeలో జరిగిన printsకు ఇది microsecondsలో ఉంటుంది. Trade reporting facility ద్వారా report అయిన printsకు తరచుగా milliseconds లేదా అంతకంటే ఎక్కువగా ఉంటుంది.

Backtestingకు ఏ market data timestampను ఉపయోగించాలి?

ఒక venueలో participant ఏమి చూడగలిగాడు లేదా ఏమి చేయగలిగాడు అనే విషయాన్ని model చేసే పనులకు participant timestampను ఉపయోగించండి. Official consolidated recordతో సరిపోలాల్సిన పనులకు SIP timestampను ఉపయోగించండి. ఏ timestampను ఎంచుకున్నా, quotesతో సహా studyలోని ప్రతి tableకు అదే timestampను వర్తింపజేయండి.

నా one-minute bars data provider barsతో ఎందుకు సరిపోలడం లేదు?

సాధారణ కారణం clock mismatch. ఒక print venue timestamp minute boundaryకి కాస్త ముందు ఉండవచ్చు. అదే print tape timestampతో boundary దాటి కాస్త తర్వాత కనిపించవచ్చు. అప్పుడు రెండు conventionsలో అది వేర్వేరు barsలోకి వెళ్తుంది. ఆలస్యంగా report అయిన off-exchange prints ఈ ప్రభావాన్ని మరింత పెంచుతాయి.

Nanosecond timestamps nanosecond స్థాయిలో ఖచ్చితంగా ఉంటాయా?

లేదు. Fieldలో nanosecond resolution ఉంటుంది. కానీ accuracy, timestamp రాసే machine clock ఎంత బాగా synchronise అయిందనే దానిపై ఆధారపడి ఉంటుంది. PTP ఉపయోగించే exchange మరియు processor systems sub microsecond alignmentను కలిగి ఉంటాయి. Broker business clocksకు మాత్రం 50 millisecond regulatory tolerance ఉంటుంది. ఎక్కువ tolerance ఉన్న clock పరిమితి కంటే సూక్ష్మమైన comparisons అర్థవంతమైనవి కావు.

పై ప్రతి panelతో దాన్ని రూపొందించిన SQL కూడా అందించబడుతుంది. అందువల్ల ప్రతి సంఖ్య ఏ clock నుంచి వచ్చిందో మీరు ఖచ్చితంగా చూడవచ్చు. మీ స్వంత prints windowను వేరే clock ఆధారంగా మళ్లీ sort చేసి tape ఎలా మారుతుందో చూడాలంటే, Strasmore terminalలో plain Englishలో ప్రశ్న అడగండి.