<<< The Lead Bullet - Writing Specs

Home

Thursday, July 24, 2003 10:31 PM >>>


Financial transactions, RSS and OFX

Thursday,  07/24/03  06:28 PM

RSS for financial transactions?

Today Dave Winer linked Deane Barker, who asked about a realtime RSS feed for credit card purchases.  Actually Tim Bray made similar mention a few weeks ago, asking for an RSS feed of his stock portfolio.  Jon Udell indicated [in email] that he'd like to receive higher-order messages from his bank in RSS - for example, periodic email alerts about an account being low, or about newly presented bills.

Introducing OFX

It turns out most large financial institutions support an XML-based standard called OFX.  (Open Financial Exchange.)  This standard was created in 1997 by Intuit, Microsoft, and CheckFree, as a way to interface personal financial managers like Quicken and Money to financial institutions like banks and bill payment services like CheckFree.  Most home banking vendors like Digital Insight support OFX as well, both as clients (they use OFX to get account information from banks) and as servers (they export account information to end-users as OFX).

In addition to account and transaction history, OFX also includes messages for bill payments and bill presentment.  Bill presentment has turned out to be a fizzle so far - there are too few billers which support it, and for consumers it is really only useful if the majority of their bills are presented electronically, so that they can get all their bills in one place.

I was with Intuit's Web Finance group for a couple of years, which included Online Bill Payment.  We worked hard to get billers to signup for bill presentment, which at that time we thought would be the Next Big Thing. We had a deal with AOL, a deal with Excite, etc. (This was 1999.) Quicken and Money have the ability to present bills right in-band, and OFX has the messages.  The big problem was getting billers to agree to present bills electronically.  You'd think billers would be anxious to save printing and mailing costs, but the big billers all value their relationship with their customers, which is currently mostly conducted through their statement.  (These are phone companies, utilities, cable companies, etc.)  Billers just didn't want to turn over that relationship to an online transaction system, even after we put a ton of branding in for them (including HTML links to their websites).  Today there are a number of bills you can get through "online bill presentment", but mostly when you want to pay a bill online, you have to do it through the biller's website, because of the customer relationship issue.

An interesting solution to the "all your bills in one place" was an idea several companies had at once; scan paper bills.  A company called Paytrust still offers a service which does this; overall it was a great idea but proved too expensive for most consumers.  The idea is that you tell all your billers to send your bills to an address as the scanning company, which opens your mail, scans all the paper, and then makes it available online through a website.  This makes it truly possible to get all your bills online, whether paper or electronic.

There are two main things offered by OFX which are slight complications over RSS.  First, there is security; OFX is always exchanged over SSL connections, with validation of server certificates by clients.  Also a client must establish identity through a logon sequence (typically userid/password, validated by server).  Second OFX servers support client-side state.  An OFX client provides the high-water mark of previously seen transactions (all transactions are sequence-numbered by the server), and the server then provides ONLY transactions newer than the high-water mark.  This enables small updates to be easily downloaded from large datasets (e.g. all the history on your credit card would make for a large message).

OFX vs. RSS

Both of these OFX features – security and client-side state – would be useful additions to RSS.  If added, they would bring RSS up to the level of OFX, but would not necessarily add anything to the OFX standard already in place.  There are already a bunch of defined XML tags for modeling financial transactions (these could be incorporated into RSS as a large “financial” namespace).  Additionally there is already software - like Quicken and Money - which “understands” OFX feeds, and incorporates the data seamlessly.  Such software wouldn't necessarily know what to do with RSS versions of the same data.

The idea of client-side state in OFX was really just born of expediency; the OFX designers realized financial institutions would be sending a ton of redundant information if all account history were sent every time. (And the target client base was mostly dial-up.)  There had to be a unique identifier for each transaction anyway (today we would call it a GUID :) and it was simple to have the server sequence-number each item.  Then a client would just keep their high-water mark, and send it on the inquiry request.  The server then could provide only items "newer" than then high-water mark.  If the client was confused or got reloaded or something, they'd just send zero and get everything again, but only the first time.

I actually think this form of client-side state would have value.  Using aggregators like Radio or SharpReader which poll every hour, typically when a blog has an update it is only one or two items.  But currently the aggregator pulls down the whole RSS feed, which could have a month's worth of items in it, and then filters the duplicates.  If the aggregator kept a high-water mark (GUID of last-seen item) for each feed, it could send this on the request (as an optional parameter on a GET) and servers which wanted could use this to optimize their bandwidth by sending only items newer than the high-water mark.  It wouldn't save me much on my blog, but really active blogs like Scripting News would probably save quite a bit of bandwidth over time.  This would be a strictly optional feature for both the client and server - if either doesn't support the feature there is no harm done - but given most RSS feeds are served by a few products (Blogger, Radio, Movable Type) and most RSS feeds are retrieved by a few products (Radio, SharpReader, NewsGator, etc.) the possibility of implementation seems pretty real.

What's next?

OFX is pretty entrenched now, with Intuit, Microsoft, CheckFree, and most large financial institutions already on board.  It isn't going anywhere.  Meanwhile RSS is also pretty entrenched now but not as a protocol for obtaining financial information.

Jon's point about getting alerts as RSS seems really well taken.  Many online services currently present such alerts by sending emails, but putting them in RSS seems very doable.  Of course you might have to add client identification but that isn't too hard - you could simply pass credentials in the HTTP Authorization: header.

I predict more and more business-to-consumer applications will use RSS as a communication mechanism, particularly if security and client-side state are added.  This could be done fairly easily with a namespace extension...