Issue downloading transactions from Chase
wjstarrsiii at gmail.com
Sat Dec 5 11:23:32 EST 2015
Actually took a bit but got another authentication message which I acted
on, connection is still working fine after that.
On Sat, Dec 5, 2015 at 10:38 AM William Starrs <wjstarrsiii at gmail.com>
> This worked like a champ! It looks like Chase will allow at least 2 UID's
> because the following got me up and running in just a few minutes:
> 1. Generated a Version 4 UUID here:
> 2. Entered it in my user settings in the aqbanking wizard - without
> the dashes
> 3. Changed the Header version to 103 (was 102)
> 4. Connect and instant success! Transactions and balance downloaded
> with no error messages in log.
> Also at least within the last 5 minutes there are no new authentication
> messages in the secure inbox. Appears to be smooth sailing from here.
> Thank you very much for your assistance.
> On Fri, Dec 4, 2015 at 8:46 PM David Reiser <dbreiser at icloud.com> wrote:
>> On Dec 4, 2015, at 9:04 AM, Bill Starrs <wjstarrsiii at gmail.com> wrote:
>> I've been battling this same issue. Constant rejection from Chase saying
>> that the username or password are incorrect and no help from customer
>> 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
>> 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
>> experienced would like to analyze after I scrub my account info out let
>> Best regards,
>> Bill Starrs
>> Your comment that Quicken works led me indirectly to:
>> https://fi.intuit.com/support/security/ffiec/ and
>> 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 Reiser
>> dbreiser at icloud.com
More information about the gnucash-user