시장 데이터 타임스탬프: SIP와 거래소 시각 비교
시장 데이터 타임스탬프는 네 가지 시각을 기준으로 생성됩니다. 동일한 거래 기록을 어떤 시각으로 정렬하느냐에 따라 테이프의 흐름이 어떻게 달라지는지 확인하고, 분석 목적에 적합한 타임스탬프 선택 기준을 알아봅니다.
시장 데이터 타임스탬프는 체결된 거래(trade print)가 매칭 엔진에서 실행되어 화면에 표시되기까지의 경로에 찍히는 시각을 의미합니다. 미국 주식 거래 기록에는 세 가지 타임스탬프가 포함되며, 각각 다른 질문에 답합니다. 동일한 거래 기록을 어떤 시각 기준으로 정렬하느냐에 따라 완전히 다른 테이프(tapes, 거래 기록의 흐름)가 생성됩니다.
단일 거래 기록이 거치는 네 가지 시각
거래 기록은 사용자에게 도달하기까지 여러 번 타임스탬프가 찍힙니다. 순서대로 나열하면 다음과 같습니다.
- 매칭 엔진 시각(Matching engine time). 거래소의 매칭 엔진이 두 주문을 체결시킨 순간입니다. 거래소 외부의 누구도 이 값을 직접 읽을 수 없습니다. 이는 거래가 발생한 실제 시점(ground truth)이며, 이후의 모든 시각은 이를 근사한 값입니다.
- 참여자 시각(Participant time), 또는 거래소 시각(venue or exchange time). 거래소가 자체 피드에 거래 기록을 게시할 때 찍는 시각으로,
participant_timestamp필드에 포함됩니다. 실제로 읽을 수 있는 데이터 중 매칭 엔진 시각과 가장 가깝습니다. - SIP 시각(SIP time). 증권 정보 처리자(Securities Information Processor, SIP)가 통합 테이프(consolidated tape)에 거래 기록을 기록할 때 찍는 시각입니다. 이는 모든 미국 주식 거래소를 통합한 공식 피드이며,
sip_timestamp필드에 해당합니다. 공식 테이프 순서는 이 시각을 따릅니다. 해당 피드와 거래소 자체 피드의 차이는 SIP 대 직접 거래소 피드에서 다룹니다. - 캡처 시각(Capture time). 패킷이 도착했을 때 사용자의 네트워크 카드가 기록하는 시각입니다. 이는 시장이 아닌 사용자의 경로를 설명하므로 벤더의 기록에는 나타나지 않습니다. 패킷 캡처 및 재생 작업은 전적으로 이 시각을 기준으로 수행됩니다.
거래소 외부에서 발생한 거래 기록에는 trf_timestamp라는 다섯 번째 타임스탬프가 추가되며, 이는 거래 보고 시설(Trade Reporting Facility, TRF)이 보고서를 접수한 시점을 나타냅니다.
거래소별로 시장 데이터 타임스탬프가 일치하지 않는 이유
거래소 시각과 통합 테이프 시각 사이의 간격은 거래 기록이 전송되고 처리자의 대기열(queue)에 머무는 시간입니다. 이는 단일한 숫자가 아닙니다. 각 거래소는 처리자와의 물리적 거리, 하드웨어, 대기열 환경이 모두 다릅니다. 아래 패널은 2026년 6월 10일 특정 30분 동안 AAPL을 거래한 모든 거래소의 해당 간격을 측정한 결과입니다.
모든 수치 뒤에 숨겨진 정확한 SQL
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해당 거래소들 중 거래소 시각과 통합 시각 간의 중앙값(median) 차이가 가장 큰 곳은 346.2 마이크로초였으며, NYSE Arca, Inc.에서 발생했습니다. 같은 기간 가장 차이가 적었던 거래소는 13.7 마이크로초를 기록했습니다. 주목해야 할 지표는 p99 열입니다. 가장 느린 거래소의 경우 이 값이 420.8 마이크로초에 달했으며, 이는 중앙값 뒤에 숨겨진 꼬리(tail) 위험을 보여줍니다.
어떤 타임스탬프를 사용해야 하는가
거의 모든 경우에 다음 네 가지 규칙이 적용됩니다.
- 미시구조 연구 및 이벤트 분석에는 참여자 시각을 사용하십시오. 거래소에서 무슨 일이 어떤 순서로 일어났는지 측정하는 모든 작업은 거래소 시각을 기준으로 해야 합니다. MBO 대 MBP 호가창 데이터의 주제인 호가창 재구성은 다른 시각 기준으로는 불가능합니다.
- 공식 테이프와 대조해야 하는 모든 작업에는 SIP 시각을 사용하십시오. 규제 보고, 최선 집행(best execution) 검토, 공식 시가 및 종가, 그리고 거래 상대방이 통합 기록과 대조할 모든 수치는 SIP 시각을 따라야 합니다.
- 자신의 경로를 측정할 때만 캡처 시각을 사용하십시오. 이는 데이터가 자신의 기기에 도달하는 데 걸린 시간을 알려줄 뿐, 거래가 발생한 시점에 대해서는 아무것도 알려주지 않습니다. 두 기기의 캡처 시각은 결코 일치하지 않습니다.
- 하나의 데이터셋 내에서 시각 기준을 혼용하지 마십시오. 한 시각 기준으로 호가를, 다른 시각 기준으로 거래를 매칭하는 조인(join) 작업은 그럴듯해 보이는 숫자를 반환하지만, 정작 중요한 순간에는 실패합니다.
동일한 거래 기록, 두 가지 정렬 방식
정렬은 추상화가 깨지는 지점입니다. 아래 패널은 해당 30분 중 가장 거래가 활발했던 10밀리초를 추출하여, 처음 12개의 거래소 거래 기록을 거래소 시각 순으로 정렬한 뒤, 동일한 12개를 통합 테이프 시각 순으로 다시 정렬했습니다. 표는 두 순위 사이에서 각 거래 기록이 얼마나 이동했는지를 기준으로 정렬되었습니다.
모든 수치 뒤에 숨겨진 정확한 SQL
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 위치로 이동했습니다. 두 정렬 방식 모두 틀린 것은 아닙니다. 다만 서로 다른 질문에 답할 뿐입니다. 테이프 시각으로 수행한 거래 순서 연구는 어떤 거래소도 생성한 적 없는 순서로 이 급등락을 읽게 되며, 거래소 시각으로 수행한 최선 집행 검토는 공식 기록과 불일치하게 됩니다.
거래소 외부 거래 기록은 이벤트보다 훨씬 늦게 도착한다
거래소 외부(도매업자나 다크풀)에서 체결된 거래는 공개 호가창에서 매칭되지 않고 거래 보고 시설에 보고됩니다. 보고서에는 체결 시각이 포함되지만, 테이프에는 그 이후에 도착합니다. 이 간격은 전송 시간이 아니라 보고 지연이며, 그 규모는 수십 배 더 큽니다.
모든 수치 뒤에 숨겨진 정확한 SQL
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개의 거래 기록을 포함합니다. 10초 늦게 도착한 거래 기록은 실제 체결된 거래소 시각을 유지하지만, 테이프 흐름상에서는 10초 뒤에 위치합니다. 테이프 시각으로 정렬하면 잘못된 분(minute)에 나타나게 됩니다. 정상적인 순서 밖에서 보고된 거래 기록은 이를 나타내는 매매 조건 코드(sale condition codes)를 포함하며, 이는 거래 조건 코드가 존재하는 이유 중 하나입니다.
동일한 거래로 서로 다른 막대 차트를 만드는 이유
"데이터가 틀렸다"는 문의의 대부분은 여기서 발생합니다. 막대(bar)는 거래 기록의 묶음이며, 어떤 타임스탬프를 기준으로 묶느냐에 따라 거래 기록이 속하는 묶음이 달라집니다. 아래 패널은 거래소 시각에서 테이프 시각으로 전환할 때 묶음이 바뀌는 거래 기록의 수를 네 가지 일반적인 막대 길이별로 계산합니다.
모든 수치 뒤에 숨겨진 정확한 SQL
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 ASC1 second 그리드에서 해당 기간 거래 기록의 8.966%는 두 시각 기준에 따라 서로 다른 막대에 속하며, 총 8944개의 거래 기록이 해당합니다. 막대를 5 minutes로 늘리면 이 수치는 0.024%로 감소합니다. 이 패턴은 기계적입니다. 시각 간격이 경계선을 가로지를 때마다 거래 기록의 묶음이 바뀌며, 막대가 짧을수록 경계선이 많아집니다. 두 벤더 모두 올바른 데이터를 사용하더라도 같은 1분에 대해 서로 다른 거래량을 발표할 수 있습니다. 막대 구성 방식은 OHLCV 막대 구성 방법에서 자세히 다룹니다.
나노초 필드가 나노초 정확도를 의미하지는 않는다
두 타임스탬프 모두 나노초 단위의 정수(integer)로 제공됩니다. 해상도(resolution)는 필드가 표현할 수 있는 단위이고, 정확도(accuracy)는 값이 실제 시각과 얼마나 일치하는지를 의미하며, 이 둘은 완전히 다른 요소에 의해 결정됩니다.
업계 전반의 시각 동기화는 물리학이 아닌 규제 허용 오차에 의해 결정됩니다. FINRA의 시각 동기화 규칙은 회원사의 업무용 시각이 NIST 기준 시각과 50밀리초 이내의 오차를 유지하도록 규정합니다. 거래소와 처리자는 훨씬 더 엄격한 정밀 시각 프로토콜(Precision Time Protocol, PTP, IEEE 1588 표준)을 사용하여 데이터가 흐르는 동일한 네트워크를 통해 기준 시각을 분배하며, 마이크로초 미만의 동기화를 유지합니다.
여기서 두 가지 사실이 도출됩니다. 한 조직 내의 타임스탬프라면 마이크로초 단위의 정렬은 의미가 있습니다. 그러나 조직 간의 타임스탬프라면 수백 나노초의 차이는 오차 범위 내에 있으므로, 이를 실제 순서로 해석하는 것은 노이즈를 읽는 것과 같습니다.
자주 묻는 질문(FAQ)
SIP 타임스탬프와 참여자 타임스탬프의 차이는 무엇입니까?
참여자 타임스탬프는 거래소가 자체 피드에 거래를 게시할 때 작성합니다. SIP 타임스탬프는 해당 거래가 공식 통합 피드에 도달했을 때 통합 테이프 처리자가 작성합니다. 둘 사이의 간격은 전송 및 대기 시간이며, 거래소 내 거래는 마이크로초 단위로, 거래 보고 시설을 통한 거래는 종종 밀리초 이상으로 측정됩니다.
백테스팅에는 어떤 시장 데이터 타임스탬프를 사용해야 합니까?
참여자가 거래소에서 무엇을 보거나 할 수 있었는지를 모델링하려면 참여자 타임스탬프를 사용하고, 공식 통합 기록과 대조해야 하는 작업에는 SIP 타임스탬프를 사용하십시오. 무엇을 선택하든 연구 내의 모든 표(호가 포함)에 동일하게 적용해야 합니다.
1분 막대 차트가 데이터 제공업체의 것과 일치하지 않는 이유는 무엇입니까?
시각 기준 불일치가 일반적인 원인입니다. 거래소 시각으로는 1분 경계 직전인 거래 기록이 테이프 시각으로는 경계 직후가 될 수 있으며, 이로 인해 동일한 거래가 두 관습에 따라 서로 다른 막대에 배치됩니다. 늦게 보고된 거래소 외부 거래는 이러한 효과를 증폭시킵니다.
나노초 타임스탬프는 나노초 단위까지 정확합니까?
아니요. 필드는 나노초 해상도를 가질 뿐이며, 정확도는 기록하는 기기의 시각이 얼마나 잘 동기화되었는지에 따라 결정됩니다. PTP를 사용하는 거래소 및 처리자 시스템은 마이크로초 미만의 동기화를 유지하지만, 브로커의 업무용 시각은 50밀리초의 규제 허용 오차를 따릅니다. 더 느슨한 시각 기준의 허용 오차보다 미세한 비교는 의미가 없습니다.
위의 모든 패널은 해당 데이터를 생성한 SQL과 함께 제공되므로 각 숫자가 어떤 시각 기준에서 나왔는지 정확히 확인할 수 있습니다. 다른 시각 기준으로 자신의 거래 기록 윈도우를 다시 정렬하고 테이프 변화를 확인하려면, Strasmore 터미널에서 평이한 영어로 질문하십시오.