Kudos - Active Tick is making some moves

[jtrader33]

Ironically, we have both real-time and historical split and div adjustments in our databases, but we haven't exposed these via our API. We'll make sure to pass this on to our product dev team. As far as adjustments, we currently adjust OHLC bar databases, but keep tick data bases intact with original pricing. Out of curiosity, how important is it for you to have access to unadjusted OHLC bars?

A few years ago I probably would have said that I'm indifferent as long as you provided all the data for me to reverse the adjustment. However, in practice, this never ends up being a clean solution (rounding errors, etc.). Obviously, the unadjusted data is important so that filters based on price, dollar volume, et al can be applied accurately on a historic basis.

The bigger issue for you may be keeping everyone happy if you're doing the adjustments on your end. I feel pretty strongly that there is only one correct way to adjust equities data (backwards ratio), however, the world disagrees; I use three data sources for EOD equities and, believe it or not, that amounts to three distinctly different ways that the data is adjusted. So clearly people have different beliefs when it comes to different adjustment methods. The simplest, best (and only) way to serve all of them is to simply provide the raw data (unadjusted price, div, split). If they can use an API, making the adjustments in whatever method they deem appropriate is trivial.

 

[jtrader33]

I guess I never answered your question above. Even though it's not the most difficult item to find an alternate provider for, I'd say it's the primary reason I'd consider leaving my current feed. So very important...and from what I've gathered from others, this seems to irritate people disproportionately.

 

[vicirek]

I'm speaking to equities data as that's my focus, but I'm sure my comments on accuracy/reliability will be shared by the futures guys as well.

1. By far the most important factor is the accuracy of the data you provide (both historical and live) and the reliability with which you provide it (redundant server availability and some mechanism for handling/preventing disconnects in the streaming feed). I can't speak to your reliability (this is IQFeed's #1 strength in my opinion) but (as mentioned) your data accuracy is a major problem. As volpunter said, wrestling with data quality issues is a huge time drain (as well as dangerous). Without this being a strength, any other features become irrelevant.
.

Bad prints and bad data are part of the business of trading. It is the trader ultimate responsibility to deal with this issue.

 

[jtrader33]

Bad prints and bad data are part of the business of trading. It is the trader ultimate responsibility to deal with this issue.

Not talking about bad prints. If you can trouble yourself to read back a few posts, you'll see "For example, there are widespread errors in their historical database (sometimes you request AAPL data and get some $12 stock in return, some days are a mix of the stock you requested and another random stock, other data is simply missing, etc.)". There's no making lemonade out of that data...it's simply useless / a waste of time.

 

[activetick]

@jtrader33 That's completely understandable, we do not adjust our tick data for this specific reason. Even if OHLC bars are adjusted for splits and corporate actions, the tick data remains the same with original pricing and trade sizes. It can be used as a source to rebuild your own, pre-adjusted bars.

Our next API release will have a feature where you will be able to use tick data as the underlying data source for OHLC bars and generate bars during request, rather than using pre-generated bars. This will give you the ability to a) get pre-adjusted OHLC bar data, and b) build OHLC bars for custom intervals, such as 10-trade bars, or 10-second bars.

You are correct about the issue you reported for the 06/04/2013 tick dataset, the tick database for that day was corrupted and had to be taken offline to re-build it. It caused the issue you described, and was only limited to that day. We've since added redundancy to make sure this type of issue does not happen again.

 

[jtrader33]

@jtrader33 That's completely understandable, we do not adjust our tick data for this specific reason. Even if OHLC bars are adjusted for splits and corporate actions, the tick data remains the same with original pricing and trade sizes. It can be used as a source to rebuild your own, pre-adjusted bars.

Our next API release will have a feature where you will be able to use tick data as the underlying data source for OHLC bars and generate bars during request, rather than using pre-generated bars. This will give you the ability to a) get pre-adjusted OHLC bar data, and b) build OHLC bars for custom intervals, such as 10-trade bars, or 10-second bars.

Obviously, there will be a serious performance hit when retrieving EOD data this way but I suppose if it's raw data, it only needs to be stored locally once. The bigger issue I see with this is how far back does your tick data go? From memory, I want to say it was ~2010 or so? If so, that probably won't be enough history for most people. Can I ask why you wouldn't do it the way I described? Clean, simple, accurate, flexible...what's not to like?

You are correct about the issue you reported for the 06/04/2013 tick dataset, the tick database for that day was corrupted and had to be taken offline to re-build it. It caused the issue you described, and was only limited to that day. We've since added redundancy to make sure this type of issue does not happen again.

Are you trying to suggest that was the only data issue I reported?

 

[jharmon]

We are in ongoing process removing bad apples from some of the symbols in our historical databases. Unfortunately the source of historical data we acquired before had some data quality issues, so are addressing these. Just recently we've hired some additional help to be dedicated to this particular task.

Which source was this?

 

[activetick]

Yes, there is probably going to be some slight performance hit when the bars get constructed at request, however, the response times should be similar to regular bars response. Our current bar databases are already split adjusted, so there isn't a way to go back to pre-adjusted phase.

 

[jharmon]

Unfortunately the source of historical data we acquired before had some data quality issues, so are addressing these.

Which source was this?

Any update here?

 

[jharmon]

bump