Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
ESBG agrees with EBA’s commentary of the usage of payment instruments for which strong customer authentication has to be applied.
ESBG also reiterates its earlier position that the Regulatory Technical Standards should neither impede innovation (including technology and business model) nor consumer con-venience. Any disposition should meet this double test to be acceptable.
ESBG supports the definition of authentication elements, the requirement for a valid com-bination thereof, and the requirement for fraud prevention, detection and blocking mecha-nisms as provided under Rationale 22. a), b) and c) of the Consultation Paper. ESBG would suggest that, should examples and illustrations be required, these would fit well into a possible, future set of “EBA Guidelines” supporting the RTS under development.
This being said, ESBG should like to make the following remarks:
- Rationale 26: Both the payee and the transaction amount should be visible to the payer on the system used for and at the moment of signing the transaction.
- Rationale 29: neither behavioural data nor any other should be excluded as (even standalone) inherence element. It is the responsibility of payment service providers to ensure that the risk mitigation process(es) they choose produce the requisite outcome. It should be noted that EBA does not substantiate its proposal.
- Art. 1.3(a): no limitation of a payment service user’s online banking session should be mandated, time out should only apply in case of inactivity.
- Art. 1.3.(b) should allow for messaging to user (such as “incorrect PIN”, in order to avoid multiple attempts and service blockage).
- Art. 1.3.(d) should mention neither http nor TLS, as the RTS may remain in force well after these protocols have become obsolete.
- Art. 1.3(e): the meaning of “PSPs’ final authorization” and its implications should be clarified. As written, it means that fraud detection systems have to operate in real time.
- Art. 1.3 (e) should define the objectives to be achieved by payment service providers, yet – with consideration for the innovation and consumer convenience criteria - leave them the choice of how to meet these objectives. Accordingly the paragraph 2nd sen-tence should be reworded as follows: “…These mechanisms may take into account:”, then continuing with a list of examples, for illustration. Regarding these, it should be noted that 1.3 (e) ii and iv are only relevant when the payment service user transacts directly with the account servicing payment service provider.
- In order to remove ex ante any potential interpretation ambiguity, Art. 2.2 b) should be clarified (e.g. through a recital) to the effect that e.g. 2 applications co-existing on the same mobile phone may be used in compliance with the RTS. This is essential for con-sumer convenience.
- Art. 2.2 b) should furthermore remove any potential ambiguity by stating, after “…linking the transaction to a specific amount and a specific payee”, “to the exclu-sion of any intermediary”.
- A clearer formulation should be proposed for Art. 2.4. The following could be consid-ered: “For the purposes of the application of strong customer authentication in accord-ance with Art. 9(2) of Directive (EU) 2015/2366, when the payer has given consent to execute a batch of remote electronic payments to several payees, the authentication code generated in accordance with Art. 1 shall uniquely link the total amount of the batch of electronic payment transactions and the group of payees in the said batch of transactions”.
- As currently written, Art. 2.3 would bring card-based transactions at a POS in scope of the dynamic linking obligation, which seems contrary to PSD2.
- As currently drafted, Art. 3.1 be limitative with respect to innovation and hence keep-ing up with future security requirements. It is recommended to reword the Article as follows: “The elements of strong customer authentication categorised as knowledge are characterised by security features. These may include length, complexity, expiration time and use of non-repeatable characters ensuring resistance against the risk of the elements being uncovered or disclosed to unauthorised parties”.
- Art. 3.2 should not allow for ambiguity by referring to non-defined “unauthorised par-ties”. This wording should be replaced by “to any party other than the payer”.
- Art. 4.1: it should be clarified that possession of a mobile phone (i.e. of a mobile phone number) is indeed considered as a possession element.
- Art. 6.3 should be amended in line with the rationale submitted above and state: “For the purposes of para. 2, the mitigating measures may include:”, then continuing with sub-paragraphs a. and b.
- In para. 6.3.a., the reference to “trusted execution environments” is misleading. This terminology has been developed in the context of notably mobile phones yet no homo-geneous definition exists. In addition the objective implied by this terminology may fail the consumer convenience and innovation criteria. It is proposed to replace this word-ing with “segregated execution environment inside the multi-purpose device, when technology allows it”.
- Art. 6.3(b): once software or a device is in the hands of a payer or a third party, Ac-count Servicing Payment Service Providers may experience difficulty in preventing their alteration. Therefore what matters is the outcome of Art. 6.2 (i.e. the outcome of the Strong Customer Authentication procedure), and not the means used to achieve it.
- Rationale 19. b) should be deleted as it does not respond to a PSD2 mandate and no legal base can be found to justify it. When stating that the option not to accept SCA (by assuming the corresponding liabilities) is allowed only for a transitional period, the Rationale impedes a significant part of current e-commerce, which would hamper com-petition in the online commerce sector.
Without prejudice to the remark made above regarding Art. 2.3, “pre-payment” in situa-tions where the transaction amount is not certain in advance (e.g. at petrol stations, gated parking facilities where a PSU is invited to log in and log out with his card, hotel check-in procedures for incidentals, car rental incidental charges,… ) may obey a range of scenarios. It would seem that only one scenario is contemplated in the draft RTS, which is not work-able in practice. Furthermore the SCA requirements would appear to impede card pay-ments under the MOTO scenario (no SCA possible currently in a phone conversation).
An additional remark is in Rationale 27 the references should be to Articles 2(3) and 2(4) of the draft RTS, and not to Articles 3(3) and 3(4) as currently stated.
The Chapter (or a Recital) should specify that payment service providers have the option (i.e. are exempted, yet not prohibited) to apply the exemptions defined therein, which would enable account servicing payment service providers to achieve higher levels of secu-rity. The exemption list should not be exhaustive either, as this could impede future inno-vation.
Further specific comments on Chapter 2 are:
- In Rationale 52, the reference to “EMV Chip & PIN technology” should be removed, as this reference would tend to limit the meaning of this Rationale to NFC (Near Field Communication) transactions.
- Art. 8.1(a): the term “exclusively” should be deleted as it leads to confusion. A proper alignment is necessary between the information not included in the concept of payment accounts and the information being exempted from SCA through this article. As the Commission clarified in the PSD1 Q&As, payment accounts are accounts “where the holder can place and withdraw funds without any additional intervention or agreement of his pay-ment service provider”.
- Art. 8.1(a)ii: the one month limit to the exemption of the application of SCA to access of information is generally welcome. However it is proposed that ASPSPs may extend this limit on the basis of a risk-based analysis of each transaction to one year - being clear though that under the risk-based principle the ASPSP may also shorten the one month timeframe as currently stated. Furthermore, this exemption should equally apply to (i) the PSU accessing the payment account information by itself and (ii) the AIS ac-cessing the payment account information with the consent of the PSU. And, in any case, ASPSPs should be able to identify if the PSU accesses the information in either situation.
Notwithstanding the above, the ASPSP should be empowered to trigger the application of SCA should there be a suspicion that the credentials have been compromised, thus in effect requiring SCA more often than once every 30 days.
- Art. 8.1. (b) should read “the payer initiates a contactless electronic payment transac-tion at point of sale” (instead of: “…at a point of sale”).
- Art. 8.1. (b)i and ii: contactless electronic payment transactions at point of sale are ex-empted from the application of SCA up to the ceilings specified in this paragraph. The same exemptions should apply to electronic payment transactions with “contact”.
- Art. 8.2.: the Article should refer to PSD2 Art. 97(1) (instead of PSD2 Art. 97(2), as the latter induces that SCA yet not dynamic linking is exempted.
- Art. 8.2(a): the exemption should be applicable too by “closed user groups” defined and managed by groupings of ASPSPs, or on behalf thereof, or by a single PSP, or on its be-half.
- Art. 8.2(b) should explicitly refer to “standing orders”. The same exemption should ap-ply to recurring card payments, in order not to discriminate between payment instru-ments.
- Art. 8.2(d): The proposed ceiling of only EUR 10 for remote electronic payment trans-actions will have a deep negative impact on existing user-friendly payment products making use of the current ceiling of EUR 30 of the so-called SecuRe Pay Recommenda-tions. Otherwise the investments already made to develop and provide such products, and for the related risk management, will be lost. Therefore it is proposed either to ap-ply the same ceiling of (at least) EUR 30 for remote electronic payment transactions as defined in the SecuRe Pay Recommendations or to apply the ceiling proposed in Art. 8.1(b)i which supports a harmonisation of the amounts of these exemptions. At the same time the cumulative amount of Art. 8.1(b)ii of EUR 150 should apply for remote electronic payment transactions, too. Hence the ceilings should respectively read EUR 30 (or EUR 50) and EUR 150.
Art. 8.1.(a)ii could be interpreted as enabling an AISP to access data for 30 days after the contract between the PSU and said AISP has been terminated – which should not be al-lowed.
In addition the wording of Art. 8.1. (b) ii should be enhanced. In order to clarify that, where the previous transactions without strong customer authentication exceed 150 EUR, then the next transaction has to be made with strong customer authentication, and where the previous transaction has been made with strong customer authentication, then no such authentication is required for the following one, the proposal is to state: “the payer initiates a contactless payment transaction at point of sale within the limits of both the following conditions:…. ii. the cumulative amount of previous non-remote electronic payment trans-actions initiated without application of strong customer authentication not exceed 150 EUR”.
- Art. 9.1 (a) should be corrected as follows: “Personalised security credentials are masked when displayed and not readable in their full extent” (i.e. deleting the first 2 words: “Data on”).
- Art. 10 should also require payees contracting with payment service providers to – be-yond implementing the security measures referred to in Art. 9 to protect data related to personalised security credentials – document these, periodically test, evaluate and have them audited – in essence clarifying that contracting payees should mirror the obliga-tions placed on payment service providers under Art. 16. Payees not evidencing an ac-cordingly proper behaviour could be made liable in case of fraud.
- Art. 11: the same remark as made above with respect to Art. 6.3(b) would apply to the requirement that “these security measures shall provide that the risks of unauthorised use of the personalised security credentials and of the authentication devices and soft-ware due to their loss, theft or copying before the delivery to the payer are effectively addressed”.
- Art. 12(b): it should be clarified that this Article can only apply after the activa-tion/implementation of a device/software by the payer – as prior to that, SCA is not possible.
- Art. 14 should not prevent a simplified procedure for the renewal of personalised secu-rity credentials where existing, valid personalised security credentials can be used to se-cure such renewal.
- Art. 15(c): it should be clarified what is meant by “public repositories”.
ESBG notes that central to this Chapter is that ASPSPs “shall offer at least one communi-cation interface”, which means that there is no obligation to offer more than one, and that ASPSPs are entitled to block any other attempt to access payment accounts.
ESBG has the following remarks:
- Art. 17.1: the bilateral identification as described in this Article could impact the logic of EMV for cards, as currently the card identifies the terminal as a device, and not the other way around. This could translate into a major architecture change for card sys-tems.
- Art. 17.2: the same remark as made above with respect to Art. 6.3(b) would apply to the requirement that “payment service providers shall ensure that mobile applications and other payment service user interfaces offering electronic payment services are pro-tected against misdirection of communication to unauthorised third parties”, all the more so as ASPSPs cannot be held responsible for e.g. payers installing malware on a device.
- Art. 19.2.c): it should be clarified that when PISPs and AISPs are allowed to transmit authentication codes and PSCs, the former must use only the communication interface constructed with that objective, which hampers neither consumer protection nor usa-bility.
- Art. 19.4 should be amended to the effect that the technical specification of account servicing payment service providers’ communication is made available to “duly regis-tered and identified payment service providers (or to their designated vendors), upon their request”, rather than “made available…on [their – i.e. the account servic-ing payment service providers’] – website. This revised disposition should make it more difficult for cyber criminals to get access to important information.
- Art. 19.5: payment service providers should be compelled to adapt their protocols and tools within a maximum set period (e.g. one month), once account servicing payment service providers have in compliance with Art. 19.5 disclosed change to the technical specifications.
- In line with the remark immediately above, Art. 19.7 should also be amended to the ef-fect that the testing facility defined therein should only be made available to “duly registered and identified payment service providers (or to their designated vendors), upon their request”. This Article should further specify that the conditions under which the testing facility and related support are made available to the above mentioned payment service providers (or their designated vendors) will be the same than the conditions under which a given account servicing payment service provider makes such facility and support available to its own customers.
- Art. 19.6: testing environments and support should be excluded from the obligation to provide a same level of service.
- Art. 20.3.(b): all parties in a transaction should be listed, not only the competent au-thority – as the ASPSP needs to know whom he deals with.
- Art. 21.5: the requirement that PSCs are not accessible to any staff must be challenged – in particular under the scenario where an AISP is entitled to repeat requests for in-formation from an ASPSP without the user’s interaction (where the AISP does need to authenticate the payer on the payer’s behalf, i.e. the AISP needs to provide the payer’s PSCs).
- Art. 21.6: ESBG would understands that the reference to ISO 27001 does not imply any certification of the implementation of this standard.
This should be clearly stated in connection with the scope of PSD2 that in Art.2. estab-lished that it only applies to payment services. Therefore, the account information service should provide consolidated information on one or more payments accounts (Art. 4) and only can have access to the information of the designated payments accounts and associat-ed payments (Art. 67.2 d).
Art. 22.1a): further clarification is necessary on the meaning of “designated payment ac-counts and associated payment transactions”. Additionally, it should be specified how the PSUs are to communicate the designated payment accounts, in a similar way as PSCs hav-ing to be transmitted through the communication interface (art. 19.2.c).
Both the frequency and the amount of information that may be requested by account in-formation service providers are a very sensitive issue, as they are very likely to impact the quality and the cost of the service delivered by account servicing payment service provid-ers, not only to third parties, but also to their own customers.
A general, non-quantifiable guideline should be that both frequency and amount of infor-mation requested by a third party on behalf of an account holder should not differ from the historical pattern of the said account holder with respect to frequency and amount of in-formation queried. In the absence of such historical pattern setting a ceiling with respect to both frequency and amount of information, a “segment” pattern would apply.
However a further dimension has to be taken into consideration, i.e. the number of ac-count information service providers that may wish to collect information, and the distribu-tion – or rather, absence thereof – of their queries throughout a day. Therefore an account servicing payment service provider should be allowed to publish time windows for account information service providers to query information, and to set a maximum amount of in-formation that can be queried, the latter expressed in hits per second, both at the level of any account information service provider, and for all account information service providers combined.
With regard to the requirement of PSD2 Art. 67.2(a) that the payment service user has to provide his explicit consent, AISPs should properly inform PSUs if they would like to make use of the option of Art. 22.5(b) to request information without active involvement of the PSU. To allow the PSU to gain transparency of the accesses to his account and to control the costs of his payment account (consumer protection), the RTS should clarify that the PSU can request from the AISP at each point in time, either to prohibit or stop information requests without active involvement of the PSU defined in Art. 22.5(b), or to limit the fre-quency.
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?
PSD2 Art. 4(30) and Art. 97(1) lay out the requirements for strong customer authentica-tion as well as the payer scenarios where payment service providers have to apply at an ad-equate level of clarity for a piece of legislation.ESBG agrees with EBA’s commentary of the usage of payment instruments for which strong customer authentication has to be applied.
ESBG also reiterates its earlier position that the Regulatory Technical Standards should neither impede innovation (including technology and business model) nor consumer con-venience. Any disposition should meet this double test to be acceptable.
ESBG supports the definition of authentication elements, the requirement for a valid com-bination thereof, and the requirement for fraud prevention, detection and blocking mecha-nisms as provided under Rationale 22. a), b) and c) of the Consultation Paper. ESBG would suggest that, should examples and illustrations be required, these would fit well into a possible, future set of “EBA Guidelines” supporting the RTS under development.
This being said, ESBG should like to make the following remarks:
- Rationale 26: Both the payee and the transaction amount should be visible to the payer on the system used for and at the moment of signing the transaction.
- Rationale 29: neither behavioural data nor any other should be excluded as (even standalone) inherence element. It is the responsibility of payment service providers to ensure that the risk mitigation process(es) they choose produce the requisite outcome. It should be noted that EBA does not substantiate its proposal.
- Art. 1.3(a): no limitation of a payment service user’s online banking session should be mandated, time out should only apply in case of inactivity.
- Art. 1.3.(b) should allow for messaging to user (such as “incorrect PIN”, in order to avoid multiple attempts and service blockage).
- Art. 1.3.(d) should mention neither http nor TLS, as the RTS may remain in force well after these protocols have become obsolete.
- Art. 1.3(e): the meaning of “PSPs’ final authorization” and its implications should be clarified. As written, it means that fraud detection systems have to operate in real time.
- Art. 1.3 (e) should define the objectives to be achieved by payment service providers, yet – with consideration for the innovation and consumer convenience criteria - leave them the choice of how to meet these objectives. Accordingly the paragraph 2nd sen-tence should be reworded as follows: “…These mechanisms may take into account:”, then continuing with a list of examples, for illustration. Regarding these, it should be noted that 1.3 (e) ii and iv are only relevant when the payment service user transacts directly with the account servicing payment service provider.
- In order to remove ex ante any potential interpretation ambiguity, Art. 2.2 b) should be clarified (e.g. through a recital) to the effect that e.g. 2 applications co-existing on the same mobile phone may be used in compliance with the RTS. This is essential for con-sumer convenience.
- Art. 2.2 b) should furthermore remove any potential ambiguity by stating, after “…linking the transaction to a specific amount and a specific payee”, “to the exclu-sion of any intermediary”.
- A clearer formulation should be proposed for Art. 2.4. The following could be consid-ered: “For the purposes of the application of strong customer authentication in accord-ance with Art. 9(2) of Directive (EU) 2015/2366, when the payer has given consent to execute a batch of remote electronic payments to several payees, the authentication code generated in accordance with Art. 1 shall uniquely link the total amount of the batch of electronic payment transactions and the group of payees in the said batch of transactions”.
- As currently written, Art. 2.3 would bring card-based transactions at a POS in scope of the dynamic linking obligation, which seems contrary to PSD2.
- As currently drafted, Art. 3.1 be limitative with respect to innovation and hence keep-ing up with future security requirements. It is recommended to reword the Article as follows: “The elements of strong customer authentication categorised as knowledge are characterised by security features. These may include length, complexity, expiration time and use of non-repeatable characters ensuring resistance against the risk of the elements being uncovered or disclosed to unauthorised parties”.
- Art. 3.2 should not allow for ambiguity by referring to non-defined “unauthorised par-ties”. This wording should be replaced by “to any party other than the payer”.
- Art. 4.1: it should be clarified that possession of a mobile phone (i.e. of a mobile phone number) is indeed considered as a possession element.
- Art. 6.3 should be amended in line with the rationale submitted above and state: “For the purposes of para. 2, the mitigating measures may include:”, then continuing with sub-paragraphs a. and b.
- In para. 6.3.a., the reference to “trusted execution environments” is misleading. This terminology has been developed in the context of notably mobile phones yet no homo-geneous definition exists. In addition the objective implied by this terminology may fail the consumer convenience and innovation criteria. It is proposed to replace this word-ing with “segregated execution environment inside the multi-purpose device, when technology allows it”.
- Art. 6.3(b): once software or a device is in the hands of a payer or a third party, Ac-count Servicing Payment Service Providers may experience difficulty in preventing their alteration. Therefore what matters is the outcome of Art. 6.2 (i.e. the outcome of the Strong Customer Authentication procedure), and not the means used to achieve it.
- Rationale 19. b) should be deleted as it does not respond to a PSD2 mandate and no legal base can be found to justify it. When stating that the option not to accept SCA (by assuming the corresponding liabilities) is allowed only for a transitional period, the Rationale impedes a significant part of current e-commerce, which would hamper com-petition in the online commerce sector.
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.
To respect both the innovation and consumer convenience criteria, the RTS should remain neutral as to when dynamic linking takes place.Without prejudice to the remark made above regarding Art. 2.3, “pre-payment” in situa-tions where the transaction amount is not certain in advance (e.g. at petrol stations, gated parking facilities where a PSU is invited to log in and log out with his card, hotel check-in procedures for incidentals, car rental incidental charges,… ) may obey a range of scenarios. It would seem that only one scenario is contemplated in the draft RTS, which is not work-able in practice. Furthermore the SCA requirements would appear to impede card pay-ments under the MOTO scenario (no SCA possible currently in a phone conversation).
An additional remark is in Rationale 27 the references should be to Articles 2(3) and 2(4) of the draft RTS, and not to Articles 3(3) and 3(4) as currently stated.
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?
It should be clarified that card-based transactions initiated at a terminal located outside the EEA by a PSU holding an account with an ASPSP within the EEA are outside the scope of these RTS.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?
The payment service provider(s) carrying the actual risk may take a different approach above the proposed amount ceilings of Art. 8.1.b(i) and Art. 8.1.d.(i) and within the scope of PSD2 Art. 95 and Art. 98.3(a), and decide to apply or not the proposed exemptions e.g. a payment service provider may decide to perform strong customer authentication for every transaction regardless of amount, or a contrario not to apply strong customer authentica-tion for an online access in function of a certain “validity” period. The RTS should remain neutral in this respect and assume that the exemptions need to “be based on the level of risk involved in the service provided” as per PSD2 Art. 98.3.a). The risk-based analysis would not discriminate depending upon the presence of AISPs or PISPs. One could also recall the earlier ECB Recommendations for the Security of Internet Payments, which in this respect have not been changed by PSD2 and suggest that “PSPs and payment schemes should determine whether and to what extent changes may be necessary to the existing se-curity measures, the technologies used and the procedures or services offered. PSPs and payment schemes should take into account the time required to implement the changes (in-cluding customer roll-out) and take the appropriate interim measures to minimise security incidents and fraud, as well as potential disruptive effects” (Recommendation II).The Chapter (or a Recital) should specify that payment service providers have the option (i.e. are exempted, yet not prohibited) to apply the exemptions defined therein, which would enable account servicing payment service providers to achieve higher levels of secu-rity. The exemption list should not be exhaustive either, as this could impede future inno-vation.
Further specific comments on Chapter 2 are:
- In Rationale 52, the reference to “EMV Chip & PIN technology” should be removed, as this reference would tend to limit the meaning of this Rationale to NFC (Near Field Communication) transactions.
- Art. 8.1(a): the term “exclusively” should be deleted as it leads to confusion. A proper alignment is necessary between the information not included in the concept of payment accounts and the information being exempted from SCA through this article. As the Commission clarified in the PSD1 Q&As, payment accounts are accounts “where the holder can place and withdraw funds without any additional intervention or agreement of his pay-ment service provider”.
- Art. 8.1(a)ii: the one month limit to the exemption of the application of SCA to access of information is generally welcome. However it is proposed that ASPSPs may extend this limit on the basis of a risk-based analysis of each transaction to one year - being clear though that under the risk-based principle the ASPSP may also shorten the one month timeframe as currently stated. Furthermore, this exemption should equally apply to (i) the PSU accessing the payment account information by itself and (ii) the AIS ac-cessing the payment account information with the consent of the PSU. And, in any case, ASPSPs should be able to identify if the PSU accesses the information in either situation.
Notwithstanding the above, the ASPSP should be empowered to trigger the application of SCA should there be a suspicion that the credentials have been compromised, thus in effect requiring SCA more often than once every 30 days.
- Art. 8.1. (b) should read “the payer initiates a contactless electronic payment transac-tion at point of sale” (instead of: “…at a point of sale”).
- Art. 8.1. (b)i and ii: contactless electronic payment transactions at point of sale are ex-empted from the application of SCA up to the ceilings specified in this paragraph. The same exemptions should apply to electronic payment transactions with “contact”.
- Art. 8.2.: the Article should refer to PSD2 Art. 97(1) (instead of PSD2 Art. 97(2), as the latter induces that SCA yet not dynamic linking is exempted.
- Art. 8.2(a): the exemption should be applicable too by “closed user groups” defined and managed by groupings of ASPSPs, or on behalf thereof, or by a single PSP, or on its be-half.
- Art. 8.2(b) should explicitly refer to “standing orders”. The same exemption should ap-ply to recurring card payments, in order not to discriminate between payment instru-ments.
- Art. 8.2(d): The proposed ceiling of only EUR 10 for remote electronic payment trans-actions will have a deep negative impact on existing user-friendly payment products making use of the current ceiling of EUR 30 of the so-called SecuRe Pay Recommenda-tions. Otherwise the investments already made to develop and provide such products, and for the related risk management, will be lost. Therefore it is proposed either to ap-ply the same ceiling of (at least) EUR 30 for remote electronic payment transactions as defined in the SecuRe Pay Recommendations or to apply the ceiling proposed in Art. 8.1(b)i which supports a harmonisation of the amounts of these exemptions. At the same time the cumulative amount of Art. 8.1(b)ii of EUR 150 should apply for remote electronic payment transactions, too. Hence the ceilings should respectively read EUR 30 (or EUR 50) and EUR 150.
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?
As already stated under the response to Question 4, ESBG would understand that account servicing payment service providers are exempted yet not prohibited from applying strong customer authentication in the scenarios referred to in PSD2 Art. 98.1 (b).Art. 8.1.(a)ii could be interpreted as enabling an AISP to access data for 30 days after the contract between the PSU and said AISP has been terminated – which should not be al-lowed.
In addition the wording of Art. 8.1. (b) ii should be enhanced. In order to clarify that, where the previous transactions without strong customer authentication exceed 150 EUR, then the next transaction has to be made with strong customer authentication, and where the previous transaction has been made with strong customer authentication, then no such authentication is required for the following one, the proposal is to state: “the payer initiates a contactless payment transaction at point of sale within the limits of both the following conditions:…. ii. the cumulative amount of previous non-remote electronic payment trans-actions initiated without application of strong customer authentication not exceed 150 EUR”.
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?
ESBG generally supports the reasoning laid out in Chapter 3 – with 6 remarks:- Art. 9.1 (a) should be corrected as follows: “Personalised security credentials are masked when displayed and not readable in their full extent” (i.e. deleting the first 2 words: “Data on”).
- Art. 10 should also require payees contracting with payment service providers to – be-yond implementing the security measures referred to in Art. 9 to protect data related to personalised security credentials – document these, periodically test, evaluate and have them audited – in essence clarifying that contracting payees should mirror the obliga-tions placed on payment service providers under Art. 16. Payees not evidencing an ac-cordingly proper behaviour could be made liable in case of fraud.
- Art. 11: the same remark as made above with respect to Art. 6.3(b) would apply to the requirement that “these security measures shall provide that the risks of unauthorised use of the personalised security credentials and of the authentication devices and soft-ware due to their loss, theft or copying before the delivery to the payer are effectively addressed”.
- Art. 12(b): it should be clarified that this Article can only apply after the activa-tion/implementation of a device/software by the payer – as prior to that, SCA is not possible.
- Art. 14 should not prevent a simplified procedure for the renewal of personalised secu-rity credentials where existing, valid personalised security credentials can be used to se-cure such renewal.
- Art. 15(c): it should be clarified what is meant by “public repositories”.
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?
EBA’s reasoning in Chapter 4 is generally supported.ESBG notes that central to this Chapter is that ASPSPs “shall offer at least one communi-cation interface”, which means that there is no obligation to offer more than one, and that ASPSPs are entitled to block any other attempt to access payment accounts.
ESBG has the following remarks:
- Art. 17.1: the bilateral identification as described in this Article could impact the logic of EMV for cards, as currently the card identifies the terminal as a device, and not the other way around. This could translate into a major architecture change for card sys-tems.
- Art. 17.2: the same remark as made above with respect to Art. 6.3(b) would apply to the requirement that “payment service providers shall ensure that mobile applications and other payment service user interfaces offering electronic payment services are pro-tected against misdirection of communication to unauthorised third parties”, all the more so as ASPSPs cannot be held responsible for e.g. payers installing malware on a device.
- Art. 19.2.c): it should be clarified that when PISPs and AISPs are allowed to transmit authentication codes and PSCs, the former must use only the communication interface constructed with that objective, which hampers neither consumer protection nor usa-bility.
- Art. 19.4 should be amended to the effect that the technical specification of account servicing payment service providers’ communication is made available to “duly regis-tered and identified payment service providers (or to their designated vendors), upon their request”, rather than “made available…on [their – i.e. the account servic-ing payment service providers’] – website. This revised disposition should make it more difficult for cyber criminals to get access to important information.
- Art. 19.5: payment service providers should be compelled to adapt their protocols and tools within a maximum set period (e.g. one month), once account servicing payment service providers have in compliance with Art. 19.5 disclosed change to the technical specifications.
- In line with the remark immediately above, Art. 19.7 should also be amended to the ef-fect that the testing facility defined therein should only be made available to “duly registered and identified payment service providers (or to their designated vendors), upon their request”. This Article should further specify that the conditions under which the testing facility and related support are made available to the above mentioned payment service providers (or their designated vendors) will be the same than the conditions under which a given account servicing payment service provider makes such facility and support available to its own customers.
- Art. 19.6: testing environments and support should be excluded from the obligation to provide a same level of service.
- Art. 20.3.(b): all parties in a transaction should be listed, not only the competent au-thority – as the ASPSP needs to know whom he deals with.
- Art. 21.5: the requirement that PSCs are not accessible to any staff must be challenged – in particular under the scenario where an AISP is entitled to repeat requests for in-formation from an ASPSP without the user’s interaction (where the AISP does need to authenticate the payer on the payer’s behalf, i.e. the AISP needs to provide the payer’s PSCs).
- Art. 21.6: ESBG would understands that the reference to ISO 27001 does not imply any certification of the implementation of this standard.
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?
ISO 20022 elements, components or approved message definitions should enable the in-teroperability of different technological communication solutions implemented between payment service providers for the provision of account information and payment initiation services. This is already provided for with respect of payment initiation by EU Regulation 260/2012. It should be specified that the reference to ISO 20022 is to the file format – the technical communication resting on (an)other communication standard(s).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 ?
The e-IDAS Regulation (and the related Implementation Acts) provides the appropriate framework for identification notably between payment service providers, via certificates is-sued by a qualified trust service provider. The RTS should clarify that both public and pri-vate qualified trust service providers may issue such certificates. The RTS should further clarify that the reference to the eIDAS framework does not mean that eIDAS is mandated.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.
In relation to the data exchange, ESBG considers that EBA should clarify that the ASPSPs shall provide AISPs only with the same information from designated payment accounts and associated payment transactions made available to the PSU when directly accessing the information online. Therefore, this information may not include display of other type of client’s information (e.g. financial instruments, insurance products, other banking prod-ucts).This should be clearly stated in connection with the scope of PSD2 that in Art.2. estab-lished that it only applies to payment services. Therefore, the account information service should provide consolidated information on one or more payments accounts (Art. 4) and only can have access to the information of the designated payments accounts and associat-ed payments (Art. 67.2 d).
Art. 22.1a): further clarification is necessary on the meaning of “designated payment ac-counts and associated payment transactions”. Additionally, it should be specified how the PSUs are to communicate the designated payment accounts, in a similar way as PSCs hav-ing to be transmitted through the communication interface (art. 19.2.c).
Both the frequency and the amount of information that may be requested by account in-formation service providers are a very sensitive issue, as they are very likely to impact the quality and the cost of the service delivered by account servicing payment service provid-ers, not only to third parties, but also to their own customers.
A general, non-quantifiable guideline should be that both frequency and amount of infor-mation requested by a third party on behalf of an account holder should not differ from the historical pattern of the said account holder with respect to frequency and amount of in-formation queried. In the absence of such historical pattern setting a ceiling with respect to both frequency and amount of information, a “segment” pattern would apply.
However a further dimension has to be taken into consideration, i.e. the number of ac-count information service providers that may wish to collect information, and the distribu-tion – or rather, absence thereof – of their queries throughout a day. Therefore an account servicing payment service provider should be allowed to publish time windows for account information service providers to query information, and to set a maximum amount of in-formation that can be queried, the latter expressed in hits per second, both at the level of any account information service provider, and for all account information service providers combined.
With regard to the requirement of PSD2 Art. 67.2(a) that the payment service user has to provide his explicit consent, AISPs should properly inform PSUs if they would like to make use of the option of Art. 22.5(b) to request information without active involvement of the PSU. To allow the PSU to gain transparency of the accesses to his account and to control the costs of his payment account (consumer protection), the RTS should clarify that the PSU can request from the AISP at each point in time, either to prohibit or stop information requests without active involvement of the PSU defined in Art. 22.5(b), or to limit the fre-quency.