BaFin - Navigation & Service

Erscheinung:16.06.2014 Dr. Josef Kokert, Dr. Markus Held / BaFin section for IT infrastructure of banks

Payment Services Directive II: Risks and serious consequences for users and banks

The 2007 European Payment Services Directive (PSD) is currently being revised. The PSD governs payments within the European Union, providing the foundation for the EU-wide single market for payments.

In particular, PSD II aims to regulate new third party payment service providers (see definition of payment service provider - PSP)1 and thus support European economic growth. However, in their current form, the proposed rules are complex and their entry into force would have far-reaching consequences. This article examines these consequences, particularly the implications for users and the banking industry.

Status of the legislative process

On 3 April 2014, the European Parliament adopted amendments to the revised Payment Services Directive (PSD II). The amended version is now being reviewed by the Committee on Economic and Monetary Affairs. Based on the outcome, the Committee of Member States’ Permanent Representatives will prepare the meeting of the Council, which must also approve PSD II before it can enter into force.

Even in the 1990s, some products were still unavailable in shops in parts of Germany. In rural areas, just asking for an English-language book was sometimes met with incomprehension. Today, products can be ordered quickly and simply online from anywhere and deliveries are made across borders. According to the German Retail Association (Handelsverband Deutschland) online retail sales increased from €14.5 billion in 2005 to €38.7 billion in 2014, with annual growth rates of between 8% and 17%. It is now hard to imagine life without Internet shopping. As a result, there is also demand for simple and secure online payment processes. Merchants want to receive payment immediately, while customers want their goods without delay.

Different payment methods

A variety of Internet payment services are offered to meet these needs, (see also “Internet payment methods”). These include the provision of payment accounts for merchants and customers (e.g. Paypal), credit card solutions (e.g. 3D-Secure), direct debit-based systems (e.g. payments on Amazon), the redirection of customers to a bank website (e.g. giropay, iDeal), or entry of the customer’s PIN and TAN for online banking and the forwarding of the payment order to their account servicing PSP (e.g. SofortÜberweisung).

These methods currently expose customers, merchants and the customers’ banks to various risks. The extent to which they are regulated also differs. For example, Paypal has a European banking licence, while giropay has contractual agreements with banks and SofortÜberweisung generally has no legal relationship with the bank that issued the PINs and TANs.

European Commission: legal vacuum

According to the European Commission there is a “legal vacuum for certain newly emerged Internet service providers, such as third party providers offering online banking based payment initiation”. It considers that “these services represent a viable and often cheaper payment alternative to card payments, attractive also for consumers who do not dispose of cards”. In its view: “The legal vacuum risks impeding innovation and appropriate market access conditions.”2

The European Commission therefore provides in the amended Payment Services Directive (PSD II) for the introduction of new payment services by third party payment providers (TPPs). TPPs use the payment infrastructures of the already regulated payment service providers, which are referred to in PSD II as “account servicing payment service providers”, on behalf of customers. The proposal requires account servicing PSPs to grant TPPs access to the IT systems they use for online banking, subject to certain conditions.

The rules on TPPs proposed by the European Commission allow for business models that could, depending on their technical configuration, pose certain risks for customers and account servicing PSPs. In particular, the proposed technical arrangements covering how TPPs can access bank data should be viewed critically. The European Central Bank (ECB) has already drawn attention to this issue.

Definition: Payment service provider (PSP)

Under section 1 (1) of the Payment Services Supervision Act (ZahlungsdiensteaufsichtsgesetzZAG), payment service providers are

  1. credit institutions within the meaning of Article 4 (1) of the Capital Requirements Regulation (CRR) which are entitled to do business in Germany,
  2. e-money institutions within the meaning of Article 1 (1b) and Article 2 (1) of the E-Money Directive,
  3. the Federation, the Länder, the local authorities and local authority associations, and indirect federal and Länder administrative bodies unless they exercise sovereign power,
  4. the European Central Bank, the Deutsche Bundesbank and other central banks in the European Union or the other signatories to the Agreement on the European Economic Area if they are not acting in their capacity as a monetary authority or other public authority, and
  5. enterprises that provide payment services either commercially or on a scale that requires a commercially organised business undertaking without falling under numbers 1 to 4 (payment institutions).

Third party payment service providers


PSD II distinguishes between payment initiation services and account information services provided by TPPs. Payment initiation services allow users to directly initiate payment over the Internet when making an online transaction. Under the business model of some service providers, customers are redirected from the e-merchant to the third party’s website. The third party then accesses the customer’s payment account with the customer’s account servicing PSP. After payment has been initiated and the account information (e.g. transactions) has been checked, the third party sends the e-merchant a message confirming whether payment has been made. Once payment is confirmed, the merchant immediately proceeds with the dispatch of the goods.

Account information services allow users to access information about accounts they hold with different banks and payment institutions. To this end, the TPP is given access to the relevant account data. Users do not have to obtain this information by opening their various online banking accounts individually. Instead, the information is collated by a single provider and is available at a glance.

Strong authentication

The issue of authentication is a major aspect of online payment security. In this case, authentication means unequivocally proving that a specific user – and no one else – has instructed a specific payment to be made. Authentication therefore provides protection against unauthorised payment transactions.

Article 4 (22) of PSD II describes the strong authentication procedure. According to this provision, strong customer authentication requires two or more elements that are categorised as:

  1. Possession – something only the user possesses (e.g. a chipTAN device)
  2. Knowledge – something only the user knows (e.g. password or PIN)
  3. Inherence – a characteristic of the customer (e.g. retina or finger print) that can be unequivocally attributed to the customer.

The elements must be selected in such a way that the theft or circumvention of one element will not affect the other. In addition, at least one element must not be capable of being easily compromised via the Internet. During transfer, the authentication data must be protected by encryption.

This rule is in line with the definition of strong authentication adopted by the European Forum on the Security of Retail Payments, a joint working group of European financial supervisory authorities and central banks, in its “Recommendations for the security of Internet payments”. The Forum considers procedures in which one of the two selected elements can become known to a third party to be weak.

This definition takes into account fundamental principles of IT security. Operators of applications or IT systems must ensure in an effective manner that they can only be accessed by the relevant persons. In online banking, access rights are generally granted to a specific individual by issuing a PIN.

Authentication when TPPs are involved

Payment initiation services currently apply the following authentication procedure (see Figure 1):

  1. On the e-merchant’s screen the customer opens a separate window with a payment transfer form, which redirects the customer from the merchant to the TPP. The form contains the information that is already known, such as the name of the person making the payment, the payment recipient and the purpose of the transaction.
  2. The customer enters the IBAN and, if applicable, BIC of their account servicing PSP and their confidential authentication data for online banking (PIN and TAN).
  3. The TPP uses the authentication data to gain access to the bank’s online banking service.
  4. At the same time, the TPP checks the account balance.
  5. The TPP informs the user’s transaction partner whether they can expect to receive payment.

Figure 1: Authentication procedure under PSD II

Figure 1: Authentication procedure under PSD II

Authentication procedure under PSD II BaFin Figure 1: Authentication procedure under PSD II

PSD II specifies that TPPs must authenticate themselves to the account servicing PSP. Customers are not required to authenticate themselves to TPPs.

Weakened authentication

The sharing of the PIN and TAN issued by the account servicing PSP to its customer is marked with a lightning bolt in Figure 1 because this weakens the authentication process. The procedure shown does not correspond to the PSD definition of strong authentication, as some of the account access details are provided to third parties.

Under the current version of the PSD, the payment service users (payers), such as bank customers, must protect these details from unauthorised access. This obligation is weakened in PSD II in that Articles 61 and 62 explicitly allow account access information to be shared with other supervised PSPs. However, PSD II forbids TPPs from saving authentication data issued by account servicing PSPs on mass storage media. In addition, it requires TPPs to prevent other parties from accessing this data.

Man-in-the-middle attacks

However, cases where TPPs are hacked are still problematic, as this can render the above measures ineffective. If the TPP is bypassed or does not authenticate itself to the account servicing PSP due to a malfunction, it is still possible for a transfer to be initiated or the account to be viewed. In a man-in-the-middle attack, the attacker intervenes between the two communicating parties (customer – TPP/merchant) and uses its system to take full control of the data transferred between the customer and the TPP or merchant. The attacker can view and manipulate the information at will, fooling the victims into believing they are communicating with each other. Since customers are redirected to a TPP’s website by the merchant’s website, merchants and TPPs are attractive targets for man-in-the-middle attacks (see Figure 2).

Figure 2: Man-in-the-middle attack

Figure 2: Man-in-the-middle attack

Man-in-the-middle attack BaFin Figure 2: Man-in-the-middle attack

Authentication of the TPP to the bank does not make the process more secure, because if hackers obtain the PIN and TAN by manipulating the TPP or merchant, they can use these to authenticate themselves to the bank. If merchants or TPPs are hacked, neither the bank nor the customer has a means of finding out.

Currently, the only practicable way of making the process more secure is for a new TAN to be generated dynamically for each transaction to be initiated, as in the chipTAN procedure, for example. However, even here, the authentication procedure is weakened to the extent that effectively only one element remains.

Social engineering and phishing attacks

The risk of social engineering and phishing attacks is also increasing. In these attacks, customers are directed – by a fraudulent e-mail, for example – to a website that looks the same as that of a legitimate PSP. This allows attackers to influence customers to initiate payments that they have no desire to make. The only effective protection against social engineering is to educate customers as a matter of urgency that they should only enter their authentication data on a website that has been previously agreed with the company that issued the authentication data. The Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik) also stresses this point (only available in German). However, it is precisely this protection that is jeopardised by sharing authentication data with TPPs. If online banking authentication credentials are shared, neither the customer nor the account servicing PSP is able to differentiate between TPPs, payers, or criminals.

In addition, the PIN grants full read access to the online account. In attacks where the attacker wishes to view the confidential account data of as many bank customers as possible, the attacker merely has to hack the website of the merchant or TPP. Online banking clients and apps can also be hacked using malware or by manipulating distribution channels. Unlike TPPs, users operate such software in IT systems to which they themselves have direct physical access. The user is personally responsible for the security of their own PC or smartphone.

User protection

The authentication procedure provided for in PSD II is intended to be practicable. However, this comes at a high price, as the procedure is insecure and would seriously threaten the traceability of the online banking transactions of several thousand European banks, thus undermining a fundamental objective of IT security. These consequences would affect users and banks alike.

In consideration of this known issue, PSD II provides for additional precautions and sets out a differentiated liability regime to cushion the impact on users. This involves numerous rules and exemptions, which are in some cases so convoluted that it is difficult for users to tell what protections and rights they enjoy. In view of this, it is welcome news that the Commission plans to publish a guidance notice that will inform users of their rights and obligations under PSD II in a clear and readily understandable manner, within two years of the Directive’s entry into force.

Account holders’ rights

What rights do account holders have if they discover an unauthorised payment from their account? In accordance with PSD II, they should immediately notify the account servicing PSP and request rectification. The account servicing PSP will then use log files to check whether the payment transaction was authorised by means of the PIN and TAN procedure. If a hacker has stolen personalised security credentials without being detected (e.g. through a man-in-the-middle attack), the following scenario would apply:

  1. The account servicing PSP would maintain that the payment was authorised, as it is registered as such in the log files. This is already the case today when hackers steal online banking data.
  2. The account holder may claim that he or she recently made a purchase in an online shop and initiated the payment via a TPP. He or she will thus state that this payment was not executed.
  3. The account servicing PSP will now contact the TPP. However, the TPP will disclaim any liability, as it did not initiate system access and therefore has no records.
  4. It is now a matter of the account holder’s word against the account servicing PSP’s records. There is already extensive case law on hacker attacks in the area of online banking, according to which either the account servicing bank or the account holder is liable depending on who breached which obligations of care.

In accordance with Article 64 (2) of PSD II, the above argument put forward by the account servicing PSP is not sufficient. It must provide further evidence for its claim. However, it is not in the position to do so, as it has access neither to the payer’s computer nor to the e-merchant’s IT system.

Under PSD II, the account holder is entitled to have the amount reimbursed by the account servicing PSP within 24 hours of providing notification. Thus, at first glance, account holders are protected by PSD II. If, however, the payment transaction was initiated through the use of a lost or stolen payment instrument, such as PINs and TANs, and the loss was identifiable by the user, the user can be held liable for up to €50. The user is thus exposed to the risk of Internet fraud up to this amount. In the current PSD, users are liable for €150. In practice, account servicing banks have generally not required customers to share the costs of such claims due to different contractual agreements or as a gesture of goodwill.

Intent and gross negligence

By contrast, users are liable for all losses relating to unauthorised payment transactions if these are incurred through intentional or grossly negligent failure to comply with one or more of the obligations set out in Article 61 of PSD II.3 These obligations include compliance with the objective terms governing the issue and use of the payment instrument (e.g. PINs and TANs). It is possible that account servicing PSPs could in future draft the terms of use for personalised security credentials in such a way that they are able to demonstrate more easily that users have breached their obligations.

Customers will in turn attempt to prevent such proof being provided. Disputes are inevitable, as has been demonstrated by similar online banking cases in recent years. If the losses borne by the account servicing PSPs exceed their risk budgets on an ongoing basis, they will have to react and adapt their pricing model at the customers’ expense. This problem exists irrespective of the use of a TPP. However, if the proposed Directive remains unchanged on this point, it is possible that Internet fraud will increase due to the authorisation of TPPs and the permission to share PIN and TAN details with TPPs outside of the websites of account servicing PSPs. The higher losses will ultimately have to be borne by the user or the account servicing bank.

Liability

The involvement of a TPP in an unauthorised payment transaction raises the question of which of the two payment service providers is liable. According to PSD II, here, too, the account servicing PSP must refund the payer the amount of the unauthorised payment transaction. The TPP is obliged to compensate the account servicing PSP for “reasonable costs” incurred in connection with the reimbursement of the payer, as well as the amount of the unauthorised payment transaction, within one working day, unless it is able to prove that it was not responsible for the unauthorised payment transaction. The burden of proof thus lies with the TPP.

However, it will hardly ever be possible to provide such proof in cases of Internet fraud. The account servicing PSP therefore depends on the TPP being in a position to pay the compensation. The current version of PSD II provides for a minimum capital requirement of €50,000 for TPPs. It is questionable whether this liability base is sufficient given that Internet fraud is on the increase and hackers are becoming more and more professional. It is likely that account servicing PSPs will be exposed to greater legal and operational risk.

One way that PSD II could resolve this problem is by only allowing TPPs to initiate payment transactions in the Single Euro Payments Area (SEPA) and by giving account servicing PSPs a right of recall in respect of all PSPs approved within the SEPA if a user claims that an unauthorised payment has been made.

Sharing of personalised security credentials

The sharing of personalised security credentials, such as PINs and TANs, with TPPs raises a security issue for account servicing PSPs. To solve this problem, PSD II provides for the European Banking Authority (EBA) to establish common, open regulatory technical standards on communication by account servicing PSPs and TPPs. In particular, these standards are intended to govern how TPPs authenticate themselves to account servicing PSPs and how account servicing PSPs notify and inform TPPs of payment orders and account balances. The PSD does not provide any concrete details on the design of these regulatory standards although this will be crucial.

The ECB and the European Forum on the Security of Retail Payments have made proposals that would allow TPPs to operate without authentication information being passed on. In its opinion on the proposed PSD II, the ECB rightly points out that it is a core principle of IT security not to share authentication data with third parties. Like the Forum, the ECB instead proposes the development of a standardised interface, which could be based on two different procedures (see figure 3):

  • TPPs would be able to directly initiate payments and receive a message confirming successful payment through the standardised interface. They would receive the customer’s payment order through their own authentication mechanisms. This is similar to an expanded version of the direct debit process.
  • TPPs would be able to prepare a payment and then forward the user to the account servicing PSP’s website via HTTP redirect. This means that the TPP would send a message to the customer’s web browser, prompting them to open the account servicing PSP’s website. The process would be made clear to the customer by their web browser. The customer would then provide authentication and authorise the payment directly on the account servicing PSP’s website.

In neither example would the authentication data issued by the account servicing PSP be shared with the TPP.

Figure 3: Solution proposed by the ECB

Figure 3: Solution proposed by the ECB

Solution proposed by the ECB BaFin Figure 3: Solution proposed by the ECB

The ECB’s proposal to create a standardised interface, which would allow the unequivocal authentication of all parties involved, would make it possible to resolve the liability issue.

Further consequences for account servicing PSPs

The current version of PSD II also has further consequences. In addition to the disadvantages of the liability regime for account servicing PSPs, PSD II would force account servicing PSPs to provide IT infrastructures and account data to TPPs free of charge. The data has an intrinsic value as it enables deep insights into customer behaviour. If TPPs are given access to the account data, they could be tempted to capitalise on it. PSD II prevents this in that the TPP only receives information from the account servicing PSP on whether sufficient funds are available in the account. In addition, PSD II forbids the use of the account data for purposes other than those instructed by the customer.

Account information services, which we have not yet examined in detail in this article, also involve risks and costs. Risks relate in particular to data confidentiality, while costs are incurred to retrieve the data itself. Consequently, a standardised interface enabling efficient and secure data retrieval and subscription to notifications would be advantageous for all sides. The main focus should be minimising the need to share data. Data could also be aggregated on the customer’s device for many practical applications, without the need of transmitting it to the TPP.

Significant need for improvement

There is a significant need for improvement with regard to the issues of authentication and liability. Better, more secure online payments would benefit European consumers, merchants and, ultimately, payment service providers. However, this will fail if technical issues are not thoroughly resolved.

Footnotes

1) The terms account servicing payment service provider (PSP), credit institution and bank are used synonymously in this article.

2) See footnote 1 of PSD II.

3) The European Banking Authority (EBA) is to issue guidelines precisely defining the term “gross negligence” within 12 months of the Directive’s entry into force.

Additional information

Did you find this article helpful?

We appreciate your feedback

Your feedback helps us to continuously improve the website and to keep it up to date. If you have any questions and would like us to contact you, please use our contact form. Please send any disclosures about actual or suspected violations of supervisory provisions to our contact point for whistleblowers.

We appreciate your feedback

* Mandatory field