The bank business model for APIs: Identity

In Europe the banks are being forced to open up APIs for third-party access to bank accounts. Obviously, this will cost money and entails risks. But from the work that Consult Hyperion has already done for banks in this area, I think I can see at least one way to build a positive business model around them.

As you may recall, the UK Government has for a while been looking at APIs in banking…

The UK Government is to launch a ‘Call for Evidence’ on how APIs could be used in banking to improve transparency and help customers compare financial services providers.

[From Finextra: UK Government issues call to action on bank APIs]

As you may further recall, I’ve commented that this is a fairly trivial use of APIs (you don’t need an API to download a statement as a CSV file and then upload it to a comparison site), but I suppose the government are looking at them in competition terms, rather than in strategic terms, and I don’t think they have any considered view of what the point of them might be. Anyway, I though you might be interested to know that while we were discussing APIs at the 18th Tomorrow’s Transaction Forum, the Chancellor’s Budget statement popped up with this snippet:

2.220 Application Programming Interfaces (APIs) in banking – The government has today confirmed its commitment to deliver an open API standard in UK banking and, working with the banking and FinTech industries, set out a detailed framework for its design by the end of 2015. This will enable FinTech firms to make use of bank data on behalf of customers in a variety of helpful and creative ways, and ensure the UK remains at the forefront of developments in financial technology and innovation.

This ought to be quite a scary snippet for banks, who are going to have to develop a strategic response to this very, very important structural change in the financial services sector. In my presentation to the Payments International 2015 pre-conference Mobile Payments Summit, I suggested that banks could begin to think about the impending API revolution by setting the goal to reinvent themselves as “amazonized” (Ie, API-based) businesses. But what shared framework could the banks and the government use to evolve their thinking? Well, one candidate has been put together by the Euro Banking Association.

As for a model for discussion purposes, the ABE-EBA “Digital Customer Services Infrastructure” (DCSI) vision for European banks is quite attractive. It envisages using three different kinds of APIs to give commerce direct access to pan-European payments infrastructure:

1. The “regulated payment APIs” as set out in PSD2.
2. The “non-regulated payment APIs” that PSPs define and agree themselves.
3. The non-payment APIs agreed between the PSDs and other stakeholders. A prime example of such a non-payment APIs would be digital identity services, ranging from authentication to age verification.

While identity is the common thread that runs through all of these APIs, in my own talk at the Forum I suggested that banks focus on this third category as the way to stay in the game and I thought again about this when Heather Schlegel was giving her excellent keynote on supporting the sharing economy. Krzysztof Korus of Prudentiz also touched on this in the session on “Access to the Account” (or “XS2A” as it is rather oddly known in European circles – surely it should be AXS2A?) that he ran at the EPCA Payment Summit 2015 in Brussels.

Banks will have to develop strong, convenient and modern identity and authentication services to make all of this would. But let’s imagine that they do. So how would all this DCSI work in practice? Well, I imagine it would be something along these lines.

1. I run my Amazon app and it asks me if it can have access to my bank account.
2. I consent, so I get bounced to my bank app and am required to authenticate to it.
3. I am returned to Amazon. Now when I check out, the default payment option will be “Amazon Super Debit Plus” (or whatever brand they use for direct access to the account).
4. In the settings for my bank app, Amazon now shows up as having direct access to my account, a setting that I can turn off at any time.

OK, quite an appealing model. But how is a bank going to make any money out of this? Providing these APIs isn’t going to be free and they have ongoing maintenance and support costs too. I spotted an article that had a useful categorisation of options for monetising APIs a while ago.

But our analysis indicates that APIs are generating revenues in one of three ways for the companies that choose to contribute their data

[FromMonetizing mobile apps: Striking the right balance | McKinsey & Company]

The three models that McKinsey identify are pay-per-use, subscription and revenue-sharing.

• Under the pay-per-use model, a company makes its transactional data available to third party apps that, for example, compare prices or analyze customer behavior. This accounts for around 40% of the APIs they looked at.
• Subscription models are similar, but fees accrue during a subscription period rather than per use. These were also around 40% of the APIs studied.
• The remaining fifth of the APIs looked used resource-usage and revenue-sharing models typically generate sales of a company’s own products (for example, on an online storefront), from which the app developer too gets a cut.

Whether you think this breakdown is right or not, it does illustrate that there are possibilities for banks to obtain revenues from providing decent identity-based services across the DCSI. These may, however, be constrained. In their report for the Treasury on “Data Sharing and Open Data for Banks” (September 2014), the Open Data Institute (ODI) and Fingleton Associates note that as PSD2 stands

banks would have to allow third parties, via an interface (an API), to initiate payments from bank accounts. That access must be given on the same basis as if to account owner, i.e., if the owner can initiate a payment at zero cost, then so must a third party.

The ODI/Fingleton report (I made a podcast about it with Andy Reiss from Fingleton if you are interested in learning more) says that APIs offer practical, immediate and valuable applications for banks, and it specifically goes on to say:

More generally, banks are in a strong position to “verify attributes” on behalf of others, or to become a trusted identity provider. They could sell this service.

If the commercial model ends up as no charge for regulated payment APIs, regulated charges for the non-regulated payments APIs but market pricing for the non-regulated,non-payment APIs (since it is unlikely that banks will be given free rein here), then some of the most valuable services might be these attribute services (IS_OVER_18, IS_UK_RESIDENT, IS_NOT_OVERDRAWN and so forth). It’s just a suggestion, but banks thinking about a strategy around identity might do worse than make attribute provision a focus.