Fidelity NetBenefits (QWIN)Closed
Find more posts tagged with
- Fidelity fixes the OFX export to reinstate the CUSIPs for these funds. This should be the quickest solution, but it is entirely up to Fidelity if/when they make this fix. Other than pressuring Fidelity, Quicken has no control over this timing.
- Quicken changes its logic to match securities against some other data elements (e.g. the fund's name) if the CUSIP is missing. This approach is inherently risky and brittle as names change all the time. It's also not a minor change and could have unexpected side effects in the future.
- Fidelity forces Quicken to move to a different import mechanism, such as using EWC+. Direct Connect/OFX is a "legacy" integration method, and is likely deprecated at Fidelity; consequently, they may be resistant to investing time in fixing this depending on how many partner integrations have been broken. Switching Fidelity to EWC+ is likely on Quicken's roadmap, but will take a while to implement and test.
At this point, given the info here and in the r/fidelityinvestments sub-reddit, I think we can be fairly positive about the root cause of this issue: on or about 3/8, Fidelity made a change to their OFX export API which broke Quicken's ability to import data for certain types of securities. More specifically, Fidelity is omitting the unique CUSIP that identifies some 401k-specific mutual funds, which is a field required by Quicken to match these funds against the holdings in your Quicken file. (Note: the CUSIP is a required field based on the OFX specification, so Fidelity's OFX export is now non-compliant with OFX standards.)
It appears that Quicken and Fildeity are both aware of the problem, although no ETA for a fix has been provided. In terms of a fix, there are really just a few possible options:
Hopefully, Fidelity fixes this soon as this change clearly makes their OFX export out-of-spec with OFX standards. Again, it may depend on how many partners are consuming their OFX API and how much impact those integrations have on Fidelity customers like us.
> Security is a big deal for Banks and Brokers (and everyone else whether they know it or not). They develop their own systems and guard them scrupiously. They understandably do not want to share their security protocols or access with anyone else. The more hands there are sharing, the more chance of a security breech. Every time a comapny tightens their security, Quicken has to adjust and either negotiate, or cirumnavigate the security obstacles with a company that does not want to share. So far it was happened with Schwab, and now Fidelity NetBenefits, and others. The pattern will repeat. I thik the days of data consolidators are numbered. There is nothing it for the financial companies themselves.
To be clear: Q's Direct Connect, other's OFX connections, are NOT data aggregation. A standard (continually evolving) exists for establishing the communication channel. The standard continues to include new security protocols (like TLS that Fidelity have chosen to implement). The standard is backward compatible, however, if one chooses to use one of the new security protocols, the downstream users (Q, other financial programs, other banking programs) have to adapt. Q apparently has not done so yet.
All that said, more and more institutions are moving away from OFX connections (Chase and Bank of America, two of the most recent in my experience). When that happens, some other mechanism will be needed to download transactional information ---- or we are left with download, import/export processes ---- or worse yet, manual entry (uggg). FDX is an up and coming protocol, but it is too young to be full blown mainstream, nor has it been adopted widely. Scrapers (like Mint, some banks, other financial institutions [even Fidelity says, give me your other accounts (and credentials), and they will show you a consolidated view of your financial accounts] do NOT use OFX connections. They use HTTP output (like you see when you visit the webpage) and use the pieces they need -- scraping the info. Fidelity (I believe the root cause in this event) has/is changing how third parties that you provide your credentials to, for them to scrape the info. I believe that broke NetBenefits from the Fidelity Investments side of the business.
None the less. For a paid subscription model as a business, more transparent communication definitely should be expected.
Fidelity NetBenefits - Valuateion/Updates Not Working. I have found no way to resolve this. What is Quicken's team doing to resolve this with Fidelity and when will this be fixed? (Windows 10 O/S). I am a very long-time Quicken Premier (online) user, however it is unacceptable to have to manually login to my Fidelity account for balance informatio then manually update either a postive/negative cash balance in order for Quicken to reflect correct valuation.
What are you seeing that makes you believe there is a TLS issue? For me, the Quicken OFX Log shows that the HTTPS connection to Fidelity appears to be working as expected, but the OFX data that's returned from Fidelity is non-compliant (which results in a "Parse error. Current object: SECID Missing Tag: TAG UNKNOWN" in the Connection Log).
As for OFX vs FDX vs scaping, the industry is certainly moving to more secure, reliable, API-based approaches such as FDX. These types of approaches no longer require the aggregator (e.g. Quicken) to store your credentials for the FIs you do business with. We've seen Quicken making this transition as they've converted different FIs to EWC+, which relies on FDX (or other FDX-like protocols) to exchange info without storing your username/password.
Such changes were inevitable as aggregation moved off of the desktop (i.e. locally-installed software like Quicken) and into the cloud (e.g. Mint, Personal Capital, …). When passwords were stored locally on your computer, there was little risk of (wide-spread) exposure. But storing millions of users' credentials in the cloud is high-risk.
As for scraping, certainly this is used for many smaller FIs, but for large FIs like Chase, BofA, Fidelity, Schwab, etc., scraping is a largely thing of the past. Now, as FIs deprecate their OFX integrations, they are being replaced with more secure, FDX-based (or FDX-like) APIs. None of these large FIs will expect aggregators/integrators to revet back to scraping; in fact, their licensing agreements likely disallow it.
I am having same problem as others are reporting, all of my other non-Fidelity NetBenefits account are updating just fine. I even have another separate Fidelity account that is updating just fine. Problem appears to be limited to the Fidelity NetBenefits account. The last sucessful update was 2/19/23. In the One Step Update Settings window, it shows up as "Fidelity NetBenefits: error recovery". I have reset the two accounts contained within Fidelity NetBenefits, with no improvement. I have Quicken Deluxe, Version R48.9, Build 27.1.48.9.
Please get this fixed.
Quicken Premier, version R48.9, build 27.1.48.9, windows 10 enterprise.
Fidelity NetBenefits
Error: OL-220-A | 2 accounts
Quicken is unable to complete your request
Shows last successful download March 2, 2023
I regularly update quicken software whenever prompted. I do not recall which version /build this issue started with, but updates had been working fine until about March
> @LQLA
>
> What are you seeing that makes you believe there is a TLS issue? For me, the Quicken OFX Log shows that the HTTPS connection to Fidelity appears to be working as expected, but the OFX data that's returned from Fidelity is non-compliant (which results in a "Parse error. Current object: SECID Missing Tag: TAG UNKNOWN" in the Connection Log).
>
In the banking program that I am using (not Q) I get the following in response to an OFX request:
connecting to: https://ofx.fidelity.com/ftgw/OFX/clients/download with method: POST
Connecting to ofx.fidelity.com
acceptable TLS protocols: [TLSv1.3, TLSv1.2]
Supported cipher suites:
TLS_AES_256_GCM_SHA384
There are at least another 20 or so TLS "cipher suites" entries. The correctly requested data then follows. Even for my NetBenefits account.
So why am I here if I am not having the problem? Well, I am having the problem with an investment tracking software. When I look at that OFX log (no downloading is occurring) - there is no mention of TLS in the entire log. From my point of view - "doesn't download - no TLS in log; does download - TLS and cipher suite references throughout." It helps me talk in the forum for the investment tracking software (not Quicken) - if I say either - Q had this problem and got it solved; or Q has this problem and has not resolved it yet". But make no mistake, I am quite happy and pleased that my banking software is downloading via secure OFX connection.
All I get when I call into Fidelity is "have you de-activated/re-activated your connection; or have you tried an empty data file." Upon hearing yes, the response so far has been, not our problem, it's a Q problem.
I am very familiar with the difference between Fidelity Investments and Fidelity NetBenefits.
In my banking account (which does download transactions), I see several <SECID> requests, all retuning with a <UNIQUEID> xxxx <UNIQUEIDTYPE> tag. The xxx in this case ends with the same digits as the CUSIP of the security in my 401k.
I do not get such responses to <SECID> or references to TLS in the OFX log when downloading from any of my 5 other financial institutions.
All of this makes my highly suspicious that some sort of TLS security overlay has been implemented at Fidelity, which has broken the existing OFX connection. But finding someone that knows or admits to that at Fidelity is hopeless.
Fidelity investments is doing a major overhaul of thier systems trying to tie them together between fidelity investments UI and netbenefits UI especially around brokerage link transactions. I am sure it is interface related and is no longer parsing like it should be with the new system changes. This will probably need to be rearchitected with a new interface on quickens end.
> Fidelity investments is doing a major overhaul of thier systems trying to tie them together between fidelity investments UI and netbenefits UI especially around brokerage link transactions. I am sure it is interface related and is no longer parsing like it should be with the new system changes. This will probably need to be rearchitected with a new interface on quickens end.
That aligns with my experience. My Fidelity NB account (BrokerageLink) all of a sudden started downloading with My Fidelity Investments OFX connection.
On a different note, there are $$$$$$ to be had by combining the Retirement Services Group with the Investment Group. Right now they are two TOTALLY INDEPENDENT organizations. Neither talk to each other. It is absurdity beyond belief. Surely the cost of compliance with any 401k regulations and restrictions is less than the cost of TWO INDEPENDENT ORGANIZATIONS that cannot get their technologies aligned.
@LQLA
If I understood your response correctly, you are using separate applications for banking and for investment tracking, neither of which is Quicken. By comparing those applications' logs, you've inferred that a TLS-related issue is preventing the investment tracking app from downloading NetBenefits data. Is that right?
I can say unequivocally that the Quicken issue is not TLS-related. If TLS were the problem, Quicken's OFX log would not be showing any data as the TLS error would prevent Quicken from establishing an HTTPS connection to Fidelity. The presence of OFX data in the log indicates that the connection must have been succesful.
Of course, I can't comment on your other software applications; however, the fact that another application is also failing for NetBenefits does imply the problem is on the Fidelity side.
@MichaelL
It sounds like you're suggesting that Quicken is scraping data from the Fidelity UI and that this failure is tied to recent Fidelity UI changes. I can assure you that is not the case; Quicken uses a Fidelity-provided API to pull data. That said, if Fidelity is attempting to unify Retirement and Investment Services, it's certainly plausible that some back-end change related to that effort has had this unintended side effect.
Of course since I left Q over 5 years ago, before the subscription model, I can't really comment on what is or is not the issue with Q and what is in or not in their logs. It appears obvious that no-one really knows what is or isn't happening, whether it is or is not related to TLS (you seem convinced it is not) - Q or Fidelity. At least they are not talking about it. Meanwhile, we all wait patiently, or not so patiently for ANY word, communication, fix from Q or Fidelity. We will all be satisfied once we reach that outcome.
I would agree that Quicken is responsible for working with Fidelity on our behalf to get this fixed, and I certainly wish Quicken would be more forthcoming with what they've found, what interactions they've had with Fidelity, etc. But, I don't believe Quicken can fix this unilaterally. It's unfortunate, but as advocates for their users, Quicken is completely tone-deaf: their lack of transparency is left for most of us to interpret as indifference.
I am continuing to get Fidelity NetBenefits OL-220-A errors, "Quicken is unable to complete your request". Last update of my Fidelity NetBenefits account was March 7, 2023. Attempting to add an account from Fidelity NetBenefits to a 'New Quicken File' results in: "Sorry. We encountered an error. (It's not your fault.)" Updating Quicken to 'Version R48.9 Build 27.1.48.9' on Windows 10 Home did not resolve the issue. It looks like Quicken may already be aware of this issue which has been going on for quite a while now. It would be nice if they would provide us with an update when they have identified the problem and provide us with an "official" explanation of the cause of this issue.
It doesn't matter what version or anything else. As far as the error code, if you look at the thread you're on, all 15 pages is OL-220-A for Fidelity Net Benefits accounts only.
I continue to have issues updating the value of my Fidelity Net Benefit account in Quicken. I have not changed my Net Benefit "securities" except quaterly when some are sold to pay management fees. The last sale was 1-3-23 and those sales posted properly to Quicken. While troubleshooting my account I went to Fidelity and forced them to download transactions from the beginning of the year. I knew it would duplicate the 1-3-23 sales but that I could delete them. Interestingly it duplicated them with slightly different security names. For instance my "Total US Stock Index" became "Total US Stock Index(OJJ4)". When I look on Quicken for my holdings in the account these newly named stocks show up as new stocks with a negative value. Usually Quicken will ask if new stocks are being added so you can link them to the old stock names but this did not happen. I was wondering if this could be part of the update problem?
Hello All,
Thank you for taking the time to visit the Community and reporting this issue here, though we apologize that you are experiencing this.
This issue has been escalated internally, though we do not have an ETA at this time. While the investigation remains ongoing, please refer to this Community Alert for any and all available updates.
Thank you!
-Quicken Anja
Make sure to sign up for the email digest to see a round up of your top posts.
Security is a big deal for Banks and Brokers (and everyone else whether they know it or not). They develop their own systems and guard them scrupiously. They understandably do not want to share their security protocols or access with anyone else. The more hands there are sharing, the more chance of a security breech. Every time a comapny tightens their security, Quicken has to adjust and either negotiate, or cirumnavigate the security obstacles with a company that does not want to share. So far it was happened with Schwab, and now Fidelity NetBenefits, and others. The pattern will repeat. I thik the days of data consolidators are numbered. There is nothing it for the financial companies themselves.