Временные метки рыночных данных: SIP против часов биржи

Временные метки рыночных данных — это отметки времени, которые присваиваются сделке в момент её прохождения от торгового ядра, где она была исполнена, до экрана, на котором она отображается. В официальной отчетности по акциям США каждая сделка имеет три такие метки, и каждая из них отвечает на свой вопрос. Если отсортировать сделки за один день сначала по одним часам, а затем по другим, вы получите две принципиально разные ленты сделок.

Четыре временные метки одной сделки

Сделка получает несколько отметок по пути к вам. В хронологическом порядке:

1. Время торгового ядра (Matching engine time). Момент, когда торговое ядро площадки свело две заявки. Никто за пределами площадки не видит это значение напрямую. Это истинное время совершения сделки, а все последующие метки являются лишь его приближением.
2. Время участника (Participant time), также называемое временем площадки или биржи. Метка, которую площадка ставит при публикации сделки в собственном потоке данных; передается в поле participant_timestamp. Из всех доступных для чтения данных эта метка ближе всего к торговому ядру.
3. Время SIP (SIP time). Метка, которую процессор рыночной информации (Securities Information Processor) ставит при попадании сделки в консолидированную ленту — единый официальный поток, объединяющий все площадки США. Это поле sip_timestamp, и именно по нему строится официальная последовательность ленты. Различия между этим потоком и прямыми потоками бирж описаны в разделе SIP против прямых биржевых потоков.
4. Время захвата (Capture time). Метка, которую ставит ваша сетевая карта в момент получения пакета. Она никогда не появляется в записях поставщиков данных, так как описывает ваш путь, а не рынок. Работа захвата и воспроизведения пакетов полностью основана на этих часах.

Внебиржевые сделки имеют пятую метку, trf_timestamp, которая фиксирует время принятия отчета центром регистрации сделок (Trade Reporting Facility).

Почему временные метки различаются на разных площадках

Разрыв между меткой площадки и консолидированной меткой — это время, которое сделка провела в пути и в очереди процессора. Это не константа. Каждая площадка находится на разном расстоянии от процессора, использует разное оборудование и стоит в разных очередях. На графике ниже измерен этот разрыв для каждой площадки, где прошла сделка по AAPL в течение фиксированного получаса 10 июня 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

Среди этих площадок самый широкий медианный разрыв между меткой площадки и консолидированной меткой составил 346.2 микросекунд на NYSE Arca, Inc.. Самая быстрая площадка в том же окне показала 13.7 микросекунд. Стоит обратить внимание на столбец p99: для той же самой медленной площадки значение достигло 420.8 микросекунд, что показывает «хвост» распределения, скрытый медианой.

Какую временную метку использовать

Почти все случаи покрываются четырьмя правилами.

• Время участника — для анализа микроструктуры и событийных исследований. Все, что измеряет происходящее на площадке и порядок событий, должно опираться на часы площадки. Реконструкция книги заявок, тема раздела данные книги заявок MBO против MBP, невозможна при использовании других меток.
• Время SIP — для всего, что должно сверяться с официальной лентой. Регуляторная отчетность, проверка качества исполнения (best execution), официальные цены открытия и закрытия, а также любые показатели, которые контрагент будет сверять с консолидированными данными.
• Время захвата — только для измерения собственного пути данных. Оно показывает, сколько времени данные шли до вашей машины. Оно ничего не говорит о времени совершения сделки, и две машины никогда не покажут одинаковый результат.
• Никогда не смешивайте часы в одном наборе данных. Объединение котировок по одним часам со сделками по другим дает цифры, которые выглядят правдоподобно, но подводят именно в критические моменты.

Одни и те же сделки, отсортированные двумя способами

Сортировка — это момент, где абстракция перестает работать. На графике ниже взяты десять самых активных миллисекунд того получаса: сначала двенадцать биржевых сделок ранжируются по времени площадки, а затем те же двенадцать — по времени консолидированной ленты. Таблица отсортирована по величине смещения каждой сделки между двумя рейтингами.

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

Максимальный разрыв между двумя позициями сделки составил 6. Эта сделка покинула площадку в 10:44:17.160712 и достигла ленты на 305.7 микросекунд позже, в 10:44:17.161018, переместившись с позиции 6 по часам площадки на позицию 12 в ленте. Ни один из вариантов сортировки не является ошибочным. Они отвечают на разные вопросы. Исследование последовательности сделок, проведенное по времени ленты, прочтет этот всплеск в порядке, который не производила ни одна площадка, а проверка качества исполнения по времени площадки будет противоречить официальным данным.

Внебиржевые сделки сильно запаздывают

Сделка, исполненная вне биржи — у маркет-мейкера или в дарк-пуле, — сообщается в центр регистрации сделок, а не сопоставляется в публичной книге заявок. Отчет содержит время исполнения, но до ленты он доходит позже. Этот интервал является задержкой отчетности, а не временем передачи, и он на порядки больше.

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

Из внебиржевых сделок по AAPL в этом окне 24.8% попадают в интервал under 1 ms. «Хвост» распределения доходит до интервала 1 s to 10 s, содержащего 74 сделок. Сделка, пришедшая с опозданием в десять секунд, все еще несет время исполнения по часам площадки, но в потоке ленты она оказывается на десять секунд позже. При сортировке по времени ленты она попадает не в ту минуту. Сделки, сообщенные вне обычной последовательности, имеют коды условий продажи, которые указывают на это; это одна из вещей, для обозначения которых существуют коды условий сделок.

Почему разные люди строят разные бары по одним и тем же сделкам

Почти каждый запрос «данные неверны» связан с этим. Бар — это корзина сделок, и то, в какую корзину попадет сделка, зависит от того, по какой метке вы ее распределяете. На графике ниже подсчитано количество сделок, которые меняют корзину при переключении с часов площадки на часы ленты для четырех стандартных таймфреймов.

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 8.966% сделок в этом окне попадают в другой бар при смене часов, всего 8944 сделок. При увеличении бара до 5 minutes это число падает до 0.024%. Механика проста: сделка меняет корзину, когда разрыв между часами пересекает границу бара, а короткие бары имеют больше границ. Два поставщика данных могут быть правы, но публиковать разный объем за одну и ту же минуту. Процесс построения подробно разобран в как строятся OHLCV-бары.

Поле наносекунд не означает наносекундную точность

Обе метки приходят как целые числа с наносекундным разрешением. Разрешение — это то, что поле может выразить. Точность — это то, насколько значение близко к истинному времени, и эти параметры определяются совершенно разными вещами.

Синхронизация часов в индустрии регулируется регуляторными допусками, а не физикой. Правило FINRA о синхронизации часов требует, чтобы бизнес-часы фирм-членов отклонялись не более чем на 50 миллисекунд от эталона NIST. Биржи и процессоры работают гораздо точнее, используя протокол точного времени (PTP, стандартизирован как IEEE 1588), который распределяет эталонное время по той же сети, что передает данные, и удерживает машины в пределах субмикросекундного отклонения.

Из этого следует два вывода. В рамках меток одной организации сортировка с микросекундным разрешением имеет смысл. Между организациями разница в несколько сотен наносекунд находится внутри погрешности, и рассматривать ее как реальный порядок — значит принимать шум за сигнал.

Часто задаваемые вопросы

В чем разница между временной меткой SIP и временной меткой участника?

Временная метка участника ставится площадкой при публикации сделки в собственном потоке. Временная метка SIP ставится процессором консолидированной ленты, когда сделка достигает официального объединенного потока. Разрыв между ними — это время передачи и нахождения в очереди, измеряемое микросекундами для биржевых сделок и часто миллисекундами или дольше для сделок, сообщаемых через центры регистрации.

Какую временную метку рыночных данных использовать для бэктестинга?

Используйте время участника для всего, что моделирует то, что участник мог видеть или сделать на площадке, и время SIP для всего, что должно сверяться с официальной консолидированной отчетностью. Что бы вы ни выбрали, применяйте это ко всем таблицам в исследовании, включая котировки.

Почему мои одноминутные бары не совпадают с данными провайдера?

Обычно дело в несовпадении часов. Сделка, метка площадки которой попадает прямо перед минутной границей, может иметь метку ленты сразу после нее, что помещает одну и ту же сделку в разные бары при разных правилах. Поздно сообщенные внебиржевые сделки усиливают этот эффект.

Являются ли наносекундные временные метки точными до наносекунды?

Нет. Поле имеет наносекундное разрешение, а точность определяется тем, насколько хорошо синхронизированы часы записывающей системы. Биржевые и процессорные системы, использующие PTP, обеспечивают субмикросекундную точность, тогда как бизнес-часы брокеров ограничены регуляторным допуском в 50 миллисекунд. Сравнения, более точные, чем допуск менее точных часов, не имеют смысла.

Каждый график выше поставляется с SQL-кодом, который его создал, поэтому вы можете увидеть, из каких именно часов взято каждое число. Чтобы пересортировать свое окно сделок по другим часам и увидеть, как меняется лента, задайте вопрос простым языком на терминале Strasmore.