Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
Whilst these transactions may trigger fraud, so may other actions initiated by the PSU to man-age his account or the payment instruments attached to it.
It should be highlighted that there are currently solutions that fulfill the independence re-quirement of the authentication elements in mobile devices (see question 6 below).
The use of exemptions should however be at the discretion of the ASPSP, who should always retain the capacity to revert to strong customer authentication (e.g. should a PSU’s behavior become “erratic”).
The clarifications suggested are useful. However the uncertainty created by the conflict be-tween Recital 69 and Art. 66 (3) b and 67 (2) b with respect to keeping the personalized secu-rity credentials safe must be resolved in the RTS. Any handing over of personalized security credentials to a third party including AIS/PIS providers must translate into a shift in liability away from the ASPSP – which has system stability implications. Additionally this situation would increase the risk referred to in para. 51.E, as third parties would have access to them.
That personalized security credentials may not be handed over to third parties actually derives from the definition of sensitive payment data (“… data, including personalized security creden-tials which can be used to carry out fraud….”) and the rules applying to payment initiation ser-vices (Art. 66.3(e): “The payment initiation service provider shall: …not store sensitive pay-ment data of the payment service user”) and the account information service provider (Art. 67.2(e): “The account information service provider shall: …not request sensitive payment data linked to the payment accounts”).
- Sent to the PSU,
- Held by the PSU,
- Used for identification.
Such risks must be mitigated by continued PSU education and information with respect to both “health practices” and usage of the proper software. Any ambiguity regarding e.g. the pro-tection of personalized security credentials can only have adverse implications with respect to the intended consumer protection objective.
As quoted by EBA, PSD2 Recital 33 (stating that “This Directive should aim to ensure continuity in the market, enabling existing and new service providers, regardless of the business model applied by them, to offer their services with a clear and harmonized regulatory framework….”) is of importance to this sec-tion of the discussion. Indeed, whilst acknowledging the entry of registered and regulated new service providers, incumbents should be allowed to continue and provide well-functioning ser-vices to payment service users without disruption to the latter and without having to revisit ex-isting business models.
a) “Common and open” standards: a common definition would be welcome – as there are cur-rently a range of definitions and interpretations available. Such definition should include a view on the required governance to evolve the standards concerned.
b) Identification of AIS and PIS providers towards ASPSPs for access: the clarifications pro-vided notably under paragraph 57 of the discussion paper are comprehensive and suitable. We recommend however that the considerations expressed in Recitals 28 and 29 be re-called when EBA drafts the RTS. The RTS should also clarify how AIS and PIS providers identify themselves unambiguously towards the payment service user, including providing evidence that they are duly registered and regulated.
c) Secure communication between ASPSPs and PSUs, and AIS/PÏS providers: a PKI archi-tecture should be used.
d) Minimum functionalities requirements for the future common and secure open standards of communication: the services that can be requested by the AIS/PIS providers are well de-fined notably in Recitals 28 and 29 – which should form the basis for that section of the RTS. The related standards should not allow for any interpretation so that processing by ASPSPs can be fully automated. The PSU’s consent must be unambiguously linked to a given payment account and a single transaction (either payment initiation, or information request), requested and provided solely through the common and open interface provided by the ASPSP.
e) Minimum security controls: there should be 3 layers of security controls:
- The PSU should be able to verify that he gives consent to a registered and regulated AIS/PIS provider;
- The AIS/PIS provider should be able to verify that he deals with a genuine PSU.
- The ASPSP should be able to verify automatically that any request originates from a registered and regulated AIS/PIS provider, on behalf (i.e. with the express consent of) a genuine PSU. The ASPSP should be able to reject any request that i.a. does not meet this test.
The PSU’s consent should be provided as stated under d) above, which enables the said PSU to withdraw consent independently from the AIS/PIS provider.
f) Minimum technical requirements for the common and secure open standards of communi-cation: taking into account remarks made notably under 11, 14, and 15 d) above, it should be noted that a wide range of market solutions already exist to supporting such secure communication. For due reasons interoperability is required. It can however not be ex-pected that all existing solutions become interoperable with each other. For practicality yet mostly for cost efficiency purposes EBA should the requirements for a small (e.g. 3) set of default secure communication standards, for interoperability purposes. Such approach would support channel independence and allow for the gradual introduction of innova-tions.
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.
The purposes for which payment initiation and account information service providers may ac-cess accounts with the explicit consent of the account holder (payment service user) are well defined, notably in Recitals 28 and 29. The payment initiation service provider may access such account to provide comfort to a payee that the payment has been initiated in order for the latter to release goods or deliver the service without undue delay, and the account information service provider may do so to provide the payment service user with an overall view of its fi-nancial situation.Whilst these transactions may trigger fraud, so may other actions initiated by the PSU to man-age his account or the payment instruments attached to it.
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?
Possession elements to be used include connected devices registered with the ASPSP (e.g. mo-bile devices, see questions 4 and 6 below) as well as dynamic and static tokens. Possession el-ements may come in the form of data, provided there is a link with a physical device.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 use of behavior-based characteristics should certainly be allowed in the context of strong customer authentication (in particular whenever other, simpler elements are also used). Such use should however not be mandated.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)?
The main challenge currently consists in enforcing on the PSU the independence of authentica-tion elements to be exchanged over distinct channels. A precondition for mobile devices is that these are registered with the ASPSP and thus linked to a given PSU.It should be highlighted that there are currently solutions that fulfill the independence re-quirement of the authentication elements in mobile devices (see question 6 below).
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
As such dynamic linking allows to fulfill the objective of strong customer authentication, pro-vided that the communication of the code generated identifies the transaction to the PSU (e.g. kind, amount, payee, etc…) and can only be accessed by using other authentication elements (knowledge, e.g. PIN, or inherence, e.g. biometrics). Furthermore the link should be traceable in case of dispute.6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
The combination of dynamic linking with access by another authentication element meets both objectives. To illustrate: a PSU would only be allowed to do a transaction by introducing a PIN (something only he knows) or using his fingerprint (something he is) on a mobile device, receiving on hi previously communicated phone number (the same device as the former, or a different one) a dynamic code that identifies the transaction, amount, payee, etc. here, chang-ing the previously registered phone number should require strong customer authentication. Al-ternatively the dynamic code could be generated through an app with the same requirements, to which other security elements could be added (e.g. root control, ssl pinning, …). There cur-rently exist mobile devices that allow to use fingerprinting, keeping the information in their own key store/key chain.7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
Both proximity low value payments and transfers between two accounts of the same PSU held at the same ASPSP should be exempt from strong customer authentication. Recurrent pay-ments could be exempted too, provided the first of such transaction be subject to strong cus-tomer authentication.The use of exemptions should however be at the discretion of the ASPSP, who should always retain the capacity to revert to strong customer authentication (e.g. should a PSU’s behavior become “erratic”).
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
EBA should acknowledge that the ultimate responsibility for customer risk evaluation resides with the ASPSP.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?
For e-commerce, additional criteria could be based on the risk assessment of the payee (i.e. “trusted” payees would be rated as low risk, based on experience). The main card schemes are already considering such an approach.10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
Opening consideration: throughout the topics covered in this section, the RTS should maintain technological neutrality in order to on one side allow for co-existence of working solutions, on the other enable innovations to be introduced.The clarifications suggested are useful. However the uncertainty created by the conflict be-tween Recital 69 and Art. 66 (3) b and 67 (2) b with respect to keeping the personalized secu-rity credentials safe must be resolved in the RTS. Any handing over of personalized security credentials to a third party including AIS/PIS providers must translate into a shift in liability away from the ASPSP – which has system stability implications. Additionally this situation would increase the risk referred to in para. 51.E, as third parties would have access to them.
That personalized security credentials may not be handed over to third parties actually derives from the definition of sensitive payment data (“… data, including personalized security creden-tials which can be used to carry out fraud….”) and the rules applying to payment initiation ser-vices (Art. 66.3(e): “The payment initiation service provider shall: …not store sensitive pay-ment data of the payment service user”) and the account information service provider (Art. 67.2(e): “The account information service provider shall: …not request sensitive payment data linked to the payment accounts”).
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
Risks occur whilst personalized security credentials are:- Sent to the PSU,
- Held by the PSU,
- Used for identification.
Such risks must be mitigated by continued PSU education and information with respect to both “health practices” and usage of the proper software. Any ambiguity regarding e.g. the pro-tection of personalized security credentials can only have adverse implications with respect to the intended consumer protection objective.
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?
Open standards exist in the market. An attractive solution allows for access tokens to be is-sued by ASPSPs to be used for authorization by a third party app.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?
Going forward – in particular considering the variety of access channels – it will be increasingly important for tamper resistance to use solely disconnected hardware devices or smart (soft-ware-based) tokens, provided the latter are certified and that this certification can be validated remotely (this would not be necessary when credentials are used solely in an ASPSP’s system, with hosting/transmitting through the latter’s system/apps)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?
The weakest point in the chain are the PSU – both from an environment and a practices per-spective – and its relation with a AIS/PIS provider (uncertainty of AIS/PIS provider identity, risk of compromise of PSU – AIS/PIS provider relationship,…). The “banalization” of third party services introduced by PSD2 in this respect creates the prospect of “snowball” effects in terms of risk and damage. At present the main risk would be related to the capture of PSU cre-dentials via phishing or social engineering: introducing third party services in the credential chain increases that risk.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?
Opening consideration:As quoted by EBA, PSD2 Recital 33 (stating that “This Directive should aim to ensure continuity in the market, enabling existing and new service providers, regardless of the business model applied by them, to offer their services with a clear and harmonized regulatory framework….”) is of importance to this sec-tion of the discussion. Indeed, whilst acknowledging the entry of registered and regulated new service providers, incumbents should be allowed to continue and provide well-functioning ser-vices to payment service users without disruption to the latter and without having to revisit ex-isting business models.
a) “Common and open” standards: a common definition would be welcome – as there are cur-rently a range of definitions and interpretations available. Such definition should include a view on the required governance to evolve the standards concerned.
b) Identification of AIS and PIS providers towards ASPSPs for access: the clarifications pro-vided notably under paragraph 57 of the discussion paper are comprehensive and suitable. We recommend however that the considerations expressed in Recitals 28 and 29 be re-called when EBA drafts the RTS. The RTS should also clarify how AIS and PIS providers identify themselves unambiguously towards the payment service user, including providing evidence that they are duly registered and regulated.
c) Secure communication between ASPSPs and PSUs, and AIS/PÏS providers: a PKI archi-tecture should be used.
d) Minimum functionalities requirements for the future common and secure open standards of communication: the services that can be requested by the AIS/PIS providers are well de-fined notably in Recitals 28 and 29 – which should form the basis for that section of the RTS. The related standards should not allow for any interpretation so that processing by ASPSPs can be fully automated. The PSU’s consent must be unambiguously linked to a given payment account and a single transaction (either payment initiation, or information request), requested and provided solely through the common and open interface provided by the ASPSP.
e) Minimum security controls: there should be 3 layers of security controls:
- The PSU should be able to verify that he gives consent to a registered and regulated AIS/PIS provider;
- The AIS/PIS provider should be able to verify that he deals with a genuine PSU.
- The ASPSP should be able to verify automatically that any request originates from a registered and regulated AIS/PIS provider, on behalf (i.e. with the express consent of) a genuine PSU. The ASPSP should be able to reject any request that i.a. does not meet this test.
The PSU’s consent should be provided as stated under d) above, which enables the said PSU to withdraw consent independently from the AIS/PIS provider.
f) Minimum technical requirements for the common and secure open standards of communi-cation: taking into account remarks made notably under 11, 14, and 15 d) above, it should be noted that a wide range of market solutions already exist to supporting such secure communication. For due reasons interoperability is required. It can however not be ex-pected that all existing solutions become interoperable with each other. For practicality yet mostly for cost efficiency purposes EBA should the requirements for a small (e.g. 3) set of default secure communication standards, for interoperability purposes. Such approach would support channel independence and allow for the gradual introduction of innova-tions.