Why is eSignal missing some irreg trades?

[bfry5282]

QQQ's 85k trade missing

In QQQ, at 13:08 today, RealTick showed 85,000 shares of QQQ traded at 34.50, about 9 cents below the prevailing market price of 34.59. Didn't see it in eSignal.

Is this a Data Manager issue, or a Winsig.exe client issue?

[bfry5282]

Minor correction, price appears wrong

Hmmm.... I didn't see the 85k trade in my 1s timeframe, but I think it did show up in my 5s timeframe. However, eSignal's price appears to have been 34.59 instead of RealTick's reported price of 34.50. So I'm a bit confused here.

In looking at trade volumes in my EFS routines, I use the NEWBAR condition to clear a LastVolume counter, and subtract that from the current bar volume(), which is cumulative for the bar, in order to get the individual trade volume. Then I set LastVolume to the current cumulative volume and do it again.

To me, this seems correct, and works as far as I can see. I'll check again that my algorithm is correct, but the price appears to have been misreported.

[bfry5282]

OK, still an issue but I had a minor prob

I checked my logic, and I think I had a minor bug in capturing every tick's volume, in my EFS in the 1s timeframe, but I still believe eSignal's reported price was incorrect, even though this 85k volume does seem to have appeared in the data feed.

[bfry5282]

Confirming esignal's prices are incorrect

I fixed my bug, and I have 2 examples where eSignal did see the trade volumes, but reports the price significantly wrong, as compared with what RealTick reports. eSignal simply lumps the volume in with what is roughly the prevailing market price.

Time: 15:56. QQQ 700,000 shares RealTick price 34.74, eSignal price 34.90, which was prevailing market price.

Time: 15:59. QQQ 500,000 shares RealTick price 34.74, eSignal price 34.90, which was prevailing market price.

I would like to see this fixed so that the correct price is reported.

TIA

[JayF]

As you know, we aren't processing the extraneous trades from Nasdaq. The exception is those that need to be processed for volume reasons per the exchange's suggested processing methodology. Average Price is one of those fields. The method we use to process Average Price trades is simply to use the trade before it and then include the volume sent. If we were to treat this as a regular trade, then there would be a large price spike on the chart, and technical analysis would thus be schewed. At this time, we don't have the ability to include a trade in the Time & Sales without putting it in the Advanced Chart.

Regarding your request for a commitment to including the extraneous trades in our feed, we cannot do so with an accurate ETA at this time due to the large amount of hours it would take to make this happen, and what's currently on the feed developers' plates. Please know that this is something we do want to do, including the inserting of Out of Sequence trades into their appropriate positions, but a time frame for when is simply not available yet.

[bfry5282]

I don't understand why not

Jay, thanks for the explanation, but I simply do not understand why you don't report the trade as it is received in streaming data mode. What you do about historical data is less important to me than what is happening right now.

There are plenty of "spikes" in the Nasdaq data, and this would simply be another one of them. Technical analysis is screwed, or skewed or whatever, anyway, due to the lack of a streaming filter capability, so that doesn't seem to make much difference.

I believe is wrong for eSignal to report a volume at an incorrect price, as eSignal does right now. It would be better if you did not roll the volume into the current price at all, because it is not volume which should be reported at that price. Then, at least, what was being reported (although incomplete) would at least be accurate.

So, I don't understand why the client can't simply pass this data through as a trade, as it is received, in the live data stream. Would that be so difficult?

I'm guessing that this extraneous trade gets to the client, but that the client handles it differently? Would passing it through to a streaming advanced chart really be that difficult, or does it involve more components of the system?

Thanks!

[bfry5282]

Volume price analysis showing the problem

Attached is an analysis of volume/price for the QQQ's from the existing eSignal data feed. Volumes in thousands.

As you can see there are many "spike" prices in instruments such as QQQ or INTC, usually at large volumes. These are legitimate trades, on which both RealTick and eSignal agree, and are shown as Green to indicate individual trades.

The volume shown in the Red is volume probably shown at the wrong price, presumably because it has been "rolled into" the volume of the current/previous trade, as I understand it.

TIA

[JayF]

As per the Nasdaq specs, an "Average Price" record should not update the High/Low or Last, but only the Volume. Since we don't currently have the option in our feed to flag a record as a non-trade (excepting Bid/Ask Quotes,) we need to include it in the volume. So as not to affect the last price, we maintain the last price from the trade prior, and set the volume equal to the "Average Price" record. Until we can add support to handle a non-trade record, this is the best way we can handle Average Price records.

[bfry5282]

Please let me know when this can be fixed

Jay, thanks for the explanation. As a user, I don't understand why this is a "non-trade", or how you determined it was an "average price" record we're talking about here.

To me it is incorrect trade data being reported, and it affects the largest trades, thus is the most important information to have.

I'd like to hear from product management when this behavior can be changed, if only in the client, if at all possible.

In summary, if Realtick is telling me 1 million shares of QQQ's were traded at 10 cents below the market, and eSignal is telling me it's at market price, then this is a HUGE problem for me.

Thanks for looking into this and proposing some solution through product management which will report this trade volume, at the correct price.

[JayF]

It sounds like there's some confusion here. Let me see if I can clear this up. Here's a screenshot of RealTick's Time and Sales for one of the trades in question.



You'll notice the trade in question is turned purple, and is marked with an "AvgPrc" flag. Essentially, these trades are a summary of a number of other trades that were processed by a broker-dealer, and are averaged together for reporting. Nasdaq, in their data feed specifications, state to not report these in the last field, nor update the high or low, but to take them into account when added up cumulative volume. I mentioned earlier why we do what we do in that regard.

My opinion is that these Average Price trades should not be included on a chart due to them being far out of the market by the time they are sent. If we were to just treat these as normal trades, then even more abnormal spikes in the data would be introduced. Ideally, a toggle would be provided to decide whether or not these are included. How would you prefer these to be handled? Anyone else care to provide their opinion?

[bfry5282]

I think they should be reported as trades

Jay, thanks for looking into this, even on the RealTick side, and for making sure we're very clear on what these represent. I'd like to take this opportunity to praise the quality of eSignal's support !!

I hadn't been aware there was a RealTick field for average price, so I learned something. BTW, how did you configure the RealTick ticker to show this field?

Anyway, you would expect me to advocate reporting these as separate trades, and here are my reasons for doing so:

My experience in doing tick by tick price/volume analysis is that there are very significant spikes in the data anyway, and inclusion of these as individual trades would add only a very few more spikes, but the upside is that the information would be very much more accurate in characterizing very important large volume trade activity.

Nasdaq guidelines you quote notwithstanding, the inclusion of this volume information, at the correct average price; and as a separate "trade" or, as you point out, "average trade price" would have only a minimal impact on the number of "spikes" in the data, as there are already a very significant number of spikes anyway. (this argues for better tick filtering capability as well).

Reporting these "average trades" at their correct reported average prices is critical in understanding where large volumes are being placed, and is therefore critical in knowing where developing support and resistance for price is headed. By reporting them as volume only (using the Nasdaq guideline you quote) added to the most recent market price is a significant distortion of the truth, IMHO, and therefore gives a false picture of very important trade activity.

For these reasons, my vote is obviously that these be reported, as RealTick reports them in its tick/trade charts, as though they were single trades, at the "average price". This is very much more indicative of how the instrument is actually trading, and this is even more important given the large volumes which these "average price" trades represent.

Also, it would make me very happy ! ;-) I doubt whether very many have much of an opinion on this issue, as many are probably not even aware that this is happening. I wasn't until I looked into the data feed more closely.

Thanks again for this outstanding level of support !!

[bfry5282]

RealTick T&S

OK, Jay, now I see that you were looking at a RealTick Time and Sales display. I just look at the ticker beside Level II displays, and don't use a T&S window specifically, which is why I wondered how you configured RealTick. Thanks.

[bfry5282]

1.25m trade -- missed in eSignal

QQQ's at about 14:16 RealTick reported 1,250,000 shrs traded @34.45 with nothing from eSignal. Market was about 35.43.

[JayF]

I found that this was a trade that was cancelled by the exchange and then reinserted shortly thereafter. Just as with Out of Sequence and Sold trade conditions, the Inserted trade condition is not currently supported. I will certainly pass this along to our Development Group to consider.

[michaelm]

For these reasons, my vote is obviously that these be reported, as RealTick reports them in its tick/trade charts, as though they were single trades, at the "average price". This is very much more indicative of how the instrument is actually trading, and this is even more important given the large volumes which these "average price" trades represent.

bfry5282,

For you this may be an important aspect for your analysis and trading, but I can assure you that neither myself, nor many other traders I know, find this reporting as "indicative of how an instrument actually trades", for the mere fact that B/D trades are reported at various times...sometimes way after the fact, plus that B/D trades can be similar to secondary transactions.

Perhaps you'd like to do some further investigating on how trades get reported per NASDAQ, NYSE, etc, and the various types of trades that get reported and their significance.