Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
Article 1.3(b)
ABN AMRO would like to point out that it is common practice today to inform the customer via the point of sale terminal when an incorrect PIN code (an element of strong customer authentication) has been used when conducting a debit card or credit card transaction. This message helps the customer in understanding what went wrong, after which customers usually enter the correct PIN code in the second attempt. After 3 incorrect attempts the card is automatically blocked. ABN AMRO believes not informing the customers what went wrong when conducting a card transaction does not increase the level of security. It could however result in confusion for the customer and merchant, which is detrimental to the efficient usage of cards when conducting payments. Therefore, ABN AMRO would like to see article 1.3 (b) adjusted. The above also applies to Internet Banking environment when customers enter their PIN in authentication devices.
Article 1.3(e)
ABN AMRO supports the idea that measures to prevent, detect and block fraudulent payment transactions before the PSP’s final authorisation increase the level of security and are essential to maintain the public trust in electronic payment transactions. One could argue that fraud prevention measures based on customer profile and behaviour are essential for offering a secure service. It is the understanding of ABN AMRO that article 1.3(e) should be read as giving ASPSP’s the option to block payments due to objective and non-discriminative measures, in line with an ASPSP’s liability and responsibility, even if a transaction has passed Strong Customer Authentication. As such, this article would allow essential measures for safety of customers by allowing ASPSP’s to block payments that are authenticated for objective fraud concerns.
It should be noted that measures based on customer profile and behaviour are not only essential for offering a secure payment service, but also for offering innovative customer centric one or two click-buying services. Inclusion of above mentioned risk mitigating measures in the requirements of strong customer authentication in articles 3,4,5 and 6 would therefore enable customer convenience.
Furthermore, for article 1.3(e) ABN AMRO would like to point out that the described fraud detection mechanism can only work properly if the information listed in the article is available real-time directly from the customers device. Putting a TPP between the customer and the bank makes fraud detection very difficult for ABN AMRO. A redirect to the banks platform for authorization of the customers, is essential to continue to perform fraud detection at an adequate level and to be able to respond quickly, effectively, and in innovative ways to imminent threats. ABN AMRO also supports the notion that a TPP should also perform measures to prevent, detect and block fraudulent payment transactions.
Article 6.2 and 6.3
ABN AMRO strongly supports these articles. According to ABN AMRO these articles support the current and future mobile (app) payment and information service solutions. Customers possess a mobile device that is linked to the current account through “device binding” and know their “PIN” code to authenticate themselves or to authorize a transaction. The exchange of authentication codes must then be organized via independent protocols or communication channels in the same device. ABN AMRO invites the EBA to be more specific on how to interpret independence and segregation of channels, devices or mobile applications. A uniform interpretation by the market is required to ensure a level playing field for all stakeholders. Please also refer to the answer to question 2.
According to ABN AMRO customers should not be allowed to enter their personalised security credentials received from the ASPSP in any other website, application or channel than the secure online environment of the ASPSP. According to ABN AMRO duty of care and fraud prevention clearly outweigh ease of use, and in practice e.g. the so called ‘redirect customer’ models have proven to be easy to use, as well as to provide the necessary level of security. Banks have spent and are still spending a lot of money and effort to educate customers how to safely interact with a world that will continue to become more digital. In this world cybercrime is the biggest enemy of all players. ABN AMRO strongly believes that digitalisation has allowed all parties, from governments to merchant to payment service provider, to improve the customer journey when buying their services. To ensure these customer centric solutions are protected against cybercrime, consumers must receive clear and simple instructions that will protect them from becoming a victim. ABN AMRO believes that this is a key element of her duty of care and would like to receive the support of EBA in the joint fight against cybercrime. ABN AMRO is of the opinion that Rationale 19a supports the above and strongly recommends the EBA to include the reasoning of Rationale 19a in article 19 - for example by adding a new clause - stating that personalised security credentials issued by the ASPSP should only be entered in the secure environment of the ASPSP, and making clear that it is not allowed by third parties to ask customers to put personalised security credentials in third party environments.
ABN AMRO supports rationale 23. ABN AMRO would like to point out that the amount and beneficiary are elements of the authentication code that dynamically links the authentication code to the transaction. The amount and beneficiary are displayed to the customer in a secure and reliable way, however the consumer (PSU) cannot (always) determine whether or not the authentication code is calculated based on the amount or beneficiary. ABN AMRO believes that rationale 23 supports the existing customer experience and does not hinder future innovation. Reference is made to the response on question 1.
Rationale 26 and article 2.2
Reference is made to the ABN AMRO response on question 1 (art 6.2 and 6.3).
Article 2.2
In case of internet or mobile payments the transaction (amount and beneficiary) for which authorization is requested is displayed to the customer in a secure and reliable way prior to giving final authorization. ABN AMRO would like to receive further clarification on the following sentence in art 2.2.b: “The channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed shall be independent or segregated from the channel, device or mobile
application used for initiating the electronic payment transaction.” According to ABN AMRO it is sufficient to show the amount and beneficiary information in the mobile- or internet banking environment that is used to conduct the transaction, and not necessary to subsequently do this in a separate device (for instance, one that is used for the generating of personalized security credentials).
With regards to mobile payments, ABN AMRO would like to point out that customers are already accustomed to “easy to use” apps. As such, it is important from a customer point of view to maintain the current propositions on mobile (app) payments. In order not to disturb the existing ease of use and innovation, ABN AMRO believes that the use of independent communication protocols in a single native app in combination with device binding should be considered as strong customer authentication.
Current apps use a combination of device binding and passwords. Device binding ensures that the bank account of the customer can only be accessed from the mobile device of the customer after the account and mobile device have been connected. Importantly, this connection is established using strong customer authentication. The combination of a single native app which is bound to the device and accessible using a password with independent channels or communication channels used inside the application for authorization purposes, should meet the EBA criteria for strong customer authentication in order not to jeopardize innovation and ease of use for customers.
With regard to the techniques used ABN AMRO would like to refer to the input of the EPC:
“There are techniques to create a secure and protected environment on a single smart phone with a single online banking app. These techniques include, but are not limited to:
- Secure Element (SIM or dedicated chip) for storage of sensitive data, accessible only by PSU and authorised app
- App-separation / sandboxing
- Remote security updates, to prevent or react on possible weaknesses
- Hardening of an app / secure coding
- White-box cryptography
- Device binding (secure activation of an app for use by only one PSU on only one device), based on continually refreshed data elements or challenge/response
- Detection of mobile malware and fraud on the device
- App-store monitoring (for malicious apps)”
ABN AMRO invites EBA to be more specific on the required level of independence or segregation from the channel, device or mobile application.
Article 2.4
As batch payments are not specifically mentioned in the Directive, ABN AMRO would like to receive a definition of a batch payment. In case a single debit, multiple credit is meant, ABN AMRO asks for clarification on the requirement where for batch payments (usually their existence is the result of regular bookkeeping by customers) the authentication code generated must be specific to the total amount to be transferred and the payees. According to ABN AMRO this is currently in place. However, the customer has the capability to approve all transactions in one authorization session. From a customer point of view ABN AMRO believes that authorization of each individual transaction of the batch is detrimental to the current ease of use, outweighing the extra level of security. As such, ABN AMRO is looking for confirmation that batch payments can be authorized in one authorization session.
According to ABN AMRO the EBA should impose strict requirements to Account Information Service providers when storing customer transaction data. The requirements should be in line with the requirements set for ASPSPs for the secure storage of customer transaction data. From a customer point of view (privacy, possible identity theft) secure storage of confidential information is essential.
Article 8
ABN AMRO would like to receive more guidance on what is considered as sensitive payment data. ABN AMRO assumes that and would welcome confirmation that the requirements to safeguard sensitive payment data applies equally to ASPSP client channels as well as AISP channels – and that AISPs would be required to protect the data customers have downloaded into their environment.
Consideration should be given to the period of time mentioned in article 8.1(a)ii. One month between authentication sessions is a short period of time from a customer convenience perspective. Clients currently may have requested their ASPSP to send their reports directly to third parties until further notice. Re-submitting their request via strong customer authentication monthly, is a far worse customer experience and might lead to manual intervention either by clients or client service departments. SCA on an monthly basis means a deterioration of the customer experience, and it is not justified from a risk perspective. ABN AMRO therefore would like to see 8.1 (a) ii removed.
In case 8.1 (a) ii is not removed, there are some interpretation issues that should be resolved. ABN AMRO would like to see confirmed that when there is a trusted channel between the AISP and the ASPSP, monthly authentication through SCA should not be required until the PSU is involved. For example, if a customer has authorized an AISP to pull information, and has not authenticated for 41 days but also not used the AISP, the AISP should still be able to pull the information from the ASPSP. As soon as the PSU then accesses this information at the AISP, the AISP should redirect to the ASPSP to authenticate the PSU using SCA (under the assumption that the credentials are issued by the ASPSP).
Furthermore, from a level playing field perspective, we would like to stress that it should not make a difference in this respect whether a customer accesses the information related to his payment account via the AISP-channel or via the ASPSP-channel.
In article 8.2(a), ABN AMRO welcomes clarification on the term “created by payer”. Currently, ABN AMRO adds recipients to a whitelist of trusted beneficiaries once they have been part of a payment transaction that has been authorized using strong customer authentication. This practice has created a high level of customer convenience without impacting security and as such ABN AMRO is of the opinion that this should still be allowed.
ABN AMRO believes that PSPs should be able to use their own risk based analysis rather than follow strongly prescribed rules. This view is not compatible with the limitative list of exemptions the EBA is proposing. We would like to see the list of exemptions to be a non-exhaustive list and to leave space for risk-based considerations, like in the EBA Guidelines for security of internet payments.
This would be in line with current market practices and services, well justified from a security perspective, and allow for innovations in the dynamic and swiftly changing world of online banking services, would work out favorably for the customer experience, and would be more in line with the liabilities involved.
In order to implement a proper system of risk management and mitigation, as liable party, one must be in control over the alleged risks related to the product offering. Specifically, it is important to note that low value does not necessarily imply low risk – but if the list of exemptions would become mandatory, the effect would be that the two are equated from a practical point of view. This will not favor the client in the end. Specifically, if the list becomes mandatory it will become a target for fraudsters, who are continuously looking to abuse flaws and gaps in the payments system. This is likely to increase fraud, negatively impacting the overall costs of payment.
Mandatory exemptions would make risk assessment of transactions and implementation of strong customer authentication a black and white decision. ABN AMRO is of the view that this is incorrect – a transaction of €11 that fits into a customer’s standard behavioral pattern can be lower risk than a transaction of €9 that falls outside standard behavior. That current grey area seems to have been ignored in the draft RTS – but it is this area where the risk based approach of payment services has proven to be very effective in the past.
The ASPSP should always have the possibility to apply strong customer authentication if deemed necessary based on e.g anomalies in customer behavior and/or transaction patterns. As mentioned the risk based approach is essential for the detection of fraud. ABN AMRO considers the above as an important element of its duty of care (“zorgplicht”). In addition to the above, as the ASPSP remains liable for the (initial) compensation of customers in case of unauthorized transactions, it should be given the possibility to manage its risks. According to ABN AMRO the non-discrimination clause will effectively prevent possible abuse that would disturb the level playing field by ASPSP’s.
Article 9.1
1(a):What does data on personalized security credentials mean? It is important to understand whether this includes userid, pin or account number, or any other elements. Furthermore, clarification is required on their full extent – does this relate to all individual data on personalized security credentials or on a combination, for example userid/password?
1(b): ABN AMRO agrees that these elements should not be stored in plain text but this is in itself not enough to guarantee an adequate level of protection. We propose therefore to change the text into “… should be adequately protected by e.g. strong encryption techniques or storage in dedicated security modules”
1(c): ABN AMRO would welcome clarification on the level of tamper resistance that is required. From an ABN AMRO perspective there are 3 levels of protection, that is to be tamper resistant against:
1. Basic-advance attack profile
2. Moderate attack profile
3. High attack profile
Consideration should also be given to protection of the personalised security credentials via hardware security (e.g. chip, hardware secure elements) or software security (e.g. HCE, White Box crypto). For these requirements, ABN AMRO suggests that ISO norms such as ISO/IEC 15408 are used.
Article 12
Currently, market solutions are in place and have proven to be effective that rely on devices that are not user exclusive. An example of this is the e-dentifier that ABN AMRO uses, which then also relies on a combination of a payment card and pin-code to authenticate the customer. ABN AMRO believes that above devices e.g. e-identifier should be customer agnostic in order not to disturb the current user experience.
12(a): ABN AMRO requests a definition of “authentication devices and software”, as well as clarification whether the article relates to the combination of elements or each element individually.
Article 13
13(b): ABN AMRO would like to understand how the process of digitally signing and the ability for the payer to check this would work, for instance for apps that are obtained via an app-store.
Article 15
Please also refer to the comment on article 9.1(a). ABN AMRO welcomes EBA to provide more clarity on this clause by giving examples on what is deemed to be a public repository. For example, does this include public blacklists or filterdata?
Article 16
ABN AMRO agrees that security measures to protect the confidentiality and integrity of the personalised security credentials should be documented, periodically tested, evaluated and audited. ABN AMRO believes it would be useful to rephrase the following sentence: “by internal or external independent and certified auditors”. The use of “and” and “or” in this sentence without clarifying brackets could provide confusion.
ABN AMRO does not see particular technical constraints that prevent the industry from using the ISO 20022 standard.
Reference is made to the response of the Dutch Payment Association “Betaalvereniging”. Please find their input below.
“We would like to comment that qualified certificates assure the quality of identification by the CA for the issuing of such a certificate, but not the quality of the technology used to keep the associated private key credentials used for authentication (proof of identity) under sole usage control by its respective owner (a PSP). In order to ensure sole usage control by the respective PSP, we proposes to specify the adequate protection (e.g. crypto smart cards, USB dongles, hardware security modules) for the associated PSP private key credentials, preferably referring to international standards. Based on such an enhanced specification, qualified certificates and associated private key credentials are a common and standard solution for PSP authentication in automated server-server communications.
We agree with the fact that a Qualified Trust Service Provider (QTSP) could provide the certificates to be used for the identification between PSPs and for website authentication subject to sufficient availability of the appropriate certification authorities on the market. However, in the case of PSP software components installed on any common type device (e.g., tablet, mobile phone), owned by the payer, there is no way to enforce sole usage control over private key credentials by the owning PSP, which renders the certificate based approach completely unsuitable for PSP authentication in such a scenario (no mitigation against PSP impersonation attacks).
Article 20.1
To avoid a monopoly for such qualified trust service providers, we consider EBA to add a provision that sufficient (min. five) trusted service providers are available offering the services mentioned.”
In addition to the above ABN AMRO would like to point out that it is important the database/register of qualified and registered PSPs offering PIS and or AIS and or CAF services is maintained on a permanent basis. This register should also offer a push mechanism to inform ASPSPs immediately in case a PSP no longer meets the requirements set by the PSD2 and the RTS to offer PIS and/or AIS and/or CAF services.
ABN AMRO is however concerned about the practical technical implementation; How should the ASPSP make a distinction between an information request by the AIS provider and a customer?
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?
ABN AMRO welcomes the reasoning but would like to receive further clarification on the requirements of strong customer authentication to fully understand the implications on existing and future business propositions. In addition ABN AMRO has some remarks to that it would like to see incorporated in the final regulatory technical standards. Please find the ABN AMRO input below :Article 1.3(b)
ABN AMRO would like to point out that it is common practice today to inform the customer via the point of sale terminal when an incorrect PIN code (an element of strong customer authentication) has been used when conducting a debit card or credit card transaction. This message helps the customer in understanding what went wrong, after which customers usually enter the correct PIN code in the second attempt. After 3 incorrect attempts the card is automatically blocked. ABN AMRO believes not informing the customers what went wrong when conducting a card transaction does not increase the level of security. It could however result in confusion for the customer and merchant, which is detrimental to the efficient usage of cards when conducting payments. Therefore, ABN AMRO would like to see article 1.3 (b) adjusted. The above also applies to Internet Banking environment when customers enter their PIN in authentication devices.
Article 1.3(e)
ABN AMRO supports the idea that measures to prevent, detect and block fraudulent payment transactions before the PSP’s final authorisation increase the level of security and are essential to maintain the public trust in electronic payment transactions. One could argue that fraud prevention measures based on customer profile and behaviour are essential for offering a secure service. It is the understanding of ABN AMRO that article 1.3(e) should be read as giving ASPSP’s the option to block payments due to objective and non-discriminative measures, in line with an ASPSP’s liability and responsibility, even if a transaction has passed Strong Customer Authentication. As such, this article would allow essential measures for safety of customers by allowing ASPSP’s to block payments that are authenticated for objective fraud concerns.
It should be noted that measures based on customer profile and behaviour are not only essential for offering a secure payment service, but also for offering innovative customer centric one or two click-buying services. Inclusion of above mentioned risk mitigating measures in the requirements of strong customer authentication in articles 3,4,5 and 6 would therefore enable customer convenience.
Furthermore, for article 1.3(e) ABN AMRO would like to point out that the described fraud detection mechanism can only work properly if the information listed in the article is available real-time directly from the customers device. Putting a TPP between the customer and the bank makes fraud detection very difficult for ABN AMRO. A redirect to the banks platform for authorization of the customers, is essential to continue to perform fraud detection at an adequate level and to be able to respond quickly, effectively, and in innovative ways to imminent threats. ABN AMRO also supports the notion that a TPP should also perform measures to prevent, detect and block fraudulent payment transactions.
Article 6.2 and 6.3
ABN AMRO strongly supports these articles. According to ABN AMRO these articles support the current and future mobile (app) payment and information service solutions. Customers possess a mobile device that is linked to the current account through “device binding” and know their “PIN” code to authenticate themselves or to authorize a transaction. The exchange of authentication codes must then be organized via independent protocols or communication channels in the same device. ABN AMRO invites the EBA to be more specific on how to interpret independence and segregation of channels, devices or mobile applications. A uniform interpretation by the market is required to ensure a level playing field for all stakeholders. Please also refer to the answer to question 2.
According to ABN AMRO customers should not be allowed to enter their personalised security credentials received from the ASPSP in any other website, application or channel than the secure online environment of the ASPSP. According to ABN AMRO duty of care and fraud prevention clearly outweigh ease of use, and in practice e.g. the so called ‘redirect customer’ models have proven to be easy to use, as well as to provide the necessary level of security. Banks have spent and are still spending a lot of money and effort to educate customers how to safely interact with a world that will continue to become more digital. In this world cybercrime is the biggest enemy of all players. ABN AMRO strongly believes that digitalisation has allowed all parties, from governments to merchant to payment service provider, to improve the customer journey when buying their services. To ensure these customer centric solutions are protected against cybercrime, consumers must receive clear and simple instructions that will protect them from becoming a victim. ABN AMRO believes that this is a key element of her duty of care and would like to receive the support of EBA in the joint fight against cybercrime. ABN AMRO is of the opinion that Rationale 19a supports the above and strongly recommends the EBA to include the reasoning of Rationale 19a in article 19 - for example by adding a new clause - stating that personalised security credentials issued by the ASPSP should only be entered in the secure environment of the ASPSP, and making clear that it is not allowed by third parties to ask customers to put personalised security credentials in third party environments.
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.
Rationale 23 and article 2.2ABN AMRO supports rationale 23. ABN AMRO would like to point out that the amount and beneficiary are elements of the authentication code that dynamically links the authentication code to the transaction. The amount and beneficiary are displayed to the customer in a secure and reliable way, however the consumer (PSU) cannot (always) determine whether or not the authentication code is calculated based on the amount or beneficiary. ABN AMRO believes that rationale 23 supports the existing customer experience and does not hinder future innovation. Reference is made to the response on question 1.
Rationale 26 and article 2.2
Reference is made to the ABN AMRO response on question 1 (art 6.2 and 6.3).
Article 2.2
In case of internet or mobile payments the transaction (amount and beneficiary) for which authorization is requested is displayed to the customer in a secure and reliable way prior to giving final authorization. ABN AMRO would like to receive further clarification on the following sentence in art 2.2.b: “The channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed shall be independent or segregated from the channel, device or mobile
application used for initiating the electronic payment transaction.” According to ABN AMRO it is sufficient to show the amount and beneficiary information in the mobile- or internet banking environment that is used to conduct the transaction, and not necessary to subsequently do this in a separate device (for instance, one that is used for the generating of personalized security credentials).
With regards to mobile payments, ABN AMRO would like to point out that customers are already accustomed to “easy to use” apps. As such, it is important from a customer point of view to maintain the current propositions on mobile (app) payments. In order not to disturb the existing ease of use and innovation, ABN AMRO believes that the use of independent communication protocols in a single native app in combination with device binding should be considered as strong customer authentication.
Current apps use a combination of device binding and passwords. Device binding ensures that the bank account of the customer can only be accessed from the mobile device of the customer after the account and mobile device have been connected. Importantly, this connection is established using strong customer authentication. The combination of a single native app which is bound to the device and accessible using a password with independent channels or communication channels used inside the application for authorization purposes, should meet the EBA criteria for strong customer authentication in order not to jeopardize innovation and ease of use for customers.
With regard to the techniques used ABN AMRO would like to refer to the input of the EPC:
“There are techniques to create a secure and protected environment on a single smart phone with a single online banking app. These techniques include, but are not limited to:
- Secure Element (SIM or dedicated chip) for storage of sensitive data, accessible only by PSU and authorised app
- App-separation / sandboxing
- Remote security updates, to prevent or react on possible weaknesses
- Hardening of an app / secure coding
- White-box cryptography
- Device binding (secure activation of an app for use by only one PSU on only one device), based on continually refreshed data elements or challenge/response
- Detection of mobile malware and fraud on the device
- App-store monitoring (for malicious apps)”
ABN AMRO invites EBA to be more specific on the required level of independence or segregation from the channel, device or mobile application.
Article 2.4
As batch payments are not specifically mentioned in the Directive, ABN AMRO would like to receive a definition of a batch payment. In case a single debit, multiple credit is meant, ABN AMRO asks for clarification on the requirement where for batch payments (usually their existence is the result of regular bookkeeping by customers) the authentication code generated must be specific to the total amount to be transferred and the payees. According to ABN AMRO this is currently in place. However, the customer has the capability to approve all transactions in one authorization session. From a customer point of view ABN AMRO believes that authorization of each individual transaction of the batch is detrimental to the current ease of use, outweighing the extra level of security. As such, ABN AMRO is looking for confirmation that batch payments can be authorized in one authorization session.
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?
ABN AMRO is not aware of other threats than the ones identified in the articles addressed in question number 3. ABN AMRO would like point out once more that there is a high concern about the increased risk of phishing. In order to maintain public trust in (electronic) payments customers should only be allowed to enter their personalized security credentials received from their ASPSP in the secure internet environment of the ASPSP. Moreover ABN AMRO considers the protection of customers against (cyber) crime an important element of her duty to care.According to ABN AMRO the EBA should impose strict requirements to Account Information Service providers when storing customer transaction data. The requirements should be in line with the requirements set for ASPSPs for the secure storage of customer transaction data. From a customer point of view (privacy, possible identity theft) secure storage of confidential information is essential.
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?
ABN AMRO agrees with the underlying principles of the exemptions. It is however important to get clarity on the nature of these exemptions. Please also refer to the answer to question 5.Article 8
ABN AMRO would like to receive more guidance on what is considered as sensitive payment data. ABN AMRO assumes that and would welcome confirmation that the requirements to safeguard sensitive payment data applies equally to ASPSP client channels as well as AISP channels – and that AISPs would be required to protect the data customers have downloaded into their environment.
Consideration should be given to the period of time mentioned in article 8.1(a)ii. One month between authentication sessions is a short period of time from a customer convenience perspective. Clients currently may have requested their ASPSP to send their reports directly to third parties until further notice. Re-submitting their request via strong customer authentication monthly, is a far worse customer experience and might lead to manual intervention either by clients or client service departments. SCA on an monthly basis means a deterioration of the customer experience, and it is not justified from a risk perspective. ABN AMRO therefore would like to see 8.1 (a) ii removed.
In case 8.1 (a) ii is not removed, there are some interpretation issues that should be resolved. ABN AMRO would like to see confirmed that when there is a trusted channel between the AISP and the ASPSP, monthly authentication through SCA should not be required until the PSU is involved. For example, if a customer has authorized an AISP to pull information, and has not authenticated for 41 days but also not used the AISP, the AISP should still be able to pull the information from the ASPSP. As soon as the PSU then accesses this information at the AISP, the AISP should redirect to the ASPSP to authenticate the PSU using SCA (under the assumption that the credentials are issued by the ASPSP).
Furthermore, from a level playing field perspective, we would like to stress that it should not make a difference in this respect whether a customer accesses the information related to his payment account via the AISP-channel or via the ASPSP-channel.
In article 8.2(a), ABN AMRO welcomes clarification on the term “created by payer”. Currently, ABN AMRO adds recipients to a whitelist of trusted beneficiaries once they have been part of a payment transaction that has been authorized using strong customer authentication. This practice has created a high level of customer convenience without impacting security and as such ABN AMRO is of the opinion that this should still be allowed.
ABN AMRO believes that PSPs should be able to use their own risk based analysis rather than follow strongly prescribed rules. This view is not compatible with the limitative list of exemptions the EBA is proposing. We would like to see the list of exemptions to be a non-exhaustive list and to leave space for risk-based considerations, like in the EBA Guidelines for security of internet payments.
This would be in line with current market practices and services, well justified from a security perspective, and allow for innovations in the dynamic and swiftly changing world of online banking services, would work out favorably for the customer experience, and would be more in line with the liabilities involved.
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?
ABN AMRO is of the opinion that PSD2 does not provide the EBA c.q. the Commission sufficient legal basis to make the list of exemptions mandatory. In our opinion, the PSD2 does not provide the EBA c.q. the Commission with such competences. Furthermore, it would be problematic for ABN AMRO for the list of exemptions to become mandatory for a PSP to implement.In order to implement a proper system of risk management and mitigation, as liable party, one must be in control over the alleged risks related to the product offering. Specifically, it is important to note that low value does not necessarily imply low risk – but if the list of exemptions would become mandatory, the effect would be that the two are equated from a practical point of view. This will not favor the client in the end. Specifically, if the list becomes mandatory it will become a target for fraudsters, who are continuously looking to abuse flaws and gaps in the payments system. This is likely to increase fraud, negatively impacting the overall costs of payment.
Mandatory exemptions would make risk assessment of transactions and implementation of strong customer authentication a black and white decision. ABN AMRO is of the view that this is incorrect – a transaction of €11 that fits into a customer’s standard behavioral pattern can be lower risk than a transaction of €9 that falls outside standard behavior. That current grey area seems to have been ignored in the draft RTS – but it is this area where the risk based approach of payment services has proven to be very effective in the past.
The ASPSP should always have the possibility to apply strong customer authentication if deemed necessary based on e.g anomalies in customer behavior and/or transaction patterns. As mentioned the risk based approach is essential for the detection of fraud. ABN AMRO considers the above as an important element of its duty of care (“zorgplicht”). In addition to the above, as the ASPSP remains liable for the (initial) compensation of customers in case of unauthorized transactions, it should be given the possibility to manage its risks. According to ABN AMRO the non-discrimination clause will effectively prevent possible abuse that would disturb the level playing field by ASPSP’s.
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?
In general, ABN AMRO believes that PSPs should be able to use their own risk based analysis rather than follow strongly prescribed rules, for example such as the ones in articles 13(c)(i) and 14. ABN AMRO welcomes clarification on the following items:Article 9.1
1(a):What does data on personalized security credentials mean? It is important to understand whether this includes userid, pin or account number, or any other elements. Furthermore, clarification is required on their full extent – does this relate to all individual data on personalized security credentials or on a combination, for example userid/password?
1(b): ABN AMRO agrees that these elements should not be stored in plain text but this is in itself not enough to guarantee an adequate level of protection. We propose therefore to change the text into “… should be adequately protected by e.g. strong encryption techniques or storage in dedicated security modules”
1(c): ABN AMRO would welcome clarification on the level of tamper resistance that is required. From an ABN AMRO perspective there are 3 levels of protection, that is to be tamper resistant against:
1. Basic-advance attack profile
2. Moderate attack profile
3. High attack profile
Consideration should also be given to protection of the personalised security credentials via hardware security (e.g. chip, hardware secure elements) or software security (e.g. HCE, White Box crypto). For these requirements, ABN AMRO suggests that ISO norms such as ISO/IEC 15408 are used.
Article 12
Currently, market solutions are in place and have proven to be effective that rely on devices that are not user exclusive. An example of this is the e-dentifier that ABN AMRO uses, which then also relies on a combination of a payment card and pin-code to authenticate the customer. ABN AMRO believes that above devices e.g. e-identifier should be customer agnostic in order not to disturb the current user experience.
12(a): ABN AMRO requests a definition of “authentication devices and software”, as well as clarification whether the article relates to the combination of elements or each element individually.
Article 13
13(b): ABN AMRO would like to understand how the process of digitally signing and the ability for the payer to check this would work, for instance for apps that are obtained via an app-store.
Article 15
Please also refer to the comment on article 9.1(a). ABN AMRO welcomes EBA to provide more clarity on this clause by giving examples on what is deemed to be a public repository. For example, does this include public blacklists or filterdata?
Article 16
ABN AMRO agrees that security measures to protect the confidentiality and integrity of the personalised security credentials should be documented, periodically tested, evaluated and audited. ABN AMRO believes it would be useful to rephrase the following sentence: “by internal or external independent and certified auditors”. The use of “and” and “or” in this sentence without clarifying brackets could provide confusion.
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?
ABN AMRO partially agrees with the reasoning on the requirements for common and secure open standards of communication. ABN AMRO understands that the regulation including regulatory technical standards should, in principle, be technology agnostic to avoid the situation where regulation hampers innovation. However, with regard to the common and secure open standards of communication to facilitate access to the account, ABN AMRO strongly believes that the standards should become more specific. According to ABN AMRO the standards should define a minimum set of requirements to allow a standardized and harmonized implementation, required for an effective implementation of the PSD2. ABN AMRO is afraid that the current RTS will lead to fragmentation at a national and European level which will make it very difficult and costly for any party to offer third party services to the benefit of its customers. Therefore ABN AMRO urges the EBA to deliver more rule-based specifications in this area. If requested ABN AMRO is more than happy to help EBA in this matter by making expert resources available.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?
ABN AMRO supports the use of ISO 20022 elements, components and messaging but we do not support mandatory use of XML because it is not the only and not the most suitable technique for API’s. According to ABN AMRO ISO 20022 is the future standard for transaction banking at large. As mentioned in the response to question number 7, standardization is required for a harmonized implementation of PSD2 and a uniform customer experience. As a final remark ABN AMRO would like to point out that interoperability has proven to have its limitation. A harmonized implementation is required.ABN AMRO does not see particular technical constraints that prevent the industry from using the ISO 20022 standard.
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 ?
Article 20Reference is made to the response of the Dutch Payment Association “Betaalvereniging”. Please find their input below.
“We would like to comment that qualified certificates assure the quality of identification by the CA for the issuing of such a certificate, but not the quality of the technology used to keep the associated private key credentials used for authentication (proof of identity) under sole usage control by its respective owner (a PSP). In order to ensure sole usage control by the respective PSP, we proposes to specify the adequate protection (e.g. crypto smart cards, USB dongles, hardware security modules) for the associated PSP private key credentials, preferably referring to international standards. Based on such an enhanced specification, qualified certificates and associated private key credentials are a common and standard solution for PSP authentication in automated server-server communications.
We agree with the fact that a Qualified Trust Service Provider (QTSP) could provide the certificates to be used for the identification between PSPs and for website authentication subject to sufficient availability of the appropriate certification authorities on the market. However, in the case of PSP software components installed on any common type device (e.g., tablet, mobile phone), owned by the payer, there is no way to enforce sole usage control over private key credentials by the owning PSP, which renders the certificate based approach completely unsuitable for PSP authentication in such a scenario (no mitigation against PSP impersonation attacks).
Article 20.1
To avoid a monopoly for such qualified trust service providers, we consider EBA to add a provision that sufficient (min. five) trusted service providers are available offering the services mentioned.”
In addition to the above ABN AMRO would like to point out that it is important the database/register of qualified and registered PSPs offering PIS and or AIS and or CAF services is maintained on a permanent basis. This register should also offer a push mechanism to inform ASPSPs immediately in case a PSP no longer meets the requirements set by the PSD2 and the RTS to offer PIS and/or AIS and/or CAF services.
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.
ABN AMRO supports the idea of introducing a limit to the frequency with which AIS providers can connect to an ASPSP to update their files, when the payment service user is not actively requesting such information. As mentioned in the RTS a limit is required to ensure availability of the communication interface.ABN AMRO is however concerned about the practical technical implementation; How should the ASPSP make a distinction between an information request by the AIS provider and a customer?