Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
However we do not agree with the requirement that an authentication code must be generated “each time that the payer … initiates an electronic transaction or carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.” This requirement disregards the existence and industry acceptance of risk-based authentication (RBA).
RBA forces the payer to respond to a step up authentication challenge (e.g., provide a unique authentication code) for risky payments only – low risk payments are passed through without intervention and payers do not need to take any additional action. The authentication engine analyzes a range of indicators to score each transaction based on its level of risk. RSA’s Risk Engine analyzes over 100 different indicators including device, behavior and the eFraudNetwork, a cross-industry repository of confirmed fraud. Some risk-based solutions, including RSA’s, also offer a policy manager so that financial institutions can align their authentication strategy with their risk tolerance and business priorities.
The EBA in fact recognizes a risk-based approach to payment security in the Executive Summary of the Consultation Paper, which states that the paper along with the legislation itself aspires to ensure “an appropriate level of security for consumers and Payment Service Providers, through the adoption of effective and risk-based requirements, securing and maintaining fair competition among all PSPs and allowing for the development of user-friendly, accessible and innovative means of payment.”
Using this same logic, RSA would argue that the requirements for “dynamic linking” outlined in Article 2 should not be applied to each and every transaction. Although RSA is a strong proponent of technologies such as transaction signing that can provide a payer with transaction details, applying it to every transaction will not deliver a user-friendly payer experience for the approximately 95% of transactions that are low risk.
As noted above, the EBA identifies in Article 1.3 a range of mechanisms that should complement the use of a one-time authentication code. These mechanisms are designed to provide a more reliable indication of whether the payment is legitimate and being executed by the named payer. Using that information not only to identify risky payments but to identify low risk payments is a logical extension.
In addition, user behavior should be considered in addition to device capabilities for “something the consumer is” (Article 5). Tracking user behavior throughout the session enables anomalies to be detected before the payment transaction is initiated, providing additional information for use in risk analysis.
However RSA does not agree with the EBA’s definition of a “low risk payment” as one that falls below a particular monetary threshold. Fraudsters can exploit fixed and predictable thresholds and often test the validity of credit cards and accounts by initiating low value payments or transfers. If the fraudulent, low value payment or transfer executes successfully, they will initiate a larger, fraudulent payment. In addition, fraudsters have been known to initiate other “low risk” activities such as checking the balance of an account before changing a password and expropriating funds or leveraging it as a mule account.
Rather, RSA posits that a low-risk transaction is one that is reasonably believed to have been initiated by the true account owner.
Risk should not be correlated with value but with level of confidence that the individual initiating the transaction is in fact the legitimate account owner. Therefore the question around what constitutes a “low risk” payment shouldn’t be “does this payment fall below the threshold” but “how confident am I that the payer is who he says he is?”
In addition, as noted above RSA agrees with the EBA’s reasoning behind identifying objections to a SCA requirement. However we believe that the merits of transaction risk analysis which balances strong security with consumer convenience far outweigh the need for a specific and limited list of exemptions. RSA believes that the EBA should retain a principles-based approach for the exemptions. This will cultivate innovation for transaction risk analysis plus strong customer authentication. Within the third party PSP environment, the ASPSP and PSPs could use the communication interface to exchange the risk and authentication details.
Ultimately it is the banks and card issuers who own the liability for fraudulent payments. Each of these banks and issuers has a different risk tolerance and business priorities. If the EBA takes a principles-based approach rather than specifying a list of exemptions to SCA, those banks and issuers can define the risk thresholds and policies that make sense for their consumers.
Failure to exempt risk-based analysis of transactions will negatively impact payer experience without improving fraud detection. In fact, challenging each and every transaction regardless of level of risk could have the unanticipated and undesirable effect of increasing fraud due to payer “alert fatigue.” If payers are accustomed to using a one-time authentication code for every transaction, they are less likely to closely examine their transactions. This Pavlovian response could in turn embolden fraudsters to increase their efforts at intercepting and diverting legitimate transactions, further increasing fraud.
In addition, requiring SCA for every transaction regardless of risk could threaten economic growth. Forcing consumers to authenticate each and every transaction will reduce the number of completed transactions, which in and of itself would slow growth. Plus there is an expense for generating a one-time password for each and every transaction. The additional expense incurred in an environment with fewer completed transactions will be passed along to consumers in the form of higher prices for goods and services, further inhibiting economic growth.
Section 54 of the Consultation Paper notes that risk-based transaction analysis will not be exempted because, “…the EBA was not able to identify which minimum set of information the RTS should require for such transaction risk analysis to be sufficiently reliable to allow a specific exemption from the application of SCA, while also ensuring a fair competition among all payment service providers.”
The goal of maintaining a level playing field is a laudable one. However the lack of a minimum set of standards will not adversely impact competitiveness among PSPs because it doesn’t take into account PSP business priorities – PSPs have a vested interest in preventing fraud. PSPs, simply out of self-interest, will not adopt a risk-based authentication solution that can’t deliver strong fraud detection rates simply to comply with EBA regulations. Adopting an ineffective risk-based authentication solution could impact profitability perhaps to an even greater degree than providing a negative payer experience would.
In short, the industry will police itself in this regard.
Please note that the payments industry itself has embraced a risk-based approach as a way to balance strong security with consumer convenience.
For example EMVCo, the international standards body owned by six of the leading card schemes and tasked with developing the 3D Secure 2.0 payment authentication protocol, has made risk-based authentication a foundation of the revised protocol. The card brands themselves, including MasterCard and Visa, have announced that they are retiring passwords and plan to take a risk-based approach to authentication of transactions.
RSA has been providing card issuers with risk-based 3D Secure services since 2009 and has sustained fraud detection rates in the mid-ninety percent rage over many years. These high detection rates have been achieved with very low false positives and an average intervention rate of just ~5%. With RSA’s risk-based authentication solution for card issuers, ~95% of transactions are allowed to pass through without intervention from the cardholder.
Likewise, our risk-based consumer authentication solution for bank account logins and transactions has consistently delivered fraud prevention rates of approximately 92% for logins and 94% for transactions with only a 3% intervention rate.
Risk-based authentication works.
Risk-based authentication is a viable and preferred option over a 100% challenge with one-time authentication code and RSA strongly advises that if the EBA opts not to take a principles-based approach that it be included in the exemptions listed in Chapter 2. Risk-based authentication of payments dramatically improves payer experience and reduces fraud. Requiring SCA for every transaction regardless of risk could stifle innovation in the payments space and have the unintended consequence of driving more fraud. In addition, the increased cost of facilitating transactions in an environment where all transactions are challenged will be passed along to consumer in the form of more expensive goods and services, adversely impacting economic growth.
Moreover, requiring SCA for every transaction also fails to take into account the fact that the majority of transactions are in fact legitimate.
RSA strongly recommends that the committee reconsider the position outlined in the Consultation Paper and, if the EBA does not adopt a principles-based approach, exempt risk-based authentication solutions from SCA requirements.
Analyzing the risk associated with a transaction yields better results when pairing the transaction data and user data with the data of the electronic device used to execute the transaction (hereafter ‘device’), which is not part of ISO 20022 elements. In fact the EBA in Article 1.3 acknowledges that other mechanisms including device identification should be included in SCA.
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?
RSA agrees in general with the EBA’s reasoning around the requirements of strong customer authentication (SCA), particularly with the provision contained in Article 1. 3, which outlines the mechanisms that should be included in SCA. Configurable policies, malware detection, transaction history, device identification and payer and device risk profiles complement unique authentication codes and RSA strongly supports their use to help identify high-risk payments.However we do not agree with the requirement that an authentication code must be generated “each time that the payer … initiates an electronic transaction or carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.” This requirement disregards the existence and industry acceptance of risk-based authentication (RBA).
RBA forces the payer to respond to a step up authentication challenge (e.g., provide a unique authentication code) for risky payments only – low risk payments are passed through without intervention and payers do not need to take any additional action. The authentication engine analyzes a range of indicators to score each transaction based on its level of risk. RSA’s Risk Engine analyzes over 100 different indicators including device, behavior and the eFraudNetwork, a cross-industry repository of confirmed fraud. Some risk-based solutions, including RSA’s, also offer a policy manager so that financial institutions can align their authentication strategy with their risk tolerance and business priorities.
The EBA in fact recognizes a risk-based approach to payment security in the Executive Summary of the Consultation Paper, which states that the paper along with the legislation itself aspires to ensure “an appropriate level of security for consumers and Payment Service Providers, through the adoption of effective and risk-based requirements, securing and maintaining fair competition among all PSPs and allowing for the development of user-friendly, accessible and innovative means of payment.”
Using this same logic, RSA would argue that the requirements for “dynamic linking” outlined in Article 2 should not be applied to each and every transaction. Although RSA is a strong proponent of technologies such as transaction signing that can provide a payer with transaction details, applying it to every transaction will not deliver a user-friendly payer experience for the approximately 95% of transactions that are low risk.
As noted above, the EBA identifies in Article 1.3 a range of mechanisms that should complement the use of a one-time authentication code. These mechanisms are designed to provide a more reliable indication of whether the payment is legitimate and being executed by the named payer. Using that information not only to identify risky payments but to identify low risk payments is a logical extension.
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.
Yes. RSA agrees with the EBA’s reasoning that the requirements should remain neutral as to when the “dynamic linking” takes place as long as the amount and payee are delivered out of band (i.e., not using the same channel, mobile app or device as that used to initiate the payment) and the payer has the ability to cancel the payment if it is not one that he initiated.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?
RSA would like to include social engineering, which could be leveraged to acquire “something the consumer knows” (Article 3) or “something the consumer has” (Article 4).In addition, user behavior should be considered in addition to device capabilities for “something the consumer is” (Article 5). Tracking user behavior throughout the session enables anomalies to be detected before the payment transaction is initiated, providing additional information for use in risk analysis.
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?
RSA agrees with the EBA’s reasoning around why exemptions should be considered when the EBA “acknowledges the benefit to allow the development for user-friendly and accessible means of payments for low-risk payments.” (Consultation Paper, Section 40).However RSA does not agree with the EBA’s definition of a “low risk payment” as one that falls below a particular monetary threshold. Fraudsters can exploit fixed and predictable thresholds and often test the validity of credit cards and accounts by initiating low value payments or transfers. If the fraudulent, low value payment or transfer executes successfully, they will initiate a larger, fraudulent payment. In addition, fraudsters have been known to initiate other “low risk” activities such as checking the balance of an account before changing a password and expropriating funds or leveraging it as a mule account.
Rather, RSA posits that a low-risk transaction is one that is reasonably believed to have been initiated by the true account owner.
Risk should not be correlated with value but with level of confidence that the individual initiating the transaction is in fact the legitimate account owner. Therefore the question around what constitutes a “low risk” payment shouldn’t be “does this payment fall below the threshold” but “how confident am I that the payer is who he says he is?”
In addition, as noted above RSA agrees with the EBA’s reasoning behind identifying objections to a SCA requirement. However we believe that the merits of transaction risk analysis which balances strong security with consumer convenience far outweigh the need for a specific and limited list of exemptions. RSA believes that the EBA should retain a principles-based approach for the exemptions. This will cultivate innovation for transaction risk analysis plus strong customer authentication. Within the third party PSP environment, the ASPSP and PSPs could use the communication interface to exchange the risk and authentication details.
Ultimately it is the banks and card issuers who own the liability for fraudulent payments. Each of these banks and issuers has a different risk tolerance and business priorities. If the EBA takes a principles-based approach rather than specifying a list of exemptions to SCA, those banks and issuers can define the risk thresholds and policies that make sense for their consumers.
Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?
Yes, RSA has strong concerns about the exemptions contained in Chapter 2, specifically the failure to extend an exemption for “transaction risk analysis” which we understand to include risk-based authentication.Failure to exempt risk-based analysis of transactions will negatively impact payer experience without improving fraud detection. In fact, challenging each and every transaction regardless of level of risk could have the unanticipated and undesirable effect of increasing fraud due to payer “alert fatigue.” If payers are accustomed to using a one-time authentication code for every transaction, they are less likely to closely examine their transactions. This Pavlovian response could in turn embolden fraudsters to increase their efforts at intercepting and diverting legitimate transactions, further increasing fraud.
In addition, requiring SCA for every transaction regardless of risk could threaten economic growth. Forcing consumers to authenticate each and every transaction will reduce the number of completed transactions, which in and of itself would slow growth. Plus there is an expense for generating a one-time password for each and every transaction. The additional expense incurred in an environment with fewer completed transactions will be passed along to consumers in the form of higher prices for goods and services, further inhibiting economic growth.
Section 54 of the Consultation Paper notes that risk-based transaction analysis will not be exempted because, “…the EBA was not able to identify which minimum set of information the RTS should require for such transaction risk analysis to be sufficiently reliable to allow a specific exemption from the application of SCA, while also ensuring a fair competition among all payment service providers.”
The goal of maintaining a level playing field is a laudable one. However the lack of a minimum set of standards will not adversely impact competitiveness among PSPs because it doesn’t take into account PSP business priorities – PSPs have a vested interest in preventing fraud. PSPs, simply out of self-interest, will not adopt a risk-based authentication solution that can’t deliver strong fraud detection rates simply to comply with EBA regulations. Adopting an ineffective risk-based authentication solution could impact profitability perhaps to an even greater degree than providing a negative payer experience would.
In short, the industry will police itself in this regard.
Please note that the payments industry itself has embraced a risk-based approach as a way to balance strong security with consumer convenience.
For example EMVCo, the international standards body owned by six of the leading card schemes and tasked with developing the 3D Secure 2.0 payment authentication protocol, has made risk-based authentication a foundation of the revised protocol. The card brands themselves, including MasterCard and Visa, have announced that they are retiring passwords and plan to take a risk-based approach to authentication of transactions.
RSA has been providing card issuers with risk-based 3D Secure services since 2009 and has sustained fraud detection rates in the mid-ninety percent rage over many years. These high detection rates have been achieved with very low false positives and an average intervention rate of just ~5%. With RSA’s risk-based authentication solution for card issuers, ~95% of transactions are allowed to pass through without intervention from the cardholder.
Likewise, our risk-based consumer authentication solution for bank account logins and transactions has consistently delivered fraud prevention rates of approximately 92% for logins and 94% for transactions with only a 3% intervention rate.
Risk-based authentication works.
Risk-based authentication is a viable and preferred option over a 100% challenge with one-time authentication code and RSA strongly advises that if the EBA opts not to take a principles-based approach that it be included in the exemptions listed in Chapter 2. Risk-based authentication of payments dramatically improves payer experience and reduces fraud. Requiring SCA for every transaction regardless of risk could stifle innovation in the payments space and have the unintended consequence of driving more fraud. In addition, the increased cost of facilitating transactions in an environment where all transactions are challenged will be passed along to consumer in the form of more expensive goods and services, adversely impacting economic growth.
Moreover, requiring SCA for every transaction also fails to take into account the fact that the majority of transactions are in fact legitimate.
RSA strongly recommends that the committee reconsider the position outlined in the Consultation Paper and, if the EBA does not adopt a principles-based approach, exempt risk-based authentication solutions from SCA requirements.
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?
RSA agrees with the EBA’s “principle-based approach” to ensuring that PSPs protect the confidentiality and integrity of personalized security credentials. This “technology and business-model neutrality” (Consultation Paper, Section 59) will foster innovation in the payments space.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?
NAQuestion 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?
RSA agrees with the use of ISO 20022 elements for financial messaging. However we caution viewing ISO 20022 elements alone as adequate for risk analysis.Analyzing the risk associated with a transaction yields better results when pairing the transaction data and user data with the data of the electronic device used to execute the transaction (hereafter ‘device’), which is not part of ISO 20022 elements. In fact the EBA in Article 1.3 acknowledges that other mechanisms including device identification should be included in SCA.