Any interest in a "import from bank website" command?

David Barrett dbarrett at quinthar.com
Thu Dec 13 03:20:16 EST 2007


Thanks for the response, Beth, comments inline:

> -----Original Message-----
> From: Beth Leonard [mailto:beth at oasis.slimy.com]
> Subject: Re: RE: Any interest in a "import from bank website" command?
> 
> I for one wouldn't use such a feature, but I don't want to speak for
> others.  I think very very few people would be interested in giving
> you their login information, especially if they know you're going to
> use their account to verify if a particular bank works or does not
> work.  

To be clear, the only reason you'd give me your login credentials is in the
context of you actually using the expensify.com service; if you're not using
the service then I agree it doesn’t make much sense to share your
credentials with me.

Furthermore, the only reason I'd hold onto your credentials is in order to
go and build an import engine for you (if I don't already support your
bank), or to figure out why the engine didn't work for you when you tried.

Again, the point is to use your information sparingly and only as required
to offer you the service you requested.


> If you do have a security
> breach, will you keep the snail-mail addresses and send mail to
> those in the state of California informing them of the breach as
> required by law?

If you're referring to California Civil Code §1798.82, I don't believe your
summary is accurate.  However, yes, I certainly intend to comply with
relevant state laws.

Furthermore, as general background, the goal is to make the entire service
"stateless" such that no information is recorded after the request is
complete.  As it stands, I don't keep record of the transactions themselves,
and the login credentials are only recorded for debugging purposes.
Furthermore, they're public-key encrypted on the server into a secure log
that can only be decrypted with a private key stored securely elsewhere. 

I genuinely don't your information; I just want to build and maintain a
service that helps you go get it as needed. 

In general, I'm a huge fan of the client-side architecture -- my recent
background is all in P2P software, for example.  Unfortunately I don't think
it's a feasible choice for this particular problem domain (though I realize
reasonable minds can disagree on this point).


> If this is a project that interests you, I recommend opening several
> bank accounts at different banks yourself (many credit unions have
> no-minimum-balance no-monthly-fee accounts) and get something working
> that works for you.  Don't start your exploration by asking people
> for their bank login data, finish there.  When you have something
> working for your own accounts, have a trusted friend give it a try
> locally on their machine for their bank.

Actually, I've already finished this phase.  There's only so many bank
accounts that one person can open, especially given the literally thousands
of different banks out there.



> Personally my bank transactions are not so numerous.  I just
> manually reconcile with my paper statement and pay for nearly
> everything with a credit card.  I download the credit card
> statements and import using the OFX import features to track
> my expenses.  (And yes I pay off the credit card bill every month.)

Ah, to be clear, this works with credit card transactions too -- I was
lumping them into the same "banking transaction" category, though perhaps
that's confusing.  I agree -- like you, I don't have very many checking
account transactions, but I have a lot of credit card purchases.  This is
certainly targeting the latter, especially in the context of when you're
using credit cards for business expenses.


So given all this, I see you're comfortable manually downloading an
importing the OFX credit card statements -- that's great.  The feature I'd
build would simply streamline that.  If I understand correctly, you're
comfortable with the manual OFX import process provided by your bank and
don't view the security risks of an automated import engine as worth the
convenience of a "one click synchronize" sort of feature.  That's perfectly
reasonable.

How about everyone else?  Are you satisfied with the "manual download,
manual import" process, or would you like a built-in, streamlined feature
for downloading and synchronizing transaction data straight from GnuCash --
such as available in MS Money out of the box? 

Thanks for all the great feedback and discussion on this; I really welcome
your views and I'll try to address your concerns as best I am able.

-david




More information about the gnucash-user mailing list