Primary tabs

Deutsche Bank AG

In principle Deutsche Bank (DB) agrees with the EBA’s reasoning in chapter 1, but the language is at times too absolute in terms of asking for solutions that entirely rule out residual risk. For example, we would suggest that the wording in Article 1.2 (c) should be changed from “the authentication code cannot be forged”, to “robust systems must be put in place to address the risk of the authentication code being forged” and similarly Article 1.3 (e) “Prevent, detect and block fraudulent payment transactions”, could be altered to “robust risk controls should be put in place to prevent, detect, and block fraudulent transactions”. Since absolute security is not practically achievable, this amendment of language should be considered to balance usability with convenience.

Another concern relates to when payments conducted by Payment Service Users (PSUs) including individuals and corporations via electronic means are captured by PSD2 (and therefore strong customer authentication (SCA) is required). DB is supportive of applying SCA in individual user initiated payments (individuals initiating electronic payments via mobile devices for example), but not all payments by PSUs are appropriate to go through the same authentication process. Payment orders, initiated within a corporates physical premises and intranet, transmitted to the bank in bulk in a fully automated electronic fashion via a bespoke connection between the corporate and Payment Service Provider (PSP) infrastructure, should be exempted from strong customer authentication (discussed in detail in Q4).

We also do not agree with the statement in paragraph 29 of the background, requiring the exclusion of behavioural data as an element of inherence for strong customer authentication. We would argue that no method for strong customer authentication should be excluded a priori by the RTS. The RTS should therefore amend Article 5.1, to allow for future innovation of secure and customer convenient solutions for strong customer authentication. Proposed new text for Article 5.1 would include the italicised text below:
“Devices and software provided to the payer in order to read authentication elements categorized as inherence (i.e. fingerprint, voice, iris, behaviour) characterized by security features including, but not limited to, algorithm specifications, biometric sensor and template protection features ensuring resistance against the risk of sensitive information related to the elements being disclosed to unauthorised parties. These security features shall also guarantee a sufficiently low likelihood of an unauthorized party being authenticated as the legitimate payment service user.”

We would also like to highlight certain scenarios not covered by text in Article 1.3 (e) on fraud detection systems. Fraud detection systems or mechanisms usually evaluate typical customer behaviour, such as by a customer’s profile based on i) transaction history and transaction data; ii) technical session parameters such as IP addresses, user agent (internet browser and geolocation, which can be derived from the IP address); and iii) device parameters such as device identification and malware detection on the customer’s device as outlined in the consultation paper. However, where the payment is initiated by a Payment Initiation Service Provider (PISP) over the internet, in many cases session information such as the customer’s IP address or information regarding the device being used is not available to the Account Servicing PSP (ASPSP).

Currently, when a customer makes a payment over the internet, ASPSPs can usually carry out end-point malware detection to check whether the device is compromised. ASPSPs can also check if the mobile device has been modified via being ‘jail broken’ for iOS devices (where the device is hacked to bypass software restrictions and make tweaks to the operating system) or ‘rooted’ for android devices (allowing a user to have administrator access and replace an entire operating system). This however is not possible if the payment is done via a PISP. This lack of information would lead to reduced capture of fraud in the fraud detection system of the ASPSP.

To avoid this, the RTS should require PISPs to forward such information on the customer to the ASPSP and where applicable to apply software to detect malware on the customer’s device and also make this information available to the ASPSP. We would suggest the information below to be made available by PISPs to ASPSPs to conduct the fraud detection as outlined in Article 1.3 (e). The information includes but is not limited to:

• IP address of the customer;
• User agent (i.e. browser), type, version, language;
• Device identification of the customer device;
• Malware detected on customer device (with a yes/no response);
• Mobile device jail broken or rooted for iOS and Android operating systems, respectively (with yes/no reports respectively).

Further, in Article 2.4 greater clarity is required to define what is meant by a value of the ‘payees of the batch to be considered collectively’. It is unclear whether this is a value defined the user, an automatic hash value or simply the number of the payees.
We agree to the reasoning outlined by the EBA. This is especially relevant when the requirement allows for two separate apps to be employed (i.e. on the same mobile phone) provided that these are independent or segregated.
A principle based approach would be more useful than a prescriptive list of threats against which the authentication elements should be resistant. As previously stated, certain areas of the RTS would benefit from wording changes to reflect that absolute security is unachievable.

In line with comments in the answer to Q1, there is one area in Article 6.1 where the wording could benefit from being softened. We suggest rephrasing from “ensuring that the breach of one of the elements” to “ensuring to extent possible the risk that the breach one of one of the elements”.
We agree with most of EBA's reasoning on the exemptions from the application of strong customer authentication, however we have concerns about the treatment of payments by corporates. In Article 97 (1) of PSD2, strong customer authentication needs to be adopted where the PSU (natural or legal person - Article 4): i) accesses its payment account; ii) initiates an electronic payment transaction; and iii) carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.

Whilst payments conducted between PSPs are excluded from strong customer authentication (Article 3), payments conducted by PSUs such as individuals and corporations via electronic means will be captured by PSD2 (and therefore requiring SCA), which causes concern. We are supportive of applying SCA in individual user initiated payments (i.e. individuals initiating electronic payments via mobile devices), but it is not appropriate to put all payments through the same authentication process.

Specifically, we would propose that Fully-automated File Transfer solutions - where corporate banking systems (for example, SAP) connect straight to a PSP system via a host-to-host connection (described in more detail below) - are exempted from the application of Article 97 of PSD2 (and thus from stringent authentication requirements) for the following reasons:

• The information is exchanged only between a system and another system (therefore the concept of something only the user is, possesses or knows would not apply between machines)
• Where files exchanged are created using electronic forms to capture payment data from individual users within a corporate; for example, the screens, processes and entitlement frameworks to do so reside under the full responsibility and within the protected environment/infrastructure (i.e. physical premises and intranet) of the corporate and are thus not exposed over the internet.
• Secure communication with Transport Layer Encryption (using SSL/TLS based protocol with client authentication enabled) and Data Encryption (with different Encryption Formats like PGP, SMIME and Encryption Algorithms like TripleDES/AES) as part of a unique corporate seal ensures the highest possible security between the corporate and the PSP infrastructure and therefore the possibility of any associated risk is low.

Article 8 contains a number of payment threshold amounts, below which strong customer authentication is to be exempted. These should be removed and the thresholds replaced new wording stating, “the amount, if any, to be determined by ASPSPs according to transaction analysis based risk management”.

Further, the ASPSP should be able to disapply strong customer authentication for login purposes when agreed with the customer. If however, activities such as payments are to be carried out, 2-factor authentication could be required. This is discussed in Article 8.1(a) (i) and (ii). Note that we consider Article 8.1 to refer to Account Information Service Providers (AISPs), and so for the avoidance of doubt, all references to “payers” should be changed to “PSUs”.

We find Article 8.2 (c) too restrictive as currently drafted. Similar to the EBA final guidelines on the security of internet payments (title II, paragraph 7.1), if the payee’s account is held by the payer’s ASPSP (i.e. ‘on-us’ payments, which are payments within the same bank) but the payer and payee are not the same natural or legal person, an exemption of SCA should also be possible.
It should be made explicit that the exemptions to SCA are an option for the PSPs, and not a requirement - i.e. strong customer authentication could always be applied. This is necessary as the RTS does not specify all eventualities possible for which SCA could be exempt, and therefore the EBA should allow it to be applied even in instances where exemptions could otherwise be presumed.

An example of this is Article 8.1 (a) (i), which suggests that PSUs accessing their information online for the first time should have to apply 2-factor authentication. We would propose that this should be optional when done for the first time, to allow for a practical and timely execution of a migration effort. This should allow 1-factor password users to remotely register and activate strong authentication (i.e. via a mobile app) using their existing (1-factor) credentials when setting up 2-factor authentication for the first time. Since the upgrade to 2-factor authentication will be a one off limited action, the risk involved is contained. This comment can also be considered in respect to Article 12b.

Proposed changes to Article 8 in the RTS to reflect this optionality would be:

Article 8.1: Suggested change from “is exempted where” to “can be exempted where”

Article 8.1 (a): Proposed deletion of the line “the application of strong customer authentication shall not be exempted where”, because as outlined above, we believe this should be optional. Based on these changes, we believe two paths are open to EBA. The first is to delete sub-sections (i) and (ii) entirely. The alternative is to amend them as below:

Article 8.1 (a) (i): The point (i) should be relabeled as (b) and we propose inclusion of additional text for clarity, adding the wording in italics “accesses the information of its payment account online, without disclosure of sensitive data, or the” to make it consistent with (a).

Article 8.1 (a) (ii): The point (ii) should be relabeled as (c) and we propose inclusion of additional text for clarity, adding the wording in italics “accesses the information of its payment account online, without disclosure of sensitive data, or the” to make it consistent with (a) and the new (b).

Article 8.1 (b): Would need to be relabeled as (d) accordingly.

Article 8.2: Suggested change from “is exempted where” to “can be exempted where”.
In principle we agree with EBA’s reasoning in chapter 3. The RTS would benefit from further clarification of the following articles to rule out uncertainty:

1) In Article 9.1 (b), it should be clarified that personalised security credentials as well as cryptographic material can be stored in plain text if stored either in a tamper resistant device or in a device which is under the control of the PSU if the device is tamper evident.

2) In Article 9.1 (c), it should be clarified that secret cryptographic material can be stored in a device which is under the control of the PSU if this device is tamper evident.

3) Clarification is required in respect to Article 12 and 13d on what is meant by a ‘secure and trusted environment’. The activation of a mobile app or hardware device would occur in client premises and thus out of a PSP’s control. Article 13a, b, c would already ensure only authorised individuals can perform the registration action.

Further, payment initiation via a PISP bears a significant risk of fraud and information security in the context of commercial payments from corporates. For high value and urgent payments that go through machine-to-machine connections via SAP for example (as outlined in Q4), risks are contained. If these payments go through PISPs however, the RTS should include wording for national competent authorities to limit the asymmetric treatment of ASPSPs and PISPs for insurance purposes. This is to compensate ASPSPs for their risk, as they are required to process refunds to PSUs within 24 hours in accordance with PSD2 Level 1 requirements (Article 73), but PISPs do not have a defined time limit. A solution would be for EBA to align the time limits to ensure as much consistency as possible, and propose that PISPs need to compensate the ASPSP “within one week at the most”.
In principle we support the EBA's reasoning on the requirements to set out a harmonised framework that aims to ensure an appropriate level of security, with focus on PSUs and PSPs.

We strongly recommend communication via a common pan-European Third Party Payment Provider (TPP) interface - also known as open API (publically available application programming interface) - to avoid fragmentation across Member States. Industry initiatives have already begun development of open-API standards (for example in the UK) and we propose that the EBA and national competent authorities support and facilitate a single open API standard.

For the purpose of identification of AISPs and PISPs, a pan-European online repository would be required for ASPSPs to check online that an AISP/PISP has a valid license or not (including all legal ‘company data’). This EBA database must be legally binding and updated on real-time basis so that ASPSPs can rely on it.
For payment products based on ISO 20022 like SEPA Credit Transfers, we do not see a technical constraint that would prevent the use of ISO 20022 elements, components or approved message definitions elements for the communication between TPPs and the ASPSP.
As mentioned in Q7, we strongly support a unique pan-European interface (an open API) for TPPs. The TPP will need to identify themselves via a certificate and therefore DB also supports a pan-European standard for the use of qualified certificates under the e-IDAS regulation. We encourage national competent authorities to support the use of e-IDAS for the purpose of identification between PSPs.

We would like to highlight that for the purpose of identification in Article 20.1, “website authentication” is not the correct functionality. The use of “electronic seals” would be more appropriate - also part of the e-IDAS regulation.

Additional information required in Article 20.2 and 20.3 is not specified in e-IDAS and whilst they are usually not part of certificates, this information is held in the systems of the entities. We are not opposed to this solution, but strongly recommend that the RTS includes wording for national competent authorities to work with the industry, to create a single specification for a common pan-European certificate, with data listed in Articles 20.2 and 20.3.

Our understanding is that these certificates are used for identification between PSPs only. Article 20 should not relate to PSUs.
In the current setup, the frequency is acceptable but the limitation is not appropriate for future digital solutions. With the implementation of SEPA Instant Payment or Robo / Algo-Traders for example, the demand for real-time or at least near-time updates of account balances will rise. Therefore we consider the proposed limitation of twice a day as not future-proof. If the PSU allows the AISP to request information when the PSU is not actively requesting such information, based on agreement between the PSU, AISP and the ASPSP there should be flexibility to choose between two times per day or enable a more frequent synchronisation at the ASPSP interface.

Furthermore, a clear articulation is required from EBA on how an ASPSP can verify the identity of the PSU when an additional account information request is made. It is unclear how it would be known if an AISP was acting on a direct customer request (where the customer is actively requesting the account data from a computer or mobile device) or whether the request is generated automatically from the AISP to maintain up to date information and thereby restricted to twice a day. The RTS should set out the authentication required in both these scenarios.
[Credit institution"]"
[Execution of payment transactions"]"
Deutsche Bank AG