Verschil tussen SIP en exchange timestamps uitgelegd

Market data-timestamps zijn de klokken die op een trade-print worden gestempeld terwijl deze van de matching engine die de transactie uitvoerde naar het scherm reist waarop deze wordt getoond. Een Amerikaanse aandelentransactie draagt er in het openbare register drie, en elk daarvan beantwoordt een andere vraag. Sorteer de prints van dezelfde dag op de ene klok en vervolgens op de andere, en u houdt twee wezenlijk verschillende tapes over.

De vier klokken die een print passeert

Een print krijgt onderweg naar u herhaaldelijk een stempel. In volgorde:

1. Matching engine-tijd. Het moment waarop de matching engine van een handelsplatform twee orders bij elkaar bracht. Niemand buiten het platform leest deze waarde direct uit. Het is de absolute waarheid over wanneer een transactie plaatsvond, en elke klok daarna is een benadering daarvan.
2. Participant-tijd, ook wel venue- of exchange-tijd genoemd. De stempel die het handelsplatform plaatst wanneer het de print op zijn eigen feed publiceert, vervat in het participant_timestamp-veld. Van alles wat u daadwerkelijk kunt uitlezen, staat dit het dichtst bij de matching engine.
3. SIP-tijd. De stempel die de securities information processor plaatst wanneer de print de consolidated tape bereikt, de enige officiële feed die alle Amerikaanse aandelenhandelsplatformen samenvoegt. Dit is het sip_timestamp-veld, en de officiële tape-volgorde volgt deze tijd. Het verschil tussen die feed en de eigen feed van een handelsplatform wordt behandeld in SIP versus directe exchange-feeds.
4. Capture-tijd. De stempel die uw eigen netwerkkaart plaatst wanneer het datapakket binnenkomt. Deze verschijnt nooit in het register van een vendor, aangezien deze uw eigen pad beschrijft in plaats van de markt. Het werk rond Packet capture en replay draait volledig op deze klok.

Prints buiten de beurs om (off exchange) dragen een vijfde stempel, trf_timestamp, die aangeeft wanneer een trade reporting facility de melding in ontvangst nam.

Waarom market data-timestamps per handelsplatform verschillen

Het gat tussen de stempel van een handelsplatform en de geconsolideerde stempel is de tijd die een print doorbracht in het transport en in de wachtrij van de processor. Dit is geen vast getal. Elk handelsplatform bevindt zich op een andere afstand van de processor, op andere hardware, achter een andere wachtrij. Het onderstaande paneel meet dat gat voor elk handelsplatform dat AAPL verwerkte gedurende een vast half uur op 10 juni 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

Over die handelsplatformen heen was het grootste mediane gat tussen de venue-stempel en de geconsolideerde stempel 346.2 microseconden, bij NYSE Arca, Inc.. Het snelste handelsplatform in hetzelfde venster zat op 13.7 microseconden. De p99-kolom is de moeite van het bekijken waard: voor datzelfde traagste handelsplatform bereikte dit 420.8 microseconden, de 'tail' die een mediaan verbergt.

Welke timestamp moet u gebruiken

Vier regels dekken bijna elk geval.

• Participant-tijd voor microstructure-onderzoek en event studies. Alles wat meet wat er op een handelsplatform gebeurde en in welke volgorde, hoort op de venue-klok. Orderboek-reconstructie, het onderwerp van MBO versus MBP orderboek-data, is op geen enkele andere klok bruikbaar.
• SIP-tijd voor alles wat moet reconciliëren met de officiële tape. Rapportages aan toezichthouders, best execution-reviews, de officiële opening en sluiting, en elk cijfer dat een tegenpartij zal controleren tegen het geconsolideerde register.
• Capture-tijd alleen voor het meten van uw eigen pad. Het vertelt u hoe lang data erover deed om uw machine te bereiken. Het vertelt u niets over wanneer de transactie plaatsvond, en twee machines zijn het hier nooit over eens.
• Combineer nooit klokken binnen één dataset. Een join die quotes op de ene klok matcht tegen transacties op de andere, levert cijfers op die plausibel lijken maar falen op precies de momenten die ertoe doen.

Dezelfde prints, op twee manieren gesorteerd

Sorteren is waar de abstractie breekt. Het onderstaande paneel neemt de drukste tien milliseconden van dat half uur, behoudt de eerste twaalf on-exchange prints in de volgorde van het handelsplatform, en rangschikt vervolgens diezelfde twaalf opnieuw in de volgorde van de consolidated tape. De tabel is gesorteerd op basis van hoezeer elke print verschoof tussen de twee rangschikkingen.

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

Het grootste gat tussen de twee rangschikkingen van een print is 6. Die print verliet zijn handelsplatform op 10:44:17.160712 en bereikte de tape 305.7 microseconden later, op 10:44:17.161018, waarbij deze verschoof van positie 6 op de venue-klok naar positie 12 op de tape. Geen van beide volgordes is fout. Ze beantwoorden verschillende vragen. Een transactievolgorde-onderzoek op basis van de tape-klok leest deze burst in een volgorde die geen enkel handelsplatform ooit heeft geproduceerd, en een best execution-review op basis van de venue-klok is in strijd met het officiële register.

Off-exchange prints komen ver na de gebeurtenis binnen

Een transactie die buiten een beurs om wordt uitgevoerd, bij een wholesaler of in een dark pool, wordt gemeld aan een trade reporting facility in plaats van gematcht in een openbaar orderboek. De melding draagt de uitvoeringstijd, en komt daarna pas aan op de tape. Dat interval is eerder een rapportagevertraging dan reistijd, en is vele malen groter.

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

Van de off-exchange AAPL-prints in dat venster landt 24.8% in de under 1 ms-bucket. De 'tail' loopt door tot de 1 s to 10 s-bucket, met daarin 74 prints. Een print die tien seconden te laat aankomt, draagt nog steeds de venue-kloktijd van de daadwerkelijke uitvoering, terwijl deze in de tape-stroom tien seconden verderop staat. Sorteer op tape-tijd en de print verschijnt in de verkeerde minuut. Prints die buiten de normale volgorde worden gerapporteerd, dragen sale condition-codes die dit aangeven; dit is een van de zaken waarvoor trade condition-codes bestaan.

Waarom twee mensen verschillende bars bouwen van dezelfde transacties

Bijna elk ticket met de melding "de data klopt niet" belandt hier. Een bar is een verzameling prints, en de bucket waarin een print valt, hangt af van de stempel waarop u sorteert. Het onderstaande paneel telt de prints die van bucket veranderen wanneer u overschakelt van de venue-klok naar de tape-klok, over vier gangbare bar-lengtes.

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

Op een 1 second-grid valt 8.966% van de prints in dat venster in een andere bar onder de twee klokken, in totaal 8944 prints. Rek de bar op naar 5 minutes en het cijfer daalt naar 0.024%. Het patroon is mechanisch: een print verandert van bucket zodra het klokverschil een grens overschrijdt, en kortere bars bevatten meer grenzen. Twee vendors kunnen beiden gelijk hebben en toch een verschillend volume publiceren voor dezelfde minuut. De constructie zelf wordt doorlopen in hoe OHLCV-bars worden gebouwd.

Een nanoseconden-veld is geen nanoseconden-nauwkeurigheid

Beide stempels komen binnen als gehele getallen met een resolutie van nanoseconden. Resolutie is wat een veld kan uitdrukken. Nauwkeurigheid is hoe dicht de waarde bij de werkelijke tijd ligt, en beide worden door totaal verschillende zaken bepaald.

Kloksynchronisatie in de sector wordt beheerst door wettelijke tolerantie in plaats van door de natuurkunde. De kloksynchronisatieregel van FINRA houdt de zakelijke klokken van lidfirma's binnen vijftig milliseconden van de NIST-referentie. Handelsplatformen en processors werken veel nauwkeuriger met het Precision Time Protocol (PTP, gestandaardiseerd als IEEE 1588), dat een referentieklok verspreidt over hetzelfde netwerk dat de data transporteert en machines binnen een sub-microseconde synchroniseert.

Twee dingen volgen hieruit. Binnen de stempels van één organisatie is ordening op microseconden-resolutie zinvol. Tussen organisaties in ligt een verschil van een paar honderd nanoseconden tussen twee stempels binnen de foutmarge, en dit behandelen als een werkelijke volgorde is ruis lezen.

Veelgestelde vragen

Wat is het verschil tussen de SIP-timestamp en de participant-timestamp?

De participant-timestamp wordt geschreven door het handelsplatform wanneer het een transactie publiceert op zijn eigen feed. De SIP-timestamp wordt geschreven door de consolidated tape processor wanneer die transactie de officiële gecombineerde feed bereikt. Het gat daartussen is transport- en wachtrijtijd, gemeten in microseconden voor on-exchange prints en vaak in milliseconden of langer voor prints die via een trade reporting facility worden gerapporteerd.

Welke market data-timestamp moet ik gebruiken voor backtesting?

Gebruik de participant-timestamp voor alles wat modelleert wat een deelnemer op een handelsplatform had kunnen zien of doen, en de SIP-timestamp voor alles wat moet reconciliëren met het officiële geconsolideerde register. Welke u ook kiest, pas deze toe op elke tabel in het onderzoek, inclusief quotes.

Waarom komen mijn één-minuut-bars niet overeen met die van mijn dataleverancier?

Een klokverschil is meestal het antwoord. Een print waarvan de venue-stempel net voor een minuutgrens valt, kan een tape-stempel net daarna hebben, waardoor dezelfde transactie onder de twee conventies in verschillende bars terechtkomt. Te laat gerapporteerde off-exchange prints vergroten dit effect.

Zijn nanoseconden-timestamps nauwkeurig tot op de nanoseconde?

Nee. Het veld bevat nanoseconden-resolutie, en de nauwkeurigheid wordt bepaald door hoe goed de klok van de schrijvende machine is gesynchroniseerd. Systemen van handelsplatformen en processors die PTP gebruiken, houden een sub-microseconde synchronisatie aan, terwijl zakelijke klokken van brokers worden gehouden aan een wettelijke tolerantie van vijftig milliseconden. Vergelijkingen die fijner zijn dan de tolerantie van de minst nauwkeurige klok zijn niet zinvol.

Elk paneel hierboven wordt geleverd met de SQL die het heeft geproduceerd, zodat u precies kunt zien van welke klok elk cijfer afkomstig is. Om uw eigen venster met prints opnieuw te sorteren onder een andere klok en te zien hoe de tape verandert, stelt u de vraag in begrijpelijke taal op de Strasmore-terminal.