Issue downloading transactions from Chase

[David Reiser]

> On Dec 4, 2015, at 9:04 AM, Bill Starrs <wjstarrsiii at gmail.com> wrote:
> 
> Hi,
> 
> I've been battling this same issue.  Constant rejection from Chase saying 
> that the username or password are incorrect and no help from customer 
> service. 
> 
> I had switched from Quicken 2013 last year to GnuCash but installed it 
> last night in a VM and connected to Chase.  It worked.  I then got the 
> email in the Secure Message center which took me to a website where I 
> clicked a button and it said all was good.  Quicken was then able to 
> connect and download transactions without issue. 
> 
> I then went right back to GnuCash and tried to connect but got the same 
> rejection.  The AppID and Version were the same in the OFX settings, but 
> there has to be something else that Quicken is doing which AqBanking is 
> not.  Looks like Chase is requiring something specific that identifies 
> Quicken specifically.  There was some kind of token generated that I 
> accepted from the secure message.  Perhaps this was generated by something 
> specific in the Quicken OFX request?
> 
> I have the OFX log from Quicken and will compare it to AqBanking to see 
> what else may be different.  I'm no expert in OFX however, if someone more 
> experienced would like to analyze after I scrub my account info out let me 
> know.
> 
> Best regards,
> 
> Bill Starrs
> 

Success!

Your comment that Quicken works led me indirectly to:
https://fi.intuit.com/support/security/ffiec/ <https://fi.intuit.com/support/security/ffiec/> and
https://fi.intuit.com/support/security/ffiec/MFA_FAQ_&_%20Refernce_%20Guide.doc <https://fi.intuit.com/support/security/ffiec/MFA_FAQ_&_%20Refernce_%20Guide.doc>

Back around 2008, I looked very hard, with no success, to find the information that Intuit has since published in the FAQ (second link above). That FAQ was last edited 2 years ago, but I haven’t been looking lately because none of my banks had been locking me out.

The current change results from Chase implementing Multi Factor Authentication for DirectConnect sessions by insisting that any Quicken-like software be able to supply a <CLIENTUID> tag as part of the login attempt. Martin supplied the capability in aqbanking by the end of 2008, but Intuit wasn’t providing any public help about how they were implementing it. The FAQ above provides enough of that information to get Gnucash reconnected to Chase accounts.

The key features are that aqbanking has to use “103” as the Header Version for its ofx connections, and it has to send a ClientUID.

The Header Version is on the Application Settings tab available while editing a User definition in an AqBanking Setup session accessed from Gnucash’s Tools>Online Banking Setup… menu.

The Client UID entry box is in the User Settings tab in the same Edit User dialog in banking setup. It has been a long time since I set up a new bank account for aqbanking, but reading some of aqbanking’s git log messages, aqbanking may offer the option of generating a ClientUID while you’re defining the user in the first place. For established accounts, it’s probably easier to find any old UUID generator and paste the results into that box in the Edit User dialog.

Because Intuit specifically says that Quicken sends a 32 character ASCII representation of a hexadecimal number, I’m almost certain that you have to delete the customary hyphens that show up in most uuidgen output. I also made my ClientUID lower case for any of the letters, based on someone else’s observations that their bank was requiring lower case. I have no idea if lower case is required, but it worked for me.

What happens with the connection is that the first time Chase sees an ofx header version 103 connection with a ClientUID that hasn’t been associated with your account, it will let you download transactions, but it fires off the ‘action required’ email to the address associated with your account, telling you to visit the Secure Message Area in your account page on the web. For me that outside email appeared approximately 3 seconds after I had connected. In that secure message, there’s a link that jumps to a verification web page (and Chase has pasted in your one-time authentication PIN) where all you have to do is click Next. There was some kind of successful completion page displayed.

Since completing the authentication process, I have been able to download transactions from my formerly blocked account from both 2.4.15 and 2.6.9 gnucash versions. They both use the same aqbanking user data, so chase just thinks I’ve logged in from the same app multiple times.

If I’m reading Chase’s tea leaves correctly, after February 15, you won’t get any grace period — you’ll have to authenticate before you can access any transaction data. It looks like the authentication PINs will expire in 7 days, now and in the future. If you go beyond 7 days (or maybe if you launch several attempts to log in without authenticating) it looks like Chase’s system will keep generating new PINs for each attempted login. Their mail message mentions you have to be sure to use the most recent PIN if you have received several secure messages regarding authentication.

The FAQ mentions that DirectConnect servers have to be at version 103 in order to implement MFA via ClientUID. In the Quicken realm all versions that haven’t been locked out of DirectConnect for failure to pay Intuit’s upgrade tax already use header version 103. Servers using version  103 are not required to use ClientUID, but 102 and earlier server versions are unable to use UIDs.

If you have already logged into a Chase account with Quicken and authenticated your ID, you might have to call Chase and have them clear your authentication. Intuit suggests that banks allow at least 2 valid ClientUID’s per account. But the banks can do what they want. Intuit also suggests that implementation of ClientUIDs be invisible to the user (#ChaseFail). Quicken stores the ClientUID in the data file, and at least in Quicken 2013 provided no way to see the number. The ClientUID was also redacted from the Quicken ofx logs, at least when I looked. Because the ClientUID is stored in the data file, you don’t have to update your authentication when you upgrade Quicken. The good news there is that GnuCash users might be able to use their authenticated ClientUID essentially forever (at least until Quicken’s potential new owner changes something else).

I hope I’ve found a general solution to the problem.

Dave
--
Dave Reiser
dbreiser at icloud.com