Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
Strong customer authentication and exemptions
The ASPSPs have an overriding interest in ensuring and maintaining a high level of access security to both their services and the payment accounts, thus safeguarding customer confidence in their provision of payment services. At the same time, they are aware that the spread of payment services using innovative channels and mobile devices relies on convenience and ease of use. Consequently, they monitor with extreme interest the constant technological developments made in the security sector, and the emergence of solutions and tools that may reconcile divergent requirements.
In order to encourage innovation and take advantage of the resulting benefits, the exemptions to the application of strong customer authentication envisaged by the future RTS should enable the ASPSPs to choose flexibly, from among the widest possible range proposed by the EBA, the criterion or combination of criteria that allows them to classify the transaction as low risk. Due to technological developments, these criteria are constantly evolving since they are linked to the availability of new types of information that, combined in various ways, allow transactions to be identified dynamically.
It is further suggested that bulk payments commonly used by Corporate customers should be added to the exemptions from strong customer authentication, as well as regular payments such as direct debits and standing orders (even without need for the PSU to explicitly include them in a white list, as indicated in paragraph 42.B of the DP).
Pre-authorisation by the payer would avoid any need for subsequent repeated specific payment authorisations, which would be difficult to obtain since the payer does not participate in each individual transaction. Accordingly, a requirement to apply strong customer authentication would not only be inconsistent with the nature of the transaction, but also particularly complex to achieve, with repercussions for the use and spread of these payment services.
Lastly, ABI agrees with the proposed specific exemption for all low-value payments, as envisaged in the PSD2 (see point 42.A).
The transactions or actions implying a risk of payment fraud are constantly evolving and the ASPSPs monitor constantly the new types of transaction exposed to risk. The examples listed in paragraph 27 appears to encompass all types of action carried out via a remote channel that may imply a risk of payment fraud and that should be included among the additional requirements of art. 97(1)(c).
However, with reference to changes to PSU data which could involve a risk of fraud or other abuses, as it may be used for payment transactions, it would be appropriate for the RTS to address this data more specifically and for this data to be defined more clearly with respect to what is indicated both in the text of the PSD2 and in the EBA Guidelines on the security of internet payments. In particular, the PSU data concerned might be limited to the contact details (e-mail, mobile phone number, receiving address for paperwork and security codes etc.) for the channels chosen by the ASPSP and the PSU for communicating the authorisation/execution of a payment.
If the EBA intends also to consider the phase of opening an on line payment account in defining the RTS, it should include a undisputablerecognition process of the client for this phase (e.g. with use of video/photo).
If data is also included, it must be generated using physical support - activated using a PIN, for example - under the PSU's control, in order to protect the PSU in the event of theft. It should not be possible to reuse or replicate the data generated, which should only be valid for a limited period of time.
Having regard for the continuous evolution of the technology adopted by tools with the above characteristics, the following non-exhaustive list provides examples of possession elements that generate data:
• Tokens and software for the generation of OTPs based on encrypted algorithms
• Mobile devices and Mobile apps for the generation of OTPs based on encrypted algorithms
• Mobile telephones for which the code associated with the user (e.g. CallerID) can be checked and which allow client recognition by entering an OTP code
• Display cards that contain certificates or generate OTPs
• Electronic signature certifications, clarifying the cases in which this instrument completely satisfies strong authentication requirements and those in which its use in combination with other instruments is necessary.
It is considered important to allow the ASPSP flexibility in choosing the solution that best meets the requirements established for strong customer authentication, based on appropriate risk analyses and risk mitigation activity.
The continuous technological evolution of payment devices and control tools, the availability of new information about the payments and transactions of the PSU, and the ability to relate them to each other rapidly, may make it possible for the ASPSP to consider these categories in the context of inherence" elements.
At the same time, there are currently complexities and issues associated with both the above categories (possible false positives, replication, statistical reliability, variability etc.); accordingly, it would be advisable for the ASPSP to remain responsible for determining if it is appropriate to select one or more of the above behaviour-based elements as part of its strong customer authentication (or as support for the risk analysis and monitoring associated with a transaction), having regard for the risk profile of the transactions, the maturity of the technological solution identified and the reliability of the behavioural data obtained (in terms of minimising false positives and the chances of replication)."
In this regard, a guiding criterion would be to maintain maximum separation between the payment application and generation of the security elements.
As an example, it might be acceptable to request the joint use of different channels (data via web and sms), different apps (e.g. QR code) and different hardware components (e.g. fingerprint), thus avoiding the vulnerability caused by simple theft of the device and the consequent risk of identity theft. The objective of independence between the elements of strong customer authentication could also be met when the possession" element (such as an OTP generated by a device) is unblocked by a "knowledge" element (PIN or password) or by a biometric element.
In the case of mobile devices, another element to be considered is the technical ability to obtain information in real time about the state of the device (violation, cloned etc.), in order to intervene promptly when necessary, or to block it at the time of access or initiation of a transaction. The fraud management activities carried out by the ASPSP therefore provide fundamental support for the strong customer authentication procedures."
The requirements must also satisfy the diverse needs of end users, consumers and businesses. Businesses authorise individual and bulk payment transactions in the context of a wide variety of internal processes and authorisation levels, depending on the internal allocation of responsibilities.
This introduces various significant new problems of a technical and organisational nature, that must be taken into consideration when drafting the future RTS:
• The algorithms for the calculation of authentication codes must be modified and physical tools that do not support dynamic data must be replaced. Only those with a connector can be retained, if they can be updated. In all cases, those without interconnections will become obsolete. It will also be necessary to modify the interfaces of the applications that use the new algorithms. Additionally, a connection algorithm should also be established for the manufacturers of devices;
• It will be necessary to identify all exemptions in which it is difficult to apply dynamic linking to payments, such as when the amount of the payment is not known;
• It is also necessary to consider the case of bulk payments subject to bulk authorisation (for example, payments in standard ISO20022/XML format), clarifying how to apply the standard when faced with multiple payments involving different beneficiaries and amounts;
• Last but not least, the future requirements might require the sector to make massive investments in order to align the security solutions.
The future RTS should clarify that “dynamic linking” may also be implemented through challenge/response mechanisms.
• Strong customer authentication that certifies the number and device of the PSU (possibly also with biometric recognition);
• Mechanism for the exchange of tokens based on the transaction (dynamic) in a manner that is transparent to the PSU once authenticated, perhaps with the simplification of push notifications used to transmit the request for authorisation of the transaction using a different channel with respect to the mobile device. As an additional security measure, the unique identifier for the transaction, encrypted when generating the OTP, could be sent from the server to the client in an encrypted format together with the client's public key. The generation of an electronic signature could be considered for authorisation purposes.
In all cases, it will be important to be able to authorise mechanisms that monitor constantly for violations of the security of the mobile device, so that additional verification options (e.g. challenge response) can be activated in order to authenticate the PSU.
With reference to point E" in paragraph 42 and to article 97(1)(a), it would be useful to go into greater detail about the potential exemptions to strong authentication of the customer in the case of on-line access to its payment account, when sensitive payment data is not displayed that, if stolen, might give rise to a fraud risk. Accordingly, it would be preferable to add a list, not necessarily complete, of example services solely for reference purposes.
Here as well, it is important for this data to be clearly defined, with respect to what is indicated both in the text of the PSD2 and in the EBA Guidelines on the security of internet payments.
The list of exemptions may change as a result of technological evolution and the assessment of risk."
Pre-authorisation by the payer would avoid any need for subsequent repeated specific payment authorisations, which would be difficult to obtain since the payer does not participate in each individual transaction. Accordingly, a requirement to apply strong customer authentication would not only be inconsistent with the nature of the transaction, but also particularly complex to achieve, with repercussions for the use and spread of these payment services.
Point 42.B could also include cases in which transactions involving a specific beneficiary or a specific type of transaction do not necessarily derive solely from a white list prepared by the PSU, but also from a white list that is defined and created dynamically by the ASPSP and reviewed periodically, or produced by certified third parties (system entities or organisations).
The possible exceptions should also expressly mention Wallet Solutions, to the extent that they satisfy the high security requirements which should be envisaged and monitored by the ASPSP concerned.
In this context, strong authentication should relate exclusively to the moment when the PSU registers the payment data needed for the first time, with more user friendly methods for subsequent transactions, freely determined by the ASPSP.
It is desirable here to identify the guidelines for determining the risk of the solutions being discussed, to allow a weighted assessment on the same scale of reference.
Lastly, ABI agrees with the proposed specific exemption for all low-value payments, as envisaged in the PSD2 (see point 42.A).
• use of security software supplied to the PSU by the ASPSP;
• information provided by the PSU about payment preferences and behaviour (for example, registering the computer used to make the transaction);
• use of geolocalisation data when analysing the history of transactions.
It might also be useful to define standard behaviour models associated with fraudulent transactions, as well as with the behaviour history of PSUs.
In any case, the future RTS should specify clearly that:
• the ASPSPs are responsible for choosing the individual criterion or the best combination of criteria from those allowed;
• the above criteria are merely examples, since the variables to be considered when performing the transaction risk assessment will change continuously over time as a result of constant technological evolution.
• risk analysis on transactions could involve suspension of payment orders sent by the PSU in order to conduct further and more detailed analysis
Protection of personalised security credentials
The arrival of new parties authorised to operate in the payment chain via the Internet objectively increases and complicates the overall set of risks associated with the use of personalised security credentials. The ASPSPs are particularly concerned, when it comes to Internet payments, about cases of phishing and the existence of fraudulent, fake or cloned websites. This is because PSUs might not be able to recognise them and, consequently, prevent unauthorised access to their credentials.
Importantly, the PSD2 requires the new providers (PISP and AISP) to be authorised/registered by the competent national Authorities and subject to their supervision, thus enhancing the security of the entire system. However, in order to increase reliability and the confidence of PSUs in the new channels, while avoiding the introduction of new risks, the future RTS should clearly identify technological solutions that do not require credentials to be shared with third parties, while guaranteeing the effective operations of all parties involved in the payment chain.
Acting between the PSU and the ASPSP, these providers have an inevitable impact on the procedures currently adopted by the ASPSP to analyse risk and manage transaction fraud in real time, increasing their complexity and prompting a need for revision. The EBA should give this aspect close attention when developing the RTS, particularly when determining the security measures to be implemented by third parties, the methods used by the PISP/AISP to inform the ASPSP about the PSU's agreement to use them, and the proper allocation of responsibilities among all parties involved.
The clarification provided in the Discussion Paper is useful. However, it would be also useful to develop the requirements for security credentials specified in the future RTS with reference to the phases of the processes in which the personalised security credentials (PSC) are used, since this breakdown will assist the analysis of risk.
Considering the importance of guaranteeing an adequate level of protection for the PSU's PSCs, it is also believed that the RTS should identify technological solutions that, to avoid introducing new risks, not only do not require the credentials to be shared with third parties, but also inform the ASPSP issuer of the PSCs, in real time, that the PSU has consented to the execution of the transaction via the PISP pursuant to art. 64 of the PSD2.
When it comes to internet payments, cases of phishing and the existence of fraudulent, fake or cloned websites are also of particular importance. This is because PSUs might not be able to recognise them and, consequently, prevent unauthorised access to their credentials.
In this context, the appearance of new parties authorised to operate in the payment chain via the Internet objectively increases and complicates the overall set of risks to which PSUs are exposed, if not appropriately educated about the proper way to carry out remote transactions.
Accordingly, in order to avoid the introduction of excessive risks, it is believed that the future RTS must identify solutions that do not require credentials to be shared with third parties.
Consistent with arts. 66 and 67 of the Directive, the RTS should also specify the requirements and procedures by which third parties guarantee the confidentiality and integrity of the PSCs.
Acting between the PSU and the ASPSP, the new providers (PISP and AISP) risk compromising the security and fraud management functions of the ASPSP which are based on the PSU's behaviour and on the origin of the connections; they also risk limiting the capacity to develop the advanced user recognition functions. The EBA should give this aspect close attention when developing the RTS, particularly when determining the security measures to be implemented by third parties, the methods used by the PISP/AISP to inform the ASPSP about the PSU's agreement to use the third party, and the proper allocation of responsibilities among all parties involved.
Lastly, under the new approach, it will be increasingly important to strengthen the education of customers about the protection of their credentials and the aware and careful use of remote channels.
In any case, there are several innovative solutions for the enrolment process, some of which are indicated below:
• Delivery of two or more parts of the PSCs via separate channels, whether traditional or electronic, or - in any case - delivery of at least one part of the key using a separate channel. However, this process may not facilitate immediate and simple use by the PSU;
• Use of electronic certificates issued in accordance with legal requirements as a useful tool for establishing a secure channel of communications with the customer, so that security credentials can be assigned for access to the payment services;
• With regard to biometrics, the analyses continue to make progress, with the proposal of solutions that combine ever increasing ease of use with security.
• Futhermore it is possible to take into consideration the use of credentials already owned by the PSU and issued in secure process certified by national electronic identification systems
• Make the PSU more responsible for the aware use of technologies, without altering the security levels of the devices used (PC, smartphone, tablet etc.);
• Increase PSU awareness of the risks associated with downloading attachments and files, with improper behaviour when browsing or using e-mail;
• Dedicate greater attention and care to the protection of device hardware and software, using recommended and appropriate tools for the mitigation of risk and the reduction of vulnerabilities (e.g. antivirus software).
Other parts of the payment chain subject to vulnerabilities include:
• Creation and transmission of credentials to the PSU;
• the process of managing service block/unblock situations and loss of credentials
• Accessing the PSU's payment account;
• Communication of payment instructions between PSU and retailer or between ASPSP and retailer;
• Communications between ASPSP and PISP/AISP.
In particular, on this last point, it is believed that significant risks will arise in future with regard to transactions between these new providers (AISP and PISP) and the ASPSP issuer of the PSCs.
For example, the fraud management techniques for the real-time analysis of transaction risk by the ASPSP in the authentication and authorisation phases will be affected by the insertion of a party between the PSU and the ASPSP. In particular, the ASPSP can no long trust that the information used for its transaction risk analysis refers directly to the PSU. The EBA must take this aspect into strong consideration, since it affects the proper allocation of responsibilities between PISP/AISP and ASPSP.
In this regard, the ASPSP should be put in a position to determine if the authorisation to operate of the AISP/PISP is valid at the time when a service request from a PISP or an AISP is received. This authorisation could in fact be withdrawn by the competent Authority at any time.
It would be extremely complex for the ASPSP to make these checks by linking to the national registers of each and every competent Authority in all member States of the European Economic Area. The central electronic register of Payment Institutions, accessible via the EBA website, established pursuant to art. 15 of the PSD2 could - if structured appropriately - be the most suitable tool to act as an updated, reliable, secure and constantly accessible repository of this information. For this purpose, it is suggested that the RTS should require the EBA register to allow ASPSPs to check identities and the validity of the authorisation in real time. This will be fundamental for the security of communications between the ASPSPs, the PISPs and AISPs, in order to allocate responsibilities properly in the event of unauthorised/fraudulent transactions, since both these elements are key to the entire architecture introduced by the PSD2.
Requirements for common and open standards of communication
The EBA highlights that it has not received a mandate to develop or maintain open and common standards of communication or to appoint a central authority for this purpose (paragraph 61).
It is noted, however, that the extreme complexity of defining new operational models and agreed, common and open standards for secure interactions with third parties and PSUs, while avoiding at the same time the emergence of numerous divergent solutions (paragraph 62), will require clear governance in the definition, design and development of a framework of solutions. In this light, it will be appropriate to identify bodies and governance mechanisms whose purpose is to define and manage the development of standards, solutions and operational models consistent with the requirements to be adopted, finding and pulling together solutions that reconcile the divergent needs of stakeholders, market dynamics and the SEPA ecosystem.
It is also noted that the DP does not address the validation of the providers authorised to offer payment and information services by the national competent Authorities.
Before actioning a service request received from a PISP or an AISP, the ASPSP - among other activities - will undoubtedly have to authenticate the third party and check that its authorisation is valid at the time of the request. This authorisation could in fact be withdrawn by the competent Authority at any time.
It would be extremely complex for the ASPSP to make these checks by linking to the national registers of each and every competent Authority in all member States of the European Economic Area. The central electronic register of Payment Institutions, accessible via the EBA website, established pursuant to art. 15 of the PSD2 could - if structured appropriately - be the most suitable tool to act as an updated, reliable, secure and constantly accessible repository of this information. For this purpose, it is suggested that the RTS should require the EBA register to allow ASPSPs to check identities and the validity of the authorisation in real time. This will be fundamental for the security of communications between the ASPSPs, the PISPs and AISPs, in order to allocate responsibilities properly in the event of unauthorised/fraudulent transactions: both these aspects are in fact key to the entire architecture introduced by the PSD2.
In general, the clarifications provided are considered comprehensive and suitable. However, it is not specified how PSUs establish their authenticity with the PISP or the AISP for the execution of transactions or the provision of information services.
With regard to points a) - f), it is worth noting:
a) In relation to what makes a standard common" and "open", that:
• if "open", it must allow specific rules to be followed in the context of a defined form of governance;
• The attribute "common" means that the standard is agreed and interoperable by different parties, even during maintenance.
c) that it is necessary to specify the meaning of "secure manner" and indicate the minimum requirements, such as a 128-bit encryption system with https; encryption keys that make third parties recognisable and identifiable in a transparent and certain manner; guarantee that these third parties do not retain the PSU's data, as required by the PSD2;
d) that access to information on the transactions performed should be included in the range of services to which the requirements apply; the common semantics of information exchanged between the different parties should also be identified.
e) that it is necessary to specify the minimum security controls required for the common and secure open standards of communication, distinguishing between those carried out in real time and those not;
f) that it is necessary to specify the minimum technical requirements applying to the common and secure open standards of communication.
With reference to the consent required by the PSD2 that the PSU must give to the third party when requesting the provision of services, the future RTS should clarify the way in which the PISP/AISP informs the ASPSP about the PSU's consent to use the third party (on a one-off or continuous basis, depending on the service) and about any withdrawal of this consent."
It is stressed that the minimum" requirements, as indicated in paragraph 63, letters d), e) and f), should neither be the cause of excessive and inappropriate investment costs, nor increase the level of risk currently accepted by the ASPSPs that hold the PSU's information."
Given the breadth of the range of possibilities, it is considered that assessment of and selection from the options available can only be carried out once the requirements have been defined, having regard for their level of detail. Specifically, with regard to the development of a standard for communications with third parties based on the requirements specified by the EBA, it would be appropriate for the market to govern itself and indicate the participating parties, in order to facilitate a discussion at international level involving all the stakeholders concerned.
• Intends to limit itself to the provision of requirements and that the ASPSPs must adopt at least one interoperable interface serving all requirements" (point 63.f);
• Highlights that it has not received a mandate to develop or maintain these open and common standards of communication or to appoint a central authority for this purpose (paragraph 61).
It is noted, however, that the extreme complexity of defining new operational models and agreed, common and open standards for secure interactions among ASPSPs third parties and PSUs, while avoiding at the same time the emergence of numerous divergent solutions (paragraph 62), will require the existence of a proper governance in the definition, design and development of a framework of solutions.
In this light, it will be appropriate to identify bodies and governance mechanisms whose purpose is to define and manage the development of standards, solutions and operational models consistent with the requirements to be adopted, finding and pulling together solutions that reconcile the divergent needs of stakeholders, market dynamics and the SEPA ecosystem."
In this regard, while on the one hand the regulation may open up opportunities for the sector, especially in the remote identification of new users, potentially even allowing the provision of cross-border services, on the other, the e-IDAS regulation does not currently appear to provide an effective solution for the specific authentication aspects of the PSU relationship since, in an already contorted and complex context, it would introduce new players and further requirements without any immediately recognisable benefits. It is noted, in fact, that the ASPSPs already give their PSUs personalised security credentials that comply with the regulations, and adopt market standards for the protection of their customers. Nevertheless, application of the e-IDAS Regulation may in future result in the emergence of valid and appropriate solutions that are relevant to payment services, security and relations with the providers of payment and information services.
Wishing to explore this aspect further, it would first be necessary to assess the activities of the providers of qualified trust services in the context of payments, considering - within the general framework of responsibilities envisaged in the PSD2 - the allocation of responsibilities in the event of anomalous behaviour involving the suppliers of those services.
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.
General comments on sections 4.1 and 4.2 of the DPStrong customer authentication and exemptions
The ASPSPs have an overriding interest in ensuring and maintaining a high level of access security to both their services and the payment accounts, thus safeguarding customer confidence in their provision of payment services. At the same time, they are aware that the spread of payment services using innovative channels and mobile devices relies on convenience and ease of use. Consequently, they monitor with extreme interest the constant technological developments made in the security sector, and the emergence of solutions and tools that may reconcile divergent requirements.
In order to encourage innovation and take advantage of the resulting benefits, the exemptions to the application of strong customer authentication envisaged by the future RTS should enable the ASPSPs to choose flexibly, from among the widest possible range proposed by the EBA, the criterion or combination of criteria that allows them to classify the transaction as low risk. Due to technological developments, these criteria are constantly evolving since they are linked to the availability of new types of information that, combined in various ways, allow transactions to be identified dynamically.
It is further suggested that bulk payments commonly used by Corporate customers should be added to the exemptions from strong customer authentication, as well as regular payments such as direct debits and standing orders (even without need for the PSU to explicitly include them in a white list, as indicated in paragraph 42.B of the DP).
Pre-authorisation by the payer would avoid any need for subsequent repeated specific payment authorisations, which would be difficult to obtain since the payer does not participate in each individual transaction. Accordingly, a requirement to apply strong customer authentication would not only be inconsistent with the nature of the transaction, but also particularly complex to achieve, with repercussions for the use and spread of these payment services.
Lastly, ABI agrees with the proposed specific exemption for all low-value payments, as envisaged in the PSD2 (see point 42.A).
The transactions or actions implying a risk of payment fraud are constantly evolving and the ASPSPs monitor constantly the new types of transaction exposed to risk. The examples listed in paragraph 27 appears to encompass all types of action carried out via a remote channel that may imply a risk of payment fraud and that should be included among the additional requirements of art. 97(1)(c).
However, with reference to changes to PSU data which could involve a risk of fraud or other abuses, as it may be used for payment transactions, it would be appropriate for the RTS to address this data more specifically and for this data to be defined more clearly with respect to what is indicated both in the text of the PSD2 and in the EBA Guidelines on the security of internet payments. In particular, the PSU data concerned might be limited to the contact details (e-mail, mobile phone number, receiving address for paperwork and security codes etc.) for the channels chosen by the ASPSP and the PSU for communicating the authorisation/execution of a payment.
If the EBA intends also to consider the phase of opening an on line payment account in defining the RTS, it should include a undisputablerecognition process of the client for this phase (e.g. with use of video/photo).
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?
We believe physical objects held exclusively by the customer to be the most appropriate as possession elements.If data is also included, it must be generated using physical support - activated using a PIN, for example - under the PSU's control, in order to protect the PSU in the event of theft. It should not be possible to reuse or replicate the data generated, which should only be valid for a limited period of time.
Having regard for the continuous evolution of the technology adopted by tools with the above characteristics, the following non-exhaustive list provides examples of possession elements that generate data:
• Tokens and software for the generation of OTPs based on encrypted algorithms
• Mobile devices and Mobile apps for the generation of OTPs based on encrypted algorithms
• Mobile telephones for which the code associated with the user (e.g. CallerID) can be checked and which allow client recognition by entering an OTP code
• Display cards that contain certificates or generate OTPs
• Electronic signature certifications, clarifying the cases in which this instrument completely satisfies strong authentication requirements and those in which its use in combination with other instruments is necessary.
It is considered important to allow the ASPSP flexibility in choosing the solution that best meets the requirements established for strong customer authentication, based on appropriate risk analyses and risk mitigation activity.
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?
The behaviour-based characteristics of the PSUs might include behaviours associated with their non-physiological biometric characteristics (e.g. mouse and keyboard use, pressure and speed of signature, keystroke dynamics etc.), as well as other types of behaviour more closely related to the payment method adopted by the PSU (e.g. transaction history, geolocalisation analysis, spending habits etc.).The continuous technological evolution of payment devices and control tools, the availability of new information about the payments and transactions of the PSU, and the ability to relate them to each other rapidly, may make it possible for the ASPSP to consider these categories in the context of inherence" elements.
At the same time, there are currently complexities and issues associated with both the above categories (possible false positives, replication, statistical reliability, variability etc.); accordingly, it would be advisable for the ASPSP to remain responsible for determining if it is appropriate to select one or more of the above behaviour-based elements as part of its strong customer authentication (or as support for the risk analysis and monitoring associated with a transaction), having regard for the risk profile of the transactions, the maturity of the technological solution identified and the reliability of the behavioural data obtained (in terms of minimising false positives and the chances of replication)."
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)?
If held on separate devices, the independent elements might make the user experience more difficult. Accordingly the challenge is to guarantee the independence of these elements, especially when they converge on the same physical support (as in the case of mobile devices), in combination with simplicity and ease of use for the PSU.In this regard, a guiding criterion would be to maintain maximum separation between the payment application and generation of the security elements.
As an example, it might be acceptable to request the joint use of different channels (data via web and sms), different apps (e.g. QR code) and different hardware components (e.g. fingerprint), thus avoiding the vulnerability caused by simple theft of the device and the consequent risk of identity theft. The objective of independence between the elements of strong customer authentication could also be met when the possession" element (such as an OTP generated by a device) is unblocked by a "knowledge" element (PIN or password) or by a biometric element.
In the case of mobile devices, another element to be considered is the technical ability to obtain information in real time about the state of the device (violation, cloned etc.), in order to intervene promptly when necessary, or to block it at the time of access or initiation of a transaction. The fraud management activities carried out by the ASPSP therefore provide fundamental support for the strong customer authentication procedures."
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
The principal challenge of dynamic linking is to collect the transaction data (amount and beneficiary) needed to generate a strong authentication process, while making it simple for the customer.The requirements must also satisfy the diverse needs of end users, consumers and businesses. Businesses authorise individual and bulk payment transactions in the context of a wide variety of internal processes and authorisation levels, depending on the internal allocation of responsibilities.
This introduces various significant new problems of a technical and organisational nature, that must be taken into consideration when drafting the future RTS:
• The algorithms for the calculation of authentication codes must be modified and physical tools that do not support dynamic data must be replaced. Only those with a connector can be retained, if they can be updated. In all cases, those without interconnections will become obsolete. It will also be necessary to modify the interfaces of the applications that use the new algorithms. Additionally, a connection algorithm should also be established for the manufacturers of devices;
• It will be necessary to identify all exemptions in which it is difficult to apply dynamic linking to payments, such as when the amount of the payment is not known;
• It is also necessary to consider the case of bulk payments subject to bulk authorisation (for example, payments in standard ISO20022/XML format), clarifying how to apply the standard when faced with multiple payments involving different beneficiaries and amounts;
• Last but not least, the future requirements might require the sector to make massive investments in order to align the security solutions.
The future RTS should clarify that “dynamic linking” may also be implemented through challenge/response mechanisms.
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
Some examples, not necessarily exhaustive, envisage procedures that essentially comprise:• Strong customer authentication that certifies the number and device of the PSU (possibly also with biometric recognition);
• Mechanism for the exchange of tokens based on the transaction (dynamic) in a manner that is transparent to the PSU once authenticated, perhaps with the simplification of push notifications used to transmit the request for authorisation of the transaction using a different channel with respect to the mobile device. As an additional security measure, the unique identifier for the transaction, encrypted when generating the OTP, could be sent from the server to the client in an encrypted format together with the client's public key. The generation of an electronic signature could be considered for authorisation purposes.
In all cases, it will be important to be able to authorise mechanisms that monitor constantly for violations of the security of the mobile device, so that additional verification options (e.g. challenge response) can be activated in order to authenticate the PSU.
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
The guidelines set out in section 4.2 are considered useful.With reference to point E" in paragraph 42 and to article 97(1)(a), it would be useful to go into greater detail about the potential exemptions to strong authentication of the customer in the case of on-line access to its payment account, when sensitive payment data is not displayed that, if stolen, might give rise to a fraud risk. Accordingly, it would be preferable to add a list, not necessarily complete, of example services solely for reference purposes.
Here as well, it is important for this data to be clearly defined, with respect to what is indicated both in the text of the PSD2 and in the EBA Guidelines on the security of internet payments.
The list of exemptions may change as a result of technological evolution and the assessment of risk."
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
It is suggested that the exemptions to strong customer authentication should include the bulk payments typical of corporate clients and recurrent payments, including direct debits and standing orders.Pre-authorisation by the payer would avoid any need for subsequent repeated specific payment authorisations, which would be difficult to obtain since the payer does not participate in each individual transaction. Accordingly, a requirement to apply strong customer authentication would not only be inconsistent with the nature of the transaction, but also particularly complex to achieve, with repercussions for the use and spread of these payment services.
Point 42.B could also include cases in which transactions involving a specific beneficiary or a specific type of transaction do not necessarily derive solely from a white list prepared by the PSU, but also from a white list that is defined and created dynamically by the ASPSP and reviewed periodically, or produced by certified third parties (system entities or organisations).
The possible exceptions should also expressly mention Wallet Solutions, to the extent that they satisfy the high security requirements which should be envisaged and monitored by the ASPSP concerned.
In this context, strong authentication should relate exclusively to the moment when the PSU registers the payment data needed for the first time, with more user friendly methods for subsequent transactions, freely determined by the ASPSP.
It is desirable here to identify the guidelines for determining the risk of the solutions being discussed, to allow a weighted assessment on the same scale of reference.
Lastly, ABI agrees with the proposed specific exemption for all low-value payments, as envisaged in the PSD2 (see point 42.A).
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?
With reference to the transaction risk analysis, it is suggested that the criteria should include the following:• use of security software supplied to the PSU by the ASPSP;
• information provided by the PSU about payment preferences and behaviour (for example, registering the computer used to make the transaction);
• use of geolocalisation data when analysing the history of transactions.
It might also be useful to define standard behaviour models associated with fraudulent transactions, as well as with the behaviour history of PSUs.
In any case, the future RTS should specify clearly that:
• the ASPSPs are responsible for choosing the individual criterion or the best combination of criteria from those allowed;
• the above criteria are merely examples, since the variables to be considered when performing the transaction risk assessment will change continuously over time as a result of constant technological evolution.
• risk analysis on transactions could involve suspension of payment orders sent by the PSU in order to conduct further and more detailed analysis
10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
General comments on section 4.3 of the DPProtection of personalised security credentials
The arrival of new parties authorised to operate in the payment chain via the Internet objectively increases and complicates the overall set of risks associated with the use of personalised security credentials. The ASPSPs are particularly concerned, when it comes to Internet payments, about cases of phishing and the existence of fraudulent, fake or cloned websites. This is because PSUs might not be able to recognise them and, consequently, prevent unauthorised access to their credentials.
Importantly, the PSD2 requires the new providers (PISP and AISP) to be authorised/registered by the competent national Authorities and subject to their supervision, thus enhancing the security of the entire system. However, in order to increase reliability and the confidence of PSUs in the new channels, while avoiding the introduction of new risks, the future RTS should clearly identify technological solutions that do not require credentials to be shared with third parties, while guaranteeing the effective operations of all parties involved in the payment chain.
Acting between the PSU and the ASPSP, these providers have an inevitable impact on the procedures currently adopted by the ASPSP to analyse risk and manage transaction fraud in real time, increasing their complexity and prompting a need for revision. The EBA should give this aspect close attention when developing the RTS, particularly when determining the security measures to be implemented by third parties, the methods used by the PISP/AISP to inform the ASPSP about the PSU's agreement to use them, and the proper allocation of responsibilities among all parties involved.
The clarification provided in the Discussion Paper is useful. However, it would be also useful to develop the requirements for security credentials specified in the future RTS with reference to the phases of the processes in which the personalised security credentials (PSC) are used, since this breakdown will assist the analysis of risk.
Considering the importance of guaranteeing an adequate level of protection for the PSU's PSCs, it is also believed that the RTS should identify technological solutions that, to avoid introducing new risks, not only do not require the credentials to be shared with third parties, but also inform the ASPSP issuer of the PSCs, in real time, that the PSU has consented to the execution of the transaction via the PISP pursuant to art. 64 of the PSD2.
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
Considering the most common attack and fraud mechanisms, it is clear that the level of protection of the PSCs depends heavily on the level of awareness of the PSUs and on their behaviour.When it comes to internet payments, cases of phishing and the existence of fraudulent, fake or cloned websites are also of particular importance. This is because PSUs might not be able to recognise them and, consequently, prevent unauthorised access to their credentials.
In this context, the appearance of new parties authorised to operate in the payment chain via the Internet objectively increases and complicates the overall set of risks to which PSUs are exposed, if not appropriately educated about the proper way to carry out remote transactions.
Accordingly, in order to avoid the introduction of excessive risks, it is believed that the future RTS must identify solutions that do not require credentials to be shared with third parties.
Consistent with arts. 66 and 67 of the Directive, the RTS should also specify the requirements and procedures by which third parties guarantee the confidentiality and integrity of the PSCs.
Acting between the PSU and the ASPSP, the new providers (PISP and AISP) risk compromising the security and fraud management functions of the ASPSP which are based on the PSU's behaviour and on the origin of the connections; they also risk limiting the capacity to develop the advanced user recognition functions. The EBA should give this aspect close attention when developing the RTS, particularly when determining the security measures to be implemented by third parties, the methods used by the PISP/AISP to inform the ASPSP about the PSU's agreement to use the third party, and the proper allocation of responsibilities among all parties involved.
Lastly, under the new approach, it will be increasingly important to strengthen the education of customers about the protection of their credentials and the aware and careful use of remote channels.
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?
The enrolment processes currently used by ASPSPs to register PSCs vary widely, based on a risk assessment carried out by each ASPSP that results in specific processes considered compatible with their own security requirements.In any case, there are several innovative solutions for the enrolment process, some of which are indicated below:
• Delivery of two or more parts of the PSCs via separate channels, whether traditional or electronic, or - in any case - delivery of at least one part of the key using a separate channel. However, this process may not facilitate immediate and simple use by the PSU;
• Use of electronic certificates issued in accordance with legal requirements as a useful tool for establishing a secure channel of communications with the customer, so that security credentials can be assigned for access to the payment services;
• With regard to biometrics, the analyses continue to make progress, with the proposal of solutions that combine ever increasing ease of use with security.
• Futhermore it is possible to take into consideration the use of credentials already owned by the PSU and issued in secure process certified by national electronic identification systems
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?
Given that the ASPSPs already comply with specific obligations for the secure management of security credentials and that they are subject to supervision by the national competent Authority, it is not considered useful to have other entities to certify or evaluate the technical components or the security of communications, which would modify the model currently in place for the ASPSPs. Accordingly, no alternatives are identified.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?
PSU behaviour is link in the payment chain subject to the greatest risks. In this regard, it is of particular importance to:• Make the PSU more responsible for the aware use of technologies, without altering the security levels of the devices used (PC, smartphone, tablet etc.);
• Increase PSU awareness of the risks associated with downloading attachments and files, with improper behaviour when browsing or using e-mail;
• Dedicate greater attention and care to the protection of device hardware and software, using recommended and appropriate tools for the mitigation of risk and the reduction of vulnerabilities (e.g. antivirus software).
Other parts of the payment chain subject to vulnerabilities include:
• Creation and transmission of credentials to the PSU;
• the process of managing service block/unblock situations and loss of credentials
• Accessing the PSU's payment account;
• Communication of payment instructions between PSU and retailer or between ASPSP and retailer;
• Communications between ASPSP and PISP/AISP.
In particular, on this last point, it is believed that significant risks will arise in future with regard to transactions between these new providers (AISP and PISP) and the ASPSP issuer of the PSCs.
For example, the fraud management techniques for the real-time analysis of transaction risk by the ASPSP in the authentication and authorisation phases will be affected by the insertion of a party between the PSU and the ASPSP. In particular, the ASPSP can no long trust that the information used for its transaction risk analysis refers directly to the PSU. The EBA must take this aspect into strong consideration, since it affects the proper allocation of responsibilities between PISP/AISP and ASPSP.
In this regard, the ASPSP should be put in a position to determine if the authorisation to operate of the AISP/PISP is valid at the time when a service request from a PISP or an AISP is received. This authorisation could in fact be withdrawn by the competent Authority at any time.
It would be extremely complex for the ASPSP to make these checks by linking to the national registers of each and every competent Authority in all member States of the European Economic Area. The central electronic register of Payment Institutions, accessible via the EBA website, established pursuant to art. 15 of the PSD2 could - if structured appropriately - be the most suitable tool to act as an updated, reliable, secure and constantly accessible repository of this information. For this purpose, it is suggested that the RTS should require the EBA register to allow ASPSPs to check identities and the validity of the authorisation in real time. This will be fundamental for the security of communications between the ASPSPs, the PISPs and AISPs, in order to allocate responsibilities properly in the event of unauthorised/fraudulent transactions, since both these elements are key to the entire architecture introduced by the PSD2.
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?
General comments on section 4.4 of the DPRequirements for common and open standards of communication
The EBA highlights that it has not received a mandate to develop or maintain open and common standards of communication or to appoint a central authority for this purpose (paragraph 61).
It is noted, however, that the extreme complexity of defining new operational models and agreed, common and open standards for secure interactions with third parties and PSUs, while avoiding at the same time the emergence of numerous divergent solutions (paragraph 62), will require clear governance in the definition, design and development of a framework of solutions. In this light, it will be appropriate to identify bodies and governance mechanisms whose purpose is to define and manage the development of standards, solutions and operational models consistent with the requirements to be adopted, finding and pulling together solutions that reconcile the divergent needs of stakeholders, market dynamics and the SEPA ecosystem.
It is also noted that the DP does not address the validation of the providers authorised to offer payment and information services by the national competent Authorities.
Before actioning a service request received from a PISP or an AISP, the ASPSP - among other activities - will undoubtedly have to authenticate the third party and check that its authorisation is valid at the time of the request. This authorisation could in fact be withdrawn by the competent Authority at any time.
It would be extremely complex for the ASPSP to make these checks by linking to the national registers of each and every competent Authority in all member States of the European Economic Area. The central electronic register of Payment Institutions, accessible via the EBA website, established pursuant to art. 15 of the PSD2 could - if structured appropriately - be the most suitable tool to act as an updated, reliable, secure and constantly accessible repository of this information. For this purpose, it is suggested that the RTS should require the EBA register to allow ASPSPs to check identities and the validity of the authorisation in real time. This will be fundamental for the security of communications between the ASPSPs, the PISPs and AISPs, in order to allocate responsibilities properly in the event of unauthorised/fraudulent transactions: both these aspects are in fact key to the entire architecture introduced by the PSD2.
In general, the clarifications provided are considered comprehensive and suitable. However, it is not specified how PSUs establish their authenticity with the PISP or the AISP for the execution of transactions or the provision of information services.
With regard to points a) - f), it is worth noting:
a) In relation to what makes a standard common" and "open", that:
• if "open", it must allow specific rules to be followed in the context of a defined form of governance;
• The attribute "common" means that the standard is agreed and interoperable by different parties, even during maintenance.
c) that it is necessary to specify the meaning of "secure manner" and indicate the minimum requirements, such as a 128-bit encryption system with https; encryption keys that make third parties recognisable and identifiable in a transparent and certain manner; guarantee that these third parties do not retain the PSU's data, as required by the PSD2;
d) that access to information on the transactions performed should be included in the range of services to which the requirements apply; the common semantics of information exchanged between the different parties should also be identified.
e) that it is necessary to specify the minimum security controls required for the common and secure open standards of communication, distinguishing between those carried out in real time and those not;
f) that it is necessary to specify the minimum technical requirements applying to the common and secure open standards of communication.
With reference to the consent required by the PSD2 that the PSU must give to the third party when requesting the provision of services, the future RTS should clarify the way in which the PISP/AISP informs the ASPSP about the PSU's consent to use the third party (on a one-off or continuous basis, depending on the service) and about any withdrawal of this consent."
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?
It is appropriate to define the requirements with an adequate level of detail and to identify governance procedures for the centralised management and periodic maintenance of the standards, in order to facilitate updates and innovations.It is stressed that the minimum" requirements, as indicated in paragraph 63, letters d), e) and f), should neither be the cause of excessive and inappropriate investment costs, nor increase the level of risk currently accepted by the ASPSPs that hold the PSU's information."
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?
A set of standards, frameworks and technologies (e.g. TLS, SAML, API, OpenID Connect, Web Services etc.), each for its own area (security, communications etc.), is already available. Although having different levels of dissemination and maturity, these could be considered in response to the broad and complex problems that the RTS will have to tackle.Given the breadth of the range of possibilities, it is considered that assessment of and selection from the options available can only be carried out once the requirements have been defined, having regard for their level of detail. Specifically, with regard to the development of a standard for communications with third parties based on the requirements specified by the EBA, it would be appropriate for the market to govern itself and indicate the participating parties, in order to facilitate a discussion at international level involving all the stakeholders concerned.
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)?
It is noted that the EBA:• Intends to limit itself to the provision of requirements and that the ASPSPs must adopt at least one interoperable interface serving all requirements" (point 63.f);
• Highlights that it has not received a mandate to develop or maintain these open and common standards of communication or to appoint a central authority for this purpose (paragraph 61).
It is noted, however, that the extreme complexity of defining new operational models and agreed, common and open standards for secure interactions among ASPSPs third parties and PSUs, while avoiding at the same time the emergence of numerous divergent solutions (paragraph 62), will require the existence of a proper governance in the definition, design and development of a framework of solutions.
In this light, it will be appropriate to identify bodies and governance mechanisms whose purpose is to define and manage the development of standards, solutions and operational models consistent with the requirements to be adopted, finding and pulling together solutions that reconcile the divergent needs of stakeholders, market dynamics and the SEPA ecosystem."
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.
The e-IDAS Regulation establishes the EU legal framework for electronic identification and trust services in relation to electronic transactions. It does not indicate specific solutions or standards that are operationally applicable to the specific problems of payments associated with the need for strong customer authentication, protection of the PSCs of PSUs or secure communications between PSUs, ASPSPs, PISPs and AISPs.In this regard, while on the one hand the regulation may open up opportunities for the sector, especially in the remote identification of new users, potentially even allowing the provision of cross-border services, on the other, the e-IDAS regulation does not currently appear to provide an effective solution for the specific authentication aspects of the PSU relationship since, in an already contorted and complex context, it would introduce new players and further requirements without any immediately recognisable benefits. It is noted, in fact, that the ASPSPs already give their PSUs personalised security credentials that comply with the regulations, and adopt market standards for the protection of their customers. Nevertheless, application of the e-IDAS Regulation may in future result in the emergence of valid and appropriate solutions that are relevant to payment services, security and relations with the providers of payment and information services.
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.
Since the ASPSPs already issue PSCs to their customers for access to the payment accounts and orders, no additional advantages in terms of confidentiality and security are currently identifiable from use of the qualified trust services provided by other parties.Wishing to explore this aspect further, it would first be necessary to assess the activities of the providers of qualified trust services in the context of payments, considering - within the general framework of responsibilities envisaged in the PSD2 - the allocation of responsibilities in the event of anomalous behaviour involving the suppliers of those services.