Response to public hearing on the Consultation paper on the amendment of the RTS on SCA&CSC under PSD2
Go back
Today, account servicing payment service providers (ASPSPs) have a choice as to whether to utilise the RTS Article 10 exemption. However, we also note the statement in the consultation paper (in paragraph 8) that divergent approaches have led to inconsistent application of the existing voluntary RTS Article 10 exemption by ASPSPs, which has “had a detrimental impact on AISPs’ services”.
Citi believes that making the exemption mandatory is a finely balanced decision.
On the one hand, the mandatory exemption would support a greater degree of harmonisation across account information services, whether such services are provided by specialist providers or by incumbent firms such as banks. If this was the case it would be helpful if the EBA could clarify what mandatory application of an SCA exemption means in terms of the balance of liability between the ASPSP and AISP.
On the other hand, we have to be mindful of our client base – part of which tends to hold significant cash balances within their accounts, and are therefore more risk adverse to digital adoption. Although Citi is working with its clients to embrace digitisation, the Article 10 mandatory exemption would pose a barrier for some of Citi’s clients as it removes a layer of security and authentication that they expect.
On balance, we propose that the Article 10 exemption not be made mandatory in order to allow us to meet the short-medium term needs of clients while enabling future changes in line with the evolution of the expectations and risk appetite of our clients.
The consultation paper usefully clarifies, in the context of the new Article 10a (Access to the payment account information through an AISP):
• In paragraph 30, that the exemption “would only apply where the access is limited to the account balance and/or the most recent 90-day transaction history, without disclosure of sensitive payment data”. We note the point that access beyond this, for example, to sensitive payment data or to transaction history exceeding 90 days, would require strong customer authentication (SCA). We observe that this is in line with the response the EBA gave to Question 2018_4177 (https://www.eba.europa.eu/single-rule-book-qa/-/qna/view/publicId/2018_4177) as part of the Single Rulebook Q&A process.
• In paragraph 31, that SCA will still be required “for the first access to the account information through the AISP, and is renewed periodically, every 180 days”.
We appreciate that AISPs are themselves subject to certain obligations under PSD2 (including those set out in PSD2 Article 67). We also noted the EBA’s comments, made during the Public Hearing on 11 November, that the EBA has some concerns regarding AISPs’ levels of compliance with those requirements and that this will be a focus area for the EBA during 2022.
We therefore welcome the fact that, in Article 10a(3), as explained in paragraphs 32-33 of the consultation paper, the EBA has acknowledged that ASPSPs may still “revert to SCA at any time” for “objectively justified and duly evidenced reasons relating to unauthorised or fraudulent access to the payment account”. Paragraph 32 states that “in cases where ASPSPs revert to SCA on such grounds they should substantiate to their national competent authority, upon request, the reasons for applying SCA”. While this seems justified to achieve the intended safeguards and harmonisation, it is unclear how this notification process will operate and implies some form of record-keeping will be required on the part of each ASPSP. It would be helpful if the EBA could provide additional clarification, including regarding the burden of proof regarding the suspicion of fraud. We understand, from paragraph 33, that ASPSPs retain the right, in line with PSD2 Article 68(5), to deny access to a payment account in circumstances of suspected fraud. Given the importance for ASPSPs to protect customers against fraud, we would not want our right to revert to SCA to be unduly limited.
We note the proposed amendments are designed to retain the voluntary nature of the exemption in Article 10 to the separate case where the customer accesses the account information directly with the ASPSP, rather than through an AISP.
Query as to interpretation
Article 10a(2)(b) indicates that [AS]PSPs shall apply SCA where “more than 180 days have elapsed since the last time the payment service user accessed online the information specified in paragraph 1(b) through the account information service provider and strong customer authentication was applied”. We appreciate that the EBA has adapted wording contained in the current Article 10(2)(b) but the cross-reference to Article 10a(1)(b) – which purely relates to access to payment transaction information – in this context could be interpreted to mean that if the AISP is only accessing payment account balance information (Article 10a(1)(a)) renewal of SCA would not be required, even after 180 days. We wonder whether that is indeed the EBA’s intention? A similar question also arises in the case where the customer accesses account information directly with the ASPSP (as per the draft revised Article 10).
We welcome the fact that the EBA is looking to extend the timeline for renewal of SCA from every 90-days since the online information was accessed and SCA was applied to 180-days and that the same periodicity applies irrespective of whether the information is accessed by the customer directly via the ASPSP or via an AISP. We agree that this should help to ensure a level playing field.
We are supportive of the proposed 180-day timeline but would not be averse to extending it further (for example, to 9 months) or even up to the year suggested by some AISPs. As a provider of payment services to public sector, financial institution, and larger, corporate clients, as well as to consumers, we can see benefits of facilitating their access to account information through our digital channels and minimising the friction involved. This would also support the development of our own potential account information service propositions.
At the EBA Public Hearing, several AISP representatives mentioned their preference for a “consent model” although we noted the EBA’s response that, as explained in paragraph 22 of the consultation, “Articles 97(1)(a) and 97(4) of PSD2 are clear that the requirement to perform SCA also applies when an AISP, acting on the customer’s behalf, is accessing the account information.” We understand the EBA does not see it has any leeway on this from a legal or mandate perspective. However, the discussion triggered some further internal thinking on our part about the need to accommodate greater automation (for AIS but also potential PIS use cases based on variable recurring payments), which we thought it would be useful to share as it may be pertinent to consider in the context of the upcoming PSD2 review and any interactions between the EBA and European Commission on this topic.
A Payment Service User (PSU i.e. an account holder) will have a need to consent to both:
a) an AISP use-case where account information is accessed once (and only once) to perform and provide some processing or analysis of the account information to derive a one-time result, e.g., how much can I borrow for a mortgage?
b) an AISP use-case where account information is accessed on a regular basis, say daily, to automatically perform ongoing analysis or derivation of results until the PSU cancels that service.
We would propose that, in the case of (a), the PSU should satisfy SCA at the beginning, and it should only be good for a one-time access. If there is PSU consent for the AISP to access the account information a further time, then a further SCA (of the one-time variety) should be required again.
In contrast, in the case of (b), the PSU should satisfy SCA at the beginning, but the consent associated with this SCA is for an indefinite period, ceasing when the PSU revokes the consent either directly with the ASPSP, or with the AISP, who subsequently should have a mechanism to communicate to the ASPSP that the consent has been terminated.
In some respects, the current RTS Article 10 exemption, which allows for 90-days before having to seek again SCA, and which Q2 is looking to extend to 180 days, is a mechanism that doesn’t properly satisfy either use-case (a) or (b). For the former, the PSU’s intention for a one-time access can potentially be left “open” for 90 days, and for the latter there is the added friction of having to renew the consent via periodic confirmation of SCAs, which interrupts automation.
Query as to interpretation
Further, as was flagged by several speakers during the Public Hearing, some additional clarification regarding application of the 180-day ‘count’ would be welcome in terms of its initial implementation once the final revised Regulatory Technical Standards (RTS) have been published in the Official Journal.
Since the current RTS are already in force, ASPSPs will be keeping track of when SCA was last applied, whether information is being accessed directly by the customer through the ASPSP or via an AISP. Does this ‘count’ continue in the same way or does the ‘clock’ get re-set so that the 180-days begins from the date when the revised RTS apply, irrespective of when SCA was applied in the preceding period? It is particularly important to understand the requirement in view of the proposed mandatory nature of application of the exemption to access to account information when an AISP is involved.
From our perspective as an ASPSP, we think that a 6-month implementation timeframe should be considered a bare minimum and ideally it should be 12 months. The suggestion for a longer implementation period is not so much driven by the complexity of the task but rather the need to accommodate technology investment decision-making timeframes. Many organisations plan on an annual basis and the spend for 2022 will already have been set without prior knowledge of this potential additional technological change.
We note that in Article 3 of the draft Delegated Regulation amending the RTS (and as articulated in paragraph 50 of the consultation paper, the EBA has also proposed a derogation from the requirements of Article 30(4) RTS. As such ASPSPs will be “required to make available to AISPS the changes made to the technical specifications of their interfaces…at least one month ahead of their implementation”. Our understanding is therefore that ASPSPs will need to make their revised technical specifications available to AISPs at least 1 month before the revised RTS apply so, for example, if the RTS were to apply from 30 November 2022, those specifications should be available by or before 31 October. We believe this is feasible.
Q1. Do you have any comments on the proposal to introduce a new mandatory exemption for the case when the information is accessed through an AISP and the proposed amendments to Article 10 exemption?
While Citi’s Consumer Bank has had interactions with some third-party providers, our Treasury & Trade Solutions business has yet to on-board any payment initiation service providers (PISPs) or account information service providers (AISPs). Similarly, Citi Private Bank’s clients are not currently utilising these services. However, we are aware that, at an industry level, AISPs have long been raising concerns about the friction caused to their services by the 90-day re-authentication requirement.Today, account servicing payment service providers (ASPSPs) have a choice as to whether to utilise the RTS Article 10 exemption. However, we also note the statement in the consultation paper (in paragraph 8) that divergent approaches have led to inconsistent application of the existing voluntary RTS Article 10 exemption by ASPSPs, which has “had a detrimental impact on AISPs’ services”.
Citi believes that making the exemption mandatory is a finely balanced decision.
On the one hand, the mandatory exemption would support a greater degree of harmonisation across account information services, whether such services are provided by specialist providers or by incumbent firms such as banks. If this was the case it would be helpful if the EBA could clarify what mandatory application of an SCA exemption means in terms of the balance of liability between the ASPSP and AISP.
On the other hand, we have to be mindful of our client base – part of which tends to hold significant cash balances within their accounts, and are therefore more risk adverse to digital adoption. Although Citi is working with its clients to embrace digitisation, the Article 10 mandatory exemption would pose a barrier for some of Citi’s clients as it removes a layer of security and authentication that they expect.
On balance, we propose that the Article 10 exemption not be made mandatory in order to allow us to meet the short-medium term needs of clients while enabling future changes in line with the evolution of the expectations and risk appetite of our clients.
The consultation paper usefully clarifies, in the context of the new Article 10a (Access to the payment account information through an AISP):
• In paragraph 30, that the exemption “would only apply where the access is limited to the account balance and/or the most recent 90-day transaction history, without disclosure of sensitive payment data”. We note the point that access beyond this, for example, to sensitive payment data or to transaction history exceeding 90 days, would require strong customer authentication (SCA). We observe that this is in line with the response the EBA gave to Question 2018_4177 (https://www.eba.europa.eu/single-rule-book-qa/-/qna/view/publicId/2018_4177) as part of the Single Rulebook Q&A process.
• In paragraph 31, that SCA will still be required “for the first access to the account information through the AISP, and is renewed periodically, every 180 days”.
We appreciate that AISPs are themselves subject to certain obligations under PSD2 (including those set out in PSD2 Article 67). We also noted the EBA’s comments, made during the Public Hearing on 11 November, that the EBA has some concerns regarding AISPs’ levels of compliance with those requirements and that this will be a focus area for the EBA during 2022.
We therefore welcome the fact that, in Article 10a(3), as explained in paragraphs 32-33 of the consultation paper, the EBA has acknowledged that ASPSPs may still “revert to SCA at any time” for “objectively justified and duly evidenced reasons relating to unauthorised or fraudulent access to the payment account”. Paragraph 32 states that “in cases where ASPSPs revert to SCA on such grounds they should substantiate to their national competent authority, upon request, the reasons for applying SCA”. While this seems justified to achieve the intended safeguards and harmonisation, it is unclear how this notification process will operate and implies some form of record-keeping will be required on the part of each ASPSP. It would be helpful if the EBA could provide additional clarification, including regarding the burden of proof regarding the suspicion of fraud. We understand, from paragraph 33, that ASPSPs retain the right, in line with PSD2 Article 68(5), to deny access to a payment account in circumstances of suspected fraud. Given the importance for ASPSPs to protect customers against fraud, we would not want our right to revert to SCA to be unduly limited.
We note the proposed amendments are designed to retain the voluntary nature of the exemption in Article 10 to the separate case where the customer accesses the account information directly with the ASPSP, rather than through an AISP.
Query as to interpretation
Article 10a(2)(b) indicates that [AS]PSPs shall apply SCA where “more than 180 days have elapsed since the last time the payment service user accessed online the information specified in paragraph 1(b) through the account information service provider and strong customer authentication was applied”. We appreciate that the EBA has adapted wording contained in the current Article 10(2)(b) but the cross-reference to Article 10a(1)(b) – which purely relates to access to payment transaction information – in this context could be interpreted to mean that if the AISP is only accessing payment account balance information (Article 10a(1)(a)) renewal of SCA would not be required, even after 180 days. We wonder whether that is indeed the EBA’s intention? A similar question also arises in the case where the customer accesses account information directly with the ASPSP (as per the draft revised Article 10).
Q2. Do you have any comments on the proposal to extend the timeline for the renewal of SCA to 180-days?
Discussions at the Public Hearing on 11 November made it clear that some AISPs feel that the EBA’s proposed extension of the timeline for renewal of SCA – from 90-days to 180-days – still does not go far enough. However, we appreciate that, as mentioned in paragraph 42 of the consultation paper, the EBA is trying to find a balance that limits the amount of friction in the process while also protecting consumers.We welcome the fact that the EBA is looking to extend the timeline for renewal of SCA from every 90-days since the online information was accessed and SCA was applied to 180-days and that the same periodicity applies irrespective of whether the information is accessed by the customer directly via the ASPSP or via an AISP. We agree that this should help to ensure a level playing field.
We are supportive of the proposed 180-day timeline but would not be averse to extending it further (for example, to 9 months) or even up to the year suggested by some AISPs. As a provider of payment services to public sector, financial institution, and larger, corporate clients, as well as to consumers, we can see benefits of facilitating their access to account information through our digital channels and minimising the friction involved. This would also support the development of our own potential account information service propositions.
At the EBA Public Hearing, several AISP representatives mentioned their preference for a “consent model” although we noted the EBA’s response that, as explained in paragraph 22 of the consultation, “Articles 97(1)(a) and 97(4) of PSD2 are clear that the requirement to perform SCA also applies when an AISP, acting on the customer’s behalf, is accessing the account information.” We understand the EBA does not see it has any leeway on this from a legal or mandate perspective. However, the discussion triggered some further internal thinking on our part about the need to accommodate greater automation (for AIS but also potential PIS use cases based on variable recurring payments), which we thought it would be useful to share as it may be pertinent to consider in the context of the upcoming PSD2 review and any interactions between the EBA and European Commission on this topic.
A Payment Service User (PSU i.e. an account holder) will have a need to consent to both:
a) an AISP use-case where account information is accessed once (and only once) to perform and provide some processing or analysis of the account information to derive a one-time result, e.g., how much can I borrow for a mortgage?
b) an AISP use-case where account information is accessed on a regular basis, say daily, to automatically perform ongoing analysis or derivation of results until the PSU cancels that service.
We would propose that, in the case of (a), the PSU should satisfy SCA at the beginning, and it should only be good for a one-time access. If there is PSU consent for the AISP to access the account information a further time, then a further SCA (of the one-time variety) should be required again.
In contrast, in the case of (b), the PSU should satisfy SCA at the beginning, but the consent associated with this SCA is for an indefinite period, ceasing when the PSU revokes the consent either directly with the ASPSP, or with the AISP, who subsequently should have a mechanism to communicate to the ASPSP that the consent has been terminated.
In some respects, the current RTS Article 10 exemption, which allows for 90-days before having to seek again SCA, and which Q2 is looking to extend to 180 days, is a mechanism that doesn’t properly satisfy either use-case (a) or (b). For the former, the PSU’s intention for a one-time access can potentially be left “open” for 90 days, and for the latter there is the added friction of having to renew the consent via periodic confirmation of SCAs, which interrupts automation.
Query as to interpretation
Further, as was flagged by several speakers during the Public Hearing, some additional clarification regarding application of the 180-day ‘count’ would be welcome in terms of its initial implementation once the final revised Regulatory Technical Standards (RTS) have been published in the Official Journal.
Since the current RTS are already in force, ASPSPs will be keeping track of when SCA was last applied, whether information is being accessed directly by the customer through the ASPSP or via an AISP. Does this ‘count’ continue in the same way or does the ‘clock’ get re-set so that the 180-days begins from the date when the revised RTS apply, irrespective of when SCA was applied in the preceding period? It is particularly important to understand the requirement in view of the proposed mandatory nature of application of the exemption to access to account information when an AISP is involved.
Q3. Do you have any comments on the proposed 6-month implementation timeline, and the requirement for ASPSPs to make available the relevant changes to the technical specifications of their interfaces not less than one month before such changes are required to be implemented?
We welcome the fact that the EBA has acknowledged that the revised requirements will require some action on the part of ASPSPs and AISPs and is therefore proposing a 6-month implementation period. The consultation paper helpfully provides, in paragraph 49, an indication as to when the changes are likely to come into effect, namely from Q4 2022. This is useful from a planning and budgeting perspective although we appreciate that it is just an estimate and that the actual date will be dictated by the legislative process, much of which is outside the EBA’s control.From our perspective as an ASPSP, we think that a 6-month implementation timeframe should be considered a bare minimum and ideally it should be 12 months. The suggestion for a longer implementation period is not so much driven by the complexity of the task but rather the need to accommodate technology investment decision-making timeframes. Many organisations plan on an annual basis and the spend for 2022 will already have been set without prior knowledge of this potential additional technological change.
We note that in Article 3 of the draft Delegated Regulation amending the RTS (and as articulated in paragraph 50 of the consultation paper, the EBA has also proposed a derogation from the requirements of Article 30(4) RTS. As such ASPSPs will be “required to make available to AISPS the changes made to the technical specifications of their interfaces…at least one month ahead of their implementation”. Our understanding is therefore that ASPSPs will need to make their revised technical specifications available to AISPs at least 1 month before the revised RTS apply so, for example, if the RTS were to apply from 30 November 2022, those specifications should be available by or before 31 October. We believe this is feasible.