[RFC] Finance::Accounts -- an abstraction above account-specific modules

If you don't want to read a few paragraphs of my rambling, here's a
summary of my idea. DBI for financial accounts: provide a
well-documented external API with backends implemented separately.

Right now, there are a multitude of modules on the CPAN to manage and
manipulate a user's accounts of various types with a number of different
financial institutions. They all use a variety of methods to obtain the
relevant account information, such as screen scraping. Some might even
churn through the downloads available for the various popular graphical
accounting packages on the market today (Quicken, Money, etc., ad
infinitum, ad nauseam magnam).

Enter the Real Person (tm). The Real Person has a number of different
kinds of accounts with a number of different institutions. I myself have
a savings account, a checking account, a few credit cards, debit cards
associated with the savings and checking accounts, and an IRA. And I'm
just 22. If I wanted to write a comprehensive program in Perl to manage
my assets (assuming modules existed to access them and that they worked
that day), I'd have quite a task in front of me. Not only would I have
to go through the motions of installing modules to access each account
manually via whatever mechanism is available to me, but I'd also have to
learn and access a different API for each kind of account with each
institution.

IMO, that's the wrong way to do things, and it's seriously hindering
Perl's usage for financial applications. If I'm going to write a
comprehensive finance management application, I want to learn *one* API
to access the user's financial accounts, regardless of what kind they
are or who the institution is. What I have in mind is a plugin-based
architecture that adheres to a strict, well-documented external API that
provides capability-based access to different kinds of assets. I'm not
asking everyone to adhere to some authoritarian API with no degree of
flexibility, but I do want some kind of basic civility when writing
software to manage my assets. This is, I think, part of why DBI is so
wildly popular. It allows the programmer to focus on the important
thing, which is the data in DBI's case and the assets in this case.

How those plugins are implemented is the decision of the plugin
developer. Screen scraping does seem to be the most popular, because it
seems that financial institutions haven't learned of the wonders that
are XML and SOAP and the rest of modern networking technology. But if
Bank XYZ publishes a SOAP API, I want the developer to be able to
publish a shiny plugin that uses that API. I want the plugin developer
to be free to access the underlying asset data however they want, so
long as they present said data to the public API in the way it expects
it.

Comments, anyone? Does something like this exist already that has
cleverly eluded my searching? Has such a project been started but
quietly gone south like so many projects of this kind? Should my ideas
and I be locked away with other similar lunatics? Or perhaps is it just
crazy enough to work?

Best Regards,
Christopher Nehren