Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
Many of the trust mechanisms rely on PKI infrastructure - SCA (as well as PSD2 overall) should not overly rely on any one trust chain. The compromise of a root or intermediary CA is possible and a recovery mechanism should be in place to issue new credentials as well as offer alternative trust chains to ensure against systemic failure. In a similar vein, compromise of user credentials is possible (and increasingly common) - mechanisms should be in place to ensure user credentials can be reissued and old credentials revoked on an individual, group and population level. (Article 21 says that users should be notified "without undue delay" - these notifications may be covered by GDPR)"
In particular:
• The syntax of ISO 20022 is based on XML or ASN.1, while it is most likely that the PSPs will opt for exchanging messages in JSON, a format that is more efficient, better supported and more widely adopted for exchanging messages in the context of web API.
• The semantics of ISO 20022 define important base concepts for the financial services industry, however they do not cover the area of customer authentication and authorization that are key for the implementation of PSD2
In general ISO 20022, in its current format, seems to be fit for exchanging information over secure channels established between parties that trust each other, while PSD2 requires a more open model where trust and authorization levels can be established dynamically, through the message exchange.
The AISP requests should differentiate between "live" and "automated" requests which would allow the PISP to decline automated requests to protect the integrity of the service.
PISPs should also offer "push" notifications where there is a change in account balance that the AISP may be interested in (balance falls below €x or balance exceeds €y, for example)."
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?
SCA Requirements - AgreeQuestion 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.
Dynamic linking - agree this should be independent. This would allow for the case where single transactions, multiple transactions and recurring transactions may be dependent on time-based valuations (for example, commodity and currency changes - pay $US100 on the 1st of each month for the next 3 months from a €-denominated account")."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?
Other threats - the use of inherence" features may be subject to "drift" over time - for example fingerprint and facial recognition false +ve and false -ve parameters could be adjusted (or attacked) to allow for impersonation. Mechanisms should be in-place to re calibrate inherence factors (recapture fingerprint / faceprint, etc..).Many of the trust mechanisms rely on PKI infrastructure - SCA (as well as PSD2 overall) should not overly rely on any one trust chain. The compromise of a root or intermediary CA is possible and a recovery mechanism should be in place to issue new credentials as well as offer alternative trust chains to ensure against systemic failure. In a similar vein, compromise of user credentials is possible (and increasingly common) - mechanisms should be in place to ensure user credentials can be reissued and old credentials revoked on an individual, group and population level. (Article 21 says that users should be notified "without undue delay" - these notifications may be covered by GDPR)"
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?
Specific values for individual and cumulative transactions should not be hard-coded" in the regulations. These need to be factored against the user profile and the current threats. Future inflation may make these values unrealistic. The user profiling should also take into account privacy issues - forcing one user to use SCA for a €50 transaction but not another, may expose the "wealth" profile of the user. Having a varying value would draw less attention to individual users."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?
Having hard-coded" values for SCA thresholds provides a known limit for fraudulent transactions to operate under. There should be some randomised trigger as well - possibly based on time, risk profile of the payer and payee and also the intermediaries."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?
Agree. However, the provisions in Article 16 around the review process, do not outline the processes that should or must be in place should any of the tests or reviews indicate the measures are not adequate.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?
We do agree. However, we would mention that such an open set of standards create the need for a common 'Testing' (and potentially certification) process for both API suppliers and consumers to enable the ecosystem to operate effectively without creating the burdensome need for all TPPs to test against Payment Institutions.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?
ISO 20022 can provide a useful starting point for the definition of the messages exchanged between PSPs, however the standard, in its current format, has significant technical constraints that, if not resolved, will prevent its adoptionIn particular:
• The syntax of ISO 20022 is based on XML or ASN.1, while it is most likely that the PSPs will opt for exchanging messages in JSON, a format that is more efficient, better supported and more widely adopted for exchanging messages in the context of web API.
• The semantics of ISO 20022 define important base concepts for the financial services industry, however they do not cover the area of customer authentication and authorization that are key for the implementation of PSD2
In general ISO 20022, in its current format, seems to be fit for exchanging information over secure channels established between parties that trust each other, while PSD2 requires a more open model where trust and authorization levels can be established dynamically, through the message exchange.
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 ?
Agree. The publication of the registration number, which is the same as the authorization number (Article 20(2)) is poor practice - the registration / authorization number should not be used in any security context.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.
ISPs may wish to provide premium" offerings that query accounts more frequently that the "2-times per day" - these should be allowed under the regulations subject to agreement between the parties, which may include payment for the premium service. Also the timing and rate of the requests should be skewed to prevent denial-of-service scenarios.The AISP requests should differentiate between "live" and "automated" requests which would allow the PISP to decline automated requests to protect the integrity of the service.
PISPs should also offer "push" notifications where there is a change in account balance that the AISP may be interested in (balance falls below €x or balance exceeds €y, for example)."