.svg)
.svg)
I’m sure that you’ve seen the same presentations that I have. An expert from a large consultancy stands up and his first slide says “API stands for Application Programming Interface”. He continues with a description of new regulations (PSDII / CMA) and describes the technology that will let customers give third parties to access their banking data and trigger new transactions. That’s all true, but it’s a mistake to start there, it leads in the wrong direction.
To win at Open Banking APIs you have to realise two things, (1) it’s not about the technology and (2) it’s not really about banking.
Let’s use Uber to explain. Uber, as I’m sure you know, is a smartphone app that gets you from A to B. You don’t even have to know where A is. The app finds your location using an API call to your smartphone’s GPS; it calls Google Map APIs to provide a street map and route for your journey; and when you finally arrive at your destination, you leave the car and a final API call to Braintree takes care of the payment. None of those APIs are visible, the customer doesn’t care. They receive a seamless experience provided by a group of companies, and it feels like a magic.
It’s not about the technology
All too frequently technologists and innovation labs put technology front and centre. They find a new technology and look around for something to apply it to. And yes, there is a real danger that banking APIs become the latest digital hammer in search of nearby nails, rather than an enabling technology for seamless services. So just creating basic banking APIs shouldn’t be a measure of success. Customers don’t want new technology, they want that Uber experience: useful and elegant. API technology needs to stay firmly in the background to the services that they enable, which brings us neatly to point 2.
It’s not about banking
It’s natural for banks to think about the impact of banking APIs within their world, to be fixated on banking journeys. Unfortunately, this limits us to simple services like providing comparison shopping between different banks, aggregating multiple accounts, or integrating with a more advanced PFM — banking APIs focussing on banking journeys. But we can do so much more. Back to the Uber example, it’s only in a bigger end-to-end taxi context that the Google Maps API becomes super useful (and revenue generating) and only in the context of leaving the taxi and walking off that the Braintree payment API becomes the cherry-on-top experience. To win at APIs, we have to partner with developers, startups, and large multinationals to create seamless services. We have to integrate banking into end-to-end journeys that aren’t really about banking, journeys in which banking only plays a minor part.
A new place to start
So I’d like to offer you a new definition of APIs, a definition that is purpose-driven rather than a technical specification, a definition that takes us in the right direction:
APIs enable end-to-end customer journeys through the integration of data and digital services from different partners.
11:FS has been working with a number of international banks recently, using this definition to explore what those big end-to-end journeys might be. Where do identity, data, and transactions fit within bigger and more complex journeys? Who plays in those areas, and which APIs, developers, startups, and big businesses fit in with that? On what platform should that user journey live? This starts from a clear purpose rather than releasing APIs and hoping that someone has a good idea of what to do with them. It’s designing with purpose… just like every other great product out there. Mortgages are part of moving house, affordability is part of leasing a car, and proving you’ve spent money with a particular retailer could easily be part of an intelligent loyalty scheme — provided that customers can specify that those retailers can only see a subset of their banking transactions. And that loyalty example is great example of why exploring customer driven use cases can have an impact both on the type of APIs you design, the potential partners you approach, and possible revenue streams for the bank. Have you seen mention of retailer filters for bank APIs? No? Banking APIs really do have the capacity to create powerful, seamless experiences for the end customer while providing some very profitable new revenue streams for the banks that develop them, but we have to focus less on the technology, and more on how banking can integrate into bigger journeys that are nothing to do with traditional banking. If you’d like to talk more about API customer journeys, revenue models, and go-to-market strategies, leave a comment below, find me on Twitter at @jasonbates, or reach out to the team: hello@11fs.co.uk For more from Jason and the 11:FS team, listen to Fintech Insider, the #1 global FinTech podcast.
