Written by 
I had a lovely time at the Payments Forward afternoon tea discussion on “When do you build, buy or partner to innovate in payments”. But in payments, new services are more likely to “assembled” aren’t they?
The discussion was interesting because, as always, Dinah had put together a terrific panel, encompassing useful, informed and different perspectives.
- Paul Stoddart, Managing Director of Strategy & Business Development, VocaLink
- Udayan Goyal, Founder, Anthemis Group and FT Advisors
- Scott Abrahams, Group Head, Acceptance UK and Ireland, MasterCard Worldwide.
- Ed Chandler, CEO, Kalixa.
I was very happy to see Ed there because his watch got me a load of retweets last month, and there is no more important measure of a man than that in my opinion. The reason was that, to make a point about paying with an Apple Watch (in a dreary technical conversation relating to secure elements and default NFC app selection) and in the context of some Twitter discussions about paying in drive-through fast-food outlets, I used my Kalixa EMV watch to pay at a McDonalds drive-through in Barnet.
This is with a watch that is about three years old. Anyway, it turned out that lots of people were interested in this, so that was fun, and I made a point of saying thanks to Ed.
And so the debate. To be completely frank, I thought the discussion was slightly outdated in some parts and that’s because I agreed with Uday about the nature of “build”. Today, “build” doesn’t mean writing a load of software that only 90% works and wasting a ton of money on systems integrators and management consultants. Today, in an organisation that is going to win, “build” really means “assemble”. It’s all about APIs, it’s all about “amazonisation”. By this I don’t mean having an excellent e-commerce operation, but the idea of using APIs for everything. I wrote extensively about this earlier in the year and I don’t want to repeat what I said then, but I did mention that our first major project for a financial services organisation looking at moving to API-based operation was a couple of years ago.
In time, banks are going to be “Amazonised” and will open their APIs both internally and externally. So what should the focus of the API be? The customer, maybe, rather than their money.
[From If there is going to be a euro-API for banking, what should it do?]
The point about the amazonisation strategy, as Uday touched on, is that it means shifting to components and networks and APIs connecting everything in an organisation, not simply adding an API layer on top of customer interfaces. The goal is to extend innovation throughout the organisation as well as facilitating co-creation with customers and suppliers. It may be hard for traditional financial services providers to come to terms with the idea of opening up in this way but it seems to me to be an inevitable restructuring in organisations that are going to survive in the new environment.
I had been reminded of this a few days earlier when I was on a panel with J.P. Rangaswami, the Chief Scientist at Salesforce, and he observed in passing that the power of their API is that they have 100 times more developers than staff. One hundred times! This is really a new way of doing business. However, as I observed back in July…
What will the euro-API mean for competition in banking?: “There is a danger that this ‘connected banking’ model turns into a sort of ‘dumb pipe’ model of banking”
Richard Johnson from Monitise mentioned this at Mobey Day in Barcelona too. Banking is a special case when it comes to amazonisation because of regulation, but if the banks are forced to open up their core services then it seems to me that their best strategy is to amazonize (if there is, or even should be, such a word) and build their own services on top of these APIs. And they should probably start fairly soon because there is a world of difference between making a strategic choice to be a smart pipe and being left with no option but to be a dumb pipe.
