Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
With regard to Art. 3, it should be further clarified in the RTS which requirement is particularly meant regarding the expiration of an element categorised as knowledge (for example, a pass¬word). We would appreciate if the recitals are amended by a respective time frame for the expiration.
With regard to the possible mechanisms that could prevent, detect and block fraudulent payment transactions before the PSP’s final authorization, as outlined in Art. 1 para. 3 lit. e of the draft regulation, the wording of sentence 2 should be amended as follows: “These mechanisms may take into account, but shall not be limited to: (…)”. From our point of view, a mandatory list of mechanisms would strongly interfere with EBA’s technology neutrality as it is outlined in several circumstances in the draft regulation. It should be up to the business model of an ASPSP which mechanisms are to be implemented; this would be in line with the directive from our point of view (cf. Art. 98 para. 2 lit. d PSD II).
On the other hand, a high level formulation of these requirements may lead to many different industry solutions to emerge across the EU. From the perspective of our member institutions, which mostly operate in more than two Member States, therefore a fragmentation of different standards across the EU will increase the burdens for cross-border banking services and, in the end, may undermine the objective of the PSD II of integrating retail payments in the EU and facilitating competition across the EU.
Having this potential national segregation in mind, it should be clarified in the context of
Art. 19 para. 1 of the draft regulation (i. e. ASPSPs offering online payment accounts shall provide at least one communication interface) that ASPSPs are free in their decision – in line with their business model – to which national standard of secure communication they will adhere to. For example, also branches of EU credit institutions established in other Member States (than the Member State of origin) may have in their host Member State the role as ASPSP. If in such (host) Member State, a domestic industry standard for an API has evolved, it shouldn’t be mandatory for the branch to adhere to this national standard; the branch should be free to adhere to the national standard of its Member State of origin, as mostly the implementation of such a standard is done by the headquarter (solo level) resident in the Member State of origin. It shall be noted in the context of Art. 19 para. 4 of the draft regulation that it is therefore sufficient for ASPSP operating via branches in different Member States that the technical specification of their communication interface is documented, the documentation made available for free and publicly on the website of the EU headquarter.
Besides this, we also would like to outline that from a ASPSPs’ perspective, the secure com-munication can only be ensured via a dedicated interface, i.e. not via the online banking interface. Especially with regards to data protection (especially in the light of the new EU General Data Protection Regulation (EU) 2016/67), it cannot be allowed for third party providers to have access to information on other bank products without direct linkage to payment services (i.e. deposits, portfolios, loans). Additionally, in many online banking environments, the customer can also review the general tax information acc. to the domestic tax provisions which the account-providing bank has recorded in order to fulfil its tasks as tax agent (as assigned by the German state). Such tax information may involve the TIN (tax identification number), an exemption order for capital gains or tax certificates. In this context, it must be noted that in Germany, tax information is generally subject to tax secrecy (“Steuergeheimnis” acc. to sec. 30 German Fiscal Code) and account-providing banks may only give such information to tax authorities provided if there is a legal requirement.
Furthermore, in Germany we have this special situation that the account-providing banks are also obliged to participate in an automated procedure to retain the German Church Taxes that are payable on certain capital gains (cf. sec. 51a para. 2c German Income Tax Act). It must be noted that for reasons of the secrecy of religious orientation and the general sensibility of such information, even most of the employees of an account-providing bank are not allowed to see this Church Tax information in the customer’s reference data: it is regulated by law that only bank employees directly involved in the tax deduction process may see the customer’s Church Tax status and that any other person shouldn’t see it (i. e. sec. 51a para. 2c sent. 9 German Income Tax Act). Information on the Church Tax status of a customer is often provided within the online banking environment, so that the customer can know about his own status. This information should never be accessible to an third party providers if they receive account information via the online banking interface. Therefore, any access of third party providers via the online banking interfaces of ASPSPs must be prohibited, especially as they may give insight to the Church Tax information.
And furthermore, PIS providers shall be obliged that they don’t retain fundamental transaction data, such as the reference (“purpose”), from the ASPSP when transmitting the details of a payment order. The ASPSP must of course know all relevant payment information in order to fulfil its requirements stemming from AML/CTF regulation.
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?
We generally share EBA's reasoning with regards to the requirements outlined in Chapter 1.With regard to Art. 3, it should be further clarified in the RTS which requirement is particularly meant regarding the expiration of an element categorised as knowledge (for example, a pass¬word). We would appreciate if the recitals are amended by a respective time frame for the expiration.
With regard to the possible mechanisms that could prevent, detect and block fraudulent payment transactions before the PSP’s final authorization, as outlined in Art. 1 para. 3 lit. e of the draft regulation, the wording of sentence 2 should be amended as follows: “These mechanisms may take into account, but shall not be limited to: (…)”. From our point of view, a mandatory list of mechanisms would strongly interfere with EBA’s technology neutrality as it is outlined in several circumstances in the draft regulation. It should be up to the business model of an ASPSP which mechanisms are to be implemented; this would be in line with the directive from our point of view (cf. Art. 98 para. 2 lit. d PSD II).
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.
We generally share EBA's reasoning with regards to the described neutrality of requirements in the context of the independence or segregation of channels.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?
No comment.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?
Although the general requirement for the involvement of a transaction-risk-based approach as required by Art. 98 para. 1 lit b and para. 3 PSD II is reflected in the consultation paper, res¬pective references in the draft regulation regarding circumstances in which exemptions from the SCA may be applied are missing.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?
We have no comment on the list of exemptions. But in general, it should be clarified if it is mandatory for the PSP to refrain from the SCA in the case an exemption listed is given. Or might it be seen as voluntary to refrain from the SCA? Due to economic considerations (i. e. higher implementation costs), PSPs may decide to apply SCA although the criteria of an exemption is fulfilled.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?
No comment.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?
In general, the Association of Foreign Banks in Germany acknowledges the difficulties the EBA faces to when developing these particular RTS. On the one hand, the RTS should of course be elaborated at a high level in order to leave room for systematic and technological innovation, in particular for the communication requirements between ASPSPs, PIS providers, AIS providers, payers, payees and other payment service providers.On the other hand, a high level formulation of these requirements may lead to many different industry solutions to emerge across the EU. From the perspective of our member institutions, which mostly operate in more than two Member States, therefore a fragmentation of different standards across the EU will increase the burdens for cross-border banking services and, in the end, may undermine the objective of the PSD II of integrating retail payments in the EU and facilitating competition across the EU.
Having this potential national segregation in mind, it should be clarified in the context of
Art. 19 para. 1 of the draft regulation (i. e. ASPSPs offering online payment accounts shall provide at least one communication interface) that ASPSPs are free in their decision – in line with their business model – to which national standard of secure communication they will adhere to. For example, also branches of EU credit institutions established in other Member States (than the Member State of origin) may have in their host Member State the role as ASPSP. If in such (host) Member State, a domestic industry standard for an API has evolved, it shouldn’t be mandatory for the branch to adhere to this national standard; the branch should be free to adhere to the national standard of its Member State of origin, as mostly the implementation of such a standard is done by the headquarter (solo level) resident in the Member State of origin. It shall be noted in the context of Art. 19 para. 4 of the draft regulation that it is therefore sufficient for ASPSP operating via branches in different Member States that the technical specification of their communication interface is documented, the documentation made available for free and publicly on the website of the EU headquarter.
Besides this, we also would like to outline that from a ASPSPs’ perspective, the secure com-munication can only be ensured via a dedicated interface, i.e. not via the online banking interface. Especially with regards to data protection (especially in the light of the new EU General Data Protection Regulation (EU) 2016/67), it cannot be allowed for third party providers to have access to information on other bank products without direct linkage to payment services (i.e. deposits, portfolios, loans). Additionally, in many online banking environments, the customer can also review the general tax information acc. to the domestic tax provisions which the account-providing bank has recorded in order to fulfil its tasks as tax agent (as assigned by the German state). Such tax information may involve the TIN (tax identification number), an exemption order for capital gains or tax certificates. In this context, it must be noted that in Germany, tax information is generally subject to tax secrecy (“Steuergeheimnis” acc. to sec. 30 German Fiscal Code) and account-providing banks may only give such information to tax authorities provided if there is a legal requirement.
Furthermore, in Germany we have this special situation that the account-providing banks are also obliged to participate in an automated procedure to retain the German Church Taxes that are payable on certain capital gains (cf. sec. 51a para. 2c German Income Tax Act). It must be noted that for reasons of the secrecy of religious orientation and the general sensibility of such information, even most of the employees of an account-providing bank are not allowed to see this Church Tax information in the customer’s reference data: it is regulated by law that only bank employees directly involved in the tax deduction process may see the customer’s Church Tax status and that any other person shouldn’t see it (i. e. sec. 51a para. 2c sent. 9 German Income Tax Act). Information on the Church Tax status of a customer is often provided within the online banking environment, so that the customer can know about his own status. This information should never be accessible to an third party providers if they receive account information via the online banking interface. Therefore, any access of third party providers via the online banking interfaces of ASPSPs must be prohibited, especially as they may give insight to the Church Tax information.
And furthermore, PIS providers shall be obliged that they don’t retain fundamental transaction data, such as the reference (“purpose”), from the ASPSP when transmitting the details of a payment order. The ASPSP must of course know all relevant payment information in order to fulfil its requirements stemming from AML/CTF regulation.