No response from OFX server

Wed Jul 31 11:39:20 EDT 2013

Hi Dave,

Thank you for continuing to help. I added TD Bank to the subject line, in
case someone knows something related to them. I downloaded and installed
the latest version of GnuCash the other week, would this have installed the
latest version of Aqbanking as well? How would I verify the version?

I did find a OFX request website (put in all the required information, and
it spits out the request and response).
https://www.barereef.com/ofxget.php?id=-1

This is what I get for a response. I'm not sure if they blacklisted the
website, or if this is related to my issue.

<HTML><HEAD>
<TITLE>Access Denied</TITLE>
</HEAD><BODY>
<H1>Access Denied</H1>

You don't have permission to access "
http://ofx.tdbank.com/scripts/serverext.dll" on this server.<P>
Reference #18.bd1a32b8.1375284522.85e7b0
</BODY>
</HTML>

On Tue, Jul 30, 2013 at 3:31 PM, David Reiser <dbreiser at icloud.com> wrote:

> It could be the date, but 1969-12-31 is Unix day 0, I think, so that
> shouldn't be a problem. Quicken does use 19900101 as their
> as-far-back-as-we-go date. But I ran a gnucash transaction retrieval
> request that only went back a couple years. I saw the same no response in
> ofx.log that you are seeing.
>
> The only other difference I see is the <TRNUID>. The ofx spec says that
> the field is A-36 (36 unicode characters). In the description of TRNUID,
> though, the spec says TRNUID is a 36 character hexadecimal encoding of a
> 128-bit number. Maybe someone changed the server code and it's choking on
> the aqbanking-generated TRNUID, which looks like a datetime. That would be
> bad programming on Intuit's part, but it wouldn't be the first time.
>
> For TRNUID
>   Quicken uses full guids like: ADA4C400-7B95-1000-8F6D-D8FFF4B80026
>   aqbanking uses datetimes (they are globally unique for
> aqbanking): 20130730131426.000
>   your Moneydance example used: 1374688739780-4
>
> I'm only using Aqbanking 5.0.23, so I'm several versions old. I'll have to
> see if any changes have been made since then to the ofx direct connect
> routines.
>
> Keep in mind the TDBank went _months_ recently with their ofx server being
> incompatible with Quicken 2007 for Mac (the most recent version available
> for the mac, btw). And this year several other financial institutions had
> troubles providing transaction downloads to Quicken customers in general.
> One of the comments by an Intuit employee mentioned that Intuit is being
> much stricter in matching bank names with source connections, so that could
> be an issue.
>
> I had a TDBanknorth checking account for a while. Before the Commerce Bank
> acquisition, I believe TDB's ofx server was written in-house. After the
> Commerce Bank acquisition they seemed to switch to Commerce's ofx
> infrastructure (hence the <ORG>CommerceBank tag). I'm pretty sure the
> current server is running Intuit software.
>
> I'm pretty much out of ideas, since I can't test anything without a valid
> TDBank account.
>
> Dave
> --
> Dave Reiser
> dbreiser at icloud.com
>
>
>
>
> On Jul 30, 2013, at 1:00 PM, njtechteenager at gmail.com wrote:
>
> Hi Dave,
>
> I did set that, but all I see in the log is what I originally posted. I do
> not see a response from the server. From the MoneyDance log I see that the
> request date is from 1990 on, while GNUcash is 1969, could the server be
> failing because of such an old date?
>
> Thank you, Chris
> On Jul 30, 2013 11:44 AM, "David Reiser" <dbreiser at icloud.com> wrote:
>
>> On Jul 30, 2013, at 9:45 AM, njtechteenager <njtechteenager at gmail.com>
>> wrote:
>>
>> > Hi David,
>> >
>> > I've looked at many of the TD Bank posts, but none of them are recent,
>> and I
>> > haven't been able to pull any useful information from any of the posts.
>> >
>> > Is there a way to see if the server is sending *any* kind of response,
>> even
>> > if it isn't in OFX format?
>> >
>> > Chris
>>
>> If you set AQOFX_LOG_COMM=1 in your environment, then both what gnucash
>> sends and what the bank sends back appears in ofx.log, usually in /tmp.
>>
>> Don't leave the variable set, though, because the log file will contain
>> your login credentials in plain text.
>>
>> --
>> Dave Reiser
>> dbreiser at icloud.com
>>
>>
>>
>>
>>
>