PSD2 – the challenges facing the banks when it comes to third party application data access

By Andrew Whaley, VP Engineering, Arxan Technologies

The next big challenge on the horizon for both the banking and cybersecurity industries comes from impending updates to the EU’s Payment Service Directive (PSD) coming into effect in 2018. The revised directive, known as PSD2, will enable bank customers – including both individual customers and businesses – to conduct their finances through third-party providers. The updated mandate is aimed at providing more flexibility and freedom to users, with customers essentially being able to mix and match individual solutions as they see fit, without having to transfer money from their original accounts to create new ones. This will extend to non-banking solutions as well, for example, paying bills or transferring money via social media.

Andrew Whaley
Andrew Whaley

Nevertheless, this increased flexibility does not come without some major security concerns. Despite Mobile OS’s actively discouraging the linking of applications to ensure data protection, banks are going to be obligated to provide application programme interfaces (APIs) to allow third-party providers access to their customers’ accounts. The only way the new directive will function effectively and securely, will be through the mobile banking application itself. However, the PSD2 does not specify how secure this access will be, nor, what risks will arise, and for who.

Integration and communication

As the PSD2 will only function securely through the mobile banking application, there has to be perfect integration and authentication between the banking and third-party applications sharing its data.

Mobile phone systems themselves actively discourage secure communication between applications because they prefer to keep each individual applications separate, in order to protect the privacy of the end user. No application is able to see what other applications are installed on the mobile phone because barriers have been put in place to avoid the mobile phone working as an interim solution. However, the PSD2 is looking to break these barriers.

The issue comes with the connection between the banking app and the third party app, a point at which attackers can intercept data going from one to the other, or plant malware. Guaranteeing secure integration, authentication, and communication between the two applications on the mobile device is no simple task. The desired end is to ensure that completely secure communication occurs so that at no point can either of the applications be manipulated, nor data leaked. However there is great complexity associated with guaranteeing secure integration between the two applications on the endpoint – predominantly on a mobile phone or tablet. If an attacker is to intercept the communication, it is possible for them to create a malicious version of the application and discreetly access bank account data.

Who holds responsibility?

Unfortunately the onus mostly falls on the banks, with further effect on their customers. It is the customer that will have to authenticate on the third party application, be it Facebook, Twitter or any other mobile app, providing it with permission to access their bank account information. The third party application will then call over to the banking app for permission to access the user’s bank details, leading the banking application to request permission for the third party application to have ongoing access. The customer will then have to confirm and authenticate this request.

Grey areas

The PSD2 contains a number of grey areas, some of which will worry the banks, and others more their customers. Unfortunately, while the directive seems to lay down the law for what it wants the banks to do it, does not specify how any of its mandates are to be achieved. With regard to the APIs, the PSD2 has not proposed a standard as such. This means one bank could publish one set of APIs, while another could publish another completely different set of, leading to a need for different authentication and communication between the mobile applications. This would then create problems when it comes to consuming these APIs as, depending on which bank the customer has their account with, the third-party application through which the account is being accessed will potentially have to build a different adapter and a different API to access the required data. This is mostly an issue for the customer as it may prevent them from being able to access their data through the application they want to use. Additionally, customers may feel their banking data is no longer secure, effecting the reputation of the banks.

PSD2 is quite clear that the banks are still responsible for the ownership, safety and confidentiality of their customers’ account data. The only way the banks can counter this is to implement the technology and counter measures that they already have in place in their mobile applications. They will basically have to force an authorisation through the app which should then mean they will be able to directly communicate with the end user at the point before the third party application has been given any access to the data.

What can be done? 

As mentioned, a big problem with the PSD2 mandate is there is no technical detail over how the banks will securely publish their APIs. The best solution for this would be to instigate a call to action for all the banks to club together and establish mutual standards over how to secure the API, how to secure the authentication, as well as what their code of connection will be, for anyone that wants to use it. This will give a general framework for everyone else to work towards, encouraging harmony across the banking industry.

Unfortunately standards like these will not come into effect immediately, meaning they will not have been established when the directive is implemented in January of next year. Although introducing such a framework will be the most effective solution, in the meantime there are solutions available to provide protection for both the banking applications and the third party applications looking to integrate and access bank customer account data.