Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
• We do not support the position of the EBA expressed in point 19b of “Background and rationale” section. According to the interpretation of the EBA, Article 74 (2) PSD2 allows the payee or his PSP to resign from strong client authentication during the short transition period between the date of implementation PDS2 (13 January 2018) and the date of implementation of the RTS (October 2018 at the earliest). In our opinion, such interpretation is not justified in the light of PSD2 – we believe that there are no legal grounds or reasons to accept such interpretation. In our opinion, analysis of Art. 98 PSD2, leads to opposite conclusions from those indicated by EBA – broader argumentation on this issue is presented in the answer to question 4. We would like to note, however, that the principle of liability shift" (included inter alia in card organizations rules) is unquestionably one of the most effective means to protect the user against potential losses. “Liability shift” principle works to the advantage of both merchants and payers. Thanks to it, merchants may offer better and more convenient solutions, e.g. one-click payments, increasing conversion and at the same time popularizing cashless payments. There is no doubt that users choose solutions that to the greatest extent allow for quick and convenient transfer of funds to the payee. Enforcing strong authentication for every transaction can (and in our opinion will) make users retreat from non-cash payments and the return of “Cash on Delivery”, which contradicts to the measures taken within the framework of the European Union’s activities for the development of cashless payments.
• The currently observed rapid development of online payments is possible thanks to the fact that merchants and PSPs may use a risk based approach, which often gives the same, and usually even higher level of security as in the case of using “traditional” strong customer authentication. Excessive use of strong customer authentication will reduce customers’ caution, e.g. in the case of popular one-time passwords sent by SMS – the customer after several dozen strong authentications is likely not to pay attention to the content of SMSs (e.g. the amount or recipient), and just re-write the password, which – together with the threat of viruses allowing to modify the content of SMS messages – greatly increases the risk on the user’s side (this in particular relates to older devices not supported by software vendors, which are still present on the market in big amount). In our opinion, the approach of the EBA should be more focused on issues of risk and practical aspects of transaction processing rather than establishing specific, narrowly defined rules. We recommend allowing the possibility not to apply strong customer authentication in a situation where the principle of “liability shift” is agreed between PSPs servicing payer’s and payee’s accounts, as is the case with card schemes (where the card organizations are responsible for establishing the rules), or bilateral agreements between the issuers of payment instruments and acquirers. Card schemes regulate – amongst others – the maximum levels of frauds both on the merchant’s and acquirer’s side, which may be a suggestion for EBA to consider setting maximum levels of frauds when allowing for the wide use of risk-based approach.
• Please explain the reasoning of the EBA’s requirement on the use of a unique code for each user – rationale 22 point b, while according to the RTS (art. 1 par. 1), the code should be unique for a given transaction, not for the payment service user (PSU). This article does not imply a need to use a unique code in a way described in the abovementioned rationale.
• Art. 1 par. 3 point e lists the cases in which the bank would be allowed to block the transaction, which would take place under the procedure of strong authentication. Because these cases are form of restrictions to making payments, and the bank is responsible for the timely processing of payment transactions and for its failures, these cases must be specified in the contract templates for servicing accounts. Under Polish law, consumer contractual provisions should be clear and understandable, not allowing the consumer’s counterparty to make any binding interpretations, as otherwise they may be deemed abusive clauses. Avoiding this risk would be possible by clarification of the situations mentioned in art. 1 par. 3 point e in a form of a closed, clear and unambiguous catalogue. We also kindly ask to indicate what actions (in particular in relation to the customer) should be taken by the ASPSP in case of occurrence of any of the situations mentioned at this point.
• It is not clear whether an “access token” previously generated by the bank (e.g. in OAUTH2 standard) will be sufficient as an element of a strong authentication. Otherwise, in order to fulfil the requirements of strong client authentication, will the user be each time forced to provide his/her ID and password to electronic payment services?
• In terms of art. 1 point 2 b, please clarify the term “at all times”, in particular please indicate whether the requirement applies to each device / channel used in the payment process at any time, or simply in one device / channel at any given time? In our opinion, the best solution would be to limit the requirement only to the moments of initiation and authorization of payments.
• In terms of art. 1 point 3 c, please clarify whether the indicated maximum number of failed authentication attempts is calculated for a specific mechanism separately or jointly for all the mechanisms implemented in the process of authentication of actions performed by the user (access to the account, payment initiation, etc.). Are authentication procedures based on the elements of biometrics excluded from this requirement? In addition, in this area we suggest an explicit indication that this number is determined by the ASPSP.
• In terms of art. 1 point 3 e, it is not clear whether the guidelines on the security/anti-fraud system apply also to third parties (AISP, PISP or PSPs issuing card-based payment instruments)? Having in mind that communication between the ASPSP and the third party is performed in a channel that is encrypted and agreed between the parties, the ASPSP is not able to execute, amongst other, mechanisms to check for indications of infection of the session by malicious software. We are of the opinion that both the ASPSPS and the third party should have a security system in place that meets the requirements specified here."
We also suggest to replace the term “authentication code”, as we believe that the requirement to use two elements of client authentication is a sufficient requirement for strong authentication process. The introduction of the provisions of the authentication code can in our opinion restrict the use of various solutions in accordance with the spirit and principles of PSD2, therefore we suggest to use the term authentication means" / ”authentication method”. Assuming, however, that the concept of authentication code would remain in the RTS, it is necessary to verify and define in more detail, in this article and throughout the RTS, when it refers to the authentication code, and when to the authorisation code.
Having in mind the widespread use of TAN cards and – verified in practice – considerable reluctance of clients to waive use of TAN cards in favour of other methods of authentication (despite the promotional activities undertaken by banks), please indicate whether such authorisation method is permissible under the RTS. If this is not the case, we suggest to introduce an exemption for the possibility of using TAN cards instead of codes generated dynamically for already-enrolled clients, together with the requirement to stop enrolling new clients for this authentication method."
It is also not clear whether the EBA actually expects to periodically change the PIN codes for payment cards, as so the requirements of art. 3 can be understood. We suggest that PIN codes that do not have an expiration date also could be considered as elements of knowledge.
Moreover, it should also be noted that as the RTS allows for contactless payments without PIN, we suggest to include in the RTS provisions allowing for already popular non-contactless payment card transactions without a PIN (e.g. in motorway tolls), in particular due to their characteristics (low amount, difficulty of use for the purposes of fraud) and the fact that they are often necessary (e.g. to ensure the flow of traffic on motorways).
In addition, we suggest to ensure that ASPSPs have the ability to block access of third parties to their infrastructure when there is a security incident related to the third party. Third parties should also be obliged to inform ASPSPs of security incidents that occur in their area. ASPSPs should also have an option of regress to the third party for compensation of losses related to incidents caused by third parties.
Despite the clear indication of the risk-based approach in the PSD2 text, the EBA has decided not to use the principle of “risk based approach” in the RTS. Under the current law (especially the EBA recommendations on the security of online payments) using a strong customer authentication, in many cases, it is left to the discretion of the PSP (including ASPSPs), e.g. for transfers within the same PSP or card payments. In addition, we believe that the mechanism of risk based approach should be introduced for all payment methods, and not only with regard to card payments and transfers within the same payment service provider.
In our opinion, the mechanism of strong customer authentication should be risk-based for all remote transactions and adapted to specific situations, rather than mandatory regardless of the circumstances associated with the transaction, which would contribute to the development of fraud prevention systems. PSPs are now competing not only with price but also with service quality, which consists of effectiveness of fraud prevention while maintaining a satisfactory level of customer conversion. The decision on the use of strong authentication should be determined by customer profile and behaviour, and could take into account e.g. the following factors:
• The value of the transaction – transaction scoring should take into account the average transaction value typical for the payer; unusual behaviour will, for example, occur when the transaction was initiated which several times exceedes the value of the previous user’s purchases.
• The client's location based on IP address, the location of the mobile device, the location of the merchant – huge analytical capabilities are associated with the category of “location”, from comparing IP of the device which initiated payment with the place of issue of a payment instrument (e.g. a card issued in Poland used in transaction initiated in Ghana), to the monitoring of the typical characteristics of buyers in a specific online store (e.g. dominance of cards issued by local issuers vs. initiation of transactions from a Venezuelan IP number).
• Characteristic typical to a given industry (e.g. jewellery, electronics or food stores, tickets for public transport) – which differ in terms of the average value of a transaction (e.g. trade in jewellery store will be tens-hundreds of times higher than in the store that offers online purchases of public transport tickets).
• Behaviour related to a particular method of delivery of goods (electronic or standard shipping) – e.g. purchasing codes to redeem games may carry a higher risk than selling boxed products containing the game on DVD.
• client devices:
- desktop computer – cookies, “device fingerprinting” or personal certificates,
- mobile devices (smartphone, tablet or smartwatch) – a unique mobile application ID (if any) or the device ID,
- other devices (such as a TV or refrigerator) – a unique device ID.
These factors analysed individually or collectively allow for monitoring of transactions and customer behaviour, so as to detect any unnatural behaviour for which it may be necessary to use strong authentication.
We are also of the opinion that the monitoring of a number of factors related to the customer profile and behaviour should be regarded as “a separate element which is characteristic of the customer (inherence)”. Unlike some methods of authentication (e.g. time-limited SMS codes, which can be compromised by phone theft or malicious software), customer behaviour pattern cannot be easily and quickly changed.
In reference to the decision of the EBA not to propose exemptions based on the analysis of transaction risk, limits for enforcing strong customer authentication are set at a very low level (10 Euro for remote electronic transactions). The current provisions of the draft RTS are not adapted to changing market conditions and are very inflexible. It is therefore a significant business obstacle to the development of PSPs, as it does not allow for diversification of suppliers based on more convenient, simpler and safer “user experience”. This low limit will adversely affect all e-commerce market stakeholders, including consumers, because shopping online will be highly unfriendly to the user. We can be sure that the payments market will develop new functionalities and services that will be associated with new risks. Rigid rules (as the limit of 10 Euro) will not apply in the case of these new risks, which is why we suggest leaving market participants some level of freedom on the use of strong customer authentication. Additionally, we are strongly against reducing the permissible rules (trusted beneficiaries exemptions) only to card transactions. In the Recommendations on the security of online payments issued by the EBA, “whitelisting” is related to payment transactions in general, not just credit transfers. The introduction of restrictions only for the “credit transfer” payments is incomprehensible, as the payments market is more diverse and the transfer is only one of the possible forms of transfer of funds by the payer. In addition, we find no justification for the introduction of limits of 10 and 100 Euro, or the reason for which in case of proximity card transactions there is proposed an amount of 50 Euro for a single transaction, despite the fact that in the opinion of many experts this type of transaction involves a risk higher than in case of transactions in the online environment.
With regard to the provisions of art. 8 par. 2 point b, limiting the exemption from strong authentication only to the same amount will work to the disadvantage of users and disproportionately worsen their experience. Therefore, we recommend the withdrawal of the provision that reduces the possibility of resignation from the use of strong authentication only to cases where there is the same amount – instead we propose to reference to the limit set by the user. At the same time, we highlight the risks associated with the fact that such transactions may relate not only to payments for phone bills and similar transactions, but also to the e-commerce platforms and payments processed through intermediaries – it is not clear whether this was the intention of this point. Within this point it is also not clear whether the strong authentication is required when the user for the first time performs a series of transfers to the account which was previously added to the list of trusted recipients.
The provisions of art. 8 par. 2 point c limit the exemption of strong authentication to accounts serviced by the same PSP, which will work to the disadvantage of users, overly limiting the usefulness of services offered by the PSP. Therefore, we recommend the withdrawal of the provision that reduces the possibility of resignation from the use of strong authentication only to cases of accounts serviced by the same PSP, together with the imposition on the PSP, which uses such a withdrawal, an obligation to verify that the payee is the same person as the payer. In addition, in terms of art. 8 par. 2 point a we suggest to include – next to credit transfers – also other forms of electronic payments.
Regarding the exemption from strong authentication for a single operation below 10 Euro (and accumulated less than 100 Euro), it should be noted that currently many banks do not provide for such exemptions and are not willing to implement them. PSPs should be able to apply more stringent rules, which should be explicitly indicated in the RTS. Also, Member States should be able to adapt limits adequate to local conditions. In addition, the introduction of the category of total limit of 100 Euro, above which strong authentication should be used, is too general and needs specification of the conditions, in particular related to time. Similar considerations apply to card transactions (art. 8 point 1 b) in terms of the limits of contactless transactions.
The provisions of art. 13 have a serious impact on the processes and costs of ASPSP, so a question arises whether it is permissible for ASPSPs to provide card or PIN using standard postal items?
It is also not clear whether the provision of art. 9 par. 1 point c forces the use of Hardware Security Module for storing data used by encryption algorithms? Such an interpretation may incur significant costs, and at the same time it should be noted that passwords are often encrypted using one-way algorithms (hashes), which eliminates the need for HSM.
In case of art. 13 point c, please explain in more detail what is meant under the term “property” in case of personalised security credentials. Similarly, in case of art. 15, please specify the precise meaning of the term information related to personalized security credentials".
With regard to art. 16, please clearly specify whether it refers also to third party providers (AISP, PISP or PSPs issuing card-based payment instruments). We also suggest to clarify what kind of certification is mentioned in relation to auditors in art. 16 par. 1."
• We believe that RTS should express in more explicit way than in the current art. 17 par. 1, that the third party is required to identify themselves to ASPSP (and vice versa), regardless of the type of realized transactions. Please also indicate how such a process of mutual identification should be performed, and provide a detailed explanation of the meaning of the term “payee's acceptance device” (e.g. what should be understood as the “payee's acceptance device” in case of transactions in parcel machines, which are implemented as credit transfers).
• We believe that RTS should explicitly indicate that it is not allowed for third parties to base their services on screen scraping. In particular, it is important to note that with such approach, third party will have no practical ability to identify themselves to ASPSP, therefore ASPSP will not be able to block access to sensitive payment data.
• As currently the draft RTS does not explicitly disallow to use screen scraping by third parties, it is necessary to point out how – in such cases – ASPSP should be provided with information that the communication is with the third party and not directly with the customer.
• We suggest to introduce a clear indication that only a solution explicitly indicated by ASPSP can be used by third party as a communication interface, i.e. In case when ASPSP provides a dedicated interface, third party shall not provide – or attempt to provide – its services using other paths.
• Please confirm that when a common standard for communication with third parties is used by several ASPSP, it is acceptable to provide a single, common test environment.
• The RTS should also ensure that the third parties provide ASPSPs with information allowing for the identification of the conditions described in the art. 1 par. 3 point e (indicators of session infection session, etc.). Another approach would generate very high risk that ASPSPs will be unable to uphold the effectiveness of their anti-fraud systems.
• In relation to the rationale 69 point f, in our view, clarification is needed as to who will be responsible for providing sufficient funds to cover the cost of the transaction and the risk of their absence. Payment service providers holding the account (ASPSP), card issuer (PSP) or its user (PSU)? This question is not answered by PSD2, which explicitly prohibits blocking of the funds by ASPSP (art. 67, 68 and 65 par. 4). It is therefore advisable to clarify the RTS provisions in terms of the responsibility for ensuring funds to finalize the transaction initiated by the external card issuer with the use of the account maintained by ASPSP. This responsibility should not lie on the side of ASPSP, since, according to PSD2, ASPSP has no right to block the funds.
• It is also not clear – as it is not described in the RTS – what action should be taken by ASPSP after the providing the card-issuing PSP with information on the availability of funds, in particular whether the ASPSP should carry out a transaction or wait for the user to initiate the payment manually.
• The concept of “relying on the authentication procedures provided by the account servicing payment service provider to the payment service user” is not precise enough – does it refer only to the use of the same authentication and authorization data elements?
• Art. 19 par. 4 imposes the obligation to make publicly available the technical specifications of communication interfaces – one should be aware that this increases the risk in the area of security. It is worth to consider limiting this requirement to provide such documentation only to licensed payment institutions, e.g. through the PSP’s identity provider under eIDAS directive.
• In recital (14) and art. 19. par. 2 amongst the listed entities there is no PSPs offering card-based payments. Does this omission stem from the fact of using a different interface than the AISPs and PISPs?
• Taking into account the need to protect banking secrecy and personal data (in accordance with General Data Protection Regulation, the data of a natural person may be transferred to other entities only with his/her explicit consent), please indicate whether ASPSP should block third party services during the transitional period until the RTS enters into force?
• In terms of functionality and information provided by a dedicated interface to third parties, please indicate what functionality should be available in case of differences in available functionalities between online banking in desktop browser, online banking in mobile browser and mobile banking in the mobile application.
• Please confirm that the management of the register of consents issued by the client in relation to access of third parties to their data may rest on ASPSP; we also suggest adding to the RTS an explicit provision in this respect. It should be noted that in accordance with the General Data Protection Regulation, the data of a natural person may be transferred only with his/her consent, and the lack of keeping the register of consents by ASPSP would prevent the compliance to this requirement.
• Another questionable issue concerns art. 22, which relates to third-party access to information which is bank secrecy. Difficulties in relation to creating such interface will be caused by the fact that such interface should enable for access to all of the data related to account/payment, to which the user has direct access. Therefore, we suggest to include in the RTS an explicit catalogue of information that should be available to AISPs when they use a dedicated interface – we suggest to limit such information only to transaction history. It is worth to mention that lack of such catalogue together with introduction of a requirement to make available almost all of the information (except for sensitive payment data) may lead to a situation where ASPSPs will artificially isolate their account information services (e.g. value-add functionalities such as expense analysis tools) from their basic e-banking platforms and make them available in separate environment, which would significantly worsen user experience.
• In this regard, it should also be noted that the disclosure of information to external entities generates risk of fraud, and the provisions of RTS are not sufficiently precise:
o AISPs should have access to anything but sensitive payment data – exactly what pieces of data should be hidden under this provision? (par. 1, point a);
o PISPs should see the same information on the initiation and execution of payments as would the user performing them directly – that is, what exactly? (par. 1 point b).
These provisions should be clarified, so that the ASPSPs are able to disclose the least amount of information, because current provisions create a vulnerability of generating new risks of frauds. In our opinion, in case of PISP a sufficient verification would be a “yes” or “no” answer (as described in par. 1 point c), whether the account is the amount sufficient to execute the order, and a confirmation of execution of payment – no additional information seems to be necessary for need to implement such services. The wider the range that the external parties will have access to account information, operations performed on it, etc., the lesser extent of banking secrecy will be possible to keep.
• In terms of allowing AIS to access the data of persons who are beneficiaries of transactions, please confirm that this provision is compliant with the General Data Protection Regulation.
• It should also be noted that the draft RTS does not explicitly refer to electronic banking services for enterprises, in particular multi-signature. We suggest that in the case of such services it should be indicated that the initiation of the payment should be on the side of the third party, but the submission of further signatures (as part of the payment authorization) should be on the side of ASPSP.
• We suggest indicating the way of proceeding for reporting and settlement of cases in which third parties recognize that they are subject to discrimination, in particular we suggest an indication that the settlements in this regard should be made by national supervisory authorities competent for given ASPSP.
In relation to the general standards of communication in the online environment (such as HTTP, HTTPS, SSL, and TLS) we share the position of the EBA (“too unspecific for communication standards”). Nevertheless, in order to provide the market with an appropriate level of confidence, we suggest to include such provision at least in the preamble to the RTS.
Referring to the proposal of the EBA to create communication standards based on the requirements of international or European standards organizations, we want to emphasize that in some countries (including Poland) there already are workable solutions for communication between PSPs. Therefore, we strongly believe that it should be possible to develop local (i.e. on a country level) standards, which could also be based on ISO 20022.
In case when the possibility of AIS downloading the data without customer’s active request remains in the RTS, it should be emphasized that the introduction of a new category of interfaces is an expensive project for ASPSPs. Most of ASPSPs currently have complex infrastructures, which use also standards different than those proposed in the draft RTS. More costs for those providers will result from the maintenance of interfaces and having to ensure adequate performance of infrastructure to process (potentially massive) requests from AISPs. We suggest to introduce the possibility for ASPSPs to charge for their services provided to AISPs, at least in the case of exceeding the specified request volume or – otherwise – to allow ASPSPs to limit the interface bandwidth for TPP in such situations.
Criteria that restrict AIS requests should also refer to the intensity of requests per time unit, so that those requests are not sent in large numbers at the same moment – such situation could affect the performance and stability of systems, also from the perspective of customers directly using electronic banking. Adaptation/scaling of infrastructure for a potentially huge number of concurrent messages is very costly.
Also, please clarify whether the approval of requests for access to account information will be covered by the regime of strong customer authentication, i.e. at least once a month. Lack of such requirement can result in inconsistency of security procedures for access to account information directly by the user or via AIS. In our opinion, the rules should be common for all market participants, while ASPSP should be able to enforce the use of strong authentication in accordance with internal risk management policies.
Additionally, please define what is meant by “not actively requesting” – an application may run in the background and, e.g. basing on the scheduled processes, ask for the balance two times a day without user interaction. Should such a process be treated as an active request?
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?
The proposed solutions described in Chapter 1 of the RTS do not raise any major objections from the perspective of the risk of frauds, and generally minimize the risk of unauthorized transactions. We agree with the reasoning of the EBA on a strong client authentication and the resulting proposed provisions contained in Chapter 1 of the RTS, however, we raise the following concerns and remarks:• We do not support the position of the EBA expressed in point 19b of “Background and rationale” section. According to the interpretation of the EBA, Article 74 (2) PSD2 allows the payee or his PSP to resign from strong client authentication during the short transition period between the date of implementation PDS2 (13 January 2018) and the date of implementation of the RTS (October 2018 at the earliest). In our opinion, such interpretation is not justified in the light of PSD2 – we believe that there are no legal grounds or reasons to accept such interpretation. In our opinion, analysis of Art. 98 PSD2, leads to opposite conclusions from those indicated by EBA – broader argumentation on this issue is presented in the answer to question 4. We would like to note, however, that the principle of liability shift" (included inter alia in card organizations rules) is unquestionably one of the most effective means to protect the user against potential losses. “Liability shift” principle works to the advantage of both merchants and payers. Thanks to it, merchants may offer better and more convenient solutions, e.g. one-click payments, increasing conversion and at the same time popularizing cashless payments. There is no doubt that users choose solutions that to the greatest extent allow for quick and convenient transfer of funds to the payee. Enforcing strong authentication for every transaction can (and in our opinion will) make users retreat from non-cash payments and the return of “Cash on Delivery”, which contradicts to the measures taken within the framework of the European Union’s activities for the development of cashless payments.
• The currently observed rapid development of online payments is possible thanks to the fact that merchants and PSPs may use a risk based approach, which often gives the same, and usually even higher level of security as in the case of using “traditional” strong customer authentication. Excessive use of strong customer authentication will reduce customers’ caution, e.g. in the case of popular one-time passwords sent by SMS – the customer after several dozen strong authentications is likely not to pay attention to the content of SMSs (e.g. the amount or recipient), and just re-write the password, which – together with the threat of viruses allowing to modify the content of SMS messages – greatly increases the risk on the user’s side (this in particular relates to older devices not supported by software vendors, which are still present on the market in big amount). In our opinion, the approach of the EBA should be more focused on issues of risk and practical aspects of transaction processing rather than establishing specific, narrowly defined rules. We recommend allowing the possibility not to apply strong customer authentication in a situation where the principle of “liability shift” is agreed between PSPs servicing payer’s and payee’s accounts, as is the case with card schemes (where the card organizations are responsible for establishing the rules), or bilateral agreements between the issuers of payment instruments and acquirers. Card schemes regulate – amongst others – the maximum levels of frauds both on the merchant’s and acquirer’s side, which may be a suggestion for EBA to consider setting maximum levels of frauds when allowing for the wide use of risk-based approach.
• Please explain the reasoning of the EBA’s requirement on the use of a unique code for each user – rationale 22 point b, while according to the RTS (art. 1 par. 1), the code should be unique for a given transaction, not for the payment service user (PSU). This article does not imply a need to use a unique code in a way described in the abovementioned rationale.
• Art. 1 par. 3 point e lists the cases in which the bank would be allowed to block the transaction, which would take place under the procedure of strong authentication. Because these cases are form of restrictions to making payments, and the bank is responsible for the timely processing of payment transactions and for its failures, these cases must be specified in the contract templates for servicing accounts. Under Polish law, consumer contractual provisions should be clear and understandable, not allowing the consumer’s counterparty to make any binding interpretations, as otherwise they may be deemed abusive clauses. Avoiding this risk would be possible by clarification of the situations mentioned in art. 1 par. 3 point e in a form of a closed, clear and unambiguous catalogue. We also kindly ask to indicate what actions (in particular in relation to the customer) should be taken by the ASPSP in case of occurrence of any of the situations mentioned at this point.
• It is not clear whether an “access token” previously generated by the bank (e.g. in OAUTH2 standard) will be sufficient as an element of a strong authentication. Otherwise, in order to fulfil the requirements of strong client authentication, will the user be each time forced to provide his/her ID and password to electronic payment services?
• In terms of art. 1 point 2 b, please clarify the term “at all times”, in particular please indicate whether the requirement applies to each device / channel used in the payment process at any time, or simply in one device / channel at any given time? In our opinion, the best solution would be to limit the requirement only to the moments of initiation and authorization of payments.
• In terms of art. 1 point 3 c, please clarify whether the indicated maximum number of failed authentication attempts is calculated for a specific mechanism separately or jointly for all the mechanisms implemented in the process of authentication of actions performed by the user (access to the account, payment initiation, etc.). Are authentication procedures based on the elements of biometrics excluded from this requirement? In addition, in this area we suggest an explicit indication that this number is determined by the ASPSP.
• In terms of art. 1 point 3 e, it is not clear whether the guidelines on the security/anti-fraud system apply also to third parties (AISP, PISP or PSPs issuing card-based payment instruments)? Having in mind that communication between the ASPSP and the third party is performed in a channel that is encrypted and agreed between the parties, the ASPSP is not able to execute, amongst other, mechanisms to check for indications of infection of the session by malicious software. We are of the opinion that both the ASPSPS and the third party should have a security system in place that meets the requirements specified here."
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.
In case of mobile payments, payment service users use single device and application in order to initiate, verify and authorize transactions. We suggest to include in the RTS a precise definition of the principle of channel separation, adequate to the technology used and the risk management policy of the PSP, including e.g. the use of separate communication channels for initiation of transactions and transmission of authentication codes. We expect that the RTS will take into account the needs of the market and user/customer experience (UX/CX), which result from the technology which is commonly used and widely accepted by consumers. In light of the necessity to ensure the confidentiality of credentials, does EBA expect ASPSPs to verify whether the mobile device is assigned only to one user?We also suggest to replace the term “authentication code”, as we believe that the requirement to use two elements of client authentication is a sufficient requirement for strong authentication process. The introduction of the provisions of the authentication code can in our opinion restrict the use of various solutions in accordance with the spirit and principles of PSD2, therefore we suggest to use the term authentication means" / ”authentication method”. Assuming, however, that the concept of authentication code would remain in the RTS, it is necessary to verify and define in more detail, in this article and throughout the RTS, when it refers to the authentication code, and when to the authorisation code.
Having in mind the widespread use of TAN cards and – verified in practice – considerable reluctance of clients to waive use of TAN cards in favour of other methods of authentication (despite the promotional activities undertaken by banks), please indicate whether such authorisation method is permissible under the RTS. If this is not the case, we suggest to introduce an exemption for the possibility of using TAN cards instead of codes generated dynamically for already-enrolled clients, together with the requirement to stop enrolling new clients for this authentication method."
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?
In our understanding, the definitions contained in art. 3, 4 and 5 are compliant with the principle adopted by the EBA and capacious enough to include the widest possible spectrum of risks. It should be noted, however, that requiring periodic changes of password by the users may in practice result in a decrease of their security, e.g. because of the fact that some part of customers in such situation is likely to use a simple passwords or to keep them written-down. Therefore, we suggest to allow ASPSP to make their own decisions in this regard, on the basis of risk analysis. The same suggestion applies to the requirement of monthly strong authentication of users merely accessing information from the account – there is a high probability that it will cause users’ confusion and in practice increase the effectiveness of phishing attacks.It is also not clear whether the EBA actually expects to periodically change the PIN codes for payment cards, as so the requirements of art. 3 can be understood. We suggest that PIN codes that do not have an expiration date also could be considered as elements of knowledge.
Moreover, it should also be noted that as the RTS allows for contactless payments without PIN, we suggest to include in the RTS provisions allowing for already popular non-contactless payment card transactions without a PIN (e.g. in motorway tolls), in particular due to their characteristics (low amount, difficulty of use for the purposes of fraud) and the fact that they are often necessary (e.g. to ensure the flow of traffic on motorways).
In addition, we suggest to ensure that ASPSPs have the ability to block access of third parties to their infrastructure when there is a security incident related to the third party. Third parties should also be obliged to inform ASPSPs of security incidents that occur in their area. ASPSPs should also have an option of regress to the third party for compensation of losses related to incidents caused by third parties.
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?
ASPSPs should be able to independently decide on the introduction of strong authentication (based on their own risk assessment and security procedures). The supervisory authorities of the Member States have the possibility to influence the ASPSP in a situation when the measures prove to be unefficient or redundant. Member States should also have the possibility of defining quota limits adapted to the specific country characteristics. Therefore, we disagree with the position of the EBA of the “risk based approach” expressed in point 3.2.2. In accordance with art. 98 of PSD2, the EBA “shall, in close cooperation with the ECB and after consulting all relevant stakeholders, including those in the payment services market, reflecting all interests involved, develop draft regulatory technical standards (...) specifying: b) the exemptions from the application of Article 97(1), (2) and (3), based on the criteria established in paragraph 3 of this Article”. At the same time, paragraph 3 refers directly and immediately to the level of risk associated with that service: “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; (...)”.Despite the clear indication of the risk-based approach in the PSD2 text, the EBA has decided not to use the principle of “risk based approach” in the RTS. Under the current law (especially the EBA recommendations on the security of online payments) using a strong customer authentication, in many cases, it is left to the discretion of the PSP (including ASPSPs), e.g. for transfers within the same PSP or card payments. In addition, we believe that the mechanism of risk based approach should be introduced for all payment methods, and not only with regard to card payments and transfers within the same payment service provider.
In our opinion, the mechanism of strong customer authentication should be risk-based for all remote transactions and adapted to specific situations, rather than mandatory regardless of the circumstances associated with the transaction, which would contribute to the development of fraud prevention systems. PSPs are now competing not only with price but also with service quality, which consists of effectiveness of fraud prevention while maintaining a satisfactory level of customer conversion. The decision on the use of strong authentication should be determined by customer profile and behaviour, and could take into account e.g. the following factors:
• The value of the transaction – transaction scoring should take into account the average transaction value typical for the payer; unusual behaviour will, for example, occur when the transaction was initiated which several times exceedes the value of the previous user’s purchases.
• The client's location based on IP address, the location of the mobile device, the location of the merchant – huge analytical capabilities are associated with the category of “location”, from comparing IP of the device which initiated payment with the place of issue of a payment instrument (e.g. a card issued in Poland used in transaction initiated in Ghana), to the monitoring of the typical characteristics of buyers in a specific online store (e.g. dominance of cards issued by local issuers vs. initiation of transactions from a Venezuelan IP number).
• Characteristic typical to a given industry (e.g. jewellery, electronics or food stores, tickets for public transport) – which differ in terms of the average value of a transaction (e.g. trade in jewellery store will be tens-hundreds of times higher than in the store that offers online purchases of public transport tickets).
• Behaviour related to a particular method of delivery of goods (electronic or standard shipping) – e.g. purchasing codes to redeem games may carry a higher risk than selling boxed products containing the game on DVD.
• client devices:
- desktop computer – cookies, “device fingerprinting” or personal certificates,
- mobile devices (smartphone, tablet or smartwatch) – a unique mobile application ID (if any) or the device ID,
- other devices (such as a TV or refrigerator) – a unique device ID.
These factors analysed individually or collectively allow for monitoring of transactions and customer behaviour, so as to detect any unnatural behaviour for which it may be necessary to use strong authentication.
We are also of the opinion that the monitoring of a number of factors related to the customer profile and behaviour should be regarded as “a separate element which is characteristic of the customer (inherence)”. Unlike some methods of authentication (e.g. time-limited SMS codes, which can be compromised by phone theft or malicious software), customer behaviour pattern cannot be easily and quickly changed.
In reference to the decision of the EBA not to propose exemptions based on the analysis of transaction risk, limits for enforcing strong customer authentication are set at a very low level (10 Euro for remote electronic transactions). The current provisions of the draft RTS are not adapted to changing market conditions and are very inflexible. It is therefore a significant business obstacle to the development of PSPs, as it does not allow for diversification of suppliers based on more convenient, simpler and safer “user experience”. This low limit will adversely affect all e-commerce market stakeholders, including consumers, because shopping online will be highly unfriendly to the user. We can be sure that the payments market will develop new functionalities and services that will be associated with new risks. Rigid rules (as the limit of 10 Euro) will not apply in the case of these new risks, which is why we suggest leaving market participants some level of freedom on the use of strong customer authentication. Additionally, we are strongly against reducing the permissible rules (trusted beneficiaries exemptions) only to card transactions. In the Recommendations on the security of online payments issued by the EBA, “whitelisting” is related to payment transactions in general, not just credit transfers. The introduction of restrictions only for the “credit transfer” payments is incomprehensible, as the payments market is more diverse and the transfer is only one of the possible forms of transfer of funds by the payer. In addition, we find no justification for the introduction of limits of 10 and 100 Euro, or the reason for which in case of proximity card transactions there is proposed an amount of 50 Euro for a single transaction, despite the fact that in the opinion of many experts this type of transaction involves a risk higher than in case of transactions in the online environment.
With regard to the provisions of art. 8 par. 2 point b, limiting the exemption from strong authentication only to the same amount will work to the disadvantage of users and disproportionately worsen their experience. Therefore, we recommend the withdrawal of the provision that reduces the possibility of resignation from the use of strong authentication only to cases where there is the same amount – instead we propose to reference to the limit set by the user. At the same time, we highlight the risks associated with the fact that such transactions may relate not only to payments for phone bills and similar transactions, but also to the e-commerce platforms and payments processed through intermediaries – it is not clear whether this was the intention of this point. Within this point it is also not clear whether the strong authentication is required when the user for the first time performs a series of transfers to the account which was previously added to the list of trusted recipients.
The provisions of art. 8 par. 2 point c limit the exemption of strong authentication to accounts serviced by the same PSP, which will work to the disadvantage of users, overly limiting the usefulness of services offered by the PSP. Therefore, we recommend the withdrawal of the provision that reduces the possibility of resignation from the use of strong authentication only to cases of accounts serviced by the same PSP, together with the imposition on the PSP, which uses such a withdrawal, an obligation to verify that the payee is the same person as the payer. In addition, in terms of art. 8 par. 2 point a we suggest to include – next to credit transfers – also other forms of electronic payments.
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?
Referring to the rationale 47 and 48, it should be emphasized that, ultimately, the risk of liability lies with the ASPSP, so in our opinion it is ASPSP who should be able to apply strong authentication also outside the criteria described in the RTS, when it will result from its security policies and procedures. The regulatory bodies of the Member States will have access to ASPSP’s policies and procedures and will be able to interact with the ASPSP in cases when the measures would prove to be redundant. Even though the EBA pointed out during the public hearing that such a possibility can be implied from the mandate of the EBA for the development of RTS contained in PSD2, we suggest to explicitly include such provision in the text of the RTS, e.g. as a recital.Regarding the exemption from strong authentication for a single operation below 10 Euro (and accumulated less than 100 Euro), it should be noted that currently many banks do not provide for such exemptions and are not willing to implement them. PSPs should be able to apply more stringent rules, which should be explicitly indicated in the RTS. Also, Member States should be able to adapt limits adequate to local conditions. In addition, the introduction of the category of total limit of 100 Euro, above which strong authentication should be used, is too general and needs specification of the conditions, in particular related to time. Similar considerations apply to card transactions (art. 8 point 1 b) in terms of the limits of contactless transactions.
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?
Yes, we agree. It should be emphasized that Polish PSP market, with the support of the regulatory bodies, developed and for many years promoted relevant standards amongst users. Banks generally educate customers of the importance of preserving the utmost care and confidentiality in terms of protection of the credentials and, above all, not to pass them to any third parties. Therefore, we believe that it is inappropriate to introduce any relaxation of the rules, especially by requiring disclosure or allowing for the disclosure credentials to third parties, acting as intermediaries under the PSD II. In particular, please confirm that in the light of the requirements of RTS it is acceptable that within the procedure of authentication and authorization it is not required to transmit authentication/authorization data to the third party’s infrastructure, but it is permissible to leave the authentication and authorisation in the sphere of ASPSP. It should be noted that this approach – apart from providing a much higher level of security – will also foster the development of competition in the market TPP, because it is expected that the level of customer confidence in new operators of this type will be higher if customers will not have to worry about the safety of their credentials. Also, in such situation it will be less costly for third parties to provide services based on accounts which use e.g. biometry authentication.The provisions of art. 13 have a serious impact on the processes and costs of ASPSP, so a question arises whether it is permissible for ASPSPs to provide card or PIN using standard postal items?
It is also not clear whether the provision of art. 9 par. 1 point c forces the use of Hardware Security Module for storing data used by encryption algorithms? Such an interpretation may incur significant costs, and at the same time it should be noted that passwords are often encrypted using one-way algorithms (hashes), which eliminates the need for HSM.
In case of art. 13 point c, please explain in more detail what is meant under the term “property” in case of personalised security credentials. Similarly, in case of art. 15, please specify the precise meaning of the term information related to personalized security credentials".
With regard to art. 16, please clearly specify whether it refers also to third party providers (AISP, PISP or PSPs issuing card-based payment instruments). We also suggest to clarify what kind of certification is mentioned in relation to auditors in art. 16 par. 1."
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?
Yes, we agree. The use of widely accepted standards will provide all market participants with the basis for stable development of the business, at the same time ensuring the security of money and data. However, it should be noted that the introduction of a new category of interfaces for communication with AISPSP, PISP and card-issuing PSPs will certainly be a significant challenge to ASPSPs, absorbent in terms of resources and the cost, as ASPSPs usually have complex infrastructure to provide payment services, which works also on the basis of other standards than those proposed in the RTS (in particular in the card payments area). In addition, we draw attention to the following points:• We believe that RTS should express in more explicit way than in the current art. 17 par. 1, that the third party is required to identify themselves to ASPSP (and vice versa), regardless of the type of realized transactions. Please also indicate how such a process of mutual identification should be performed, and provide a detailed explanation of the meaning of the term “payee's acceptance device” (e.g. what should be understood as the “payee's acceptance device” in case of transactions in parcel machines, which are implemented as credit transfers).
• We believe that RTS should explicitly indicate that it is not allowed for third parties to base their services on screen scraping. In particular, it is important to note that with such approach, third party will have no practical ability to identify themselves to ASPSP, therefore ASPSP will not be able to block access to sensitive payment data.
• As currently the draft RTS does not explicitly disallow to use screen scraping by third parties, it is necessary to point out how – in such cases – ASPSP should be provided with information that the communication is with the third party and not directly with the customer.
• We suggest to introduce a clear indication that only a solution explicitly indicated by ASPSP can be used by third party as a communication interface, i.e. In case when ASPSP provides a dedicated interface, third party shall not provide – or attempt to provide – its services using other paths.
• Please confirm that when a common standard for communication with third parties is used by several ASPSP, it is acceptable to provide a single, common test environment.
• The RTS should also ensure that the third parties provide ASPSPs with information allowing for the identification of the conditions described in the art. 1 par. 3 point e (indicators of session infection session, etc.). Another approach would generate very high risk that ASPSPs will be unable to uphold the effectiveness of their anti-fraud systems.
• In relation to the rationale 69 point f, in our view, clarification is needed as to who will be responsible for providing sufficient funds to cover the cost of the transaction and the risk of their absence. Payment service providers holding the account (ASPSP), card issuer (PSP) or its user (PSU)? This question is not answered by PSD2, which explicitly prohibits blocking of the funds by ASPSP (art. 67, 68 and 65 par. 4). It is therefore advisable to clarify the RTS provisions in terms of the responsibility for ensuring funds to finalize the transaction initiated by the external card issuer with the use of the account maintained by ASPSP. This responsibility should not lie on the side of ASPSP, since, according to PSD2, ASPSP has no right to block the funds.
• It is also not clear – as it is not described in the RTS – what action should be taken by ASPSP after the providing the card-issuing PSP with information on the availability of funds, in particular whether the ASPSP should carry out a transaction or wait for the user to initiate the payment manually.
• The concept of “relying on the authentication procedures provided by the account servicing payment service provider to the payment service user” is not precise enough – does it refer only to the use of the same authentication and authorization data elements?
• Art. 19 par. 4 imposes the obligation to make publicly available the technical specifications of communication interfaces – one should be aware that this increases the risk in the area of security. It is worth to consider limiting this requirement to provide such documentation only to licensed payment institutions, e.g. through the PSP’s identity provider under eIDAS directive.
• In recital (14) and art. 19. par. 2 amongst the listed entities there is no PSPs offering card-based payments. Does this omission stem from the fact of using a different interface than the AISPs and PISPs?
• Taking into account the need to protect banking secrecy and personal data (in accordance with General Data Protection Regulation, the data of a natural person may be transferred to other entities only with his/her explicit consent), please indicate whether ASPSP should block third party services during the transitional period until the RTS enters into force?
• In terms of functionality and information provided by a dedicated interface to third parties, please indicate what functionality should be available in case of differences in available functionalities between online banking in desktop browser, online banking in mobile browser and mobile banking in the mobile application.
• Please confirm that the management of the register of consents issued by the client in relation to access of third parties to their data may rest on ASPSP; we also suggest adding to the RTS an explicit provision in this respect. It should be noted that in accordance with the General Data Protection Regulation, the data of a natural person may be transferred only with his/her consent, and the lack of keeping the register of consents by ASPSP would prevent the compliance to this requirement.
• Another questionable issue concerns art. 22, which relates to third-party access to information which is bank secrecy. Difficulties in relation to creating such interface will be caused by the fact that such interface should enable for access to all of the data related to account/payment, to which the user has direct access. Therefore, we suggest to include in the RTS an explicit catalogue of information that should be available to AISPs when they use a dedicated interface – we suggest to limit such information only to transaction history. It is worth to mention that lack of such catalogue together with introduction of a requirement to make available almost all of the information (except for sensitive payment data) may lead to a situation where ASPSPs will artificially isolate their account information services (e.g. value-add functionalities such as expense analysis tools) from their basic e-banking platforms and make them available in separate environment, which would significantly worsen user experience.
• In this regard, it should also be noted that the disclosure of information to external entities generates risk of fraud, and the provisions of RTS are not sufficiently precise:
o AISPs should have access to anything but sensitive payment data – exactly what pieces of data should be hidden under this provision? (par. 1, point a);
o PISPs should see the same information on the initiation and execution of payments as would the user performing them directly – that is, what exactly? (par. 1 point b).
These provisions should be clarified, so that the ASPSPs are able to disclose the least amount of information, because current provisions create a vulnerability of generating new risks of frauds. In our opinion, in case of PISP a sufficient verification would be a “yes” or “no” answer (as described in par. 1 point c), whether the account is the amount sufficient to execute the order, and a confirmation of execution of payment – no additional information seems to be necessary for need to implement such services. The wider the range that the external parties will have access to account information, operations performed on it, etc., the lesser extent of banking secrecy will be possible to keep.
• In terms of allowing AIS to access the data of persons who are beneficiaries of transactions, please confirm that this provision is compliant with the General Data Protection Regulation.
• It should also be noted that the draft RTS does not explicitly refer to electronic banking services for enterprises, in particular multi-signature. We suggest that in the case of such services it should be indicated that the initiation of the payment should be on the side of the third party, but the submission of further signatures (as part of the payment authorization) should be on the side of ASPSP.
• We suggest indicating the way of proceeding for reporting and settlement of cases in which third parties recognize that they are subject to discrimination, in particular we suggest an indication that the settlements in this regard should be made by national supervisory authorities competent for given ASPSP.
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?
We agree with the suggestion to use ISO 20022. However, in order to ensure technological neutrality, the standard should be recommended rather than required to apply.In relation to the general standards of communication in the online environment (such as HTTP, HTTPS, SSL, and TLS) we share the position of the EBA (“too unspecific for communication standards”). Nevertheless, in order to provide the market with an appropriate level of confidence, we suggest to include such provision at least in the preamble to the RTS.
Referring to the proposal of the EBA to create communication standards based on the requirements of international or European standards organizations, we want to emphasize that in some countries (including Poland) there already are workable solutions for communication between PSPs. Therefore, we strongly believe that it should be possible to develop local (i.e. on a country level) standards, which could also be based on ISO 20022.
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 ?
We share the position of the EBA, especially in view of the argument set out in the rationale 73 and 76 in terms of the need for certification of intermediaries in access to the account through dedicated authorities established under eIDAS, because we are convinced that the critical element is the verification of the PSP before issuing a certificate, and the related acceptance of responsibility by the issuer of a certificate (or – as we understand – electronic seal defined in eIDAS). Such an approach should also provide effective protection and stability of services based on the PSD2.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.
We believe that downloading of account information/data should be carried out only on the customer’s active request – otherwise it will cause the need for multiplication of infrastructure capabilities, which involves costs disproportionately large in relation to the aim of AIS services from their users’ perspective.In case when the possibility of AIS downloading the data without customer’s active request remains in the RTS, it should be emphasized that the introduction of a new category of interfaces is an expensive project for ASPSPs. Most of ASPSPs currently have complex infrastructures, which use also standards different than those proposed in the draft RTS. More costs for those providers will result from the maintenance of interfaces and having to ensure adequate performance of infrastructure to process (potentially massive) requests from AISPs. We suggest to introduce the possibility for ASPSPs to charge for their services provided to AISPs, at least in the case of exceeding the specified request volume or – otherwise – to allow ASPSPs to limit the interface bandwidth for TPP in such situations.
Criteria that restrict AIS requests should also refer to the intensity of requests per time unit, so that those requests are not sent in large numbers at the same moment – such situation could affect the performance and stability of systems, also from the perspective of customers directly using electronic banking. Adaptation/scaling of infrastructure for a potentially huge number of concurrent messages is very costly.
Also, please clarify whether the approval of requests for access to account information will be covered by the regime of strong customer authentication, i.e. at least once a month. Lack of such requirement can result in inconsistency of security procedures for access to account information directly by the user or via AIS. In our opinion, the rules should be common for all market participants, while ASPSP should be able to enforce the use of strong authentication in accordance with internal risk management policies.
Additionally, please define what is meant by “not actively requesting” – an application may run in the background and, e.g. basing on the scheduled processes, ask for the balance two times a day without user interaction. Should such a process be treated as an active request?