Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
1) Merchant shop systems and payment service provider (backend) systems (especially if they are accessed via the internet) need to be secured against unauthorized access by third parties and protected by strong authentication. Even if there is no sensitive PSU data available in those systems, an unauthorized third party may be able to:
- initiate refunds for transactions (In some scenarios, this would allow an organized group of fraudsters to purchase goods, wait for the shipment to arrive and then initiate the refund in the merchant shop system, leaving the merchant with a loss of goods)
- obtain customer data such as full names, addresses, telephone numbers, email addresses, date and time of payment, payment method used, payment amounts and items ordered
It would be a useful clarification if the definition of a “payment account” in PSD2 Article 4 (12) would explicitly include merchant shop system and payment service provider back-ends.
Additionally it would be very useful if the definition of a payment service user (PSU) would explicitly include merchants as well.
2) We understand Article 4 (3) and the therein referred Annex I explicitly includes one-off direct debit transactions in the definition of a “payment service”. However, there seems to be a gap to Article 97 (1.a) “initiates an electronic payment transaction”, because the necessary one-off direct debit transaction mandate is usually not protected by strong authentication.
Due to the absence of national or European e-mandate schemes for SEPA direct debit transactions, the guidelines (in the “EBA Guidelines on the security of internet payments”) regarding e-Mandates for direct debits are failing to address a large portion of the internet payments in some EU member states such as Germany. In Germany, for example, it is currently practice to have one-time SEPA mandates for internet purchases without any further authorization (due to the absence of any national e-mandate regime). This practice has been ruled compliant to the “EBA Guidelines on the security of internet payments” by German regulator BaFin.
These one-time SEPA mandates for internet purchases are a major fraud loss contributor for payment service providers and e-commerce merchants in Germany
Regarding Article 97(1), the requirement to perform strong authentication when accessing a payment account online seems to be unnecessary. Considering the information contained in an online payment account is not sensitive according to the definition of the PSD2, there is no need in our opinion to perform strong authentication upon login into this online payment account.
As stated correctly in the discussion paper (32), the potential compromise of the mobile device compromises both authentication requirements.
Additionally, also applicable to transactions initiated from a traditional PC or laptop, it is almost impossible for a payment service provider to check if a strong authentication of a payment fulfills the independence requirement. For example if the pushTAN (knowledge) was received on the same device (possession) the payment was initiated on, the independence requirement is not fulfilled.
Transaction risk analysis as a process to identify low risk transactions is a valuable tool to avoid consumer dissatisfaction and enabling a fast and convenient online shopping experience.
However, there is no definition of a “low risk transaction”, which would result in payment service providers making their own decision on which transactions can be classified as low risk. Depending of the risk appetite of the respective payment service providers, the definition of a low risk transaction might be impacted by commercial interests rather than risk and security aspects.
Therefore, we would like to have a more concrete definition of “low risk transaction” in order to enable a level playing field between payment service providers and avoid a heavy impact of commercial considerations (by PSPs and merchants) on the security of internet payments.
Low value transactions are not per se less risky than transactions of higher value, especially considering some industries usually impacted by high fraud rates have rather low average transaction amounts (for example online gaming, online gambling, digital content).
Transaction risk analysis (including the suggestions in our answers to questions 7. and 9.) would be much more appropriate than a general exclusion of low value payments to ensure a consumer friendly online shopping experience in our opinion.
- Third party information such as consumer credit ratings, address verification services, public registers (where available and legal). These can be used for example to link payers to billing and/or delivery addresses (significantly reducing the risk of stolen financial instruments for the sale of physical goods)
- Analysis of a transaction compared to other transactions going through the system (including historic data). Useful data points for example could be: transactions to the same payee, same delivery address (including postcode and general geographic area), same or similar IP address (IP ranges), items purchased, transactions with similar details (Cards with the same BIN, bank accounts with the same BIC), time of transaction
- Analysis of IP and connection type, for example proxy IPs, VPN connections, IP anonymisation etc.
- Analysis of internal consistency and validity of payer data (address, phone number, post code & city etc.)
The EBA should consider the aspects of enrolment, creation, storage and distribution of strong authentication details and data in their upcoming RTS.
1) The payer (PSU): There are multiple attack vectors for criminals to get personal and sensitive payment data from payers (not necessarily limited to consumers). Phishing, malware, social engineering among others are widespread tools to get hold of personal or confidential information that can be used to steal identities, make payments and other unauthorized uses.
The best possible customer authentication and security is almost worthless if an account was setup and verified with a stolen identity
2) The payee: Similar to the payer, payees can be manipulated into giving access to data by phishing, social engineering and malware. Other than the payer situation, a breach at a payee usually results in multiple datasets being stolen (instead of just one) or higher financial impact for all parties involved.. Therefore increasing the impact.
3) Unencrypted email: Logins, passwords and payment details etc. are still sent via unencrypted mail from (online) payment institution and service providers to their customers. Apart from the fact if the vulnerability of an email account itself, unencrypted email in those cases may contain either login data including passwords or personal data that would allow third parties to assume the identity of a payer or payee.
1. With respect to Article 97(1) (c), are there any additional examples of transactions or actions implying a risk of payment fraud or other abuses that would need to be considered for the RTS? If so, please give details and explain the risks involved.
There are two main gaps in our opinion which have to be addressed in order to reduce internet payment fraud. There is also a clarification needed regarding Article 97(1)regarding the applicability of strong authentication when accessing a payment account online.1) Merchant shop systems and payment service provider (backend) systems (especially if they are accessed via the internet) need to be secured against unauthorized access by third parties and protected by strong authentication. Even if there is no sensitive PSU data available in those systems, an unauthorized third party may be able to:
- initiate refunds for transactions (In some scenarios, this would allow an organized group of fraudsters to purchase goods, wait for the shipment to arrive and then initiate the refund in the merchant shop system, leaving the merchant with a loss of goods)
- obtain customer data such as full names, addresses, telephone numbers, email addresses, date and time of payment, payment method used, payment amounts and items ordered
It would be a useful clarification if the definition of a “payment account” in PSD2 Article 4 (12) would explicitly include merchant shop system and payment service provider back-ends.
Additionally it would be very useful if the definition of a payment service user (PSU) would explicitly include merchants as well.
2) We understand Article 4 (3) and the therein referred Annex I explicitly includes one-off direct debit transactions in the definition of a “payment service”. However, there seems to be a gap to Article 97 (1.a) “initiates an electronic payment transaction”, because the necessary one-off direct debit transaction mandate is usually not protected by strong authentication.
Due to the absence of national or European e-mandate schemes for SEPA direct debit transactions, the guidelines (in the “EBA Guidelines on the security of internet payments”) regarding e-Mandates for direct debits are failing to address a large portion of the internet payments in some EU member states such as Germany. In Germany, for example, it is currently practice to have one-time SEPA mandates for internet purchases without any further authorization (due to the absence of any national e-mandate regime). This practice has been ruled compliant to the “EBA Guidelines on the security of internet payments” by German regulator BaFin.
These one-time SEPA mandates for internet purchases are a major fraud loss contributor for payment service providers and e-commerce merchants in Germany
Regarding Article 97(1), the requirement to perform strong authentication when accessing a payment account online seems to be unnecessary. Considering the information contained in an online payment account is not sensitive according to the definition of the PSD2, there is no need in our opinion to perform strong authentication upon login into this online payment account.
2. Which examples of possession elements do you consider as appropriate to be used in the context of strong customer authentication, must these have a physical form or can they be data? If so, can you provide details on how it can be ensured that these data can only be controlled by the PSU?
“Data” is a form of possession, which is presumably independent of its carrier, but in practice the carrier of the data strongly influences the quality of authentication. For example, if data is available inside a phone, it is easier to steal without being detected than if it is in the form of a QR code or a file on a separate USB stick. So, allowing the user to choose a medium that is not readily accessible might be useful to increase security but would come at the cost of convenience.3. Do you consider that in the context of “inherence” elements, behaviour-based characteristics are appropriate to be used in the context of strong customer authentication? If so, can you specify under which conditions?
We don’t consider behavior-based characteristics to be appropriate to be used in the context of strong customer authentication as an element of the authentication itself (i.e. as a replacement of one of the three types knowledge, possession and knowledge). However, behavioral characteristics are a very important tool in transaction risk analysis and can be used there to great effect.4. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to the independence of the authentication elements used (e.g. for mobile devices)?
Especially for mobile devices including tablets, a separation (independence) between possession (the device) and either knowledge (a one-time TAN sent to this device for example) or inherence (a biometric scanner, i.e. for fingerprints etc.) is challenging in practice. Please also keep in mind that many new PCs and laptops also have biometric scanners built in, which means the problem not only applies to mobile devices such as mobile phones, tablets etc.As stated correctly in the discussion paper (32), the potential compromise of the mobile device compromises both authentication requirements.
Additionally, also applicable to transactions initiated from a traditional PC or laptop, it is almost impossible for a payment service provider to check if a strong authentication of a payment fulfills the independence requirement. For example if the pushTAN (knowledge) was received on the same device (possession) the payment was initiated on, the independence requirement is not fulfilled.
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
n/a6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
n/a7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
We are considering the clarifications to be useful, but not extensive enough.Transaction risk analysis as a process to identify low risk transactions is a valuable tool to avoid consumer dissatisfaction and enabling a fast and convenient online shopping experience.
However, there is no definition of a “low risk transaction”, which would result in payment service providers making their own decision on which transactions can be classified as low risk. Depending of the risk appetite of the respective payment service providers, the definition of a low risk transaction might be impacted by commercial interests rather than risk and security aspects.
Therefore, we would like to have a more concrete definition of “low risk transaction” in order to enable a level playing field between payment service providers and avoid a heavy impact of commercial considerations (by PSPs and merchants) on the security of internet payments.
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
In our opinion, a general exclusion of low value payments (even considering the requirement for ongoing monitoring of cumulative transactions) is misleading and potentially dangerous.Low value transactions are not per se less risky than transactions of higher value, especially considering some industries usually impacted by high fraud rates have rather low average transaction amounts (for example online gaming, online gambling, digital content).
Transaction risk analysis (including the suggestions in our answers to questions 7. and 9.) would be much more appropriate than a general exclusion of low value payments to ensure a consumer friendly online shopping experience in our opinion.
9. Are there any other criteria or circumstances which the EBA should consider with respect to transaction risks analysis as a complement or alternative to the criteria identified in paragraph 45?
There are multiple other criteria that can be included in transaction risk analysis. The following ones are in our opinion valuable to be included as a requirement (if applicable for the specific payment instrument chosen) in order to have a minimum standard of transaction risk analysis.- Third party information such as consumer credit ratings, address verification services, public registers (where available and legal). These can be used for example to link payers to billing and/or delivery addresses (significantly reducing the risk of stolen financial instruments for the sale of physical goods)
- Analysis of a transaction compared to other transactions going through the system (including historic data). Useful data points for example could be: transactions to the same payee, same delivery address (including postcode and general geographic area), same or similar IP address (IP ranges), items purchased, transactions with similar details (Cards with the same BIN, bank accounts with the same BIC), time of transaction
- Analysis of IP and connection type, for example proxy IPs, VPN connections, IP anonymisation etc.
- Analysis of internal consistency and validity of payer data (address, phone number, post code & city etc.)
10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
It would be beneficial to include examples for channels and technical components which are deemed insecure, for example unencrypted email.11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
One important aspect missing more details and requirements regarding the strong authentication is the creation and storage of authentication data (by the PSU or a third party), the security of the enrolment process to any authentication scheme and possibly the distribution of the same authentication method across multiple services, creating a single point of failure.The EBA should consider the aspects of enrolment, creation, storage and distribution of strong authentication details and data in their upcoming RTS.
12. Have you identified innovative solutions for the enrolment process that the EBA should consider which guarantee the confidentiality, integrity and secure transmission (e.g. physical or electronic delivery) of the users’ personalised security credentials?
n/a13. Can you identify alternatives to certification or evaluation by third parties of technical components or devices hosting payment solutions, to ensure that communication channels and technical components hosting, providing access to or transmitting the personalised security credential are sufficiently resistant to tampering and unauthorized access?
n/a14. Can you indicate the segment of the payment chain in which risks to the confidentiality, integrity of users’ personalised security credentials are most likely to occur at present and in the foreseeable future?
There are in our opinion three segments in the payment chain, which are most likely to threaten the integrity of personalized security details:1) The payer (PSU): There are multiple attack vectors for criminals to get personal and sensitive payment data from payers (not necessarily limited to consumers). Phishing, malware, social engineering among others are widespread tools to get hold of personal or confidential information that can be used to steal identities, make payments and other unauthorized uses.
The best possible customer authentication and security is almost worthless if an account was setup and verified with a stolen identity
2) The payee: Similar to the payer, payees can be manipulated into giving access to data by phishing, social engineering and malware. Other than the payer situation, a breach at a payee usually results in multiple datasets being stolen (instead of just one) or higher financial impact for all parties involved.. Therefore increasing the impact.
3) Unencrypted email: Logins, passwords and payment details etc. are still sent via unencrypted mail from (online) payment institution and service providers to their customers. Apart from the fact if the vulnerability of an email account itself, unencrypted email in those cases may contain either login data including passwords or personal data that would allow third parties to assume the identity of a payer or payee.