On January 13th, 2018 a new set of rules for banking came into force that open up the market by allowing new companies to offer electronic payment services. These rules follow from the EU Directive 2015/2366 of 25 November 2015 that is commonly referred to as Payment Services Directive II (PSDII). They promise innovation that some believed the large banks in the UK would otherwise fail to provide. However, as well as providing opportunities they also introduce new risks. Nevertheless, it is good to see the progress that has been made in the UK towards implementing this directive.
Under this new regime the banks, building societies, credit card issuers, e-money institutions, and others (known as Account Servicing Payment Service Providers ASPSPs) must provide an electronic interface (APIs) that allows third parties (Payment Service Providers or PSPs) to operate an account on behalf of the owner. This opens up the banking system to organizations that are able to provide better ways of making payments, for example through new and better user interfaces (Apps), as well as completely new services that could depend upon an analysis of how you spend your money. These new organizations do not need to run the complete banking service with all that that entails, they just need to provide additional services that are sufficiently attractive to pay their way.
This introduces security challenges by increasing the potential attack surface and, according to some, may introduce conflicts with GDPR privacy obligations. It is therefore essential that security is top of mind when designing, implementing and deploying these systems. In the worst case they present a whole new opportunity for cyber criminals. As regards the potential conflicts with GDPR there will be a session at KuppingerCole’s Digital Finance World in February on this subject. For example, one challenge concerns providing the details of a recipient of an erroneous transfer who refuses to return the money.
To meet the requirements of this directive, the banking industry is moving its IT systems towards platforms that allow them to exploit multiple channels to their customers. This can be achieved in various ways – the cheap and cheerful method being to use “screen scraping” which needs no change to existing systems and new apps use the existing user interfaces to interact. This creates not only security challenges but also a technical architecture that is very messy. A much better approach is to extend existing systems to add open APIs. This is this approach being adopted in the UK.
PSD II is a directive and therefore each EU state needs to implement this locally. However, the job of implementing some of the provisions, including regulatory technical standards (RTS) and guidelines, has been delegated to the European Banking Authority (EBA). In the UK, HM Treasury published the final Payment Services Regulations 2017. The UK Financial Conduct Authority (FCA) issued a joint communication with the Treasury on PSDII and open banking following the publication of these regulations.
While PSDII prevents the UK regulators from mandating a particular method of access, the UK’s Competition and Markets Authority set up the Open Banking Implementation Entity (OBIE) to create software standards and industry guidelines that drive competition and innovation in UK retail banking.
As of now they have published APIs that include:
Open Data API specifications allow API providers (e.g. banks, building societies and ATM providers) to develop API endpoints which can then be accessed by API users (e.g. third-party developers) to build mobile and web applications for banking customers. These allow providers to supply up to date, standardised, information about the latest available products and services so that, for example, a comparison website can more easily and accurately gather information, and thereby develop better services for end customers.
Open Banking Read/Write APIs enable Account Servicing Payment Service Providers to develop API endpoints to an agreed standard so that Account Information Service Providers (AISPs) and Payment Initiation Service Providers (PISPs) can build web and mobile applications for Payment Service Users (PSUs, e.g. personal and business banking customers).
These specifications are now in the public domain which means that any developer can access them to build their end points and applications. However, use of these in a production environment is limited to approved/authorised ASPSPs, AISPs and PISPs.
Approved/authorised will be enrolled in Open Banking Directory. This will provide digital identities and certificates which enable organisations to securely connect and communicate via the Open Banking Security Profile in a standard manner and to best protect all parties.
Open Banking OIDC Security Profile - In many cases, Fintech services such as aggregation services use screen scraping and store user passwords. This is not adequately secure, and the approach being taken is to use a token model such as OAuth [RFC6749, RFC6750]. The aim is to develop a REST/JSON model protected by OAuth. However, OAuth needs to be profiled to be used in the financial use-cases. Therefore, the Open Banking Profile has some differences between the FAPI R+W profile necessary to reduce delivery risk for ASPSPs.
This all seemed straightforward until the publication of the draft Draft supplement to the EU technical regulations. This appears to prohibit the use of many secure approaches and I will cover this in a later blog.
In conclusion, the UK banking industry has taken great strides to define an open set of APIs that will allow banks to open their services as required by PSD II.It would appear that, in this respect, the UK is ahead of the rest of the EU. At the moment, these are only available to cover a limited set of use cases, principally the make an immediate transfer of funds in UK Pounds. In addition, the approach to strong authentication is still under discussion. One further concern is to ensure that all of the potential privacy issues are handled transparently. To hear more on these subjects, attend KuppingerCole Digital Finance World in Frankfurt in February 2018.
