My question is regarding the accuracy in general of how volume is reported as either transacted at the bid or the offer.

As the attached screen shot shows, often I observe transactions at the same price, all within milliseconds of each other, yet with some reported as occurring at the bid, with others at the offer price.

The fact that volume is occasionally (very rarely with IQFeed) reported as between the bid and offer suggests that ticks/transactions are not stamped with a tag that clearly identifies who initiated the transaction, but rather that after the transaction occurs, it is compared with the current bid and offer and then labelled as either bid or ask volume.

Is this a reasonable assumption to make?

Basically, I think most people want to know the initiator of the transaction. If it was someone who places a buy market, or a marketable limit buy order, etc., then it would be expected that this is reported as "buy volume" (at the offer).

So, given the above thoughts, can you give me a brief detail of how this information is determined? When I see rapid changes in bid/offer volume at the same price, can I be completely sure that this matches the intention of the order, as described above?

Hi Josh,

The data that comes from the exchange through IQFeed is really pretty cut and dry - there is no interpretation made or suggested as to who the initiator of the trade was. I have enclosed a picture of our time and sales to give you an idea of the data fields that are sent -
bid and ask are the nearest bid and ask prices, B and A Size are the quantities bid and offered at the nearest bid and ask levels... and, of course, they change rapidly, at times. The Volume field that comes from the exchange is a total of actual transactions - it does not identify itself with one side or the other of the transaction.

I understand that there are charting softwares that take the data and interpret it in various ways, but the data itself does not make assumptions about who may or may not have initiated the trade.

Here is the time and sales pic:

Thank you for your reply Todd, though I do not see a picture attached.

So, what you're saying is that the exchange itself provides only the nearest bid and ask values, and thus it cannot be determined for certain (particularly in fast market conditions) whether the limit order that was in the limit order book was at the bid or the offer?

Hi Josh,

The time and sales picture is above your question (we must have crossed paths). When you look at it, you will see that there are arrows next to either the bid or the ask if the transacted price was at the bid or ask. But the interpretation of that fact is up for grabs.

Thanks again Todd--

So, the arrow next to bid or ask is information that comes from the exchange itself, is that what you're saying?

As far as interpretation, outside the walls of the exchange I suppose there can be none here--if the transaction is marked as executed at the ask, then it means the initiator of the trade, the one who placed the order as a market order, or a marketable limit order, is taking the long side. I don't think there's any other meaning we can gather, unless you can think of something I'm missing. I know there can be interpretation as to the intent of the trader but no one can know that, but I think from the above it IS possible to objectively draw those conclusions.

Now, I suppose it's possible that at the exchange level there could be some issue with synchronization, but we have no control over that.

Do you agree or no?

Hi,

The arrows in the time and sales do not come from the exchange - they are just a visual feature of the time and sales I was showing to point out when the last trades were at the bid or offer prices. I think the bottom line is that the data is what it is. Trying to interpret that is the challenge of the trader.

Todd,

My overall question is this: who determines that the trade was at the bid or the ask and flags it as such? The exchange? DTN? My local software? I understand that the data is what it is, but the designation as bid or ask volume must come from somewhere; my question is, from who?

Your local software is what determines if a trade was at the bid or the ask. The exchange doesn't provide this information. We provide the bid and ask price at the time of trade within our historical tick data so software can more efficiently analyze the data. There is no "flag" in our feed that says it traded at the bid or ask (since there is no way to know), but this is how local/client software interprets the data we provide in IQFeed. The reason Traders prefer IQFeed over other feeds is because they have determined it provides the most accurate data for Volume Profile, VPOC, Delta/Footprint analysis.

I hope this helps clarify.

---

Jay Froscheiser
Telvent DTN

Jay, thank you so much. Are incoming ticks from IQFeed timestamped, and if so, what is the resolution of the time stamp?

What is the easiest way to capture or display raw tick data that I can analyze in Excel or some other tool? I would like to capture a small amount of data from the feed and look at the data myself.

We timestamp trades to the nearest second and use the exchange timestamp of the trade.

To look at the data you could use DDE to see the stream coming in. The IQFeed client installation includes a sample DDE spreadsheet to get you started. Otherwise, you would need the IQFeed API subscription in order to write your own code to access the feed.

---

Jay Froscheiser
Telvent DTN

Thank you Jay,

I am having problems with Excel freezing when I try to use DDE but I think I have the information now that I need.

After watching the tape a little bit tonight and reading the comments here again, it is very clear to me now and quite simple; I was not clear that every tick also includes the bid price and ask price at the time of the transaction. I assumed there was a bid or ask flag. However, there might as well be, given the simplistic way it's calculated: if the price of the transaction is the bid price associated with the transaction, it's assumed that the transaction was executed at the bid, thus meaning that a buy limit order was filled by a marketable sell order of some kind. We can only logically make these conclusions, however, if the bid and ask for each tick are indeed what they were when the order was actually filled.

I am not clear on whether these fields (the bid and ask price for each transaction) come from the exchange directly, or whether IQFeed determines this. With my broker (TT) feed, I get very different values for bid/ask for each transaction. I suspect this is where IQFeed's ticker plant, and other fancy things come into play, but I cannot be sure.

Jay, after reading your reply above again, I see that you're saying IQFeed provides a bid/ask price for each tick on historical data; but does it also provide the bid/ask for live, incoming tick data, or must the local client software capture the bid and ask on each incoming tick? If you do not provide a bid/ask data field for live data, then it's conceivable that there could be sequencing and synchronization issues on a local machine that your sophisticated equipment would not have; in addition, a reload of historical data would yield different values for bid/ask than what is calculated live. Can you verify which case is true here, namely, whether IQFeed also provides a bid and ask price for live, incoming ticks as well as historical data?

By the way, thanks so much to both of you for taking the time to answer my detailed questions; I feel it's very important to understand the data I get as I am considering different methods of calculation on this subject, and I thank you for being so helpful.

Every time we receive a trade message, the IQFeed client will also update/send the current bid/ask to the user's software (we do some of the heavy lifting in this case, but leave it up to the software to analyze it however it wants). The exchange doesn't send any type of flag/message indicating the bid/ask at the time of the trade. What we store in historical tick data is the same as what the client is being sent in real time as the ticks come in. This is where the real value occurs as you can be assured that what came through the stream matches history (except in the case of tick corrections/etc that we process to history).

---

Jay Froscheiser
Telvent DTN

So Jay, when you say "Every time we receive a trade message, the IQFeed client will also update/send the current bid/ask to the user's software," you are saying that for every time-stamped tick that the client receives in real time, there is also a bid/ask value for that particular tick, "attached to" that particular tick as a field of data--is that correct?

Or, is it the case where there is a simply a global "current" bid/ask value that my local client sees that you update with each tick, and the client is responsible for matching the incoming tick to that current value?

Jay or Todd, any answer to my last question?

Hi Josh,

Your latter answer is more accurate. The last transacted price is not "attached to" the bid or the offer - that is what I mean when I say, the data is what it is. Any attaching or matching that is done, is not done by the data in the feed.

Todd,

That being the case, do you know then if the incoming (to my PC) data that signals a bid/ask change is serialized along with tick data, in a synchronous fashion, or are the two pieces of information asynchronous? We could have a synchronization issue if the "current" bid/ask is updated in a parallel stream separate from the tick data.

For example, in a serial data stream, the data might look like this:

[tick1]
[tick2]
[b/a change]
[tick3]
[b/a change]
[tick4]
[tick5]
...

I am not familiar with the API or how the data comes in--is this a reasonable approximation of it, and is this done with a protocol that will ensure the messages are received in the correct order?

Or, are there perhaps more than one data stream where one might indicate a change in bid/ask, and the other is ticks only, and thus the two could get out of sync?

Josh,

We send all the data with each update in a single Level I stream that includes both trades and quotes. They are send as comma delimited strings, and the current infromation for each field is sent with each update. Thus, if a trade comes in, the current bid/ask price is in the same message. If a bid/ask update comes in, the last trade price is in that same message as well. Thus, you don't need to worry about syncing anything as its all in the same level I stream.

---

Jay Froscheiser
Telvent DTN

Jay,

This puts this to rest for me finally--thank you so much for the reply. I will now leave you guys alone! :-)

-Josh

I thought of one question I forgot to ask... now that I know how the data comes in...

Sometimes a transaction is reported at a price below the current bid, above the current offer, or even between the two. For example:

http://screencast.com/t/F2vJfwLsRTc4

Obviously this is a synchronization issue, as it's nonsensical to think of it any other way. The question is, how can this scenario occur, and where does the synchronization issue lie? It is obviously either at the exchange, or at your ticker plant, or somewhere in between. Can you shed some light on this phenomenon please?

It's been 3 days, any answer to this question?

Hi Josh,

Sorry about the delay - I was off for two days, but will get you an answer soon.

Josh,

Our Market Data Services looked into this example and verified that the data came from the exchange that way.

Thank you for checking this Todd -- have a great day!