Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
In chapter 1, several solutions for strong authentication are identified with no indication if there will be a distinction between these different solutions in particular in terms of level of assurance.
Worldline suggests that the final document could take into account the level of assurance that is already addressed by the Regulation (EU) N°910/2014 on electronic identification and trust services for electronic transactions in the internal market (eIDAS Regulation) and the 3 identified levels.
The distinction could be very helpful for the market to select solutions, it could be also very helpful in order to define a relationship between the level of risk for a transaction and the level of assurance required to mitigate that risk through the appropriate authentication method.
In article 1.3.e, there is a list of input information in order to prevent fraudulent transactions. It seems that theses information may be provided by different actors. We suggest clarifying the responsibilities for each item in this list.
In article 2-3, it requires in case of card-based payment transaction where the exact amount is not known at the start of the transaction, e.g. petrol unattended terminal, that the authentication code is linked to the maximum amount that the payer has given consent. It should be added that it is not mandatory to display this maximum amount at each transaction initiated by the payer if this amount is known by the payer, e.g. as a result of a clear communication by the card issuer to the card holder, the payer. In other words, the dynamic linking is not always the most adapted answer.
In Article 6.3, we have seen that for multipurpose devices (smartphone) authentication, it will be required to use a separated trusted execution environment.
This Trusted Execution Environment (TEE) technology is not mature enough, and is mainly driven by smartphone manufacturers (mostly non-European), we can see that some manufacturers do not want to open this technology to third parties and that it will lead to monopolistic position.
In article 7, it is mentioned that authentication solution must be regularly audited by internal or external auditors. We are wondering what could be the audit framework in that case.
Worldline considers that a common audit matrix or the reference to existing certification processes (ISO, Common criteria, ETSI-Standards, or compatible national framework….) should be relevant in order to produce a relevant report.
Report confidentiality: as the audit report may contain confidential data, Worldline consider that
• Either a summarized report should be made also available publicly
• Or the complete report must not be published without the explicit authorization of the authentication solution providers.
General considerations
When the transaction does not process a Strong Customer authentication, is there a need to explain it to the customer, and a need for a minimum set of rules to identify the payer?
• prevents from fraudulent disputes by archiving the proof of authentication with the related sensitive transactions,
• reinforces the confidence of the customer during the authentication process, and
• improves the non-replay ability of an authentication
We also agree that segregated communication channel (out of band) is a good method in order to improve the efficiency of the dynamic linking
We consider that the definition of segregated channels could be clarified in order to prevent from a misinterpretation; actually there are potentially several meanings:
• Separated channels on two different devices
• Separated communication channels even on the same device but with separated session, with for example separated SSL tunnels
Our understanding is that two communication channels even in the same mobile application in the same device could be possible if it leads to two segregated secure channels
We are wondering how should be considered the dynamic linking when there will be several payments, with a mandate for example, to only one payee and where the maximum amount is not known at the time of the transaction?
Physiological biometrics, fingerprint recognition, face recognition and eyes recognition do not provide the same level of assurance, especially if we consider the possible fake authentications.
So it seems interesting to qualify the different biometrics methods related to a level of reliability and then a level of assurance.
We suggest considering a minimum level of security for biometrics authentication (Equal Error rate for example).
This could be adapted regularly in the future with new possible biometrics authentication or technological improvement.
Indeed, market of strong authentication evolves towards Risk-Based Authentication and Continuous Authentication concepts in order to find the right balance between security and user experience.
Some new online payment protocols (for example 3D Secure 2.0) also go in that direction, by enabling “frictionless flow” for low risk transactions.
equensWorldline’s position is to let issuers decide the best authentication strategy for each transaction, based on a risk scoring engine. And exempt transactions that are scored as low risk.
Article 8-1-b-ii and 8-2-d-ii: cumulative amount of previous contactless transactions: is there a limitation in time or no limitation and cumulative till realization of a transaction with strong authentication with same payment instrument?
It is very unclear to see how the cumulative amount is managed because there is no indication of duration for that cumulative amount (month?)
That shows that the idea of velocity of similar transaction is taken into account but with very light rules.
It should be possible to add more rules around that list of exemptions in order to propose a real risk based authentication features.
That could improve the user experience for the same level of security.
We suggest that RTS mentions the minimum security requirements applying in context of the exemption, if any (i.e. by if no strong customer authentication, what else is required? E.g. for Low Value Payment, we still need some device authentication (something you have) without customer authentication (something you know)
Article 12 (a): Worldline would like to point out that in certain situations, user identification and or authentication during the initial services activation can be delegated to a third party. In this particular case, the PSP should be allowed to accept an authentication proof that user’s identity has been performed by a third party. The associated personalized credentials, devices & software will be executed in a PSP secured environment as described in this chapter, but based on user identity verified by a third party.
Article 16: Worldline has the same remarks as in article 7 (commented in question 1).
General considerations:
equensWorldline considers mandatory to clarify terms as “sensitive data” and “personalized security credentials”. This will also help to define rules of liability and chargebacks.
Sensitive data defined in this list should also comply with data protection requirements existing in place in each country.
The RTS mentions mainly the use of standard for the technical interface with the ASPSP’s.
We see the need for standardization at two levels:
• The functionality of the services
• The technical interface
Standardization of the functionality of the services
The functional scope of the new services (Account Information Service AIS, Payment Initiation Service PIS, check available amount) should be standardized - in order to ensure a coherent development and deployment of new services by all actors for the benefit of the actors (payers, payees) - rather than having access to same information as on current bank remote infrastructure (as stated in article 22).
The functional description of the exchange of information between PSP and Account Service Payment Service Provider (ASPSP) aims to ensure the integrity and atomicity of the transaction. Several aspects should be described and standardized per function (AIS, PIS, ...)
• Content of the service, e.g. for PIS, execution of an SEPA Credit Transfer, real-time notification of execution and guarantee of execution
• Nominal behaviour: exchange of messages; mandatory content of messages, e.g. elements for unambiguous identification of the transaction; optional content; integration of the payer authentication session within the transactional flow, etc.
• Exception behaviour: timeout handling, e.g. technical cancellation; process in case of problem, e.g. non execution of SCT, payee account not credited
As an example, the content of the service ‘availability of funds’, article 22-1c should clearly mention that the answer of this request (Yes or No) doesn’t imply any kind of reservation of the amount or any kind of payment guarantee.
Standardization of the technical interface
Article 19.1 imposes ASPSP’s to offer at least one communication interface for the new services (AIS, PIS, check available amount). Article 19, 3, imposes use of ISO20022 elements, components or approved message definitions, if available.
Having a standard technical solution would bring as benefit
• A standardization of the functionality, even if some flexibility will remain
• An assurance for a full reachability of all banks and thus an improved level of acceptance
• A reduction of the costs of the new services by a reduction of the technical barriers (i.e. no need for a PSP to support several different technical solutions for a same service).
Article 19-5: mentions that ASPSP may change its technical specification with a 3 months notification period. This delay appears to be very short. A distinction should be made between urgent changes and normal maintenance for which a notification period of 6 months is a minimum. In a context where the technical interface is defined by a standardization body as suggested above, it would be the responsibility of this body to manage the evolution and maintenance of the specifications, including a maintenance lifecycle (e.g. one new release per year, information on scope 9 months before publication, publication of specifications 6 months before release).
Consumer authentication according to methods provided by the ASPSP
RTS mentions that the consumer must use the authentication method provided by ASPSP and that ASPS may on a bilateral basis agree for an authentication made by the PSP.
Our opinion is that non-bank PSP (AISP, PISP, card issuer) should also be allowed to provide their own authentication solution to their consumers (in line with requirements related to strong customer authentication) and ASPSP’s should be obliged to accept such method provided this method is approved by a recognized independent body as meeting the SCA requirements. The rationale is that using the authentication method provided by the ASPSP is probably acceptable in the remote/E-Com environment but is not realistic in the proximity environment (e.g. use of a ‘loyalty’ token/card provided by a merchant for its own new payment method at the cash register environment cannot be combined with a dynamic authentication method provided by an ASPSP which requires a dedicated user interaction and for instance the use of the bank card combined with a specific hardware module to open the session and to sign the transaction).
We consider that the case by case negotiation between a PSP (AISP, PISP, card issuer) and various ASPS’s for acceptance on a bilateral basis of their PSP authentication solution is not realistic and will bring a distortion of competition between PSP’s (banks probably more open to negotiate with more important/worldwide actors and not with small actors). Article 19-1 should be adapted accordingly.
• The first is about the secure identification between Payment Service User and PSP.
• The second is about the secure identification between PSPs.
The first issue is in our view out of scope of the present RTS, and may indeed be different according to the technologies used, including devices. For example, the current EMV protocol does not include identification of the merchant by the card.
The second issue is clearly within the scope of this RTS: we believe that digital certificates issued by a qualified trust service provider could indeed be used to identify and secure communication between PSPs and we support this idea.
Regarding the use of digital certificates issued under the eIDAS policy, many questions still need to be answered:
Today, eIDAS rules are dedicated to public bodies. They will need to be adapted to payment activities in a private sector. When will these rules be established?
Who will manage the issuance of certificates? Will it be the national regulatory bodies delivering the licenses? Is so, under which eIDAS policy, under what delay, etc? If so, will there also be a central pan-European register to manage the certificates?
As a conclusion, EBA should: first clarify the usage of digital certificates, making it clear that they will be used to mutually identify PSPs and not PSUs and PSPs, and second provide more information on the implementation of eIDAS compliant certificates in the context of PSD2.
But EBA should consider that ASPSPs support a higher frequency in case the PSU explicitly requests more than 2 times a day access to the account via an AIS provider. At least EBA should ensure the continuation of the same service level for the PSU as provided by ASPSP via online banking portals today.
This includes no extra charge and no limitation for multiple accesses per day.
Clarification about the time zone to define the beginning/end of day would be necessary.
In latter case the AIS should receive a mandate from the PSU for multiple accesses to avoid application for each single request.
Question 1: Do you agree with the EBA’s reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS?
The concept of strong customer authentication is welcomed as it will provide trust to Account holders in the new services.In chapter 1, several solutions for strong authentication are identified with no indication if there will be a distinction between these different solutions in particular in terms of level of assurance.
Worldline suggests that the final document could take into account the level of assurance that is already addressed by the Regulation (EU) N°910/2014 on electronic identification and trust services for electronic transactions in the internal market (eIDAS Regulation) and the 3 identified levels.
The distinction could be very helpful for the market to select solutions, it could be also very helpful in order to define a relationship between the level of risk for a transaction and the level of assurance required to mitigate that risk through the appropriate authentication method.
In article 1.3.e, there is a list of input information in order to prevent fraudulent transactions. It seems that theses information may be provided by different actors. We suggest clarifying the responsibilities for each item in this list.
In article 2-3, it requires in case of card-based payment transaction where the exact amount is not known at the start of the transaction, e.g. petrol unattended terminal, that the authentication code is linked to the maximum amount that the payer has given consent. It should be added that it is not mandatory to display this maximum amount at each transaction initiated by the payer if this amount is known by the payer, e.g. as a result of a clear communication by the card issuer to the card holder, the payer. In other words, the dynamic linking is not always the most adapted answer.
In Article 6.3, we have seen that for multipurpose devices (smartphone) authentication, it will be required to use a separated trusted execution environment.
This Trusted Execution Environment (TEE) technology is not mature enough, and is mainly driven by smartphone manufacturers (mostly non-European), we can see that some manufacturers do not want to open this technology to third parties and that it will lead to monopolistic position.
In article 7, it is mentioned that authentication solution must be regularly audited by internal or external auditors. We are wondering what could be the audit framework in that case.
Worldline considers that a common audit matrix or the reference to existing certification processes (ISO, Common criteria, ETSI-Standards, or compatible national framework….) should be relevant in order to produce a relevant report.
Report confidentiality: as the audit report may contain confidential data, Worldline consider that
• Either a summarized report should be made also available publicly
• Or the complete report must not be published without the explicit authorization of the authentication solution providers.
General considerations
When the transaction does not process a Strong Customer authentication, is there a need to explain it to the customer, and a need for a minimum set of rules to identify the payer?
Question 2: In particular, in relation to the “dynamic linking” procedure, do you agree with the EBA’s reasoning that the requirements should remain neutral as to when the “dynamic linking” should take place, under the conditions that the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed is independent or segregated from the channel, mobile application or device used for initiating the payment, as foreseen in Article 2.2 of the draft RTS.
Worldline considers that “dynamic linking” procedure is a good feature for authentication platform in order to reinforce the whole authentication process, in particular because it:• prevents from fraudulent disputes by archiving the proof of authentication with the related sensitive transactions,
• reinforces the confidence of the customer during the authentication process, and
• improves the non-replay ability of an authentication
We also agree that segregated communication channel (out of band) is a good method in order to improve the efficiency of the dynamic linking
We consider that the definition of segregated channels could be clarified in order to prevent from a misinterpretation; actually there are potentially several meanings:
• Separated channels on two different devices
• Separated communication channels even on the same device but with separated session, with for example separated SSL tunnels
Our understanding is that two communication channels even in the same mobile application in the same device could be possible if it leads to two segregated secure channels
We are wondering how should be considered the dynamic linking when there will be several payments, with a mandate for example, to only one payee and where the maximum amount is not known at the time of the transaction?
Question 3: In particular, in relation to the protection of authentication elements, are you aware of other threats than the ones identified in articles 3, 4 and 5 of the draft RTS against which authentication elements should be resistant?
For inherence authentication factor, Worldline considers that the different biometrics technologies are not equivalent in terms or reliability and false positive rate.Physiological biometrics, fingerprint recognition, face recognition and eyes recognition do not provide the same level of assurance, especially if we consider the possible fake authentications.
So it seems interesting to qualify the different biometrics methods related to a level of reliability and then a level of assurance.
We suggest considering a minimum level of security for biometrics authentication (Equal Error rate for example).
This could be adapted regularly in the future with new possible biometrics authentication or technological improvement.
Question 4: Do you agree with the EBA’s reasoning on the exemptions from the application of Article 97 on strong customer authentication and on security measures, and the resultant provisions proposed in Chapter 2 of the draft RTS?
Worldline considers that exemptions are too limited, and are not in line with future evolutions of strong authentication approved methodIndeed, market of strong authentication evolves towards Risk-Based Authentication and Continuous Authentication concepts in order to find the right balance between security and user experience.
Some new online payment protocols (for example 3D Secure 2.0) also go in that direction, by enabling “frictionless flow” for low risk transactions.
equensWorldline’s position is to let issuers decide the best authentication strategy for each transaction, based on a risk scoring engine. And exempt transactions that are scored as low risk.
Article 8-1-b-ii and 8-2-d-ii: cumulative amount of previous contactless transactions: is there a limitation in time or no limitation and cumulative till realization of a transaction with strong authentication with same payment instrument?
It is very unclear to see how the cumulative amount is managed because there is no indication of duration for that cumulative amount (month?)
That shows that the idea of velocity of similar transaction is taken into account but with very light rules.
It should be possible to add more rules around that list of exemptions in order to propose a real risk based authentication features.
That could improve the user experience for the same level of security.
We suggest that RTS mentions the minimum security requirements applying in context of the exemption, if any (i.e. by if no strong customer authentication, what else is required? E.g. for Low Value Payment, we still need some device authentication (something you have) without customer authentication (something you know)
Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?
Innovation in online services is one of the key points for Payment Service Providers (PSPs) to invent and propose new and innovative services. This list of exemption is very limited to allow PSPs implementing Risk based Authentication and so propose a seamless, powerful but still secure user experience.Question 6: Do you agree with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials, and the resultant provisions proposed in Chapter 3 of the draft RTS?
Article 11: On creation and usage of personalized security credentials, Worldline is in line to produce and update on regular bases risk analysis;Article 12 (a): Worldline would like to point out that in certain situations, user identification and or authentication during the initial services activation can be delegated to a third party. In this particular case, the PSP should be allowed to accept an authentication proof that user’s identity has been performed by a third party. The associated personalized credentials, devices & software will be executed in a PSP secured environment as described in this chapter, but based on user identity verified by a third party.
Article 16: Worldline has the same remarks as in article 7 (commented in question 1).
General considerations:
equensWorldline considers mandatory to clarify terms as “sensitive data” and “personalized security credentials”. This will also help to define rules of liability and chargebacks.
Sensitive data defined in this list should also comply with data protection requirements existing in place in each country.
Question 7: Do you agree with the EBA’s reasoning on the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, and the resultant provisions proposed in Chapter 4 of the draft RTS?
We fully support the use of standard for the new services proposed by the PSD2. We even consider that as those services are new for most actors, there is a momentum for the creation of standards to be supported by all actors in order to ease an efficient deployment of those new services (by removing any technical barrier).The RTS mentions mainly the use of standard for the technical interface with the ASPSP’s.
We see the need for standardization at two levels:
• The functionality of the services
• The technical interface
Standardization of the functionality of the services
The functional scope of the new services (Account Information Service AIS, Payment Initiation Service PIS, check available amount) should be standardized - in order to ensure a coherent development and deployment of new services by all actors for the benefit of the actors (payers, payees) - rather than having access to same information as on current bank remote infrastructure (as stated in article 22).
The functional description of the exchange of information between PSP and Account Service Payment Service Provider (ASPSP) aims to ensure the integrity and atomicity of the transaction. Several aspects should be described and standardized per function (AIS, PIS, ...)
• Content of the service, e.g. for PIS, execution of an SEPA Credit Transfer, real-time notification of execution and guarantee of execution
• Nominal behaviour: exchange of messages; mandatory content of messages, e.g. elements for unambiguous identification of the transaction; optional content; integration of the payer authentication session within the transactional flow, etc.
• Exception behaviour: timeout handling, e.g. technical cancellation; process in case of problem, e.g. non execution of SCT, payee account not credited
As an example, the content of the service ‘availability of funds’, article 22-1c should clearly mention that the answer of this request (Yes or No) doesn’t imply any kind of reservation of the amount or any kind of payment guarantee.
Standardization of the technical interface
Article 19.1 imposes ASPSP’s to offer at least one communication interface for the new services (AIS, PIS, check available amount). Article 19, 3, imposes use of ISO20022 elements, components or approved message definitions, if available.
Having a standard technical solution would bring as benefit
• A standardization of the functionality, even if some flexibility will remain
• An assurance for a full reachability of all banks and thus an improved level of acceptance
• A reduction of the costs of the new services by a reduction of the technical barriers (i.e. no need for a PSP to support several different technical solutions for a same service).
Article 19-5: mentions that ASPSP may change its technical specification with a 3 months notification period. This delay appears to be very short. A distinction should be made between urgent changes and normal maintenance for which a notification period of 6 months is a minimum. In a context where the technical interface is defined by a standardization body as suggested above, it would be the responsibility of this body to manage the evolution and maintenance of the specifications, including a maintenance lifecycle (e.g. one new release per year, information on scope 9 months before publication, publication of specifications 6 months before release).
Consumer authentication according to methods provided by the ASPSP
RTS mentions that the consumer must use the authentication method provided by ASPSP and that ASPS may on a bilateral basis agree for an authentication made by the PSP.
Our opinion is that non-bank PSP (AISP, PISP, card issuer) should also be allowed to provide their own authentication solution to their consumers (in line with requirements related to strong customer authentication) and ASPSP’s should be obliged to accept such method provided this method is approved by a recognized independent body as meeting the SCA requirements. The rationale is that using the authentication method provided by the ASPSP is probably acceptable in the remote/E-Com environment but is not realistic in the proximity environment (e.g. use of a ‘loyalty’ token/card provided by a merchant for its own new payment method at the cash register environment cannot be combined with a dynamic authentication method provided by an ASPSP which requires a dedicated user interaction and for instance the use of the bank card combined with a specific hardware module to open the session and to sign the transaction).
We consider that the case by case negotiation between a PSP (AISP, PISP, card issuer) and various ASPS’s for acceptance on a bilateral basis of their PSP authentication solution is not realistic and will bring a distortion of competition between PSP’s (banks probably more open to negotiate with more important/worldwide actors and not with small actors). Article 19-1 should be adapted accordingly.
Question 8: In particular, do you agree that the use of ISO 20022 elements, components or approved message definitions, if available, should be required to ensure the interoperability of different technological communication solutions implemented between PSPs for the provision of AIS, PIS or for the confirmation on the availability of funds? Do you see any particular technical constraint that would prevent the use of such industry standards?
Standardization around messages between the Third Party Provider (TPP) and ASPSP is welcome and effectively standard ISO 20022 seems to be appropriate.Question 9: With regards to identification between PSPs, do you agree that website certificates issued by a qualified trust service provider under an e-IDAS policy would be suitable and allow for the use of all common types of devices (such as computers, tablets and mobile phones) for carrying out different payment services ?
There are in our view two different issues to be covered.• The first is about the secure identification between Payment Service User and PSP.
• The second is about the secure identification between PSPs.
The first issue is in our view out of scope of the present RTS, and may indeed be different according to the technologies used, including devices. For example, the current EMV protocol does not include identification of the merchant by the card.
The second issue is clearly within the scope of this RTS: we believe that digital certificates issued by a qualified trust service provider could indeed be used to identify and secure communication between PSPs and we support this idea.
Regarding the use of digital certificates issued under the eIDAS policy, many questions still need to be answered:
Today, eIDAS rules are dedicated to public bodies. They will need to be adapted to payment activities in a private sector. When will these rules be established?
Who will manage the issuance of certificates? Will it be the national regulatory bodies delivering the licenses? Is so, under which eIDAS policy, under what delay, etc? If so, will there also be a central pan-European register to manage the certificates?
As a conclusion, EBA should: first clarify the usage of digital certificates, making it clear that they will be used to mutually identify PSPs and not PSUs and PSPs, and second provide more information on the implementation of eIDAS compliant certificates in the context of PSD2.
Question 10: With regards to the frequency with which AIS providers can request information from designated payment accounts when the payment service user is not actively requesting such information, do you agree that the proposed limit of no more than two times a day achieve an appropriate balance between allowing AISP to provide updated information to their users while not negatively impacting the availability of the ASPSP’s communication interface? If not, please indicate what would be in your view the appropriate frequency and rationale for such frequency.
In principle the frequency of two times per day seems to be sufficient as default.But EBA should consider that ASPSPs support a higher frequency in case the PSU explicitly requests more than 2 times a day access to the account via an AIS provider. At least EBA should ensure the continuation of the same service level for the PSU as provided by ASPSP via online banking portals today.
This includes no extra charge and no limitation for multiple accesses per day.
Clarification about the time zone to define the beginning/end of day would be necessary.
In latter case the AIS should receive a mandate from the PSU for multiple accesses to avoid application for each single request.