Open banking read write APIs – Are they really customer friendly?

The Competition and Markets Authority (CMA) in the UK has released a second set of APIs named Read/Write APIs. These APIs focus on Account Information and Payment Initiation capabilities that banks or ASPSP need to provide as part of PSD2 regulation.

There have been many discussions around the target customer experience once PSD2 APIs are published by the banks and how third party providers (TPPs) and FinTechs will immediately capture the market that will result in loss of customers for the banks. The PSD2 regulation itself has not provided any standards around API definition or target customer experience. Additionally, the security aspects are PSD2 are described in another standard known as Regulatory Technical Standard (RTS). RTS provides all the necessary technical standards that an ASPSP or Banks must adhere to. To protect consumers, it prescribes implementation of Strong Customer Authentication (SCA).

With two regulations, ASPSPs or banks are left to interpret these regulations and provide appropriate APIs with great level of security to the third party providers. In the UK, CMA took a step to standardize these APIs and customer experience. The Read/Write APIs is a result of this initiative providing standardize API definitions and customer experience for banks, TPPs and customers.

While the CMA APIs provides API details However, the key challenge with CMA APIs is that it prescribes a customer experience that is governed by banks and not by TPPs.

Every time a TPP wants to initiate a payment on customer’s behalf, there are sequence of steps that must be followed as below;

1. Submit an intent to the bank to make a payment to a beneficiary. For example, the intent would say pay ￡10 to Starbucks' account number XXXX. At this stage, the TPP may or may not know the account from where the money would come from. Bank would register this intent and will provide a payment Id.
2. With this payment Id, the TPP must redirect the customer to bank’s authentication and authorization portal which includes all SCA based rules. TPP is completely bypassed in this interaction. During this process, the customer chooses the account from where money is taken for the payment.
3. If customer authorizes payment, TPP get an “access token” to actually submit a payment using payment-submission API to initiate the payment using Faster Payment Scheme.

While this flow puts bank in full control of the security, it poses following challenges for the TPP when designing customer experience with these APIs.

1. There is no provision to get a multiple transaction authorization from the customer. This means, all the steps above MUST be repeated for every transaction. This creates an experience like iDEAL payments in the Netherlands that was introduced in 2005 i.e. 12 years ago.
2. Because the flow defined by CMA relies on HTTP redirection, it is not possible to initiate payment from channels that do not support “web” based interface. Thus, channels that do not have a web based interface such as loyalty cards, telephone, POS machines will not be able to use these APIs.
3. Additionally, the web based interface is only applicable to customer owned devices such as web browsers and smartphone apps. The flow, as defined by CMA, will not work with TPP or merchant owned devices such as POS terminals, kiosks, ATM machines etc. TPPs will have to put in additional step in the interaction to make these APIs work on non-customer devices.

With account information APIs, the experience is lot better. Once customer authorizes a TPP, they receive a “long lasting” token that allows them to access account information repeatedly without need of re-authorization. This would allow “aggregators” easier access to customer information without asking them about their internet banking credentials (which is a major repulsive factor today).

While many would think Open Banking APIs are far better than screen scraping technologies deployed by many FinTechs today, the customer experience with these new APIs is only a small step in the right direction and leaves many questions unanswered. PSD2 is designed keeping customer at the centre where customer gets to choose who they transact with. However, with this not so impressive experience, TPPs, especially PISPs, may find it difficult to attract customers especially when far superior payment experience being offered by likes of Apple Pay, Samsung Pay and existing card networks. However, we may see a surge in account aggregators marketplace due far simpler integration and experience complexities.