Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
Mobile phones, tablets, computers, connected devices etc., to be enrolled within the ASPSP
Dynamic token devices (i.e. RSA key, Vasco token, etc.) and static token devices (e.g. a certificate), both issued by a Certification Authority, which is part of a Public Key Infrastructure.
Possession elements can be data but there need to be a link with a physical form (what I own). This means that the PSU will always use a device to access the data.
Upon the enrolment by the ASPSP, the device needs to be registered: a single specific authentication key is delivered by the ASPSP and is uploaded on the device of the PSU.
The use of behaviour-based characteristics should be left at the sole discretion of the ASPSP.
The RTS should neither forbid the use of behaviour-based characteristics nor make them mandatory.
.
More generally, we consider that the confidence in the overall system of SCA should be in line with state- of- the-art standards defined by an independent accredited body (cf. title 2 of EBA internet security payments guidelines regarding supervision).
Total independence of the authentication elements used can never be ensured, the PSU being able to decide which device to use, i.e. a clear increase in the usage of mobile devices today.
To tackle those challenges regarding the use of a mobile device by the customer, the following requirements should be made mandatory:
A prior enrolment of the user’s devices shall be processed when he/she enters in relation with his/her ASPSP; the quality of this enrolment being key to give to the ASPSP the capability to link securely and efficiently the elements allowing to process a strong customer authentication. (cf. the SecurePay Forum draft regarding security guidelines on mobile payment)
Each of both elements should be processed independently, through 2 different channels, for example internet network and mobile network
Moreover, there is a challenge regarding the independence of the authentication elements on a mobile device, which shall generate a reinforced fraud management policy. This fraud management will require detailed information on the associated payment environment: the device that is used, and the context usage.
It results that the processing of a transaction (account information or payment initiation services) through a TPP should not remove the capability for the ASPSP to have a direct access to the PSU in order to process its strong customer authentication, even if the TPP relies on the authentication procedures provided by the ASPSP.
For users, we consider the 3DS process existing in payment cards provides this dynamic linking: today a dynamic code issued by the ASPSP is sent to the PSU, who enters it to finalize his/her payment knowing the amount and beneficiary, and hence validate the true amount and beneficiary.
A similar process is currently used to finalize SCT payments: if the payment is considered sensitive, a dynamic code issued by the ASPSP is sent to the PSU, who enters it to finalize his/her payment, hence validating the true amount and beneficiary.
In both cases, this could be considered as the relevant information of the payer on the specific transaction.
If not, some ASPSP’s payment infrastructures would have to be upgraded to further dynamically link the code to the beneficiary and amount of the transaction, sealing the payment signature. This could require more than 18 months to develop and implement for some actors.
For corporate bodies and governmental agencies, the strong customer authentication is performed in a specific way: for instance corporate bodies does no validate each transaction but the whole file with the summary of all their transactions. The dynamic linking shall only be done with the file.
It results that the processing of a transaction (account information or payment initiation) through a TPP should not prevent the ASPSP to have a direct access to the customer’s device to process its strong customer authentication, even if the TPP relies on the authentication procedures provided by the ASPSP.
However, as SCA is made mandatory under PSD2, we understand that ASPSPs have the responsibility to perform systematically a SCA to ensure the security of transactions.
Our understanding is also that potential exemptions to SCA are being considered by the EBA, which makes the implementation by the ASPSP of such exemptions possible but not mandatory (art. 97).
The exemption list proposed in the EBA discussion paper seems to come directly from the EBA guidelines on Internet payments such as listed below:
a) low value payments,
b) white beneficiaries lists to be stated by the customer (which is to be maintained by the ASPSPs)
c) transfers between two accounts on the same PSU held at the same PSP,
d) low risk transaction based on a transaction risk analysis ,
e) purely consultative services,
f) This list has to be completed as follows: Instalment payments, where only the first transaction should be based on the SCA
And amended as follow:
the criterion b) “white beneficiaries lists to be stated by the customer, (which is to be maintained by the ASPSPs)” has to be deleted from the criteria exemption list knowing that if a white list could be a criterion of acceptation of beneficiaries, it couldn’t be a criterion of exemption of SCA.
We would like to point out
I) Regarding low value payments, that online low value payments made by SCT may represent some risk and do not mean low level of fraud. ASPSPs are currently facing daily massive frauds on electronic payments (for instance online music purchase).
NB: It has to be underlined that it is different for low value payment processed “over the air” transaction like NFC transaction where the customer is present with his card.
NB: Regarding specifically the ‘’low risk transaction based on a transaction risk analysis’’, we suggest to make it broader in order to encompass the account access. We would prefer to have ‘’low risk transaction and account access based on a risk analysis performed by the ASPSP’’.
Moreover, a definition of low value payments would be appreciated as today there seems to be different definitions.
In addition, RTS should provide a specific definition for contactless payment.
II) Regarding ‘’consultative services’’:
- As there is no definition of what “purely consultative services are, we would like the RTS to clarify this notion with use cases, make it more explicit and define it.
In our understanding “purely consultative services” can only apply to the PSU, and not to the TPP which will request the consultation plus transmission of data.
Furthermore we suggest that the RTS provides clarification on the sensitive payment data (art. 4) with examples on data that are considered sensitive. As the account number and the name of the beneficiary are not sensitive for TPPs, they should also be considered not sensitive for ASPSPs in order to ensure a level playing field.
- As a best practice the RTS would have to recommend the use of strong customer authentication when the AISP accesses the account for the first time. This will allow the ASPSP to get the required explicit consent of the PSU and his acknowledgment of which accounts to be accessed by the TPP. After a certain period depending of the ASPSP’s own risk management policy (i.e. risk detection, new device used by the customer …) or in case of a modification of the list of the accounts to which the AIS can have access, the ASPSP may request another strong authentication of the user.
- In terms of workflow, it is unclear how the ASPSP will know when the user wants to stop using the services offered by the AISPs.
We take the above exemptions - points a) to f) - into consideration in a context of direct relationship between PSU and ASPSP, however we question their application in case of the use of a TPP. We would like indeed to point out 4 major items.
1) In a context of a purchase made by the PSU via a mobile device and a payment subject to SCA exemption, made by a TPP, the ASPSP still needs sufficient information on the customer’s environment to perform its risk analysis, exactly as in the case of a direct access, with or without a SCA performed. The introduction of TPP in the process, should never reduce the quality / strength of the authentication compared with the authentication already performed by the ASPSP towards its PSU.
As a result, the ASPSP should be able to access directly the PSU’s device via a dedicated and direct connection in order to apply its own appropriate risk-based analysis, which shall be processed, independently from any risk analysis that may be performed by the involved TPP. The ASPSP has to be absolutely sure that the customer is the right one, and that he gives its consent to the transaction.
2) If against our understanding, such exemptions to SCA are made mandatory by the RTS, and if there is no direct connection between the PSU’s device and the ASPSP for sake of performing SCA in case of transactions via a TPP, then the ASPSP has no way to perform its risk analysis and to comply with its obligation to perform a complete SCA. This should logically result in a shift of liability from ASPSP to the TPP.
In case of SCT transaction, the PISP will have to provide the beneficiary IBAN. The ASPSP will have to rely on this information, which will be the only one (alongside with the name) known on the beneficiary. The PISP will have to provide the ASPSP with the information required for the correct execution of the transaction, included the finalisation of all controls needed.
3) The ASPSP shall have the capability to decide whether to apply the SCA exemptions (management of its own risk on the basis of its risk policy).
If not, it would have as a consequence that if the ASPSP requires a SCA but can’t perform it, the transaction can be rejected unless there is a liability shift to the PISP.
4) In the context of exemption to SCA and in the absence of dispute resolution rules, the forthcoming claims on remote SCT payments wouldn’t be addressable in an industrial manner. However a serious risk of a significant rise of claims exists, a minima as what is foreseeable for card remote payments. New remote payments methods, less secure than card payments, risk to be very attractive for fraudsters, especially when a TPP is involved. The number of fraud cases will increase along with fraudsters’ taking advantage of the context of SCA exemptions. A comprehensive framework is necessary to address the forthcoming customers’ claims.
We believe that the evaluation of the customer risk belongs to the own risk policy of each ASPSP. So, even if an exemption is requested, the ASPSP must be allowed to process a SCA (e.g. one every x payment, or one at random.)
Again, a framework (or a minima a set of requirements) should be developed to address the forthcoming customers’ claims and secure the customers against fraud.
A risk based analysis should be developed, if not already done, by the ASPSP, which could lead or not to a SCA. In case of a transaction via a TPP, the ASPSP could miss key elements such as the one listed in paragraph 45 a;b;c.
This information would have to be requested by the fraud detection module which could be accessed in any API settled to process payment transaction, even if a TPP is involved in.
Today when using the PSU’s personalised security credentials (PSC) a TPP access to the whole online banking of the PSU, includes sensitive information as well as information not needed by the TPP to address its client’s needs. For both reasons, it is necessary to strongly protect the PSU's PSC.
So, we would like to recall that personalised security credentials are keys in the SCA process. Nevertheless this wording encompasses a very wide notion.
Art. 67.2b and 66.3b seem to be ambiguous: will TPPs have access or not to the PSUs’ security credentials
The suggested clarification regarding the protection of users personalised security credentials seems to be appropriate but is not sufficient enough.
As stated in Article 67b, TPPs shouldn’t have the right to access the PSUs’ personalised security credentials. But Art. 67.2b and 66.3b are ambiguous, RTS will definitively have to specify this topic.
Critical risks currently exist relating to the confidentiality and the integrity of users’ personalised security credentials when a TPP is involved in a transaction and as a consequence in the trust chain.
TPPs shouldn’t have the right to access the PSUs’ personalised security credentials as stated in Art 67 b.
RTS will definitively have to specify this topic and should be more specific on the protection of PSU’s personalised security credentials. The RTS should clearly state that the PSU has to authenticate himself with the authentication method of his ASPSP inside the ASPSP's environment during the transaction phase. That will prevent any disclosure of the PSC to any third party. It is worth reminding that in case the PSC are compromised while being used for another purpose than the one for which they were established (i.e. access to online banking), these PSC will need to be changed for all purposes (online banking, aggregation services, payment initiation ...).
More specifically (referring to paragraph 51 E of the discussion paper), French banks strongly recommend that PISP do not have access to the PSC at any time during the payment process. They do not need this information to require the ASPSP to initiate a payment. They would favour solutions where the PSU is redirected by the PISP to the ASPSP's authentication module and authenticated himself in the ASPSP's secure environment. The benefit for the PISP lies in the fact that it won't have to develop and maintain secure processes to access, transmit and store sensitive data.
Moreover a key question has to be addressed: How can the user identify that the TPP is the correct one?
TPPs will have to be registered in the EBA register. As the market develops, phishing attacks may increase and TPPs may be hacked. PSUs may then lose confidence when accessing a TPP’s interface as they are not able to distinguish a genuine TPP’s interface from a fake one.
As the market develops, how will this process be supervised? This needs to be specified by the RTS.
Moreover there should be an evaluation to insure a good level of confidence in the overall system. This evaluation should be performed by an independent accredited body and state of the art standards should be referred to.
Risks are identified but would be amplified if all the requirements currently existing on ASPSPs did not apply equally to TPPs (risk assessment, incident monitoring, safeguard processes, etc. – cf. EBA guidelines on the security of internet payments, etc.).
Key questions remain the same: What does the enrolment process encompass? Which are the actors in place? Are we talking about customer-to-ASPSP enrolment? TPP-to- ASPSP enrolment?
ASPSPs have their own innovative and secure solutions for remote customer enrolment into the bank process. As of today, it is not designed for TPP involvement in the process.
Frameworks such as OAuth 2.0 precisely aim at securing the transmission of the client's consent to access its resource without compromising its online banking credentials. To do that OAuth introduces an authorisation layer in which a third-party app is issued by the server which hosts the client's resource (e.g. the ASPSP) a dedicated set of credentials. Other common and innovative protocols will probably emerge in the coming years to address the future challenges. That reinforces the need for the EBA to remain technology neutral in order to be compatible with the coming new open and common standards.
In paragraph 52, the EBA addresses two different issues concerning the enrolment:
1- Enrolment of the PSU by the ASPSP (§A to D)
2- Access of the data by TPP in the course of a payment service (§E).
The first issue is been addressed for years by ASPSP, that have implemented elaborate processes to limit fraud during the enrolment phase, even in the case of digital communication channels.
As mentioned in the answer to question 10, French banks strongly recommend that TPP do not access to the personalised security credentials at any time during the payment process. They do not need this information to request the ASPSP to initiate a payment.
They would favour solutions where the PSU is redirected by the TPP to the ASPSP's authentication module and authenticates himself in the bank's secure environment. The benefit for the TPP lies in the fact that it won't have to develop and maintain secure processes to access, transmit and store sensitive data.
There are existing open standards on the market such as SEPAmail, whose one key component is a common PKI (public key infrastructure) allowing interoperability and a secure and harmonized marketplace among PSD2 actors.
In the early 2010s, the client had to share its credentials with the TPP to access its resources, what created numerous problems and limitations. As the number of web services and mobile apps requiring the creation of a user account by the client, new protocols and frameworks have being designed by the IT international community to address the issue of third parties applications accessing restricted resources. OAuth 2.0 is an example of such frameworks. As stated in the RFC6749, such practices are deemed to be unsecure:
- Third party applications are required to store the resource owner's (PSUs) credentials for future use, typically a password in clear-text;
- Third-party applications gain overly broad access to the resource owner's protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources;
-Resource owners cannot revoke access to an individual third party without revoking access to all third parties, and must do so by changing the third party's password.
Consequently the state-of-the-art practices do not rely on credentials sharing. If sharing credentials was quite common when the draft PSD2 has been written, that is no longer the case. The EBA should take the fact into account.
Moreover, as explained before state-of-the-art practices evolve quite quickly in the market. This fact strengthens the necessity for the EBA's rules to be technologically neutral to adapt to the future standards and best practices of the market.
Art. 67.2b and 66.3b are ambiguous: TPPs should not have access to security credentials. RTS will have to specify this topic.
In the future, TPPs will have to be registered in the EBA register. As the market develops, phishing attacks may increase TPPs can be hacked and, the PSUs may then lose confidence when accessing TPPs’ interface, as they are not able to distinguish a genuine TPP’s interface from a fraudster. As the market develops, how will this process be supervised?
- ensure a PKI (public key infrastructure) for a proper and mutual authentication between TPP and ASPSP
- define common standard and ensure the shared evolution of the common rules
- define the minimum level of security
- harmonized implementation and evolution
An open standard means accessibility on the contrary to a proprietary standard. Everybody can use it freely.
We globally support open and common standard widely shared and used by a majority of entities such as W3C
Globally the level of details that is provided does not allow a practical and precise implementation of a secure communication between ASPSP and TPP.
a) Definition of standards
For corporate bodies there seem to be no need for recommendations of standards by the EBA as corporate bodies and banks are currently using open, common and secure standards, such as EBICS.
Regarding security standards, it is not sufficient to have neither ‘open’, ‘common’ and ‘standards’: ASPSPs cannot accept low level of norms (for instance SSL v1 is not acceptable, and everyone should use at least SSLv3/TLSv1) and should be able to decide the adequate level of standards to be used, such as RFC6749.
Some type of governance should be in place to ensure shared evolution of the common rules.
b) The way TPP identified themselves to ASPSP
TPP should be duly registered by national regulators with the description of the services that are proposed (PIS, AIS).
Then TPPs have to identify themselves towards the ASPSPs as required in art. 67.2.c.
For sake of authentication, we recommend either a centralized PKI maintained by a central body at EU level or a European federation of domestic certification authorities, or at least a list of certification authorities with a common level of quality (duly registered and accredited), to ensure a level playing field.
If there is no PKI, the trust in the TPP couldn’t be insured out of the request of the signature of bilateral contracts within TPPs and ASPSPs, and the risk in fine of a fragmentation of the market.
c) The way PIS, AIS, and ASPSPs communicate with each other’s and with the PSUs should be based on common, open and secure standards
d) As the workflow is not known yet, it is difficult to address this question. Clear governance appears to be vital. Functionalities should at least encompass the strongly authentication of the TPP by the ASPSP and for AIS, the PSU’s consent to access to the account. RTS should not go beyond what PSD2 outlines (for instance in article 66.4.b for PIS).
e) The minimum security controls should at least encompass the preservation of the confidentiality and integrity of data during of the exchanges, evidence management and traceability of the user device elements regarding fraud management. Automatic delegation of SCA should in no way be defined as a rule by EBA.
f) Regarding technical requirements: Without any contract or framework management, there could not be any service level requirements imposed by the RTS.
As TPP will benefit from the same level of service as PSUs, ASPSP should expect the same behaviour from a TPP than a PSU. This assessment, refers to the ‘’user thinking time’’, and avoid any batch or robot treatment.
To ensure a better service to the end-users, we recommend the RTS to define exchange limits in terms of volumetric to avoid any risk of denial of service and potentially any discrimination. Such requirements are defined on existing infrastructures (i.e. STET). In France the daily operation of some ASPSPs’ online banking services were seriously disrupted due to unexpected peaks of TPPs requests.
NB: PSUs are expected to give explicit consent for each TPP they choose to use. This may lead to the creation of filters of TPP in the PSU’s online banking at the request of the PSU
New protocols such as OAuth 2.0 do take into account the privacy dimension in so that the client defines the set of resources that the third party app can access to deliver its own service. On the contrary to the current practice of aggregators, where they can access to the whole online banking, these new frameworks respect the principle of privacy by design.
They also foresee the registration of the TPP by an authorization server before accessing the resources of the client. Different methods can be used to accomplish this step, but in any case the TPP has to provide information to the authorization server (such as application name, description, acceptance of legal terms...).
In our view, other existing standards seem as of today appropriate and relevant, such as for instance TLSv1.2 or EBICS TS.
Such requirements should also be compatible with existing solutions that are already secured (i.e. EBICS TS for instance).
What are the other innovative business models, other than PIs and PIS, which are suggested?
Open standards such as SEPAmail for instance could be the appropriate answer as open standards allow any type of interfacing, with existing or new frameworks. Once again, in our view, other existing standards seem as of today appropriate and relevant, such as TLSv1.2 or EBICS TS.
It has to be mentioned that a solution implying the issuance by the PIS or AIS of their own credential to authenticate strongly the user can’t be used by the ASPSP to collect the user consent to give access to its account to the TPP. Without any contractual relationship between ASPSPs and TPPs, the only mean to collect the consent of the user is based on its strong customer authentication by the ASPSP.
- Regarding server mutual authentication process, e-IDAS can be used for the server seal with a sufficient level.
- For signature services for instance, e-IDAS define precisely levels that could be used by all parties.
- As far as authentication is concerned, 3 levels are defined depending on specific criteria. SCA requires a certain level of certificates. ASPSPs have to keep the possibility to apply their risk policy when performing SCA, of which certificates represent one authentication mean. At a minimum it has to be consistent with the e-IDAS substantial level.
We would like to underline the fact that e-IDAS has never thought to take into consideration the case of the transmission of credentials delivered by an ASPSP via a third party.
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 examples provided for in Article 97(1)(c) appear to be comprehensive enough. There seems to be no need of additional examples of transactions or actions implying a risk of payment fraud or other abuses to be considered in the forthcoming RTS.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?
Below are examples of devices that are currently used or that could be used in the near future, and that are considered as appropriate in the context of strong customer authentication (SCA): Mobile phones, tablets, computers, connected devices etc., to be enrolled within the ASPSP
Dynamic token devices (i.e. RSA key, Vasco token, etc.) and static token devices (e.g. a certificate), both issued by a Certification Authority, which is part of a Public Key Infrastructure.
Possession elements can be data but there need to be a link with a physical form (what I own). This means that the PSU will always use a device to access the data.
Upon the enrolment by the ASPSP, the device needs to be registered: a single specific authentication key is delivered by the ASPSP and is uploaded on the device of the PSU.
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 behaviour-based characteristics understood as behavioural biometrics such as keystroke, mouse usage, and tablet position, may strengthen the SCA adding “inherence” elements. The sole scoring related to connection habits or purchase habits is clearly not sufficient in the context of “inherence” elements to process a SCA.The use of behaviour-based characteristics should be left at the sole discretion of the ASPSP.
The RTS should neither forbid the use of behaviour-based characteristics nor make them mandatory.
.
More generally, we consider that the confidence in the overall system of SCA should be in line with state- of- the-art standards defined by an independent accredited body (cf. title 2 of EBA internet security payments guidelines regarding supervision).
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)?
There are obviously challenges.Total independence of the authentication elements used can never be ensured, the PSU being able to decide which device to use, i.e. a clear increase in the usage of mobile devices today.
To tackle those challenges regarding the use of a mobile device by the customer, the following requirements should be made mandatory:
A prior enrolment of the user’s devices shall be processed when he/she enters in relation with his/her ASPSP; the quality of this enrolment being key to give to the ASPSP the capability to link securely and efficiently the elements allowing to process a strong customer authentication. (cf. the SecurePay Forum draft regarding security guidelines on mobile payment)
Each of both elements should be processed independently, through 2 different channels, for example internet network and mobile network
Moreover, there is a challenge regarding the independence of the authentication elements on a mobile device, which shall generate a reinforced fraud management policy. This fraud management will require detailed information on the associated payment environment: the device that is used, and the context usage.
It results that the processing of a transaction (account information or payment initiation services) through a TPP should not remove the capability for the ASPSP to have a direct access to the PSU in order to process its strong customer authentication, even if the TPP relies on the authentication procedures provided by the ASPSP.
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
‘Dynamic linking’ relates to electronic remote payment transactions as stated in Article 97.For users, we consider the 3DS process existing in payment cards provides this dynamic linking: today a dynamic code issued by the ASPSP is sent to the PSU, who enters it to finalize his/her payment knowing the amount and beneficiary, and hence validate the true amount and beneficiary.
A similar process is currently used to finalize SCT payments: if the payment is considered sensitive, a dynamic code issued by the ASPSP is sent to the PSU, who enters it to finalize his/her payment, hence validating the true amount and beneficiary.
In both cases, this could be considered as the relevant information of the payer on the specific transaction.
If not, some ASPSP’s payment infrastructures would have to be upgraded to further dynamically link the code to the beneficiary and amount of the transaction, sealing the payment signature. This could require more than 18 months to develop and implement for some actors.
For corporate bodies and governmental agencies, the strong customer authentication is performed in a specific way: for instance corporate bodies does no validate each transaction but the whole file with the summary of all their transactions. The dynamic linking shall only be done with the file.
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
There are existing solutions such as OTP (one time password delivered by a token independent from the mobile , such as RSA key, Vasco token, etc., or by SMS) or OOB (out of band) which fulfil both the objectives of independence and dynamic linking. If the independence of the authentication elements on a mobile device is combined with adequate fraud management, this fraud management would require detailed information on the associated payment information, used device and context usageIt results that the processing of a transaction (account information or payment initiation) through a TPP should not prevent the ASPSP to have a direct access to the customer’s device to process its strong customer authentication, even if the TPP relies on the authentication procedures provided by the ASPSP.
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
Clarifications suggested are useful.However, as SCA is made mandatory under PSD2, we understand that ASPSPs have the responsibility to perform systematically a SCA to ensure the security of transactions.
Our understanding is also that potential exemptions to SCA are being considered by the EBA, which makes the implementation by the ASPSP of such exemptions possible but not mandatory (art. 97).
The exemption list proposed in the EBA discussion paper seems to come directly from the EBA guidelines on Internet payments such as listed below:
a) low value payments,
b) white beneficiaries lists to be stated by the customer (which is to be maintained by the ASPSPs)
c) transfers between two accounts on the same PSU held at the same PSP,
d) low risk transaction based on a transaction risk analysis ,
e) purely consultative services,
f) This list has to be completed as follows: Instalment payments, where only the first transaction should be based on the SCA
And amended as follow:
the criterion b) “white beneficiaries lists to be stated by the customer, (which is to be maintained by the ASPSPs)” has to be deleted from the criteria exemption list knowing that if a white list could be a criterion of acceptation of beneficiaries, it couldn’t be a criterion of exemption of SCA.
We would like to point out
I) Regarding low value payments, that online low value payments made by SCT may represent some risk and do not mean low level of fraud. ASPSPs are currently facing daily massive frauds on electronic payments (for instance online music purchase).
NB: It has to be underlined that it is different for low value payment processed “over the air” transaction like NFC transaction where the customer is present with his card.
NB: Regarding specifically the ‘’low risk transaction based on a transaction risk analysis’’, we suggest to make it broader in order to encompass the account access. We would prefer to have ‘’low risk transaction and account access based on a risk analysis performed by the ASPSP’’.
Moreover, a definition of low value payments would be appreciated as today there seems to be different definitions.
In addition, RTS should provide a specific definition for contactless payment.
II) Regarding ‘’consultative services’’:
- As there is no definition of what “purely consultative services are, we would like the RTS to clarify this notion with use cases, make it more explicit and define it.
In our understanding “purely consultative services” can only apply to the PSU, and not to the TPP which will request the consultation plus transmission of data.
Furthermore we suggest that the RTS provides clarification on the sensitive payment data (art. 4) with examples on data that are considered sensitive. As the account number and the name of the beneficiary are not sensitive for TPPs, they should also be considered not sensitive for ASPSPs in order to ensure a level playing field.
- As a best practice the RTS would have to recommend the use of strong customer authentication when the AISP accesses the account for the first time. This will allow the ASPSP to get the required explicit consent of the PSU and his acknowledgment of which accounts to be accessed by the TPP. After a certain period depending of the ASPSP’s own risk management policy (i.e. risk detection, new device used by the customer …) or in case of a modification of the list of the accounts to which the AIS can have access, the ASPSP may request another strong authentication of the user.
- In terms of workflow, it is unclear how the ASPSP will know when the user wants to stop using the services offered by the AISPs.
We take the above exemptions - points a) to f) - into consideration in a context of direct relationship between PSU and ASPSP, however we question their application in case of the use of a TPP. We would like indeed to point out 4 major items.
1) In a context of a purchase made by the PSU via a mobile device and a payment subject to SCA exemption, made by a TPP, the ASPSP still needs sufficient information on the customer’s environment to perform its risk analysis, exactly as in the case of a direct access, with or without a SCA performed. The introduction of TPP in the process, should never reduce the quality / strength of the authentication compared with the authentication already performed by the ASPSP towards its PSU.
As a result, the ASPSP should be able to access directly the PSU’s device via a dedicated and direct connection in order to apply its own appropriate risk-based analysis, which shall be processed, independently from any risk analysis that may be performed by the involved TPP. The ASPSP has to be absolutely sure that the customer is the right one, and that he gives its consent to the transaction.
2) If against our understanding, such exemptions to SCA are made mandatory by the RTS, and if there is no direct connection between the PSU’s device and the ASPSP for sake of performing SCA in case of transactions via a TPP, then the ASPSP has no way to perform its risk analysis and to comply with its obligation to perform a complete SCA. This should logically result in a shift of liability from ASPSP to the TPP.
In case of SCT transaction, the PISP will have to provide the beneficiary IBAN. The ASPSP will have to rely on this information, which will be the only one (alongside with the name) known on the beneficiary. The PISP will have to provide the ASPSP with the information required for the correct execution of the transaction, included the finalisation of all controls needed.
3) The ASPSP shall have the capability to decide whether to apply the SCA exemptions (management of its own risk on the basis of its risk policy).
If not, it would have as a consequence that if the ASPSP requires a SCA but can’t perform it, the transaction can be rejected unless there is a liability shift to the PISP.
4) In the context of exemption to SCA and in the absence of dispute resolution rules, the forthcoming claims on remote SCT payments wouldn’t be addressable in an industrial manner. However a serious risk of a significant rise of claims exists, a minima as what is foreseeable for card remote payments. New remote payments methods, less secure than card payments, risk to be very attractive for fraudsters, especially when a TPP is involved. The number of fraud cases will increase along with fraudsters’ taking advantage of the context of SCA exemptions. A comprehensive framework is necessary to address the forthcoming customers’ claims.
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
If, to the contrary to the provisions of the PSD2, the RTS allow the TPP to decide to apply SCA exemptions, and if consequently the ASPSP is not in a position to perform its own risk analysis, then it should be acknowledged that it implies a liability shift from the ASPSP to the TPP.We believe that the evaluation of the customer risk belongs to the own risk policy of each ASPSP. So, even if an exemption is requested, the ASPSP must be allowed to process a SCA (e.g. one every x payment, or one at random.)
Again, a framework (or a minima a set of requirements) should be developed to address the forthcoming customers’ claims and secure the customers against fraud.
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?
We recommend to also consider corrupted devices (for instance a device with jailbreak or root access) as a complement to the risks set forth in paragraph 45.A risk based analysis should be developed, if not already done, by the ASPSP, which could lead or not to a SCA. In case of a transaction via a TPP, the ASPSP could miss key elements such as the one listed in paragraph 45 a;b;c.
This information would have to be requested by the fraud detection module which could be accessed in any API settled to process payment transaction, even if a TPP is involved in.
10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
Suggested clarifications are useful, however a key phase appears to be missing. The revocation phase should indeed be added to paragraph 52.iToday when using the PSU’s personalised security credentials (PSC) a TPP access to the whole online banking of the PSU, includes sensitive information as well as information not needed by the TPP to address its client’s needs. For both reasons, it is necessary to strongly protect the PSU's PSC.
So, we would like to recall that personalised security credentials are keys in the SCA process. Nevertheless this wording encompasses a very wide notion.
Art. 67.2b and 66.3b seem to be ambiguous: will TPPs have access or not to the PSUs’ security credentials
The suggested clarification regarding the protection of users personalised security credentials seems to be appropriate but is not sufficient enough.
As stated in Article 67b, TPPs shouldn’t have the right to access the PSUs’ personalised security credentials. But Art. 67.2b and 66.3b are ambiguous, RTS will definitively have to specify this topic.
Critical risks currently exist relating to the confidentiality and the integrity of users’ personalised security credentials when a TPP is involved in a transaction and as a consequence in the trust chain.
TPPs shouldn’t have the right to access the PSUs’ personalised security credentials as stated in Art 67 b.
RTS will definitively have to specify this topic and should be more specific on the protection of PSU’s personalised security credentials. The RTS should clearly state that the PSU has to authenticate himself with the authentication method of his ASPSP inside the ASPSP's environment during the transaction phase. That will prevent any disclosure of the PSC to any third party. It is worth reminding that in case the PSC are compromised while being used for another purpose than the one for which they were established (i.e. access to online banking), these PSC will need to be changed for all purposes (online banking, aggregation services, payment initiation ...).
More specifically (referring to paragraph 51 E of the discussion paper), French banks strongly recommend that PISP do not have access to the PSC at any time during the payment process. They do not need this information to require the ASPSP to initiate a payment. They would favour solutions where the PSU is redirected by the PISP to the ASPSP's authentication module and authenticated himself in the ASPSP's secure environment. The benefit for the PISP lies in the fact that it won't have to develop and maintain secure processes to access, transmit and store sensitive data.
Moreover a key question has to be addressed: How can the user identify that the TPP is the correct one?
TPPs will have to be registered in the EBA register. As the market develops, phishing attacks may increase and TPPs may be hacked. PSUs may then lose confidence when accessing a TPP’s interface as they are not able to distinguish a genuine TPP’s interface from a fake one.
As the market develops, how will this process be supervised? This needs to be specified by the RTS.
Moreover there should be an evaluation to insure a good level of confidence in the overall system. This evaluation should be performed by an independent accredited body and state of the art standards should be referred to.
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
Major risks are detailed above. Critical risks currently exist relating to the confidentiality and the integrity of users’ personalised security credentials in the context of disruption of the trust chain when a TPP is involved in a transaction. How can the PSU identify that the TPP is the correct one?Risks are identified but would be amplified if all the requirements currently existing on ASPSPs did not apply equally to TPPs (risk assessment, incident monitoring, safeguard processes, etc. – cf. EBA guidelines on the security of internet payments, etc.).
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?
There are currently open standards available on the market, such as https or a value added messaging system as the SEPAmail open standard.Key questions remain the same: What does the enrolment process encompass? Which are the actors in place? Are we talking about customer-to-ASPSP enrolment? TPP-to- ASPSP enrolment?
ASPSPs have their own innovative and secure solutions for remote customer enrolment into the bank process. As of today, it is not designed for TPP involvement in the process.
Frameworks such as OAuth 2.0 precisely aim at securing the transmission of the client's consent to access its resource without compromising its online banking credentials. To do that OAuth introduces an authorisation layer in which a third-party app is issued by the server which hosts the client's resource (e.g. the ASPSP) a dedicated set of credentials. Other common and innovative protocols will probably emerge in the coming years to address the future challenges. That reinforces the need for the EBA to remain technology neutral in order to be compatible with the coming new open and common standards.
In paragraph 52, the EBA addresses two different issues concerning the enrolment:
1- Enrolment of the PSU by the ASPSP (§A to D)
2- Access of the data by TPP in the course of a payment service (§E).
The first issue is been addressed for years by ASPSP, that have implemented elaborate processes to limit fraud during the enrolment phase, even in the case of digital communication channels.
As mentioned in the answer to question 10, French banks strongly recommend that TPP do not access to the personalised security credentials at any time during the payment process. They do not need this information to request the ASPSP to initiate a payment.
They would favour solutions where the PSU is redirected by the TPP to the ASPSP's authentication module and authenticates himself in the bank's secure environment. The benefit for the TPP lies in the fact that it won't have to develop and maintain secure processes to access, transmit and store sensitive data.
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?
As such, we do not identify alternatives to certification or evaluation by TPP of component payments solutions or mobile devices.There are existing open standards on the market such as SEPAmail, whose one key component is a common PKI (public key infrastructure) allowing interoperability and a secure and harmonized marketplace among PSD2 actors.
In the early 2010s, the client had to share its credentials with the TPP to access its resources, what created numerous problems and limitations. As the number of web services and mobile apps requiring the creation of a user account by the client, new protocols and frameworks have being designed by the IT international community to address the issue of third parties applications accessing restricted resources. OAuth 2.0 is an example of such frameworks. As stated in the RFC6749, such practices are deemed to be unsecure:
- Third party applications are required to store the resource owner's (PSUs) credentials for future use, typically a password in clear-text;
- Third-party applications gain overly broad access to the resource owner's protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources;
-Resource owners cannot revoke access to an individual third party without revoking access to all third parties, and must do so by changing the third party's password.
Consequently the state-of-the-art practices do not rely on credentials sharing. If sharing credentials was quite common when the draft PSD2 has been written, that is no longer the case. The EBA should take the fact into account.
Moreover, as explained before state-of-the-art practices evolve quite quickly in the market. This fact strengthens the necessity for the EBA's rules to be technologically neutral to adapt to the future standards and best practices of the 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?
Critical risks currently exist relating to the confidentiality and the integrity of the users’ personalized security credentials in the context of the disruption of the trust chain when a TPP is involved. How can the user identify that the TPP is the correct one?Art. 67.2b and 66.3b are ambiguous: TPPs should not have access to security credentials. RTS will have to specify this topic.
In the future, TPPs will have to be registered in the EBA register. As the market develops, phishing attacks may increase TPPs can be hacked and, the PSUs may then lose confidence when accessing TPPs’ interface, as they are not able to distinguish a genuine TPP’s interface from a fraudster. As the market develops, how will this process be supervised?
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?
A centralized body at EU level would a way to:- ensure a PKI (public key infrastructure) for a proper and mutual authentication between TPP and ASPSP
- define common standard and ensure the shared evolution of the common rules
- define the minimum level of security
- harmonized implementation and evolution
An open standard means accessibility on the contrary to a proprietary standard. Everybody can use it freely.
We globally support open and common standard widely shared and used by a majority of entities such as W3C
Globally the level of details that is provided does not allow a practical and precise implementation of a secure communication between ASPSP and TPP.
a) Definition of standards
For corporate bodies there seem to be no need for recommendations of standards by the EBA as corporate bodies and banks are currently using open, common and secure standards, such as EBICS.
Regarding security standards, it is not sufficient to have neither ‘open’, ‘common’ and ‘standards’: ASPSPs cannot accept low level of norms (for instance SSL v1 is not acceptable, and everyone should use at least SSLv3/TLSv1) and should be able to decide the adequate level of standards to be used, such as RFC6749.
Some type of governance should be in place to ensure shared evolution of the common rules.
b) The way TPP identified themselves to ASPSP
TPP should be duly registered by national regulators with the description of the services that are proposed (PIS, AIS).
Then TPPs have to identify themselves towards the ASPSPs as required in art. 67.2.c.
For sake of authentication, we recommend either a centralized PKI maintained by a central body at EU level or a European federation of domestic certification authorities, or at least a list of certification authorities with a common level of quality (duly registered and accredited), to ensure a level playing field.
If there is no PKI, the trust in the TPP couldn’t be insured out of the request of the signature of bilateral contracts within TPPs and ASPSPs, and the risk in fine of a fragmentation of the market.
c) The way PIS, AIS, and ASPSPs communicate with each other’s and with the PSUs should be based on common, open and secure standards
d) As the workflow is not known yet, it is difficult to address this question. Clear governance appears to be vital. Functionalities should at least encompass the strongly authentication of the TPP by the ASPSP and for AIS, the PSU’s consent to access to the account. RTS should not go beyond what PSD2 outlines (for instance in article 66.4.b for PIS).
e) The minimum security controls should at least encompass the preservation of the confidentiality and integrity of data during of the exchanges, evidence management and traceability of the user device elements regarding fraud management. Automatic delegation of SCA should in no way be defined as a rule by EBA.
f) Regarding technical requirements: Without any contract or framework management, there could not be any service level requirements imposed by the RTS.
As TPP will benefit from the same level of service as PSUs, ASPSP should expect the same behaviour from a TPP than a PSU. This assessment, refers to the ‘’user thinking time’’, and avoid any batch or robot treatment.
To ensure a better service to the end-users, we recommend the RTS to define exchange limits in terms of volumetric to avoid any risk of denial of service and potentially any discrimination. Such requirements are defined on existing infrastructures (i.e. STET). In France the daily operation of some ASPSPs’ online banking services were seriously disrupted due to unexpected peaks of TPPs requests.
NB: PSUs are expected to give explicit consent for each TPP they choose to use. This may lead to the creation of filters of TPP in the PSU’s online banking at the request of the PSU
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?
Governance is expected by ASPSPs to ensure a space for the actors to exchange and implement the PSD2 in a harmonized way.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?
There are existing open standards, for instance open standards of value added messaging system such as the SEPAmail standard whose key component is a common PKI (public key infrastructure) allowing interoperability and a secure and harmonized marketplace among PSD2 actors.New protocols such as OAuth 2.0 do take into account the privacy dimension in so that the client defines the set of resources that the third party app can access to deliver its own service. On the contrary to the current practice of aggregators, where they can access to the whole online banking, these new frameworks respect the principle of privacy by design.
They also foresee the registration of the TPP by an authorization server before accessing the resources of the client. Different methods can be used to accomplish this step, but in any case the TPP has to provide information to the authorization server (such as application name, description, acceptance of legal terms...).
In our view, other existing standards seem as of today appropriate and relevant, such as for instance TLSv1.2 or EBICS TS.
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)?
Future requirements that will be defined by EBA need to be as open and evolutive as possible to encompass further innovation.Such requirements should also be compatible with existing solutions that are already secured (i.e. EBICS TS for instance).
What are the other innovative business models, other than PIs and PIS, which are suggested?
Open standards such as SEPAmail for instance could be the appropriate answer as open standards allow any type of interfacing, with existing or new frameworks. Once again, in our view, other existing standards seem as of today appropriate and relevant, such as TLSv1.2 or EBICS TS.
It has to be mentioned that a solution implying the issuance by the PIS or AIS of their own credential to authenticate strongly the user can’t be used by the ASPSP to collect the user consent to give access to its account to the TPP. Without any contractual relationship between ASPSPs and TPPs, the only mean to collect the consent of the user is based on its strong customer authentication by the ASPSP.
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.
As e-IDAS regulation specifies principles and requirements regarding identity and authentication levels, it represents an opportunity for European customers to benefit from harmonized principles of identification and authentication all over Europe.- Regarding server mutual authentication process, e-IDAS can be used for the server seal with a sufficient level.
- For signature services for instance, e-IDAS define precisely levels that could be used by all parties.
- As far as authentication is concerned, 3 levels are defined depending on specific criteria. SCA requires a certain level of certificates. ASPSPs have to keep the possibility to apply their risk policy when performing SCA, of which certificates represent one authentication mean. At a minimum it has to be consistent with the e-IDAS substantial level.
We would like to underline the fact that e-IDAS has never thought to take into consideration the case of the transmission of credentials delivered by an ASPSP via a third party.