Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
In fact, we can observe some trade-offs between a higher level of security and customer experience. For instance, from a customer’s point of view, the segregation of channels – which should give more security to the payment service user (PSU) - justified by rationale no. 26 and article 2.2.b. could be interpreted as excessively burdensome and may negatively affect customer experience.
Please find below our comments on specific rationales and resultant provisions:
Rationales 20, 21 and 40: UniCredit is of the view that the limited scope of the SCA exemptions included in the RTS may inhibit the development of low-risk payment solutions in the years to come, to the detriment of consumer’s convenience.
Rationales 17 and 18: according to rationales 17 and 18, the remote initiation of a “Direct Debit” is not subject to SCA, irrespectively of the amount of the credit or the type of creditor. Even the exemptions as per article 2.2 are not relevant for Sepa Direct Debits (SDD) initiations, since they do fall into any of the explained categories.
In our interpretation, the RTSs seem to assume that before each single remote SDD initiation, an e-mandate should be given by the PSU, which is – in any case – subject to SCA as it falls under the scope of article 97.1.c of the Payment Services Directive 2 (PSD2).
In case of a reimbursement asked by a PSU, the creditor shall reimburse the PSU, if no mandate can be presented by the creditor himself within 13 months after execution of an unauthorized initiated SDD. This is because the burden of proof to present a SDD-mandate (paper or e-mandate) as evidence is on the payee/creditor.
In our view, this proposed provision, as it is, could provoke a possible shift from remote payment initiations (with very prescriptive and strict exemption-rules) into the initiation of remote SDD (with a general exemption of SCA and no obligation of an e-mandate). The impact of such shift is that the management of the risk could be transferred from a regulated Payment Services Provider (PSP) to a non-regulated payee/creditor.
In addition, we are of the view that these rules are not guaranteeing fair competition. In fact, SDD-based payment systems for remote payment can be managed on risk-based principles, however SCT-based remote payment must follow strict exemptions, which are reducing the option of developing convenient and modern remote payment solutions for the benefit of the consumers.
Rationale 22 and Article 1.3.e: according to Article 1.3.e, “… strong customer authentication procedure SHALL include mechanisms to prevent, detect and block fraudulent payment transactions …”. In our view, this article goes beyond the mandate conferred to the EBA by article 98.1.c. of the PSD2, according to which the task assigned to the EBA is only to protect “the confidentiality and the integrity of the personalized security credentials”. Also, such inclusion is not needed because “antifraud mechanisms to prevent, detect and block frauds threats” are already included in the antifraud engine, the monitoring and the alerting systems. We recommend the following amendment to the wording of article 1.3.e: “strong customer authentication procedure MAY include mechanisms to prevent, detect and block fraudulent payment transactions …”
Rationale 19a and Recital 10: UniCredit is of the view that recital 10 does not adequately reflects the logic expressed in rationale 19a.
According to rationale 19a, the Payment Initiation Services Providers (PISPs) “have the right” to rely on the authentication procedures provided by the Account Servicing Payment Services Providers (ASPSPs); while recital 10 establishes that the communication interface (which should be set up by the ASPSP) “should” allow PISPs to rely on the authentication procedures – provided by the ASPSP. We recommend that rationale 19a should be well reflected in recital 10. It should be clearly stated that TPPs “must” rely on ASPSPs’ authentication procedures, in order to minimize the risk of fraud and unauthorized transactions.
Specifically, since the consultation paper differentiates the PSD2 Art. 97.1 and Art.97.2, we suggest to clarify if the principle of “dynamic linking” stays valid in the case of initiation of a remote payment transaction, irrespectively of the fact that SCA is exempted or not.
Article 8: in our view, the wording of the provisions regarding the exemptions seem to oblige ASPSP to apply such exemptions. In our view, ASPSP should be free to decide whether or not to apply the exemption to a specific type of transaction. That would mean that a ASPSP would be free - based on a risk-degree assessment of the situation - to apply the SCA even in cases where the criteria for the application of the exemptions are met. This would allow ASPSPs to handle their own risk efficiently.
UniCredit has some observations also in relation to article 8.1.a, with regards to the exemptions of SCA when the customer accesses exclusively the information of its payment account online, without disclosure of sensitive payment data.
UniCredit agrees with the provision (i), which does not exempt SCA for “the first access” of the customer. However, we recommend to eliminate point (ii) that makes reference to time or event-based logics. For instance, some typical situations in which the “30-day scenario” could be applied and where the exemption of SCA should be allowed are the following:
1. a customer is being requested to insert his SCA for login. From her/his perspective, it is not clear why “sometimes she/he has to provide SCA and sometimes not”, since she/he is unable to track the last time he logged in;
2. a customer who usually uses only consultative services (e.g. check for balance of her/his current account or credit cards outstanding balance) accesses the web to view some information related to her/his account (so-called “info-only customer”); she/he is not used to insert his SCA for login on a regular basis and may find difficult to provide his SCA (again on a non-regular basis).
Hence, it would be preferable if the ASPSP could rely on risk-based counter measures to protect the PSU data without impacting their own customers. This approach would avoid confusion from customer’s perspective.
Articles 8.1 b (i) and 8.2.d (i): thresholds for SCA exemption should be the same for contactless electronic payments at the point of sale and remote electronic payment transactions.
We recommend that no threshold differentiation should be made, since it could create confusion for customers. Hence, we support the introduction of a single thresholds at 50 euro for each type of transaction.
Article 8.2.: in our view, the inalterability of the payee’s account can be guaranteed by the PSP, when a list of trusted beneficiaries is available, regardless of whether the list is generated by the payer or by the PSP itself from a secure repository from which the PSU can choose when initiates a payment.
We recommend that the scope of Article 8.2(a) should be extended to a “trusted beneficiaries list” also created or provided by the ASPSP. ASPSPs can have a white list in their internal systems of payees that are considered very safe (e.g. energy or gas providers).
Hence, UniCredit would like to draw attention to the unbalanced allocation of responsibility/liability, as well as to the implementation costs between ASPSP and TPPs. In fact, the implementation costs, of both communication interface and the (recently added) testing facility, will have to be borne exclusively and entirely by the ASPSP. Furthermore, the responsibility of the well-functioning and the security of both requirements will again fall on the ASPSPs.
In fact, according to RTSs proposed article 19.7, the ASPSP has to make available a testing facility of the abovementioned communication interface, including support, for connection and functional testing to test their software and applications, before starting to be used for offering payment services (e.g. TPPs) to users.
Hence, the ASPSP shall be responsible for the security and continuous availability of both the communication interface and the testing facility. In our view, the requirement of a testing facility represents an additional burden in terms of liability/responsibility and implementation costs for the ASPSPs. In order to provide a safe test environment, the testing facility has to ensure the same level of security as the communication interface, thus it becomes a new channel which increases the risk of exposure to frauds and cyber-attacks.
Furthermore, according to articles 19.4 and 19.5, it is on the responsibility of the ASPSP to document and make publicly available all technical specifications, as well as announcing any changes related to the communication interface no less than three months before its implementation. In our understanding, this would include decommissioning or shutting down, and software deprecation of the communication interface.
Hence, we believe that the RTSs oblige ASPSPs to sustain remarkable responsibilities as well as relevant costs for implementation. In our view, these requirements seem excessive considering that TPPs will benefit from such a situation without investing any economic resources to set-up the safe environment. In addition, TPPs will rely on the authentication procedures provided by the ASPSP to the users, avoiding any responsibilities and costs arisen from such service.
We recommend that responsibility and costs between ASPSPs and TPPs should be shared as fairly as possible, considering the increased risk of exposure for the ASPSP that would derive from setting up an additional channel (testing facility), publishing the technical specification of the communication interface and providing technical support.
Indeed, the provision of those support services would require the ASPSP to be structured and properly organized to perform such activities, which we deem as a burdensome responsibility.
Articles 19.2 and 19.2.b.: according to article19.2.a., “the communication interface shall: enable PISPs and AISPs to “start the authentication procedure”; also article 19.2.b. refers to: “ …the authentication procedure”. In our view, it is not clear what “authentication procedure” these articles refer to, given that the “authentication” is usually part of the initiation process.
We suggest that if this wording refers to a specific kind of “authentication” procedure, ASPSPs should be free to develop their own procedures without excessive prescriptive provisions introduced that would make the procedure very restrictive from a technical point of view.
Article 22: according to Article 22.1.a, ASPSPs shall provide Account Information Service Providers (AISPs) with the “same information from designated payment accounts and associated payment transactions, as it is made available to the user when accessing the information online, excluding all sensitive payment data”.
We recommend to clarify the meaning of “same information”. We deem important that information from our customers that is not useful for the purposes of AISPs should be maintained as safe and private as possible.
Furthermore, we would deem important to convey the EBA attention on a point of high concern for the possible implications in terms of data exchange and the allocation of the responsibility related to the following situation: when a TPP accesses the ASPSP system, it goes to hide/override the characteristics of the user’s connection (e.g. IP number, fingerprint,…), which are essential data for the antifraud system. In fact, without this user info, antifraud system from the ASPSP (bank) may not be able, for example, to detect and alert fraud deriving from phishing.
According to article 66 and 68.5 of the PSD2, the ASPSP (bank) may deny a TPP access to a payment account for objectively justified and duly evidenced reasons; however in case of user connection info overriding deriving from a TPP’s access, the ASPSP (bank) may not have all necessary information to raise that evidence.
According to article 73.1 of the PSD2, the reimbursement is within a working day, unless the “ASPSP (bank) has reasonable reason to suspect fraud (and communicate these reasons in a written format)”. However the ASPSPs (bank), in case of user connection info overriding deriving from a TPP’s access, may not have all information needed to declare a fraud.
Hence, we recommend to take into consideration in the “data exchange” section (art. 22 of RTS) also the case above mentioned, regarding the user information that may be overwritten by a TPP access.
In addition, from a mere technical point of view, the standard expected for the exchange of messages by ISO 20022 is XML. If the expected channel for PSD2 will be an API, XML could be a limit for developers. JSON Technology ensures a better interoperability with external systems and better performances.
However, the EBA should take into account, that the these standards are amended to satisfy the needs of the ASPSPs i.e. identifying PSPs by its type, registration number and registration authority within the website certificate. For instance, ETSI 319 412-1 v.1.1.1 and the definitions of the element id-etsi-qcs-SemanticsId-Legal need to be amended with the acronyms “PIS” and “AIS”.
Also, we suggest to include in the RTS a reference to the e-IDAS Annex II or equivalent regulations.
Article 20: first, in our view, ASPSPs should not be responsible for the authentication of PISPs and AISPs against the ASPSPs via a qualified certificate.
In fact, it is important that qualified trust service providers (QTSPs) are duly registered and that competent authorities make this registry available to match as much as possible with the application date of PSD2. Also, it should be important that QTSPs have their part on liability in case of fraud or any other violation. Finally, besides the sole use of a quality certificate, it should be necessary to include a specific attribute issued by a trust-center (according to e-IDAS Regulation), in order to identify when a Third Party is legally registered by the authorities.
Secondly, for the purpose of identification, RTSs oblige Payment Services Providers to rely on qualified certificates for website authentication.
We suggest to clarify if qualified certificates will be also allowed for APIs (application programming interface).
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?
UniCredit agrees with the reasoning provided by the EBA on the requirements of the strong customer authentication (SCA). Nevertheless, UniCredit is of the view that some provisions should be reconsidered, in order to meet the Industry needs and to limit the negative impact on customer experience.In fact, we can observe some trade-offs between a higher level of security and customer experience. For instance, from a customer’s point of view, the segregation of channels – which should give more security to the payment service user (PSU) - justified by rationale no. 26 and article 2.2.b. could be interpreted as excessively burdensome and may negatively affect customer experience.
Please find below our comments on specific rationales and resultant provisions:
Rationales 20, 21 and 40: UniCredit is of the view that the limited scope of the SCA exemptions included in the RTS may inhibit the development of low-risk payment solutions in the years to come, to the detriment of consumer’s convenience.
Rationales 17 and 18: according to rationales 17 and 18, the remote initiation of a “Direct Debit” is not subject to SCA, irrespectively of the amount of the credit or the type of creditor. Even the exemptions as per article 2.2 are not relevant for Sepa Direct Debits (SDD) initiations, since they do fall into any of the explained categories.
In our interpretation, the RTSs seem to assume that before each single remote SDD initiation, an e-mandate should be given by the PSU, which is – in any case – subject to SCA as it falls under the scope of article 97.1.c of the Payment Services Directive 2 (PSD2).
In case of a reimbursement asked by a PSU, the creditor shall reimburse the PSU, if no mandate can be presented by the creditor himself within 13 months after execution of an unauthorized initiated SDD. This is because the burden of proof to present a SDD-mandate (paper or e-mandate) as evidence is on the payee/creditor.
In our view, this proposed provision, as it is, could provoke a possible shift from remote payment initiations (with very prescriptive and strict exemption-rules) into the initiation of remote SDD (with a general exemption of SCA and no obligation of an e-mandate). The impact of such shift is that the management of the risk could be transferred from a regulated Payment Services Provider (PSP) to a non-regulated payee/creditor.
In addition, we are of the view that these rules are not guaranteeing fair competition. In fact, SDD-based payment systems for remote payment can be managed on risk-based principles, however SCT-based remote payment must follow strict exemptions, which are reducing the option of developing convenient and modern remote payment solutions for the benefit of the consumers.
Rationale 22 and Article 1.3.e: according to Article 1.3.e, “… strong customer authentication procedure SHALL include mechanisms to prevent, detect and block fraudulent payment transactions …”. In our view, this article goes beyond the mandate conferred to the EBA by article 98.1.c. of the PSD2, according to which the task assigned to the EBA is only to protect “the confidentiality and the integrity of the personalized security credentials”. Also, such inclusion is not needed because “antifraud mechanisms to prevent, detect and block frauds threats” are already included in the antifraud engine, the monitoring and the alerting systems. We recommend the following amendment to the wording of article 1.3.e: “strong customer authentication procedure MAY include mechanisms to prevent, detect and block fraudulent payment transactions …”
Rationale 19a and Recital 10: UniCredit is of the view that recital 10 does not adequately reflects the logic expressed in rationale 19a.
According to rationale 19a, the Payment Initiation Services Providers (PISPs) “have the right” to rely on the authentication procedures provided by the Account Servicing Payment Services Providers (ASPSPs); while recital 10 establishes that the communication interface (which should be set up by the ASPSP) “should” allow PISPs to rely on the authentication procedures – provided by the ASPSP. We recommend that rationale 19a should be well reflected in recital 10. It should be clearly stated that TPPs “must” rely on ASPSPs’ authentication procedures, in order to minimize the risk of fraud and unauthorized transactions.
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.
Articles 2 and 8.2.d.: although UniCredit welcomes the differentiation made between articles 97.1 and 97.2 of PSD2 regarding the exemptions to the application of SCA, we believe that some points should be clarified in the final RTSs.Specifically, since the consultation paper differentiates the PSD2 Art. 97.1 and Art.97.2, we suggest to clarify if the principle of “dynamic linking” stays valid in the case of initiation of a remote payment transaction, irrespectively of the fact that SCA is exempted or not.
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?
===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?
===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?
Generally speaking, UniCredit is of the view that the list of exemptions suggested by the EBA in Chapter 2, Article 8 should not be considered as exhaustive as it is presented in the draft.Article 8: in our view, the wording of the provisions regarding the exemptions seem to oblige ASPSP to apply such exemptions. In our view, ASPSP should be free to decide whether or not to apply the exemption to a specific type of transaction. That would mean that a ASPSP would be free - based on a risk-degree assessment of the situation - to apply the SCA even in cases where the criteria for the application of the exemptions are met. This would allow ASPSPs to handle their own risk efficiently.
UniCredit has some observations also in relation to article 8.1.a, with regards to the exemptions of SCA when the customer accesses exclusively the information of its payment account online, without disclosure of sensitive payment data.
UniCredit agrees with the provision (i), which does not exempt SCA for “the first access” of the customer. However, we recommend to eliminate point (ii) that makes reference to time or event-based logics. For instance, some typical situations in which the “30-day scenario” could be applied and where the exemption of SCA should be allowed are the following:
1. a customer is being requested to insert his SCA for login. From her/his perspective, it is not clear why “sometimes she/he has to provide SCA and sometimes not”, since she/he is unable to track the last time he logged in;
2. a customer who usually uses only consultative services (e.g. check for balance of her/his current account or credit cards outstanding balance) accesses the web to view some information related to her/his account (so-called “info-only customer”); she/he is not used to insert his SCA for login on a regular basis and may find difficult to provide his SCA (again on a non-regular basis).
Hence, it would be preferable if the ASPSP could rely on risk-based counter measures to protect the PSU data without impacting their own customers. This approach would avoid confusion from customer’s perspective.
Articles 8.1 b (i) and 8.2.d (i): thresholds for SCA exemption should be the same for contactless electronic payments at the point of sale and remote electronic payment transactions.
We recommend that no threshold differentiation should be made, since it could create confusion for customers. Hence, we support the introduction of a single thresholds at 50 euro for each type of transaction.
Article 8.2.: in our view, the inalterability of the payee’s account can be guaranteed by the PSP, when a list of trusted beneficiaries is available, regardless of whether the list is generated by the payer or by the PSP itself from a secure repository from which the PSU can choose when initiates a payment.
We recommend that the scope of Article 8.2(a) should be extended to a “trusted beneficiaries list” also created or provided by the ASPSP. ASPSPs can have a white list in their internal systems of payees that are considered very safe (e.g. energy or gas providers).
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?
===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?
Articles 19.1 and 19.7: the proposed provision state that ASPSPs (i) shall offer a secure “communication interface”, accessible online, including Third Payment Services Providers (TPPs) such as payment initiation services providers (PISP) and Account Information Services Providers (AISP), and (ii) make available a “testing facility”.Hence, UniCredit would like to draw attention to the unbalanced allocation of responsibility/liability, as well as to the implementation costs between ASPSP and TPPs. In fact, the implementation costs, of both communication interface and the (recently added) testing facility, will have to be borne exclusively and entirely by the ASPSP. Furthermore, the responsibility of the well-functioning and the security of both requirements will again fall on the ASPSPs.
In fact, according to RTSs proposed article 19.7, the ASPSP has to make available a testing facility of the abovementioned communication interface, including support, for connection and functional testing to test their software and applications, before starting to be used for offering payment services (e.g. TPPs) to users.
Hence, the ASPSP shall be responsible for the security and continuous availability of both the communication interface and the testing facility. In our view, the requirement of a testing facility represents an additional burden in terms of liability/responsibility and implementation costs for the ASPSPs. In order to provide a safe test environment, the testing facility has to ensure the same level of security as the communication interface, thus it becomes a new channel which increases the risk of exposure to frauds and cyber-attacks.
Furthermore, according to articles 19.4 and 19.5, it is on the responsibility of the ASPSP to document and make publicly available all technical specifications, as well as announcing any changes related to the communication interface no less than three months before its implementation. In our understanding, this would include decommissioning or shutting down, and software deprecation of the communication interface.
Hence, we believe that the RTSs oblige ASPSPs to sustain remarkable responsibilities as well as relevant costs for implementation. In our view, these requirements seem excessive considering that TPPs will benefit from such a situation without investing any economic resources to set-up the safe environment. In addition, TPPs will rely on the authentication procedures provided by the ASPSP to the users, avoiding any responsibilities and costs arisen from such service.
We recommend that responsibility and costs between ASPSPs and TPPs should be shared as fairly as possible, considering the increased risk of exposure for the ASPSP that would derive from setting up an additional channel (testing facility), publishing the technical specification of the communication interface and providing technical support.
Indeed, the provision of those support services would require the ASPSP to be structured and properly organized to perform such activities, which we deem as a burdensome responsibility.
Articles 19.2 and 19.2.b.: according to article19.2.a., “the communication interface shall: enable PISPs and AISPs to “start the authentication procedure”; also article 19.2.b. refers to: “ …the authentication procedure”. In our view, it is not clear what “authentication procedure” these articles refer to, given that the “authentication” is usually part of the initiation process.
We suggest that if this wording refers to a specific kind of “authentication” procedure, ASPSPs should be free to develop their own procedures without excessive prescriptive provisions introduced that would make the procedure very restrictive from a technical point of view.
Article 22: according to Article 22.1.a, ASPSPs shall provide Account Information Service Providers (AISPs) with the “same information from designated payment accounts and associated payment transactions, as it is made available to the user when accessing the information online, excluding all sensitive payment data”.
We recommend to clarify the meaning of “same information”. We deem important that information from our customers that is not useful for the purposes of AISPs should be maintained as safe and private as possible.
Furthermore, we would deem important to convey the EBA attention on a point of high concern for the possible implications in terms of data exchange and the allocation of the responsibility related to the following situation: when a TPP accesses the ASPSP system, it goes to hide/override the characteristics of the user’s connection (e.g. IP number, fingerprint,…), which are essential data for the antifraud system. In fact, without this user info, antifraud system from the ASPSP (bank) may not be able, for example, to detect and alert fraud deriving from phishing.
According to article 66 and 68.5 of the PSD2, the ASPSP (bank) may deny a TPP access to a payment account for objectively justified and duly evidenced reasons; however in case of user connection info overriding deriving from a TPP’s access, the ASPSP (bank) may not have all necessary information to raise that evidence.
According to article 73.1 of the PSD2, the reimbursement is within a working day, unless the “ASPSP (bank) has reasonable reason to suspect fraud (and communicate these reasons in a written format)”. However the ASPSPs (bank), in case of user connection info overriding deriving from a TPP’s access, may not have all information needed to declare a fraud.
Hence, we recommend to take into consideration in the “data exchange” section (art. 22 of RTS) also the case above mentioned, regarding the user information that may be overwritten by a TPP access.
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?
In our view, we agree to use the standard (ISO) for interoperability on the above mentioned cases. However, its use should not be mandatory, because the ISO may imply the need of the certification, further IT implementations and an annual revision for every single PSPs, which could be really complex to achieve.In addition, from a mere technical point of view, the standard expected for the exchange of messages by ISO 20022 is XML. If the expected channel for PSD2 will be an API, XML could be a limit for developers. JSON Technology ensures a better interoperability with external systems and better performances.
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 ?
UniCredit agrees to use qualified website certificates, as qualified certificates assure the quality of identification, according to e-IDAS and the ETSI standards 319 412-1 to -5 v.1.1.1.However, the EBA should take into account, that the these standards are amended to satisfy the needs of the ASPSPs i.e. identifying PSPs by its type, registration number and registration authority within the website certificate. For instance, ETSI 319 412-1 v.1.1.1 and the definitions of the element id-etsi-qcs-SemanticsId-Legal need to be amended with the acronyms “PIS” and “AIS”.
Also, we suggest to include in the RTS a reference to the e-IDAS Annex II or equivalent regulations.
Article 20: first, in our view, ASPSPs should not be responsible for the authentication of PISPs and AISPs against the ASPSPs via a qualified certificate.
In fact, it is important that qualified trust service providers (QTSPs) are duly registered and that competent authorities make this registry available to match as much as possible with the application date of PSD2. Also, it should be important that QTSPs have their part on liability in case of fraud or any other violation. Finally, besides the sole use of a quality certificate, it should be necessary to include a specific attribute issued by a trust-center (according to e-IDAS Regulation), in order to identify when a Third Party is legally registered by the authorities.
Secondly, for the purpose of identification, RTSs oblige Payment Services Providers to rely on qualified certificates for website authentication.
We suggest to clarify if qualified certificates will be also allowed for APIs (application programming interface).