Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
Comment 1
Relative to Strong Authentication as a whole we have the following comment.
The promotion of Strong Authentication is a positive evolution and will certainly contribute to the objectives of enhancing consumer protection.
However we have witnessed initiatives in the past that had the same objectives but did not get the full potential of the intended objectives or simply failed. Some major initiatives failed due to the fact that they were not adopted globally and therefor left significant and major loopholes.
We consider in this case that this situation may reoccur given that these initiatives are limited to Europe.
As an example for card payments, no matter what the level of sophistication of strong authentication used by a PSU, an attacker will continue to harvest credit card numbers and expiry dates through malware botnets or data breaches, as he does today. The credit card number and expiry date are sufficient for the attacker to commit fraud with the compromised card (probably at non-European merchants present on the Internet that will not require any authentication).
These facts should be taken into account for the development of the RTS given that fraud (at least with payment cards and wallets) will most probably continue to be significant independent of the level of sophistication of the required strong authentication.
User experience for PSUs should be foreseen as central objectives for the strong authentication requirements and exemptions in the RTS, and so too to the adoption of risk-based security requirements.
Comment 2 (Paragraphs 27ii. and 43)
In order to avoid possible ambiguities on the scope of applicability of Article 97, it should be clarified that orders sent by e-mail (electronic mail) shall be considered electronic payment transactions in scope of strong customer authentication requirements. Unless cryptographically secured (authenticity, integrity and confidentiality), electronic mail orders imply high risk of payment fraud and other abuses. E-mail orders should not be confused with physical/paper-based mail orders which are excluded from the scope of Article 97.
Comment 3
Having a direct link between the ASPSP and the PSU is significant advantage on a security perspective.
As an example nowadays in an online banking context, an ASPSP may quickly decide to change or introduce new security mechanisms (e.g. the ASPSP may decide to collect the PSU device fingerprinting for risk scoring).
On the other hand in the card payment context, any change would have to involve the preparation of all the participating parties’ (Payment systems, acquirers and merchants) systems. These changes would only be deployable when all systems are ready. In practice such a change would take years to rollout.
In summary the flexibility and time-to-market that banks have nowadays in responding to fraud trends and new evolutions will not be the same with the introduction of PIS/AIS. Critical changes should not depend on unknown third parties, or else it would hamper any innovation initiative.
Furthermore the current wealth of contextual information that the ASPSP may collect from the PSU is hindered when a third party lays between the PSU and the ASPSP. This information is crucial to determine the level of risk and therefore its absence interferes with the security controls and significantly limits the effectiveness of fraud detection systems.
This fact should be contemplated in the development of the standards.
Response to 1.
Response: We identify actions “which may imply risk of payment fraud or other abuses” as any action that may alter the risk level namely changes to elements used for authenticating the PSU, changes to risk parameters or federating other payment instruments. Depending on the context some of these actions may require strong authentication.
Following are examples of actions that alter the risk level:
• When credentials are modified such as: changing a PSU credential (e.g. the OTP mobile phone number) or changing a physical/e-mail address.
• When transaction risk parameters are modified such as: adding a destination account to a white list, setting geographical restrictions or setting amount thresholds that require no, minimum, or strong authentication.
• When federating other payment instruments such as: generating a virtual card (with amount, time or other restrictions) or associating a card to a wallet.
Rationale: Changing any parameter that alters the risk level may require strong authentication. Examples of the rationale behind these are:
• An attacker through malware may change the mobile phone to where OTPs are sent thus getting hold of one of the authentication factors.
• Inserting a destination account into a white list may exempt transactions to that destination account from requiring strong authentication. Strong authentication for this action should be required to avoid an attacker from inserting an e-mule account.
Evidence: We have witnessed attacks that make use of creative techniques to circumvent controls. It is expectable that they will continue to do so.
We consider that data can equally be considered as possession elements given that the entropy of the data be sufficiently large.
Physical objects controlled by the PSU (e.g. hardware token, chip card, SIM card, grid card) can also be considered as possession elements, since securely enrolled and maintained.
There is no absolute guarantee that these elements are only controlled by the PSU (as any other credential even biometric that may be social engineered) however an adequate degree of control may be achieved.
Rationale: Fingerprinting a device can involve the combination of a series of elements such as hardware data, installed programs/apps, software/hardware versions and configurations, mobile IMEI numbers, ISPs, IP addresses, contact list, music list, rendering dynamics, active WiFi hotspot list or, more conventionally, digital certificates.
An adequate combination of these elements will be quite complex for an attacker to reproduce and in practice are used nowadays with a high degree of success especially when used in combination with other controls.
Such features are especially effective for aiding user identification if online monitoring, registering and analysis are made of them, so that the payment instrument is able to perceive changes dynamically and raise authentication standards in real-time, when deviations from registered standards are encountered; or lessen authentication providing a better user experience.
Specifying the conditions under which behaviour-based characteristics may be considered as an inherence element is complex and we have not identified a clear set of rules that could be applied to consider so.
Rationale: It is certainly understandable that when a given PSU usage session takes place in strict conformity to saved patterns, this should be understood as a very clear indication that the probability of the PSU being the authorized person is high.
Hand recognized typing, touching and swiping patterns, or even device inclination stats can contribute to effectively authenticate the PSU.
Same transactions conveying similar amounts, to same destinations, from same origins and at recognized dates, are, not only risk factors to take into consideration but the pattern itself is an inherence element that should be considered.
In essence these elements may be considered risk factors but they are most certainly an effective way to authenticate that indeed the legitimate PSU is performing the transaction.
We have however questioned ourselves to what degree a malware infected device may guarantee the independence of the elements if, for example, simultaneously compromising a password, an SMS OTP and a biometric scanning.
Or at an extreme case, but unfortunately common, compromising the PSU through social engineering can lead to the compromise of all factors, however sophisticated.
Thus the challenge is fundamentally to define under what conditions may one consider two elements to be sufficiently independent as well as the circumstances under which a strict level of independence should be mandatory or not. A balanced approach supported by contextual and transactional risk analysis is advisable, instead of a strict mandatory requirement which might reveal disproportionate or even not effective against fraud.
Rationale: Disconnected possession elements provide further independence from the PSU’s device.
However, for instance the use of chip cards with offline readers (CAP) has not been widely deployed nor well accepted by PSUs/consumers, contrasting with SMS OTPs and grid cards.
Furthermore, behavior-based characteristics like the same transactions conveying similar amounts, to same destinations, from same origins and at recognized dates, might be considered as an independent authentication “inherence” element which in conjunction with other authentication element could in certain circumstances fulfill the objectives of strong customer authentication.
Some present day solutions, that fulfill dynamic linking, require dedicated physical tokens (CAP). However secure they may be, they present negative user experience and we have found them to be detrimental for the promotion for payments on the internet, at least for the majority of users.
Rationale: Various solutions have been used for several years now that link transaction data to authorization codes in a manner that seems to respect the concept described on Article 97(2). That seems to be the case of SMS OTPs where the code is provided within a message where transaction data is also included. Other solutions involve dedicated physical devices, such as security tokens where transaction data is also added in the process of authorization code generation. These, however, often present logistics issues and have a negative impact on the user experience and ease of use, which may lead to bad security practices or to clients simply abandoning the channel.
However mobile devices are one of the best means to achieve these objectives given that they have an ever sophisticated security ecosystem and under the right conditions are very effective in this field.
Furthermore we cannot ignore that by adopting the widely spread and user friendly mobile device as an authentication element, instead of requiring yet another hardware token, we are promoting the development of electronic payments and contributing to support of the growth of the Union economy and thus benefitting the European consumers.
Rationale: Mobile solutions designed with no security considerations are certainly prone to be compromised and thus fail to guarantee an adequate protection.
However high levels of security may be achieved by adopting security mechanisms at all stages, from design to use, and at all levels, from the operating system level to the application level.
Rationale: In a context where new elements are constantly being added to the online risk analysis procedures, new exemptions to strong customer authentication could be taken into consideration thus improving security and user experience.
Such elements may come from the use of existing technology that was not previously considered, new technology features that are continuously being added to PSU’s devices or even additional solutions, independent from currently used ones.
Evidence: As an example we have seen new features surfacing that may be used to consider for new strong customer authentication exemptions. GPS location, 3D Touch or wearables are examples of characteristics that were unavailable in the recent past.
Rationale: There are some merchants where the PSPs have an increased level of trust that could be part of a white list, for example, government institutions, and utilities companies and so on.
Due to the nature of recurring transactions, it would not be practical for the PSU to have all transactions strongly authenticated.
1. the level of risk involved in the service provided;
2. the amount and/or the recurrence of the transaction;
3. the payment channel used for the execution of the transaction.
The discussion paper identifies yet the following criteria:
A. low-value payments as defined in the PSD2 provided that the risk for cumulative transaction are monitored;
B. outgoing payments to trusted beneficiaries included in previously established white lists by a PSU;
C. transfers between two accounts of the same PSU held at the same PSP;
D. low-risk transactions based on a transaction risk analysis (taking into account detailed criteria to be defined in the RTS);
E. purely consultative services, with no display of sensitive payment data, taking into account data privacy laws
Paragraph 45 mentions
a) an adequate transaction history of that customer to evaluate the latter’s typical spending and behaviour patterns,
b) information about the customer device used (e.g. IP address, model, operating system, language preferences) and where applicable
c) a detailed risk profile of the payee (e.g. types of service provided, transaction history) and the payees device (where applicable)
We consider all these as risk criteria, in fact we identify any of the following criteria can influence the decision to require, reduce or exempt strong authentication:
- Originator: PSU risk profile, PSU device[b], PSU geo-location, PSU behavior[a], etc
- Destination: Beneficiary risk profile[c], PSU defined trusted beneficiary[B], ASPSP defined trusted beneficiary, beneficiary device[c], beneficiary geo-location, etc.
- Transaction: amount[2][A], recurrence[2], service provided (financial or consultative)[1][E][c], used channel[3], type of connection to beneficiary (direct or indirect), intra PSU controlled accounts[C], intra ASPSP controlled accounts, non-PSU transaction patterns, fraud transaction patterns, etc.
In summary exemptions should be driven through risk analysis taking into account the relevant previous criteria, but not closed to these.
Rationale: It is important not to leave the set of criteria and circumstances too closed, as the emergence of new technologies and methodologies can bring with them the means for additional authentication that may lessen the need for strong authentication while maintaining optimum risk control levels. In this regard, technologies such as geolocation, wearables and others may be integrated into new solutions that could be used for optimizing/reducing authentication levels.
Rationale: The clarification provides the necessary focus on what players on the payment instrument eco-system must consider and address, be they current players or future ones.
Violating this principle will contribute to increase the attack surface and thus the risk of PSC compromise.
Rationale: In an environment where a large portion of successful fraud attempts are the result of social engineering schemes or rely substantially in PSU unawareness, breaking down one of the key security practices will, most certainly, be a problem.
For the issue of credential sharing with PIS/AIS, it should be strongly considered the possibility of the PSP being allowed to enroll a specific PIS/AIS and to issue specific credentials, for that PIS/AIS, that provide limited access to a given PSU’s accounts/transactions through his explicit authorization. This solution would limit the access of PISs/AISs strictly to the functionality and data that is mentioned on the directive and that the PSUs authorize, and not to other content that is precluded from it and may contain PSUs’ more sensitive data or transaction features.
Rationale: The process of enrolment should also benefit from the use of new technology trends in order to simplify this process for the PSU.
The issuance of specific credentials to a PIS/AIS has not only the benefit of providing the functionality and level of service demanded by the new legislation but also provides a secure, auditable and independent context for PSU activity incoming from PIS/AIS channels and reduces the negative effect of breaking the above mentioned security principle of not-sharing PSUs’ specific PSCs.
Any AIS/PIS solution should be certified and evaluated by third parties analogue to already existing processes like EMVCo, PCI, 3DS, etc.
All service providers including TPPs should comply with these certifications/evaluations.
However it is assumed that the existing certification rules are taken into account for setting concrete requirements in the RTS. Given the fact that organizations are sometimes subject to a wide range of security related certification programs, some rationalization in this field would be appreciated.
It would be beneficial to implement a framework building upon present day certification programs in order to avoid inefficiencies.
Rationale: Organizations are subject to numerous certification programs such as PCI DSS, PCI PIN and ISO 27001, resulting in the repetitive evaluations and auditing of the same systems and processes.
Rationale: Regarding the PSU, the lack of security awareness and the lack of easy to use solutions to secure PSCs are the main reasons.
Regarding the AIS/PIS, we identify that the necessary security controls to protect PSCs - that are already quite well implemented in the banking industry - may not be as mature on this segment of payment chain as they aren’t under the scrutiny of security audits.
Equally there should be means for the PSU to authenticate the AIS/PSU to determine that it is legitimate.
Rationale: It is nowadays very complex for an ASPSP to distinguish between an attacker and an AIS/PIS. It is essential that AIS/PIS authenticate themselves towards ASPSP in order to make the distinction and not trigger the fraud detection engines.
In any case it will be a formidable task to achieve this balance especially in a highly dynamic context, which is the case.
Above all the standards will have to be able to evolve not only for innovative solutions,
that will certainly appear, but also for the natural technological evolution (eg. broken cryptography or protocols; new tools, platforms, frameworks, etc).
Rationale: In areas where maturity levels are high (ranging from EMV to TLS standards) we have witnessed ever evolving standards in response to technological improvements and to new threats. In this highly dynamic arena of payment services on the internet it is crucial to have swift response adapting to new scenarios. Not doing so will be detrimental for the objective of the PSD2 in what relates to the security of electronic payments in order to “ensure the protection of users and the development of a sound environment for e-commerce”.
However the e-IDAS Regulation has been developed to secure an authentication of an identity and not the authenticity and integrity of a payment transaction. The consideration of dynamic linking, behavior based and fraud management are not in the scope of e-IDAS. Therefore e-IDAS would have to be further developed to contemplate these PSD2 essential characteristics.
The dialogue and close collaboration on these matters between the EU institutions and the public and private sectors will be crucial in order to devise secure and effective solutions into that context and broadly to the Digital Single Market.
Indeed, to fully benefit from cross-country and cross-sector use of eID and eTS there is a need for a careful reviewing and clarification of supervision and liability settings, especially in circumstances where both regulations (eIDAS and PSD2) might apply.
Qualified trusted service with a proper level of security assurance for sole control, are conceivable to be used as PSCs for AIS, PIS and ASPSPs.
Alternatively, also certificates from trusted commercial CA's with a secure registration process could be allowed for this purpose, if in line with the PSC level of assurance for PSPs, yet to be specified.
Irrespective of that, a dedicated CA should be established who issues trusted attribute certificates for a proper cross-border identification of all PSPs, registered and regulated according to PSD2.
However, the qualified trust services involved should be subject to the same liabilities as the other participants in the payment value chain. Indeed, careful reviewing and clarification of supervision and liability settings should be ensured.
1. With respect to Article 97(1) (c), are there any additional examples of transactions or actions implying a risk of payment fraud or other abuses that would need to be considered for the RTS? If so, please give details and explain the risks involved.
Comments to the discussion paperComment 1
Relative to Strong Authentication as a whole we have the following comment.
The promotion of Strong Authentication is a positive evolution and will certainly contribute to the objectives of enhancing consumer protection.
However we have witnessed initiatives in the past that had the same objectives but did not get the full potential of the intended objectives or simply failed. Some major initiatives failed due to the fact that they were not adopted globally and therefor left significant and major loopholes.
We consider in this case that this situation may reoccur given that these initiatives are limited to Europe.
As an example for card payments, no matter what the level of sophistication of strong authentication used by a PSU, an attacker will continue to harvest credit card numbers and expiry dates through malware botnets or data breaches, as he does today. The credit card number and expiry date are sufficient for the attacker to commit fraud with the compromised card (probably at non-European merchants present on the Internet that will not require any authentication).
These facts should be taken into account for the development of the RTS given that fraud (at least with payment cards and wallets) will most probably continue to be significant independent of the level of sophistication of the required strong authentication.
User experience for PSUs should be foreseen as central objectives for the strong authentication requirements and exemptions in the RTS, and so too to the adoption of risk-based security requirements.
Comment 2 (Paragraphs 27ii. and 43)
In order to avoid possible ambiguities on the scope of applicability of Article 97, it should be clarified that orders sent by e-mail (electronic mail) shall be considered electronic payment transactions in scope of strong customer authentication requirements. Unless cryptographically secured (authenticity, integrity and confidentiality), electronic mail orders imply high risk of payment fraud and other abuses. E-mail orders should not be confused with physical/paper-based mail orders which are excluded from the scope of Article 97.
Comment 3
Having a direct link between the ASPSP and the PSU is significant advantage on a security perspective.
As an example nowadays in an online banking context, an ASPSP may quickly decide to change or introduce new security mechanisms (e.g. the ASPSP may decide to collect the PSU device fingerprinting for risk scoring).
On the other hand in the card payment context, any change would have to involve the preparation of all the participating parties’ (Payment systems, acquirers and merchants) systems. These changes would only be deployable when all systems are ready. In practice such a change would take years to rollout.
In summary the flexibility and time-to-market that banks have nowadays in responding to fraud trends and new evolutions will not be the same with the introduction of PIS/AIS. Critical changes should not depend on unknown third parties, or else it would hamper any innovation initiative.
Furthermore the current wealth of contextual information that the ASPSP may collect from the PSU is hindered when a third party lays between the PSU and the ASPSP. This information is crucial to determine the level of risk and therefore its absence interferes with the security controls and significantly limits the effectiveness of fraud detection systems.
This fact should be contemplated in the development of the standards.
Response to 1.
Response: We identify actions “which may imply risk of payment fraud or other abuses” as any action that may alter the risk level namely changes to elements used for authenticating the PSU, changes to risk parameters or federating other payment instruments. Depending on the context some of these actions may require strong authentication.
Following are examples of actions that alter the risk level:
• When credentials are modified such as: changing a PSU credential (e.g. the OTP mobile phone number) or changing a physical/e-mail address.
• When transaction risk parameters are modified such as: adding a destination account to a white list, setting geographical restrictions or setting amount thresholds that require no, minimum, or strong authentication.
• When federating other payment instruments such as: generating a virtual card (with amount, time or other restrictions) or associating a card to a wallet.
Rationale: Changing any parameter that alters the risk level may require strong authentication. Examples of the rationale behind these are:
• An attacker through malware may change the mobile phone to where OTPs are sent thus getting hold of one of the authentication factors.
• Inserting a destination account into a white list may exempt transactions to that destination account from requiring strong authentication. Strong authentication for this action should be required to avoid an attacker from inserting an e-mule account.
Evidence: We have witnessed attacks that make use of creative techniques to circumvent controls. It is expectable that they will continue to do so.
2. Which examples of possession elements do you consider as appropriate to be used in the context of strong customer authentication, must these have a physical form or can they be data? If so, can you provide details on how it can be ensured that these data can only be controlled by the PSU?
Response: We are of the opinion that it is possible to consider as possession elements the devices used by PSU’s given that a reasonable number of controls be performed.We consider that data can equally be considered as possession elements given that the entropy of the data be sufficiently large.
Physical objects controlled by the PSU (e.g. hardware token, chip card, SIM card, grid card) can also be considered as possession elements, since securely enrolled and maintained.
There is no absolute guarantee that these elements are only controlled by the PSU (as any other credential even biometric that may be social engineered) however an adequate degree of control may be achieved.
Rationale: Fingerprinting a device can involve the combination of a series of elements such as hardware data, installed programs/apps, software/hardware versions and configurations, mobile IMEI numbers, ISPs, IP addresses, contact list, music list, rendering dynamics, active WiFi hotspot list or, more conventionally, digital certificates.
An adequate combination of these elements will be quite complex for an attacker to reproduce and in practice are used nowadays with a high degree of success especially when used in combination with other controls.
Such features are especially effective for aiding user identification if online monitoring, registering and analysis are made of them, so that the payment instrument is able to perceive changes dynamically and raise authentication standards in real-time, when deviations from registered standards are encountered; or lessen authentication providing a better user experience.
3. Do you consider that in the context of “inherence” elements, behaviour-based characteristics are appropriate to be used in the context of strong customer authentication? If so, can you specify under which conditions?
Response: Yes, behaviour-based characteristics are appropriate to be used in the context of strong customer authentication and can be highly effective.Specifying the conditions under which behaviour-based characteristics may be considered as an inherence element is complex and we have not identified a clear set of rules that could be applied to consider so.
Rationale: It is certainly understandable that when a given PSU usage session takes place in strict conformity to saved patterns, this should be understood as a very clear indication that the probability of the PSU being the authorized person is high.
Hand recognized typing, touching and swiping patterns, or even device inclination stats can contribute to effectively authenticate the PSU.
Same transactions conveying similar amounts, to same destinations, from same origins and at recognized dates, are, not only risk factors to take into consideration but the pattern itself is an inherence element that should be considered.
In essence these elements may be considered risk factors but they are most certainly an effective way to authenticate that indeed the legitimate PSU is performing the transaction.
4. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to the independence of the authentication elements used (e.g. for mobile devices)?
Response: Independence of authentication elements is without doubt a desired attribute that will contribute for the overall security of the authentication process.We have however questioned ourselves to what degree a malware infected device may guarantee the independence of the elements if, for example, simultaneously compromising a password, an SMS OTP and a biometric scanning.
Or at an extreme case, but unfortunately common, compromising the PSU through social engineering can lead to the compromise of all factors, however sophisticated.
Thus the challenge is fundamentally to define under what conditions may one consider two elements to be sufficiently independent as well as the circumstances under which a strict level of independence should be mandatory or not. A balanced approach supported by contextual and transactional risk analysis is advisable, instead of a strict mandatory requirement which might reveal disproportionate or even not effective against fraud.
Rationale: Disconnected possession elements provide further independence from the PSU’s device.
However, for instance the use of chip cards with offline readers (CAP) has not been widely deployed nor well accepted by PSUs/consumers, contrasting with SMS OTPs and grid cards.
Furthermore, behavior-based characteristics like the same transactions conveying similar amounts, to same destinations, from same origins and at recognized dates, might be considered as an independent authentication “inherence” element which in conjunction with other authentication element could in certain circumstances fulfill the objectives of strong customer authentication.
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
Response: One of the identified challenges is related to the fact that at the time of authentication the amount may not be yet known.Some present day solutions, that fulfill dynamic linking, require dedicated physical tokens (CAP). However secure they may be, they present negative user experience and we have found them to be detrimental for the promotion for payments on the internet, at least for the majority of users.
Rationale: Various solutions have been used for several years now that link transaction data to authorization codes in a manner that seems to respect the concept described on Article 97(2). That seems to be the case of SMS OTPs where the code is provided within a message where transaction data is also included. Other solutions involve dedicated physical devices, such as security tokens where transaction data is also added in the process of authorization code generation. These, however, often present logistics issues and have a negative impact on the user experience and ease of use, which may lead to bad security practices or to clients simply abandoning the channel.
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
Response: We cannot consider any solution absolutely secure, and in the case of mobile devices fulfilling the objectives of independence and dynamic linking, it is susceptible to certain attack vectors.However mobile devices are one of the best means to achieve these objectives given that they have an ever sophisticated security ecosystem and under the right conditions are very effective in this field.
Furthermore we cannot ignore that by adopting the widely spread and user friendly mobile device as an authentication element, instead of requiring yet another hardware token, we are promoting the development of electronic payments and contributing to support of the growth of the Union economy and thus benefitting the European consumers.
Rationale: Mobile solutions designed with no security considerations are certainly prone to be compromised and thus fail to guarantee an adequate protection.
However high levels of security may be achieved by adopting security mechanisms at all stages, from design to use, and at all levels, from the operating system level to the application level.
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
Response: Yes. They’re certainly very useful. It is however important to consider that the exemption list should not be provided as a closed one and should be risk based given that any exemption list will not resist future trends, technologies and solutions.Rationale: In a context where new elements are constantly being added to the online risk analysis procedures, new exemptions to strong customer authentication could be taken into consideration thus improving security and user experience.
Such elements may come from the use of existing technology that was not previously considered, new technology features that are continuously being added to PSU’s devices or even additional solutions, independent from currently used ones.
Evidence: As an example we have seen new features surfacing that may be used to consider for new strong customer authentication exemptions. GPS location, 3D Touch or wearables are examples of characteristics that were unavailable in the recent past.
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
Response: We suggest the use of white lists established by the PSP, and not only the ones that are defined by the PSU, to be also considered.Rationale: There are some merchants where the PSPs have an increased level of trust that could be part of a white list, for example, government institutions, and utilities companies and so on.
Due to the nature of recurring transactions, it would not be practical for the PSU to have all transactions strongly authenticated.
9. Are there any other criteria or circumstances which the EBA should consider with respect to transaction risks analysis as a complement or alternative to the criteria identified in paragraph 45?
Response: Article 98.3 mentions the following criteria:1. the level of risk involved in the service provided;
2. the amount and/or the recurrence of the transaction;
3. the payment channel used for the execution of the transaction.
The discussion paper identifies yet the following criteria:
A. low-value payments as defined in the PSD2 provided that the risk for cumulative transaction are monitored;
B. outgoing payments to trusted beneficiaries included in previously established white lists by a PSU;
C. transfers between two accounts of the same PSU held at the same PSP;
D. low-risk transactions based on a transaction risk analysis (taking into account detailed criteria to be defined in the RTS);
E. purely consultative services, with no display of sensitive payment data, taking into account data privacy laws
Paragraph 45 mentions
a) an adequate transaction history of that customer to evaluate the latter’s typical spending and behaviour patterns,
b) information about the customer device used (e.g. IP address, model, operating system, language preferences) and where applicable
c) a detailed risk profile of the payee (e.g. types of service provided, transaction history) and the payees device (where applicable)
We consider all these as risk criteria, in fact we identify any of the following criteria can influence the decision to require, reduce or exempt strong authentication:
- Originator: PSU risk profile, PSU device[b], PSU geo-location, PSU behavior[a], etc
- Destination: Beneficiary risk profile[c], PSU defined trusted beneficiary[B], ASPSP defined trusted beneficiary, beneficiary device[c], beneficiary geo-location, etc.
- Transaction: amount[2][A], recurrence[2], service provided (financial or consultative)[1][E][c], used channel[3], type of connection to beneficiary (direct or indirect), intra PSU controlled accounts[C], intra ASPSP controlled accounts, non-PSU transaction patterns, fraud transaction patterns, etc.
In summary exemptions should be driven through risk analysis taking into account the relevant previous criteria, but not closed to these.
Rationale: It is important not to leave the set of criteria and circumstances too closed, as the emergence of new technologies and methodologies can bring with them the means for additional authentication that may lessen the need for strong authentication while maintaining optimum risk control levels. In this regard, technologies such as geolocation, wearables and others may be integrated into new solutions that could be used for optimizing/reducing authentication levels.
10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
Response: Yes.Rationale: The clarification provides the necessary focus on what players on the payment instrument eco-system must consider and address, be they current players or future ones.
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
Response: One of the major risks foreseeable in this context is the one resulting from the fact that the sound and generally accepted rule that a user must not share his PSC, is broken. The fact that the PSU will have to provide his PSCs to a PIS or to a AIS, will violate this principle.Violating this principle will contribute to increase the attack surface and thus the risk of PSC compromise.
Rationale: In an environment where a large portion of successful fraud attempts are the result of social engineering schemes or rely substantially in PSU unawareness, breaking down one of the key security practices will, most certainly, be a problem.
12. Have you identified innovative solutions for the enrolment process that the EBA should consider which guarantee the confidentiality, integrity and secure transmission (e.g. physical or electronic delivery) of the users’ personalised security credentials?
Response: In the context of creation, issuance and modification of PSCs it seems certainly interesting to consider the possibilities provided by new technology trends including: biometry (recognition of PSUs’ fingerprint, face, iris, voice, and so on), geo-location, combined use of pre-registered PSU’s devices, enhanced reality, wearables (independent), among others.For the issue of credential sharing with PIS/AIS, it should be strongly considered the possibility of the PSP being allowed to enroll a specific PIS/AIS and to issue specific credentials, for that PIS/AIS, that provide limited access to a given PSU’s accounts/transactions through his explicit authorization. This solution would limit the access of PISs/AISs strictly to the functionality and data that is mentioned on the directive and that the PSUs authorize, and not to other content that is precluded from it and may contain PSUs’ more sensitive data or transaction features.
Rationale: The process of enrolment should also benefit from the use of new technology trends in order to simplify this process for the PSU.
The issuance of specific credentials to a PIS/AIS has not only the benefit of providing the functionality and level of service demanded by the new legislation but also provides a secure, auditable and independent context for PSU activity incoming from PIS/AIS channels and reduces the negative effect of breaking the above mentioned security principle of not-sharing PSUs’ specific PSCs.
13. Can you identify alternatives to certification or evaluation by third parties of technical components or devices hosting payment solutions, to ensure that communication channels and technical components hosting, providing access to or transmitting the personalised security credential are sufficiently resistant to tampering and unauthorized access?
Response: We have not identified any alternatives to certifications or evaluations.Any AIS/PIS solution should be certified and evaluated by third parties analogue to already existing processes like EMVCo, PCI, 3DS, etc.
All service providers including TPPs should comply with these certifications/evaluations.
However it is assumed that the existing certification rules are taken into account for setting concrete requirements in the RTS. Given the fact that organizations are sometimes subject to a wide range of security related certification programs, some rationalization in this field would be appreciated.
It would be beneficial to implement a framework building upon present day certification programs in order to avoid inefficiencies.
Rationale: Organizations are subject to numerous certification programs such as PCI DSS, PCI PIN and ISO 27001, resulting in the repetitive evaluations and auditing of the same systems and processes.
14. Can you indicate the segment of the payment chain in which risks to the confidentiality, integrity of users’ personalised security credentials are most likely to occur at present and in the foreseeable future?
Response: We identify the PSUs and the AIS/PIS to be the segments where the compromise of PSCs is most likely to occur.Rationale: Regarding the PSU, the lack of security awareness and the lack of easy to use solutions to secure PSCs are the main reasons.
Regarding the AIS/PIS, we identify that the necessary security controls to protect PSCs - that are already quite well implemented in the banking industry - may not be as mature on this segment of payment chain as they aren’t under the scrutiny of security audits.
15. For each of the topics identified under paragraph 63 above (a to f), do you consider the clarifications provided to be comprehensive and suitable? If not, why not?
Response: One of the clarifications (b) covers the identification of AIS/PIS towards ASPSPs. We believe it should go further and include the authentication of the AIS/PIS with the ASPSP.Equally there should be means for the PSU to authenticate the AIS/PSU to determine that it is legitimate.
Rationale: It is nowadays very complex for an ASPSP to distinguish between an attacker and an AIS/PIS. It is essential that AIS/PIS authenticate themselves towards ASPSP in order to make the distinction and not trigger the fraud detection engines.
16. For each agreed clarification suggested above on which you agree, what should they contain in your view in order to achieve an appropriate balance between harmonisation, innovation while preventing too divergent practical implementations by ASPSPs of the future requirements?
Response: It is very difficult to determine what is presently used without an inventory of the present day implementations. It is essential that the development of standards take this inventory into account.In any case it will be a formidable task to achieve this balance especially in a highly dynamic context, which is the case.
17. In your opinion, is there any standards (existing or in development) outlining aspects that could be common and open, which would be especially suitable for the purpose of ensuring secure communications as well as for the appropriate identification of PSPs taking into consideration the privacy dimension?
Response: We do not have knowledge of any adequate standard that would fulfill the desired characteristics and that would meet every player’s needs.18. How would these requirement for common and open standards need to be designed and maintained to ensure that these are able to securely integrate other innovative business models than the one explicitly mentioned under article 66 and 67 (e.g. issuing of own credentials by the AIS/PIS)?
Response: The standards will have to be designed taking into account that they are sufficiently wide-ranging to cover every reasonable identified functionality and that the implementation be as cost effective as possible.Above all the standards will have to be able to evolve not only for innovative solutions,
that will certainly appear, but also for the natural technological evolution (eg. broken cryptography or protocols; new tools, platforms, frameworks, etc).
Rationale: In areas where maturity levels are high (ranging from EMV to TLS standards) we have witnessed ever evolving standards in response to technological improvements and to new threats. In this highly dynamic arena of payment services on the internet it is crucial to have swift response adapting to new scenarios. Not doing so will be detrimental for the objective of the PSD2 in what relates to the security of electronic payments in order to “ensure the protection of users and the development of a sound environment for e-commerce”.
19. Do you agree that the e-IDAS regulation could be considered as a possible solution for facilitating the strong customer authentication, protecting the confidentiality and the integrity of the payment service users’ personalised security credentials as well as for common and secure open standards of communication for the purpose of identification, DP on future RTS on strong customer and secure communication under PSD2 31 authentication, notification, and information? If yes, please explain how. If no, please explain why.
Response: Stakeholders in retail payments might benefit from the future availability of EU-wide recognized electronic identification (eID) and qualified electronic trust services (eTS) framed under the e-IDAS regulation but contemplating also PSD2 needs.However the e-IDAS Regulation has been developed to secure an authentication of an identity and not the authenticity and integrity of a payment transaction. The consideration of dynamic linking, behavior based and fraud management are not in the scope of e-IDAS. Therefore e-IDAS would have to be further developed to contemplate these PSD2 essential characteristics.
The dialogue and close collaboration on these matters between the EU institutions and the public and private sectors will be crucial in order to devise secure and effective solutions into that context and broadly to the Digital Single Market.
Indeed, to fully benefit from cross-country and cross-sector use of eID and eTS there is a need for a careful reviewing and clarification of supervision and liability settings, especially in circumstances where both regulations (eIDAS and PSD2) might apply.
20. Do you think in particular that the use of “qualified trust services” under e-IDAS regulation could address the risks related to the confidentiality, integrity and availability of PSCs between AIS, PIS providers and ASPSPs? If yes, please identify which services and explain how. If no, please explain why.
Response: Indeed e-IDAS qualified trust services may be adopted and would contribute for a EU-wide solution however, given the critical nature of financial services and the financial gain motivation for cybercriminal groups they should be adopted considering its maturity level.Qualified trusted service with a proper level of security assurance for sole control, are conceivable to be used as PSCs for AIS, PIS and ASPSPs.
Alternatively, also certificates from trusted commercial CA's with a secure registration process could be allowed for this purpose, if in line with the PSC level of assurance for PSPs, yet to be specified.
Irrespective of that, a dedicated CA should be established who issues trusted attribute certificates for a proper cross-border identification of all PSPs, registered and regulated according to PSD2.
However, the qualified trust services involved should be subject to the same liabilities as the other participants in the payment value chain. Indeed, careful reviewing and clarification of supervision and liability settings should be ensured.