Hi there,
I was wondering how bars are calculated from “subscribe_bars”.
Given that I have a live data subscription and a tradingview account with live data, I checked the AAPL data. On 04/21/2022, time 13:51 (UTC), 1-minute data, Tradingview’s high is $170.8701. However, a request for historical data via Alpaca Markets shows a high of $170.875.
According to Tradingview support, there was an odd lot trade on April 21, 2022 13:51:59 - which I can confirm with Alpaca’s trade data. If this odd lot trade had not been included, this bar would have been correct.
So the question: what conditions are included in Alpaca’s calculation of bars? Am I correct in assuming that I need to calculate my own bars if I want the exact same data as displayed in Tradingview? Have Alpaca’s bars been calculated internally at all?
Thanks for any help!
@jc_trade See some details on potential differences between TradingView and Alpaca data here: Invalid bars around 8am EST shuffle for TQQQ - #5 by CapitalMastery
In short, it may not even be possible to build your own bars that match exactly. At least not for extended hours.
1 Like
Thanks, @CapitalMastery!
What still surprises me is that in the individual trades I see this odd-lot trade, which according to common rules should not be in within a bar - relatively independent of the time, as this is the last and only trade with the price $170,875 in this minute (from Alpaca’s side, not from Tradingview).
But thanks again for your post. That clarified some other issues I had ^^
I have a feeling I’m going to run into your issue soon in my own development. Are you seeing this issue only from the realtime stream, or also in the historic bars that you get from here? Historical Data | Alpaca Docs I’m wondering if Alapca has handled some of these details for us in the historic data.
It does seem like many vendors (TradingView, Polygon, InteractiveBrokers, TradeZero) follow very similar data handling practices. It would be really nice if Alpaca did the same, or at least had an easy mode option that followed these practices, and then have separate APIs for those that want to get into the hardcore details. It seems like they’re trying to offer developers maximum flexibility, but that means we have to figure out these nuanced details on our own, which we’re not used to doing when working with the other platforms mentioned above.
In the end I may grow to love this flexibility, but while in the process of trying to get everything transferred over to Alpaca, it’s a pain in the ass.
Unfortunately, I haven’t had the time to check if the realtime bars over Websockets differ from those over the REST API. Therefore, I can only say that the historical data gathered is different from the data from Tradingview.
I ran the test by saving the individual trades (realtime/#trade-schema) in realtime to a json-file. Then I calculated my own bars from this file. Afterwards I requested the Historical Data | Alpaca Docs of the period and wrote down the Tradingview data.
There are few, but enough differences to observe, mostly in the close, high, low and of course in the volume. I checked AAPL and BAC (pre-market [30 min], mid-market [2h], post-market [6 min]).
Fair enough; thanks for the insight. I’ll share my findings as well once I dig in further.
Regarding volume, I wouldn’t pay too much attention to it. Volume is something I haven’t had any luck matching between vendors, but it’s usually close. And in reality you rarely need exact volume. That said, I will say that Polygon and TradingView match 99% of the time. I’ve used Polygon for over a year in live trading and backtesting with great results, but paying $200/mo for data is getting old, especially as a personal trader, so I’m hoping to make the switch to Alpaca if I can ultimately live with the discrepancies.
Polygon is unfortunately not a solution as my final product goes to a professional trading company. 2k-3k $/mnth for data is too expensive.
Yes, i have given up trying to get the volume together. But the volume, as you said, is less important.
In that case, one more potential solution for you is to use InteractiveBrokers. If Alpaca doesn’t end up working out, I’m going to fallback on IB.
I currently use QuantRocket as my platform, which has built in support for IB realtime data. That said, it uses TimescaleDB under the hood for aggregating realtime trades into bars, which you could easily setup.
IB has great quality data (aligns with TradingView) for pretty damn cheap; it’s $15/mo for personal use; not sure about professional, but I’d assume it’s reasonable. Although I don’t use IB for order execution, I have a few thousand in an account so I can get access to their data. Hope this helps!
Thanks, as far as I know IB has a limit on requests per minute.
BTW, just checked again with my issue:
There is a trade (trade-ID 22393; time 13:51:59.894415). So you were absolutely right that it was a problem with the different times:
@jc_trade IB does have request limits, BUT you can run multiple IB gateways per accounts to increase the limits. Also, you can purchase booster packs to increase limits. Here’s a great guide on how to get the most out of the IB data API: https://www.quantrocket.com/docs/#historical-ibkr-data-guide
With a professional account, you also get way better limits assuming you’re paying more in commissions.
Yea man, this timing thing is going to be a pain.