Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
In our view the requirements proposed in the RTSs are too strict and costly to implement, compared with the potential threat at hand and compared to what can be achieved with risk-based approach. Implementing all techniques in 1.3 e) would mean significant annual costs increases per payment channel. Even if those investments were made, PSPs wouldn't still be able to take purely risk-based approach to authentication. This would likely lead to mixed incentives, where PSPs would acquire the technology, but instead purchasing the best out there, one would settle for the cheapest. Additional costs would in turn mean higher fees for customers.
Terminology-wise strong customer authentication should be broken down to three sub-categories: a) authentication i.e. customer identifying himself and accessing the services b) in-session monitoring i.e. customer using the payment service, time from login to logout c) authorisation, i.e. customer verifying the payments he/she made. This classification is required to avoid confusion. For example authentication should be required in majority of use cases, when accessing payments account online, as should in-session monitoring, but authentication could be exempt in certain use cases. Referring to the whole payment process as SCA, makes interpretation of e.g. Chapter 2 on exemptions difficult.
Implementation of RTS, when it comes to SCA, should take into account experiences from Secure Internet Payments "comply or explain" experiences as there are numerous ways of implementing a secure service. Fraud problem is dynamic by nature and therefore the EBA should not restrict too much the ways to mitigate the problem. Authorities should primarily use fraud figures of a respective PSP to assess the PSPs ability to provide secure services instead of introducing strict limits (and exemptions) on how to implement SCA. ECB conducted Cyber Risk Questionnaire in 2015 amongst the ~100 largest banks, which included fraud loss questions. This data should be used to keep requirements in proportion with the threat. Tackling a 1 eur threat with 10 eur investments is not sensible in the long run.
Finally, as far as the independence of the authentication elements is concerned and when the elements or the code is used through multi-purpose devices such as tablets or mobile phones, the OP considers that ASPSP do not have the means to control whether there is a risk of the device being compromised. Multi-purpose devices belong to consumers and remain largely outside the control of banks. It also should be noted that there are authentication elements not controlled and issued by banks (e.g. fingerprint readers embedded in smart phones) that are however used by PSPs.
The requirement for an independent or segregated channel should be amended in such a way that PSP would be allowed to do in-session profiling and decide the need for a separate channel, if the electronic payment at hand is deemed as risky one. We need to be able to provide usable and fluent payment flows, if the payment is seen as low risk payment.
Requiring independent channel would also mean huge cost increases that are out of proportion compared to the threat. The estimated costs of universal second channel verification in our case would exceed the costs related to current fraud levels more than hundred-fold. This in turn would highly mean higher fees for customers in order to cover the costs. With risk-based approach we currently use, we optimize security and user experience; the customers actually read the contents of the 2nd channel message, when we send them only, when something special is taking place - effect which would certainly be diluted, if all payments would need to be verified through another channel.
Additionally, term authentication code is confusing, when used in the context of referring to payment authorisation. Preferably term authorisation code could be used instead. Linking transaction data and authorisation code is logically impossible in authentication phase, when customer is logging into the service and hasn't yet made a single payment. When customer is authorising a payment, linking transaction data and token should be only one alternative. Also using tokens that have a limited expiration time should be equally allowed (otherwise you rule out majority of time based OTP devices). Main point should be that tokens are one time use only and that is already written in Article 1.
Majority of this text could be rewritten just to state that tokens cannot be reusable and dynamic real time risk assessment should be made regarding the payment and appropriate authorisation level required based on the output of the risk analysis. Too much detail on required technical solutions creates problems (and prevents development); principles like if one element of security is compromised it must not affect other elements" should be enough.
Also, on our view the RTSs are mixing corporate customer bulk payments with on-line payments: these are two wholly different processes, which should be acknowledged in the RTS's. Bulk payments should be fully out of scope."
The fraudsters' main scheme is real time phishing, where knowledge, possession and inherence alone do not help, if customer is lead to thinks that he/she is communicating with a PSP and relays all SCA related data directly to the fraudster. Thus, in-session monitoring and risk based authorisation mechanisms need to be used.
Furthermore, would article 4 make it non-compliant to print payment card number and cvv number on the face of a payment card as they can be easily copied, if access to card obtained physically?
Also, more simple definitions required, like possession is something that cannot be copied", knowledge is something that can be changed over time etc. Concrete requirements should be left to (existing) security standards OP would also like to raise the potential problem with the definition of strong customer authentication, namely requiring two out of three elements (knowledge, possession, inherence). In out view technical development may in the future allow for methods e.g. combining several factors of inherence which would allow for a more secure authentication than e.g. combinations of knowledge and possession."
Authentication should be dynamic and risk based, as different transaction have very different risk profiles. These fixed exemptions make a real risk-based approach impossible. There is also a real danger that rigid requirements may lead to an unfriendly user experience and discourage use of secure payment methods. It should also be noted that risk –based approach has been approved in e.g. credit risk management (which must be based on models but banks have degrees of freedom in defining those models). EBA has also itself been developing guidelines based on risk based approach.
OP also sees that the reasoning should take into account the following:
Art 8. 1. a. : Accessing payment data without disclosing sensitive data is impossible as all payment data can be seen as sensitive (e.g. used in identity theft, invoice fraud, social engineering).
Art 8. 1. b.: Should there be a timeframe, when cumulative 150 eur reset? E.g. 150 eur cumulative per month?
Art 8. 2. a.: Creating a whitelist of trusted beneficiaries should not only be left to the customer. Customer created whitelists do not help fighting the fraud as the fraudsters only need to social engineer the customer and add new recipients to the list to misuse this functionality. Countries, where this approach is used, seem to have high fraud losses dispite the approach.. You should also take into account that PSPs should also be allowed to decide the risk level of a transaction like Art 1.3 e) iii states. Accounts in customer transaction history and data about known reliable beneficiaries, like utility company accounts, should be a allowed to be exempt from excessive payment authorisation, if PSP decides so. PSP carries the risk, not the customer.
As already mentioned under previous question, OP also considers that exemptions should be optional, and not interpreted in a way of preventing PSPs to apply strong customer authentication using risk-based approach even if individual transaction could fall under exemption e.g. based solely on the amount.
In OP's opinion there may also be cases in which whitelisting could also be done directly by the PSPs, such as allowing by default payments of taxes to dedicated accounts etc.
Art 11,12,13 should also allow the possibility to give credentials in a fully digital process. Taking into account e-IDAS regulation, we should be in a model, where potential customers A can authenticate to service X with credentials granted by party Y and ask for a new set of credentials from X
The access of third parties to payments accounts should be implemented with some security measures which are needed in order to protect the confidentiality of the information that is present in the system of the PSP and that is not directly linked to the operation which is subject to the access of a third party. Without these security measures, third parties have a direct access to the internet banking of the bank’s customers and are allowed to see all the services provided by the PSP through the internet banking; services that are not necessarily linked with the payment/consultation operation required and should be protected by banking privacy.
OP sees that the requirement to publicly disclose changes 3 months in advance has disadvantages, e.g. is does not allow quick adoption of changes which may be occasionally required in today's rapidly evolving market environment. We would propose using an alternative method (which is currently typically employed in e.g. our interface services) which would allow instant implementation of changes but simultaneously require a continued support for pre-change functionalities for a sufficiently long period, e.g. 6 months.
In OP's view requirement to ensure free and unlimited availability of test environment to the community of TPPs increases ASPSPs' costs with no obligation for the supported PSP to develop and correctly manage interface on their side. Also free of charge support should be limited to basic questions, allowing models of tiered support.
Regarding the security of the communication session, OP considers that it is not safe enough to prevent only the staff of AISP and PISP from seeing the credentials in the clear in intermediate stages. Indeed, machines can still see the credentials and these machines can be compromised/hacked even within secure environments and also need to be shielded from access to this information.
Finally, as there is no clear definition of sensitive payment data, it should be clarified that information made available to TPPs is limited to those required by payment systems and they shall not include other personal information that could be maintained by ASPSPs as other services of functionality provided by the website channel.
If the ISO 20022 messages will be used also the support for different versions of those messages should be defined as there are several versions of the messages in the ISO catalogue. In addition to that SEPA scheme utilizes only certain versions and certain data sets in the bank-to-customer and customer-to-bank context.
Finally, in OP's view ISO 20022 is a good framework for message semantics and several banking related message standards have been defined. ISO 20022 specifies the use of XML to define these messages. However, the developers working with APIs have been converging and using REST protocol together with JSON formats for the payloads. OP views that the standard shouldn’t restrict the use to ISO 20022 but would instead encourage simultaneous publishing of JSON formats with the same message definitions, in order to help accelerate the development ecosystem. EBA should also help set an European wide standard for these and not assume ISO 20022 working group to pick up the task.
Furthermore, a clarification may be needed in order to understand if the scope of the requirement is beyond the PSP to PSP communication, which, in our opinion, should not include personal computer, tablet or mobile device, but shall be limited to server to server communication.
Finally, in relation to RTS's in general, OP would also welcome more clearly defined guidelines for operation during transition period – i..e. what will happen from Jan 2018 when PSD2 has to be implemented until the RTSs will be applicable
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?
OP takes note of the EBA’s approach to the definition of the requirements of the strong customer authentication consisting in setting high level principles over extremely detailed provisions.In our view the requirements proposed in the RTSs are too strict and costly to implement, compared with the potential threat at hand and compared to what can be achieved with risk-based approach. Implementing all techniques in 1.3 e) would mean significant annual costs increases per payment channel. Even if those investments were made, PSPs wouldn't still be able to take purely risk-based approach to authentication. This would likely lead to mixed incentives, where PSPs would acquire the technology, but instead purchasing the best out there, one would settle for the cheapest. Additional costs would in turn mean higher fees for customers.
Terminology-wise strong customer authentication should be broken down to three sub-categories: a) authentication i.e. customer identifying himself and accessing the services b) in-session monitoring i.e. customer using the payment service, time from login to logout c) authorisation, i.e. customer verifying the payments he/she made. This classification is required to avoid confusion. For example authentication should be required in majority of use cases, when accessing payments account online, as should in-session monitoring, but authentication could be exempt in certain use cases. Referring to the whole payment process as SCA, makes interpretation of e.g. Chapter 2 on exemptions difficult.
Implementation of RTS, when it comes to SCA, should take into account experiences from Secure Internet Payments "comply or explain" experiences as there are numerous ways of implementing a secure service. Fraud problem is dynamic by nature and therefore the EBA should not restrict too much the ways to mitigate the problem. Authorities should primarily use fraud figures of a respective PSP to assess the PSPs ability to provide secure services instead of introducing strict limits (and exemptions) on how to implement SCA. ECB conducted Cyber Risk Questionnaire in 2015 amongst the ~100 largest banks, which included fraud loss questions. This data should be used to keep requirements in proportion with the threat. Tackling a 1 eur threat with 10 eur investments is not sensible in the long run.
Finally, as far as the independence of the authentication elements is concerned and when the elements or the code is used through multi-purpose devices such as tablets or mobile phones, the OP considers that ASPSP do not have the means to control whether there is a risk of the device being compromised. Multi-purpose devices belong to consumers and remain largely outside the control of banks. It also should be noted that there are authentication elements not controlled and issued by banks (e.g. fingerprint readers embedded in smart phones) that are however used by PSPs.
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.
The OP agrees with the goal of EBA reasoning as explained in Rationale 23 of the Consultation Paper that requirements should remain neutral as to when the ’’dynamic linking’’ should take place under the conditions expressed above. However, in OP's view the proposed model is not technology neutral and the cost of using independent channel in all payments by far exceeds the fraud risk.The requirement for an independent or segregated channel should be amended in such a way that PSP would be allowed to do in-session profiling and decide the need for a separate channel, if the electronic payment at hand is deemed as risky one. We need to be able to provide usable and fluent payment flows, if the payment is seen as low risk payment.
Requiring independent channel would also mean huge cost increases that are out of proportion compared to the threat. The estimated costs of universal second channel verification in our case would exceed the costs related to current fraud levels more than hundred-fold. This in turn would highly mean higher fees for customers in order to cover the costs. With risk-based approach we currently use, we optimize security and user experience; the customers actually read the contents of the 2nd channel message, when we send them only, when something special is taking place - effect which would certainly be diluted, if all payments would need to be verified through another channel.
Additionally, term authentication code is confusing, when used in the context of referring to payment authorisation. Preferably term authorisation code could be used instead. Linking transaction data and authorisation code is logically impossible in authentication phase, when customer is logging into the service and hasn't yet made a single payment. When customer is authorising a payment, linking transaction data and token should be only one alternative. Also using tokens that have a limited expiration time should be equally allowed (otherwise you rule out majority of time based OTP devices). Main point should be that tokens are one time use only and that is already written in Article 1.
Majority of this text could be rewritten just to state that tokens cannot be reusable and dynamic real time risk assessment should be made regarding the payment and appropriate authorisation level required based on the output of the risk analysis. Too much detail on required technical solutions creates problems (and prevents development); principles like if one element of security is compromised it must not affect other elements" should be enough.
Also, on our view the RTSs are mixing corporate customer bulk payments with on-line payments: these are two wholly different processes, which should be acknowledged in the RTS's. Bulk payments should be fully out of scope."
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?
We would like to point out that article 4 anti-cloning features should allow the use of physical token cards, if copying that token card alone is not enough to make any transactions - otherwise article is not technologically neutral. For example, in our OTP card model, there is a separate username and password, in-profile monitoring and risk based authorisation, which in total create a system, where fraud losses are amongst the lowest in EU, according to ECB Cyber Risk Study. Different authentication elements can be used to achieve same results.The fraudsters' main scheme is real time phishing, where knowledge, possession and inherence alone do not help, if customer is lead to thinks that he/she is communicating with a PSP and relays all SCA related data directly to the fraudster. Thus, in-session monitoring and risk based authorisation mechanisms need to be used.
Furthermore, would article 4 make it non-compliant to print payment card number and cvv number on the face of a payment card as they can be easily copied, if access to card obtained physically?
Also, more simple definitions required, like possession is something that cannot be copied", knowledge is something that can be changed over time etc. Concrete requirements should be left to (existing) security standards OP would also like to raise the potential problem with the definition of strong customer authentication, namely requiring two out of three elements (knowledge, possession, inherence). In out view technical development may in the future allow for methods e.g. combining several factors of inherence which would allow for a more secure authentication than e.g. combinations of knowledge and possession."
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?
OP considers that the EBA’s reasoning on the exemptions from the application of article 97 of PSD2 is too prescriptive. Combined with the fact that banks are largely liable for any fraud and are the first port of call to resolve any issue puts banks (and their mandate to protect client funds) in a straightjacket without recourse to own risk management. It should also be explicitly expressed that exemptions should be considered an option, i.e. that banks should allowed deciding on whether to apply them or not. For example, in NFC payments, a standard practice currently is to require the customer to enter the card-PIN at certain, randomised intervals even when payments are below the normal threshold.Authentication should be dynamic and risk based, as different transaction have very different risk profiles. These fixed exemptions make a real risk-based approach impossible. There is also a real danger that rigid requirements may lead to an unfriendly user experience and discourage use of secure payment methods. It should also be noted that risk –based approach has been approved in e.g. credit risk management (which must be based on models but banks have degrees of freedom in defining those models). EBA has also itself been developing guidelines based on risk based approach.
OP also sees that the reasoning should take into account the following:
Art 8. 1. a. : Accessing payment data without disclosing sensitive data is impossible as all payment data can be seen as sensitive (e.g. used in identity theft, invoice fraud, social engineering).
Art 8. 1. b.: Should there be a timeframe, when cumulative 150 eur reset? E.g. 150 eur cumulative per month?
Art 8. 2. a.: Creating a whitelist of trusted beneficiaries should not only be left to the customer. Customer created whitelists do not help fighting the fraud as the fraudsters only need to social engineer the customer and add new recipients to the list to misuse this functionality. Countries, where this approach is used, seem to have high fraud losses dispite the approach.. You should also take into account that PSPs should also be allowed to decide the risk level of a transaction like Art 1.3 e) iii states. Accounts in customer transaction history and data about known reliable beneficiaries, like utility company accounts, should be a allowed to be exempt from excessive payment authorisation, if PSP decides so. PSP carries the risk, not the customer.
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?
Payment authorisation is by nature a dynamic risk decision, where multiple factors need to be taken into account each time a payment is made. Therefore, exemption cases should not be static list, but rather rely on the dynamic risk decision process, where factors listed in Art 1.3. e) are used. Static lists are outdated approach and hinder the development of payment services.As already mentioned under previous question, OP also considers that exemptions should be optional, and not interpreted in a way of preventing PSPs to apply strong customer authentication using risk-based approach even if individual transaction could fall under exemption e.g. based solely on the amount.
In OP's opinion there may also be cases in which whitelisting could also be done directly by the PSPs, such as allowing by default payments of taxes to dedicated accounts etc.
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?
Largely yes, as they point out that e.g. screen scraping techniques inevitably break the confidentiality of personalised security credentials as credentials are transmitted in clear text to 3rd parties and this need to change. However, it should be noted that Art 9 1. a) should not be interpreted in such a way that username and one time tokens need to be masked, when customer is inputting them into the payment service as it would severely hinder the usability of those services, with no real security gains. Usernames and other tokens used to identify the customers should not be masked in log files as they are the the essential data keys to lookup, what the customer has done. In a username + password + token-model, masking the password from input fields and logs should be sufficient.Art 11,12,13 should also allow the possibility to give credentials in a fully digital process. Taking into account e-IDAS regulation, we should be in a model, where potential customers A can authenticate to service X with credentials granted by party Y and ask for a new set of credentials from X
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?
OP generally agrees on the need for establishing common and secure open standards of communication. However, we would like to make some observations.The access of third parties to payments accounts should be implemented with some security measures which are needed in order to protect the confidentiality of the information that is present in the system of the PSP and that is not directly linked to the operation which is subject to the access of a third party. Without these security measures, third parties have a direct access to the internet banking of the bank’s customers and are allowed to see all the services provided by the PSP through the internet banking; services that are not necessarily linked with the payment/consultation operation required and should be protected by banking privacy.
OP sees that the requirement to publicly disclose changes 3 months in advance has disadvantages, e.g. is does not allow quick adoption of changes which may be occasionally required in today's rapidly evolving market environment. We would propose using an alternative method (which is currently typically employed in e.g. our interface services) which would allow instant implementation of changes but simultaneously require a continued support for pre-change functionalities for a sufficiently long period, e.g. 6 months.
In OP's view requirement to ensure free and unlimited availability of test environment to the community of TPPs increases ASPSPs' costs with no obligation for the supported PSP to develop and correctly manage interface on their side. Also free of charge support should be limited to basic questions, allowing models of tiered support.
Regarding the security of the communication session, OP considers that it is not safe enough to prevent only the staff of AISP and PISP from seeing the credentials in the clear in intermediate stages. Indeed, machines can still see the credentials and these machines can be compromised/hacked even within secure environments and also need to be shielded from access to this information.
Finally, as there is no clear definition of sensitive payment data, it should be clarified that information made available to TPPs is limited to those required by payment systems and they shall not include other personal information that could be maintained by ASPSPs as other services of functionality provided by the website channel.
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?
OP does agree that common message definitions should be used. However, ISO 20022 messages are usually used in file based transfers as in SEPA scheme, but not in online web interfaces as is case regarding online banking. Furthermore ISO 20022 messages are mainly used in corporate transactions, both CustomerToBank and BankToCustomer context, but not necessarily or not at all with private customers as their banking services are based on online web based services where they connect to the bank using web browsers. This applies also to corporate customers who use online banking services through web-browser instead of file transfers.If the ISO 20022 messages will be used also the support for different versions of those messages should be defined as there are several versions of the messages in the ISO catalogue. In addition to that SEPA scheme utilizes only certain versions and certain data sets in the bank-to-customer and customer-to-bank context.
Finally, in OP's view ISO 20022 is a good framework for message semantics and several banking related message standards have been defined. ISO 20022 specifies the use of XML to define these messages. However, the developers working with APIs have been converging and using REST protocol together with JSON formats for the payloads. OP views that the standard shouldn’t restrict the use to ISO 20022 but would instead encourage simultaneous publishing of JSON formats with the same message definitions, in order to help accelerate the development ecosystem. EBA should also help set an European wide standard for these and not assume ISO 20022 working group to pick up the task.
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 ?
The OP agrees that website certificates issued by a qualified trust service provider under an e-IDAS policy are a suitable solution for the identification between PSPs. It is welcomed that PSPs must identify themselves with a digital certificate so the bank can see it’s a third party accessing the account and not the customer. However, regarding the content of the certificate (article 20. 3 (a)) which shall include, among others, the role of the PSP, it should be noted that a single TPP can e.g. be both PISP and AISP, thus a combined certificate covering multiple roles should also be possible.Furthermore, a clarification may be needed in order to understand if the scope of the requirement is beyond the PSP to PSP communication, which, in our opinion, should not include personal computer, tablet or mobile device, but shall be limited to server to server communication.
Question 10: With regards to the frequency with which AIS providers can request information from designated payment accounts when the payment service user is not actively requesting such information, do you agree that the proposed limit of no more than two times a day achieve an appropriate balance between allowing AISP to provide updated information to their users while not negatively impacting the availability of the ASPSP’s communication interface? If not, please indicate what would be in your view the appropriate frequency and rationale for such frequency.
In OP's view it seems justifiable to define a maximum number of requests per day for requesting information from a designated payments account without the user’s request. OP would however like to see that the 2 request per day limit be interpreted in a way which would not prohibit the ASPSP to allow for more requests, if it so chooses.Finally, in relation to RTS's in general, OP would also welcome more clearly defined guidelines for operation during transition period – i..e. what will happen from Jan 2018 when PSD2 has to be implemented until the RTSs will be applicable