Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
If there is a strong rationale for strong authentication, then the broad principles expressed in Article 1 are sound. In routine enterprise security contexts outside of a payment scenario these requirements in Article 1 would be required for an authentication solution that has to be: resistant to a high threat scenario; provide very high levels of integrity; or meet the highest levels of assurance as defined in government authentication frameworks.
There has been no compelling evidence or rationale provided that consumer payments to financial institutions and merchants are at such threat and risk that they would warrant meeting the highest level of assurance demanded by governments. Moreover, all the scenarios in which the citizen engages with government and which relate to the citizen either paying government (such as taxes) or otherwise receiving benefits require significantly lesser assurance than demanded in these RTS.
If the governments do not demand such protection, why are these RTS and the requirements for strong authentication set at such a high level? There is no compelling evidence that the risk to consumer remote payments on merchant sites or by credit transfers from their bank require this level of strong authentication and protection in each and every payment context.
Moreover, there has been little or no formal assessment made as to the detrimental impact on consumer perceptions of use and convenience of e-commerce and on-line banking that such draconian measures might have. These measures are unlikely to have the desired impact of promoting e-commerce, rather they will drive people away from e-commerce because of the lack of convenience and ease of use.
Finally, in card payments the concept of authentication is very distinct process from that of authorisation. The RTS conflates these two phases of a card payment. There is merit in these being two distinct phases of the payment process, and if they were to be formally joined then this would seriously compromise current merchant to acquirer standards requiring wholesale revision of current protocols in most European markets.
Article 2.2 is awkward and lacks clarity. Firstly, and very simply, it is unclear why the confidentiality of any authentication code that has been generated as set out in the RTS should require confidentiality protection. Secondly the RTS is incorrect in asserting in 2.2(a) that any change to the amount or payee will change the authentication code. The change will only be detected when the PSP providing the PSCs validates the authentication code presented to the PSP. The implication in this article is that it is somehow automatic. The requirement should be that the PSP issuing the PSC must validate the authentication code to ensure that the amount and payee have not been tampered with in transit.
The second sentence of Article 2.2(b) requiring the independence of the channel displaying the linking of amount and payee being independent of the channel through which the payment is made technically unfeasible on all remote channels where the payment is executed from a consumer’s/payer’s device. Or rather the level of investment needed to satisfy this requirement is disproportionate to the risk it is trying to address.
The scenarios in Article 2.2(b) seem likely to try and mitigate the risk of a merchant tampering with the payment amount or the payee prior to submission to the PSP. If there was any compelling evidence that this was a high threat scenario, then e-commerce would never have approached the commercial and consumer acceptance levels it has throughout the world. In my long experience of working within the payments industry I have never seen this threat manifest itself. On any risk basis it is difficult to justify this degree of control.
Articles 3 to 4 inclusive are sound but questionable based on the response made to Question 1. Moreover, all the Articles in this chapter provide insufficient detail to be able to conduct a technical assessment as demanded under Article 7. There is no technical detail nor an assessment framework that would allow any solution to either be judged as to whether it meets these RTS or be compared one with another.
The exemptions are muddled and confused. If there are exemptions for strong authentication, it could be asserted that there are no requirements for any authentication. The guidance and RTS provides no sense of what authentication is required below the level it is designed to apply at. If there are exemptions, then the level of authentication below strong authentication must be applied if it is required. Nowhere in this Chapter is this more relevant than 2.1(a). Access to any information of the payer on his account must be subject to authentication. This is personal information, and depending on the purchases on the statement it could indeed be sensitive personal information that must be protected from unauthorised access. Therefore, the level of authentication that is required must be stated explicitly at what level below strong authentication this must be.
In Article 2.1(b) it is wholly unclear why face-to-face contactless transactions requirements have been included in the RTS. The recital at the beginning of the RTS describes these authentication requirements and standards being applicable to on-line and remote transactions. This section should be removed as having no bearing on remote transactions.
At Article 2.2(d) placing any value limits on the level of transaction for which strong authentication is not required is in appropriate. This seems more sensible to defer to the liability and commercial arrangements between PSPS and acquiring PSPS and their merchants.
Finally, there has been throughout all the consultations on strong authentication and security of internet payments there has been a woeful lack of attention to merchant account-on-file card payment solutions. The risk environment has demonstrated that some measure of relaxation on strong authentication is warranted where merchants accepting card payments have registered the card holder’s account in an account-on-file solution where all transactions within that merchant might be made from the account registered. These accounts offer a significant risk reduction from ad-hoc e-commerce payments and should be subject to a reasonable exemption.
If strong authentication is to have the strength that seems to be indicative in these RTS, irrespective of whether it is agreed with, then it is essential to consider the overall security of the PSC, their initialisation and their binding to the payer. The contradiction throughout this RTS is that if strong authentication is to have a meaning and purpose then an agreed comparable level of assurance across a variety of solutions is required. Without this one cannot be assured that one solution is secure as another.
Therefore the RTS falls well below the level of detail required that will ensure the “strong” in SCA is met universally and comparable across devices; on that basis alone the RTS are flawed. Moreover, if the regulatory authorities require “strong” then it is essential that they define what comparably “strong” looks across all potential solutions, it would be wholly ill advised to allow this to market forces to define what “strong” looks like in any specific solution.
Most telling is the difficulty in trying to establish some measure of strength in the provisioning of a hardware PSC solution and a payer’s mobile phone used for authentication. In order for the mobile phone based authentication solution to be as effective and as “strong” as a hardware solution there is insufficient detail in the RTS to achieve this.
By way of example, the assertion of the requirement within the RTS at article 6.3(a) for mobile devices to have trusted execution environment (TEE) is not mentioned at all as mandatory requirement for the protection of a payer’s PSC is not even mentioned as a necessary control to protect PSC within a mobile environment. Even if it is wholly unlikely that within the time left to implement these RTS that there will be widespread adoption of a common model of TEE that would allow PSPs to consider for their solution implementations. This is not even counting the huge number of legacy mobile devices that would not even have a TEE within their basis model.
This session is broadly neutral and is currently implemented in the vast majority of payment systems by a matter of right. At that level it is somewhat surprising that there is a need to mandate specific RTS explicitly for what is already in place.
The omission is the need to consider directory routing requirements to ensure that the payer can be routed through any system to their account owning PSP to authenticate the pater. Within a credit transfer this is unlikely to be required, however, in e-commerce there may well be a requirement outside of the payment channel to redirect an authentication request from the merchant through to the payer’s account holding PSP who it is unlikely to have any relation to the merchant. It is reasonable to expect that these directory requirements would have been included in the RTS.
There is a rich message set within ISO20022 for payment related messages. None of these are suitable or relevant for the passage of authentication assertions. It seems wholly incorrect within a technical standard to discount mainstream accepted authentication protocols. There are increasing number of messaging constructs that could be used including SAML, OpenID and Openauth. Given that these were all designed for the explicit purpose of sending and receiving authentication codes and authentication assertions to allow a remote party to execute an authentication task it seems entirely unreasonable on a technical basis and naïve as a standard to discount their use.
Moreover, the issue of availability of funds is not an authentication question, this is an authorisation question and represents a measure of confusion within the RTS as to whether it is a standard defining security of authentication assertions to a relying party or a measure of how to authorise a financial or payment transaction.
The frequency should be threat and risk driven. It is not reasonable to define absolute limits within the a RTS. This is better left to determine the level of risk that these servies are subjected to.
As Head of Security at APACS (which is now UK Payments) I led the UK banking and payment response to:
The growth in e-banking fraud, and the only accurate capture of the level of harm this type of fraud generates
The development of the UK payments industry cooperative standard for two-factor authentication using EMV cards for on-line banking authentication.
Leading the engagement within the EPC on the development of secure remote banking practices and an assessment of current solutions and threats to on-line banking across Europe
The execution of a study that conducted the first assessment of all strong authentication solutions and the development of an assessment methodology to guide investment decisions by users of the technology
A risk assessment of mobile devices and the capabilities of mobile network operators to support authentication requirements.
As VP Payment System Risk at Visa Europe I was responsible for:
Defining and implementing the payment system risk strategy that was designed to contain the risk of PSC and account data being compromised in merchants and service providers and then being used fraudulently
Coordinating the response to breaches of cardholder information within merchants and service providers across Europe, from which the first accurate insight was gained to the level of threat of data breaches and the harm that these compromised credentials represented when used fraudulently
Defining and assessing the security arrangements of those manufacturing, initialising card based PSCs across Europe.
Engaging with regulators in the EU, the ECB and national central banks to contributing to informing their understanding of the threat and risk environment of the European card payment environment and eco-system.
Since these roles I have maintained a positive interest and tracking of these issues and the implications they represent for all parties.
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?
Do not agree.If there is a strong rationale for strong authentication, then the broad principles expressed in Article 1 are sound. In routine enterprise security contexts outside of a payment scenario these requirements in Article 1 would be required for an authentication solution that has to be: resistant to a high threat scenario; provide very high levels of integrity; or meet the highest levels of assurance as defined in government authentication frameworks.
There has been no compelling evidence or rationale provided that consumer payments to financial institutions and merchants are at such threat and risk that they would warrant meeting the highest level of assurance demanded by governments. Moreover, all the scenarios in which the citizen engages with government and which relate to the citizen either paying government (such as taxes) or otherwise receiving benefits require significantly lesser assurance than demanded in these RTS.
If the governments do not demand such protection, why are these RTS and the requirements for strong authentication set at such a high level? There is no compelling evidence that the risk to consumer remote payments on merchant sites or by credit transfers from their bank require this level of strong authentication and protection in each and every payment context.
Moreover, there has been little or no formal assessment made as to the detrimental impact on consumer perceptions of use and convenience of e-commerce and on-line banking that such draconian measures might have. These measures are unlikely to have the desired impact of promoting e-commerce, rather they will drive people away from e-commerce because of the lack of convenience and ease of use.
Finally, in card payments the concept of authentication is very distinct process from that of authorisation. The RTS conflates these two phases of a card payment. There is merit in these being two distinct phases of the payment process, and if they were to be formally joined then this would seriously compromise current merchant to acquirer standards requiring wholesale revision of current protocols in most European markets.
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.
Do not agree.Article 2.2 is awkward and lacks clarity. Firstly, and very simply, it is unclear why the confidentiality of any authentication code that has been generated as set out in the RTS should require confidentiality protection. Secondly the RTS is incorrect in asserting in 2.2(a) that any change to the amount or payee will change the authentication code. The change will only be detected when the PSP providing the PSCs validates the authentication code presented to the PSP. The implication in this article is that it is somehow automatic. The requirement should be that the PSP issuing the PSC must validate the authentication code to ensure that the amount and payee have not been tampered with in transit.
The second sentence of Article 2.2(b) requiring the independence of the channel displaying the linking of amount and payee being independent of the channel through which the payment is made technically unfeasible on all remote channels where the payment is executed from a consumer’s/payer’s device. Or rather the level of investment needed to satisfy this requirement is disproportionate to the risk it is trying to address.
The scenarios in Article 2.2(b) seem likely to try and mitigate the risk of a merchant tampering with the payment amount or the payee prior to submission to the PSP. If there was any compelling evidence that this was a high threat scenario, then e-commerce would never have approached the commercial and consumer acceptance levels it has throughout the world. In my long experience of working within the payments industry I have never seen this threat manifest itself. On any risk basis it is difficult to justify this degree of control.
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?
Partially AgreeArticles 3 to 4 inclusive are sound but questionable based on the response made to Question 1. Moreover, all the Articles in this chapter provide insufficient detail to be able to conduct a technical assessment as demanded under Article 7. There is no technical detail nor an assessment framework that would allow any solution to either be judged as to whether it meets these RTS or be compared one with another.
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?
Do not Agree.The exemptions are muddled and confused. If there are exemptions for strong authentication, it could be asserted that there are no requirements for any authentication. The guidance and RTS provides no sense of what authentication is required below the level it is designed to apply at. If there are exemptions, then the level of authentication below strong authentication must be applied if it is required. Nowhere in this Chapter is this more relevant than 2.1(a). Access to any information of the payer on his account must be subject to authentication. This is personal information, and depending on the purchases on the statement it could indeed be sensitive personal information that must be protected from unauthorised access. Therefore, the level of authentication that is required must be stated explicitly at what level below strong authentication this must be.
In Article 2.1(b) it is wholly unclear why face-to-face contactless transactions requirements have been included in the RTS. The recital at the beginning of the RTS describes these authentication requirements and standards being applicable to on-line and remote transactions. This section should be removed as having no bearing on remote transactions.
At Article 2.2(d) placing any value limits on the level of transaction for which strong authentication is not required is in appropriate. This seems more sensible to defer to the liability and commercial arrangements between PSPS and acquiring PSPS and their merchants.
Finally, there has been throughout all the consultations on strong authentication and security of internet payments there has been a woeful lack of attention to merchant account-on-file card payment solutions. The risk environment has demonstrated that some measure of relaxation on strong authentication is warranted where merchants accepting card payments have registered the card holder’s account in an account-on-file solution where all transactions within that merchant might be made from the account registered. These accounts offer a significant risk reduction from ad-hoc e-commerce payments and should be subject to a reasonable exemption.
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?
See response to Question 4Question 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?
Partially AgreeIf strong authentication is to have the strength that seems to be indicative in these RTS, irrespective of whether it is agreed with, then it is essential to consider the overall security of the PSC, their initialisation and their binding to the payer. The contradiction throughout this RTS is that if strong authentication is to have a meaning and purpose then an agreed comparable level of assurance across a variety of solutions is required. Without this one cannot be assured that one solution is secure as another.
Therefore the RTS falls well below the level of detail required that will ensure the “strong” in SCA is met universally and comparable across devices; on that basis alone the RTS are flawed. Moreover, if the regulatory authorities require “strong” then it is essential that they define what comparably “strong” looks across all potential solutions, it would be wholly ill advised to allow this to market forces to define what “strong” looks like in any specific solution.
Most telling is the difficulty in trying to establish some measure of strength in the provisioning of a hardware PSC solution and a payer’s mobile phone used for authentication. In order for the mobile phone based authentication solution to be as effective and as “strong” as a hardware solution there is insufficient detail in the RTS to achieve this.
By way of example, the assertion of the requirement within the RTS at article 6.3(a) for mobile devices to have trusted execution environment (TEE) is not mentioned at all as mandatory requirement for the protection of a payer’s PSC is not even mentioned as a necessary control to protect PSC within a mobile environment. Even if it is wholly unlikely that within the time left to implement these RTS that there will be widespread adoption of a common model of TEE that would allow PSPs to consider for their solution implementations. This is not even counting the huge number of legacy mobile devices that would not even have a TEE within their basis model.
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?
Partially AgreeThis session is broadly neutral and is currently implemented in the vast majority of payment systems by a matter of right. At that level it is somewhat surprising that there is a need to mandate specific RTS explicitly for what is already in place.
The omission is the need to consider directory routing requirements to ensure that the payer can be routed through any system to their account owning PSP to authenticate the pater. Within a credit transfer this is unlikely to be required, however, in e-commerce there may well be a requirement outside of the payment channel to redirect an authentication request from the merchant through to the payer’s account holding PSP who it is unlikely to have any relation to the merchant. It is reasonable to expect that these directory requirements would have been included in the RTS.
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?
Do not agreeThere is a rich message set within ISO20022 for payment related messages. None of these are suitable or relevant for the passage of authentication assertions. It seems wholly incorrect within a technical standard to discount mainstream accepted authentication protocols. There are increasing number of messaging constructs that could be used including SAML, OpenID and Openauth. Given that these were all designed for the explicit purpose of sending and receiving authentication codes and authentication assertions to allow a remote party to execute an authentication task it seems entirely unreasonable on a technical basis and naïve as a standard to discount their use.
Moreover, the issue of availability of funds is not an authentication question, this is an authorisation question and represents a measure of confusion within the RTS as to whether it is a standard defining security of authentication assertions to a relying party or a measure of how to authorise a financial or payment transaction.
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 ?
NeutralQuestion 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.
Do Not AgreeThe frequency should be threat and risk driven. It is not reasonable to define absolute limits within the a RTS. This is better left to determine the level of risk that these servies are subjected to.
Please select which category best describes you and/or your organisation
[Other "]"If you selected "Other", please provide details
I provide independent information and cyber security consultancy within the payment and wider business contexts. I am well qualified to comment on this consultation from my previous experience and my in depth understanding of the issues on SCA and payments. My experience includes:As Head of Security at APACS (which is now UK Payments) I led the UK banking and payment response to:
The growth in e-banking fraud, and the only accurate capture of the level of harm this type of fraud generates
The development of the UK payments industry cooperative standard for two-factor authentication using EMV cards for on-line banking authentication.
Leading the engagement within the EPC on the development of secure remote banking practices and an assessment of current solutions and threats to on-line banking across Europe
The execution of a study that conducted the first assessment of all strong authentication solutions and the development of an assessment methodology to guide investment decisions by users of the technology
A risk assessment of mobile devices and the capabilities of mobile network operators to support authentication requirements.
As VP Payment System Risk at Visa Europe I was responsible for:
Defining and implementing the payment system risk strategy that was designed to contain the risk of PSC and account data being compromised in merchants and service providers and then being used fraudulently
Coordinating the response to breaches of cardholder information within merchants and service providers across Europe, from which the first accurate insight was gained to the level of threat of data breaches and the harm that these compromised credentials represented when used fraudulently
Defining and assessing the security arrangements of those manufacturing, initialising card based PSCs across Europe.
Engaging with regulators in the EU, the ECB and national central banks to contributing to informing their understanding of the threat and risk environment of the European card payment environment and eco-system.
Since these roles I have maintained a positive interest and tracking of these issues and the implications they represent for all parties.