We welcome the fact that Payment Services Directive (PSD2) includes SCA as this will lead to strengthen the overall security of payments in Europe. SCA applied by PSP is mandatory when the payer accesses his payment account on-line or initiates an electronic payment transaction or carries out any action, through a remote channel, which may imply a risk of payment fraud or other abuses.
As ASPSPs are responsible for the protection of PSU’s funds and for the correct execution of PSU’s payment transactions: SCA should always be performed by ASPSPs.
Customer authentication should be based on multiple tools defined by transactional contexts and customer behaviour. For instance, authentication for account consulting should not be the same if initiated from home by the user or from an internet coffee in another country.
The examples of actions carried out via a remote channel that may imply a risk of payment fraud or other abuses that are listed in the paragraph 27.iii of the discussion paper are clear enough and bring sufficient detail to understand the issue of article 97 (1) (c) of PSD2.
About the reference to the remote channel, we understand that it concerns only actions being conducted via the internet or through a device that can be used for distant communication: RTS should then refer to electronic remote channel only, excluding for instance mail, fax channels.

In tomorrow’s digital world, part of the data will be in the cloud. Therefore, having only a physical support as element of possession is unrealistic. Both physical form and data are to be considered as possession element for SCA.
Furthermore, if the element of ownership only had to be a physical form, it would lead to have all PSUs equipped: management of tokens or keys means issues to deal with in terms of stocks of piles for calculators for example or quick replacement in case of loss or theft.
The border between the physical support and the immaterial form is blurring: the real matter is to ensure the exclusive control by the PSU of its possession element. There should be an evaluation of the solution level of security to make sure that the container is secured.
Via a softToken (application downloaded into the device), the PSU will always have a device or a media, that is a physical support in the hands, which has been previously enrolled by its AS PSP: the issue relies on the quality and the efficiency of the enrolment of the device by the AS PSP.
Enrolment of the PSU’s device by the AS PSP with the supply of a key linked to that device could be considered, provided that it can be controlled by the AS PSP (when processing the enrollment and regarding the integrity of the device). The PSU, in case of a payment transaction that requires SCA, validates the elements of the transaction in addition to the entry of the credential sent.
Concerning Out Of Band solution, the possession element is a software certificate downloaded into the smartphone of the PSU.

Behaviour-based characteristics may help to fight against fraud and may be part of the inherence element. Nonetheless, they cannot be a full substitute to SCA.
The most important part is that there should be an evaluation to ensure a level of confidence in the overall system. This evaluation should be performed by an independent body and state of the art standards should be referred to.
It is clear that for a better customer experience, within the coming years, biometric characteristics will be increasingly used. In the context of SCA, biometric characteristics match the definition of strong inherence element.

We believe that tomorrow use cases in the digital world will not imply 2 different devices. Consumers are keen on easy and quick payment solutions.
Referring to paragraph 32, Out Of Band solution is considered as a secured and valid solution for SCA and is currently applied in our banking group. The Out Of Band authentication is a double factor authentication similar to the OTP SMS authentication. Via a first channel, the aim is to check “what I know” (my pin code) and then via a second channel “what I own” (my mobile phone). The PSU has to register the “fingerprint” of his/her smartphone (hash) with the bank first and he has to know his/her pin code. The Out Of Band authentication allows the AS PSP to verify the mobile phone possession before each sensitive operation.
It is difficult to ensure a complete 100% independence of the two authentication elements used for SCA with for instance a known case of Trojan horse on smartphones which had impact on payment transactions and captured SMS code (both applications were hacked).
A prior enrollment of the PSU’s devices shall be processed when he/she enters in relation with its AS PSP; the quality of this enrollment being a key point to give the AS PSP the ability to link securely and efficiently the elements allowing to process a strong customer authentication.
Moreover, the AS PSP will have to deal with this issue of independence of the authentication elements on a mobile device and implement adequate fraud management. This fraud management will require detailed information on associated payment data, the device and the use case.

With the development of electronic payments and data to be managed in the cloud, PSPs should try to duplicate the principles used in the area of proximity payments like for card payments i.e. ensuring the link between the payment transaction and the PSU. The PSU should always be aware of what he/she is doing and then especially about the amount of the transaction and the name of the beneficiary (principle of what you see is what you sign). This link may be processed with different solutions.
It should be noted that currently when transmitting payment orders by files, corporates are not asked to validate each transaction but their file of payment transactions. Therefore, in such case, dynamic linking should only be done with the file.
It should be noticed that even with dynamic linking, the man in the middle fraud still exists.

SCA processed via Out Of Band solution fulfil both objective of independence and dynamic linking.

Clarifications suggested in paragraph 42 will be very useful.
It should be noticed that when SCA is not required, authentication based on the PSU’s device (for example with the key provided by the ASPSP for the enrolment) and on behaviour-based characteristics could be done in some cases.
Access to services should be based on a multi-level authentication which level is defined by transactional contexts and customer behaviour. For instance, authentication for account consulting could not be the same if initiated from home by the user or from an internet coffee in another country.
Account number and name of the PSU are considered in PSD2 as non-sensitive data for AIS and PIS under article (4) (32). Thus, for level playing field, these data should also be considered as non-sensitive for ASPSPs.
Clarifications would also be very useful:
- referring to the exemption in 42.A. on the amount of low-value payments
- referring to the exemption in paragraph 42.E. on sensitive payment data (what about the sensibility of the beneficiary’s account number?)
- referring to the exemption in 42.E. on the definition of “purely consultative services” with some use cases for instance. In our understanding, the definition of “purely consultative services” applies only for direct access by PSUs.

In case of PIS or AIS, which transactions may benefit from exemptions listed in the paragraph 42 ? In case of a direct relation between the ASPSP and the PSU, the ASPSP is allowed to apply a simple authentication - exemption to SCA- for transactions with amount below €20 (example of NFC payments). The ASPSP then bears the associated risk. If the TPP was to apply SCA exemption, the TPP should bear the associated risk in case of fraud.
Should such exemptions to SCA be mandatory, and without direct link between the PSU’s device and the ASPSP in case of PIS, then the ASPSP has no means to perform its risk analysis and comply with authentication. As a result, a liability shift should happen from the ASPSP to the TPP as it currently happens in the cards payments framework if the payee’s PSP refuses the strong customer authentication.
We are concerned about the fact that ASPSPs might face the risk of massive claims about unauthorized operations. Such number may increase regarding exemptions application that could attract fraudsters’ interest. Requirements in terms of industrial management of customers’ claims should be addressed particularly in case of PIS as ASPSPs and PISPs do not have any contractual relationship. Without such framework, numerous legal actions will happen and generate additional costs (exceptional handling, insurance, communication).

There is today no other factor except the fact that all actors should be considered in the same way to ensure a level playing field (same rules for all).
It is important to anticipate and define an agile way of reviewing the RTS especially about exemptions to SCA. Some exemptions detailed in the RTS may attract fraudsters interested in data theft or fraudulent payments. ASPSPs have systems and solutions that help for monitoring fraud attempts. Such agile mechanism for reviewing RTS on exemptions to SCA should be addressed provided that ASPSPS are free to stop any access or block any service in case of fraud attack.

Other criteria should be added to the ones listed in paragraph 45. such as PSU’s device jailbreak/rootable.

Revocation of PSCs at the PSU’s request or at the initiative of the PSP should be added to the paragraph 52.i.Some actions done by the PSU on his/her device like rootage or jailbreak of iOS induce that SCA solution might not be considered as sufficiently secured. In such case, it should be allowed to upgrade the level of authentication with an analysis of other characteristics.
There is no need for TPPs to get the PSU’s personalised security credentials: this goes against what ASPSPs have worked for during last decades. Each credential is personal and private and should not be shared with anybody or any third party. The PSU should not be allowed to transmit his PSCs to anyone.

We identify the following items:
- Revocation and destruction of data
- Revocation of credentials

We are facing a situation where the number of actors implied in the payment segment chain may increase quickly. Evidence and end-to-end traceability are essential to offer safe and secure payment services to PSUs with clear rights and obligations between all parties.
We question how the PSU can be certain that the TPP is authorized and is the one it pretends to be?

Key questions remain the same: What does the enrolment process encompass? What are the actors involved, are we talking about PSU to ASPSP enrolment or TPP to ASPSP enrolment?
Besides face-to-face done at the branch office, solutions to be considered for securing the enrolment and the credentials’ delivery will include tomorrow innovative process like face-to-face with video as some solutions are currently being audited for secure qualification.
OAuth 2.0 is an example of open standard that could be used when processing the enrolment.

No, certification or evaluation by third parties of component payment solutions or mobile devices is necessary.

Such risks are present over all segments of the payment chain from enrolment to consent to execute a payment.
The growing number of actors between the ASPSP and the PSU, by adding new segments in the payment chain, actually increases the risk of fraud and may weaken the chain.
Moreover, a higher number of actors in the payment chain also increases the risk of phishing.
Evidence and end-to-end traceability are definitely essential issues to mitigate risks over the payment chain.

The list of topics under paragraph 63 seems appropriate. Nonetheless, as regards to the future Regulatory Technical Standards, the definition of the good and appropriate level of detail is a key point. Indeed, the future Regulatory Technical Standards should not be too precise for safety reasons i.e. not having the same solution implemented by all PSPs that could attract fraudster’s interest and for not slowing down innovation, nor too vague in order to allow effective implementation by PSPs of compliant solutions.
Moreover, besides the scope and content of these future Regulatory Technical Standards, having a whole framework describing rules and responsibilities of different actors is necessary as it would bring trust and confidence for PSUs, PSPs, and TPPs.
These RTS are paramount to the harmonisation of the market at pan-European level and should ensure a level playing field among all actors.

When defining RTS, we believe that a focus should be made on traceability on ASPSPs and TPPs flows in order to enable fraud prevention and liability shift.

About topic b) - the way TPPs identify themselves towards the ASPSPs: To address this issue, there is a need for a European body which would maintain an updated list of authorized TPPs and would issue associated certificates (PKI concept). This body should operate a Trusted Service List at the European level or centralize Trusted Service Lists operated in each member state.

About topic d) - The minimum functionalities requirements:
Comments on this topic is rather difficult at this stage, we would have wished to be able to further comment on this topic, the lack of clear picture at this stage of RTS details, use cases and customer experience with AIS or PIS was a restraint.

About topic f) - The minimum technical requirements:
Without any contract or scheme management, there could not be any SLA required by EBA. TPP will benefit from the same level of service as PSUs, ASPSP should expect the same behavior from a PSU or a TPP, which refers to the ‘’user thinking time’’, and avoid any batch or robot process .To ensure a better service to the end-users, we recommend that EBA defines exchange limits in terms of volumetric to prevent the risk of denial of service and potentially any discrimination. Such requirements are defined on existing infrastructures (i.e. STET). In France some ASPSPs’ online banking services already went down due to peaks of TPPs requests.

Some type of framework is expected to ensure a secure way for all parties to communicate and exchange and to allow a harmonized implementation of PSD2.

Open standards currently exist like those based on API concept.
It is important to use open standards that are regularly certified by Third Parties and subject to audits.

These requirements should ensure that all parties refer to common and open standards allowing innovations’ integration. As stated at the question 17, there is a need for using open standards that are regularly certified by Third Parties and subject to audits.

e-IDAS regulation could be considered as a solution with the substantial level for authentication issue.
e-IDAS regulation could be then a facilitator or an opportunity. In France, today, we do not have any national e-id mean, therefore e-IDAS may not be a short term solution but it could be a facilitating solution in the coming years.

e-IDAS regulation does not foresee the transmission of credentials via third parties.
Besides, regarding certificates, all authentication solutions should not be certified as e-IDAS qualified, as it may not fit the need of security of AS PSPS’s services (a lighter method for authentication could be appropriate and then chosen by the ASPSP).