What would Bank 2.0 look like? Lessons for Telco 2.0
Sometimes for inspiration in business model innovation you need to look outside your own industry. We've previously examined supermarkets and airlines. Once more we'll turn to banks. Sometimes it's easier to get the principles of a new business model when shorn of all the familiar ARPUs, churn rates and equipment subsidies.
Banks are very much in the news these days, although not always for good reasons. Return of capital has become as much an issue to depositors as returns to capital. Indeed, Willie Sutton's famous quip would these days have to become "Why do Banks rob taxpayers? Because that's where the money is". Thankfully the telecoms industry lacks the solvency, honesty and transparency issues that banks face (although some might disagree strongly).
However, there are considerable structural similarities. Both are regulated capital-intensive networked industries, with mounds of under-exploited customer data. (If you want some inspiration on how banks are doing a better job of exploiting this, check out the Visa Extras program.) They are also wedded to vertically integrated models, where the end user experience is controlled and tied to the back office. "Banking mashups" don't yet feature heavily in everyday vocabulary. They should.
What is a bank for?
My business bank (whom I sadly can't commend to anyone) is fairly typical. I may only have ten or twenty transactions in a month. Many are fully automated, such as a direct debit for my mobile phone usage. A few are conducted via the web site.
My bank thinks of itself in terms of transactions, in the same way that a telco tends to think in terms of calls and messages. But that isn't what I as a customer care about, per se. I want to manage my cashflow, ensure my bills are paid, and generally not have to think about my finances. So when one of my invoices is paid, I would ideally like to flag some of that cash as being reserved for the evil VAT man, some to pay the iniquitous corporation tax, some for the pernicious bills from my accountant, and the rest of lucre going to a worthy cause -- i.e. me. My "account balance" doesn't begin to tell me how much money I've really got.
"Get an accounting package!" you scream in response. Well, that just adds another layer of complexity and cost. The ones I tried out are all designed for accountants, with the comprehensibility of Linear B. I can import transactions into my accounts package, but I can't transact from within it. Two inflexible silos, instead of one.
So a bank is a transaction platform tied into a particularly unattractive user interface. What if we could de-couple the two?
What's the alternative?
What I'd much prefer is to allow an organisation such as the Professional Contractors Group to offer me a service targeted at my niche. Each bank would offer a basic API set, deal with authentication, but would let someone else deal with the user interface. It could be as simple as being able to annotate my statements to give them to my accountant. In my case, I'd like to be able to run a tally of VAT owed, and how much I need to set aside to pay my corporation tax. Overkill for an accounting package, but impossible to do by extending my banking application.
Where's the value?
As Tim O'Reilly reminds us in the context of Web 2.0 darling Twitter, hard-to-replicate data (such as authentication credentials for a bank account) is the new 'Intel Inside' of 2.0 business models:
What's different, of course, is that Twitter isn't just a protocol. It's also a database. And that's the old secret of Web 2.0, Data is the Intel Inside. That means that they can let go of controlling the interface. The more other people build on Twitter, the better their position becomes.
Amazingly, each bank I deal with seems to only let me search a short window of transactions going back 6 months. When it comes to doing my annual accounts, I may be looking back 18 months, so I have to rely on paper statements. There's a total mismatch between the bank's view of a successful service, and mine.
What's the revenue model?
How to banks make money (apart from bailouts)? They borrow short (creditor deposits) to lend long (loans and other debt). This may be a good or bad thing, and isn't our concern as telcoheads. Also, as cash is shuffled around, a slice is creamed off each time. So for APIs to make an impact on profits you need:
- More customers. If you don't support third party user interfaces, and someone else does, I'll move.
- More deposits. I'd rather put my money somewhere that it is easily manageable.
- More transactions. The third party user interfaces are effectively an extension of your retail distribution network.
- More products. As with Amazon, you can use affiliate programs to reward sales of additional products like insurance.
This accellerates the existing business model. You don't need to charge for APIs for them to be profit drivers.
We asked attendees at the third Telco 2.0 Executive Brainstorm last year to rate five different revenue models for APIs, picking their favourite. The results are below.
The clear favourite was to charge for APIs. It could be that banking and telecoms are completely different. Or it could be that the urge for more billable events is driving irrational behaviour in telcos.
What does this mean for me?
Every time you hear about 'open' business models, I substitute the word 'clopen'. You need something that is closed and defensible, as well as allowing new value to be created on top via open interfaces. Banks, like telcos, have become over-reliant on an entirely closed product set. This encourages 'over the top' applications like Mint to scrape all that data up, without the bank getting involved, evolving its own business model, or gathering new and precious data on user behavior and needs.
Telcos likewise need to work out what is their true value -- the 'closed' parts of the business model -- and relinquish control over the rest. The core is likely to be directory data, linking identities of users, devices, services and locations.
Strangely, many telco API offerings let you place calls and send messages, but expect the rest of the customer experience to work in the way it always has. Does everyone need exactly the same call routing and voicemail experience? We thought not. Just that the absence of real choice has led us to believe that what the users are being given is what they actually want.
So in summary, get ready to let go of the end user experience, and allow third parties to fill in all the niche user needs. But keep a tight hold of the underlying data, since that is where the value lies.