The era of the open banking application programming interface (API) is nigh, thanks to the European Union’s (EU’s) revised Payment Services Directive, aka PSD2. Come January 2018, the PSD2 will enable all bank customers, both consumers and businesses, to use third-party providers to manage their finances. Despite mobile operating systems’ actively discouraging the linking of applications to ensure data protection, banks are going to be obligated to provide 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.
An API is essentially a set of instructions or routines to complete a specific task, or interact with another system, from servers to other applications. Because APIs are able to perform tasks such as retrieving data or initiating other processes, developers can integrate different APIs into their software to complete complex tasks. APIs have become a real game-changer in software development as, rather than spending countless hours writing every aspect of the software from scratch, developers can simply pick from an increasingly large selection of best-of-breed APIs developed by specialists, and plug them straight in. Using ready-made components enables developers to considerably reduce costs and time-to-market, and perhaps more importantly also frees up time and resources to pour into the innovative and unique features that will cause their application to stand out.
However, despite having so many benefits, APIs do come with their downsides. The principal weakness is the simple authentication that is widely used by most API management solutions to confirm that the client app on a device is genuine and has been authorized to utilise server assets. Typically, this is done using a simple challenge-response exchange, as the client app tries to connect to the API server. This exchange is usually a cryptographic operation, which means that the mobile client generally contains a secret key for an asymmetric cipher like Rivest Shamir Adleman (RSA) or Elliptic Curve Cryptography (ECC).
If attackers are able to break the application’s security and decompile its code, they can root out the encryption keys. Any application that is available for download is particularly vulnerable to this, as they can be attacked indefinitely until a weakness is found. Once the keys have been found, attackers can use them to trick the system into recognizing them as a legitimate client and enabling them to access anything the API was authorised to connect with. An API that accesses data on the backend server for a cloud application, for example, could provide attackers with the ability to break in and steal sensitive data or perform other malicious activity. To prevent tampering, keys need to be defended with code-hardening measures such as obfuscation, a process that renders code into unusable scrambled code; or debugger detection, which will detect if the application has been used in a debugging environment used by hackers.
A new way of banking
Come January 2018, APIs are going to play a big role within the banking industry as the PSD2 makes open banking mandatory. The PSD2 is battling against what the bureaucrats see as a bank monopoly, introducing third party access to customer account data in the hope that it brings about some competition as well as reduces the reliance we have on banks when it comes to handling our finances.
Once the PSD2 comes into effect, customers will be able to access particular banking services through other mobile applications. However, for this to happen they will first have to authenticate, on the app they want to use, that it has permission to access their data. The process for the end customer authenticating to the bank that they are happy for a third party to access their account details will go as follows: The customer will first have to authenticate on the third party app, let’s use Facebook as an example, that it has permission to access said customer’s bank details – most likely this will be the customer’s bank balance. The Facebook application will then have to call over to the banking application for this access permission. Following this, the customer will receive a request from the banking app asking them to confirm that Facebook is allowed to have ongoing permission to access their bank information. The customer will then have to confirm and authenticate this through the banking app.
Security issues – are there any solutions?
An obvious issue associated with the PSD2 mandate is that it has stated what it wants, but seems to have neglected the all-important issue of security. The above process is the only way these demands issued by the PSD2 will function securely, however, this will only work if there is perfect integration and communication between the banking application and the third party app. Despite having a secure banking application, if the third party app is insecure then the request could be manipulated before reaching the banking app. Similarly, if the third party app is secure but the banking app is not, the request could be manipulated at the other end. As a consequence, both the banking application and the third party application are going to have to be protected. For this to work correctly, the banks are going to have to establish a code of conduct that tells the third parties that if they want to use their APIs they have to follow certain requirements, use the software development kit (SDK) that the bank provides, as well as ensure their application is secure.
One question that arises from the introduction of communication between banking and third party apps is, how can the bank be certain that when the third party app is calling, that it is acting on the user’s behalf? Third party apps are not subject to such strict regulations as banking apps are with regard to where data is stored and who can access it. In order to tackle this, banks are going to need to provide screens, or a way of managing those permissions to monitor how long the mandate is used for, notably how long the third party apps can have access to customer data, as well as some way of requesting whether the customer is happy for the third party app to still have access to bank information. It will be possible for users to change their requests on the banking app – however this does not mean that the permission preferences on the third party app will change.
Who will suffer the consequences?
Unfortunately for them, it is the banks that will carry all of the risks for PSD2, as they have an obligation to protect their customers and any of their data.
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, 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 not only an issue for the banks, but also 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, affecting the reputation of the banks.
The PSD2 has caused a lot of concern within the banking industry. Its expected introduction in January 2018 will not give banks enough time to design a plan of action to combat the inevitable security risks associated not only with APIs but also, quite simply, the sharing of personal and financial data between mobile applications.
The only way the PSD2 mandates will be fully secure is if all the banks issue a call-to-action to create a mutual standard for both authentication and the providing of APIs. As such standards are never implemented with much haste, it is vital that in the meantime banks do all they can do to protect not only their customers’ data, but also their own reputation. The best solution for the banks will be to implement the technology and counter measures that they already have in place in their mobile applications, basically forcing an authorisation through the app. This 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.
The benefits of an in-house bank are increasingly evident, but some treasury departments still hesitate to take the plunge. This article offers a step-by-step guide.
Last month BNY Mellon and Volante Technologies announced that they had been collaborating to enable BNY Mellon to become the first bank to successfully originate a real-time payment over the Clearing House’s (TCH) new Real-Time Payments (RTP) network.
A 'digital treasury ecosystem', where the CFO or treasurer makes real-time financial decisions on their tablets, is not far beyond the reach of currently available technology. In such an ecosystem, there is no direct reliance on banking partners or the company’s broader organisation - just an executive and an interactive dashboard powered by interconnected digital technologies, writes Eric Cohen, PwC.
For treasury professionals across the globe, regardless of the size and type of organisation, two words are likely to be high on the agenda - sustainability and efficiency, says Owen Balloch, Marketing Manager at Alaris, a Kodak Alaris business.