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

[Donald Allen]

FYI, I operate the same way Beth does -- pay for as much as possible
with credit cards, pay the credit card bills in full every month, and
manually reconcile my bank statement, which isn't a big deal (the vast
majority of the transactions on my account will have been entered when
they occurred, usually a result of paying a bill via their web-based
bill-payment service). The security aspects of what you propose would
preclude my using it to solve what, for me, is a very small problem.

/Don

On Dec 13, 2007 3:20 AM, David Barrett <dbarrett at quinthar.com> wrote:
> 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
>
>
>
> _______________________________________________
> 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.
>