PSD2 risks and IT controls to mitigate

Introduction

PSD2 is the new European Directive on consumer and business payments. With the introduction of PSD2, new providers of new payment and account information services will enter the market. They will act as an online third party between you and your bank. These third parties – also known as Third Party Payment Providers – can be other banks, for example, or FinTech companies. The PSD2 brings two major changes to the payments industry: it mandates stronger security requirements for online transactions through multi-factor authentication and it forces banks and other financial institutions to give third-party payment services providers access to customer bank accounts if account holders give their consent.

There are many opportunities and advantages that will be introduced by the second Payment Services Directive (PSD2), such as increase protection of payment service users through increase security requirements and the opportunity for new services, based on account information and payment initiation capabilities. Unfortunately, with the new regulation and new opportunities and advantages, new risks will also be introduced. The risks include both operational and third-party risks and must be managed effectively. Banks and Third Party Payment Providers (TPPs) will experience significant growth in the volume of their business to business (B2B) network connections and traffic, and a growth in exposure of core banking functions driving up enterprise risk. In addition, by mandating banks to do business with TPPs, they will soon face the challenge of how to aggregate and understand risk from potentially dozens to hundreds of TPPs. The question is, is this practice safe for your security and compliance program? Alternatively, if it’s not safe, which controls could be applied to your product team to mitigate the risks? ([Blea18])

In this article, we will present the related risks arising from PSD2 for four parties: banks, customers, TPPs and supervisors, with a focus on IT. We will also explain how to mitigate these risks, followed by some controls and best practices.

Background

PSD2 forces banks of the Netherlands and Europe to share data with licensed organizations and execute a payment through initiation of payment services. Transaction data can be shared – this includes how consumers spend their money whether with cash or through credit, including information on loans of customers. One of the key elements of PSD2 is introduction of Access to Accounts (XS2A) via TPPs. Banks and other financial institution must give certain licensed third parties access to account information and cannot treat payments that go through Third-party Service Providers differently. Once a customer has given their explicit consent to have their data shared, this is most commonly done through a trusted API that requires strong customer authentication ([Mant18]). Open banking is the use of open APIs that share financial information with providers in a secure way. Open banking API means that the customers’ information stored in banks will no longer be “proprietary” and will finally belong to the account owners, not to the banks keeping those accounts.

Figure 1. PSD2 stakeholder relationships. [Click on the image for a larger image]

PSD2 is the second Payment Services Directive and is applicable to the countries of the European Economic Area (EEA). The PSD2 directive aims to establish legal clarity and create a level playing field in the payments sector in order to promote competition in the payments network, efficiency and innovation. Furthermore, higher security standards will be introduced to protect consumers and customers with online payments.

The scope of PSD2 relates to any party that offers payment services for example FinTechs, innovative new providers, also referred to as TPPs and tech giants such as GAFAMs (Google, Apple, Facebook, Amazon, Microsoft). Payment services include account information services and payment initiation services. TPPs include payment initiation services providers (PISPs) that initiate payments on behalf of customers and aggregators and account information service providers (AISPs) that give an overview of customer accounts and balances ([EuCo17]).

In order to comply with PSD2, certain Regulatory Technical Standards (RTS) will have to be complied with, specifically Strong Customer Authentication (SCA) and Secure Communication. SCA allows payments that are being made to be more secure through enhanced levels of authentication that are required when completing a transaction. There are, however, some exceptions to this rule, including but not limited to, low value and recurring transactions ([Adye18]). Due to the complexity of the requirements The European Banking Authority (EBA) has advised an opinion that the deadline for SCA for online card transactions should be postponed to 31 December 2020 ([EBA19a]) and National Competent Authorities adhered to this as service providers, mainly retailers and PSPs, experienced implementation challenges over Europe. Riskified, a global payment service provider facilitator, performed a survey that included participants from UK, Germany, France and Spain and noted that nine out of ten retailers (88%) believe consumers are ‘somewhat’ or ‘very aware’ of PSD2. However, more than three-quarters (76%) of consumers report that they haven’t even heard of PSD2, showing an imbalance between retailers and online consumers awareness ([Sing19]). Over the last few years, EU Member States have integrated PSD2 into local legislation in order to issue, among other, TPP licenses. The total number of TPPs in the EEA is 326 with the UK leading with 158.

Figure 2. TPPs in EEA in 2020 ([OBE20]). [Click on the image for a larger image]

In order to ensure that payment providers adhere to these regulations, supervisors have been tasked with monitoring compliance with PSD2, in certain cases in conjunction with one another. In the Netherlands, supervision is being shared between four supervisors: the Dutch Bank (DNB) that is focused on authorizations, providing licenses to payment service providers as well as being the prudential supervisor, the Dutch Data Protection Authority (AP) that focuses on the protection of personal data in PSD2, the Dutch Authority for Financial Markets (AFM) that is focused on behavioral or conduct supervision on payment services providers, and the Dutch Authority Consumer and Market (ACM) that is focused on the competition between payment service providers ([McIn20]).

The current payment landscape brings certain risks with it. We will present the related risks arising from PSD2 for privacy, security and transaction fraud risk from the perspective of the four parties: banks, customers, payment service providers and supervisors, with a focus on IT.

Risks

Privacy

PSD2 will allow customers to share their banking information and “sensitive personal data” with parties other than their bank. This raises questions about the privacy of customer data and whether the movement of customer data can be traced; it is clear who has access to what data. Banks and PSPs will accumulate customer data and eventually process the data and should therefore be aware of the risks relating to retention and processing of data as well as complying with legislation such as the General Data Protection Regulation (GDPR).

Companies with a license as a PSP can access payment data from account holders. However, once information from customers is obtained, these payment institutions need to protect the information, otherwise they are at risk for getting major fines of €20 million or 4% of global sales ([Hoor17]). For a new PSP that enters the market, suffering the reputational damage if customers are not comfortable with how their data is being used or feel that their data has been “stolen” through unclear agreements could be detrimental to their success.

Banks need to consider the impact of the interplay between PSD2 and GDPR as requirements may be conflicting. Banks will share banking information with relevant TPPs that have a PSD2 license, however, due to the GDPR that came into play on 25 May 2018, it is also the responsibility of banks to protect their customer data that they are obliged to share. If banks do not share data, competition authorities may intervene. Furthermore, only data should be shared for which explicit and current consent has been provided to avoid unauthorized data being shared and the reputational damage that will follow ([Benn18]).

Customers need to give explicit permission to the relevant financial institution, or PSP is allowed to access their payment information. The risk for the user is that they give permission too easily and too quickly without considering the consequences ([Hoor17]). Customers cannot limit the amount of information that is shared with the PSP, all payment account information is shared whether it is relevant to the payment service or not. This is a risk if the TPP uses customer data beyond its primary responsibility or if data is stolen, because the banking history of customers could reveal information of other parties through combined customer information and buying trends, such as spending rates at specific retail institutions. Therefore, customers may consent to sharing both their banking information as well as “sensitive personal data”, such as purchasing history revealing habits or perhaps sensitive purchases, that may not even be relevant to the PSP and has the risk of ending up in the wrong hands ([PrFi19]).

It is expected that supervisors monitor players in the payment landscape to ensure a safe and fair payment environment. The compliance set out by regulators needs to be adhered to in order to ensure this (see also the KPMG Point of View paper [KPMG20], which focuses on potential regulatory compliance risks arising from payments innovation). The major risk faced by the regulators and supervisors is loss of visibility of different players, and that players are no longer held accountable for their actions, their customers and their payment information ([McIn20]).

Security

PSD2 brings potential threats, such as security risk in sharing data with third-party payment providers, risk of fraud in case of dishonorable third-party payment providers, or hacked customers and requests made via TPPs that may be susceptible to third party fraud powered by malware or social engineering techniques, and fraudsters could use the TPPs as an obfuscation layer to confuse the banks’ fraud defenses. It is therefore important that TPPs are able to cope up with the security threats and mitigate such risks. By nature, Fintech firms – new PISPs and AISPs – have little reputation at stake. This means they may be inclined to take riskier business decisions, or even involve themselves in misleading business activities.

First, banks must train their IT systems to cope with potential cyberattacks. It’s helpful to think of an API as a set of doorways, and behind every door is a different set of data: account balances, transaction history, the ability to make deposits/withdrawals along with other customer information. In an ideal system, these APIs (or doorways) would only be accessible to trusted parties with your knowledge of their access. However, banks have always been a target of criminal activity, and it’s not hard for anyone to imagine that there are those out there waiting to abuse these new access points to bank data ([EBA19b]). To eliminate cyber-attacks from hackers, robust authentication barriers need to be in place. For the banks there needs to be a concrete clarification that the PISP is who she says she is. The way banks manage this will be crucial for investors as well as depositors. If banks are unable to develop sound API infrastructure to become reliable Account Servicing Payment Service Providers (ASPSPs), their market share will be lost to FinTech firms.

Customers making use of the services offered by TPPs under PSD2 need to be aware of the security risks. Whereas customers placed their faith in decades-old institutions with a long history of security, they will now be transferring that same trust to lesser-known third-party providers that don’t have a long track record of combating fraud. Antifraud systems of banks will have less data input to train computer models and spot fraud in real time as their customers’ financial data will spread across multiple companies. While customers are now more aware of phishing techniques that cybercriminals used in the past, malicious actors will get new opportunities to trick banking customers. Cybercriminals could pretend to be the FinTech companies working with banks, and new phishing schemes are expected to emerge.

Additionally, the regulators are yet to establish effective methods of monitoring for the increasing number of smaller but significant players. This could reduce overall levels of compliance and make the market vulnerable to money launderers and fraudsters ([Hask]).

Transaction fraud risk

The market changes that we anticipate as a result of PSD2 will likely create new opportunities for fraud because banks will be required to open up their infrastructure and allow third-party providers access to customer account information. This will impact the visibility of banks when it comes to end-to-end transaction monitoring and will inevitably affect their ability to prevent and detect fraudulent transactions.

While the objective is to allow innovation and development of the payment services industry, the growing concern is that this provides criminals with possibilities to commit fraud and to launder money.

Three key fraud risks, as highlighted by the Anti Money Laundering Center (AMLC) ([Lamm17]) are:

• potentially unreliable and criminal TPPs,
• reduced fraud detection, and
• misuse and phishing of data.

The first risk to consider is that of potentially unreliable and criminal TPPs. The entry into force of the PSD2 may lead to an increase in both local and foreign TPPs that are active on the Dutch payment market. If direct access is allowed, the ASPSP is also unable to verify if the TPP actually executes the transaction in accordance with the wishes of the payment service user. Furthermore, malicious persons who aim to commit large-scale (identity) fraud, can set up a TPP themselves to facilitate fraudulent payments. Customers may interact with these fraudulent TPPs e.g. by entering their details on fake websites or mobile payment apps. The criminal can then use this information to access information about the customer and/or make payments in the name of this customer.

The second key risk to consider is that of reduced fraud detection. PSD2 opens the payment market for new entrants who may not have gained any experience with compliance and fraud detection yet. There is a growing trend to accelerate payment transactions via instant payments, which also makes an accelerated cash-out possible. As the risk that fraud transactions are conducted successfully increases, so does the importance of adequate fraud detection in relation to ASPSPs. Traditional financial organizations have so far enjoyed a bilateral relationship with their customers, which will change as TPPs enter the market with new services. PSD2 is bringing higher transaction volume for banks, and more demand from customers for mobile payments and quicker transactions. Those increases result in more pressure being put on fraud detection systems — which, in turn, provide obvious opportunity for businesses that sell fraud prevention technology. The window for investigations will be significantly reduced and banks will need to rely on automation and advanced analytics to mitigate the increased fraud risk ([PYMN18]).

The third risk to consider is the misuse and phishing of data. As outlined above, TPPs may be used as a way to unethically obtain confidential information, which could then be used to facilitate fraudulent transactions. For example, with PSD2 and the dynamic linking of authentication codes to the payment transaction details for remote transactions, phishing of authentication codes may become redundant while the phishing of activation codes for mobile payment /authentication apps could become the new target ([EPC19]).

While the introduction of PSD2 facilitates the innovation of the payments sector, it poses key privacy, security and transaction fraud risks. The next section explores the considerations concerning mitigating these risks.

Mitigation of risks

While PSD2 is a directive brought into effect to stimulate innovation and development within the Payments sector, a number of risks arising as a result have also been identified. The following should be considered in order to reduce the risk of transacting under PSD2 regulation to an acceptable level.

To protect customers, the identified risks need to be appropriately mitigated through sound operational risk management practices by all the players involved (i.e. banks and third parties) that address the security, business continuity and robustness of operations, both in the internal systems of the different parties as well as in the transmission or communication between them. This is particularly challenging in the case of third-party players rather than regulated financial institutions, who often lack the risk management frameworks that are common practice in the banking sector, with detailed policies, procedures and internal and external controls. Financial institutions should develop and document an information security policy that should define the high-level principles and rules to protect the confidentiality, integrity and availability of financial institutions’ and their customers’ data and information ([Carr18]) .

This policy is identified for PSPs in the security policy document to be adopted in accordance with Article 5(1)(j) of Directive (EU) 2015/2366. Based on the security policy information, financial institutions should establish and implement security measures to mitigate the information and communication technology and security risks that they are exposed to. These measures should include policies and controls in place over change management, logical security, physical security, operations security, security monitoring, information security reviews, assessment and testing, information security training and awareness and incident and problem management ([JTFP19]).

PSPs are expected to develop a security policy that thoroughly describes the measures and process that they have in place for the purposes of protecting customers against fraud. PSPs are expected to implement SCA processes for customers accessing their accounts online, initiating electronic payments or carrying out transactions through remote channels. As these activities have a high degree of risks, the PSD2 mandates PSPs to implement appropriate security processes to reduce the incidence of risk. Adopting appropriate SCA processes will promote confidentiality of users and assure the integrity of communication between participants regarding the transactions taking place on any particular platform ([Adey19]).

The implementation of PSD2 will contribute to building new relationships and data partnerships between financial institutions, which helps protect customers interests and improve transactional oversight. To capitalize on the vast amounts of data being channeled through PISPs and AISPs, banks must, however, invest in technology that finds the patterns that indicate crime. PSPs need to share transaction data and intelligence through a central hub that is underpinned by the necessary legal permissions and security to ensure compliance with GDPR. The risk of attack can be mitigated by following a sound API architectural approach, one that integrates security requirements and tools into the API itself. By adding more layers of fraud protection and authentication to APIs, banks could potentially integrate features like access control and threat detection directly into data-sharing offerings, allowing them to be proactive, rather than reactive, when it comes to securing APIs.

All the involved parties such as banks and TPPs need to work in creating a risk tolerant control framework and implementing the control objectives from the RTS guidelines and having specific payment related control activities. The banks and TPPs should coordinate with each other and work on this together to standardize the approach and methodology and discuss the smoothening of the overall process for the consumers with their market competitors.

Conclusion

PSD2 has been put in place in order to stimulate the payments industry creating innovation and broadening the market for payment service providers. As the services of TPP relies on use of sensitive personal and financial data, it opens up the market to a greater number of competitors as well as being heavily reliant on the IT infrastructure of several parties, a number of risks have been identified. Whilst these risks have been identified, so have a number of mitigating measures to reduce the overall operational risks around privacy, security and transaction and fraud risk to an acceptable level. Careful consideration however should be taken by all parties involved in payments services. Further, the regulators will take an active role to ensure a safe and secure payment landscape as part of the mitigation of risks identified in the market through the requirement of certain controls that should be in place for licensed organizations. Due to the dynamic nature of this industry and rapid development of technology, we can expect the landscape of services, and therefore the associated risks, to also develop at a rapid pace. With robust risk management strategies in place, there is an opportunity for payment services community to revolutionize the industry and provide a wide range of innovative payment products and services.