online balance info

John Klar jklar@projectplasma.com
Thu, 21 Jun 2001 23:29:06 -0400 (EDT)


On 21 Jun 2001, Derek Atkins wrote:
> Honestly, I don't know if I could tell the difference.  I don't have
> any of the Vanguard OFX handy to look it up for you, but I can grab
> some.

In the Header there should be an attribute VERSION:102 or something that's
close to the version your FI uses.

FWIW my Credit Union exports version 1.02, which is odd because the
consultants that my Credit Union uses for online account access, Digital
Insight, is/(was?) one of the core OFX members.

Nathan "A." Smith <nasa000@home.com> writes:
> Just for verificaiton - which ofx are we referring to?  There are two
> very different formats for this standard.  One based on XML (newest
> version) and one based on SGML(the one most banks seem to be supporting
> now).

No, not all that different.  Calling it XML is mostly Buzzword 
Compliance(sm).  That and they get to (well think they can) leverage
existing XML parsers which are much lighter (and less expensive) than
existing SGML parsers.  Oh and 2.0 formally adopted https as the
transport.  If left to the banks it would have likely have been EDI over
X.25 (ka-ching!) or .NET...


About half a year ago, due to a less than fond experience with my CU, I
went in search of a better FI, one that supported OFX and didn't want to
rape me in fees.  Sadly, those two requirements seem to be orthagonal to
each other.  Outside of the biggest banks (CitiBank, Fleer^Ht,
etc.) nobody seems interested in offering a real OFX interface.


Linas wrote: (2nd point)
> OFX also seems to loose inter-account transfer info, and has
> mal-formed, badly capitalized and cryptic info in 'payee' and
> 'memo' fields, at least based on samples I've looked at.

v1.02 doesn't seem to have a Payee :( and memo looks like whatever string
the payee emitted to your FI

> Its a bit cleaner than QIF to parse (e.g. it should indicate the
> currency of the transaction).  But its not a double-entry system;
> all you know is that money came, or went, but you are never clear
> on to whom, or how or why.

I'm not seeing this.  

 <FITID> should be "unique", but I'm detecting some rollover compared
         to a statement pulled from last year.
 <TRNTYPE> gives me "how" (CHECK,CREDIT,DEBIT,CASH,XFER)
	C&D are electronic
 <NAME> gives me "why" (SH DRAFT,DEPOSIT,PURCHASE,WITHDRAW,
			TRANSFER TO mumble)
 <CHECKNUM> correlates the check
 <MEMO> includes additional detail.  In the case of 102, this
        is where the PAYEE info is.

Note: I get about as much info as I get via my CU's web interface; if the
transaction was electronic, I get buried in detail otherwise, I need to
enter the payee info from the checkbooks (which I should have done already
and the OFX import should auto balance those, rather, a side-effect of
the import...).

> You have to guess based on the 
> badly-formatted, badly-capitalized, and possibbly blank 'payee' 
> and 'memo' fields.   To maintain consistency, the OFX importer 
> would have to remember how it guessed last time, and hope it can
> do the same again.   Sigh. And I thought OFX was the answer to 
> all problems.

Anything specific that you were hoping to find?  Vendor_ID? (who assigns
this particularly in a global economy?)  A fixed format (at least
more strict) Payee field?

Those would be nice, but as far as I can tell, substring filtering on a
combination of TRNTYPE, PAYEE, NAME, and MEMO would be as effective.  This
isn't much different than filtering email ;)  (Verizon?  ooh, that's spam)

John Klar