Posted 30 April, 2011 in:

Source-agnostic Funding

As technology has become so common, we've seen only modest integration by the money transfer industry. There's not been enough movement toward better banking options and money transfer abilities. The result of this is that, as with the problems caused by poor service authentication, we are held back both economically and culturally.

You’ve probably heard of PayPal. You might have heard of Flattr and Bitcoin. Surely you’re aware of credit cards and checks. As technology has become so common, we’ve seen only modest integration by the money transfer industry. There’s not been enough movement toward better banking options and money transfer abilities. The result of this is that, as with the problems caused by poor service authentication, we are held back both economically and culturally. The idea I’m examining today is source-agnostic funding. Let’s say you’ve signed up for a subscription, and that signup represents a recurring bill. Every month you pay a fee, and the service continues. For convenience, you attach a credit card to that service. It’s automatically billed, until the card expires and a new one is issued. Suddenly you have to go through a number of services to update your card details and continue automatic billing. Instead of this system, what should happen is that you provide a service provider with a source-agnostic funding credential. It’s like providing a credit card number, but you control what’s attached to it. The service providers still bill it mostly like a credit card, and it still offers as much of a guarantee of payment as a credit card. On the backend, you can change the source at any time and save yourself the trouble of having to update a bunch of payment details at a bunch of different services. The interesting part about this idea is that it’s not new by any means. Credit cards are the same idea, as is PayPal and Flattr. But where the current solutions fail is that they just shift the problem a single step. If you use credit cards instead of checks, then you can pay the credit card with a different source, but services that are relying on that card’s details will need to manually receive new data to process a different source. If you use PayPal, you can change the source to pay a particular bill, but if a service doesn’t accept PayPal, then you have to switch to another similar service like Google Checkout. What’s needed is not to perpetuate that problem: if you simply set up some new container and attach existing sources to it, it will only shift the problem again. My guess is that the solution will turn on two things:

An URN-like identifier for sources of funds.
A tree-like structural requirement for URN-providing sources.

The URN-style identifier will allow for easy, unique reference to a source, and the tree structure will require and allow that any source could be attached to another, to build a tree of sources. The tree requirement is essential, as cyclical source graphs would be problematic.

Please Deposit Two Cents: Cancel reply