Category Archives: Uncategorized

Google I/O payment announcements: is a revolution with no insurgency possible?

Google’s megafest was happening last week, with big announcement for Hangout, Google +, Android and Search / Maps. Among these were a couple of announcements related to Payments (but no major push from Google since Wallet 2.0 last year  and no Google Card):

– The headline-grabbing announcement – send money via email.

Wow, dollar button in Gmail, massively sexy and headline worthy …..

Pay_by_Gmail

… with the main issue that, in my view, P2P payments do not drive behaviour changes. Various startups, established players (Obopay, ClearXchange, Popmoney etc..) have tried and not succeeded. I am betting Barclays Pingit has not found major traction with this use case. The main reason is not implementation quality. It’s just that people don’t do that many P2P transactions relative to Commerce transactions and are much less attached to those. Frequency is a major driver in behaviour changes (as with contactless cards) people just forget they have it if they don’t use it enough. Also this is currently limited to the US only and while free with a linked bank account or prepaid Google card, it will cost you 2.9% (minimum 0.30$) from a debit or credit card (note: Google is not willing to take a loss on these non-commerce transactions …)

Also, while I am sure Google is focused on this, this could become a massive risk challenge with compromised Gmail accounts. Extending it beyond US only (it could be really powerful in remittance markets) will require much more work

My prediction: in this current form this will have limited traction and remain relatively small. 

The more interesting announcement was in my view Google Instant Buy:

Per Google, 97% of mobile shoppers abandon their cart. The solution is broadly known, with a central point for registering Id, address and payment means. Google’s solution appears quite complex:

– It works on the existing credit card rails. In more details, it interfaces a virtualised Mastercard debit card with the users payment means to connect with the merchant processor as a Card Not Present Transaction. As a consequence, Google is taking a loss on every transactions made through the system.

– It still requires merchant / app creators on boarding. While it runs before the payment processor, it still requires implementation on the merchant side (though Google claims this is an easy implementation).

There are several issue with this solution:

– It leverages Android to help on adoption but this may not be as much of a strength position as it looks. Every app with a strong enough sign in infrastructure could  provide the same simplicity or has done so. Amazon is the main example. Airbnb, while part of the Google Wallet launch, uses Venmo Touch (from their payment provider Braintree) on the iPhone. iOS is just the start if we are to believe this: https://www.braintreepayments.com/company/careers/new-york-city/android-engineer-venmo-touch-venmo-p2p. Paypal can do this as well.

– Instant Buy may become major on the Android platform, for new mobile only services, but will face strong competition from other devices platforms and cross devices platforms (Amazon, Ebay etc…). For a strong enough merchant, driving customers through their payment system while not disclosing additional data to Google will become a major focus. It’s no surprise that Google Request full line items details in the Instant Buy implementation.

“The full wallet request specifies purchase details. You should include information such as the line items in the user’s shopping cart, purchase total, and a few other parameters. Google recommends that you include the description field so that you can use it in the receipt to describe purchases made with Google Wallet. This parameter describes the backing instrument with the last four numbers, such as “VISA-1234 via Google Wallet”.”

– Google is losing money on every transactions (on difference between cost of customer card and their rate of 160 bps), that should be compensated via advertising. This is not new for Google in terms of Business model but the difference here is they have no control over the costs. In every other services, their infrastructure cost structurally trends down (Moore’s law, etc..) but payment is one of the few area where this has not happened. Nothing in their current implementation shows a focus on addressing this problem (they are limited to Mastercard CNP). They still need to convince merchants to use Instant Buy (vs pushing a standard for checkout information), I hope they can leverage it in some ways to propose new payment rails.

My prediction: this will face strong competition even on the Android platform and will have difficulties expanding beyond.

Taken at first view, these two Google I/O announcements show a great potential … but appear limited, in some was because they are constrained by the payment platforms they are built on. Google’s “revolution” is a derivative on existing rails; I wish they would show a more insurgent approach and build to improve / replace those. They need to convince merchants to onboard Google Wallet, a radical approach could help was well.

Note: this post is indebted to Tom Noyes twitter exchange and blog post: http://tomnoyes.wordpress.com/2013/05/16/google-in-payments-why-yesterday-was-big-news/

Bank hacking: power to the financial services makers

With the Maker Faire movement growing over the last few years, Hardware hacking has finally been making the headlines. It is one of the root causes of the recent startup hardware trends that are also fueled by platforms such as Kickstarter. What is interesting to me is that independent, smart  and techno savy people put the same effort in building hacks around financial services to make them fit. It’s not always pretty, but it gives strong indication of where things could be going.

Hacking hardware. For people living in a card contactless environment, getting to one platform via mobile can’t happen soon enough. The solution? Cutting and soldering.

From this post on RFID transplantation in Singapore.

 

Rooting Android to support more NFC scenarios. Cherian Abraham has an excellent post on the limitation of NFC in native Android (linked to a controlled Secure Element) and how a rooted Android Environment can help make NFC more open for payment for example with SimplyTapp

SimplyTapp appealed to an early segment of Android enthusiasts who abhorred having been told as to what functionality they are allowed to enable on their phones – by Google, Carriers or anyone else. And to any who dared to root an NFC phone (supported by CyanogenMod) and install the Cyanogenmod firmware, they were rewarded by being able to use both SimplyTapp as well as GoogleWallet to pay via NFC – the former where credentials were stored on the cloud and the latter – within the embedded SE.

Scrapping Personal Banking Data. Truth is, it’s not easy to acces your own banking data. Most of the bank websites have an average to bad UI, non-existing archiving functionalities (being upgraded to 9 months archive is considered amazing) and API access does not exist in 99% of the cases. If you want to automate movements between your bank accounts, get your bank account balanced pushed by email to you every morning then start by building your own scraper: https://github.com/tubaman/bankscrape . You can also find wrappers to access swedish banks: https://github.com/klr/bank and many more.

Bank account simulationhttps://github.com/search?p=2&q=bank+account+management&ref=searchresults&type=Repositories I was looking for more of these examples and I am sure they exist as this is an area where I expect an increase in interesting work. Accounts management is currently a very manual activity and there is no reasons it will not become automated in the future. 

In my view the financial services industry should keep a close eye on the fringe of banking personal hacking. These are early signs and indicators of major trends and innovative services. Hacking challenges, idea crowdsourcing, clients on-boarding are essential tools for the future bank.

 

 

Should people manage their bank accounts? No!

One of the points raised many times at Next Bank Europe is that banks should give better tools for people to manage their accounts and finance. Actually, when asked, most people want to be able to better manage their bank accounts.

However, maybe this is looking at this problem through the wrong lens. Actively managing my own finance is a social holy grail. Amazon has at least 14,000 references for Personal Finance Management. TV shows are devoted to educating people on better personal finance management.

 

 

What is more surprising is that personal finance, accounting are rarely taught to children and studied in school. Society sets proper personal finance management as a key life goal but does little to equip people with this taskIt’s no surprise that people’s finances range from well-managed to sub-optimal (too much cash on checking account for example) to catastrophic.

But the focus put on Finance Management has another consequence. It constrains the problem of building a better bank to a very specific framework. For people to better manage their finance, banking innovators believe they should make their various products more transparent and easy to use. What if the question was: should people even use these tools? Continue reading Should people manage their bank accounts? No!

Creating value around payment – will Offers disappoint?

There is a coupon information bubble right now, but its interesting to see how different it is depending who is talking Offers.

For banking and payment, Offers seem to be still seen as the future of revenue. Whether it is Google, which decided not to take a cut on the payments through google wallet but make money via offers, Serve (American Express) who will power the local offer play of Path, or various PFM providers who source offers as via the credit card transactions, the next big thing is coupons (a little bit of a caricature on my side I agree)

On the other hand, the coupon model has received it’s fair share of criticism since Groupon filed it’s S-1 for its IPO. Outside of the interesting accounting, buy-in of existing investors, recent posts have explored how coupons model such as Groupon, LivingSocial, Google Offers are actually detrimental to businesses and may plateau or dwindle once the novelty wears out (or the economic conditions improve). To read more about Groupon business model, Techcrunch has an passionating series of post on the topic:

Groupon Was “The Single Worst Decision I Have Ever Made As A Business Owner”, Google Offers Is A Cheap Knockoff, Why I Want Google Offers And The Entire Daily Deals Business To Die , Why Groupon Is Poised For Collapse

Yipit teardown is also very interesting:  Groupon S-1 Reveals Business Model Deteriorating in Oldest Markets

To resume: Offers may not work for most small businesses, as their cumulative costs can be higher than what a “regular” marketing campaign would costs, the traffic generated may not create a new customers, and so on…

So is this the end of payments’ next best business model? (dramatic tone)

As said by David Lee during one the Internet Week New York Event : “the closer you are to payment, the more value you capture”

“Owning” the payment data (especially with the ability of connecting a single customer id on each transaction) opens the door to more ways to generate value on payments, for example:

– Analytics on spending patterns for advertising – a possibility of the Google Wallet offer

– CRM/ERP for businesses (dashboards with Google Analytics in mind, in ease of use and richness) – hinted in Square recent releases

– Extensive customer loyalty programs  – (with offers, customer care, … a la Apple)

– Personal Financial Dashboards

What do you think? Are Offers overvalued in the payment / banking industry? Do you see other business models around payment?

 

 

Does Color hint at Payment Social Graphs?

I read daily (and fanatically) Fred Wilson’s blog AVC. How he can manage to publish a daily post and of this level of quality is a mystery for me. On top of that, he has created an incredible community of commenters, which one up each post with their own insights. Thursday’s post The Implicit Social Graph, mused on Color and the underlying assumptions on social networks future.

To summarize, contrary to what Facebook is trying to achieve, Fred’s point of view is that there cannot be a single social graph and that multiple ad-hoc graphs, especially implicit graphs will develop. Implicit graphs are social graphs based on an underlying common activity but moving in terms of members and relationships. They are especially important since maintaining social graphs is difficult and a struggle for users. To quote Fred Wilson:

I believe we will have at least dozens of social graphs in our lives. But even more, I believe that we will have social graphs that come and go and that are formed implicitly not explicitly.

Continue reading Does Color hint at Payment Social Graphs?

Finovate Europe Demo Session

Live blogging the first demo session:

04.13

IND:
First PFM for online banking, users can create ad-hoc tags to aggregate different spending in an single event (vacation for example). Also can identify spending on Google Maps.

04.03

Striata:

Online billing in email via pdf, secured by password, with interactive graphs for bills, update data, download for PFM (not sure it is a case for a majority).

12.54

Final Test

12.53

Testing more

12.52

Modified the Facebook plugin and testing

12.50

Thats a lot of Like and Twitter buttons

12.49

Testing liveblogging for Finovate

While really motivating, this first trial a live blogging did not succeed due to a slow connection. Looking forward to trying more of these. You can search for #finovate on twitter for live feedback on the presenting companies.

Banking as a platform: coming soon with BankSimple

New website, recruitments, preview of Ipad app: BankSimple is on a roll recently; but for me the most important piece of news was the announcement of the BankSimple API.

We’ll be launching an API for use by third-party developers in conjunction with the release of our initial user-facing web and mobile products. We intend the API to support everything that users can do with BankSimple, including retrieving transaction information, transferring funds, and more.

And perhaps even more important, from Joshua Reich on the BankSimple API Google group:

We’ve spent the last year thinking about these issues, but we’d love to hear
your input. Our business model isn’t pageview driven. We want our customers
to own their own data and use it in ways we could never imagine. We want to
support a rich ecosystem of 3rd party applications that make banking better,
while respecting the privacy of our customers.

Now, if you look at your current banking experience, what can you do with your financial data? At best, you can access it from another service (say Mint) which will reformat it to make it more useful for you. THAT’S IT… (if you know of other uses cases, please put them in comment)

Continue reading Banking as a platform: coming soon with BankSimple