Issue downloading transactions from Chase

David G Hamblen dhamblen at afrinc.com
Sat Dec 5 11:18:50 EST 2015


Bill,

After my success, I got an email telling me to go to the secure inbox, 
which I did, and things still work.

DaveH

On 12/05/2015 10:38 AM, William Starrs wrote:
> Dave,
>
> 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:
>     https://www.uuidgenerator.net/version4
>     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.
>
> Bill
>
>
> 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:
>>
>> 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/ and
>>
>> 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
>>
>>
>>
>>
>>
>>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.



More information about the gnucash-user mailing list