On May 12, 2006, at 3:38 AM, Christian Stimming wrote:
[...]
If I understand you correctly,
then in OFX we should not rely on this assumption anymore. Do the OFX
specifications actually define a clear index key of the bank? (I have
never worked with the OFX specs; I only know the HBCI ones.) I find it
hard to believe the specs don't define something like this.
Sadly, both the OFX 1.0.2 spec and 2.1 draft say regarding the Signon
Request group regarding the <FI> block:
-----------------------
"Financial-Institution-identification aggregate
NOTE: The client will determine out-of-band whether a FI aggregate
should be used and if so, the appropriate values for it.
If the FI aggregate is to be used, then the client should send it
in every request, and the server should return it in every response."
------------------------
Out-of-band!? What were they thinking??? I guess this is what we get
for standards generated by Intuit and Microsoft.
Furthermore, within the <FI> block, only <ORG> is a required tag.
<FID> is optional, and only need be unique within <ORG>.
And in a change in the 2.x series the spec draft also says:
----------------------
"If a server requires the <FI> aggregate in <SONRQ> requests and it
contains
incorrect information there are several different specification
compliant
ways to respond. These are given in the order of preference:
◆Return a 2000 error with appropriate text message – since the FI
aggregate information is incorrect the user’s information
(<USERID> and <USERPASS>) cannot be verified. Returning a 15500
might cause clients to display messages to the user that the
attempt to communicate with the server failed. A client would
probably suggest that the user verify their <USERID> and <USERPASS>
values.
◆Return a 15500 error – since the FI aggregate information is
incorrect
or unknown the server cannot verify the <USERID>, <USERPASS>, etc.
◆Return an http 400 error – this is the least desirable option since
it will provide no useful feedback to the client communicating with
the server, however it is legal."
---------------------------
So Vanguard is doing precisely what the 2.x spec says when it feeds
me an http 400 error when I send an <FID> in the signon request group.
Bah.
For a while I thought about the possibility of generating an ID
for OFX
institutions that lacked them. But that gets ugly very fast: neither
aux1 nor aux1+aux2 is unique in the current data set. aux1+bankName
might be, but that's still ugly.
In any case we need some unique index key throughout the aqbanking
library, and because of the historical HBCI background, this
happens to
be the bankID (plus country code). If OFX requires something else as
identification, then we have two choices:
1. Change the unique index key of the banks in aqbanking, and make the
bankID field optional as seems to be appropriate for OFX (but not for
HBCI, as explained above)
2. Change the interpretation of the bankID field in the OFX
backend, but
still use it as the unique index key for aqbanking. In other words,
the
bankId should not be transmitted to the OFX server but still be used
inside aqbanking.
But you do need a valid bankId when it is the RTN for a checking or
savings account.
Just don't send it in the <SONRQ> block.
Clearly #2 is the much easier solution here... wait a sec: If you look
into src\plugins\backends\aqofxconnect\plugin\context.c and search
for
"BankCode", you will encounter this comment:
/* only copy bank id if it is a number (-> routing number)
* otherwise it serves only identification purposes for this backend
* and doesn't represent a routing number */
Can you try to enter a bankId whose first character is a letter
instead
of a digit? :-)
If what the FI's are doing is consistent with what I think I'm
reading in the spec, then maybe what we need is 'only copy <FID> if
it is numeric' option in the OFX <SONRX> block. That would still mean
(?) manual intervention in the case of Vanguard, maybe...
I'm fairly certain that if we're talking about (checking, savings,
money market, or line of credit), then we'll still need the valid
bankID, but still not in the signon phase.
And then there's the issue with how the aqbanking backend is parsing
the returned data for valid account information. (I could live
without Vanguard access, but right now, no transactions are making it
through gnucash-hbci.) Let me know if you think the returned ofx
headers from Citibank, Chase, Ameritrade, and Vanguard are of
interest (credit card and investment only, I think I'll have a
directconnect checking account by mid summer.)
Regards,
Christian
thanks for the help.
Dave
--
David Reiser
[EMAIL PROTECTED]
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Aqbanking-devel mailing list
Aqbanking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
