Give me an “A”, give me a “P”, give me an “I”. Put it together and what have you got? Disruption

[Dave Birch] APIs are all the rage. You know what I mean: Application Programming Interfaces. Every strategic planner in a bank should be thinking about them.

APIs serve as contact mechanisms – virtual handshakes, if you will – that allow various software to interact. The first API was released by eBay in 2005. Google was another early leader in opening its APIs to allow the creation of “mashup” applications. The location data in Google Maps is a good example of an application that has been used to create mashups.

[From Capital One, Lemon, and LevelUp Beef Up Their Tech Offerings | Bank Innovation]

We are already used to Facebook, Google, Twitter and so on being completely integrated into everything we do through their APIs. We don’t even think about it when we take a picture in iPhoto and click a button to upload it to Facebook. We just take it for granted that stuff should work with other stuff. Now we are beginning to see the start of that API explosion in financial services. This might begin with making and taking payments, and a bunch of non-transactional stuff, but will pretty soon extend across the sector. I genuinely do think that there are new opportunities for competition and disruption here. As I said a while back,

[European merchants] like the SCT (no chargebacks) so a pan-European PingIt would go down a treat. They don’t like SDD (eight week cancellation period). They like wallets, prepaid, “overlay services” (i.e., merchant applications sitting on bank API) and they remarked on the potential reuse of ID/authentication as well. I’m rather sympathetic to these positions… I also think that wallets built from bank APIs — about which I will blog more soon — look good.

[From You can’t touch me I’m part of the Union]

There are some businesses that our clients are involved in that are on an inevitable trajectory toward API-based services and no-one really knows how competition between API-based services will be managed or where it will take us. That’s why it’s fun. A good current example is the world of mobile wallet, where I said more recently that

it makes sense for banks to focus on API-based strategies to make their services available to other wallets

[From Wallets, mobile wallets and hyper wallets]

OK, so if you drink that Kool Aid, as our transatlantic cousins might say, where can you look around to find some examples and inspiration? Here are a few examples that we have explored with our clients recently:

PayPal were, I guess, the trailblazers here. Look at some of the recent announcements of products and services built on top of the PayPal API. Not only do these make for great services for end-consumers, but they help PayPal toward its goal of becoming the “commerce identity” for customers.

Intuit, who provide both consumer financial products and core banking software, has announced that it will open the APIs to its financial data service and allow third-party developers to use its capabilities to build innovative new software, the company announced today.

Stripe and Braintree have made a terrific plays in the card space by offering a very developer-friendly API for accepting payments along with very merchant-friendly entry strategies.

Lemon. They have a digital wallet (for storing receipts, loyalty cards etc) and have now opened the API so (as with Apple’s Passbook) third-parties can put their services inside the Lemon framework (known as, unsurprisingly, Lemonade).

CapitalOne. Their newly-announced API will make Cap One’s deals, rewards, and (rather interestingly, in my opinion) user identities available for developers to offer personalised coupons and offers for their customers

AXA Banque. This French bank’s API allows developers to access and integrate customer information data from AXA Banque with other applications.

LevelUp. There are over 4,000 merchants using LevelUp in the U.S., which range in size from small mom-and-pop shops to large chain retailers and they claim more than 300,000 users already.

This list goes on. I would have thought that a strategy for API-based competition is a) an imperative for financial services providers, b) exciting and c) frightening. It’s frightening because if you have spent the last generation on brand and product-based competition, shifting into competition on the basis of services delivered through APIs is scary. Who knows how it will work? Can we look around and find examples of companies who are already by competing by providing a financial services API (screen scraping doesn’t count!) that allows third-party applications execute financial transactions? Well, what about The Currency Cloud?

Provide a cross-border payments and forex solution via an API.  The API can be used by firms looking to provide cross border payments services. Innotribe Startup finalist TransferWise is an example of a firm that is utilizing this API.

[From Celent Banking Blog » Finovate Fall 2012 Recap]

I interviewed Mike Laven, CEO of The Currency Cloud for a Tomorrow’s Transactions podcast that was posted a few weeks ago, weeks so you can listen to Mike for yourself. This isn’t simply about financial services trend, though. I rather echo Dean Bubley’s “smart pipes not dumb services” strategic advice to telcos so I find it unsurprising that mobile operators are beginning to explore APIs that could be integral to, for example, mobile wallet services. 

In France, the big three national operators Orange, Bouygues Telecom and SFR have formed a consortium called YouConnect that exposes an API that allows m-commerce apps to auto-fill in purchase information (name, address, credit card, etc.) from carrier subscriber databases.

[From Meet YouConnect: Maybe carriers and developers can get along — Mobile Technology News]

I have a vague memory that the GSMA had something called OneAPI floating around earlier this year, so I don’t really understand why the French operators can’t use that, but whatever. Another category of organisation that is keen to develop API-based strategies is retailers.

Our goal is to essentially put an API around our stores. We want to think of all the key functions that customers need and have those exist in an API, with Web services for third parties to work with. We started with the photo print feature, but our goal is to expand to all areas of the business, from pharmacy to the health and daily living shopping experience.

[From Innovator Spotlight: Walgreens – Putting an API Around Their Stores]

You can see a vision beginning to emerge here: a retailer wallet that pulls together the retailer API, the operator API and the bank API to deliver a great, great service to consumers, totally integrated with the POS. One more point on this: There must be, of course, some substance behind the API. API to a service that goes down all the time, chokes on volume and delivers incorrect results is hardly progress. So the back end has to work.

Ultimately with many apps, it is actually the backend service (in Sparrow’s case, email), which is where the sustained value for the user lies. This puts companies that roll out backend platforms, which can keep users coming back over time and potentially access via many different devices, in a much stronger position to capture value in the long term.

[From Why the App Economy Isn’t the App Economy, But the API Economy | PandoDaily]

This ought to be good for scale providers who already have a robust infrastructure. Ideally, banks ought to fall in this category. With the obvious proviso that an appropriate cross-industry security platform needs to come into place, why shouldn’t banks be successful at providing API services?

These are personal opinions and should not be misunderstood as representing the opinions of 
Consult Hyperion or any of its clients or suppliers