Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
Changes suggested
• RTS Refers to Payer throughout – Scope is broader so should refer to “Payment Service User”
• RTS refers to payment services provider – scope is broader so should refer to account service providers also (TPP’s)
• Article 1 3 (d) Reference to “HTTP over TLS” is too specific – requirements should be technology neutral
• Article 1 (3) (e): ii: it is very difficult to detect signs of malware infection, consideration and clarity required.
From an audit perspective, Article 7.1 is not prescriptive enough, i.e. it is open to each PSP to apply their own standards and does not allow for a level playing field. For example:
• Article 7: The frequency of the period of evaluation and audit is not explained. Can clarity be provided?
• Article 7.1 points to periodic testing and evaluation by ‘internal or external independent and certified auditors’. We believe this is either an ‘internal audit team’ or an ‘external independent certified auditor’, please clarify?
• How will the integrity of the audit report be determined?
Article’s 3, 4 and 5: Definition of knowledge, possession and inherence
The RTS should exclude all ‘face-to-face’ payments and payment services completely. The EBA state that chip and pin is a secure method so surely ATM’s should also be exempted. However, there is no apparent reference to ATMs under the exemption section.
If the language is such that the security features listed are mandatory we would dispute the requirement for expiration on knowledge security data such as card or online PINs or security answers. The user experience for customers must be considered and having to change their card PIN number every 4-6 weeks will create friction and generate more frustration and calls to PSPs contact centres.
Concern that “expiration time” & “use of non-repeatable characters” may be out of step with latest industry thinking. If this is the case, then the list provided should not be so prescriptive.
Yes, we agree with the EBA’s reasoning on the exemptions but it would be helpful to understand the general move away from the proposed risk-based approach to SCA, and why a more prescriptive regime is set out. We believe that the EBA did not fulfil its mandate to allow exemptions based on transaction risk analysis.PSD2 clearly contemplates a risk based approach being applied, or catered for, in respect of the use of Strong Customer Authentication (SCA) by Payment Service Providers (PSPs). In this regard, at Art.98, the EBA is tasked with the development of Regulatory Technical Standards (RTS) which will, among other matters, define the use of SCA by PSPs.
Art.98(2)provides;
2. The draft regulatory technical standards referred to in paragraph 1 shall be developed by EBA in order to: (a) ensure an appropriate level of security for payment service users and payment service providers, through the adoption of effective and risk-based requirements;
Art.98(3) provides;
3. The exemptions referred to in point (b) of paragraph 1 shall be based on the following criteria:
(a) the level of risk involved in the service provided;
On this basis, it is clear that risk consideration was intended to be an integral part of the RTS, and, in particular, any exemptions, or situations where PSPs could exclude the use, or application, of the RTS &/or SCA, would incorporate a risk based analysis.
We would like clarity on the following part of the consultation paper:
1. Rationale 48 b)ii and Article 8 1)ii. In essence this is describing the issuing of a monthly access token to access exclusively online account information that does not contain sensitive payment data. Given how 48 b)ii is worded it suggests that it’s possible that an AISP can avail of ongoing access to the customer’s payment account so long as the customer logs onto their ASPSP channel more than once a month i.e. it’s not necessary that the AISP forces the customer to enter their security credentials to refresh the token access via the AISP’s channel/app, instead, once the customer has entered their security credentials via the ASPSP banking channel, all TPPs with appropriate customer consent can avail of this provision of the security credentials?
2. Clarity required on the one month expiry requirement Article 8(1)(a)(ii) refers to exceptions to exemptions where SCA will apply for a period, later than 1 month after the last day when SCA was previously applied. Is this applicable only for AISP’s, because PISP initiated payment transactions must always be validated for 2FA (dual factor authentication)? Further does this mean, that grants or refresh tokens issued to TPPs cannot be more than a month old? In other words, the maximum period allowed for a refresh token to be valid must not be greater than a month after the day it was issued.
3. Article 8(1)(b)(ii): Our understanding is that the cumulative amount of EUR150 is not applicable for a particular period, rather it will be reset to zero whenever SCA is applied when used in POS/Internet transactions.
We do not consider that the RTS should include a hard cumulative limit for contactless transactions of EUR150. Currently, the parameters around cumulative limits or number of transactions are not set by the schemes; they are at the card issuer’s discretion. We think that there should not be a hard limit and the current approach retained.
4. Article 8.1 (b) and 8.2 (d): In addition the values should be harmonised between contactless and remote payment. We believe that €10.00 is too low and suggest this value should be €50.
5. The list of exemptions should not be an exhaustive list, so as to leave the PSP the ability to apply exemptions based on its own transaction risk analysis. An exhaustive list of possible exemptions or criteria to be considered by PSPs for the transaction risk analysis may not be future proof and prevent future innovations in fraud prevention analysis.
6. Article 8.1 and Rationale 19 (b): We understand from the EBA Public Hearing that every merchant has to apply SCA from October 2018. We note that the explicit requirement is not in the draft RTS. However, it is included in Rationale 19 (b).
7. Regarding Rationale 50 and Article 22.1(a) we believe further clarity is required regarding sensitive payment data. If the intention is to ensure fraud is not possible, then sensitive data could be the payees name or payees account number. If this information appears on the narrative of the transaction details on the customer’s account then is it reasonable to determine that to ensure ASPSPs do not provision sensitive payment data to AISPs that any transaction narratives that would contain either a name or account number should be redacted before being provided to the AISP?
• Article 16: The frequency of the period of evaluation and audit is not explained. Can clarity be provided?
• Article 16.1 points to periodic testing and evaluation by ‘internal or external independent and certified auditors’. We believe this is either an ‘internal audit team’ or an ‘external independent certified auditor’, please clarify?
• How will the integrity of the audit report be determined?
1. Article 17(1): Can clarity be provided in relation to the phrase ‘payee’s acceptance devices’? What will be the nature of a secure bilateral communication between payer’s and payee’s device?
2. Article 19(1)(c ): We understand that this means that ASPSPs own and manage the authentication process between their customers and TPPs for non-card based communications interfaces not withstanding a bilateral arrangement.
3. Will there be any industry guidelines as to how the new regime should work (i.e. the fact that we're liable to PSUs for unauthorised payments even where the payment is initiated through a PISP etc.)?
4. Article 19 (2c): Please clarify that while AISPs and PISPs will ‘transmit’ personalised security credentials of a PSU, these will not be visible/accessible by AISP/PISPs (as per Article 21 (5))
5. Article 21.5: PISPs & AISPs should have an obligation to inform ASPSP when an incident occurs. The PISPs should also have liability to “clean up” after any such incident.
1. If the Bank agrees to adopt the approach under eIDAS, do we have to adhere to the criteria set out in Annex IV of eIDAS?
Article 22.5 (b): We agree with limiting access to no more than two times a day when the customer is not requesting the update themselves. There is a risk that large scale PSPs that specialise in data would look for constant real-time updates to utilise big data and provision other services to users which would put pressure on accessibility for other TPPs.
In relation to Article 22(1) (a) - clarity required as to what constitutes “sensitive payment data”? It would be helpful if a definition was provided to align with the meaning given under the EBA Guidelines for Security of Internet Payments.
Re account information requests - can you clarify what information must be provided? e.g. a balance enquiry is this full information including recent transactions and does this need to be provided in real-time? What about historic information of bank statements? For the subsequent 2nd enquiry on the day does the same information need to be provided?
GENERAL COMMENTS
1) The RTS refers to ‘Payment Service Providers issuing card-based payment instruments' in quite a few places. However under Directive (EU) 2015/2366 (“PSD 2”), it is only referenced in a couple of recitals and only under Article 65 (availability of funds). Why is there a greater emphasis for PSP’s issuing card-based payment instruments in this RTS?
2) Executive summary states that the draft RTS……………………ensuring an appropriate level of security for consumers…… - this scope should be broader and cover all Payment/account Service Users
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?
Yes, we agree with the provisions in Chapter 1, particularly around the requirement for a single authentication code for each online access to either, the account, initiating transactions or any other online actions. This ensures a level playing field for the customer experience when the customer uses their own bank or a 3rd party for accessing account details or initiating payments. It also ensures the security standards applied to the customer are determined by the party that is responsible for initial liability when the customer is looking for a refund of a transaction that was un-authorised. By ensuring the customer experience is consistent via the different PSPs it also means customers trust and understand the expected security levels when they transact online.Changes suggested
• RTS Refers to Payer throughout – Scope is broader so should refer to “Payment Service User”
• RTS refers to payment services provider – scope is broader so should refer to account service providers also (TPP’s)
• Article 1 3 (d) Reference to “HTTP over TLS” is too specific – requirements should be technology neutral
• Article 1 (3) (e): ii: it is very difficult to detect signs of malware infection, consideration and clarity required.
From an audit perspective, Article 7.1 is not prescriptive enough, i.e. it is open to each PSP to apply their own standards and does not allow for a level playing field. For example:
• Article 7: The frequency of the period of evaluation and audit is not explained. Can clarity be provided?
• Article 7.1 points to periodic testing and evaluation by ‘internal or external independent and certified auditors’. We believe this is either an ‘internal audit team’ or an ‘external independent certified auditor’, please clarify?
• How will the integrity of the audit report be determined?
Article’s 3, 4 and 5: Definition of knowledge, possession and inherence
The RTS should exclude all ‘face-to-face’ payments and payment services completely. The EBA state that chip and pin is a secure method so surely ATM’s should also be exempted. However, there is no apparent reference to ATMs under the exemption section.
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.
Article 2(2)(b) - Regarding dynamic linking and the issue of segregation versus independence, we believe that consumers should not be forced to use two devices: segregation of channels, apps and device is of the essence. We would envisage that applications (segregated channel) can be segregated inside a single smart phone for instance.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?
With regard to the wording of Articles 3 – 5, the use of the “shall be characterised by security features including, but not limited to, length, complexity, expiration time …” we would suggest that these security features are mere examples of possible security features AS PSPs can adopt.If the language is such that the security features listed are mandatory we would dispute the requirement for expiration on knowledge security data such as card or online PINs or security answers. The user experience for customers must be considered and having to change their card PIN number every 4-6 weeks will create friction and generate more frustration and calls to PSPs contact centres.
Concern that “expiration time” & “use of non-repeatable characters” may be out of step with latest industry thinking. If this is the case, then the list provided should not be so prescriptive.
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?
Chapter 2Yes, we agree with the EBA’s reasoning on the exemptions but it would be helpful to understand the general move away from the proposed risk-based approach to SCA, and why a more prescriptive regime is set out. We believe that the EBA did not fulfil its mandate to allow exemptions based on transaction risk analysis.PSD2 clearly contemplates a risk based approach being applied, or catered for, in respect of the use of Strong Customer Authentication (SCA) by Payment Service Providers (PSPs). In this regard, at Art.98, the EBA is tasked with the development of Regulatory Technical Standards (RTS) which will, among other matters, define the use of SCA by PSPs.
Art.98(2)provides;
2. The draft regulatory technical standards referred to in paragraph 1 shall be developed by EBA in order to: (a) ensure an appropriate level of security for payment service users and payment service providers, through the adoption of effective and risk-based requirements;
Art.98(3) provides;
3. The exemptions referred to in point (b) of paragraph 1 shall be based on the following criteria:
(a) the level of risk involved in the service provided;
On this basis, it is clear that risk consideration was intended to be an integral part of the RTS, and, in particular, any exemptions, or situations where PSPs could exclude the use, or application, of the RTS &/or SCA, would incorporate a risk based analysis.
We would like clarity on the following part of the consultation paper:
1. Rationale 48 b)ii and Article 8 1)ii. In essence this is describing the issuing of a monthly access token to access exclusively online account information that does not contain sensitive payment data. Given how 48 b)ii is worded it suggests that it’s possible that an AISP can avail of ongoing access to the customer’s payment account so long as the customer logs onto their ASPSP channel more than once a month i.e. it’s not necessary that the AISP forces the customer to enter their security credentials to refresh the token access via the AISP’s channel/app, instead, once the customer has entered their security credentials via the ASPSP banking channel, all TPPs with appropriate customer consent can avail of this provision of the security credentials?
2. Clarity required on the one month expiry requirement Article 8(1)(a)(ii) refers to exceptions to exemptions where SCA will apply for a period, later than 1 month after the last day when SCA was previously applied. Is this applicable only for AISP’s, because PISP initiated payment transactions must always be validated for 2FA (dual factor authentication)? Further does this mean, that grants or refresh tokens issued to TPPs cannot be more than a month old? In other words, the maximum period allowed for a refresh token to be valid must not be greater than a month after the day it was issued.
3. Article 8(1)(b)(ii): Our understanding is that the cumulative amount of EUR150 is not applicable for a particular period, rather it will be reset to zero whenever SCA is applied when used in POS/Internet transactions.
We do not consider that the RTS should include a hard cumulative limit for contactless transactions of EUR150. Currently, the parameters around cumulative limits or number of transactions are not set by the schemes; they are at the card issuer’s discretion. We think that there should not be a hard limit and the current approach retained.
4. Article 8.1 (b) and 8.2 (d): In addition the values should be harmonised between contactless and remote payment. We believe that €10.00 is too low and suggest this value should be €50.
5. The list of exemptions should not be an exhaustive list, so as to leave the PSP the ability to apply exemptions based on its own transaction risk analysis. An exhaustive list of possible exemptions or criteria to be considered by PSPs for the transaction risk analysis may not be future proof and prevent future innovations in fraud prevention analysis.
6. Article 8.1 and Rationale 19 (b): We understand from the EBA Public Hearing that every merchant has to apply SCA from October 2018. We note that the explicit requirement is not in the draft RTS. However, it is included in Rationale 19 (b).
7. Regarding Rationale 50 and Article 22.1(a) we believe further clarity is required regarding sensitive payment data. If the intention is to ensure fraud is not possible, then sensitive data could be the payees name or payees account number. If this information appears on the narrative of the transaction details on the customer’s account then is it reasonable to determine that to ensure ASPSPs do not provision sensitive payment data to AISPs that any transaction narratives that would contain either a name or account number should be redacted before being provided to the AISP?
Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?
Yes, we would have a concern if a PSP could not apply SCA on a transaction that meets the exemption criteria. The PSP should always be in control of security around account access and other online transactions and it should be at the discretion of the PSP to apply SCA at a product level, even in exempted cases. For example, should the situation arise that fraud is suspected then it should be possible to request SCA details.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?
From an audit perspective, Article 16.1 is not prescriptive enough, i.e. it is open to each PSP to apply itsr own standards and does not allow for a level playing field. For example:• Article 16: The frequency of the period of evaluation and audit is not explained. Can clarity be provided?
• Article 16.1 points to periodic testing and evaluation by ‘internal or external independent and certified auditors’. We believe this is either an ‘internal audit team’ or an ‘external independent certified auditor’, please clarify?
• How will the integrity of the audit report be determined?
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?
Chapter 4:1. Article 17(1): Can clarity be provided in relation to the phrase ‘payee’s acceptance devices’? What will be the nature of a secure bilateral communication between payer’s and payee’s device?
2. Article 19(1)(c ): We understand that this means that ASPSPs own and manage the authentication process between their customers and TPPs for non-card based communications interfaces not withstanding a bilateral arrangement.
3. Will there be any industry guidelines as to how the new regime should work (i.e. the fact that we're liable to PSUs for unauthorised payments even where the payment is initiated through a PISP etc.)?
4. Article 19 (2c): Please clarify that while AISPs and PISPs will ‘transmit’ personalised security credentials of a PSU, these will not be visible/accessible by AISP/PISPs (as per Article 21 (5))
5. Article 21.5: PISPs & AISPs should have an obligation to inform ASPSP when an incident occurs. The PISPs should also have liability to “clean up” after any such incident.
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?
A broader industry standard (at a point in time) should be used to future proof. Reference is useful, but is there a possibility of future restriction – Will ISO20022 always be the standard of choice?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 ?
Chapter 4 - Article 20(1):1. If the Bank agrees to adopt the approach under eIDAS, do we have to adhere to the criteria set out in Annex IV of eIDAS?
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.
Chapter 4Article 22.5 (b): We agree with limiting access to no more than two times a day when the customer is not requesting the update themselves. There is a risk that large scale PSPs that specialise in data would look for constant real-time updates to utilise big data and provision other services to users which would put pressure on accessibility for other TPPs.
In relation to Article 22(1) (a) - clarity required as to what constitutes “sensitive payment data”? It would be helpful if a definition was provided to align with the meaning given under the EBA Guidelines for Security of Internet Payments.
Re account information requests - can you clarify what information must be provided? e.g. a balance enquiry is this full information including recent transactions and does this need to be provided in real-time? What about historic information of bank statements? For the subsequent 2nd enquiry on the day does the same information need to be provided?
GENERAL COMMENTS
1) The RTS refers to ‘Payment Service Providers issuing card-based payment instruments' in quite a few places. However under Directive (EU) 2015/2366 (“PSD 2”), it is only referenced in a couple of recitals and only under Article 65 (availability of funds). Why is there a greater emphasis for PSP’s issuing card-based payment instruments in this RTS?
2) Executive summary states that the draft RTS……………………ensuring an appropriate level of security for consumers…… - this scope should be broader and cover all Payment/account Service Users