ETF Price History Issue on Certain ETFs

Gilley7997

So I have been having an issue with certain ETF Price History Values being incorrect and finally had a chance to dig into it with a little troubleshooting tonight.

These are the ETF's that I am seeing this issue occurring with:
BND VYMI IGRO VNQI VIGI VCIT VMBS

Lets take VMBS as an example:

Here is the current price history for VMBS in my file:

And Here is the price History in a brand new file with this security added:

If we take a good look at for example 12/16/2021 There is no entry in the new file, but in my file I have a value with a price of $52.93 and 0's for the rest of the data. The issue is that this was not the closing price at the end of 12/16/2021 that was $52.91.

I can only assume that what happened here is that I ran a one step update sometime during the day and pulled down the 52.93 price, or somehow or other was able to pull that value, which was the high value for that day but definitely not the close. This pattern holds true for for all the values in my file that do not have a corresponding value in the new file price history. It seems that the value I'm pulling sometime midday is being recorded, but then never updated again, and no I did not make any trades on that day, so it's not a price that's coming in from a transaction.

Any thoughts as to why this would be occurring, and why the price history is missing even in a brand new file?

Thanks

Jim_Harman

Normally for a new security, Quicken downloads daily prices for the past 30 days, Friday prices for the 11 months before that, and month-end prices for years 2-5.

Your new security file is missing prices for even numbered days in December, except for the last week. I got the same result for VMBS and also for BND, and don't know why.

I think your analysis for 12/16 is correct. If you do a one Step Update while the market is open, Quicken may get a real time quote from your FI even if there was no transaction. Usually these quotes are the ones that are missing the High, Low, and Close data. That quote will remain in the price history unless it is over-written by a quote from the quote provider, but it looks like the quote provider is skipping even numbered days.

q_lurker

Odd.  Just this evening I added VMBS to my test file.  It now seems to have more complete data. Maybe somebody reacted to your morning post.


You can see the 12/16 price now shows as the 52.91 you said was proper.  

But BND still shows the skips - only odd dates from 12-7 through 12/23 and a couple of zero hi-lo-volume figures in the data as well (12/24, 12/29, 12/31 = same pattern your new file VBMS data shows).  

I don't think your during-the-day updates had anything to do with the bad data.  I'd put it all on the data supplier.  If these are holdings in a Vanguard brokerage account, I don't believe they provide real-time quotes (in my limited experience and testing).  

For VBMS, I'd suggest backing up your file, deleting the last 30 days of prices, and doing a fresh quotes update.  For the others, you might try the Report a Problem through Help citing the specific ETFs.

Gilley7997

> @q_lurker said:
>
> I don't think your during-the-day updates had anything to do with the bad data.  I'd put it all on the data supplier.  If these are holdings in a Vanguard brokerage account, I don't believe they provide real-time quotes (in my limited experience and testing).  
>

Yeah the holdings are in a Schwab account if that makes any difference as far as to how the incorrect price may have gotten in there.

It was just interesting to see the problem showing up on certain ETF's and in odd patterns, and I agree it seems service related than something specific to my file. I wanted to get some other confirmation on the issue and get it out here as maybe something to be looked into, because the only reason I noticed is that I happened to glance at a Price Day Change number in Quicken and the corresponding one in my FI web page for a holding, and was like why aren't those equal???

If your only relying on the data in Quicken, it appears that the service is providing junk data or no data at all in some instances, and maybe needed to be reported.

q_lurker

Ahhh.  Schwab.  With all the fiasco associated with that transition, that might be the source of the extra data in your working file.  

Gilley7997

@q_lurker

Could you by any chance check VMBS again in your test file this morning? So last night before bed I ran one step updates and verified that everything was looking good for 1/4/2021 for this security.

This morning I ran a one step update in my main file, and it blanked out the good price information from last night and updated it with something else, I don't know from where.

So I went back to my test file the price history from 1/4/2021 is gone for 1/4.

This has to be a quicken problem that needs to be resolved.

q_lurker

Yep,  Changes. 
I opened file and checked == looked the same as last night
Download Quotes == some differences
Download Historical Quotes == no further changes

Differences noted on two dates Close / Hi / Lo / Vol
1/4/22
was 52.66 / 52.66 / 52.28 / 1,474,256
now 52.63 / 0 / 0 / 0
12/31/21
was 52.84 / 52.87 / 52.79 / 1,036,688
now 52.80 / 0 / 0 / 0

Not sure what to make of that.

q_lurker

For documentation purposes, my data from evening of 1/5/22

Gilley7997

So how does one get the attention of Quicken to get this looked at as it's clearly not a me thing, and I have noticed this type of thing going on for some time now just hadn't had time to look into it.

Jim_Harman

It's not easy. You can use the Report a Problem link from inside Quicken, but you will not get a response. Make sure you reference this discussion in the description.

Your best bet would probably be to contact Quicken support and make sure the agent understands the problem. A new data file that exhibits the problem with clear Steps to Reproduce usually helps.

Frankx

Just to muddy the waters a little more...

Here are Vanguard's NAV prices for the time frame 12/03/2021 through yesterday.  As this is a Vanguard security, I would believe these are primary source data.



Please note that the NAV price for 12/16 was actually 52.93 not 52.91.  I suspect that Schwab (with its newfangled connection method) could be the culprit here, but that is just a suspicion at this point.

(edited to clarify - NAV vs. closing price)

 Frankx

Jim_Harman

Remember that unlike mutual funds, for an ETF there is a spread and the NAV (Net Asset Value) is not generally the same as the closing price, might be higher or lower by a few cents.

I think the quote is the market price, not the NAV.

[Update] It turns out I noticed the problem with ETF closing quotes switching back and forth between NAV and market price back in 2017. Still not resolved apparently ...

Gilley7997

@Quicken_Tyka Any chance this can get turned into some type of issue and looked into? It is annoying to have bad data showing up in the files, especially when it changes after it was initially correct.