Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
Rationale 19.b:
We support the conclusion made by EBA that PSD2 does not allow for any exemptions on the acquiring/merchant side from the requirement to support strong customer authentication for all card payments, once the RTS is in force. We also agree that the liability shift described in the second sentence in Article 74(2) therefore have a larger relevance for the period in between when the PSD2 is in force and until the RTS comes in force, i.e. there are a larger number of transactions for which this liability shift is applicable. However, we would like to point out that the liability shift in 74 (2) is still valid also after the point in time when the RTS comes in force, in cases where the merchant/acquirer still fails to comply with the law (PSD2 and RTS) in supporting strong authentication – in such cases there will still be a value in itself to have this clause clearly laying the liability on the acquirer, despite the fact that the acquirer is in breach of the law; and this liability shift should apply regardless if the issuer have managed to decline in the authorisation the non-strong customer authentication- transaction, or not.
Article 1.3.e:
For example article 1 deals with authentication, but in article 1.3 authorization is suddenly used. The Article seems to confuse authentication (the customer proving their identity) with authorization (the customer approving the execution of a payment). The difference between these concepts and how they are used is an important issue. Regardless whether authorization is outside the mandate of the PSD2 or not the article’s wording “shall take into account” should be changed to “may take into account”.
The reason for this is that this article goes beyond the mandate given in PSD2.
The term authentication code" is used in a way which is difficult to interpret, see for example article 1 and point 22, 24, 25 in the Rationale. It seems as if the term can mean a variety of things – for example a PIN-code, a code delivered to a PIS or a code generated by different elements during the process of strong customer authentication – which makes it difficult to know if you are compliant.
The writing concerning the requirement of the payee to accept strong customer authentication, for example point 19 b) and article 74.2 are not sufficiently clear and do not correspond with the responsibility stated in article 74.2. Additionally, the process on how this is supposed to be managed in practice is missing. Finally, it only mentions card transactions.
Article 1.3.b:
In some situations, feedback to the payer on what went wrong can be helpful. For example if the payer enters the wrong PIN for a card transaction, it is common practice to display “Wrong PIN” in the terminal. The article should therefore be revised.
Article 2.1.b:
The article does note state a clear correlation between the payee and the issued transaction that can be used with regard to the validity (non-repudiation). This can be achieved by using a digital signature mechanism for the electronic payment transaction.
We are concerned, that requirements explained in Rationale 26 are conflicting with Rationale 34 when we talk about payment authorization using personal qualified certificates on e-identity smart cards or secure USB devices. The payment information (amount, payee) display in such cases is usually done in the same channel where the payment was initiated (e.g. the PC). We would like to see stronger assurance that payments authorized with qualified personal certificates under e-IDAS are compliant with RTS without exemptions."
Additionally, the list of exemptions should not be an exhaustive list. The ASPSP must be free to apply exemptions based on its own transaction risk analysis. An exhaustive list of possible exemptions or criteria to be considered by ASPSPs for the transaction risk analysis may prevent future innovations in fraud prevention analysis that are to be expected in this dynamic and changing environment. This means that the ASPSP must have the possibility to apply strong customer authentication even though formally exceptions would apply.
We strongly suggest that a digital signature should be used for credit transfers except for low value payments specified as exemptions.
Article 8.1.a.ii:
The ASPSPs want freedom of choice on when to perform strong customer authentication.
For example, if there are indications that the credentials have been compromised (based on transaction analysis, identity theft, malware etc.) the ASPSPs need to be able to require strong customer authentication more often than every 30th day. The reason for this is consumer protection and that the ASPSP must decide on the frequency to verify that the customer is active and that the ASPSPs are responsible to verify issued credentials.
Article.8.1.b:
The word “contactless” should be deleted. The RTS in general and the exemptions from strong customer authentication should ensure technological neutrality, which the EBA states in rationale 50. This principle should be upheld also for low value payments at point of sale.
In the draft RTS EBA state that only contactless electronic payment transactions should be subject to a low value exemption from strong customer authentication in order to preserve the high level of security provided by “chip & pin”. This motivation is not logical - contact without PIN transactions cannot be deemed less safe than contactless without PIN, on the contrary they are safer.
We would like to highlight that some of the major card schemes operating in Europe allow for “contact” payment transactions without PIN for small amounts (e.g. vending machines) and also for larger amounts (e.g. parking/tolls). In several cases, such as unattended parking terminals, exemptions on the PIN requirement are also done for security reasons, i.e. in order for the PIN not to be compromised by usage in a physical environment with high visibility.
Therefore, our view is that the exemption from strong customer authentication defined in article 8 (b) must be extended to also cover “contact” electronic payment transactions on the condition that the payment instrument used can be securely authenticated, i.e. the word “contactless” should be removed in Article 8.
Article 8.2.b:
Recurring card payments should enjoy the same exemption as recurring credit transfers, as pointed out in comment to Rationale 17, i.e. paragraph 2 in Article 8 should be updated accordingly:
“(b) the payer initiates online a series of credit transfers or card-based payments with the same amount and the same payee.
The application of strong customer authentication shall not be exempted where the payer initiates the series of credit transfers or card-based payments for the first time or amends the series of credit transfers.”
We understand that the application of the exemptions is optional for the payer’s PSP (the issuer in a card context). Preventing the implementation of stronger security would be against all principles of rationality and common sense. Issuers take risks through liabilities and may be limited by regulations towards not taking too high risks. But regulations should never refrain issuers from lowering their risks, e.g. through mandating security exemptions. Such an approach would indirectly induce also drastic reactions instead of proper risk-based reactions, should Issuers be confronted with new threats specifically targeting any of the exemption scenarios (e.g. massive low risk transaction fraud). Mandating exemptions could also result in unresolved situations that prevent ASPSPs to comply with other regulations (e.g. national) imposing more strict requirements.
Furthermore, the idea of allowing exemptions from the requirement on strong customer authentication, is to allow the possibility to make payment initiation more convenient for the payers. The underlying assumption being that strong customer authentication always creates a hustle or at least a slower payment initiation. With the escalating innovation in customer authentication methods and technology, this is no longer the case, and will be even less so in the future. Many times these new strong authentication methods are more customer-friendly and convenient, than many weak authentication methods like e.g. static passwords. For payment solutions where there is today only a strong customer authentication method offered for all transactions, which is perceived as convenient by the users, there is no need to introduce another weak customer authentication method, that would at the same time be less customer-friendly.
Article 8:
Item 2(a) is contradictive to article 2.1(b) requiring signing of the amount and payee of the payment initiation. E.g. if a payment through a PISP is done for an e-merchant with strong customer authentication and the e-merchant is amended as trusted beneficiary (again through strong customer authentication). Should subsequent purchases (regardless of amount) at that e-merchant really be possible without strong customer authentication? Please elaborate.
Article 8.1.a.ii:
We believe that it is the ASPSP’s responsibility to check whether or not the exemptions could be abused but this seems slightly unclear. Could you please elaborate?
It is stated that strong customer authentication is not required for 30 days. Today our online channels have a time out of several minutes, this to ensure protection of customer data. Is it really feasible to allow access without strong customer authentication for such a long period of time? Is it also feasible to allow customers through TPPs (according to the 2 times a day rule) access for such a long time without strong customer authentication?
One problem that can arise is that the consumer ends its engagement with the TPP but the TPP is still allowed up to 30 days without the customer consenting (according to the 2 times a day rule) since the PSPs cannot control if the consumer has ended the agreement with the TPP.
See also our answer to question 10.
- Which party is responsible for providing information about rights and risks to the PSU: AISP or ASPSP;
- Should PSU be allowed to revoke their consent for account information inquiry, and if so – how.
We would like to see clarification of the term “payment account information”. What specific account information is falling under this term: account balance, account statement (i.e. list of historical transactions on account)?
We would also like RTS to address the case when multiple authorisations / signatures are needed to initiate a payment (e.g. corporate customer, where more than one representative of the company must authorize payment instruction). In such cases, is ASPSP obliged to offer payment initiation service for PISPs, if such a service is available via its own internet banking service?
Another question is whether PSU should or could have a possibility to submit their will to the ASPSP to deny any requests coming from AISP or PISP on behalf of that PSU (i.e. “opt-out” from the TPP intermediation model in fear of possible fraud attacks via this vector).
We think that the RTS proposal to use website certificates" for AISP and PISP identification towards ASPSP is not correct, because “website certificates” are used to identify a server to the client but not a client to the server. Instead our suggestion is to use “electronic seals” and “qualified certificates for electronic seals”’ (eIDAS Article 3 (27), (30)) for that purpose. The right use of such method (provided certain data elements are included in the certificate) would allow ASPSP to identify any third party (legal person) with full assurance of its registration number, which would in turn allow to obtain required data about the AISP / PISP from the public register defined in Article 14 of Directive (EU) 2015/2366, and make the decision if to grant the service.
Our view is that methods used for identification of AISP/PISP towards ASPSP have no relation to the capabilities or suitability of various types of devices to carry out payment services, as this is identification between institutions and not the end-user (PSU)."
However, we think there should not be any strict requirements for ASPSP regarding requested data amount (e.g. the historical length of an account statement) or performance (e.g. response time) and these conditions should depend on technical capabilities of a particular ASPSP, i.e. the load of its systems. If needed, ASPSP should have the possibility to limit account information requests to prevent systems’ failure.
Additionally we think that if account balance or details of payment transactions on account (like payment amount, payee name) are considered “sensitive payment information” by ASPSP (because this information can be used for social engineering fraud schemes), then ASPSP should be able to require strong customer authentication on every account information request from AISP.
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?
The terms “authentication” and “authorisation’ are used in the document to describe and explain the RTS but there is no clear distinction between “authentication” and “authorisation”. It would be valuable if there were. Please rephrase/clarify the meaning with the respective word.Rationale 19.b:
We support the conclusion made by EBA that PSD2 does not allow for any exemptions on the acquiring/merchant side from the requirement to support strong customer authentication for all card payments, once the RTS is in force. We also agree that the liability shift described in the second sentence in Article 74(2) therefore have a larger relevance for the period in between when the PSD2 is in force and until the RTS comes in force, i.e. there are a larger number of transactions for which this liability shift is applicable. However, we would like to point out that the liability shift in 74 (2) is still valid also after the point in time when the RTS comes in force, in cases where the merchant/acquirer still fails to comply with the law (PSD2 and RTS) in supporting strong authentication – in such cases there will still be a value in itself to have this clause clearly laying the liability on the acquirer, despite the fact that the acquirer is in breach of the law; and this liability shift should apply regardless if the issuer have managed to decline in the authorisation the non-strong customer authentication- transaction, or not.
Article 1.3.e:
For example article 1 deals with authentication, but in article 1.3 authorization is suddenly used. The Article seems to confuse authentication (the customer proving their identity) with authorization (the customer approving the execution of a payment). The difference between these concepts and how they are used is an important issue. Regardless whether authorization is outside the mandate of the PSD2 or not the article’s wording “shall take into account” should be changed to “may take into account”.
The reason for this is that this article goes beyond the mandate given in PSD2.
The term authentication code" is used in a way which is difficult to interpret, see for example article 1 and point 22, 24, 25 in the Rationale. It seems as if the term can mean a variety of things – for example a PIN-code, a code delivered to a PIS or a code generated by different elements during the process of strong customer authentication – which makes it difficult to know if you are compliant.
The writing concerning the requirement of the payee to accept strong customer authentication, for example point 19 b) and article 74.2 are not sufficiently clear and do not correspond with the responsibility stated in article 74.2. Additionally, the process on how this is supposed to be managed in practice is missing. Finally, it only mentions card transactions.
Article 1.3.b:
In some situations, feedback to the payer on what went wrong can be helpful. For example if the payer enters the wrong PIN for a card transaction, it is common practice to display “Wrong PIN” in the terminal. The article should therefore be revised.
Article 2.1.b:
The article does note state a clear correlation between the payee and the issued transaction that can be used with regard to the validity (non-repudiation). This can be achieved by using a digital signature mechanism for the electronic payment transaction.
We are concerned, that requirements explained in Rationale 26 are conflicting with Rationale 34 when we talk about payment authorization using personal qualified certificates on e-identity smart cards or secure USB devices. The payment information (amount, payee) display in such cases is usually done in the same channel where the payment was initiated (e.g. the PC). We would like to see stronger assurance that payments authorized with qualified personal certificates under e-IDAS are compliant with RTS without exemptions."
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 welcome the reasoning about the flexibility offered on where and when the dynamic linking can take place. That one app triggers another app is positive for the customer experience which in turn drives an increased use of strong customer authentication by the customers.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?
The threats identified are well described.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?
Contrary to EBA’s conclusion (in Rationale 54) not to propose exemptions based on a transaction-risk analysis performed by the ASPSP, we do not believe that the EBA fulfils its mandate with regard to PSD2 Art. 98.3(a): exemptions based on “the level of risk involved in the service provided”, since the exemptions in the current draft RTS do not allow for a risk-based assessment / approach by the ASPSP.Additionally, the list of exemptions should not be an exhaustive list. The ASPSP must be free to apply exemptions based on its own transaction risk analysis. An exhaustive list of possible exemptions or criteria to be considered by ASPSPs for the transaction risk analysis may prevent future innovations in fraud prevention analysis that are to be expected in this dynamic and changing environment. This means that the ASPSP must have the possibility to apply strong customer authentication even though formally exceptions would apply.
We strongly suggest that a digital signature should be used for credit transfers except for low value payments specified as exemptions.
Article 8.1.a.ii:
The ASPSPs want freedom of choice on when to perform strong customer authentication.
For example, if there are indications that the credentials have been compromised (based on transaction analysis, identity theft, malware etc.) the ASPSPs need to be able to require strong customer authentication more often than every 30th day. The reason for this is consumer protection and that the ASPSP must decide on the frequency to verify that the customer is active and that the ASPSPs are responsible to verify issued credentials.
Article.8.1.b:
The word “contactless” should be deleted. The RTS in general and the exemptions from strong customer authentication should ensure technological neutrality, which the EBA states in rationale 50. This principle should be upheld also for low value payments at point of sale.
In the draft RTS EBA state that only contactless electronic payment transactions should be subject to a low value exemption from strong customer authentication in order to preserve the high level of security provided by “chip & pin”. This motivation is not logical - contact without PIN transactions cannot be deemed less safe than contactless without PIN, on the contrary they are safer.
We would like to highlight that some of the major card schemes operating in Europe allow for “contact” payment transactions without PIN for small amounts (e.g. vending machines) and also for larger amounts (e.g. parking/tolls). In several cases, such as unattended parking terminals, exemptions on the PIN requirement are also done for security reasons, i.e. in order for the PIN not to be compromised by usage in a physical environment with high visibility.
Therefore, our view is that the exemption from strong customer authentication defined in article 8 (b) must be extended to also cover “contact” electronic payment transactions on the condition that the payment instrument used can be securely authenticated, i.e. the word “contactless” should be removed in Article 8.
Article 8.2.b:
Recurring card payments should enjoy the same exemption as recurring credit transfers, as pointed out in comment to Rationale 17, i.e. paragraph 2 in Article 8 should be updated accordingly:
“(b) the payer initiates online a series of credit transfers or card-based payments with the same amount and the same payee.
The application of strong customer authentication shall not be exempted where the payer initiates the series of credit transfers or card-based payments for the first time or amends the series of credit transfers.”
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?
We are of the opinion that the exemptions must be optional for ASPSPs. Applying exemptions should enhance and improve the customer experience. To introduce measures which are less convenient for the customer is inappropriate. Please refer to answer on question 4.We understand that the application of the exemptions is optional for the payer’s PSP (the issuer in a card context). Preventing the implementation of stronger security would be against all principles of rationality and common sense. Issuers take risks through liabilities and may be limited by regulations towards not taking too high risks. But regulations should never refrain issuers from lowering their risks, e.g. through mandating security exemptions. Such an approach would indirectly induce also drastic reactions instead of proper risk-based reactions, should Issuers be confronted with new threats specifically targeting any of the exemption scenarios (e.g. massive low risk transaction fraud). Mandating exemptions could also result in unresolved situations that prevent ASPSPs to comply with other regulations (e.g. national) imposing more strict requirements.
Furthermore, the idea of allowing exemptions from the requirement on strong customer authentication, is to allow the possibility to make payment initiation more convenient for the payers. The underlying assumption being that strong customer authentication always creates a hustle or at least a slower payment initiation. With the escalating innovation in customer authentication methods and technology, this is no longer the case, and will be even less so in the future. Many times these new strong authentication methods are more customer-friendly and convenient, than many weak authentication methods like e.g. static passwords. For payment solutions where there is today only a strong customer authentication method offered for all transactions, which is perceived as convenient by the users, there is no need to introduce another weak customer authentication method, that would at the same time be less customer-friendly.
Article 8:
Item 2(a) is contradictive to article 2.1(b) requiring signing of the amount and payee of the payment initiation. E.g. if a payment through a PISP is done for an e-merchant with strong customer authentication and the e-merchant is amended as trusted beneficiary (again through strong customer authentication). Should subsequent purchases (regardless of amount) at that e-merchant really be possible without strong customer authentication? Please elaborate.
Article 8.1.a.ii:
We believe that it is the ASPSP’s responsibility to check whether or not the exemptions could be abused but this seems slightly unclear. Could you please elaborate?
It is stated that strong customer authentication is not required for 30 days. Today our online channels have a time out of several minutes, this to ensure protection of customer data. Is it really feasible to allow access without strong customer authentication for such a long period of time? Is it also feasible to allow customers through TPPs (according to the 2 times a day rule) access for such a long time without strong customer authentication?
One problem that can arise is that the consumer ends its engagement with the TPP but the TPP is still allowed up to 30 days without the customer consenting (according to the 2 times a day rule) since the PSPs cannot control if the consumer has ended the agreement with the TPP.
See also our answer to question 10.
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?
We agree with EBA’s reasoning and conclusions.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?
We would like to see more details about the PSU’s consent/mandate given to the AISP for inquiring account information from the ASPSP, particularly:- Which party is responsible for providing information about rights and risks to the PSU: AISP or ASPSP;
- Should PSU be allowed to revoke their consent for account information inquiry, and if so – how.
We would like to see clarification of the term “payment account information”. What specific account information is falling under this term: account balance, account statement (i.e. list of historical transactions on account)?
We would also like RTS to address the case when multiple authorisations / signatures are needed to initiate a payment (e.g. corporate customer, where more than one representative of the company must authorize payment instruction). In such cases, is ASPSP obliged to offer payment initiation service for PISPs, if such a service is available via its own internet banking service?
Another question is whether PSU should or could have a possibility to submit their will to the ASPSP to deny any requests coming from AISP or PISP on behalf of that PSU (i.e. “opt-out” from the TPP intermediation model in fear of possible fraud attacks via this vector).
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?
We are in favor of using ISO 20022 elements, where available, for communication between PSPs.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 support the approach of using only qualified certificates, issued by “qualified trust service providers” (under eIDAS regulation - Article 3 (20)), for PSP identification.We think that the RTS proposal to use website certificates" for AISP and PISP identification towards ASPSP is not correct, because “website certificates” are used to identify a server to the client but not a client to the server. Instead our suggestion is to use “electronic seals” and “qualified certificates for electronic seals”’ (eIDAS Article 3 (27), (30)) for that purpose. The right use of such method (provided certain data elements are included in the certificate) would allow ASPSP to identify any third party (legal person) with full assurance of its registration number, which would in turn allow to obtain required data about the AISP / PISP from the public register defined in Article 14 of Directive (EU) 2015/2366, and make the decision if to grant the service.
Our view is that methods used for identification of AISP/PISP towards ASPSP have no relation to the capabilities or suitability of various types of devices to carry out payment services, as this is identification between institutions and not the end-user (PSU)."
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.
We agree that when AISP is requesting information from ASPSP without active PSU request, a limit of no more than 2 times per day (per account) should be set.However, we think there should not be any strict requirements for ASPSP regarding requested data amount (e.g. the historical length of an account statement) or performance (e.g. response time) and these conditions should depend on technical capabilities of a particular ASPSP, i.e. the load of its systems. If needed, ASPSP should have the possibility to limit account information requests to prevent systems’ failure.
Additionally we think that if account balance or details of payment transactions on account (like payment amount, payee name) are considered “sensitive payment information” by ASPSP (because this information can be used for social engineering fraud schemes), then ASPSP should be able to require strong customer authentication on every account information request from AISP.