Strasmore Research
Analysen Matt ConnorVon Matt Connor

Marktdaten-Zeitstempel: SIP- oder Börsenzeit?

Vier Uhren prägen Marktdaten. Erfahren Sie, wie dieselben Trades je nach Zeitstempel ein anderes Tape ergeben und welche Uhr sich wofür eignet.

Zeitstempel in Marktdaten sind die Uhrzeiten, die einem einzelnen ausgeführten Trade zugewiesen werden, während er vom Matching Engine, die ihn ausgeführt hat, an die Anzeige weitergeleitet wird. Ein US-Aktientrade trägt im öffentlichen Datensatz drei solcher Zeitstempel. Jeder beantwortet eine andere Frage. Sortieren Sie die Prints desselben Tages zunächst nach der einen und dann nach einer anderen Uhrzeit. Sie erhalten zwei tatsächlich unterschiedliche Tapes.

Die vier Uhrzeiten eines einzelnen Prints

Ein Print erhält auf dem Weg zu Ihnen wiederholt einen Zeitstempel. Die Reihenfolge:

  1. Zeit des Matching Engine. Der Zeitpunkt, an dem die Matching Engine eines Handelsplatzes zwei Orders zusammenführt. Niemand außerhalb des Handelsplatzes kann diesen Wert direkt auslesen. Er ist die maßgebliche Zeitangabe für die Ausführung eines Trades. Jeder spätere Zeitstempel ist nur eine Annäherung daran.
  2. Teilnehmerzeit, auch Venue- oder Börsenzeit genannt. Der Zeitstempel, den der Handelsplatz beim Publizieren des Prints in seinem eigenen Feed vergibt. Er steht im Feld participant_timestamp. Von allen Werten, die Sie tatsächlich auslesen können, liegt dieser am nächsten an der Matching Engine.
  3. SIP-Zeit. Der Zeitstempel, den der Securities Information Processor vergibt, sobald der Print das konsolidierte Tape erreicht. Dabei handelt es sich um den einzigen offiziellen Feed, der alle US-Aktienhandelsplätze zusammenführt. Dieser Zeitstempel steht im Feld sip_timestamp. Die offizielle Reihenfolge des Tapes richtet sich danach. Der Unterschied zwischen diesem Feed und dem Feed eines Handelsplatzes selbst wird in SIP versus direkte Börsenfeeds erläutert.
  4. Erfassungszeit. Der Zeitstempel, den Ihre eigene Netzwerkkarte beim Eintreffen des Pakets vergibt. Er erscheint in keinem Datensatz eines Anbieters, weil er Ihren Übertragungsweg und nicht den Markt beschreibt. Arbeiten zu Paketerfassung und Replay basieren vollständig auf dieser Uhrzeit.

Außerbörsliche Prints tragen einen fünften Zeitstempel, trf_timestamp. Er zeigt an, wann eine Trade Reporting Facility die Meldung erhalten hat.

Warum Zeitstempel von Marktdaten zwischen Handelsplätzen voneinander abweichen

Die Differenz zwischen dem Zeitstempel eines Handelsplatzes und dem konsolidierten Zeitstempel entspricht der Zeit, die ein Print für die Übertragung und in der Warteschlange des Prozessors benötigt. Es handelt sich nicht um einen einheitlichen Wert. Jeder Handelsplatz liegt in einer anderen Entfernung zum Prozessor, verwendet andere Hardware und hat eine andere Warteschlange. Die folgende Grafik misst diese Differenz für jeden Handelsplatz, an dem während eines festgelegten halbstündigen Zeitraums am 10. Juni 2026 AAPL gehandelt wurde.

AbfrageSIP-Empfangsverzögerung nach Handelsplatz, AAPL, 10. Juni 2026 (Mikrosekunden)
Das exakte SQL hinter jeder Zahl
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
Run this yourself

Über diese Handelsplätze hinweg betrug die größte mediane Differenz zwischen Handelsplatz- und konsolidiertem Zeitstempel 346.2 Mikrosekunden bei NYSE Arca, Inc.. Der Handelsplatz mit der geringsten Differenz lag im selben Zeitraum bei 13.7 Mikrosekunden. Besonders aussagekräftig ist die p99-Spalte: Beim langsamsten Handelsplatz erreichte sie 420.8 Mikrosekunden. Diese Ausreißer im oberen Rand der Verteilung werden vom Median nicht sichtbar.

Welchen Zeitstempel sollten Sie verwenden?

Vier Regeln decken fast alle Fälle ab.

  • Teilnehmerzeit für Mikrostrukturanalysen und Ereignisstudien. Alles, was misst, was an einem Handelsplatz geschehen ist und in welcher Reihenfolge, gehört auf die Uhr des Handelsplatzes. Die Rekonstruktion des Orderbuchs, die in MBO versus MBP bei Orderbuchdaten behandelt wird, ist mit jeder anderen Uhr unbrauchbar.
  • SIP-Zeit für alles, was mit dem offiziellen Tape übereinstimmen muss. Dazu gehören regulatorische Meldungen, die Überprüfung der Best Execution, der offizielle Börsenbeginn und -schluss sowie jede Kennzahl, die eine Gegenpartei mit dem konsolidierten Datensatz abgleichen wird.
  • Erfassungszeit nur zur Messung Ihres eigenen Übertragungswegs. Sie zeigt, wie lange die Daten bis zu Ihrem Rechner gebraucht haben. Sie sagt nichts darüber aus, wann der Trade stattgefunden hat. Außerdem stimmen zwei Rechner bei dieser Zeitangabe nie vollständig überein.
  • Mischen Sie innerhalb eines Datensatzes niemals verschiedene Uhren. Ein Join, der Quotes nach einer Uhrzeit mit Trades nach einer anderen Uhrzeit verknüpft, liefert Zahlen, die plausibel aussehen und genau in den entscheidenden Momenten scheitern.

Dieselben Prints, auf zwei Arten sortiert

Beim Sortieren wird der Unterschied konkret. Die folgende Grafik nimmt die zehn aktivsten Millisekunden dieses halben Stundenzeitraums, behält die ersten zwölf Börsenprints in der Reihenfolge des Handelsplatzes und ordnet dieselben zwölf Prints anschließend erneut nach der Reihenfolge im konsolidierten Tape. Die Tabelle ist danach sortiert, wie stark sich die Position jedes Prints zwischen den beiden Rangfolgen verändert hat.

AbfrageDieselben zwölf Prints, sortiert nach Handelsplatz-Uhr und Tape-Uhr
Das exakte SQL hinter jeder Zahl
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
Run this yourself

Die größte Differenz zwischen den beiden Rangpositionen eines Prints beträgt 6. Dieser Print verließ seinen Handelsplatz um 10:44:17.160712 und erreichte das Tape 305.7 Mikrosekunden später, um 10:44:17.161018. Dabei wechselte er von Position 6 nach der Uhr des Handelsplatzes auf Position 12 im Tape. Keine der beiden Reihenfolgen ist falsch. Sie beantworten unterschiedliche Fragen. Eine Studie zur Reihenfolge von Trades, die nach der Tape-Zeit ausgeführt wird, liest diesen Ausbruch in einer Reihenfolge, die kein Handelsplatz erzeugt hat. Eine Best-Execution-Prüfung nach der Uhr des Handelsplatzes weicht dagegen vom offiziellen Datensatz ab.

Außerbörsliche Prints treffen weit nach dem Ereignis ein

Ein Trade, der außerhalb einer Börse bei einem Wholesale-Händler oder in einem Dark Pool ausgeführt wird, wird einer Trade Reporting Facility gemeldet. Er wird nicht in einem öffentlichen Orderbuch zusammengeführt. Die Meldung enthält die Ausführungszeit und erreicht das Tape erst danach. Dieses Intervall ist eine Meldeverzögerung und keine Übertragungszeit. Es ist um Größenordnungen größer.

AbfrageAußerbörsliche AAPL-Prints nach Meldeverzögerung, 10. Juni 2026
Das exakte SQL hinter jeder Zahl
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
Run this yourself

Von den außerbörslichen AAPL-Prints in diesem Zeitraum fallen 24.8% in das Bucket under 1 ms. Die längste Verzögerung reicht bis zum Bucket 1 s to 10 s, das 74 Prints enthält. Ein Print, der zehn Sekunden verspätet eintrifft, trägt weiterhin die Zeit des Handelsplatzes, zu der er tatsächlich ausgeführt wurde. Im Stream des Tapes liegt er jedoch zehn Sekunden dahinter. Nach Tape-Zeit sortiert, erscheint er in der falschen Minute. Prints, die außerhalb der normalen Reihenfolge gemeldet werden, tragen Sale-Condition-Codes, die darauf hinweisen. Dies ist einer der Zwecke von Trade-Condition-Codes.

Warum zwei Personen aus denselben Trades unterschiedliche Bars erstellen

Fast jedes Ticket mit dem Hinweis „Die Daten sind falsch“ führt zu diesem Problem. Eine Bar ist ein Bucket von Prints. In welches Bucket ein Print fällt, hängt davon ab, nach welchem Zeitstempel Sie ihn zuordnen. Die folgende Grafik zählt die Prints, die beim Wechsel von der Uhr des Handelsplatzes zur Tape-Zeit in ein anderes Bucket fallen. Betrachtet werden vier gängige Bar-Längen.

AbfragePrints, die beim Wechsel der Uhren den Bar ändern, nach Bar-Länge
Das exakte SQL hinter jeder Zahl
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
Run this yourself

Bei einer 1 second-Einteilung fallen 8.966% der Prints in diesem Zeitraum unter den beiden Uhren in unterschiedliche Bars. Insgesamt betrifft das 8944 Prints. Wird die Bar auf 5 minutes verlängert, sinkt der Wert auf 0.024%. Das Muster ist mechanisch: Ein Print wechselt das Bucket, sobald die Differenz zwischen seinen Zeitstempeln eine Grenze überschreitet. Kürzere Bars enthalten mehr Grenzen. Zwei Anbieter können daher beide korrekte Daten liefern und für dieselbe Minute dennoch ein unterschiedliches Volumen ausweisen. Die Erstellung wird in der Erstellung von OHLCV-Bars Schritt für Schritt erläutert.

Ein Nanosekundenfeld bedeutet keine Genauigkeit im Nanosekundenbereich

Beide Zeitstempel werden als Ganzzahlen mit Nanosekundenauflösung übermittelt. Die Auflösung beschreibt, was ein Feld darstellen kann. Die Genauigkeit beschreibt, wie nahe der Wert an der tatsächlichen Zeit liegt. Beides wird durch völlig unterschiedliche Faktoren bestimmt.

Die Uhren-Synchronisierung in der Branche richtet sich nach regulatorischen Toleranzen und nicht nach physikalischen Grenzen. Die FINRA-Regel zur Uhrensynchronisierung verpflichtet Mitgliedsunternehmen, ihre Geschäftsuhren innerhalb von 50 Millisekunden zur NIST-Referenz zu halten. Börsen und Prozessoren arbeiten mit deutlich höherer Präzision. Sie nutzen das Precision Time Protocol (PTP, standardisiert als IEEE 1588), das eine Referenzuhr über dasselbe Netzwerk verteilt, über das auch die Daten übertragen werden. Dadurch bleiben die Rechner mit einer Abweichung von weniger als einer Mikrosekunde synchron.

Daraus folgen zwei Punkte. Innerhalb der Zeitstempel einer Organisation ist eine Reihenfolge auf Mikrosekundenebene aussagekräftig. Zwischen Organisationen liegt eine Differenz von einigen hundert Nanosekunden innerhalb der Fehlergrenze. Sie als tatsächliche Reihenfolge zu interpretieren, bedeutet, Rauschen als Signal zu lesen.

FAQ

Was ist der Unterschied zwischen SIP-Zeitstempel und Teilnehmerzeitstempel?

Der Handelsplatz vergibt den Teilnehmerzeitstempel, wenn er einen Trade in seinem eigenen Feed veröffentlicht. Der Prozessor des konsolidierten Tapes vergibt den SIP-Zeitstempel, sobald dieser Trade den offiziellen zusammengeführten Feed erreicht. Die Differenz entspricht der Übertragungs- und Warteschlangenzeit. Bei Börsenprints wird sie in Mikrosekunden gemessen. Bei Prints, die über eine Trade Reporting Facility gemeldet werden, beträgt sie häufig Millisekunden oder mehr.

Welchen Zeitstempel von Marktdaten sollte ich für Backtests verwenden?

Verwenden Sie den Teilnehmerzeitstempel für alles, was modelliert, was ein Marktteilnehmer an einem Handelsplatz hätte sehen oder ausführen können. Verwenden Sie den SIP-Zeitstempel für alles, was mit dem offiziellen konsolidierten Datensatz übereinstimmen muss. Unabhängig von Ihrer Wahl müssen Sie ihn auf jede Tabelle der Studie anwenden, einschließlich der Quotes.

Warum stimmen meine Ein-Minuten-Bars nicht mit denen meines Datenanbieters überein?

Die übliche Ursache ist eine Abweichung bei den Zeitstempeln. Ein Print, dessen Zeitstempel des Handelsplatzes knapp vor einer Minutengrenze liegt, kann einen Tape-Zeitstempel knapp danach tragen. Nach den beiden Konventionen fällt derselbe Trade dadurch in unterschiedliche Bars. Spät gemeldete außerbörsliche Prints verstärken den Effekt.

Sind Zeitstempel mit Nanosekundenauflösung auf die Nanosekunde genau?

Nein. Das Feld verfügt über eine Auflösung von Nanosekunden. Die Genauigkeit hängt davon ab, wie gut die Uhr des erfassenden Rechners synchronisiert ist. Börsen- und Prozessorsysteme mit PTP erreichen eine Synchronisierung von weniger als einer Mikrosekunde. Die Geschäftsuhren von Brokern unterliegen einer regulatorischen Toleranz von 50 Millisekunden. Vergleiche, die genauer sind als die Toleranz der weniger präzisen Uhr, sind nicht aussagekräftig.


Jede Grafik oben wird zusammen mit der SQL-Abfrage ausgeliefert, die sie erzeugt hat. So können Sie genau sehen, aus welcher Uhrzeit die jeweilige Zahl stammt. Um Ihren eigenen Print-Zeitraum nach einer anderen Uhrzeit neu zu sortieren und die Veränderung des Tapes zu beobachten, formulieren Sie die Frage in Klartext im Strasmore-Terminal.

#market data#timestamps#sip#latency#data quality