Overview
Think of API’s as;
- Doorways where what goes in and out of the ‘doorway’ is very, very predictable and widely publicised, and
- Doorways which are open to anyone with the right key, and
- Which come in “pairs” like doors at either end of a windowless corridor.
In the PSD2 and Open Banking Context, this is illustrated in a simplified way below. 
The example bank in this diagram has created several API’s which open doorways onto their account database and payments processing capability. Two different customers of this Bank (A and B in the diagram) are using two different apps to do things with different companies. (Third Party Providers or TPP’s in the jargon).
- Customer A is using his mobile phone to make a purchase online and rather than use his credit card, he has given the retailer permission to make a payment off his bank account to the retailer.
- Customer B is using a comparison site to consider switching phone companies. His account history will help the comparison site and mobile phone companies access his credit worthiness and because he is confident in his track record, he allows the comparison site to access his bank account information.
Both these scenarios use API’s to achieve these goals. The TPP’s open the first door (API) at their end of the corridor based on the customer’s request. The customer has told them their bank, and given some security information so the TPP knows which door to open at which bank. At the bank end of the corridor they have a door for payment instructions and a different door for account information. The bank gets a knock on its door from the TPP and does some security checks.
- Is the company asking registered with authorities as permitted to come through the door?
- Are the customer credentials correct? So for that particular customer is it able to open the door to the TPP?
It should be noted that this is not a bilateral relationship. The TPP’s are registered at a UK/EU wide level and so, once registered can approach any bank in the UK/EU for information. Conversely one bank has to provide a service to any authorised TPP in the UK/EU, provided the customer has given permission.
Standards for Banking APIs
Because of the Any to Any nature of Open Banking/PSD2. Standards are needed to make this all work. Unfortunately at an EU level there are none (yet). Pity!!! At the UK level there is the Open Banking standards and there are others emerging in the EU such as those being developed by the Berlin Group.
Legislation
In a bid to foment competition and a single market, the EU came up with the Payment Services Directive (PSD2). This requires all banks that have a payment account (essentially a current account) to provide API access to that account to TPP’s at a cost no greater than the bank charges their own customers to access the information by electronic means. To all intents and purposes this means the TPP’s have zero cost access to the information and very cheap means of making payments (typically ACH payments in Europe are free of cost or a few pence/cents). In the UK the competition and Markets Authority came up with rules that align with PSD2 but:
- Go into more detail on standards and
- Go beyond the range of accounts and services covered by PSD2.
- Are called Open Banking.
The relation between the two sets of legislation is illustrated below.
Implications for Banks
PSD2 and Open Banking is the first step on the “API-ification” of services. The UK life and pensions industry are under pressure to provide API access to people’s pension information to create what are called pensions dashboards for people who collect multiple pensions over their working lives. In a different sphere, the government is keen to create API’s to Government services to allow users to access and share their information between government departments. Many companies are voluntarily creating API’s to their products and services so that they can be easily added to another company’s website/ marketplace. All this means three things for Banks;
- They will have to, and want to, provide API’s to their products – current accounts, credit cards, loans, mortgages etc.
- There are no real standards yet for these API’s so banks will have to come up with flexible ways of creating them in the next few years.
- Expect to have to add new API’s.
- Expect to have to put extra translation layers onto them as standards evolve.
- Consider third party API providers for these API software services.
- Start building bank product and channel strategies with third parties. The age of the vertically integrated bank, one where only bank products are sold and serviced through bank electronic channels and only bank channels can be used sell and service bank products, is well and truly over.
The challenge for banks in all these three areas is to develop these API based capabilities before the Digital start-ups. If you would like to comment on this, discuss this further or find out about similar issues, contact us by clicking here.
