Category: api

A look at the Opensocial Virtual Currency API proposal

The Opensocial virtual currency API proposal is at revision #3. There has been growing interest in the money geek community as to what it might entail, so I thought I’d take a stab at it.

First of all, we are talking about virtual currency, that is governement-currency converted to a separate denomination to provide the following benefits:

  • Allow those without a bank account, particularly kids to be able to convert cash into virtual currency by way of gift cards.
  • Higher relative denominations (ex. $1USD = 10 virtual currency unit) for psychological impact: to increase the perceived value of virtual goods sold and of monetary gifts received.
  • Usually, non-convertibility or limited convertibility back into government-issued currency, which limits liquidity risk on the issuer side while allowing the issuer to use the currency as a way for users to earn by participating, checking-in, accomplishing tasks, volunteering personal information, etc.
  • Typically shouted transactions in the social graph as a way to seek mimetism of donations by social graph members or to increase social capital and seek indirect reciprocal benevolent behaviors.

Motivation

The first paragraph of the design explains the primary motivation for the API. The API provides essentially a way to workaround the fact that the application requesting the payment does not hold user’s credentials required to authorize the payment, so it has to communicate first with the container of the application, get the user’s authorization at that level, before the request can be passed to the authorization system.

A bias towards single currency per app

Looking at the details of the API, what is interesting is that there is no currency passed as part of the Payment object, only an amount and a reason. In fact, the currency is implicitly specified via the a opt_paymentHandlerUrl parameter (the URL of the payment handler) or via a pre-registered payment service URL.

In other words, it is designed primarily for applications who only deal with their own single currency, although it does not prevent an application to support multiple payment URLs. In all cases, each currency is tied to a currency service. It should also work very well for applications, which want to use a third-party currency and currency transaction service.

A bias towards purchases/rewards

Looking at the required versus parameters, the API seems really biased towards transactions between the application and the user such as virtual goods purchases.

The API supports both debiting the user’s account and crediting it, which means the API can be used to authorize both purchases and rewards for the user.

Extensibility

Despite the above mentioned biases, flexible “parameter” parameter can contain any application-specific data that the application may want to transmit. This opens the door to referencing invoice #, destination accounts, currencies, etc

Developers: register your API key and start your own credit union/bank

Imagine if a bank or CU was exposing their system via a GData-like API, and was outsourcing innovation to third-parties, possibly creating a dedicated VC fund or prize to finance startups building applications on their API, managing innovation as a good old option portfolio, possibly acquiring only the most successful and profitable of these innovators.

Well, that’s not really possible yet, but it seems the idea is in the air, at least the API part. Here are some excerpt from the comments section of OpenSourceCU report on BarCampBankDallas. Here is a summary:

In the current economic context, some credit unions may be pushed to innovate to survive, and one effective tool would be to expose their API. Tim McAlpine says:

As far as the API goes, traditional FIs are the opposite of open source. Being open requires a start-up mentality. Unfortunately today’s old dogs are more interested in keeping the vault full and closed. […]

This API opportunity lies with the credit unions. If an open CU was backed into a corner to survive, they may think differently if we could get them to understand the concept and potential power of an API. This type of CU may be ripe for innovation and may just turn that API over. If they did, I bet the geek world would love to slide in the door and innovate on their behalf!

In a subsequent comment, Robbie Wright took this vision to the next level: what if someone was providing a platform for anyone to start their own financial institution, leaving the difficult paperwork part to the platform provider:

I believe a large opportunity exists in helping people start new CU’s. It is so tough from a regulatory perspective and from a capital perspective, that it always seems starting a CU is impossible. That is what we need to change. Aside from the open source core processor idea that has been kicked around for a while now, there exists the possibility to create an entirely new industry of the outsourced FI.

Now, what would this API would look like?

BarCampBankDallas, Whuffie and open Banking Web APIs

I wasn’t able to attend BankCampBankDallas, but Charlie over at Open Source CU wrote a nice report highlighting some of the concepts that were discussed during the camp:

  • Incorporating online reputation into financial reputation: “why can’t [FIs] hook into LinkedIn and view a person’s Recommendations and process that into their credit score”
  • Opening a FI’s APIs to the creativity of their customers and 3rd party developers: “could there ever be a day where an existing financial institution could let people hook into it and meaningfully tailor the infrastructure and product to their own needs?”

I think exploring the links between online reputation and financial reputation is very interesting indeed. I think leveraging public social data is a great way for banks to reduce the risk of payment default on people with less than perfect credit. I’ve talked about this before, particularly in the context of peer-to-peer lending: in the problem with banking innovation…, I explained how a loan where some of the people lending money are family members offers a different and more attractive risk profile than someone’s lending money from people they don’t know (and don’t care) about (especially when you have a huge securitization food chain). I had never thought that such data could eventually actually be part of the FICO score, and that I think that will take A LOT of time. Here is my guess at how things will evolve: I think that Experian-like services computing someone’s overall reputation (see how to compute someone’s whuffie) will develop, and as they become established brands, may end up as an input to FICO scores. Anyway, I do think FIs are fundamentally social intermediaries and can’t afford to ignore the publicly available social data. I think there is a great opportunity, especially at credit intermediaries whose goal is the benefit of the community (credit unions), to re-socialize credit relationships.

Regarding the opening of Banking Web APIs, I think also that this is a great way for FIs to smartsource innovation while ensuring the highest level of security standards. In the problem with banking innovation…, I suggested at the very end that one way to smartsource innovation could be to “do what Apple or Facebook do: expose some of this information via easy-to-use APIs in a way that is more secure than their startup competitors. Then, allocate a VC fund to fund startups using this API (which is equivalent to buy an option to invest more/buy out the most promising ventures later).”

So, I’m glad to see that these highlighted concepts are inline with some of my own ideas and probably with many other people. I really hope I can make it to the next BarCampBank near San Francisco.