20 November 2017
TL;DR: – open banking is a new concept in digital banking, which provides for the use of interfaces (and applications) built by third parties accessing banks’ systems. The significance of this change means that, with customers’ permission, access to their accounts, whether for the purposes of pulling information or initiating payments, is now a possibility for third parties. This opens a potentially limitless number of new use cases to the digital ecosystem, which previously weren’t possible due to the very tight control banks exercised over customer accounts.
What is open banking? – open banking is a new concept in digital banking, which provides for the use of interfaces (and applications) built by third parties accessing banks’ systems. In a European context, this has been driven by two pieces of legislation. In the UK, the CMA Order on Retail Banking included as part of its remedies, the need for 9 of the largest retail banks (CMA9) to implement Application Programming Interfaces (APIs) to deliver information about a range of on sale products (Open Data), to deliver information about customer accounts (AISP) and to allow the initiation of payments on a customer’s behalf (PISP).
Across Europe, the Revised Payment Services Directive, better known as PSD2, also provided for the implementation of APIs, as well as a number of changes to system timelines to support this. The principle difference between these two pieces of legislation, is that the CMA Order provided for the creation of a body (the Open Banking Implementation Entity or OBIE) to deliver API specifications or standards, the result being that all of the CMA9 would have at the base of their API ecosystems a common interface.
The reason for this seems to be the relatively specific aims the CMA has in its Order, essentially increasing competition through the levelling of the playing field which larger banks have dominated to date. There is, potentially, a significant economy of scale from the point of view of a developer, in being able to develop one application which can interface with a large number of banks, as opposed to proprietary development for each bank.
There are limited differences to the scope of each piece of legislation, and in many respects the CMA Order and the consequent API specifications can be seen as a stepping stone to PSD2 compliance. Whilst the scope of account information that a bank must publish under the CMA Order is wider, and there is no Open Data element to PSD2, the scope of payments that a bank must allow under PSD2, and the range of accounts are wider.
A further Regulatory Technical Standard on Strong Customer Authentication is expected to be published in January 2018, and will dictate part of the technical design of the interfaces, and which banks will have 18 months to comply with.Most banks impacted by both acts are implementing the required scope of the CMA Order, with a view to achieving PSD2 compliance over the course of the RTS transition period.
What does this all mean for the customer? – in the first instance, the short answer is very little. None of the changes which banks have to implement are customer facing and open banking developing is dependent on whether a market of applications grows and are used by customers. Potentially there is quite a lot of scope for significant change for how customers access financial services.
PISP (Payment Initiation) – both acts provide for banks allowing the initiation of payments by a third party. What this would practically mean is that, rather than using a card to pay for a good or service, an organisation with an online purchase capability would redirect a customer to their banks online portal, where they would be asked to authorise a direct transfer to the merchant in the context of the purchase. Once they’d provided this authorisation using a secure method, the merchant could then initiate the payment which the bank would then execute off line, with a settlement time dependent on the nature of the payment. It should be made clear that this does not give the merchant unfettered access to or control of a customer’s account – this is retained by the customer and the bank, with the latter having the ability to stop an instruction if they had concerns about the merchant.
From the merchant and bank’s point of view, there are substantial cost savings in the use of this method as opposed to traditional card payment, which incurs significant fees. The savings on these could be passed on to customers as an added benefit. The other notable benefit is the immediacy of settlement at the point of execution – once again it is important to make clear that third parties can only initiate payments, and the execution of these (which should take place extremely quickly) remains in the banks’ domain.
The PISP domain also provides for the movement of money between customer accounts – third parties could avail of this service to offer customers gains in leveraging particular rates, avoiding fees and the like. Any third party service is reliant on customer authentication and authorisation, so building a relationship of trust with the customer will be key to the development of an offering.
AISP (Account Information) – contrary to what has been written elsewhere, this service does not grant a third party unfettered access to customer accounts. In real use, a third party would sent up a request to a specific range of information – for example transactions, direct debits, account fees and charges – which the customer would have to then authorise the release of. In contrast to the PISP journey which (at go live) will only be single immediate payments, AISP services can be ongoing so that a third party could request this information multiple times after one authorisation by the customer, though requests can be timed boxed and information can only be pulled a maximum of 4 times a day.
The range of information available is key to analysis of the potential use cases which third parties may seek to develop on behalf of the customer. PSD2 has restricted AISP flows to (de minimis) balance and transaction information, whereas the CMA order provides for a wide range of information. The scope of what is being requested must be defined by the third party and presented to the customer before they authorise it being delivered, so ultimate and granular control of what information flows stays in their hands.
The most frequently cited examples for the AISP flows relate to consolidation of accounts where a customer has multiple accounts with a range of providers, and from a business perspective, giving company accountants direct access to business accounts to assist in the delivery of their services. These are both functions available in today’s marketplace, as is price comparison, and are not particularly exciting. Some challenger banks which already have developed API platforms have linked with third parties to look at more interesting use cases – round up (where a customer’s transactions are rounded up to the nearest single unit and the remainder stored in a savings account) and location based alerts for partnered services being two examples. The reality of the account information space is that it provides for a very significant number of use cases which could improve finance management no end.
The key to the development of this market, whilst trust remains important, will be showing customers what the added benefits of using third parties as the primary interface to their accounts is, as opposed to the banks themselves. This change in customer centricity is perhaps where banks see the greatest threat to open banking, and some are responding in their services already to counter it. Ultimately, much of how open banking effects banks will be dependent on whether they are capable of embracing it, but that should remain the subject of another post.
Conclusion – this closes a brief introduction to open banking. The following topics are planned for the future but any suggestions are welcome.
- TPPs and the Regulatory Landscape
- Strategic open banking development for banks
- Debunking open banking myths