Schwab - wrong transaction dates

JPG

Yet another update from the Schwab Customer Advocacy Team. Looks like Wurster has lit a fire under everyone. He clearly understands that even if Quicken is at fault, the issue is damaging the relationship between Schwab and its customers.

"October 15, 2024

Dear Joseph Giasi, 

I'm sharing some additional information provided by our Technology team regarding the Quicken issue.  Clients can upload the transaction history into Quicken in two ways:

From Schwab.com a client can download the history into an excel file and upload this information into Quicken.

This process is working as expected and no issues were identified.

From Quicken software, a client can initiate a call to fetch the transaction history and this request is handled by system interface on our side.

The data sent by our interface is correct, and our team has validated the response.

There is a bug on the Quicken side that is incorrectly loading the transaction date.

Quicken accepted and confirmed the bug is on their side.

We are actively working with our vendor to fix the bug.

Our technology team indicated we would be initiating a call with Quicken to expedite a fix for the defect. Although we do not have an estimated time of resolution, I will continue providing any updates I can find.  

Sincerely,

Dan Siffring

Resolution Manager | Client Advocacy Team"

Stu

The finger pointing ping-pong game continues. I had a similar email response from my Schwab FA after I told him of my own letter to Wurster. So do we now have to put the pressure again on Quicken?

ronwalter

These two statements seem to be a contradiction:

"Quicken accepted and confirmed the bug is on their side.

We are actively working with our vendor to fix the bug."

veegee

One day the problem will suddenly disappear, and we'll probably be still left wondering what happened.
Oh, well, as long as it gets fixed.

One thing that seems to come out from the JSON data is that the 'time of the trade' information appears to be available to Quicken. Now, if only we can get Quicken to also present the transaction downloads in 'time' order.
Wait, sorry, I am dreaming.

K123

Thanks to all who have helped elevate this issue. It looks like activity is happening, although no visible progress yet.

As an aside, one of the temp "workarounds" suggested above by Schwab is using a CSV file to import the investment transactions in the meantime. I have looked for years for a good way to do this with Quicken but have never found one I'm smart enough to use. It's easy to import prices, but I've found no tool that will actually support the conversion to a QFX or OFX file that Quicken recognize in the Investment register.

Anyone here have a good solution while we await the Quicken/Schwab resolution? I'd love to hear about it.

smutschler

Reflecting back on the first response letter from Schwab to @JPG, it contained this quip: "… Schwab’s Data Aggregation Services Owner, as well as the company who operates the infrastructure for Quicken, …".

Don't want to read too much between the lines, but I'd bet that the "Data Aggregation Services" are the ones who store and provide the data for both Intuit (the middleman for Quicken) AND the data made available through the JSON download interface that @Bill44 made us aware of weeks ago. That snapshot of JSON data is still the smoking gun in my mind. The transaction example contained a field with accurate date datum as well as additional fields containing "day before" dates. Hard to ignore that.

In the second letter to JPG we hear Schwab's IT folks telling the execs "it's not us, it's Quicken". There are several possibilities: 1) Schwab techies haven't dug deep enough to realize the problem in on their side; 2) they are lying to their execs (unlikely at these levels, too suicidal); or, 3) the problem actually is with intermediary Intuit, which would seem to point to something to do with international time zones, date conversion, or the like. Or even more remote, maybe the Data Aggregation Services are passing additional data (time zone identifiers?) that are used by receivers to perform date conversion, and this ancillary data is now incorrect. A secondary data dependency issue like this could easily go unnoticed by programmers looking for something more obvious.

Sorry for pontificating, but I post here in the hopes that someone at Quicken will read and be stimulated to look into non-obvious rabbit holes.

Stu

Yet another twist today that points a finger back to Schwab. I did an option rollout trade yesterday. These rollouts usually cause Schwab to post the CvrSht portion immediately to the History file. This is later updated to reduce the commission when they realize it has a matching ShtSell. The original CvrSht post is then deleted. This is normal.

In this case, when I did the Quicken OSU today, not only were the dates wrong as usual, but Quicken recorded TWO CvrSht transactions - one with the original commission, and one with the updated commission. I have never seen that before. Quicken could only have done this if Schwab sent BOTH the original and updated CvrSht transactions. Quicken could not have generated the first transaction out of thin air.

veegee

I had written a reply to @Stu 's post explaining how this can happen. It got deleted by someone. No reason was given. I would like to understand why.

veegee

I don't think Stu's issue has anything to do with the date issue.

Say Schwab creates the original transaction O at time t1, and then a replaces it with transaction M at time t2 (usually towards end of day).
If you do download from Schwab between times t1 and t2 (and the request goes all the way to Schwab) you will have transaction O downloaded. Then later, after time t2, if you do a download again (and the request goes all the way to Schwab), you will have transaction M downloaded too.
Quicken cannot recognize the downloaded M is a replacement for the downloaded O. You may even have accepted O into the register before you download M.

Now, what do I mean by "the request goes all the way to Schwab) ? From my observations, the data fetch from Schwab appears to be "cached" i.e. stored locally -somewhere by an intermediary (Intuit?) Further requests within a certain period of time does not go all the way to Schwab, but are served 'from the cache'. Which is why you do not get up-to-date data from Schwab every time you do a download.

smutschler

Very disappointed, another week goes by with no ETA from Quicken. It is hard to believe anyone is really working on this. Why this is not receiving higher priority is truly puzzling.

ronwalter

My understanding is this is a problem Schwab has to fix, so I'm directing my frustration towards my Schwab Financial Advisor,

Stu

@ronwalter. No harm in that, but the ball just bounces back to Quicken from Schwab.
See above in the response from Schwab: "The data sent by our interface is correct, and our team has validated the response. There is a bug on the Quicken side that is incorrectly loading the transaction date. Quicken accepted and confirmed the bug is on their side."

Rick8

Having the same issue as well. Thanks for posting. I thought I was nuts!😶

Stu

https://community.quicken.com/discussion/comment/20456845#Comment_20456845

So maybe we just have to wait another few days to see if the UTC adjustment or other timezone issue is the root cause. If our problem disappears on Monday, that's a smoking gun. It just means the problem will be dormant until March 9th next year unless it's fixed properly. It does seem that Bill44's forensic work should be used by Quicken engineers to fix the problem. There's been no Quicken comment for three weeks on this. The engineers need to look at any updates they made to their software on the weekend of June 15th, when the problem first appeared.

Larry Goodnight

Thanks Stu for all of your help in figuring out what the problem is here. I've used Quicken for over 30 years and every now and then there seems to be a problem that takes much longer to solve than it should. Hope we are near the end of this one. This one has been a real headache for me.

smutschler

So frustrating! Even if this problem is not technically on Schwab's side of the fence, Schwab should be involved and leaning hard on Quicken to fix it. It is unique to Schwab, so a Schwab embarrassment. At the very least, they should be pointing fingers at Quicken loud and publicly. That would help speed things up, I am sure. The fact they have posted no public announcement is a smoking gun. They were not so hesitant to lay blame when the Microsoft software glitch took them down earlier this year.

Bill44

This is what I have done to adjust the date & Time from Eastern to Central. this is in .NET.

            Dim dt As Date

            For Each Tran In TransactionsList

                dt = TimeZoneInfo.ConvertTimeBySystemTimeZoneId(Tran.settlementDate.ToUniversalTime, "Eastern Standard Time").Date

                Tran.settlementDate = dt

                dt = TimeZoneInfo.ConvertTimeBySystemTimeZoneId(Tran.tradeDate.ToUniversalTime, "Eastern Standard Time").Date

                Tran.tradeDate = dt

            Next

Ye, I know, I do not need dt. I left it there for clarity. It's from my testing.

If you, Quicken or your partners, use this or derive any help, I would like an enhancement to Quicken I have been asking for years and it keeps getting denied.

Allow a way to have Bill and Income Reminders enter on the 1st of the month, instead of having to calculate the number of days. I have several I have to change every month. (It doesn't hurt to ask).

Stu

@Bill44. Your code is right on the nose. After digging around, here is what comes up in the Quicken spec for the FI interface:

Page 53

"DTTRADE (in INVTRAN) - Quicken uses this date for the investment transaction, without converting to local time zone." (my emphasis).

This is specified in their manual: https://us.v-cdn.net/6031128/uploads/editor/03/zjl4b668yi1c.pdf

While the spec is 6 years old and refers to OFX rather than QFX, I'd wager a large sum that it is still in effect and the cause of the problem.

By using the Schwab trade date (incorrectly presented as one hour earlier than truth when DST is in effect), QuIcken is giving us the wrong date "without converting to local time zone."

As such, Quicken tells the FI that they are not going to convert the date and the FI (Schwab) ignores the interface definition. They are both at fault.

Rick8

Yes, it all makes sense, except…..everything was working fine for years before July 2024!! User since DOS 5.25 Floppies.

Bill44

Schwab brought the last set of users from TD Ameritrade over mid-May 2024. This was the users that have their own API for accessing Schwab. Schwab created a whole new API from scratch just for us. I am pretty sure that this transaction issue is related. I had several challenges with dates because of the differences with TD Ameritrade. This is what their dates look like "2024-11-01T13:22:51.023Z".

All of the developers using this API have figured it out and are currently using it just fine. I haven't seen any issues with date since the original ramp up to the conversion. It seems, only one user, with paying customers is refusing to fix it.

JPG

@Bill44

That is an interesting analysis. I was a former TD Ameritrade customer (and wish I still was!), and I was moved over in May. So, are we to conclude that the only Schwab customers affected by the date problem are in that subset?

But the date problem didn't arise until July. What would account for that delay in the problem's appearance? (I am resisting an aside about Venn diagrams.)

Also, if we are only a small subset of Schwab's and Quicken's customer bases, it does not portend for a speedy resolution of the issue, which is now in its 4th month!

Sam Dickerson

Just to clear up the Venn diagram speculation I have the date problem and am a long term Schwab customer never a TD one. I, too, keep wondering how it was that something working fine for a long time suddenly goes haywire… and, of course, why it's not getting fixed. As an aside, I wrote my first program in FORTRAN in 1969… so, one might say I have bit of experience and, not so long ago, proficiency in computer technology generally. Mystifying… I do realize we have, at least, three parties involved, but cmon man… Somebody or somebodies changed something…

Larry Goodnight

Replying to @Bill44 comment "That is an interesting analysis. I was a former TD Ameritrade customer (and wish I still was!), and I was moved over in May. So, are we to conclude that the only Schwab customers affected by the date problem are in that subset?"

I have been an active trader with Schwab since 2019. I never had a problem with the wrong trade date on stocks until July 2024. So I don't believe this only affects the subset of customers moved over from TD Ameritrade.

Stu

There continues to be some confusion about when the problem first appeared. While it was first reported on this forum in July, it had been occurring earlier. My own analysis first identified the weekend of June 15th, but recently I looked at all transactions between March 1st and today. On one of the accounts, it clearly shows it started over the Memorial Day weekend on May 27th. 3-day weekends are the most popular with systems companies to undertake major upgrades… See below:

The rightmost column shows any date differences between the Quicken reported transactions on the left and the Schwab ledger on the right. The date differences of zero extend back beyond March and those of one day extend up through today.

@Larry Goodnight. My example above shows transactions in a Schwab checking account. I had previously traced errors in my Schwab brokerage accounts back to June 15th, but have not been able to definitively trace them back to May 27th yet.

A couple of other facts:

1. It is not confined to former TDA clients
2. If you are a Schwab customer living in Arizona or Hawaii, you may not be experiencing the problem. This was raised to me by a senior Schwab customer service person. Guess why not? AZ and HI do not observe DST.

K.

I'm at Schwab and using Quicken more than 30 years. All transactions downloading with the date once day earlier than actual. I never had a TD Ameritrade account. Does not matter what time of day, time zone, type of trade, etc. - everything is dated one day prior to actual

Bill44

I did not mean that this only applied to TD Ameritrade customers. I was saying Schwab made changes to their systems to accommodate the users that have direct access. I am thinking that all downloading was affected. This means those with direct access like Quicken which is using the same transaction download as the rest of us with API access.

This is why I pointed this out, as I fixed it for my system.

Sorry to confuse you!

veegee

DST changes at 2:00AM on Sun Nov 3 - so if this is a DST related issue, then we can expect the problem to disappear on Monday, I presume. (Till it re-appears next year).

I don't see why data transfers - or storage - that include dates use anything other than UTC. IMHO, they should. It should only be at user presentation level that they be converted to local time.

veegee

I downloaded transactions for today (Mon 11/4/2024) mid-day. They show up with the previous date - Sun 11/3/2024.

Larry Goodnight

I just downloaded stock purchases and sales I made today (11/04/24) using Schwab. Daylight savings time started yesterday. All transactions that I made today and downloaded today using Quicken One Step Update were dated 11/3/24. I don't believe this problem has anything to do with daylight savings time.

smutschler

@veegee and @Larry Goodnight, I also concur!