Market Data Timestamps: SIP یا Exchange Clocks؟

Market data timestamps وہ clocks ہیں جو ایک single trade print پر اس وقت ثبت ہوتے ہیں جب وہ اسے execute کرنے والے matching engine سے اس screen تک پہنچتا ہے جہاں اسے دکھایا جاتا ہے۔ US equity trade کے public record میں ایسے تین timestamps ہوتے ہیں، اور ہر timestamp ایک مختلف سوال کا جواب دیتا ہے۔ ایک ہی دن کے prints کو پہلے ایک clock اور پھر دوسری clock کے مطابق sort کریں، تو آپ کے پاس حقیقتاً دو مختلف tapes آتی ہیں۔

ایک print سے گزرنے والی چار clocks

آپ تک پہنچنے سے پہلے ایک print پر بار بار timestamp ثبت ہوتا ہے۔ ترتیب یہ ہے:

1. Matching engine time۔ یہ وہ لمحہ ہے جب کسی venue کے matching engine نے دو orders کو cross کیا۔ Venue سے باہر کوئی شخص یہ value براہِ راست نہیں پڑھ سکتا۔ یہی اس بات کی حقیقی بنیاد ہے کہ trade کب ہوا، اور اس کے بعد آنے والی ہر clock اسی کی approximation ہوتی ہے۔
2. Participant time، جسے venue یا exchange time بھی کہا جاتا ہے۔ یہ وہ timestamp ہے جو venue اپنے feed پر print publish کرتے وقت لکھتا ہے، اور یہ participant_timestamp field میں ہوتا ہے۔ جن values کو آپ حقیقتاً پڑھ سکتے ہیں، ان میں یہ matching engine کے سب سے قریب ہوتی ہے۔
3. SIP time۔ یہ وہ timestamp ہے جو securities information processor اس وقت لکھتا ہے جب print consolidated tape تک پہنچتا ہے۔ Consolidated tape وہ واحد official feed ہے جو US equity venues کو یکجا کرتا ہے۔ یہ sip_timestamp field ہے، اور official tape sequence اسی کے مطابق ہوتی ہے۔ اس feed اور venue کے اپنے feed کے درمیان فرق SIP اور direct exchange feeds کا تقابل میں بیان کیا گیا ہے۔
4. Capture time۔ یہ وہ timestamp ہے جو packet آپ کے network card پر پہنچنے کے وقت آپ کا اپنا system لکھتا ہے۔ یہ 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 کے درمیان فرق وہ وقت ہے جو print نے transit اور processor کی queue میں گزارا۔ یہ ایک مستقل number نہیں ہوتا۔ ہر venue processor سے مختلف فاصلے پر واقع ہوتا ہے، مختلف hardware استعمال کرتا ہے اور مختلف queue کے پیچھے ہوتا ہے۔ ذیل کا panel ہر اس venue کے لیے یہ فرق ناپتا ہے جس نے 10 June 2026 کو مقررہ آدھے گھنٹے کے دوران AAPL میں print کیا۔

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 تک پہنچا، یعنی وہ tail جسے median چھپا دیتا ہے۔

آپ کو کون سا timestamp استعمال کرنا چاہیے

تقریباً ہر صورت کے لیے چار اصول کافی ہیں۔

• Microstructure research اور event studies کے لیے participant time۔ Venue پر کیا ہوا اور کس ترتیب سے ہوا، اس کی پیمائش venue clock کے مطابق ہونی چاہیے۔ Order book reconstruction، جس کا موضوع MBO اور MBP order book data کا تقابل ہے، کسی دوسری clock پر قابلِ استعمال نہیں رہتی۔
• ہر اس کام کے لیے SIP time جسے official tape سے reconcile کرنا ہو۔ اس میں regulatory reporting، best execution review، official open اور close، اور وہ ہر figure شامل ہے جسے counterparty consolidated record سے verify کرے گا۔
• Capture time صرف اپنے data path کی پیمائش کے لیے۔ یہ بتاتا ہے کہ data کو آپ کی machine تک پہنچنے میں کتنا وقت لگا۔ یہ نہیں بتاتا کہ trade کب ہوا، اور دو machines اس value پر کبھی متفق نہیں ہوتیں۔
• ایک dataset کے اندر clocks کو کبھی mix نہ کریں۔ اگر quotes کو ایک clock پر اور trades کو دوسری clock پر match کیا جائے، تو ایسے numbers ملتے ہیں جو بظاہر درست لگتے ہیں، مگر عین اہم لمحات پر ناکام ہو جاتے ہیں۔

وہی prints، دو طریقوں سے sorted

Sorting کے مرحلے پر یہ فرق واضح ہو جاتا ہے۔ ذیل کا panel اس آدھے گھنٹے کے مصروف ترین ten milliseconds لیتا ہے، venue order میں exchange prints میں سے پہلے twelve برقرار رکھتا ہے، اور پھر انہی twelve کو consolidated tape order میں دوبارہ rank کرتا ہے۔ Table کو اس بنیاد پر sort کیا گیا ہے کہ ہر print دونوں rankings کے درمیان کتنی جگہ منتقل ہوا۔

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 کی دونوں rankings کے درمیان سب سے بڑا فرق 6 ہے۔ یہ print اپنے venue سے 10:44:17.160712 پر نکلا اور 305.7 microseconds بعد 10:44:17.161018 پر tape تک پہنچا۔ Venue clock پر یہ position 6 سے tape پر position 12 پر منتقل ہوا۔ دونوں orderings غلط نہیں ہیں۔ وہ مختلف سوالات کے جواب دیتی ہیں۔ Tape clock پر کی جانے والی trade sequence study اس burst کو ایسی ترتیب میں پڑھے گی جو کسی venue نے کبھی پیدا نہیں کی، جبکہ venue clock پر کی جانے والی best execution review official record سے مختلف ہو گی۔

Off exchange prints واقعے کے بہت بعد پہنچتے ہیں

Exchange سے باہر، کسی wholesaler یا dark pool میں execute ہونے والا trade public book پر match نہیں ہوتا۔ اسے trade reporting facility کو report کیا جاتا ہے۔ Report میں execution time موجود ہوتا ہے، مگر یہ بعد میں tape تک پہنچتی ہے۔ یہ وقفہ travel time نہیں بلکہ reporting delay ہوتا ہے، اور اس کا حجم کئی orders 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

اس 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 رکھتا ہے جس وقت trade حقیقتاً execute ہوا تھا، لیکن tape کے stream میں اس سے دس seconds آگے دکھائی دیتا ہے۔ Tape time کے مطابق sort کرنے پر یہ غلط minute میں نظر آتا ہے۔ معمول کی sequence سے باہر report کیے گئے prints sale condition codes رکھتے ہیں جو اس بات کی نشاندہی کرتے ہیں۔ یہی ان چیزوں میں سے ایک ہے جنہیں trade condition codes flag کرتے ہیں۔

ایک ہی trades سے دو افراد مختلف bars کیوں بناتے ہیں

تقریباً ہر "data غلط ہے" ticket کا تعلق اسی مسئلے سے ہوتا ہے۔ Bar دراصل prints کا ایک bucket ہے، اور print کس bucket میں جائے گا، اس کا انحصار اس timestamp پر ہے جس کے مطابق آپ bucket بناتے ہیں۔ ذیل کا panel چار عام bar lengths میں یہ count کرتا ہے کہ venue clock سے tape clock پر switch کرنے سے کتنے prints کا bucket تبدیل ہوتا ہے۔

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 کے 8.966% prints دونوں clocks کے تحت مختلف bar میں جاتے ہیں، یعنی مجموعی طور پر 8944 prints۔ Bar کو 5 minutes تک بڑھانے پر یہ figure کم ہو کر 0.024% رہ جاتی ہے۔ Pattern mechanical ہے: جب کسی print کا clock gap کسی boundary کو cross کرتا ہے تو اس کا bucket بدل جاتا ہے، اور چھوٹی bars میں boundaries زیادہ ہوتی ہیں۔ دو vendors دونوں درست ہو سکتے ہیں اور پھر بھی ایک ہی minute کے لیے مختلف volume publish کر سکتے ہیں۔ اس construction کی مکمل وضاحت OHLCV bars کیسے بنائی جاتی ہیں میں موجود ہے۔

Nanosecond field کا مطلب nanosecond accuracy نہیں

دونوں timestamps ایسے integers کی صورت میں آتے ہیں جن کی resolution nanosecond ہوتی ہے۔ Resolution سے مراد یہ ہے کہ field کس حد تک value ظاہر کر سکتا ہے۔ Accuracy سے مراد یہ ہے کہ value حقیقی وقت کے کتنی قریب ہے۔ دونوں کو بالکل مختلف عوامل متعین کرتے ہیں۔

Industry میں clocks کی alignment physics کے بجائے regulatory tolerance کے تحت ہوتی ہے۔ FINRA کا clock synchronization rule member firms کی business clocks کو NIST reference سے 50 milliseconds کے اندر رکھتا ہے۔ Exchanges اور processors اس سے کہیں زیادہ tight alignment پر کام کرتے ہیں۔ وہ Precision Time Protocol (PTP، IEEE 1588 کے طور پر standardised) استعمال کرتے ہیں، جو data لے جانے والے اسی network پر reference clock تقسیم کرتا ہے اور machines کو sub microsecond alignment میں رکھتا ہے۔

اس کے دو نتائج نکلتے ہیں۔ ایک ہی organisation کے stamps میں microsecond resolution پر ordering معنی رکھتی ہے۔ مختلف organisations کے درمیان دو timestamps کا چند سو nanoseconds کا فرق error bar کے اندر ہوتا ہے۔ اسے حقیقی ordering سمجھنا noise کو پڑھنے کے مترادف ہے۔

سوالات و جوابات

SIP timestamp اور participant timestamp میں کیا فرق ہے؟

Participant timestamp venue اس وقت لکھتا ہے جب وہ اپنے feed پر trade publish کرتا ہے۔ SIP timestamp consolidated tape processor اس وقت لکھتا ہے جب trade official combined feed تک پہنچتا ہے۔ دونوں کے درمیان فرق transit اور queueing time ہوتا ہے۔ On exchange prints کے لیے اسے microseconds میں ناپا جاتا ہے، جبکہ trade reporting facility کے ذریعے report کیے گئے prints کے لیے یہ اکثر milliseconds یا اس سے زیادہ ہوتا ہے۔

Backtesting کے لیے کون سا market data timestamp استعمال کرنا چاہیے؟

اگر model یہ دکھاتا ہے کہ کوئی participant venue پر کیا دیکھ یا کر سکتا تھا، تو participant timestamp استعمال کریں۔ اگر data کو official consolidated record سے reconcile کرنا ہو، تو SIP timestamp استعمال کریں۔ آپ جو بھی timestamp منتخب کریں، study کی ہر table، بشمول quotes، پر وہی timestamp لاگو کریں۔

میری one minute bars میرے data provider سے match کیوں نہیں کرتیں؟

عام طور پر وجہ clock mismatch ہوتی ہے۔ جس print کا venue timestamp minute boundary سے عین پہلے ہو، اس کا tape timestamp boundary کے فوراً بعد ہو سکتا ہے۔ یوں دونوں conventions کے تحت وہی trade مختلف bars میں چلا جاتا ہے۔ Late reported off exchange prints اس فرق کو مزید بڑھا دیتے ہیں۔

کیا nanosecond timestamps nanosecond تک accurate ہوتے ہیں؟

نہیں۔ Field میں nanosecond resolution ہوتی ہے، جبکہ accuracy اس بات پر منحصر ہوتی ہے کہ writing machine کی clock کتنی اچھی طرح synchronised ہے۔ PTP استعمال کرنے والے exchange اور processor systems sub microsecond alignment برقرار رکھتے ہیں، جبکہ broker business clocks کے لیے regulatory tolerance 50 milliseconds ہے۔ زیادہ ڈھیلی clock کی tolerance سے بھی باریک comparisons معنی خیز نہیں ہوتے۔

اوپر موجود ہر panel کے ساتھ وہ SQL بھی فراہم کی جاتی ہے جس سے اسے تیار کیا گیا، تاکہ آپ بالکل دیکھ سکیں کہ ہر number کس clock سے آیا ہے۔ اپنے prints کی window کو کسی دوسری clock کے مطابق دوبارہ sort کرنے اور tape کو تبدیل ہوتے دیکھنے کے لیے Strasmore terminal پر سوال plain English میں درج کریں۔