Response to public hearing on the Consultation paper on the amendment of the RTS on SCA&CSC under PSD2
Go back
ETPPA fully agrees that a new mandatory exemption is required for the case when the PSU accesses their account information “through an AISP” pursuant to PSD2 Art. 97(4), i.e. PSU => AISP => ASPSP.
ETPPA believes that this proposal is a very positive step towards a better implementation of PSD2. This mandatory exemption will allow fair competition in Europe, with the same rules for the same service. We would like to commend and thank the EBA for harmonising and clarifying this part of the PSD2 implementation in Europe.
We also note and support the newly proposed Art. 10a(3), which is indeed required to avoid any circumvention by ensuring justification of any imposed SCA on request.
The remainder of this response is making suggestions for additional improvements and a different interpretation for some other cases. This is meant to expand the current EBA proposal, but it should not lead to any reduction, delay or abandonment of the proposal, because the status quo should not be retained, no matter what.
A1.2) PSU offline - access by the AISP itself
The above case is, however, different from the case where the information is accessed “by an AISP” itself, i.e. AISP => ASPSP, when the PSU is not online. Bird & Bird has recently stated that:
"Based on the wording of Article 36(5)(b) of the RTS, one could take the view that (1) a background refresh is not an instance of the payer accessing its payment account online (which in principle requires SCA under PSD2) but instead an instance of the AISP (but not the payer) accessing the payment account online and therefore not an event requiring SCA under PSD2, and/or (2) AISPs have an unconditional right pursuant to the RTS to perform background refreshes irrespective of the use or non-use of an optional exemption to SCA by the ASPSP (i.e. the AISP’s right to perform a background refresh should be not made conditional on the ASPSP deciding to make use of an optional exemption)."
(Source: https://www.twobirds.com/en/news/articles/2021/global/eba-consults-on-changes-to-strong-customer-authentication)
PSD2 Art. 97(1a) requires SCA “where the payer accesses its payment account online”, which is different from “where the payer accesses its online payment account”. The latter would not imply that the payer must be online, whereas the actual text does imply exactly that. Similarly, PSD2 Art. 97(4) says “information is requested through an AISP”, which is different from the case where the “information is requested by an AISP”. Hence, in the case where the payer is not online and therefore does not access its payment account online, neither directly nor “through” an AISP, both PSD2 Art. 97(1a) and Art. 97(4) should not apply. Consequently, the case where the information is accessed “by an AISP” in the absence of the payer is in our view not regulated under PSD2 Art. 97 and therefore does not require an SCA, although we are aware that such access is restricted to four times in a 24-hour period according to RTS Art. 36(5b). This restriction does not apply when the PSU actively requests such information, i.e. “through” the AISP, but this is then the case of provision PSD2 Art. 97(4), where an SCA is required, unless the proposed new mandatory exemption of Art. 10 does apply.
We believe that SCA could not and should not apply when the customer/PSU is not present, i.e. cannot be authenticated. PSD2 has provided a solution to avoid the previous practice of TPPs “impersonating” the customer by introducing eIDAS-based security and mandating TPPs to identify themselves. Hence, it is now the TPP who can and should be authenticated, when accessing the PSU’s account. This is where all the PSD2 security measures around AISPs come into play, e.g. secure communication with the ASPSP, eIDAS certificates, use of tokens, licensing, supervision, security audits, etc., and which was in our understanding the main reason for bringing AISPs into the scope of PSD2.
A1.3) Risk-proportionality
PSD2 Art. 98 (2a) mandates the RTS to “ensure an appropriate level of security for payment service users and payment service providers, through the adoption of effective and risk-based requirements” and PSD2 Art. 98(3a) stipulates that exemptions “shall be based on ... the level of risk involved in the service provided”. Whilst there is no day passing by without payments fraud, ETPPA is not aware of any statistics or even a single fraud case ever, which occurred because an SCA was not applied to simply accessing an account, i.e. without moving any money from it. The Consultation Paper paragraphs 32-35 lists multiple reasons why there is very little risk incurred, including the case where an AISP is involved, which is a regulated and supervised entity that cannot access any account without obtaining and using a qualified eIDAS certificate. We believe that SCA serves an essential purpose for payments, but not for account access itself. Unless there is any evidence of such fraud cases, PSD2 Art. 97 (1a) should be deleted altogether in the upcoming review of this directive.
In the meantime and according to PSD2 Art. 98(2a) & (3a), it would not be an “effective and risk-based requirement” nor “be based on the level of risk involved” if RTS Art. 10 was amended in a way that would require the application of any SCA relating to account access, unless
- there is a specific security concern as detailed in RTS Art. 2; or
- the account is accessed for the first time, either directly or through an AISP, where in the latter case this serves as the PSU’s consent and mandate for future access “by the AISP” itself.
As a matter of fact, any recurring SCA actually increases the risk of fraud in the case of account access, because it offers recurring opportunities for man-in-the-middle attacks (especially when requiring redirection), without adding any further protection of the data accessed. The initial SCA serves the purpose to ensure that the (repeat) access token is given to the rightful account holder or to their consented AISP. Any change of the account or its ownership would render this token invalid, hence there is only added risk, but no added value, in re-authenticating the account holder at any periodic stage.
Hence, there is neither any evidenced risk, nor added mitigation that could justify repeat SCAs. On the other side, there is plenty of evidence for the negative impacts these repeat SCAs have on consumers, SMEs and TPPs. These are ranging from severe inconvenience and disruption of previously automated business processes, in the best case, to business losses and bankruptcy, in the worst case. Consequently, weighing both sides against each other, i.e. establishing the “risk-proportionality” of this measure, it is very clear in our mind that it cannot be justified from that perspective.
A1.4) No SCA when PSUs are not actively involved
Therefore, we disagree with the EBA’s conclusion in paragraph 22 of the Consultation Paper, because
- Articles 97(1)(a) and 97(4) of PSD2 are not clear that the requirement to perform SCA also applies when an AISP, acting on the customer’s behalf, is accessing the account information. To the contrary, we believe that they clearly apply only to the case where the PSU is online and accesses its payment account either directly or through an AISP.
- The AISPs regulatory obligations, in particular their mandatory identification when attempting to access an account ensures an appropriate level of security of the customer’s data, and would therefore still be in line with Article 97(1)(a) of PSD2. (unless any evidence can prove otherwise)
And accordingly, we must also disagree with the EBA’s conclusion in paragraph 23 of the Consultation Paper, because
- PSD2 [Art. 97] does not cover both the case where the PSU is actively requesting the information through the AISP and where the AISP is accessing the data without the PSU’s involvement (i.e, without the customer actively requesting the information).
- Otherwise, RTS Art. 36(5) would not make any sense, because it clearly differentiates between these two cases, where only in case a) the PSU’s active involvement can relate to an access “through an AISP” (PSU => AISP => ASPSP), whilst in case b) the PSU is not accessing anything at all.
- This latter case, RTS Art. 36(5b), has no reference to the fact that PSD2 Art. 97 or RTS Art. 10 would not apply, which can only mean that they do not apply “per se”.
We believe this to be the most plausible interpretation of the relevant articles, but even if this view could only be recognized as one possible interpretation, it follows from the required risk proportionality that any more stringent view could not be justified without clear risk evidence.
A1.5) Avoid unintended consequences for PISPs
The current Article 10 doesn’t limit the SCA exemption to be applied solely in the context of an AISP but instead in the case of account access in a broader context. Account access goes beyond the scope of AISPs as account access form part of current PIS journeys. Limiting the SCA exemption to AISPs only would have undesirable, and possibly unintentional, effects on PISPs. The PSU is impacted by the inconsistent application of the SCA exemption also in a PIS journey by ASPSPs across the EU. As an example, in a PIS journey, the PSU is required to review payment account information and select an account to be debited in the ASPSP domain. Such account information access should also benefit from the scope of the mandatory SCA exemption introduced in the proposed Art10a of an amended RTS. Therefore, we encourage the EBA to replace the explicit references to AISPs in Art.10a with references to “payment account access online through an authorized payment service provider”.
Furthermore, in the same way solutions exist for accessing accounts within an AIS journey (with an AIS access token) there is a similar way in a PIS journey (PIS access token). We see no real barriers for why this couldn't be included. Rather the contrary, as the account access in a PIS journey is limited to account numbers (which could be masked as well) and balances to the PSU only (no statement or transaction history, etc.) the exposure without SCA is also less than in the pure AIS case. Furthermore, it is our opinion that not limiting the SCA exemption for AISPs usage only would meet the objectives of the EBA in developing the RTS and doing so without jeopardizing the objective of ensuring the safety of PSUs’ funds and personal data:
- securing and maintaining fair competition among all PSPs, and more specifically enabling for PISP’s services to be more competitive, as well as;
- allowing for the development of user-friendly, accessible and innovative means of payment
The largest part of a typical PSU onboarding process of an AISP is the SCA requested when the PSU accesses their account online “though the AISP” for the first time, which serves as the PSU’s consent and mandate for future access “by the AISP” itself. The need to renew this mandate with another SCA vis-à-vis the ASPSP every 90 days, resulted in a situation where the AISP is basically losing their whole customer base every 90 days and has to re-onboard them all from scratch. Losing your customers every 180 days is slightly better, but it does not resolve the core of the problem.
To our knowledge, there is no other precedence of such a situation in any other industry, and not even in banking itself. Previously, service providers in many industries, especially in online marketing, were attempting a customer lock-in by defaulting users into their service and then making an opt-out very cumbersome. Thankfully, regulators have taken care of this and common practice is now the requirement for a) an initial, explicit opt-in to any service, and b) facilitating an easy (1-click) opt-out to ensure that customers are not getting locked in. This is also the standard for financial services, including direct debits.
It should also be considered that we are not talking about any dubious email newsletters here, but about regulated financial services, which people rightfully expect to be reliable, for example for balance alerts and budgeting purposes. These cannot be cut off after some period, just because the PSU has forgotten to renew their willingness to receive them. Imagine, customers would lose their internet or telephone connection every 180 days, or electricity, or water. It is important to ensure that services can be terminated easily if and when desired, but terminating them automatically is unheard of and can cause serious financial harm.
Requiring AISPs to obtain a regularly recurring re-opt-in of their whole customer base is not only unique across all industries, but completely disproportionate to the low risk of their service. Furthermore, stipulating not just a “re-consent” vis-à-vis the AISP, but an SCA vis-à-vis the ASPSP aggravates the user experience to an unbearable level. If anything, AIS should be subject to a less stringent process than applied to more risky services, like direct debit, but under no circumstances it should be more. Therefore, ETPPA believes that the common (and best) practice should be applied, whereby there is an initial, explicit opt-in, preferably by giving consent to the AISP, but - as a one-off - an SCA with the ASPSP would be acceptable, too. In addition, there should then be a requirement for an easily accessible 1-click opt-out, either in the AISP’s app or website.
ETPPA cannot see any justification for any requirement beyond this common practice, and especially not for requiring any re-opt-in. If there were to be any evidence or justification for such a requirement, this should still not go any further than obliging a re-consent vis-à-vis the AISP, i.e. what has been proposed by the UK FCA in their consultation.
Requiring a recurring SCA with the ASPSP is the maximum handicap an AISP can be given in comparison with any other service provider, and if the lock-in risk of an AISP is really seen to be so much higher than for any other service in the market, then we would like to ask for allowing an even longer period than 180 days. One, or better two years, would cut the AISPs renewal costs further down into half, respectively a quarter, without requiring any principal change of the approach.
This is also required to minimise the negative impacts on the customer journey. When clients give access to bank accounts located in different banks, they have to perform an SCA for each bank (sometimes 3 or 4 SCAs). This painful experience must be limited to avoid claims of the client and a loss of business for the TPP, which - not to be forgotten - are regulated institutions able to deal with clients’ consent.
A2.2) Access via commercial interfaces
It should also be noted that TPPs, using dedicated interfaces, are currently facing unfair competition with other interfaces, offered commercially by ASPSPs under a contract to regulated or unregulated institutions allowing a “payer to access its payment account online”. An example for this is EBICS T, which is one of two EBICS variations:
- EBICS TS, concerning payments
- EBICS T, concerning account information
EBICS TS is exempted from SCA by ASPSPs in some European Countries, according to PSD2 Art. 17. ETPPA has no objection to that practice, which is in any case not part of this consultation, as it does not concern article 10 of the RTS.
However, different to EBICS TS, EBICS T is an interface allowing access to bank account information. EBICS T is in scope of article 10 (and this consultation), as it allows access to:
1) the balance of one or more designated payment accounts
2) the payment transactions executed in the last 90 days through one or more designated payment accounts
When a client accesses account information via EBICS T, no SCA is required in some countries (like France). On the other hand, when this same client wants to access account information via a PSD2 API, the client will have to perform an SCA. ETPPA considers that the SCA rules should apply in the same way for all interfaces, both EBICS T and PSD2 API.
ETPPA would ask the EBA to clarify, for example in a recital, that the exemption of the article 10 applies to all accesses to the balance of payment accounts and payment transactions, and not just to the PSD2 dedicated interfaces. In the same way, when the SCA exemption of the article 10 does not apply, EBICS T or other non-PSD2 dedicated interfaces access must also be concerned.
A2.3) Unlimited transaction history
Finally, in correspondence with amending the 90-day SCA, ETPPA believes that the RTS Art. 10(1b) limitation to the 90-day transaction history, has not proven to add any value, and should be eliminated as well. If anything, older transactions are less relevant today than newer ones, and this restriction is causing unnecessary and, in our view, unjustified overheads to the technical integrations. Some ASPSPs are even using this article to justify a second SCA for data older than 90-days. Rather than just clarifying that this would not be compliant, it would be better to remove this clause altogether. As a minimum, the historical period should be re-aligned with a potentially amended re-consent or re-authentication period, if that cannot be avoided at all.
At the public hearing, it became quite clear that ASPSPs are keen to keep as many limits as possible, so that they can then monetise the lifting of these limitations. We must expect that anything, which is left to their discretion, will then be sold as a premium service. The card issuers maximisation of SCA exemptions is a blatant example of that. As stated above, there should not be any security concern about retrieving transaction information older than 90 days, but if this limit were to be sustained, it could then not be abused for monetisation. This data belongs to the PSU, not the ASPSP, no matter how old it is.
Furthermore, ASPSPs already have in place technical solutions (that includes access tokens) for account access. It’s deemed that extending the SCA time limit would reuse the same technical solution that ASPSPs already have in place. There wouldn’t be a need to introduce new technical solutions to meet an extended time limit. Rather, adjusting the validity period of the technical solution that already exists to comfort the new timeline of SCA exemption is more of a configuration instead of the introduction of a complex new solution for ASPSPs. Please note that even those banks, which are not applying the 90-day exemption so far at all, must have implemented this token approach to allow 4 times per day access without customer presence. Thus, there should not be a need for having an implementation timeline of 6 months. A more realistic timeline would be 3 months.
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?
A1.1) PSU online - access through an AISPETPPA fully agrees that a new mandatory exemption is required for the case when the PSU accesses their account information “through an AISP” pursuant to PSD2 Art. 97(4), i.e. PSU => AISP => ASPSP.
ETPPA believes that this proposal is a very positive step towards a better implementation of PSD2. This mandatory exemption will allow fair competition in Europe, with the same rules for the same service. We would like to commend and thank the EBA for harmonising and clarifying this part of the PSD2 implementation in Europe.
We also note and support the newly proposed Art. 10a(3), which is indeed required to avoid any circumvention by ensuring justification of any imposed SCA on request.
The remainder of this response is making suggestions for additional improvements and a different interpretation for some other cases. This is meant to expand the current EBA proposal, but it should not lead to any reduction, delay or abandonment of the proposal, because the status quo should not be retained, no matter what.
A1.2) PSU offline - access by the AISP itself
The above case is, however, different from the case where the information is accessed “by an AISP” itself, i.e. AISP => ASPSP, when the PSU is not online. Bird & Bird has recently stated that:
"Based on the wording of Article 36(5)(b) of the RTS, one could take the view that (1) a background refresh is not an instance of the payer accessing its payment account online (which in principle requires SCA under PSD2) but instead an instance of the AISP (but not the payer) accessing the payment account online and therefore not an event requiring SCA under PSD2, and/or (2) AISPs have an unconditional right pursuant to the RTS to perform background refreshes irrespective of the use or non-use of an optional exemption to SCA by the ASPSP (i.e. the AISP’s right to perform a background refresh should be not made conditional on the ASPSP deciding to make use of an optional exemption)."
(Source: https://www.twobirds.com/en/news/articles/2021/global/eba-consults-on-changes-to-strong-customer-authentication)
PSD2 Art. 97(1a) requires SCA “where the payer accesses its payment account online”, which is different from “where the payer accesses its online payment account”. The latter would not imply that the payer must be online, whereas the actual text does imply exactly that. Similarly, PSD2 Art. 97(4) says “information is requested through an AISP”, which is different from the case where the “information is requested by an AISP”. Hence, in the case where the payer is not online and therefore does not access its payment account online, neither directly nor “through” an AISP, both PSD2 Art. 97(1a) and Art. 97(4) should not apply. Consequently, the case where the information is accessed “by an AISP” in the absence of the payer is in our view not regulated under PSD2 Art. 97 and therefore does not require an SCA, although we are aware that such access is restricted to four times in a 24-hour period according to RTS Art. 36(5b). This restriction does not apply when the PSU actively requests such information, i.e. “through” the AISP, but this is then the case of provision PSD2 Art. 97(4), where an SCA is required, unless the proposed new mandatory exemption of Art. 10 does apply.
We believe that SCA could not and should not apply when the customer/PSU is not present, i.e. cannot be authenticated. PSD2 has provided a solution to avoid the previous practice of TPPs “impersonating” the customer by introducing eIDAS-based security and mandating TPPs to identify themselves. Hence, it is now the TPP who can and should be authenticated, when accessing the PSU’s account. This is where all the PSD2 security measures around AISPs come into play, e.g. secure communication with the ASPSP, eIDAS certificates, use of tokens, licensing, supervision, security audits, etc., and which was in our understanding the main reason for bringing AISPs into the scope of PSD2.
A1.3) Risk-proportionality
PSD2 Art. 98 (2a) mandates the RTS to “ensure an appropriate level of security for payment service users and payment service providers, through the adoption of effective and risk-based requirements” and PSD2 Art. 98(3a) stipulates that exemptions “shall be based on ... the level of risk involved in the service provided”. Whilst there is no day passing by without payments fraud, ETPPA is not aware of any statistics or even a single fraud case ever, which occurred because an SCA was not applied to simply accessing an account, i.e. without moving any money from it. The Consultation Paper paragraphs 32-35 lists multiple reasons why there is very little risk incurred, including the case where an AISP is involved, which is a regulated and supervised entity that cannot access any account without obtaining and using a qualified eIDAS certificate. We believe that SCA serves an essential purpose for payments, but not for account access itself. Unless there is any evidence of such fraud cases, PSD2 Art. 97 (1a) should be deleted altogether in the upcoming review of this directive.
In the meantime and according to PSD2 Art. 98(2a) & (3a), it would not be an “effective and risk-based requirement” nor “be based on the level of risk involved” if RTS Art. 10 was amended in a way that would require the application of any SCA relating to account access, unless
- there is a specific security concern as detailed in RTS Art. 2; or
- the account is accessed for the first time, either directly or through an AISP, where in the latter case this serves as the PSU’s consent and mandate for future access “by the AISP” itself.
As a matter of fact, any recurring SCA actually increases the risk of fraud in the case of account access, because it offers recurring opportunities for man-in-the-middle attacks (especially when requiring redirection), without adding any further protection of the data accessed. The initial SCA serves the purpose to ensure that the (repeat) access token is given to the rightful account holder or to their consented AISP. Any change of the account or its ownership would render this token invalid, hence there is only added risk, but no added value, in re-authenticating the account holder at any periodic stage.
Hence, there is neither any evidenced risk, nor added mitigation that could justify repeat SCAs. On the other side, there is plenty of evidence for the negative impacts these repeat SCAs have on consumers, SMEs and TPPs. These are ranging from severe inconvenience and disruption of previously automated business processes, in the best case, to business losses and bankruptcy, in the worst case. Consequently, weighing both sides against each other, i.e. establishing the “risk-proportionality” of this measure, it is very clear in our mind that it cannot be justified from that perspective.
A1.4) No SCA when PSUs are not actively involved
Therefore, we disagree with the EBA’s conclusion in paragraph 22 of the Consultation Paper, because
- Articles 97(1)(a) and 97(4) of PSD2 are not clear that the requirement to perform SCA also applies when an AISP, acting on the customer’s behalf, is accessing the account information. To the contrary, we believe that they clearly apply only to the case where the PSU is online and accesses its payment account either directly or through an AISP.
- The AISPs regulatory obligations, in particular their mandatory identification when attempting to access an account ensures an appropriate level of security of the customer’s data, and would therefore still be in line with Article 97(1)(a) of PSD2. (unless any evidence can prove otherwise)
And accordingly, we must also disagree with the EBA’s conclusion in paragraph 23 of the Consultation Paper, because
- PSD2 [Art. 97] does not cover both the case where the PSU is actively requesting the information through the AISP and where the AISP is accessing the data without the PSU’s involvement (i.e, without the customer actively requesting the information).
- Otherwise, RTS Art. 36(5) would not make any sense, because it clearly differentiates between these two cases, where only in case a) the PSU’s active involvement can relate to an access “through an AISP” (PSU => AISP => ASPSP), whilst in case b) the PSU is not accessing anything at all.
- This latter case, RTS Art. 36(5b), has no reference to the fact that PSD2 Art. 97 or RTS Art. 10 would not apply, which can only mean that they do not apply “per se”.
We believe this to be the most plausible interpretation of the relevant articles, but even if this view could only be recognized as one possible interpretation, it follows from the required risk proportionality that any more stringent view could not be justified without clear risk evidence.
A1.5) Avoid unintended consequences for PISPs
The current Article 10 doesn’t limit the SCA exemption to be applied solely in the context of an AISP but instead in the case of account access in a broader context. Account access goes beyond the scope of AISPs as account access form part of current PIS journeys. Limiting the SCA exemption to AISPs only would have undesirable, and possibly unintentional, effects on PISPs. The PSU is impacted by the inconsistent application of the SCA exemption also in a PIS journey by ASPSPs across the EU. As an example, in a PIS journey, the PSU is required to review payment account information and select an account to be debited in the ASPSP domain. Such account information access should also benefit from the scope of the mandatory SCA exemption introduced in the proposed Art10a of an amended RTS. Therefore, we encourage the EBA to replace the explicit references to AISPs in Art.10a with references to “payment account access online through an authorized payment service provider”.
Furthermore, in the same way solutions exist for accessing accounts within an AIS journey (with an AIS access token) there is a similar way in a PIS journey (PIS access token). We see no real barriers for why this couldn't be included. Rather the contrary, as the account access in a PIS journey is limited to account numbers (which could be masked as well) and balances to the PSU only (no statement or transaction history, etc.) the exposure without SCA is also less than in the pure AIS case. Furthermore, it is our opinion that not limiting the SCA exemption for AISPs usage only would meet the objectives of the EBA in developing the RTS and doing so without jeopardizing the objective of ensuring the safety of PSUs’ funds and personal data:
- securing and maintaining fair competition among all PSPs, and more specifically enabling for PISP’s services to be more competitive, as well as;
- allowing for the development of user-friendly, accessible and innovative means of payment
Q2. Do you have any comments on the proposal to extend the timeline for the renewal of SCA to 180-days?
A2.1) Easy opt-out instead of re-opt-inThe largest part of a typical PSU onboarding process of an AISP is the SCA requested when the PSU accesses their account online “though the AISP” for the first time, which serves as the PSU’s consent and mandate for future access “by the AISP” itself. The need to renew this mandate with another SCA vis-à-vis the ASPSP every 90 days, resulted in a situation where the AISP is basically losing their whole customer base every 90 days and has to re-onboard them all from scratch. Losing your customers every 180 days is slightly better, but it does not resolve the core of the problem.
To our knowledge, there is no other precedence of such a situation in any other industry, and not even in banking itself. Previously, service providers in many industries, especially in online marketing, were attempting a customer lock-in by defaulting users into their service and then making an opt-out very cumbersome. Thankfully, regulators have taken care of this and common practice is now the requirement for a) an initial, explicit opt-in to any service, and b) facilitating an easy (1-click) opt-out to ensure that customers are not getting locked in. This is also the standard for financial services, including direct debits.
It should also be considered that we are not talking about any dubious email newsletters here, but about regulated financial services, which people rightfully expect to be reliable, for example for balance alerts and budgeting purposes. These cannot be cut off after some period, just because the PSU has forgotten to renew their willingness to receive them. Imagine, customers would lose their internet or telephone connection every 180 days, or electricity, or water. It is important to ensure that services can be terminated easily if and when desired, but terminating them automatically is unheard of and can cause serious financial harm.
Requiring AISPs to obtain a regularly recurring re-opt-in of their whole customer base is not only unique across all industries, but completely disproportionate to the low risk of their service. Furthermore, stipulating not just a “re-consent” vis-à-vis the AISP, but an SCA vis-à-vis the ASPSP aggravates the user experience to an unbearable level. If anything, AIS should be subject to a less stringent process than applied to more risky services, like direct debit, but under no circumstances it should be more. Therefore, ETPPA believes that the common (and best) practice should be applied, whereby there is an initial, explicit opt-in, preferably by giving consent to the AISP, but - as a one-off - an SCA with the ASPSP would be acceptable, too. In addition, there should then be a requirement for an easily accessible 1-click opt-out, either in the AISP’s app or website.
ETPPA cannot see any justification for any requirement beyond this common practice, and especially not for requiring any re-opt-in. If there were to be any evidence or justification for such a requirement, this should still not go any further than obliging a re-consent vis-à-vis the AISP, i.e. what has been proposed by the UK FCA in their consultation.
Requiring a recurring SCA with the ASPSP is the maximum handicap an AISP can be given in comparison with any other service provider, and if the lock-in risk of an AISP is really seen to be so much higher than for any other service in the market, then we would like to ask for allowing an even longer period than 180 days. One, or better two years, would cut the AISPs renewal costs further down into half, respectively a quarter, without requiring any principal change of the approach.
This is also required to minimise the negative impacts on the customer journey. When clients give access to bank accounts located in different banks, they have to perform an SCA for each bank (sometimes 3 or 4 SCAs). This painful experience must be limited to avoid claims of the client and a loss of business for the TPP, which - not to be forgotten - are regulated institutions able to deal with clients’ consent.
A2.2) Access via commercial interfaces
It should also be noted that TPPs, using dedicated interfaces, are currently facing unfair competition with other interfaces, offered commercially by ASPSPs under a contract to regulated or unregulated institutions allowing a “payer to access its payment account online”. An example for this is EBICS T, which is one of two EBICS variations:
- EBICS TS, concerning payments
- EBICS T, concerning account information
EBICS TS is exempted from SCA by ASPSPs in some European Countries, according to PSD2 Art. 17. ETPPA has no objection to that practice, which is in any case not part of this consultation, as it does not concern article 10 of the RTS.
However, different to EBICS TS, EBICS T is an interface allowing access to bank account information. EBICS T is in scope of article 10 (and this consultation), as it allows access to:
1) the balance of one or more designated payment accounts
2) the payment transactions executed in the last 90 days through one or more designated payment accounts
When a client accesses account information via EBICS T, no SCA is required in some countries (like France). On the other hand, when this same client wants to access account information via a PSD2 API, the client will have to perform an SCA. ETPPA considers that the SCA rules should apply in the same way for all interfaces, both EBICS T and PSD2 API.
ETPPA would ask the EBA to clarify, for example in a recital, that the exemption of the article 10 applies to all accesses to the balance of payment accounts and payment transactions, and not just to the PSD2 dedicated interfaces. In the same way, when the SCA exemption of the article 10 does not apply, EBICS T or other non-PSD2 dedicated interfaces access must also be concerned.
A2.3) Unlimited transaction history
Finally, in correspondence with amending the 90-day SCA, ETPPA believes that the RTS Art. 10(1b) limitation to the 90-day transaction history, has not proven to add any value, and should be eliminated as well. If anything, older transactions are less relevant today than newer ones, and this restriction is causing unnecessary and, in our view, unjustified overheads to the technical integrations. Some ASPSPs are even using this article to justify a second SCA for data older than 90-days. Rather than just clarifying that this would not be compliant, it would be better to remove this clause altogether. As a minimum, the historical period should be re-aligned with a potentially amended re-consent or re-authentication period, if that cannot be avoided at all.
At the public hearing, it became quite clear that ASPSPs are keen to keep as many limits as possible, so that they can then monetise the lifting of these limitations. We must expect that anything, which is left to their discretion, will then be sold as a premium service. The card issuers maximisation of SCA exemptions is a blatant example of that. As stated above, there should not be any security concern about retrieving transaction information older than 90 days, but if this limit were to be sustained, it could then not be abused for monetisation. This data belongs to the PSU, not the ASPSP, no matter how old it is.
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?
A3) Given the urgency of this amendment and the existential problems of the B2C AISPs, which still exist, we cannot lose any time whatsoever. ETPPA would not object to reducing the standard 3-month notice on interface changes to one month or even less, but in return we should also reduce the implementation timeline to a maximum of 3 months.Furthermore, ASPSPs already have in place technical solutions (that includes access tokens) for account access. It’s deemed that extending the SCA time limit would reuse the same technical solution that ASPSPs already have in place. There wouldn’t be a need to introduce new technical solutions to meet an extended time limit. Rather, adjusting the validity period of the technical solution that already exists to comfort the new timeline of SCA exemption is more of a configuration instead of the introduction of a complex new solution for ASPSPs. Please note that even those banks, which are not applying the 90-day exemption so far at all, must have implemented this token approach to allow 4 times per day access without customer presence. Thus, there should not be a need for having an implementation timeline of 6 months. A more realistic timeline would be 3 months.