Association of Foreign Banks in Germany / Verband der Auslandsbanken in Deutschland e.V.
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).
We generally share EBA's reasoning with regards to the described neutrality of requirements in the context of the independence or segregation of channels.
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.
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.
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.
As the SEPA Regulation (EU) 260/2012 already detailed, among other things, the use of the ISO 20022 message standards by PSPs and payment service users, this standard seems now widely accepted in European payment markets and we therefore do not see any particular technical constraint that would prevent the use of it.
In order to support such an uniform European standard, that may receive even further recognition in other fields of financial regulation (AML, for example), we generally agree with the reference on e-IDAS.
As AIS providers may request information from designated payment accounts and associated payment transactions – on the one hand – each time the payment service user is requesting such information or – on the other hand – no more than two times a day given the payment service user doesn’t actively request, it is still questionable how an ASPSP could distinguish those two modes of requests. Due to technological reasons, the mere request cannot be definitely associated with one of the two request modes. This may give an opportunity for AIS providers to request more than two times a day, as the ASPSP cannot know the payment service user’s activity. Therefore, a further mechanism indicating if a request is made by the payment service user on its own or by the AIS provider for other reasons should be taken into account.