Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
At stated by ERPB , while preserving the choice for debtors and creditors on the way they give and accept electronic mandates there is a need for an incentive for creditors to move generally towards solutions with proper debtor authentication and mandate authorization. This is also addressed by ECB where the issuance and amendment of direct debit mandates are supposed to be protected by strong authentication. The 91(1)(b) could be interpreted as not relevant to direct debit mandates, given a direct debit is actually not “initiated” by the payer but by the payee or by the payee’s PSP. Unless this point is address by the transposition workshops, AFEPAME recommends to include the issuance and amendment of direct debit mandates within the 97(1)(c), given these operations imply a risk of fraud or other identity theft abuses that can generate a lose of consumer trust in payment systems.
ERPB/2014/014 : Report on the pan-european use of electronic mandates for SEPA Direct Debit - November 2014
ECB : Recommendations for the security of internet payments – Jan 2013
Data has however an inherent sensibility to manipulation. We think that software technology will bring secure software solution that would make sure that data cannot be intercepted, such as randomly dynamic information that change on both side of a transaction (the PSU and the server) preventing any unexpected usage.
Two examples of technologies (existing today) that would fit the criteria above detailed are:
• Device fingerprinting. In further detail, technical implementation based on the identifiers provided by software elements can be cloned. Technical solutions based on the fingerprint generated by the electronic circuit can be considered Strong. In the aspect the “PUF technology” (Physical Unclonable Functions) is making big steps.
• User inherence detection. In further detail, the collection of data inherent to how a given user makes use of his computer (including, browser cookies, browser identification, add-ons or plugins installed, etc) make possible to characterize the user. Beyond this techniques, that are based on what the user has done, techniques base on what the user is doing at the same instant (i.e. keystroke jitter patterning) have been developed in the last years.
Other “human” inherent elements could be appropriate to strong authentication, notably the ones related to the five senses (sight, hearing, touch, smell and taste). Again the use of such shoudn’t prevents PISP and AISP access to the market.
We also understand that independence is a big challenge, on that aspect we consider and try to use as working hypothesis that two non-independent authentication elements are only one represented by the link between the first and the second authentication method. Guidelines shall be elaborated to clarify what independence means and how this can be objectively monitored. Otherwise we may fail again to implement strong customer authentication.
In addition, it seems that the need of dynamic linking is strongly influenced by legacy technology existing in the card industry (i.e. CAP readers, EMV transactions, etc.) allowing to bind the transaction amount to a code generated via an authenticator or card itself. We have also experimented the unacceptable conversion rates associated to these mechanisms when considering online scenarios.
Furthermore, scenarios in which the dynamic linking does not make real sense appear more and more every day. Those are typically associated to the new generations lifestyle were perpetual purchase business models are being changes by subscription based (i.e. video on demand, music, pay per view or pay per usage, etc.). Recurring payments where the payment details (card, bank based or other) are stored by the PSP would inherently lack of this dynamic linking, unless we are willing to go against the payment frictionless need that the market has raised.
We also consider that dynamic linking should exist but it shall be balanced against usability and need, i.e. define (user selectable) thresholds under which dynamic linking is not needed, narrow it to specific verticals or type of transactions, etc.
In a general word, we understand the need and we consider its use valuable. Technology independence is a must (it cannot be that we need a payment card or analogue virtual to achieve a transaction based on a Bank Account).
The development of multiple data point, machine learning and real-time risk assessment reduces risks and offer real alternative to strong authentication.
AFEPAME notes that EBA clarifications are concerning PSU authentication. The PSD text mentions several time the notion of “Strong Customer Authentication”. It should be noted that in certain cases, the user is not the “customer” of the PSP that acquires or initiates a payment transaction. The notion of “customer” is too close to the definition of a business relation that calls AML checks. AFEPAME would like EBA to refer in the RTS to a “Strong User Authentication” rather than a “Strong Customer Authentication”.
Additionally AFEPAME is very concerned by the fact the RTS will come into force almost 9 months after transposition of the PDS2, which pushes back the launch of the PIS and AIS services for at least the same 9 months, and may be much more. This issue is not addresses in EBA’s clarifications.
https://fidoalliance.org/membership/members/
b- -
c- Preferably this way shouldn’t create any barrier to AIS and PIS to set-up and use the communication, such as abusive qualification procedures or restricted accesses. The communication should create a level playing field between all players, notably shoudn’t give a advantage to ASPSP in setting up their own PIS or AIS compared to a Payment Institution willing to do the same.
d- ASPSP rejection of PIS instructions should be part of the minimum functionalities. The PIS or AIS should be able to understand why the ASPSP wouldn’t deliver the service, notably in case of reachability denial or technical failure.
It should be envisaged that the access on the availability of funds could not be anymore restricted to payment instruments that are linked to the issuing of a card, given this current restriction is difficult to understand in the context of making the payment market more competitive.
e- -
f- AFEPAME stresses the point that under no circumstances the PSU’s PSC delivered by the ASPSP for AIS or PIS should differ from the regular PSC to access the online banking. AFEPAME is concerned by the EBA’s 57(v) statement that says the PSC are « usually those issued » by the ASPSP. It would be very counterproductive of having two sets of PSC (one for online access and one for PIS /AIS), and could be a of source unfair access to the market.
• ISO20022 covering the data exchanged between the PIS, AIS and the ASPSP. This aspect is not yet part of the ISO but we consider it shall be added to the latter by a working group (eventually fostered or supported by the EBA)
• FIDO U2F and UAF as globally agreed authentication initiative between most of the stakeholders active in this market.
We consider that failing to reference existing, open and appropriate standards may lead to an unclear playing field with a single consequence: advantage for the established parties and lack of effective competition.
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.
Yes, the issuance and amendment of direct debit electronic mandates.At stated by ERPB , while preserving the choice for debtors and creditors on the way they give and accept electronic mandates there is a need for an incentive for creditors to move generally towards solutions with proper debtor authentication and mandate authorization. This is also addressed by ECB where the issuance and amendment of direct debit mandates are supposed to be protected by strong authentication. The 91(1)(b) could be interpreted as not relevant to direct debit mandates, given a direct debit is actually not “initiated” by the payer but by the payee or by the payee’s PSP. Unless this point is address by the transposition workshops, AFEPAME recommends to include the issuance and amendment of direct debit mandates within the 97(1)(c), given these operations imply a risk of fraud or other identity theft abuses that can generate a lose of consumer trust in payment systems.
ERPB/2014/014 : Report on the pan-european use of electronic mandates for SEPA Direct Debit - November 2014
ECB : Recommendations for the security of internet payments – Jan 2013
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?
AFEPAME strongly believes that data will become more and more the relevant appropriate possession element. The physical forms of possession elements have demonstrated with time their limitation with omniscient customer experience (continuous customer experience across different channels), and time to time unfair practices that are contradictory with the DSP objective to bring consumers with more choice (a physical form such as a EMV chip card issued by the ASPSP, will restrain consumer freedom to change, given a card is often associated with a minimum contract length).Data has however an inherent sensibility to manipulation. We think that software technology will bring secure software solution that would make sure that data cannot be intercepted, such as randomly dynamic information that change on both side of a transaction (the PSU and the server) preventing any unexpected usage.
Two examples of technologies (existing today) that would fit the criteria above detailed are:
• Device fingerprinting. In further detail, technical implementation based on the identifiers provided by software elements can be cloned. Technical solutions based on the fingerprint generated by the electronic circuit can be considered Strong. In the aspect the “PUF technology” (Physical Unclonable Functions) is making big steps.
• User inherence detection. In further detail, the collection of data inherent to how a given user makes use of his computer (including, browser cookies, browser identification, add-ons or plugins installed, etc) make possible to characterize the user. Beyond this techniques, that are based on what the user has done, techniques base on what the user is doing at the same instant (i.e. keystroke jitter patterning) have been developed in the last years.
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?
Yes, behavior-based characteristics are appropriate to be used. However the usage of this element shouldn’t exclude the intermediation of authentication by a PISP or AISP. The usage of a PISP or AISP, would probably alter the PSU behavior, and this should not be a cause of authentication reject.Other “human” inherent elements could be appropriate to strong authentication, notably the ones related to the five senses (sight, hearing, touch, smell and taste). Again the use of such shoudn’t prevents PISP and AISP access to the market.
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 is to avoid that the corruption of one element propagates itself to the corruption of the second element. AFEPAME is less worried by mobile theft, given such a theft is often detected by the owner very quickly, and remote locking of the device is now very familiar. AFEPAME is more worried by the fact phones are becoming small computers, and then more and more sensitive to software corruption.We also understand that independence is a big challenge, on that aspect we consider and try to use as working hypothesis that two non-independent authentication elements are only one represented by the link between the first and the second authentication method. Guidelines shall be elaborated to clarify what independence means and how this can be objectively monitored. Otherwise we may fail again to implement strong customer authentication.
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
We feel the notion of dynamic linking comes from disconnect between the authentication and the transaction validation. Whatever the authentication, a corruption can make the user validate another transaction than expected. It would rather be pointed out that what requires a strong authentication is not the user but the transaction itself (or the validation of a series of transactions).In addition, it seems that the need of dynamic linking is strongly influenced by legacy technology existing in the card industry (i.e. CAP readers, EMV transactions, etc.) allowing to bind the transaction amount to a code generated via an authenticator or card itself. We have also experimented the unacceptable conversion rates associated to these mechanisms when considering online scenarios.
Furthermore, scenarios in which the dynamic linking does not make real sense appear more and more every day. Those are typically associated to the new generations lifestyle were perpetual purchase business models are being changes by subscription based (i.e. video on demand, music, pay per view or pay per usage, etc.). Recurring payments where the payment details (card, bank based or other) are stored by the PSP would inherently lack of this dynamic linking, unless we are willing to go against the payment frictionless need that the market has raised.
We also consider that dynamic linking should exist but it shall be balanced against usability and need, i.e. define (user selectable) thresholds under which dynamic linking is not needed, narrow it to specific verticals or type of transactions, etc.
In a general word, we understand the need and we consider its use valuable. Technology independence is a must (it cannot be that we need a payment card or analogue virtual to achieve a transaction based on a Bank Account).
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
None that provides currently a satisfactory universality, user experience and independence from the card infrastructure (physical payment cards, mobile payment cards or cloud emulated payment cards). But technology moves fast.7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
Yes absolutely.The development of multiple data point, machine learning and real-time risk assessment reduces risks and offer real alternative to strong authentication.
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
We consider that exceptions shall be granted to avoid interdependence of bank payments with card payments. That is, ensure that the need of strong authentication or dynamic linking of transactions for bank based transactions (i.e. using IBAN and not PAN details) can be fulfilled with other means than the ones provided by card instruments (or the virtualization of the latter, i.e. SE or HCE based card implementations).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?
NA10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
YesAFEPAME notes that EBA clarifications are concerning PSU authentication. The PSD text mentions several time the notion of “Strong Customer Authentication”. It should be noted that in certain cases, the user is not the “customer” of the PSP that acquires or initiates a payment transaction. The notion of “customer” is too close to the definition of a business relation that calls AML checks. AFEPAME would like EBA to refer in the RTS to a “Strong User Authentication” rather than a “Strong Customer Authentication”.
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
NA12. 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?
At this stage we would like to refer to the FIDO Alliance (https://fidoalliance.org/specifications/overview/) providing standardized specification to implement strong authentication. In all cases it is based on a strong local authentication (i.e. biometric, password based or other) that relays the success or not of it to the Merchant requiring authentication. The local strong authentication provides access to a private key that is used for that purpose.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?
The current certification and security evaluation market is in the hands of few accredited laboratories and independent parties. While understanding the need of independent parties to assess the capabilities of the ecosystem, we would like to raise the interested for a self-regulated industry body that reduces the amount of eventual barriers that may appear to enter into this market.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 biggest risk is the User to deactivate protections if the user experience is too complex.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?
Yes, nevertheless we consider surprising the lack of emphasis put on standardization of those RTS. The SEPA regulation introduced (by force) the usage of the ISO20022 in the FI to Customer space, we would expect that the RTS continue with this tendency (even though at the current stage details about what would be added and how it would be added to the ISO are premature).Additionally AFEPAME is very concerned by the fact the RTS will come into force almost 9 months after transposition of the PDS2, which pushes back the launch of the PIS and AIS services for at least the same 9 months, and may be much more. This issue is not addresses in EBA’s clarifications.
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?
a- We have ISO20022 (for the actual data exchange) and we would suggest FIDO for the authentication (given the amount of players already implementing it).https://fidoalliance.org/membership/members/
b- -
c- Preferably this way shouldn’t create any barrier to AIS and PIS to set-up and use the communication, such as abusive qualification procedures or restricted accesses. The communication should create a level playing field between all players, notably shoudn’t give a advantage to ASPSP in setting up their own PIS or AIS compared to a Payment Institution willing to do the same.
d- ASPSP rejection of PIS instructions should be part of the minimum functionalities. The PIS or AIS should be able to understand why the ASPSP wouldn’t deliver the service, notably in case of reachability denial or technical failure.
It should be envisaged that the access on the availability of funds could not be anymore restricted to payment instruments that are linked to the issuing of a card, given this current restriction is difficult to understand in the context of making the payment market more competitive.
e- -
f- AFEPAME stresses the point that under no circumstances the PSU’s PSC delivered by the ASPSP for AIS or PIS should differ from the regular PSC to access the online banking. AFEPAME is concerned by the EBA’s 57(v) statement that says the PSC are « usually those issued » by the ASPSP. It would be very counterproductive of having two sets of PSC (one for online access and one for PIS /AIS), and could be a of source unfair access to the market.
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?
AFEPAME suggests to make explicit reference to framework standards widely spread in the Financial Industry. Specific references that AFEPAME suggests are:• ISO20022 covering the data exchanged between the PIS, AIS and the ASPSP. This aspect is not yet part of the ISO but we consider it shall be added to the latter by a working group (eventually fostered or supported by the EBA)
• FIDO U2F and UAF as globally agreed authentication initiative between most of the stakeholders active in this market.
We consider that failing to reference existing, open and appropriate standards may lead to an unclear playing field with a single consequence: advantage for the established parties and lack of effective competition.