Financial Innovation

edit topic

4 flavors of the mighty dollar

Posted by Pelle December 8th, 2010 edit

Continuing on from yesterdays article On currencies, virtual or otherwise I thought I’d look at the US dollar. I’d argue that the US$ is not just one but more like thousands of different competing currencies

Is $100 in cash the same as $100 in my bank account or as part of my PayPal balance? Not really? They aren’t fungible between each other. $100 in cash can be converted to $100 in my bank account fairly easily, but it’s not the same thing.

$100 cash can buy me a case of wine in my local wine store, but it can’t buy me server hosting. So they aren’t directly fungible. There may also be a cost of swapping between $100 in cash and $100 in my bank account, such as ATM and other bank fees.

We can all agree that a $100 bank note is a real US$ issued by the federal reserve. But the $100 in your bank account, while denominated in US$ is actually a different beast all together.

Here is a small set of properties of 4 currencies that you could all label US$:

USD Bank Note USD Bank Account PayPal USD Starbucks Card
Promise Legal tender for all debts public and private On demand exchange for USD Bank Notes Easy deposit to my bank account Redeem for Coffee
Issuer Federal Reserve Bank EBay Starbucks
Backing (some small percentage) in foreign currency and gold reserves 0-10% USD Federal Reserve credits 100% in USD Bank Accounts Deferred revenue
Transferability anyone in same location to other account holders in same bank to most people in industrialized world Starbuck stores and physical transfer of cards
Transfer method Bearer Book entry Book entry Book Entry/Bearer
Yield none interest none none
Storage cost none for small amounts, safe for large amounts fees none none
Transfer cost none for small transactions, Brinks, security guards for large transactions fees fees none
Money supply M0 M1 M1? n/a

There are distinct advantages and applications for each of these 4 types of currencies. Each one may have more or less value to you or your business in a given moment. Banks, PayPal etc essentially make money of this difference in value through transaction costs and arbitrage.

I would even argue that every single bank issues multiple kinds of currency. The balance of a checking account at Ocean Bank in South Florida has different properties as one in CitiBank. For one it’s easier to deposit into a CitiBank account while being in the other part of the country than it is to do so with a local bank like Ocean Bank. A local bank like Ocean Bank might actually have other benefits such as access to local loan managers, that might be more important to you.

Back during the days of Free Banking banks and other businesses actually issued competing paper currencies. These were mostly freely traded at a 1 to 1 value, but if there was a rumor about problems at a bank the value could fluctuate between them. In the days before the FDIC there actually was a real trust difference between having your money in different banks. That is why old fashioned banks often had impressive architecture to show how trustworthy they were.

The traditional non cash payment as used today is generally a complex chain of value transfers between multiple competing currencies. PayPal transparently does this in the background for payments over your PayPal balance. These payments make these competing currencies all seem like one.

In tomorrows post I’ll focus on some of the above currency properties and how they also apply to virtual currencies.

On currencies, virtual or otherwise

Posted by Pelle December 7th, 2010 3 comments edit

Currency is one of the most popular buzzwords right now and there are lots of different definitions. I’ll try to unify them in some way and talk about some of the issues involved. Over the next couple of posts I’ll try to analyze what currency is.

Maceration of Money

If you ask most people on the street, currency is what they have in their bank account and in their wallet.

Gamers will tell you that currency can also mean numbers on a screen earned and spent within a game.

Silicon valley hipsters will also try to say that Virtual Currency is the latest monetization strategy out there, often without realizing what it really means.

Community activists also like to remind us of all the successful community currencies that have sprouted up in the past few years.

So my first attempt at a definition is:

A currency is a fungible asset that can be transferred from one person to the other.

Now under that definition we may also need to include stocks, options other securities. As they are generally transferrable and fungible. Most people wouldn’t consider them currency, but they fit the definition perfectly. I’m personally quite happy to consider them currencies.

Virtual Currencies?

What makes a currency virtual or not? It’s not wether it has any real value as World of Warcraft Gold clearly has value. I’d say it depends on the backing of it. So an attempt at a definition:

A virtual currency is a currency backed by the promise of it’s issuer.

Closed loop currencies

A closed loop currency is a currency only meant to be spent with the issuer. Good examples are Starbucks Cards, but most game currencies are also closed loop currencies as you can only use them within the games.

What about Whuffie, Page Rank and other reputation currencies?

That is a good question. These are currencies that are objectively awarded and taken away based on your standing/actions in a community. Pagerank is often also described as a currency. Most of these break my definition above as they aren’t generally speaking transferable.

Whether they are really fungible is also a good question. A Google PageRank of 8 would have to be worth 8 times a PageRank of 1. But clearly that is not the case.

In my next post I explore a few different flavors of what many of us think is just one currency, the all mighty US Dollar.

Open Web Payments - an alternative to OpenTransact

Posted by Pelle July 22nd, 2010 edit

Correction: I had misunderstood this to be an official PayPal proposal. It is actually Praveen and Ray Tanaka private provosal, that they are trying to push with amongst other providers PayPal.

Praveen and Ray Tanaka’s both from PayPal gave a talk at OsCon presenting their new Open Web Payments proposal:

PayPal of course have one of the oldest http based payment APIS out there already, but as PayPal’ers like Praveen have admitted it is pretty old school in its approach and very bloated by now. I’ve been talking quite a lot with Praveen the last half year about OpenTransact , which seems to have had a fair amount of influence on this.

Like OpenTransact Open Web Payments utilizes OAuth as well as WebFinger. Where it differs is it’s use of Atom and AtomPub and more fundamentally that it ignores URI’s as a fundamental part of the protocol.

Atom transactions

I think Atom in itself could be a good way of publishing transaction data, but it shouldn’t be the only way. There also needs to be json and microformats. XML and in particular heavily namespaced XML is not very popular today with developers outside the enterprise. The datamodel isn’t too bad but I think it is too complex. There are too many data elements:

AtomPub for payments

To create a payment you POST a chunk of atom xml to a URL creating an entry. I’m glad it follows HTTP conventions. I’m not in love with allowing GETS for modifying transactions. And a refund might be better modeled with a DELETE

This is an example of a transaction:

Contrast this with OpenTransacts equivalent:

POST /transactions/usd HTTP/1.1
Authorization: OAuth ... oauth_token="ad180jjd733klru7", ...
Content-length: 239

amount=25.00&to=[email protected]&memo=Milk

Again too much information. We already know the sender through the OAuth token, no need to repeat it. Why do we need enter this much information about about the recipients. A single URI, email address or other identifier should be sufficient, particular as we are using webfinger.

What this does have that OpenTransact doesn’t support at the moment is multiple recipients. We could add that using the following convention:

POST /transactions/usd HTTP/1.1
Authorization: OAuth ... oauth_token="ad180jjd733klru7", ...
Content-length: 239

amount=25.00&to=[email protected]&memo=Milk&amount.2=2.00&to.2=[email protected]

Where art thou URI

Each transaction does have a URI which is excellent. Posting to an atom resource should create a URI. The rest of the API misses an opportunity to look at the fundamental concept of value as a resource.

For historical reasons payment apis have traditionally followed the messaging model. This goes back to the days before financial institutions were online (see my previous article on the sorry state of payment standards). PayPal, VISA, M/C, SWIFT are financial intermediaries sending messages with instructions back and forth. This message oriented way of thinking about payments is what causes much of the complexity as you need to include lots of redundant information in the payment message.

The web on the other hand works using the concept of resources and actions. It is pretty object oriented in this way. Messaging applications can be created on top of the web, but the complexities are hidden behind this object oriented world. This is how atom, twitter, facebook etc all work.

The best example of a field all payment messaging standards require is the currency field. On the web we don’t need this as we have URI’s.

A payment is the transfer of one resource to another. So lets model that in the restful object oriented way. Each currency has a separate URI:


HTTP POST to this URI to transfer funds. HTTP GET to get transactions in that currency.

In addition in the above grocery transaction the funding types elements. Neither the merchant nor the consumer cares about these. They are also extremely specific to PayPal and are likely not of any interest to most other people wanting to implement this, such as banks. They could be modeled into the URIS as well:

  • – do whatever default behavior is

These options could be presented to merchant using WebFinger.

This concept of using URI’s to represent value is key to OpenTransact’s simplicity.


I am glad that Praveen is at PayPal trying to open up their payment world. We can’t discount the importance of an evangelist within PayPal pushing for open standards. I just don’t think it is radical enough. I also think it is too complex both for consuming developers and for developers creating new financial services supporting it.

Any good developer could definitely work with it, but for the majority of developers creating simple PHP/ASP type sites it would present some major hurdles the same way OAuth 1 has. OAuth 2 learnt from this and PayPal’s proprietary API’s have always been targeted at these kinds of developers. While conceptually it is simpler than the old API’s, I think many developers would find it easier to deal with the old API in practice due to the complexities of XML.

Another important question is if PayPal are actually committing to this. I believe PayPal has good intentions with this, but other large corporations were notorious for bringing down competitors with nothing but press releases announcing new products.

It is more of a full stack though than OpenTransact. Hopefully we can work together on the lists to create a common full stack. I see this as Ray and Praveen’s reply to OpenTransact and as the start of a conversation. Similar to OAuth Wrap being the response to the complexity of OAuth1 which lead to the great new OAuth2 standard.

How OAuth beat Chip and Pin

Posted by Pelle February 12th, 2010 1 comments edit

2 news stories on the same day are quite interesting in their contrast.

Pin and Chip is broken

The first one has the collective might and minds of the European banking system and their suppliers who overlooked a slight issue in their authentication protocol for authenticating Chip cards with a pin number. In Europe most Visa/MC cards are smart cards and have to be authenticated with a pin. This in theory allows for an authenticated payment message.

Only problem was that, well one very important bit of the message was not authenticated leaving a gaping hole. I won’t go into the details as well as Ross Anderson does. He is one of the security researchers who discovered the flaw. Unfortunately it sounds like carders discovered it before them.

Now what to do with these supposedly safe authenticated transactions? There is no way of knowing which ones were fake. You can’t mass revoke all european cards. Some one is in a bit of a bind right now.

Grader’s security screw up

The second story was about HubSpot a Cambridge, Mass. based startup who self admittedly screwed up and let a malicious user comprise the security of their Grader service a rating service for twitter users.

Granted we are not talking about a system that handles the majority of Europe’s electronic point of sales transactions here. But they know they screwed up. However due to the fact that Grader used OAuth they were able to mitigate any damage pretty quickly by asking Twitter to revoke their Consumer credentials and any tokens they had issued to it.


The difference is that while both Chip and Pin and OAuth are ways of doing delegated authentication, the only token to revoke in the Chip and Pin scheme is in the card itself. The standards behind Chip and Pin assumes that it’s technology is perfect and through their rule books that all parties involved along the long chain from the card to the issuing bank can automatically be trusted.

This is basically the exact issue I described in The sorry state of Payment Standards.

OAuth does not define how a user authenticates himself to either of the services involved, rather it is focused on the delegation.

The delegation is done in the form of an authorized token that can be equipped with limits and can at any time be revoked. It is under the control of the user. In this case Grader themselves request the revocation as they knew that all of their credentials were compromised. Where do the European bankers even start to clean up this mess?

I think OAuth a simple (as authentication standards go) standard developed on a mailing list by a small group of developers has incredible potential in payments applications. This is of course why we picked it as one of the fundamental building blocks for OpenTransact.

Is OAuth perfect? Probably not. Nothing is 100% secure. It has had one serious security flaw which was fixed. But by design it is revokable. You can do something about it if something goes wrong. There is now an IETF OAuth Working Group working on making it an official internet standard.

OpenTransact a tiny payment standard

Posted by Pelle February 11th, 2010 1 comments edit

As I mentioned in my last post The Sorry state of Payment Standards I wanted to blog about OpenTransact which so far is probably one of the most important outcomes of the Agile Banking mailing list set up after my talk last year on Agile Banking.

OpenTransact was designed to be very simple and is based on REST the best practice for current web API design. It should be so easy to implement for developers that there really shouldn’t be an excuse not to implement it.

An OAuth authenticated HTTP POST request to assets URL containing the parameters amount, to and optional memo field. Payer is deduced from the OAuth token.


POST /transactions/usd HTTP/1.1
Authorization: OAuth ... oauth_token="ad180jjd733klru7", ...
Content-length: 239

amount=10.00&to=[email protected]&memo=Milk

The above example shows a payment of $10 to [email protected] from the user who authorized the “ad180jjd733klru7” OAuth token.

Using the Ruby OAuth gem you would write the above as: "/transactions/usd", :amount=>10, :to=>"[email protected], :memo=>"Milk"

That is pretty much it. But please do read on for more about motivations, issues and applications.

Join my Blockchain newsletter

Receive all my latest articles on Bitcoin, Ethereum and building businesses using Blockchain technologies.

I will never send you spam. Unsubscribe at any time.