Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
We assume that ‘maximum time’ here applies to the maximum time of inactivity of the payer.
Article 1.3(b)
Although we agree with this principle in general, it is only relevant in situations where more than one single security credential is involved. In use cases where only a single security credential is entered, the application or device should be allowed to respond that this security code is incorrect. An example of this is in cards payments, where it is currently common practice that a message ‘wrong PIN’ can be given on the terminal display, which is well acceptable in our opinion. We therefore suggest to add an exclusion to article 1.3(b) for cases where one security credential is involved.
Article 1.3(e) – Rationale 22(c)
Regarding the information required by these mechanisms, we would welcome a clear statement in the RTS on the role of the AISP / PISP in providing the information, in models where an AISP or PISP is involved in the strong customer authentication process. In models where the ASPSP allows the AISP / PISP to collect the credentials, the information forwarded to the ASPSP should be such, that the ASPSP is able to perform the transaction monitoring as required by this Article. See also our response on Article 22.4 (Question 7).
Article 2.4 – Rationale 27
In the context of this Article, we distinguish between a “batch” of payments (single debit payment / multiple credit payments; mostly used in corporate environments) and a “set” of payments (multiple debit payments / multiple credit payments; mostly used in retail banking). It is not clear whether Article 2.4 covers for both cases. We suggest to make the text unambiguous on the concept of “batch” and the required procedure for authorisation. In case of a “batch”, the customer should not be required to check every individual transaction in the online environment before authorisation.
Article 5 – Rationale 29
We agree with EBA’s view expressed in Rationale 29 on the use of behavioural data. However, we would expect a stricter wording in Article 5, in order to exclude the use of behavioural data as a standalone inherence element. Our main reasoning is that one should distinguish between behavioural data in general and behavioural biometrics (such as a person's handwritten signature, which can be analysed since exact handwriting style is unique to everyone. It is possible that devices analyse the speed, style and exact position on the screen of someone signing their name, by using a stylus) where the latter can very well be used as an inherence element.
Article 6.2
Following a risk-based approach, we believe that a bank can not only rely on mitigating “the risk of the multi-purpose device being compromised”. Consumer multi-purpose devices should be considered largely outside the scope of control of a bank. Therefore we suggest to adapt this sentence part to “the consequences of the multi-purpose device being compromised.”
Article 6.3(a)
We suggest to avoid the use of the term ‘trusted execution environment’, since this is also a defined term (with capital letters: Trusted Execution Environment, or TEE) for a future Global Platform standard. Since this standard is not fully available yet and not all smartphones are capable of implementing a TEE, we think the reference to TEE as a standard is both unnecessary and too far-fetched. We suggest to replace the words ‘separated trusted' with “secured”.
Rationale 19a
We welcome the interpretation in this Rationale, since it is important in maintaining the security of the payment chain, in particular the addition that “the authentication procedure will remain fully in the sphere of competence of the ASPSP”.
We also interpret this such that as a consequence of the above, the PISP / AISP is not allowed to store the personalised security credentials issued by an ASPSP without a contract between the PISP / AISP and the ASPSP, since the use of these personalised security credentials must be secured with a credential mechanism issued by the PISP / AISP.
We would welcome these interpretations to be added in the text of the Regulation.
Rationale 25
We think it confusing here to use the term ‘tamper-resistant’ in relation to the authentication procedure, since the term is normally used in the context of devices. We suggest to change the text to “the authentication procedure is adequately protected against compromise”. See also our reaction on Question 6 / Article 9.
It is however crucial that the ASPSP – being ultimately responsible for the correct, timely and safe execution of the payment service – has flexibility in determining the measures to assure the integrity of the payment data (amount and payee) towards the PSU. The viewpoint stated in the RTS that this assurance can only be established through an independent or segregated channel, app or device is too restricting; it would for instance limit the opportunity for innovative payment solutions in the field of ‘seamless payments’, where authentication of the payer is done early in the shopping process, and authorisation is done at the moment of payment.
Moreover, fraud figures for online and mobile banking in the Netherlands have shown a sharply decreasing trend in previous years. Our members clearly state that this decline results mainly from improved risk monitoring on transactions, and not so much from strengthening the authentication procedure for payment service users.
Article 2.2(b) – Rationale 26
Article 2.2(b) describes the requirement that the channel, device or app for displaying the amount and payee shall be independent or segregated from the channel, device or app for initiating the payment transaction. To our interpretation, the current wording of this Article would exclude the use of a mobile banking app using a single 5-digit pin code for authorisation. This is currently a common (and safe) practice in the various mobile banking apps as provided by Dutch consumer banks and broadly used by their customers.
Our concerns are regarding simple credit transfers, where the PSU initiates the payment from a mobile app, and then authorises that payment in the same app on the same device. We tend to think of this process as being performed over a single channel. In our response to the Discussion Paper (Question 4 and 6) we have commented on the mechanisms that are applied in securing the mobile banking channel, in a way that the mobile banking apps as mentioned earlier comply with the requirements from SCA, i.e. two-factor authentication and dynamic linking.
We further believe such mechanisms are equally effective in creating an adequately secured and protected environment to display the amount and the account number of the payee, and assuring the integrity of these data towards the PSU, on a single smart phone with a single online banking app. These mechanisms may include, but are not limited to:
- Secure Element (SIM or dedicated chip) for storage of sensitive data, accessible only by PSU and authorized app
- App-separation / sandboxing
- Remote security updates, to prevent or react on possible weaknesses
- Hardening of an app / secure coding
- White-box cryptography
- Device binding (secure activation of an app for use by only one PSU on only one device), based on continually refreshed data elements or challenge/response
- Detection of mobile malware and fraud on the device
- App-store monitoring (for malicious apps)
Besides our expectation as expressed in our response to the Discussion Paper, that the EBA shall take a risk-based approach on this issue, we fail to believe that EBA has the intention to disallow the current form of mobile banking apps as implemented by many Dutch banks and broadly used by millions of their customers. This seemed to be confirmed by EBA during the hearing on 23 September where it was stated that this Article 2.2(b) should not lead to the situation where customers use two mobile devices for mobile payments. We therefore strongly suggest to delete Article 2.2(b).
Alternatively, EBA could amend the text of Article 2.2(b) as follows, such that it better reflects the intentions, i.e. the logic segregation instead of the physical segregation:
“The [add: processing including] channel, device or mobile application [delete: through] [add: with] which the information linking the transaction to a specific amount and a specific payee is displayed shall be [add: logically] independent or segregated from the [add: processing including] channel, device or mobile application used for initiating the electronic payment transaction.”
We assume the requirements from Article 2.2(b) to be fulfilled already in both (i) card-based payments – with displaying amount / payee and initiation done on a single POS terminal – and (ii) iDEAL Mobile payments – with displaying amount / payee and initiation done on a mobile phone. In both cases (i) and (ii), two segregated channels are being used, i.e. 1) the Acquirer for the initiation of the transaction and 2) the Issuer being in control of displaying the amount / payee.
Article 3.1
We would want to read this Article such that the security features are not independent, which means for instance that a longer expiration time can be balanced by one or more other security features in order to “ensuring resistance” as required by this Article.
Article 3.1
It is unclear what is meant by ‘non-repeatable characters’. We suggest to remove these words, since their most likely meaning would already be covered by the term “complexity”.
Article 3.2
With an increase in the number of PSPs involved in a payment transaction – as allowed by PSD2 – we see an increased risk of phishing attacks or other attempts to mislead PSUs to get hold of their credentials. Therefore we suggest to add the following text to this Article: “, specifically via phishing or misleading the PSU regarding their personalised security credentials.”
We tend to assess EBA’s conclusion (in Rationale 54) not to propose exemptions based on a transaction-risk analysis performed by the PSP, as being inconsistent with the liabilities and responsibilities of an ASPSP as laid down in the level 1 text. Those liabilities and responsibilities determine the risks an ASPSP is able or willing to take in any payment transaction. Such a risk-based approach also seems to be supported by the same level 1 text, for instance in Article 98 where it states:
- “ensure an appropriate level of security for payment service users and payment service providers, through the adoption of effective and risk-based requirements” in Article 98.2(a), and
- “exemptions […] shall be based on […] (a) the level of risk involved in the service provided” in Article 98.3.
On this basis, it seems clear to us that risk consideration was intended to be an integral part of the RTS, and, in particular, any exemptions, or situations where PSPs could exclude the use, or application, of the RTS and/or SCA, would incorporate a risk-based analysis. To our assessment, the exhaustive list of exemptions in the current draft RTS inadequately allows for a risk-based assessment / approach by the PSP.
We believe this proposition is further supported by the references to proportionate, risk based security measures at PSD2’s Recitals 91 an 96:
- “(91) Payment service providers are responsible for security measures. Those measures need to be proportionate to the security risks concerned.”
- “(96) The security measures should be compatible with the level of risk involved in the payment service.”
Furthermore, we would like to challenge EBA’s reasoning in Rationale 53, where it states that the requirement of “a consistent application of SCA by all PSPs” finds its ground in Article 66.4(c) and 67.3(b) of PSD2. To our understanding, these two Articles state that an ASPSP is not allowed to discriminate between activities performed through an AISP or PISP and those performed directly by the PSU. Hence, we believe there is insufficient ground in Articles 66.4(c) and 67.3(b) of PSD2 to state that a PSP is not allowed to differentiate to apply SCA, based on a transaction-risk analysis on a per-transaction basis, as long as this is done irrespective of the channel through which the action takes place (via an AISP / PISP or directly by the PSU).
Based on our understanding as formulated above, we advise EBA to make the list of exemptions non-exhaustive and risk-based, since it would not be realistic to us to maintain a list of exemptions that is both suitable for the payment services and their providers currently present in the market, while also for new innovations that are to be expected in this dynamic and changing environment. Furthermore, a fixed list of exemptions does not take account of the large diversity of payment services and the contexts in which these services are provided. Such an approach also introduces uncertainties regarding the legal obedience of current exemptions in existing payment schemes. See our comments with Article 8 below for more specificities.
Article 8.1(a)ii
Choosing the period of one month is an arbitrary one. We do not foresee significant additional issues or threats when extending this to a longer period. We therefore suggest to extend the text with the optional extension of the one-month period by the PSP based on a case-by-case risk-analysis.
Article 8.1(b)
The exemptions in this Article fail to include payment products that currently exist, such as no-CVM (Card Verification Method) debit- or credit card payments under EUR 50 used for paying at toll ways and for parking. We therefore strongly suggest to amend this Article as follows:
(b) the payer initiates a contactless [add: or no-CVM (Card Verification Method)] electronic payment transaction at a point of sale within the limits of both the following conditions:
i. the individual amount of contactless electronic [add: or no-CVM (Card Verification Method)] payment transaction does not exceed the maximum amount of 50 EUR [add: or lower threshold set by the ASPSP or the payer];
ii. the cumulative amount of previous non-remote electronic [add: or no-CVM (Card Verification Method)] payment transactions initiated via the payment instrument offering a contactless [add: or no-CVM (Card Verification Method)] functionality without application of strong customer authentication does not exceed 150 EUR [add: or lower threshold set by the ASPSP or the payer].
Article 8.2(a)
We strongly suggest to add the possibility for ASPSP to add a limit on transaction amount also for trusted beneficiaries.
Article 8.2(d)
Choosing an amount of EUR 10 seems an arbitrary one. We do not foresee significant additional issues or threats when slightly lowering or heightening this amount. We therefore suggest to extend the text with the optional change of the amount (regarding the applicability of this Article) by the PSP based on a case-by-case risk-analysis.
Article 8.2
Notwithstanding the reference to Article 97.2 (PSD2) in Article 8.2, we can only interpret this Article in such a way that the exemptions mentioned in Article 8.2 relate to the entire SCA procedure, and not only to the dynamic linking of amount and payee. We suggest EBA to amend the text of Article 8.2 in order to clarify the ambiguity on the scope of the exemptions.
Important note: all the comments provided above are made under the assumption that the exemptions remain optional for the ASPSPs. We also refer to our reaction on Question 5 in case the exemptions are intended to become mandatory.
As a consequence of a limited and mandatory list of exemptions, we foresee a risk that the average level of security of payment systems and/or their service level is lowered:
- There are specific situations of some of the proposed exemption cases for which it is currently common practice to require application of SCA, however which would not be allowed anymore with these draft RTS. For example, there could be a risk in payment transactions executed between two bank accounts (for example a transaction from a savings account to a current account) of the same legal person (an exemption case in itself), if such a payment transaction is immediately followed by a number of payment transactions to other accounts (to divert the money to fraudsters), since this is a pattern that has been seen with fraudsters.
- In general, a payment transaction for which the exemptions have to be applied, runs the risk to attract fraudsters because they can be quite sure that no further authentication will be required, once they are successful in initiating such a transaction. Nevertheless, such a transaction is probably signaled and marked as suspicious by the ASPSP. However, in case these draft RTS apply, nothing can be done against it, other than to block the transaction, i.e. lowering the service level, which is not a desirable outcome for both the payer and the payee/merchant.
Although we agree in general with the text in this Article, we would encourage a more principle-based approach. With the level of detail of the current text we see a risk of overlooking additional important aspects, such as physical and logical security, procedures for staff, etc. In our view, the current requirements do not ensure the secure storage and use of these credentials. A suggestion could be to refer to the application of technical standards. Standards such as FIPS 140 (cryptography) or ISO 9564 (PIN management) are suitable in this context.
Article 9.1(c)
The requirement of ‘tamper resistancy’ simply can not apply to consumer devices such as smartphones.
Article 13(b)
The words “digitally signed” refer to one specific technology, while we consider other technologies equally effective in ensuring the authenticity of the software delivered by the PSP. Moreover, in order to distribute software through genuine app stores the software must be digitally signed by the provider. We suggest EBA to formulate this requirement more general, by amending the text as follows:
“Mechanisms [add: allowing the payment service user to verify the authenticity of the authentication software delivered] [delete: that the authentication software delivered to the payment services user via the internet has been digitally signed] by the payment services provider”
Article 13(c)i
Our members assess that this requirement should be formulated in a more risk-based manner. In particular with the additional requirement in Article 13(c)ii, it would be sufficient to require:
i. Adequately protect the personalised security credentials, the authentication devices or software against the unauthorised use when delivered through the same channel.
What is meant by “secure bilateral identification” between the payer’s device and payee’s accepting device. Is mutual authentication meant here? This would create incompatibility with EMV card-based payments, which does not require terminal authentication. EMV is a widely accepted industry standard.
Article 17.2
We suggest EBA to add “adequately” before “protected”, since we think the current text is too strictly formulated.
Article 19.2(c)
We have the impression that this Article is only applicable in those models where the ASPSP allows the AISP / PISP to collect the credentials. In cases where credentials are transferred directly by the PSU to the ASPSP this Article is not applicable. If our interpretation is the intended one, then we think the word ‘when’ should be changed into ‘if’.
Article 21.5
Based on this article, is it correct to assume, that Article 16 on audit requirements would also be applicable for the PISP and AISP, in so far they are part of the authentication procedure?
Article 22.1(a) – Rationale 69(d)
In relation to the data exchange, we would suggest that EBA would clarify that the ASPSP shall provide the account information service provider at most with the same information from designated payment accounts and associated payment transactions made available to the payment services user when directly accessing the information online. Therefore this information may not include display of other types of customer transactions.
Furthermore, the use of the word “functionalities” in Rationale 69(d) might involve additional data as well. We therefore suggest to amend the text as follows:
(a) Account information service providers with the same information from designated payment accounts and associated payment transactions made available to the payment service user when directly accessing the information online [add: , limited to the transaction data elements from the interbank exchange and information on the balance], provided that this information does not include display of sensitive payment data;
Article 22.4
Suggest to change the text to:
“… with the same information [delete: requested] [add: collected] from the payment service user …”
This would include for instance geolocation, IP address, etc. to ensure adequate fraud mitigation.
No, we do not see technical constraints that prevent the use of industry standards, as long as these are sufficiently technology-neutral.
We agree with the fact that a Qualified Trust Service Provider (QTSP) could provide the certificates to be used for the identification between PSPs and for website authentication subject to sufficient availability of the appropriate certification authorities on the market. However, in the case of PSP software components installed on any common type device (e.g., tablet, mobile phone), owned by the payer, there is no way to enforce sole usage control over private key credentials by the owning PSP, which renders the certificate based approach completely unsuitable for PSP authentication in such a scenario (no mitigation against PSP impersonation attacks).
Article 20.1
To avoid a monopoly for such qualified trust service providers, we consider EBA to add a provision that sufficient (min. five) trusted service providers are available offering the services mentioned.
However, we are concerned about the amount of data that can be requested. When PSUs are allowed to request for example their full transaction history of the past seven years that would lead to an enormous (and unacceptable) load on the ASPSP’s systems. Therefore we expect that ASPSPs are allowed to limit the amount of data that can be transferred in one request.
Question 1: Do you agree with the EBA’s reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS?
Article 1.3(a)We assume that ‘maximum time’ here applies to the maximum time of inactivity of the payer.
Article 1.3(b)
Although we agree with this principle in general, it is only relevant in situations where more than one single security credential is involved. In use cases where only a single security credential is entered, the application or device should be allowed to respond that this security code is incorrect. An example of this is in cards payments, where it is currently common practice that a message ‘wrong PIN’ can be given on the terminal display, which is well acceptable in our opinion. We therefore suggest to add an exclusion to article 1.3(b) for cases where one security credential is involved.
Article 1.3(e) – Rationale 22(c)
Regarding the information required by these mechanisms, we would welcome a clear statement in the RTS on the role of the AISP / PISP in providing the information, in models where an AISP or PISP is involved in the strong customer authentication process. In models where the ASPSP allows the AISP / PISP to collect the credentials, the information forwarded to the ASPSP should be such, that the ASPSP is able to perform the transaction monitoring as required by this Article. See also our response on Article 22.4 (Question 7).
Article 2.4 – Rationale 27
In the context of this Article, we distinguish between a “batch” of payments (single debit payment / multiple credit payments; mostly used in corporate environments) and a “set” of payments (multiple debit payments / multiple credit payments; mostly used in retail banking). It is not clear whether Article 2.4 covers for both cases. We suggest to make the text unambiguous on the concept of “batch” and the required procedure for authorisation. In case of a “batch”, the customer should not be required to check every individual transaction in the online environment before authorisation.
Article 5 – Rationale 29
We agree with EBA’s view expressed in Rationale 29 on the use of behavioural data. However, we would expect a stricter wording in Article 5, in order to exclude the use of behavioural data as a standalone inherence element. Our main reasoning is that one should distinguish between behavioural data in general and behavioural biometrics (such as a person's handwritten signature, which can be analysed since exact handwriting style is unique to everyone. It is possible that devices analyse the speed, style and exact position on the screen of someone signing their name, by using a stylus) where the latter can very well be used as an inherence element.
Article 6.2
Following a risk-based approach, we believe that a bank can not only rely on mitigating “the risk of the multi-purpose device being compromised”. Consumer multi-purpose devices should be considered largely outside the scope of control of a bank. Therefore we suggest to adapt this sentence part to “the consequences of the multi-purpose device being compromised.”
Article 6.3(a)
We suggest to avoid the use of the term ‘trusted execution environment’, since this is also a defined term (with capital letters: Trusted Execution Environment, or TEE) for a future Global Platform standard. Since this standard is not fully available yet and not all smartphones are capable of implementing a TEE, we think the reference to TEE as a standard is both unnecessary and too far-fetched. We suggest to replace the words ‘separated trusted' with “secured”.
Rationale 19a
We welcome the interpretation in this Rationale, since it is important in maintaining the security of the payment chain, in particular the addition that “the authentication procedure will remain fully in the sphere of competence of the ASPSP”.
We also interpret this such that as a consequence of the above, the PISP / AISP is not allowed to store the personalised security credentials issued by an ASPSP without a contract between the PISP / AISP and the ASPSP, since the use of these personalised security credentials must be secured with a credential mechanism issued by the PISP / AISP.
We would welcome these interpretations to be added in the text of the Regulation.
Rationale 25
We think it confusing here to use the term ‘tamper-resistant’ in relation to the authentication procedure, since the term is normally used in the context of devices. We suggest to change the text to “the authentication procedure is adequately protected against compromise”. See also our reaction on Question 6 / Article 9.
Question 2: In particular, in relation to the “dynamic linking” procedure, do you agree with the EBA’s reasoning that the requirements should remain neutral as to when the “dynamic linking” should take place, under the conditions that the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed is independent or segregated from the channel, mobile application or device used for initiating the payment, as foreseen in Article 2.2 of the draft RTS.
We basically agree with EBA’s reasoning in Rationale 23 assuming that an authentication code can be linked with the specific transaction (re. amount and payee) at a later stage in the authentication procedure. The customer experience is not affected; during normal use, the PSU cannot tell whether the authentication code is calculated based on amount and payee, or not.It is however crucial that the ASPSP – being ultimately responsible for the correct, timely and safe execution of the payment service – has flexibility in determining the measures to assure the integrity of the payment data (amount and payee) towards the PSU. The viewpoint stated in the RTS that this assurance can only be established through an independent or segregated channel, app or device is too restricting; it would for instance limit the opportunity for innovative payment solutions in the field of ‘seamless payments’, where authentication of the payer is done early in the shopping process, and authorisation is done at the moment of payment.
Moreover, fraud figures for online and mobile banking in the Netherlands have shown a sharply decreasing trend in previous years. Our members clearly state that this decline results mainly from improved risk monitoring on transactions, and not so much from strengthening the authentication procedure for payment service users.
Article 2.2(b) – Rationale 26
Article 2.2(b) describes the requirement that the channel, device or app for displaying the amount and payee shall be independent or segregated from the channel, device or app for initiating the payment transaction. To our interpretation, the current wording of this Article would exclude the use of a mobile banking app using a single 5-digit pin code for authorisation. This is currently a common (and safe) practice in the various mobile banking apps as provided by Dutch consumer banks and broadly used by their customers.
Our concerns are regarding simple credit transfers, where the PSU initiates the payment from a mobile app, and then authorises that payment in the same app on the same device. We tend to think of this process as being performed over a single channel. In our response to the Discussion Paper (Question 4 and 6) we have commented on the mechanisms that are applied in securing the mobile banking channel, in a way that the mobile banking apps as mentioned earlier comply with the requirements from SCA, i.e. two-factor authentication and dynamic linking.
We further believe such mechanisms are equally effective in creating an adequately secured and protected environment to display the amount and the account number of the payee, and assuring the integrity of these data towards the PSU, on a single smart phone with a single online banking app. These mechanisms may include, but are not limited to:
- Secure Element (SIM or dedicated chip) for storage of sensitive data, accessible only by PSU and authorized app
- App-separation / sandboxing
- Remote security updates, to prevent or react on possible weaknesses
- Hardening of an app / secure coding
- White-box cryptography
- Device binding (secure activation of an app for use by only one PSU on only one device), based on continually refreshed data elements or challenge/response
- Detection of mobile malware and fraud on the device
- App-store monitoring (for malicious apps)
Besides our expectation as expressed in our response to the Discussion Paper, that the EBA shall take a risk-based approach on this issue, we fail to believe that EBA has the intention to disallow the current form of mobile banking apps as implemented by many Dutch banks and broadly used by millions of their customers. This seemed to be confirmed by EBA during the hearing on 23 September where it was stated that this Article 2.2(b) should not lead to the situation where customers use two mobile devices for mobile payments. We therefore strongly suggest to delete Article 2.2(b).
Alternatively, EBA could amend the text of Article 2.2(b) as follows, such that it better reflects the intentions, i.e. the logic segregation instead of the physical segregation:
“The [add: processing including] channel, device or mobile application [delete: through] [add: with] which the information linking the transaction to a specific amount and a specific payee is displayed shall be [add: logically] independent or segregated from the [add: processing including] channel, device or mobile application used for initiating the electronic payment transaction.”
We assume the requirements from Article 2.2(b) to be fulfilled already in both (i) card-based payments – with displaying amount / payee and initiation done on a single POS terminal – and (ii) iDEAL Mobile payments – with displaying amount / payee and initiation done on a mobile phone. In both cases (i) and (ii), two segregated channels are being used, i.e. 1) the Acquirer for the initiation of the transaction and 2) the Issuer being in control of displaying the amount / payee.
Question 3: In particular, in relation to the protection of authentication elements, are you aware of other threats than the ones identified in articles 3, 4 and 5 of the draft RTS against which authentication elements should be resistant?
We think the current text is sufficient.Article 3.1
We would want to read this Article such that the security features are not independent, which means for instance that a longer expiration time can be balanced by one or more other security features in order to “ensuring resistance” as required by this Article.
Article 3.1
It is unclear what is meant by ‘non-repeatable characters’. We suggest to remove these words, since their most likely meaning would already be covered by the term “complexity”.
Article 3.2
With an increase in the number of PSPs involved in a payment transaction – as allowed by PSD2 – we see an increased risk of phishing attacks or other attempts to mislead PSUs to get hold of their credentials. Therefore we suggest to add the following text to this Article: “, specifically via phishing or misleading the PSU regarding their personalised security credentials.”
Question 4: Do you agree with the EBA’s reasoning on the exemptions from the application of Article 97 on strong customer authentication and on security measures, and the resultant provisions proposed in Chapter 2 of the draft RTS?
Rationale 53 and 54We tend to assess EBA’s conclusion (in Rationale 54) not to propose exemptions based on a transaction-risk analysis performed by the PSP, as being inconsistent with the liabilities and responsibilities of an ASPSP as laid down in the level 1 text. Those liabilities and responsibilities determine the risks an ASPSP is able or willing to take in any payment transaction. Such a risk-based approach also seems to be supported by the same level 1 text, for instance in Article 98 where it states:
- “ensure an appropriate level of security for payment service users and payment service providers, through the adoption of effective and risk-based requirements” in Article 98.2(a), and
- “exemptions […] shall be based on […] (a) the level of risk involved in the service provided” in Article 98.3.
On this basis, it seems clear to us that risk consideration was intended to be an integral part of the RTS, and, in particular, any exemptions, or situations where PSPs could exclude the use, or application, of the RTS and/or SCA, would incorporate a risk-based analysis. To our assessment, the exhaustive list of exemptions in the current draft RTS inadequately allows for a risk-based assessment / approach by the PSP.
We believe this proposition is further supported by the references to proportionate, risk based security measures at PSD2’s Recitals 91 an 96:
- “(91) Payment service providers are responsible for security measures. Those measures need to be proportionate to the security risks concerned.”
- “(96) The security measures should be compatible with the level of risk involved in the payment service.”
Furthermore, we would like to challenge EBA’s reasoning in Rationale 53, where it states that the requirement of “a consistent application of SCA by all PSPs” finds its ground in Article 66.4(c) and 67.3(b) of PSD2. To our understanding, these two Articles state that an ASPSP is not allowed to discriminate between activities performed through an AISP or PISP and those performed directly by the PSU. Hence, we believe there is insufficient ground in Articles 66.4(c) and 67.3(b) of PSD2 to state that a PSP is not allowed to differentiate to apply SCA, based on a transaction-risk analysis on a per-transaction basis, as long as this is done irrespective of the channel through which the action takes place (via an AISP / PISP or directly by the PSU).
Based on our understanding as formulated above, we advise EBA to make the list of exemptions non-exhaustive and risk-based, since it would not be realistic to us to maintain a list of exemptions that is both suitable for the payment services and their providers currently present in the market, while also for new innovations that are to be expected in this dynamic and changing environment. Furthermore, a fixed list of exemptions does not take account of the large diversity of payment services and the contexts in which these services are provided. Such an approach also introduces uncertainties regarding the legal obedience of current exemptions in existing payment schemes. See our comments with Article 8 below for more specificities.
Article 8.1(a)ii
Choosing the period of one month is an arbitrary one. We do not foresee significant additional issues or threats when extending this to a longer period. We therefore suggest to extend the text with the optional extension of the one-month period by the PSP based on a case-by-case risk-analysis.
Article 8.1(b)
The exemptions in this Article fail to include payment products that currently exist, such as no-CVM (Card Verification Method) debit- or credit card payments under EUR 50 used for paying at toll ways and for parking. We therefore strongly suggest to amend this Article as follows:
(b) the payer initiates a contactless [add: or no-CVM (Card Verification Method)] electronic payment transaction at a point of sale within the limits of both the following conditions:
i. the individual amount of contactless electronic [add: or no-CVM (Card Verification Method)] payment transaction does not exceed the maximum amount of 50 EUR [add: or lower threshold set by the ASPSP or the payer];
ii. the cumulative amount of previous non-remote electronic [add: or no-CVM (Card Verification Method)] payment transactions initiated via the payment instrument offering a contactless [add: or no-CVM (Card Verification Method)] functionality without application of strong customer authentication does not exceed 150 EUR [add: or lower threshold set by the ASPSP or the payer].
Article 8.2(a)
We strongly suggest to add the possibility for ASPSP to add a limit on transaction amount also for trusted beneficiaries.
Article 8.2(d)
Choosing an amount of EUR 10 seems an arbitrary one. We do not foresee significant additional issues or threats when slightly lowering or heightening this amount. We therefore suggest to extend the text with the optional change of the amount (regarding the applicability of this Article) by the PSP based on a case-by-case risk-analysis.
Article 8.2
Notwithstanding the reference to Article 97.2 (PSD2) in Article 8.2, we can only interpret this Article in such a way that the exemptions mentioned in Article 8.2 relate to the entire SCA procedure, and not only to the dynamic linking of amount and payee. We suggest EBA to amend the text of Article 8.2 in order to clarify the ambiguity on the scope of the exemptions.
Important note: all the comments provided above are made under the assumption that the exemptions remain optional for the ASPSPs. We also refer to our reaction on Question 5 in case the exemptions are intended to become mandatory.
Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?
Yes. We interpret this Question in such a way that it refers to the list of exemptions becoming mandatory for a PSP to implement. Further to our arguments in our response to Question 4, we have fundamental objections against a mandatory exhaustive list of exemptions. Given the responsibilities and liabilities of an ASPSP, the ASPSP must be able to decide on the application of SCA, regardless of exemptions allowed.As a consequence of a limited and mandatory list of exemptions, we foresee a risk that the average level of security of payment systems and/or their service level is lowered:
- There are specific situations of some of the proposed exemption cases for which it is currently common practice to require application of SCA, however which would not be allowed anymore with these draft RTS. For example, there could be a risk in payment transactions executed between two bank accounts (for example a transaction from a savings account to a current account) of the same legal person (an exemption case in itself), if such a payment transaction is immediately followed by a number of payment transactions to other accounts (to divert the money to fraudsters), since this is a pattern that has been seen with fraudsters.
- In general, a payment transaction for which the exemptions have to be applied, runs the risk to attract fraudsters because they can be quite sure that no further authentication will be required, once they are successful in initiating such a transaction. Nevertheless, such a transaction is probably signaled and marked as suspicious by the ASPSP. However, in case these draft RTS apply, nothing can be done against it, other than to block the transaction, i.e. lowering the service level, which is not a desirable outcome for both the payer and the payee/merchant.
Question 6: Do you agree with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials, and the resultant provisions proposed in Chapter 3 of the draft RTS?
Article 9Although we agree in general with the text in this Article, we would encourage a more principle-based approach. With the level of detail of the current text we see a risk of overlooking additional important aspects, such as physical and logical security, procedures for staff, etc. In our view, the current requirements do not ensure the secure storage and use of these credentials. A suggestion could be to refer to the application of technical standards. Standards such as FIPS 140 (cryptography) or ISO 9564 (PIN management) are suitable in this context.
Article 9.1(c)
The requirement of ‘tamper resistancy’ simply can not apply to consumer devices such as smartphones.
Article 13(b)
The words “digitally signed” refer to one specific technology, while we consider other technologies equally effective in ensuring the authenticity of the software delivered by the PSP. Moreover, in order to distribute software through genuine app stores the software must be digitally signed by the provider. We suggest EBA to formulate this requirement more general, by amending the text as follows:
“Mechanisms [add: allowing the payment service user to verify the authenticity of the authentication software delivered] [delete: that the authentication software delivered to the payment services user via the internet has been digitally signed] by the payment services provider”
Article 13(c)i
Our members assess that this requirement should be formulated in a more risk-based manner. In particular with the additional requirement in Article 13(c)ii, it would be sufficient to require:
i. Adequately protect the personalised security credentials, the authentication devices or software against the unauthorised use when delivered through the same channel.
Question 7: Do you agree with the EBA’s reasoning on the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, and the resultant provisions proposed in Chapter 4 of the draft RTS?
Article 17.1What is meant by “secure bilateral identification” between the payer’s device and payee’s accepting device. Is mutual authentication meant here? This would create incompatibility with EMV card-based payments, which does not require terminal authentication. EMV is a widely accepted industry standard.
Article 17.2
We suggest EBA to add “adequately” before “protected”, since we think the current text is too strictly formulated.
Article 19.2(c)
We have the impression that this Article is only applicable in those models where the ASPSP allows the AISP / PISP to collect the credentials. In cases where credentials are transferred directly by the PSU to the ASPSP this Article is not applicable. If our interpretation is the intended one, then we think the word ‘when’ should be changed into ‘if’.
Article 21.5
Based on this article, is it correct to assume, that Article 16 on audit requirements would also be applicable for the PISP and AISP, in so far they are part of the authentication procedure?
Article 22.1(a) – Rationale 69(d)
In relation to the data exchange, we would suggest that EBA would clarify that the ASPSP shall provide the account information service provider at most with the same information from designated payment accounts and associated payment transactions made available to the payment services user when directly accessing the information online. Therefore this information may not include display of other types of customer transactions.
Furthermore, the use of the word “functionalities” in Rationale 69(d) might involve additional data as well. We therefore suggest to amend the text as follows:
(a) Account information service providers with the same information from designated payment accounts and associated payment transactions made available to the payment service user when directly accessing the information online [add: , limited to the transaction data elements from the interbank exchange and information on the balance], provided that this information does not include display of sensitive payment data;
Article 22.4
Suggest to change the text to:
“… with the same information [delete: requested] [add: collected] from the payment service user …”
This would include for instance geolocation, IP address, etc. to ensure adequate fraud mitigation.
Question 8: In particular, do you agree that the use of ISO 20022 elements, components or approved message definitions, if available, should be required to ensure the interoperability of different technological communication solutions implemented between PSPs for the provision of AIS, PIS or for the confirmation on the availability of funds? Do you see any particular technical constraint that would prevent the use of such industry standards?
Yes, we agree with the use of ISO 20022 elements, components or approved message definitions when it comes to the underlying ‘data dictionary’. Requiring the use of XML would not be future-proof in our view. Currently, industry standards such as JSON are used for data exchange.No, we do not see technical constraints that prevent the use of industry standards, as long as these are sufficiently technology-neutral.
Question 9: With regards to identification between PSPs, do you agree that website certificates issued by a qualified trust service provider under an e-IDAS policy would be suitable and allow for the use of all common types of devices (such as computers, tablets and mobile phones) for carrying out different payment services ?
We would like to comment that qualified certificates assure the quality of identification by the CA for the issuing of such a certificate, but not the quality of the technology used to keep the associated private key credentials used for authentication (proof of identity) under sole usage control by its respective owner (a PSP). In order to ensure sole usage control by the respective PSP, we propose to specify the adequate protection (e.g. crypto smart cards, USB dongles, hardware security modules) for the associated PSP private key credentials, preferably referring to international standards. Based on such an enhanced specification, qualified certificates and associated private key credentials are a common and standard solution for PSP authentication in automated server-server communications.We agree with the fact that a Qualified Trust Service Provider (QTSP) could provide the certificates to be used for the identification between PSPs and for website authentication subject to sufficient availability of the appropriate certification authorities on the market. However, in the case of PSP software components installed on any common type device (e.g., tablet, mobile phone), owned by the payer, there is no way to enforce sole usage control over private key credentials by the owning PSP, which renders the certificate based approach completely unsuitable for PSP authentication in such a scenario (no mitigation against PSP impersonation attacks).
Article 20.1
To avoid a monopoly for such qualified trust service providers, we consider EBA to add a provision that sufficient (min. five) trusted service providers are available offering the services mentioned.
Question 10: With regards to the frequency with which AIS providers can request information from designated payment accounts when the payment service user is not actively requesting such information, do you agree that the proposed limit of no more than two times a day achieve an appropriate balance between allowing AISP to provide updated information to their users while not negatively impacting the availability of the ASPSP’s communication interface? If not, please indicate what would be in your view the appropriate frequency and rationale for such frequency.
Our concerns are not with the frequency, which seems to be appropriate and useful to us.However, we are concerned about the amount of data that can be requested. When PSUs are allowed to request for example their full transaction history of the past seven years that would lead to an enormous (and unacceptable) load on the ASPSP’s systems. Therefore we expect that ASPSPs are allowed to limit the amount of data that can be transferred in one request.