Market Data Timestamp: SIP বনাম Exchange Clock

Market data timestamp হলো কোনো একক trade print matching engine-এ সম্পাদিত হওয়ার পর তা প্রদর্শনকারী স্ক্রিনে পৌঁছানো পর্যন্ত বিভিন্ন ধাপে বসানো সময়চিহ্ন। US equity trade-এর public record-এ এমন 3টি timestamp থাকে, এবং প্রতিটি আলাদা প্রশ্নের উত্তর দেয়। একই দিনের prints একটি clock অনুযায়ী সাজিয়ে আবার অন্য clock অনুযায়ী সাজালে প্রকৃতপক্ষে 2টি ভিন্ন tape পাওয়া যায়।

একটি print যে 4টি clock অতিক্রম করে

একটি print আপনার কাছে পৌঁছানোর পথে একাধিকবার timestamp পায়। ক্রমানুসারে:

1. Matching engine time। কোনো venue-এর matching engine যে মুহূর্তে 2টি order match করে। Venue-এর বাইরের কেউ এই value সরাসরি পড়তে পারে না। Trade কখন ঘটেছে, তার প্রকৃত ভিত্তি এটি; পরের প্রতিটি clock সেই সময়ের আনুমানিক হিসাব।
2. Participant time, যাকে venue বা exchange time-ও বলা হয়। Venue নিজস্ব feed-এ print প্রকাশ করার সময় যে timestamp লেখে, সেটি participant_timestamp field-এ থাকে। বাস্তবে আপনি যে timestamp পড়তে পারেন, তার মধ্যে এটিই matching engine-এর সবচেয়ে কাছাকাছি।
3. SIP time। Print consolidated tape-এ পৌঁছালে securities information processor যে timestamp লেখে। এটি US equity-এর প্রতিটি venue-এর data একত্র করা একক official feed। এটি sip_timestamp field, এবং official tape-এর sequence এই timestamp অনুসরণ করে। ওই feed এবং venue-এর নিজস্ব feed-এর পার্থক্য SIP বনাম direct exchange feeds-এ ব্যাখ্যা করা হয়েছে।
4. Capture time। Packet আপনার নিজস্ব network card-এ পৌঁছালে সেটি যে timestamp লেখে। এটি কোনো vendor-এর record-এ থাকে না, কারণ এটি market-এর নয়, আপনার data path-এর বর্ণনা দেয়। Packet capture এবং replay-সংক্রান্ত কাজ সম্পূর্ণভাবে এই clock-এর ওপর নির্ভর করে।

Exchange-এর বাইরে সম্পাদিত prints-এ 5ম timestamp, trf_timestamp, থাকে। এটি trade reporting facility report গ্রহণ করার সময় নির্দেশ করে।

Venue ভেদে market data timestamp কেন আলাদা হয়

Venue-এর timestamp এবং consolidated timestamp-এর ব্যবধান হলো print-এর transit time এবং processor-এর queue-তে কাটানো সময়। এটি একক কোনো সংখ্যা নয়। প্রতিটি venue processor থেকে আলাদা দূরত্বে থাকে, ভিন্ন hardware ব্যবহার করে এবং ভিন্ন queue-এর পেছনে থাকে। নিচের panel-এ 10 June 2026-এ নির্দিষ্ট 30 মিনিটে AAPL print করা প্রতিটি venue-এর এই ব্যবধান মাপা হয়েছে।

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

ওই venue-গুলোর মধ্যে venue timestamp এবং consolidated timestamp-এর median ব্যবধান সবচেয়ে বেশি ছিল 346.2 microseconds, NYSE Arca, Inc.-এ। একই সময়সীমায় সবচেয়ে কম ব্যবধানের venue-এ তা ছিল 13.7 microseconds। যে column-টির দিকে বিশেষভাবে নজর দেওয়া উচিত, সেটি হলো p99: একই slowest venue-এর ক্ষেত্রে তা 420.8 microseconds-এ পৌঁছেছিল। Median এই tail-এর তথ্য আড়াল করে।

কোন timestamp ব্যবহার করবেন

প্রায় সব পরিস্থিতির জন্য 4টি নিয়ম যথেষ্ট।

• Microstructure analysis এবং event study-এর জন্য 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 ব্যবহার করুন।
• নিজস্ব data path মাপার জন্য কেবল capture time। Data আপনার machine-এ পৌঁছাতে কত সময় লেগেছে, এটি তা জানায়। Trade কখন ঘটেছে, তা জানায় না। 2টি machine কখনও capture time-এ একমত হবে না।
• একটি dataset-এর মধ্যে কখনও clock মেশাবেন না। এক clock-এ quotes এবং অন্য clock-এ trades মিলিয়ে করা join এমন সংখ্যা দিতে পারে যা বিশ্বাসযোগ্য দেখায়, কিন্তু গুরুত্বপূর্ণ মুহূর্তেই ভুল প্রমাণিত হয়।

একই prints, 2ভাবে সাজানো

Sorting-এর সময় এই ধারণাগত পার্থক্যটি স্পষ্ট হয়। নিচের panel-এ ওই 30 মিনিটের সবচেয়ে ব্যস্ত 10 milliseconds নেওয়া হয়েছে। Venue order অনুযায়ী exchange prints-এর প্রথম 12টি রাখা হয়েছে। এরপর একই 12টি consolidated tape order অনুযায়ী আবার rank করা হয়েছে। 2টি ranking-এর মধ্যে প্রতিটি 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-এর 2টি rank-এর মধ্যে সর্বাধিক ব্যবধান ছিল 6। Print-টি তার venue থেকে 10:44:17.160712-এ বেরিয়ে tape-এ পৌঁছায় 305.7 microseconds পরে, 10:44:17.161018-এ। Venue clock-এ তার position ছিল 6, tape-এ তা হয় 12। কোনো ordering-ই ভুল নয়। তারা আলাদা প্রশ্নের উত্তর দেয়। Tape clock ব্যবহার করে করা trade sequence study এমন একটি ক্রম দেখায়, যা কোনো venue কখনও তৈরি করেনি। Venue clock ব্যবহার করে করা best execution review official record-এর সঙ্গে অমিল দেখাতে পারে।

Exchange-এর বাইরে সম্পাদিত prints event-এর অনেক পরে tape-এ আসে

Exchange-এর বাইরে, কোনো wholesaler বা dark pool-এ সম্পাদিত trade public order book-এ match না হয়ে trade reporting facility-তে report করা হয়। Report-এ execution time থাকে, কিন্তু সেটি পরে tape-এ পৌঁছায়। এই ব্যবধান travel time নয়, reporting 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

ওই সময়সীমার off exchange AAPL prints-এর মধ্যে 24.8%টি under 1 ms bucket-এ পড়েছে। Tail 1 s to 10 s bucket পর্যন্ত বিস্তৃত, যেখানে 74টি print রয়েছে। 10 seconds দেরিতে আসা কোনো print-এ তার প্রকৃত execution-এর venue clock time-ই থাকে, কিন্তু tape stream-এ সেটি execution-এর 10 seconds পরে অবস্থান করে। Tape time অনুযায়ী সাজালে print-টি ভুল minute-এ দেখা যায়। স্বাভাবিক sequence-এর বাইরে report করা prints-এ sale condition code থাকে, যা এই বিষয়টি চিহ্নিত করে। এই কারণেই trade condition codes গুরুত্বপূর্ণ।

একই trades থেকে 2 জন কেন আলাদা bars তৈরি করেন

প্রায় সব “data is wrong” ticket-এর মূল কারণ এখানেই। একটি bar হলো prints-এর একটি bucket। কোনো print কোন bucket-এ পড়বে, তা নির্ভর করে কোন timestamp অনুযায়ী bucket করা হচ্ছে তার ওপর। Venue clock থেকে tape clock-এ বদলালে 4টি প্রচলিত bar length-এ কত prints-এর bucket বদলে যায়, নিচের panel-এ তা গণনা করা হয়েছে।

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-এ ওই সময়সীমার 8.966% prints 2টি clock-এর অধীনে আলাদা bar-এ পড়ে; মোট prints ছিল 8944। Bar-এর দৈর্ঘ্য 5 minutes করা হলে এই সংখ্যা কমে 0.024% হয়। কারণটি যান্ত্রিক: কোনো print-এর 2টি timestamp-এর ব্যবধান একটি boundary অতিক্রম করলেই তার bucket বদলে যায়। ছোট bar-এ boundary বেশি থাকে। তাই 2টি vendor একইভাবে সঠিক থেকেও একই minute-এর জন্য আলাদা volume প্রকাশ করতে পারে। এই construction প্রক্রিয়া OHLCV bars কীভাবে তৈরি করা হয়-এ ধাপে ধাপে দেখানো হয়েছে।

Nanosecond field মানেই nanosecond accuracy নয়

2টি timestamp-ই nanosecond resolution-সহ integer হিসেবে আসে। Resolution হলো কোনো field কত সূক্ষ্ম সময় প্রকাশ করতে পারে। Accuracy হলো value-টি প্রকৃত সময়ের কতটা কাছাকাছি। এই 2টি বিষয় সম্পূর্ণ ভিন্ন উপাদানের ওপর নির্ভর করে।

Industry-wide clock alignment physics নয়, regulatory tolerance দ্বারা নিয়ন্ত্রিত। FINRA-এর clock synchronization rule অনুযায়ী member firm-এর business clock NIST reference time থেকে 50 milliseconds-এর মধ্যে থাকতে হবে। Exchange এবং processor আরও কঠোর synchronization ব্যবহার করে। তারা Precision Time Protocol (PTP, IEEE 1588 হিসেবে standardised) ব্যবহার করে, যা data বহনকারী একই network-এর মাধ্যমে reference clock বিতরণ করে এবং machine-গুলোর alignment sub microsecond পর্যায়ে রাখে।

এর 2টি ফল রয়েছে। একই organisation-এর timestamp-গুলোর মধ্যে microsecond resolution-এ ordering অর্থবহ। কিন্তু ভিন্ন organisation-এর timestamp-এর মধ্যে কয়েকশ nanoseconds-এর পার্থক্য error bar-এর মধ্যেই পড়ে। সেটিকে প্রকৃত ordering হিসেবে ব্যাখ্যা করা noise পড়ার সমান।

FAQ

SIP timestamp এবং participant timestamp-এর মধ্যে পার্থক্য কী?

Venue নিজস্ব feed-এ trade প্রকাশ করার সময় participant timestamp লেখে। Trade official combined feed-এ পৌঁছালে consolidated tape processor SIP timestamp লেখে। 2টির ব্যবধান 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-ই বেছে নিন, study-এর প্রতিটি table-এ সেটিই ব্যবহার করুন, quotes-সহ।

আমার one minute bars data provider-এর bars-এর সঙ্গে মেলে না কেন?

সাধারণত কারণ হলো clock mismatch। কোনো print-এর venue timestamp minute boundary-এর ঠিক আগে হতে পারে, কিন্তু tape timestamp boundary-এর ঠিক পরে হতে পারে। ফলে 2টি convention-এ একই trade আলাদা bar-এ পড়ে। দেরিতে report করা off exchange prints এই পার্থক্য আরও বাড়ায়।

Nanosecond timestamp কি nanosecond পর্যন্ত accurate?

না। Field-টি nanosecond resolution ধরে রাখে। Accuracy নির্ভর করে timestamp লেখার machine-এর clock কতটা সঠিকভাবে synchronized তার ওপর। PTP ব্যবহারকারী exchange এবং processor system sub microsecond alignment বজায় রাখে। Broker-এর business clock-এর ক্ষেত্রে regulatory tolerance 50 milliseconds। যে clock-এর tolerance বেশি, তার সীমার চেয়ে সূক্ষ্ম comparison অর্থবহ নয়।

উপরের প্রতিটি panel-এর সঙ্গে তা তৈরি করা SQL দেওয়া হয়েছে। ফলে প্রতিটি number কোন clock থেকে এসেছে, তা আপনি নির্দিষ্টভাবে দেখতে পারবেন। নিজের prints-এর কোনো সময়সীমা অন্য clock অনুযায়ী আবার সাজিয়ে tape কীভাবে বদলে যায় তা দেখতে Strasmore terminal-এ plain English-এ প্রশ্ন করুন।