Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
In our opinion, the draft RTS provided by EBA doesn’t fulfill the PSD2 mandate to implement requirements of SCA and the requirements of exemptions to SCA by focusing almost completely on very narrow use cases (such as payments between accounts held by the same user with the same PSP) or low value transactions. The risk of a transaction is very narrowly defined by the EBA based on the amount of the transaction.
Additionally, PaySquare acknowledges the focus of the draft RTS is on technology and technological solutions to reduce fraud in payments.
However, there are two effects this focus has in our opinion:
1. Exclusion
Many of the solutions to provide SCA are very much focused on state of the art technology, which is (at least at first) only available to a limited number of people. Smartphones with scanners for biometrics etc. are available but costly. This would lead to an exclusion of a substantial number of people from everyday processes like online-shopping or other activities involving remote payments.
This has a negative effect on the growth objective.
Additionally, considering the timeline the regulation will come into effect, it seems unlikely the technology available at this point in time will be able to support the SCA requirements for a majority of the population in Europe. This will have a negative effect on growth of the e-Commerce business in Europe.
2. Awareness and operational processes
The focus on technology might lead to a loss of focus on awareness (by consumers, merchants, PSPs) about security of payments and a loosening of operational procedures and processes to reduce fraud due to the technological solutions in place. Many successful fraud attacks are the result of social engineering or weak operational processes.
Please also take note of the fact these operational best practice procedures are important for entities not in scope of the PSD2 or not even a financial institution per se. Any operational best practice guide or regulation has to keep in scope any service provider with an impact on the security of possession and inherence elements.
For example a telecommunications provider is in control of SIM-cards. Recent fraud types involving the replacement of SIM cards to unauthorized third parties using those to circumvent SMS-TAN security measures have shown this vulnerability.
In our opinion, the draft RTS provided by EBA doesn’t fulfill the PSD2 mandate to implement the exemptions to the SCA requirements by focusing almost completely on very narrow use cases (such as payments between accounts held by the same user with the same PSP) or low value transactions. The risk of a transaction is very narrowly defined based on the amount of the transaction by the EBA.
We disagree especially on the topics of exemptions based on transaction risk analysis.
In our opinion, the current draft actually doesn’t fulfil the mandate. The PSD2 requirements as given in Art. 98 explicitly mention in (a) “the level of risk in the service provided”. By focusing solely on the amount of the transaction and some narrow use cases of recurring transactions, EBA doesn’t fulfil the mandate to include exemptions based on the level of risk with the service provided.
In our opinion, EBA doesn’t have the mandate to ignore Art. 98 (3a) of the PSD2.
Transaction Risk Analysis
PaySquare disagrees on the removal of a classification of transactions as low risk (and therefore exempt from SCA) following a transaction risk analysis from the draft RTS (as compared to the previous guidelines or the discussion paper).
Forcing a consumer into a SCA every time (except for a rather limited set of exemptions) he/she makes a remote electronic payment is a brute force method of security that is neither user friendly nor does it provide any incentives for the payments industry to make smart decisions during the transaction process and investing into data analytics technology and analytical capabilities. This is a clear contradiction to the goal of supporting growth by the PSD2.
From a consumer point of view, it is not a good user experience for a consumer shopping (for example) regularly at the same merchant with the same details (i.e. average amount spent, delivery address, IP details etc.) to go through an SCA process. It doesn’t add any additional security to the transaction and doesn’t prevent any fraud, because there was none in the first place (in this example).
Transactional risk analysis done right is a great tool to make an analytical decision on the level of risk involved with any remote electronic payment transaction. It can be used to make smart decisions and ask a payer for a strong authentication as the owner of the used payment instrument if there is a higher than low risk involved with the transaction.
Additionally, enforcing SCA on all but a few transactions could have the effect of payers moving to less secure payment methods not in scope of the regulation or payment methods with less or no consumer protection against non-delivery of goods (bank transfers, money remittance, sending cash via physical mail etc.). By enforcing SCA without exemptions based on transaction risk analysis, EBA might ultimately make remote payments less secure.
PaySquare asks EBA to allow exemptions to SCA based on a transaction risk analysis and to provide basic requirements for a transaction risk analysis based exemption to SCA.
Failure to do so will be contradictory to the growth objective of the PSD2.
Low transaction amounts don’t equal low risk
As mentioned already in our response to the discussion paper, a low value transaction is not automatically a low risk transaction. Some industries (for example online gaming) have rather low average transaction values, but comparatively high rates of fraud.
In our opinion, transaction risk analysis is a much better tool to determine risk of transactions in this environment than a flat 10 Euro threshold per transaction (or cumulative amount of 100 Euro for a single payment instrument) .
Recurring transactions
PaySquare has objections regarding the exemption restriction of recurring payments (“a series of credit transfers”) to a series with the same amount. Many subscription based business models in e-commerce today and even more so in the near future, will rely on being flexible regarding the specific amount to be paid each time. For example utility bills can be paid with subscriptions models already today and in many markets, the monthly amount changes depending on usage.
The restriction based on “same amount” doesn’t add any additional security or protection against unauthorized use of the payment instrument, considering the setting up of the series of credit transfers was verified with SCA.
Considering enabling growth is one of the key goals of the PSD2, the restriction on same amount subscriptions will severely hinder growth in e-commerce and possibly remove some business models completely.
Additional Remarks:
PaySquare welcomes the clarification provided in recital (41) on page 14, clarifying exemptions to SCA as defined in the draft RTS are performed by the Payer’s PSP and should applied by it only. However, PaySquare would welcome the inclusion of this remark in the text of the RTS itself to provide a clear and concise message to the industry.
PSPs should be able – based on transaction risk analysis – enforce SCA on transactions below the single transaction or cumulative value thresholds. Failing to do so would lead to a migration of fraudulent payments to amounts just below the thresholds. Fraudsters have proven to be very mobile and able to adjust to fixed thresholds in the past and they will do so in the future.
On the topic of integrity of personalized security credentials, especially on inherence elements such as finger prints, iris scans and similar items, PaySquare is worried about the possibility of identity theft using cloned inherence items. Finger prints and iris scans in particular have proven to be insecure as they can be copied and bypass some of the scans currently on the market.
Additionally, how a stolen identity using stolen inherence elements can be restored to the original person these belong to is an open question. In our opinion, this has to be addressed.
Due to industry standards, i.e. PCI DSS on the security and storage of payment card data, affected PSPs and merchants are trying to store only as much payment data as necessary for their operations. For example for card payments, acquirers are not storing the full credit card number usually.
Forcing acquirer such as PaySquare to store all transaction data including card numbers in order to provide traceability (on their own), would result in additional large investments to meet the compliance requirements of the technical standards and other industry security standards such as PCI DSS.
Additionally, payment card data (as an example for relevant transaction data) would be stored in many more locations than nowadays and therefore the probability of the data being stolen would increase. This is contradictory to the goal of the RTS and the PSD2 in our opinion.
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?
PaySquare SE agrees with the reasoning on the requirements for strong customer authentication in principle, but doesn’t agree with all conclusions made by EBA.In our opinion, the draft RTS provided by EBA doesn’t fulfill the PSD2 mandate to implement requirements of SCA and the requirements of exemptions to SCA by focusing almost completely on very narrow use cases (such as payments between accounts held by the same user with the same PSP) or low value transactions. The risk of a transaction is very narrowly defined by the EBA based on the amount of the transaction.
Additionally, PaySquare acknowledges the focus of the draft RTS is on technology and technological solutions to reduce fraud in payments.
However, there are two effects this focus has in our opinion:
1. Exclusion
Many of the solutions to provide SCA are very much focused on state of the art technology, which is (at least at first) only available to a limited number of people. Smartphones with scanners for biometrics etc. are available but costly. This would lead to an exclusion of a substantial number of people from everyday processes like online-shopping or other activities involving remote payments.
This has a negative effect on the growth objective.
Additionally, considering the timeline the regulation will come into effect, it seems unlikely the technology available at this point in time will be able to support the SCA requirements for a majority of the population in Europe. This will have a negative effect on growth of the e-Commerce business in Europe.
2. Awareness and operational processes
The focus on technology might lead to a loss of focus on awareness (by consumers, merchants, PSPs) about security of payments and a loosening of operational procedures and processes to reduce fraud due to the technological solutions in place. Many successful fraud attacks are the result of social engineering or weak operational processes.
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.
PaySquare agrees with EBA’s reasoning about when the dynamic linking should take place. However, we would like to add that the dynamic linking (and the respective SCA) should take place before the payment is processed.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?
On the elements of possession and inherence, PaySquare is of the opinion technological solutions should be accompanied by best practices and/or regulation for operational procedures in order to prevent social engineering and other, similar attacks, which aim to circumvent the possession element (and to some extent the element of inherence).Please also take note of the fact these operational best practice procedures are important for entities not in scope of the PSD2 or not even a financial institution per se. Any operational best practice guide or regulation has to keep in scope any service provider with an impact on the security of possession and inherence elements.
For example a telecommunications provider is in control of SIM-cards. Recent fraud types involving the replacement of SIM cards to unauthorized third parties using those to circumvent SMS-TAN security measures have shown this vulnerability.
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?
PaySquare SE agrees partly with the reasoning on the requirements for strong customer authentication, but doesn’t agree with all conclusions made by EBA.In our opinion, the draft RTS provided by EBA doesn’t fulfill the PSD2 mandate to implement the exemptions to the SCA requirements by focusing almost completely on very narrow use cases (such as payments between accounts held by the same user with the same PSP) or low value transactions. The risk of a transaction is very narrowly defined based on the amount of the transaction by the EBA.
We disagree especially on the topics of exemptions based on transaction risk analysis.
In our opinion, the current draft actually doesn’t fulfil the mandate. The PSD2 requirements as given in Art. 98 explicitly mention in (a) “the level of risk in the service provided”. By focusing solely on the amount of the transaction and some narrow use cases of recurring transactions, EBA doesn’t fulfil the mandate to include exemptions based on the level of risk with the service provided.
In our opinion, EBA doesn’t have the mandate to ignore Art. 98 (3a) of the PSD2.
Transaction Risk Analysis
PaySquare disagrees on the removal of a classification of transactions as low risk (and therefore exempt from SCA) following a transaction risk analysis from the draft RTS (as compared to the previous guidelines or the discussion paper).
Forcing a consumer into a SCA every time (except for a rather limited set of exemptions) he/she makes a remote electronic payment is a brute force method of security that is neither user friendly nor does it provide any incentives for the payments industry to make smart decisions during the transaction process and investing into data analytics technology and analytical capabilities. This is a clear contradiction to the goal of supporting growth by the PSD2.
From a consumer point of view, it is not a good user experience for a consumer shopping (for example) regularly at the same merchant with the same details (i.e. average amount spent, delivery address, IP details etc.) to go through an SCA process. It doesn’t add any additional security to the transaction and doesn’t prevent any fraud, because there was none in the first place (in this example).
Transactional risk analysis done right is a great tool to make an analytical decision on the level of risk involved with any remote electronic payment transaction. It can be used to make smart decisions and ask a payer for a strong authentication as the owner of the used payment instrument if there is a higher than low risk involved with the transaction.
Additionally, enforcing SCA on all but a few transactions could have the effect of payers moving to less secure payment methods not in scope of the regulation or payment methods with less or no consumer protection against non-delivery of goods (bank transfers, money remittance, sending cash via physical mail etc.). By enforcing SCA without exemptions based on transaction risk analysis, EBA might ultimately make remote payments less secure.
PaySquare asks EBA to allow exemptions to SCA based on a transaction risk analysis and to provide basic requirements for a transaction risk analysis based exemption to SCA.
Failure to do so will be contradictory to the growth objective of the PSD2.
Low transaction amounts don’t equal low risk
As mentioned already in our response to the discussion paper, a low value transaction is not automatically a low risk transaction. Some industries (for example online gaming) have rather low average transaction values, but comparatively high rates of fraud.
In our opinion, transaction risk analysis is a much better tool to determine risk of transactions in this environment than a flat 10 Euro threshold per transaction (or cumulative amount of 100 Euro for a single payment instrument) .
Recurring transactions
PaySquare has objections regarding the exemption restriction of recurring payments (“a series of credit transfers”) to a series with the same amount. Many subscription based business models in e-commerce today and even more so in the near future, will rely on being flexible regarding the specific amount to be paid each time. For example utility bills can be paid with subscriptions models already today and in many markets, the monthly amount changes depending on usage.
The restriction based on “same amount” doesn’t add any additional security or protection against unauthorized use of the payment instrument, considering the setting up of the series of credit transfers was verified with SCA.
Considering enabling growth is one of the key goals of the PSD2, the restriction on same amount subscriptions will severely hinder growth in e-commerce and possibly remove some business models completely.
Additional Remarks:
PaySquare welcomes the clarification provided in recital (41) on page 14, clarifying exemptions to SCA as defined in the draft RTS are performed by the Payer’s PSP and should applied by it only. However, PaySquare would welcome the inclusion of this remark in the text of the RTS itself to provide a clear and concise message to the industry.
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 mentioned already, PaySquare is of the opinion that low amounts (10 Euro for remote and 50 Euro for contactless transactions) are not by definition low risk. The risk of a transactions is a sum of many factors including the consumer history, merchant, item bought, location, etc. . Amount is one of these.PSPs should be able – based on transaction risk analysis – enforce SCA on transactions below the single transaction or cumulative value thresholds. Failing to do so would lead to a migration of fraudulent payments to amounts just below the thresholds. Fraudsters have proven to be very mobile and able to adjust to fixed thresholds in the past and they will do so in the future.
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?
PaySquare agrees with the reasoning, but would like to see an additional focus on operational procedures, processes and best practices to go hand-in-hand with regulation on technical standards. Please see also our answer to Q2 for more details.On the topic of integrity of personalized security credentials, especially on inherence elements such as finger prints, iris scans and similar items, PaySquare is worried about the possibility of identity theft using cloned inherence items. Finger prints and iris scans in particular have proven to be insecure as they can be copied and bypass some of the scans currently on the market.
Additionally, how a stolen identity using stolen inherence elements can be restored to the original person these belong to is an open question. In our opinion, this has to be addressed.
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?
PaySquare is concerned about parts of the provision in Article 18 (“Traceability”). PSPs are required to provide traceability “of all relevant transaction data in all the various stages”.Due to industry standards, i.e. PCI DSS on the security and storage of payment card data, affected PSPs and merchants are trying to store only as much payment data as necessary for their operations. For example for card payments, acquirers are not storing the full credit card number usually.
Forcing acquirer such as PaySquare to store all transaction data including card numbers in order to provide traceability (on their own), would result in additional large investments to meet the compliance requirements of the technical standards and other industry security standards such as PCI DSS.
Additionally, payment card data (as an example for relevant transaction data) would be stored in many more locations than nowadays and therefore the probability of the data being stolen would increase. This is contradictory to the goal of the RTS and the PSD2 in our opinion.