Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
(1) paydirekt trusts that the PSD2 and its ancillary regulation, e.g. RTS, sets a framework for e- and m-commerce that drives innovation and prosperity. One of the main challenges is to combine the trust and safety of money transfers with the speed and agility of technical innovations and the requirements of consumers. It is not possible to predict which systems or devices consumers will use in the future and how they will access them.
The success of the PSD2 regulation is highly dependent on the compatibility with further technical developments. One of the utmost key factors that contributes to this issue is absolutely technical neutrality as well as neutrality to the types of payment systems and methods. For example, recent product releases show products that can only be accessed by voice combined with artificial intelligence. One of the major online stores released a product that allows to purchase goods (including the payment process) by pressing just one button – no display, no other input method.
EBA should verify if the RTS draft, especially the strict strong customer authentication requirements, is compatible with consumers’ preferences and the Commissions priority on the Digital Single Market, particularly the strategy regarding the Internet of Things including M2M communication.
On the other hand, it is not sufficient to draft a regulation that only addresses future payments. There is an existing payment market within the European Union which is used by millions of customers on a daily basis throughout different methods, different channels and in different environments. The market has developed various solutions to address these different requirements. Therefore the regulation must be compatible with existing conditions.
(2) In order to drive innovation in a competitive market environment, one of the main objectives of the PSD2 is a level playing field for payment service providers (European Commission - Fact Sheet; Payment Services Directive: frequently asked questions; Brussels, 8 October 2015). PSD2 and the ancillary regulation has to be interpreted in a way that is compatible with this main objective. In addition, EBA has to guarantee fair competition in that market avoiding unjustifiable discrimination against any existing player in the market (Recital 95 of PSD2). Nothing within the RTS should obstruct the level playing field.
We support EBA’s approach to implement principle-based requirements, i.e. developed at a high level. This is the best and only option to achieve a level playing field. Having principle-based rules and not a very specific technical ruleset, each market player is able to implement the rules in a way that suits its business model, and therefore results in different models that compete on a free market and addresses different consumer requirements.
We do not support exemptions regarding sector specific business models especially if this exemption is not addressed in PSD2 because this may cause frictions in the level playing field and every exemption may discriminate other payment solutions. Such exemptions raise the risk that certain - but not all market players - are able to develop an approach that complies with the PSD2 and RTS (Regulatory Technical Standards) by referring to the exemption, but having a significant advantage competing with other business models that cannot refer to the exemption.
(3) We do not agree with EBA that Article 74(2) of PSD2 only applies during a short-time transitional period between the application date of PSD2 and the application date of the RTS (CP, No. 19). Article 74(2) governs the liability if the PSP (payment service provider) does not require SCA. The Article has no temporal restriction.
Such change would negatively impact the balanced approach of the European Parliament and the Council. Article 74(2) of PSD2 is one important pillar for the balanced risked based approach, which is implemented by Article 98(3) of PSD2. Because EBA does not implement the balanced risk-based approach within the RTS, EBA has the need to alter other PSD2 provisions which are part of PSD2’s balanced risk-based approach. However, since the European Parliament and the Council did not empower EBA to decide on the application of Article 74(2), the European Parliament and the Council shows that it is not within EBA’s mandate to decide on the general application of the balanced risk-based approach. As a conclusion it is not within EBA’s mandate to change or limit the provisions of PSD2 unless there is a direct mandate for such change or limitation. As EBA stated itself, EBA’s mandate does not include to alter the application of Article 74(2).
(4) We do not agree with the content of paragraph 29 of the Rationale section, i.e. the exclusion of behavioural data as an inherence element of strong customer authentication. No element of strong customer authentication should be excluded a priori by the RTS as long as no relevant studies exist indicating problems with the security of that element.
Only by implementing a balanced transactional risk-based approach it is possible to gather the necessary information to evaluate it. The implementation could be combined with a closed monitoring on fraud and conversion rates. In addition, EBA could underlie the balanced transactional risk-based approach with key performance indicators; e. g. a PSP is only allowed to rely on a balanced transactional risk-based approach as an exemption for SCA as long as its fraud rate for the balanced transactional risk-based approach is under a specific percentage (2.0 %). This ensures that the balanced transactional risk-based approach still works as an exemption to SCA and only those PSPs can rely on a balanced transactional risk-based approach, that have a low fraud rate. This would boost additional competition and rewards PSP’s with low fraud rates.
EBA in collaboration with the Commission has always the option to address specific issues of the balanced risk-based approach with renewed or amended RTS if the risk-based approach is misused in EBA’s opinion. However by not implementing a balanced risk-based approach, EBA and all market participants cannot evaluate and gather experience with the risk based approach.
(2) There are several reasons that strongly support such an exemption:
• User Friendly: the balanced risk-based approach addresses the needs of the customers to have an easy to use money transfer system; no additional action is required for low risk transactions even if the transferred amount is higher than stated in Article 8.2 (d) of RTS.
• SCA drives cost to goods and services purchased.
• The customer has no additional risk because the PSP is liable if the PSP has not requested SCA (Article 74(2)).
• SCA might discriminate consumers with no or low income. Such groups usually do not have access to the latest and therefore most expensive mobile devices. While there is a chance that the latest mobile devices include features that support convenient SCA or SCA at all by featuring trusted execution environments there is the risk that such group cannot afford the latest mobile devices.
• Level Playing Field: each PSP is able to factor the risk based on its own business model without any additional risks for the customer (in addition, please refer to our answer to Q1).
Requiring SCA is an entry barrier for new or small market players, which leads to monopoles and higher prices.
The European Parliament and the Council understood, that user convenience is a key factor for user acceptance and the success of PSD2. If the consumers do not accept the new payment requirements, e. g. SCA, they will find and use different – probably unregulated - payment methods. Such unregulated payment methods were a main reason to develop the PSD2 regime (European Commission - Fact Sheet; Payment Services Directive: frequently asked questions; Brussels, 8 October 2015). Consumers favored new providers that were unregulated and therefore able to offer cheaper and more convenient payment methods than the regulated ASPSP.
User friendly payment methods are one of the main objectives of the PSD2. Therefore the European Parliament and the Council gave EBA the task to develop the RTS in order to allow user-friendly, accessible and innovative means of payment (Article 98(2) e of PSD2).
On the other hand, developing and offering convenient SCA methods is difficult for small market players. There are technical ways to implement the second factor in a way, that it could be part of a device or within the transaction (e.g. using session tokens). Certain convenient SCAs are available only if device manufactures implement such solutions within their hardware. In addition, they would need to grant PSPs access to such functions. However, it is very likely that access to such functions will raise costs of the payment solution. In another scenario the manufacturer could use such functions exclusively to support its own payment method. EBA should take into account that European payment solutions would be highly dependable on mobile phone manufactures or OS developers. None of the major mobile phone manufactures or OS developers have headquarters within the European Union.
• Centralized transactional risk analysis can quickly be adapted to new or different risks and lowers fraud; while a distributed SCA needs time and raises high costs to adapt to new attack vectors; e.g. it is not always possible to update the mobile phone OS or – in a worst case scenario – change certain hardware if it proves vulnerable after some time.
• The transactional risk analysis promotes innovation and competition.
Without a balanced risk approach there is no incentive for the PSPs to develop robust SCA methods as long as the current method is in compliance with PSD2/RTS. Moreover, without such an incentive PSPs will tend to the cheapest/weakest solution.
With a balanced risk approach a robust SCA is within the PSP’s own interest. It is the PSP’s own interest to improve the risked analysis as good as it can. The more the PSP has improved its risk analysis the merrier it has the option to grant more customers a convenient payment solution. After the risk analysis the PSP has a better understanding, which transactions are at medium and high risks and this raises the need to mitigate the risk with a robust SCA.
• Better adoption to the type of transfer. For example there are different needs, requirements and risks in consumer to consumer/merchant transactions than in business to business transactions. The average amount in a consumer transaction is significant lower than in a business environment. On the other hand, consumers put more attention to convenience than on methods which promote the highest security standards (especially if the PSP has to compensate potential losses).
The exemption for transactional risk analysis should be principle based to achieve all targets mentioned above. However, if EBA seeks to set minimum information within the RTS required for such transaction risk analysis, it should consider the Recommendations for the security of Internet Payments by ECB; especially Recommendation 10.1. In addition, EBA could consider the following information required for such transaction risk analysis:
• Consumer device level (device type, OS/browser, malware (not) present, rooted / jailbroken, device identification, etc.).
• Connection level (direct / indirect, IP-address, IP GeoLocation, ISP, etc.).
• Application level (language of the application, etc.).
• Payer level (profiling, user interaction profiling, click-path profiling, etc.).
• Transactional level (history, beneficiary account, amount, country, urgent/non-urgent payment, etc.).
• Payee or beneficiary level (profiling).
• Big data (data related to fraud / threat environment, customer claims).
(3) We strongly suggest to reassess the explicit amounts set out in Chapter 2. Each PSP should be able to extend the given limits based on a balanced transactional risk analysis. Therefore the limits should work as a baseline.
But even taking such an analysis into account, providing fixed amounts in a regulation, seems short-sighted. Will EBA adjust those amounts based in inflation? The current amount of EUR 10 for electronic payment transactions is far too low for e-commerce.
(4) In addition to white lists (list of trusted beneficiaries) managed by the PSU, white lists managed by ASPSPs should also be possible. Example: white list containing all acceptors having a contract (or authorisation or license) with a given payment scheme.
Security and convenience are two of the main objectives of paydirekt. The system is convenient and easy to use because it is part of the user’s bank account. Security is one fundamental part of the core design. The whole payment process takes place in the secure online environments of the participating ASPSP. The payments can be initiated without transferring any sensitive data (like the credit card or bank account number) to the receiving party. Therefore several attack vectors do not exist and do not have to be mitigated.
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?
paydirekt welcomes the opportunity to comment on EBA’s Consultation Paper (CP) on the draft Regulatory Technology Standards (RTS) specifying requirements on strong customer authentication and common secure communications under PSD2.(1) paydirekt trusts that the PSD2 and its ancillary regulation, e.g. RTS, sets a framework for e- and m-commerce that drives innovation and prosperity. One of the main challenges is to combine the trust and safety of money transfers with the speed and agility of technical innovations and the requirements of consumers. It is not possible to predict which systems or devices consumers will use in the future and how they will access them.
The success of the PSD2 regulation is highly dependent on the compatibility with further technical developments. One of the utmost key factors that contributes to this issue is absolutely technical neutrality as well as neutrality to the types of payment systems and methods. For example, recent product releases show products that can only be accessed by voice combined with artificial intelligence. One of the major online stores released a product that allows to purchase goods (including the payment process) by pressing just one button – no display, no other input method.
EBA should verify if the RTS draft, especially the strict strong customer authentication requirements, is compatible with consumers’ preferences and the Commissions priority on the Digital Single Market, particularly the strategy regarding the Internet of Things including M2M communication.
On the other hand, it is not sufficient to draft a regulation that only addresses future payments. There is an existing payment market within the European Union which is used by millions of customers on a daily basis throughout different methods, different channels and in different environments. The market has developed various solutions to address these different requirements. Therefore the regulation must be compatible with existing conditions.
(2) In order to drive innovation in a competitive market environment, one of the main objectives of the PSD2 is a level playing field for payment service providers (European Commission - Fact Sheet; Payment Services Directive: frequently asked questions; Brussels, 8 October 2015). PSD2 and the ancillary regulation has to be interpreted in a way that is compatible with this main objective. In addition, EBA has to guarantee fair competition in that market avoiding unjustifiable discrimination against any existing player in the market (Recital 95 of PSD2). Nothing within the RTS should obstruct the level playing field.
We support EBA’s approach to implement principle-based requirements, i.e. developed at a high level. This is the best and only option to achieve a level playing field. Having principle-based rules and not a very specific technical ruleset, each market player is able to implement the rules in a way that suits its business model, and therefore results in different models that compete on a free market and addresses different consumer requirements.
We do not support exemptions regarding sector specific business models especially if this exemption is not addressed in PSD2 because this may cause frictions in the level playing field and every exemption may discriminate other payment solutions. Such exemptions raise the risk that certain - but not all market players - are able to develop an approach that complies with the PSD2 and RTS (Regulatory Technical Standards) by referring to the exemption, but having a significant advantage competing with other business models that cannot refer to the exemption.
(3) We do not agree with EBA that Article 74(2) of PSD2 only applies during a short-time transitional period between the application date of PSD2 and the application date of the RTS (CP, No. 19). Article 74(2) governs the liability if the PSP (payment service provider) does not require SCA. The Article has no temporal restriction.
Such change would negatively impact the balanced approach of the European Parliament and the Council. Article 74(2) of PSD2 is one important pillar for the balanced risked based approach, which is implemented by Article 98(3) of PSD2. Because EBA does not implement the balanced risk-based approach within the RTS, EBA has the need to alter other PSD2 provisions which are part of PSD2’s balanced risk-based approach. However, since the European Parliament and the Council did not empower EBA to decide on the application of Article 74(2), the European Parliament and the Council shows that it is not within EBA’s mandate to decide on the general application of the balanced risk-based approach. As a conclusion it is not within EBA’s mandate to change or limit the provisions of PSD2 unless there is a direct mandate for such change or limitation. As EBA stated itself, EBA’s mandate does not include to alter the application of Article 74(2).
(4) We do not agree with the content of paragraph 29 of the Rationale section, i.e. the exclusion of behavioural data as an inherence element of strong customer authentication. No element of strong customer authentication should be excluded a priori by the RTS as long as no relevant studies exist indicating problems with the security of that element.
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?
(1) We encourage EBA to take the opportunity provided by EP / Council and implement an exemption from the application of Article 97 of PSD2 on SCA for low risk transactions based on a balanced transaction risk analysis. Such an exemption is part of the exemptions provided by PSD2 (Article 98(3) (a) of PSD2).Only by implementing a balanced transactional risk-based approach it is possible to gather the necessary information to evaluate it. The implementation could be combined with a closed monitoring on fraud and conversion rates. In addition, EBA could underlie the balanced transactional risk-based approach with key performance indicators; e. g. a PSP is only allowed to rely on a balanced transactional risk-based approach as an exemption for SCA as long as its fraud rate for the balanced transactional risk-based approach is under a specific percentage (2.0 %). This ensures that the balanced transactional risk-based approach still works as an exemption to SCA and only those PSPs can rely on a balanced transactional risk-based approach, that have a low fraud rate. This would boost additional competition and rewards PSP’s with low fraud rates.
EBA in collaboration with the Commission has always the option to address specific issues of the balanced risk-based approach with renewed or amended RTS if the risk-based approach is misused in EBA’s opinion. However by not implementing a balanced risk-based approach, EBA and all market participants cannot evaluate and gather experience with the risk based approach.
(2) There are several reasons that strongly support such an exemption:
• User Friendly: the balanced risk-based approach addresses the needs of the customers to have an easy to use money transfer system; no additional action is required for low risk transactions even if the transferred amount is higher than stated in Article 8.2 (d) of RTS.
• SCA drives cost to goods and services purchased.
• The customer has no additional risk because the PSP is liable if the PSP has not requested SCA (Article 74(2)).
• SCA might discriminate consumers with no or low income. Such groups usually do not have access to the latest and therefore most expensive mobile devices. While there is a chance that the latest mobile devices include features that support convenient SCA or SCA at all by featuring trusted execution environments there is the risk that such group cannot afford the latest mobile devices.
• Level Playing Field: each PSP is able to factor the risk based on its own business model without any additional risks for the customer (in addition, please refer to our answer to Q1).
Requiring SCA is an entry barrier for new or small market players, which leads to monopoles and higher prices.
The European Parliament and the Council understood, that user convenience is a key factor for user acceptance and the success of PSD2. If the consumers do not accept the new payment requirements, e. g. SCA, they will find and use different – probably unregulated - payment methods. Such unregulated payment methods were a main reason to develop the PSD2 regime (European Commission - Fact Sheet; Payment Services Directive: frequently asked questions; Brussels, 8 October 2015). Consumers favored new providers that were unregulated and therefore able to offer cheaper and more convenient payment methods than the regulated ASPSP.
User friendly payment methods are one of the main objectives of the PSD2. Therefore the European Parliament and the Council gave EBA the task to develop the RTS in order to allow user-friendly, accessible and innovative means of payment (Article 98(2) e of PSD2).
On the other hand, developing and offering convenient SCA methods is difficult for small market players. There are technical ways to implement the second factor in a way, that it could be part of a device or within the transaction (e.g. using session tokens). Certain convenient SCAs are available only if device manufactures implement such solutions within their hardware. In addition, they would need to grant PSPs access to such functions. However, it is very likely that access to such functions will raise costs of the payment solution. In another scenario the manufacturer could use such functions exclusively to support its own payment method. EBA should take into account that European payment solutions would be highly dependable on mobile phone manufactures or OS developers. None of the major mobile phone manufactures or OS developers have headquarters within the European Union.
• Centralized transactional risk analysis can quickly be adapted to new or different risks and lowers fraud; while a distributed SCA needs time and raises high costs to adapt to new attack vectors; e.g. it is not always possible to update the mobile phone OS or – in a worst case scenario – change certain hardware if it proves vulnerable after some time.
• The transactional risk analysis promotes innovation and competition.
Without a balanced risk approach there is no incentive for the PSPs to develop robust SCA methods as long as the current method is in compliance with PSD2/RTS. Moreover, without such an incentive PSPs will tend to the cheapest/weakest solution.
With a balanced risk approach a robust SCA is within the PSP’s own interest. It is the PSP’s own interest to improve the risked analysis as good as it can. The more the PSP has improved its risk analysis the merrier it has the option to grant more customers a convenient payment solution. After the risk analysis the PSP has a better understanding, which transactions are at medium and high risks and this raises the need to mitigate the risk with a robust SCA.
• Better adoption to the type of transfer. For example there are different needs, requirements and risks in consumer to consumer/merchant transactions than in business to business transactions. The average amount in a consumer transaction is significant lower than in a business environment. On the other hand, consumers put more attention to convenience than on methods which promote the highest security standards (especially if the PSP has to compensate potential losses).
The exemption for transactional risk analysis should be principle based to achieve all targets mentioned above. However, if EBA seeks to set minimum information within the RTS required for such transaction risk analysis, it should consider the Recommendations for the security of Internet Payments by ECB; especially Recommendation 10.1. In addition, EBA could consider the following information required for such transaction risk analysis:
• Consumer device level (device type, OS/browser, malware (not) present, rooted / jailbroken, device identification, etc.).
• Connection level (direct / indirect, IP-address, IP GeoLocation, ISP, etc.).
• Application level (language of the application, etc.).
• Payer level (profiling, user interaction profiling, click-path profiling, etc.).
• Transactional level (history, beneficiary account, amount, country, urgent/non-urgent payment, etc.).
• Payee or beneficiary level (profiling).
• Big data (data related to fraud / threat environment, customer claims).
(3) We strongly suggest to reassess the explicit amounts set out in Chapter 2. Each PSP should be able to extend the given limits based on a balanced transactional risk analysis. Therefore the limits should work as a baseline.
But even taking such an analysis into account, providing fixed amounts in a regulation, seems short-sighted. Will EBA adjust those amounts based in inflation? The current amount of EUR 10 for electronic payment transactions is far too low for e-commerce.
(4) In addition to white lists (list of trusted beneficiaries) managed by the PSU, white lists managed by ASPSPs should also be possible. Example: white list containing all acceptors having a contract (or authorisation or license) with a given payment scheme.
Please select which category best describes you and/or your organisation
[Small and medium-sized enterprises (SMEs)"]"Please select which category best describes the services provided by you/your organisation
[Other"]"If you selected "Other", please provide details
paydirekt GmbH is a service provider to ASPSP. The paydirekt Service enables the participating ASPSP to offer their customers an electronic payment service. The paydirekt Service is being offered by the ASPSP on one’s own behalf and within the safe infrastructure of an ASPSP. At present paydirekt is offered – among others – by the German cooperative banks, German credit banks, Deutsche Bank, Commerzbank, Postbank, ING-DiBa and Unicredit as Hypovereinsbank.Security and convenience are two of the main objectives of paydirekt. The system is convenient and easy to use because it is part of the user’s bank account. Security is one fundamental part of the core design. The whole payment process takes place in the secure online environments of the participating ASPSP. The payments can be initiated without transferring any sensitive data (like the credit card or bank account number) to the receiving party. Therefore several attack vectors do not exist and do not have to be mitigated.