Timestamps de mercado: SIP ou relógio da bolsa?

Os timestamps de dados de mercado são os horários registrados em um único negócio executado enquanto ele percorre o caminho entre o matching engine que o executou e a tela que o exibe. Uma operação com ações dos EUA tem três desses horários no registro público, e cada um responde a uma pergunta diferente. Ordene os negócios do mesmo dia por um horário e depois por outro: você terá dois tapes genuinamente diferentes.

Os quatro horários pelos quais passa um único negócio

Um negócio recebe vários timestamps até chegar ao investidor. Em ordem:

1. Horário do matching engine. O instante em que o matching engine de uma venue cruzou duas ordens. Ninguém fora da venue lê esse valor diretamente. Ele é a referência exata de quando o negócio ocorreu, e todos os horários posteriores são aproximações desse momento.
2. Horário do participante, também chamado de horário da venue ou da bolsa. É o timestamp que a venue registra quando publica o negócio em seu próprio feed, no campo participant_timestamp. Entre todos os horários que podem ser lidos diretamente, este é o mais próximo do matching engine.
3. Horário do SIP. É o timestamp registrado pelo securities information processor quando o negócio chega ao tape consolidado, o feed oficial único que reúne todas as venues de ações dos EUA. Esse é o campo sip_timestamp, e a sequência do tape oficial segue esse horário. A diferença entre esse feed e o feed próprio de uma venue é explicada em SIP versus feeds diretos das bolsas.
4. Horário de captura. É o timestamp registrado pela placa de rede quando o pacote chega. Ele nunca aparece no registro de um vendor, pois descreve o seu caminho, não o mercado. O trabalho de captura e replay de pacotes usa exclusivamente esse horário.

Negócios realizados fora das bolsas recebem um quinto timestamp, trf_timestamp, que indica quando uma trade reporting facility recebeu o reporte.

Por que os timestamps de dados de mercado divergem entre venues

A diferença entre o timestamp de uma venue e o timestamp consolidado é o tempo que o negócio passou em trânsito e na fila do processador. Não se trata de um único número. Cada venue está a uma distância diferente do processador, usa hardware diferente e enfrenta filas diferentes. O painel abaixo mede essa diferença para todas as venues que registraram negócios de AAPL durante uma janela fixa de meia hora em 10 de junho de 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

Entre essas venues, a maior diferença mediana entre o timestamp da venue e o timestamp consolidado foi de 346.2 microssegundos, na NYSE Arca, Inc.. A venue com a menor diferença na mesma janela ficou em 13.7 microssegundos. A coluna p99 é a que merece mais atenção: para a venue mais lenta, chegou a 420.8 microssegundos. Esse é o extremo da distribuição que a mediana oculta.

Qual timestamp usar

Quatro regras cobrem quase todos os casos.

• Horário do participante para trabalhos de microestrutura e estudos de eventos. Tudo que mede o que aconteceu em uma venue e em que ordem deve usar o relógio da venue. A reconstrução do livro de ofertas, tema de dados de livro MBO versus MBP, não funciona com outro horário.
• Horário do SIP para tudo que precisa ser conciliado com o tape oficial. Isso inclui reportes regulatórios, análises de best execution, a abertura e o fechamento oficiais e qualquer número que uma contraparte confira contra o registro consolidado.
• Horário de captura apenas para medir o seu próprio caminho. Ele mostra quanto tempo os dados levaram para chegar à sua máquina. Não informa quando o negócio ocorreu, e duas máquinas nunca terão o mesmo valor.
• Nunca misture relógios dentro do mesmo conjunto de dados. Um join que cruza cotações em um relógio com negócios em outro produz números plausíveis, mas falha justamente nos momentos relevantes.

Os mesmos negócios, ordenados de duas formas

É na ordenação que a abstração deixa de funcionar. O painel abaixo usa os dez milissegundos mais movimentados daquela meia hora, mantém os primeiros doze negócios em bolsa na ordem da venue e depois classifica novamente os mesmos doze pela ordem do tape consolidado. A tabela é ordenada pela distância que cada negócio percorreu entre os dois 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

A maior diferença entre as duas posições de um negócio é 6. Esse negócio saiu da venue em 10:44:17.160712 e chegou ao tape 305.7 microssegundos depois, às 10:44:17.161018, passando da posição 6 no relógio da venue para a posição 12 no tape. Nenhuma das duas ordens está errada. Elas respondem a perguntas diferentes. Um estudo da sequência de negócios executado no relógio do tape lê esse fluxo em uma ordem que nenhuma venue produziu, enquanto uma análise de best execution executada no relógio da venue diverge do registro oficial.

Negócios fora das bolsas chegam muito depois do evento

Um negócio executado fora de uma bolsa, em um wholesaler ou dark pool, é reportado a uma trade reporting facility, em vez de ser cruzado em um livro público. O reporte contém o horário da execução, mas chega ao tape depois. Esse intervalo é um atraso de reporte, não um tempo de trânsito, e é muito maior.

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

Dos negócios de AAPL realizados fora das bolsas nessa janela, 24.8% caíram no intervalo under 1 ms. A cauda chega ao intervalo 1 s to 10 s, com 74 negócios. Um negócio que chega dez segundos atrasado ainda mantém o horário da venue em que de fato foi executado, embora apareça no fluxo do tape dez segundos depois. Se for ordenado pelo horário do tape, ele parecerá estar no minuto errado. Negócios reportados fora da sequência normal carregam códigos de condição da operação que indicam isso. Essa é uma das funções de códigos de condição das operações.

Por que duas pessoas constroem barras diferentes com os mesmos negócios

Quase todo chamado de “os dados estão errados” chega a esse ponto. Uma barra é um intervalo de negócios, e o intervalo em que cada negócio entra depende do timestamp usado. O painel abaixo conta os negócios que mudam de intervalo quando se troca o relógio da venue pelo relógio do tape, em quatro durações comuns de barra.

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

Em uma grade de 1 second, 8.966% dos negócios dessa janela entram em uma barra diferente sob os dois relógios, totalizando 8944 negócios. Ao aumentar a barra para 5 minutes, o percentual cai para 0.024%. O padrão é mecânico: um negócio muda de intervalo sempre que a diferença entre os dois relógios atravessa um limite, e barras mais curtas têm mais limites. Dois vendors podem estar corretos e ainda assim publicar volumes diferentes para o mesmo minuto. O processo é explicado em como as barras OHLCV são construídas.

Um campo em nanossegundos não significa precisão de nanossegundos

Ambos os timestamps chegam como inteiros com resolução de nanossegundos. Resolução é o que um campo consegue expressar. Precisão é o quão próximo o valor está do horário verdadeiro, e as duas características são determinadas por fatores completamente diferentes.

O alinhamento dos relógios no setor é definido por uma tolerância regulatória, não pela física. A regra de sincronização de relógios da FINRA exige que os relógios operacionais das firmas membros estejam a no máximo 50 milissegundos da referência do NIST. Bolsas e processadores operam com tolerâncias muito menores, usando o Precision Time Protocol (PTP, padronizado como IEEE 1588), que distribui um relógio de referência pela mesma rede que transporta os dados e mantém as máquinas alinhadas em nível inferior a um microssegundo.

Duas conclusões decorrem disso. Dentro dos timestamps de uma mesma organização, a ordenação em resolução de microssegundos é significativa. Entre organizações, uma diferença de algumas centenas de nanossegundos entre dois timestamps está dentro da margem de erro. Tratá-la como uma ordem real é interpretar ruído como informação.

FAQ

Qual é a diferença entre o timestamp do SIP e o timestamp do participante?

O timestamp do participante é registrado pela venue quando ela publica um negócio em seu próprio feed. O timestamp do SIP é registrado pelo processador do tape consolidado quando esse negócio chega ao feed oficial combinado. A diferença entre eles é o tempo de trânsito e de fila, medido em microssegundos para negócios em bolsa e frequentemente em milissegundos ou mais para negócios reportados por uma trade reporting facility.

Qual timestamp de dados de mercado devo usar em backtests?

Use o timestamp do participante para tudo que modele o que um participante poderia ter visto ou feito em uma venue. Use o timestamp do SIP para tudo que precise ser conciliado com o registro consolidado oficial. Qualquer que seja a escolha, aplique-a a todas as tabelas do estudo, incluindo as cotações.

Por que minhas barras de um minuto não coincidem com as do meu provedor de dados?

A causa mais comum é uma divergência de relógios. Um negócio cujo timestamp da venue esteja pouco antes do limite de um minuto pode ter um timestamp do tape pouco depois desse limite. Assim, o mesmo negócio entra em barras diferentes conforme a convenção usada. Negócios fora das bolsas reportados com atraso ampliam o efeito.

Timestamps em nanossegundos têm precisão de nanossegundos?

Não. O campo tem resolução de nanossegundos, mas a precisão depende do grau de sincronização do relógio da máquina que o registra. Sistemas de bolsas e processadores que usam PTP mantêm alinhamento inferior a um microssegundo, enquanto os relógios operacionais de corretoras estão sujeitos a uma tolerância regulatória de 50 milissegundos. Comparações mais precisas do que a tolerância do relógio menos preciso não são significativas.

Cada painel acima é acompanhado do SQL que o produziu, para que você veja exatamente de qual relógio veio cada número. Para reordenar sua própria janela de negócios usando outro relógio e observar como o tape muda, faça a pergunta em linguagem natural no terminal Strasmore.