1
$\begingroup$

I downloaded data regarding the YUM stock traded on the New York Stock Exchange in the year 2014. Basically in this dataset, we have 4 columns: the first column is the day the second column is the time in milliseconds expressed in epoch time, the third column is the transaction price and the fourth column is the volume. At a particular moment, there are instances where transactions, reported in milliseconds, occur at the same price and instant but involve different volumes for example

28,1393603190476,56940,450
28,1393603190476,56940,188

These 2 rows indicate that on the 28th at the instant 1393603190476(milliseconds elapsed from 1 January 1970) there are 2 transactions at the same price with different volume Why are the transactions reported separately if they occur at the same instant?

Improve this question
$\endgroup$
3
  • 5
    $\begingroup$ Why not? At that moment Person A bought 638 shares, of which 450 were sold by person B and 188 by person C. That is how a Matching Engine works. $\endgroup$
    – nbbo2
    Commented Jan 27 at 13:27
  • $\begingroup$ sorry if my question is stupid , but it is the first time I deal with real data : in this case we have 28,1393603143937,56920,400 28,1393603143937,56920,1004 28,1393603143937,56910,600 28,1393603143937,56910,100 28,1393603143937,56910,100 28,1393603143937,56910,100 28,1393603143937,56910,100 28,1393603143937,56900,100 28,1393603143937,56900,800 why in this case the transaction prices are different at the same instant? I had thought about selling and buying prices but there are 3 different prices at the same instant $\endgroup$
    – XY0
    Commented Jan 27 at 15:51
  • 1
    $\begingroup$ I suggest you get some documentation from the source of the data. Guessing can only get us so far. $\endgroup$
    – nbbo2
    Commented Jan 27 at 17:05

3 Answers 3

Reset to default
1
$\begingroup$

Why are the transactions reported separately if they occur at the same instant?

In the absence of any other information about your data source, it is most likely that the trades do not occur at the same instant. That is, your data source has timestamped the trades to the nearest milisecond. But trades on NYSE Arca are not executed in milisecond time buckets. There are trades within those miliseconds, and that is why it appears to you that they were executed at the same time. You can check the real-time datafeed specification, to see that the trade message timestamps go down to nanoseconds.

Regarding the importance of time resolution, I recall a paper that compares the differences between measurements derived from second vs. milisecond time-stamped TAQ data, definitely a good read:

Holden, Craig W., and Stacey Jacobsen. "Liquidity measurement problems in fast, competitive markets: Expensive and cheap solutions." The Journal of Finance 69, no. 4 (2014): 1747-1785.

Improve this answer
$\endgroup$
5
  • 1
    $\begingroup$ is correct, they most likely did not occur in the same instant. It's just that your data source truncated the nanosecond part of the timestamp. That said, there are times when trades happen within the same nanosecond timestamp and sequence number; some matching engines are capable of reporting multiple events that are related to the same trade event. $\endgroup$
    – databento
    Commented Mar 10 at 2:22
  • $\begingroup$ A few cases may be like this, but the correct answer comes from the comment by @nbbo2 $\endgroup$
    – Brian B
    Commented Apr 5 at 12:40
  • $\begingroup$ @BrianB I disagree with your suggestion that "few cases may be like this". I queried data from my database, selecting an arbitrary starting datetime (data from SIP). There are numerous trades occurring within a single millisecond. It is not limited to a few cases, I can provide you with as many such examples as you want (example below). Data from 2020-02-03, NYSE ARCA: 310.94 75 10:00:00.013264111 310.94 25 10:00:00.013307761 310.94 50 10:00:00.013307937 310.94 50 10:00:00.013452262 310.94 60 10:00:00.013601109 310.94 40 10:00:00.013927973 310.94 60 10:00:00.013928342 $\endgroup$
    – danospanos
    Commented Apr 27 at 18:32
  • $\begingroup$ @BrianB I would agree with nbbo2's answer and thus with your comment. However, how do you know that the matching engine will report like this (with the same timestamp for multiple trade execution reports) on the NYSE markets? Can you provide a relevant document with the technical specifications on which you base these claims? $\endgroup$
    – danospanos
    Commented Apr 27 at 18:33
  • $\begingroup$ @BrianB Regarding the tech spec on time reporting. The only relevant information I found was in the "NYSE_Group_Equities_Technology_FAQ.pdf" under Section 5, "Matching Engine", subsection 5.5, which states: "The Exchange processes one message at a time." I infer from this that each market order execution is likely to be reported individually, each with a unique timestamp and sequence number. It would also be critical to distinguish between SendTime and SourceTime as described in the "Pillar_Common_Client_Specification_v2.6c.pdf". $\endgroup$
    – danospanos
    Commented Apr 27 at 18:39
1
$\begingroup$

Free data equals bad data. Cheap data equals bad data. You are not dealing with real data here. This data has been aggregated to the 1ms timeframe at best. I have seen other such data that is aggregated to 4ms timeframe. The providers call this real-time data but be careful. In data provider parlance, real-time can be anything that is provided less than 10 minutes from the time the event occurred.

Real trade message data from the exchange is timestamped with 1ns resolution. Trade messages typically contain the information for a single transaction. This information includes Exchange Time (when the transaction occurred), Sending Time (when the transaction message was sent to the wire), Price, Quantity Filled, Order Count (Aggressing order filled by N sitting orders), Aggressor Side (Sell the Bid, Buy the Ask).

The highest volume of messages in a session comes from order book updates. These consist of new limit orders, sitting order modification and/or cancellation. The volume of these messages can exceed trade messages by 5 to 1. There are also various administrative messages sent to indicate exchange status, market status, instrument status, statistics, etc.

Historical data from the exchange is stored as a PCAP (packet capture) file which contains the binary encoded messages for the entire session.

The exchanges publish very detailed specifications on the message protocols (usually based on SBE or FIX). Do a bit of google search to find the specifications for the exchange's message protocol to find out exactly what the messages contain and timing of the messages. Search "NYSE FIX Protocol" or "NASDAQ Market Data Message Spec" and go from there.

The only place to get this data is from the exchange. Of course, there are other providers of market data, but they offer aggregated data and are often restricted by the terms of their license agreement (in exchange for lower cost) with the exchange from providing the raw data. If you want the real data, the only way is to be directly licensed by the exchange to have access to this data.

If you can get the license, which retail traders and researchers usually cannot, you have been granted permission to connect to the market data feed and receive the serialized, encoded messages. Great! Now all you have to do is develop an application that can connect to the exchange session (must pass a rigorous certification process), receive the message packets (over UDP typically), decode them and present them for analysis by a trading strategy. If you want to display the data on a chart on a screen you have to pay more for the licensing fee. There are vendors who offer the "FIX Decoders", which is a great way to accelerate the development of your system to read market data. Of course, you'll want to place orders as well. The order feed is an entirely separate feed and protocol, but the process of getting licensed, certified and able to place orders is similar except for the fact that now other people become concerned with your risk profile and such. But I digress.

You also need to be collocated as well. The connection to the exchange servers does not work for servers that are not collocated.

In summary, any data you get that is not from the exchange has been aggregated or manipulated in some way by the data provider to fit within their business model, storage capacity, infrastructure, etc. It is not real data. I'm afraid far too many people simply are not aware of this.

Improve this answer
$\endgroup$
0
$\begingroup$

Maybe the trades occurred on separate markets/exhanges (e.g., NYSE vs. CBOE) or maybe different trading codes (e.g., "bunched sold trade" vs. "intermarket sweep").

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.